写在前面：上篇我们搭了一个能跑的朴素 RAG，也认领了它的五个硬伤。这篇开始打补丁——针对其中两个最"伤智商"的问题：所有问题都无脑检索（1+1 也要翻书）和多跳问题搜不准（答案不在任何一段原文里，要跳好几次）。readme 给的药方很明确——前者靠"llm 来判断简单"，后者靠"llm 规划能力，拆分，分步骤"。两个 demo 文件，一个教 RAG 分诊，一个教 RAG 拆题。以下所有代码均来自课堂真实文件。
一、补丁一：给 RAG 装一个分诊台
医院的分诊逻辑
去医院看病，进门先遇到分诊台——不是所有病人都直接推进手术室。护士问两句：
- "挂个号开个药" → 普通门诊
- "胸口疼、呼吸困难" → 急诊
分诊的价值在于把资源用在对的地方。对所有病人一律上全套检查，是浪费，也是灾难。
朴素 RAG 就是那种"全部上全套"的医院——你问"1+1 等于几"，它也要去《天龙八部》里搜五段原文出来。readme 的判断：
"所有问题都走 RAG 检索？简单问题不需要检索，浪费资源（token 和 检索，增强流程）。1+1=？两个分支，一个简单的问题，一个复杂的问题。llm 来判断简单？"
"llm 来判断" —— 这四个字就是解法。
路由状态：先加一个"路线"字段
rag-query-router.mjs 比上篇的朴素版本多了一个关键字段：
const GraphState = Annotation.Root({
question: Annotation,
k: Annotation,
strategy: Annotation, // ← 新增：策略
routeReason: Annotation, // ← 新增：判断理由
documents: Annotation,
generation: Annotation,
})
strategy 存的是"走哪条路"，routeReason 存的是"为什么这么走"——后者不只是为了好看，它是可观测性的基础。 出了问题你能看到模型当时是怎么想的。
路由节点：用结构化输出做判断
const RouteSchema = z.object({
// 枚举
strategy: z.enum(["simple", "complex"]),
reason: z.string(),
});
这里用了结构化输出 + Zod 枚举——前面专门学过的知识，现在派上大用场了。
z.enum(["simple", "complex"]) 意味着模型只能在这两个值里选一个。这就避免了模型回答"可能是简单的吧"这种没法用代码判断的模糊输出。
const routeQuestionNode = async (state) => {
console.log('___ROUTE-QUESTION___');
// 结构化输出
const router = model.withStructuredOutput(RouteSchema);
const route = await router.invoke(`
你是问答路由器，请判断用户问题是否需要外部检索。
规则：
- simple 常识问答、简短定义、无需特定小说细节即可回答。
- complex 需要《天龙八部》具体情节、人物关系、章节事实、原文细节或证据支持。
用户问题: ${state.question}
`)
console.log(`路由策略：${route.strategy} ${route.reason}`)
return {
question:state.question,
k:state.k,
strategy: route.strategy,
routeReason: route.reason,
}
}
这就是"分诊护士"的全部工作。 几句 prompt 说清判断标准，剩下的交给模型。
prompt 里的两句规则设计得很精准：
| 策略 | 判断标准 |
|---|---|
simple | 常识问答、简短定义、无需特定小说细节 |
complex | 需要《天龙八部》具体情节、人物关系、章节事实、原文细节或证据 |
关键词是"无需特定小说细节"和"需要原文细节或证据"——把判断标准落在"是否需要查资料"这个本质问题上，而不是落在"问题长短"这种表面特征上。
这才是好的路由 prompt：给判断依据，不给判断捷径。
两条分支：直答 vs 检索
const directAnswerNode = async (state) => {
console.log('___DIRECT-ANSWER___');
process.stdout.write("\n [AI 回答(流式)] \n")
let generation = "";
const stream = await model.stream(`你是一个中文回答助手，
请简洁回答问题。
问题：${state.question}
`)
// ... 流式输出 ...
return {
question:state.question,
k:state.k,
strategy: state.strategy,
routeReason: state.routeReason,
documents: [], // ← 注意：没有文档
generation: generation,
}
}
注意 documents: [] ——直答节点不产生任何文档。这个细节很重要：它明确表达了"这条路没检索"，而不是含糊地留空。
对比一下两条路的 prompt：
| 节点 | prompt 特点 |
|---|---|
directAnswerNode | "你是一个中文回答助手，请简洁回答问题" —— 轻量、直接 |
generateNode（RAG 那条路） | 五条防幻觉要求 + 拼接的 context —— 重装备、严谨 |
两条路的 prompt 完全不同——这也是分诊的意义：不是省了一次检索，而是给不同复杂度的问题配不同规格的处理流程。
编排：一个条件边搞定
const decideNext = (state) => {
return state.strategy === "simple" ? "direct_answer" : "retrieve";
}
const graph = new StateGraph(GraphState)
.addNode("route_question", routeQuestionNode)
.addNode("direct_answer", directAnswerNode)
.addNode("retrieve", retrieveNode)
.addNode("rag_generate", generateNode)
.addEdge(START, "route_question")
.addConditionalEdges("route_question",decideNext, {
direct_answer: "direct_answer",
retrieve: "retrieve",
})
.addEdge("retrieve", "rag_generate")
.addEdge("direct_answer", END)
.addEdge("rag_generate", END)
.compile()
流程图长这样：
┌→ direct_answer → END （简单问题，直接答）
START → route_question
└→ retrieve → rag_generate → END （复杂问题，检索再答）
上篇那条"一条道走到黑"的直线，现在有了岔路口。
条件边 addConditionalEdges 前面学过——decideNext 返回 "direct_answer" 还是 "retrieve"，决定了走哪条。
测试它：一个"不该检索"的问题
const question = 'js写一个add函数';
const k = 5;
看到这个测试问题，我笑了——这是个用来问《天龙八部》助手的测试用例。
但它设计得太聪明了：js写一个add函数 跟《天龙八部》毫无关系，也完全不需要查小说。
- 朴素 RAG：硬去书里搜 5 段最相似的文字（大概是"武功招式"之类的）→ 然后基于这些莫名其妙的内容回答 → 大概率胡说
- 现在的路由版：判断为
simple→ 走direct_answer→ 不检索，直接正常回答
这个测试用例的精妙之处在于：它验证的不是"能不能答对"，而是"能不能不检索"。
一条负向测试——好的测试用例常常是反着设计的。
二、补丁二：给 RAG 装上拆题能力
分诊解决了"要不要检索"，接下来解决"检索什么"。
多跳问题长什么样
readme 给的那道题，我上篇引用过，这里再挖深一点：
"天龙八部中 四大恶人 排行第二的是谁？此人之子在身世揭晓前，其生父在武林中的公开身份是什么？"
这道题有两个问句，但实际推理链条更长：
问句 1：四大恶人排行第二的是谁？
↓ 答案：叶二娘（"无恶不作"）
问句 2 的第一环：叶二娘的儿子是谁？
↓ 答案：虚竹
问句 2 的第二环：虚竹的生父是谁？
↓ 答案：玄慈
问句 2 的第三环：玄慈在武林中的公开身份是什么？
↓ 答案：少林寺方丈
要回答它，得跳四步。 而每一步的答案，分散在书中不同的章节里。
文件开头的注释也点出了另一个典型例子：
// 段誉遇到的第一个神仙姐姐画像，是谁的弟子？
// 直接把query 向量化匹配不够准确
// 支持子问题拆分的工作节点
"直接把 query 向量化匹配不够准确" —— 这句话就是病因诊断。
为什么不准？因为整句话的向量是"混合语义"：
"四大恶人排行第二的是谁？此人之子在身世揭晓前，其生父在武林中的公开身份是什么？"
↓ embedding
一个混合了【四大恶人】【儿子】【生父】【公开身份】的向量
↓ 去数据库搜
找到的片段：可能在讲"四大恶人"，也可能在讲"生父"
但很难有一段话同时覆盖这条链
一个向量，装不下一条推理链。 所以解法是——先拆，再分头检索。
拆解节点：让 LLM 当"出题老师"
const DecomposeSchema = z.object({
sub_question: z.array(z.string()).min(1).max(8),
reason: z.string(),
})
同样用结构化输出约束——sub_question 必须是 1 到 8 条的字符串数组。.min(1).max(8) 是 Zod 的数组长度约束。
const decomposeQuestionNode = async (state) => {
console.log('___DECOMPOSE-QUESTION___');
// 结构化输出
const decomposer = model.withStructuredOutput(DecomposeSchema);
const out = await decomposer.invoke(`
你是《天龙八部》多跳问答的【子问题拆解器】。
用户原始问题：
${state.question}
任务：将问题拆成**有序**子问题列表 sub_questions，用于**依次向量检索**。要求：
1. 链式推理、多层关系、因果先后的问题，必须拆成多条；单跳即可答也可输出一条。
2. 每条子问题必须是**可独立检索**的完整中文问句，**禁止**使用「他/她/此人/上文」等指代；可写全人物名与事件名。
3. 顺序必须符合推理链：先搞清前置实体/事实，再查后续结论。
4. **不要**把整句原题原样复制成唯一一条（除非确实无法拆分）；不要拆成过碎的关键词列表。
5. 输出 1～8 条即可。
请输出 sub_questions 与简短 reason。
`)
这五条要求，每一条都在防一个具体的坑。 值得逐条分析：
| 要求 | 防的坑 |
|---|---|
| 1. 链式推理必须拆成多条 | 防止模型偷懒，整句照搬 |
| 2. 禁止指代，要写全人物名 | 最精彩的一条 |
| 3. 顺序符合推理链 | 防止检索顺序颠倒导致后续查不到 |
| 4. 不要原样复制 / 不要拆太碎 | 两头防：防不拆，也防拆烂 |
| 5. 数量限定 1-8 条 | 防爆炸 |
重点看第 2 条——为什么禁止指代？
假设模型拆出这样的子问题：
❌ 他的儿子是谁？ ← "他"指谁？检索时不知道
❌ 此人的公开身份是什么？ ← "此人"又是谁？
因为检索是"独立"的——第二个子问题去数据库搜的时候，它不知道第一个子问题查到了"叶二娘"。指代词在脱离上下文后完全失效，向量化出来就是一团模糊语义。
正确的拆法是：
✅ 叶二娘的儿子是谁？
✅ 虚竹的生父是谁？
✅ 玄慈在武林中的公开身份是什么？
注意第三句——它用了"玄慈"这个只有走完前两步才知道的名字。 这说明模型在拆解时已经推演过整条链，把中间答案都补全了。
这就是 prompt 第 3 条"顺序必须符合推理链：先搞清前置实体/事实，再查后续结论"的深意——它要求模型先自己走一遍推理，再倒着把每一步写成可检索的问句。
一个"拆解器"，其实干了两件事：规划 + 预演。
拿到子问题后的处理
// 去除空格，排除不需要的question
const subQuestions = out.sub_question.map((s) => s.trim()).filter(Boolean);
if (subQuestions.length === 0) {
throw new Error("decompose_question: sub_questions 为空");
}
console.log(`拆解${subQuestions.length}条子问题(${out.reason})`);
subQuestions.forEach((q, i) => {
console.log(`[${i+1}] ${q}`);
});
return {
subQuestions,
nextSubIdx: 0, // 从第 0 条开始
currentQuery: subQuestions[0],
}
三层防御：
.trim()去空格.filter(Boolean)过滤空字符串（Boolean("")是false）- 空数组就抛异常——宁可报错，也不要带着空问题继续跑
nextSubIdx: 0 是"游标"——标记下一条要检索哪个子问题。 这是整个多跳流程的驱动器。
状态设计：12 个字段的巧思
多跳版本的状态膨胀到了 12 个字段：
const GraphState = Annotation.Root({
question: Annotation,
k: Annotation,
strategy: Annotation,
routeReason: Annotation,
subQuestions: Annotation, // 拆解出的子问题列表
nextSubIdx: Annotation, // question[i] 跳出循环
currentQuery: Annotation, // 当前子问题
retrievalCount: Annotation, // 已检索轮次
maxRetrievals: Annotation, // 最大轮次上限
plannedNext: Annotation, // 下一步决策
documents: Annotation,
generation: Annotation,
})
三个字段是循环控制三件套：
| 字段 | 作用 |
|---|---|
nextSubIdx | 走到第几条了（游标） |
retrievalCount | 已经查了几轮（计数） |
maxRetrievals | 最多查几轮（上限） |
注释写得很明白：
nextSubIdx: Annotation, // question[i] 跳出循环
question[i] 这个写法暗示了它的用法——像遍历数组一样，一条条处理子问题。 而"跳出循环"说明它兼作终止条件。
maxRetrievals 初始值 8：
maxRetrievals: state.maxRetrievals ?? 8,
?? 8 是"没设置就用 8"——给循环上了一道安全阀。
检索节点：一次查一条，累积去重
const retrieveNode = async (state) => {
const subs = state.subQuestions ?? [];
const idx = state.nextSubIdx ?? 0;
const q = subs[idx]?.trim(); // 当前这一轮问题
if (!q) {
throw new Error(`retrieve: 子问题下标${idx} 无有效文本
(共${subs.length}条)
`);
}
const round = state.retrievalCount + 1;
console.log(`----第${round}轮，子问题：${idx+1}/${subs.length}----`)
console.log(`---查询：${q}---`);
const newDocs = await retrieveRelevantContent(q, state.k);
// 多轮retrieve 有可能重复，会浪费资源
// 重复可能让llm 我们在强调，错觉
const merged = mergeUnique(state.documents ?? [], newDocs);
// ...
return {
documents: merged,
retrievalCount: round,
nextSubIdx: idx + 1,
currentQuery: q
}
}
这个节点每次只处理一条子问题——取出 subs[nextSubIdx]，检索，然后把游标 +1。
代码注释点出了去重的必要性：
// 多轮retrieve 有可能重复，会浪费资源
// 重复可能让llm 我们在强调，错觉
重复文档有两个害处：
- 浪费资源——同样的内容占两份 token
- 制造"错觉"——如果同一段文字出现三次，模型可能以为"这个信息被多次强调了，应该很重要"，从而高估它的权重
第二条很微妙——冗余会被模型误读为强调。 这是很多人想不到的坑。
去重函数：一个经典的取舍
const mergeUnique = (existingDocs, newDocs) => {
// map key 可以是对象
// has get
const map = new Map();// es6新增的HashMap 数据结构 key:value
for (const d of [...existingDocs, ...newDocs]) {
const key = String(d.id);
const prev = map.get(key);
if(!prev || Number(d.score) > Number(prev.score)){
map.set(key, d);
}
}
return Array.from(map.values()).sort((a, b) => Number(b.score) - Number(a.score));
}
十几行代码，完成三件事：
| 步骤 | 做法 |
|---|---|
| 去重 | 用 Map 按 id 做 key，同一个 id 只保留一条 |
| 择优 | 保留分数更高的那条 |
| 排序 | 按分数降序排列 |
"保留高分"这个决策值得细想。
同一段文字可能被多个子问题命中——比如"叶二娘"那段，既被"叶二娘的儿子是谁"命中，也被"虚竹的生父"命中。两次的相似度分数可能不同：
第一次命中：score = 0.72
第二次命中：score = 0.85 ← 这次更相关
保留哪个？这段代码选择留高分（Number(d.score) > Number(prev.score)）。
为什么合理？因为分数代表"这段话对这个具体问题的相关度"——0.85 那次说明这个子问题跟它更贴合，用高分数更真实地反映它的价值。
Number(d.score) 的强制转换是必要的——分数有时是字符串（尤其经过 JSON 序列化后），不转成数字比较会出错。
注释还提了一句 ES6 知识：
// es6新增的HashMap 数据结构 key:value
// map key 可以是对象
// has get
Map 和普通对象的区别——对象（Object）的 key 只能是字符串/符号，Map 的 key 可以是任何类型（包括对象）。这里虽然用的是字符串 key，但注释把这个特性点出来了。
Array.from(map.values()) 把 Map 的迭代器转成数组——因为 Map 不能直接 .sort()。
决策节点：该继续查，还是该回答了？
检索完一条，接下来要判断：够了吗？还要不要继续？
const NextStepSchema = z.object({
nextAction: z.string(["retrieve" , "generate"]),
reason: z.string(),
})
又一次结构化输出——nextAction 只能是 "retrieve" 或 "generate"。
const planNextStepNode = async (state) => {
console.log('___PLAN-NEXT-STEP___');
const subs = state.subQuestions ?? [];
const nextIdx = state.nextSubIdx ?? 0;
const remaining = subs.length - nextIdx;
const subList = subs.map((s, i) => `[${i+1}] ${s}
${i < nextIdx ? "已检索" : i === nextIdx ? "（下一轮将检索，若选择继续）" : "未检索"}`).join("\n");
这段代码在给模型画一张进度表：
[1] 四大恶人排行第二的是谁？ 已检索
[2] 叶二娘的儿子是谁？ （下一轮将检索，若选择继续）
[3] 虚竹的生父是谁？ 未检索
[4] 玄慈在武林中的公开身份是什么？ 未检索
让模型清楚知道"走到哪了、还剩什么"——这是让它做出正确判断的前提。
然后把已召回的文档也喂给它：
const docStr = state.documents.length === 0
? "(尚无检索结果)"
: state.documents
.slice(0, 6) // ← 只取前 6 条
.map((d, i) => `
[${i+1}] score=${Number(d.score).toFixed(4)} 第${d.chapter_num}章
${d.content.slice(0, 200)} // ← 每条只取前 200 字
`).join("\n\n");
两个截断：最多 6 条、每条 200 字。
这是上下文管理的经典手法——判断"够不够"不需要看全文，看摘要和分数就够了。全塞进去，反而浪费 token 还干扰判断。
prompt 部分写得很有意思，有一句特别关键：
const prompt = `你是多跳 RAG 规则器。检索查询已由前置步骤拆解为**有序子问题**，
若需要继续检索，下一轮将自动使用[下一条子问题] 做向量检索，你**不要**自拟新的检索句
...
"你不要自拟新的检索句" —— 这条约束很聪明。
因为模型看到检索结果后，可能冒出"我觉得应该查查 XX"的想法，自己编一个新的搜索词。但这个流程的设计是"严格按拆解好的顺序走"，让它自由发挥就破坏了规划的严谨性。
这叫"约束模型的自由度"——在需要严格流程的地方，明确告诉它"别乱来"。
然后是判断规则：
请判断下一步：
1. 已有足够依据回答用户原始问题 -> nextAction=generate
2. 仍缺关键事实、且仍存在未检索的子问题、且未超过轮数上限 -> nextAction=retrieve
硬性规则：
- 若剩余未检索子问题条数为0，必须 nextAction=generate
- 若已检索轮数已到达或超过最大检索轮数，必须 nextAction=generate。
注意"硬性规则"这四个字——prompt 里说了，但代码里还要再兜一遍：
let finalNext = nextAction;
if(state.retrievalCount >= state.maxRetrievals) finalNext = "generate";
if(remaining <= 0) finalNext = "generate";
console.log(`[决策] plannedNext=${finalNext}
(模型建议=${nextAction})(${reason})`)
return {
plannedNext: finalNext,
}
这是"不信任模型"的正确姿势。
模型可能会忽略 prompt 里的"硬性规则"（LLM 对负向约束的遵守率并不完美）。所以代码层面再做一次强制校验——无论模型说什么，超轮数或没剩余子问题，一律转 generate。
日志还刻意区分了两个值：
[决策] plannedNext=generate (模型建议=retrieve)(...)
↑ 最终生效的 ↑ 模型原本想要的
把"模型建议"和"最终决策"都打出来——如果两者不一致，就能知道"是模型判断错了，还是被安全阀拦下来了"。这是非常好的调试设计。
完整的图：一个带反馈回路的闭环
const graph = new StateGraph(GraphState)
.addNode("route_question", routeQuestionNode)
.addNode("direct_answer", directAnswerNode)
.addNode("decompose_question", decomposeQuestionNode)
.addNode("retrieve", retrieveNode)
.addNode("plan_next_step", planNextStepNode)
.addNode("generate", generateNode)
.addEdge(START, "route_question")
.addConditionalEdges("route_question",afterRoute, {
direct_answer: "direct_answer",
decompose_question: "decompose_question",
})
.addEdge("decompose_question", "retrieve")
.addEdge("retrieve", "plan_next_step")
.addConditionalEdges("plan_next_step",afterPlan, {
retrieve: "retrieve", // ← 回到 retrieve！
generate: "generate",
})
.addEdge("direct_answer", END)
.addEdge("generate", END)
.compile()
看流程图：
┌→ direct_answer → END
START → route_question
└→ decompose_question → retrieve → plan_next_step
│
┌───────────────┤
↓ ↓
retrieve ────→ generate → END
（循环回来）
retrieve → plan_next_step → retrieve 形成了一个环。 这就是 LangGraph 前面学的"循环"能力——条件边指回上游节点。
而跳出循环的条件有三个：
- 模型判断"够了"（
nextAction=generate） - 子问题查完了（
remaining <= 0） - 达到轮数上限（
retrievalCount >= maxRetrievals）
一个受控的循环：能重复，但不会失控。
拆解效果
代码里的日志会打印拆解结果：
console.log(`拆解${subQuestions.length}条子问题(${out.reason})`);
subQuestions.forEach((q, i) => {
console.log(`[${i+1}] ${q}`);
});
如果模型拆得对，你会看到类似这样的输出：
拆解4条子问题(需要多跳推理才能确定生父身份)
[1] 《天龙八部》中四大恶人排行第二的是谁？
[2] 叶二娘的儿子是谁？
[3] 虚竹的生父是谁？
[4] 玄慈在武林中的公开身份是什么？
从一句"绕晕人"的长问句，变成四句"每句都能独立检索"的短问句——这就是拆题术的价值。
测试问题：两个版本
async function main () {
// const question = 'js写一个add函数';
const question = `《天龙八部》中【四大恶人】排行第二的是谁？
此人之子在身世揭晓前，其生父在武林中的公开身份是什么？`;
注意被注释掉的那行——js写一个add函数。
这是上篇路由 demo 的测试问题，在这个多跳版本里被注释掉了。 为什么？因为这个问题会走 direct_answer 分支，压根到不了拆解节点——在这个 demo 里它测不出东西来。
留下这行注释的价值在于：它记录了两个 demo 之间的关联——同一个测试用例，在不同的架构版本里，会走出完全不同的路径。
三、两个补丁，治好了哪两个硬伤
回头对照上篇的五个硬伤表：
| # | 硬伤 | 这篇的补丁 | 状态 |
|---|---|---|---|
| 1 | 所有问题都检索 | 路由分流（simple/complex 二选一） | ✅ 已修 |
| 2 | 没有评估机制 | 决策节点部分涉及（判断"够了没"） | 🟡 部分 |
| 3 | 处理不了多跳问题 | 问题拆解（子问题 + 顺序检索 + 去重） | ✅ 已修 |
| 4 | 语义匹配不准 | 关键词检索 | ⬜ 待办 |
| 5 | 不会联网兜底 | 网络搜索 | ⬜ 待办 |
两个补丁，两个新节点结构，两次结构化输出的实战应用。
值得留意的是——这两个补丁的技术手段其实是同一个：让 LLM 做判断。
- 路由分诊：判断"简单还是复杂"
- 下一步决策：判断"继续还是停止"
而多跳拆解是"让 LLM 做规划"——判断是"选择题"，规划是"简答题"。 前面的结构化输出（z.enum）天然适合做选择题，后面的子问题拆解（z.array(z.string()).min(1).max(8)）用来做简答题。
这就是上篇说的"在这个骨架上插节点"——骨架上插的每个节点，本质都是一次"让模型做一次结构化判断"。
四、从"流水线"到"有回路"
最后看一下这两个 demo 的架构变化。上篇的朴素 RAG：
START → retrieve → generate → END
直线，走完就完。
这篇的两个版本：
路由版： START → route → (direct | retrieve→generate) → END
↑ 岔路口
多跳版： START → route → decompose → retrieve → plan ─┐
↑ │
└────────┘
（回路）
岔路口 + 回路。
这正是前面 LangGraph 那节课讲的核心——从"线性流水线"升级到"网状图"。 而这张网的每个分叉点、每个回路点，决策者都是 LLM 自己。
readme 的总结很到位：
"死板的检索生成流程，升级为可思考、可判断、可纠错的智能 RAG 架构。"
- 可思考 → 拆解问题（规划）
- 可判断 → 分诊、决定继续还是停止
- 可纠错 → 还没做完（下一篇的评估节点）
PS：这两篇看下来，最大的感受是——RAG 的升级不是在"检索算法"上做文章，而是把决策权交给模型。以前是"所有问题都走同一条路"，现在是"让模型看看这是什么问题、走到哪了、够不够了"。下一篇我们补上最关键的一块：让 RAG 知道自己"不知道"，并且学会出门求助。
