RAG 聊天机器人为什么会在复杂请求面前停下?
做出一个企业级 RAG 聊天机器人后,很快就会看到它的极限。它接到问题后检索文档、生成回答——这种直线结构就是单线管道。面对“找出去年第四季度的业绩,再把今年的战略提案初稿写出来”这样的请求,一个只会检索和回答的管道,根本没有执行这项工作的路径。
循环和分支为什么是智能的核心?
便利店没有水时,人会打开地图找旁边那家便利店。单线管道只会说“没有”然后停下。检索没有结果就换个关键词再试,还是不行就改用别的工具——受阻时折返的循环、依情况改道的分支,这两者就是智能的核心,而设计它们的工作就是编排。
角色分为三部分。LangChain 提供与 LLM 对话的标准组件,LangGraph 提供绘制循环和分支的控制流,LangSmith 提供看清系统内部的可观测性。三者齐备,才构成一个完整的编排系统。
没有可观测性会失去什么?——税务咨询自动化
可观测性常被忽视,但没有它,就无法回溯 AI 所给答案的依据。以税务咨询为例,经办人员每天要花一两个小时翻查税法条款和客户的赠与记录。要把这项工作自动化,就需要在法条检索和记录查询之间往返的分支。
何况在错误答案会带来法律责任的领域,还必须留下审计日志,记录答案是依据哪条条款、哪段记录得出的。留下这份依据的痕迹,正是可观测性,也正是 LangSmith 承担的职责。
非开发者在这套设计中承担什么?
在这套设计里,非开发者的分量比想象中更重。决定放入哪些数据的数据所有权,把业务逻辑画成流程图,用100道问题和标准答案做成评估集——这些全是领域知识,而非编程。只要会画流程图,把它变成代码的事交给 Vibe Coding 就行。
不过,给一次 API 调用就能完成的工作套上编排,是一种浪费。它是当业务复杂到需要循环和分支时才拿出来的工具。AX 的起点不是工具,而是能亲手画出业务流程的领域知识。