RAG知识库乱答？用分诊台和拆题术重构检索链路

如果你搭过 RAG 知识库，大概率见过这种场面：用户问了一个很正经的问题，系统召回一大堆不相干的片段，最后大模型一本正经地拼出一个看似合理、实则跑偏的答案。我第一次做 RAG 时，也以为是向量检索精度不够，花了好几个晚上换 embedding 模型、调 top_k、加重排序，效果始终上不去。直到把整条链路拆开一条条看，才反应过来：真正的问题在更靠前的位置——链路里少了一个“判断”的环节。

这个项目的核心思路，就是给 RAG 加两个东西，一个叫分诊台（Triage），一个叫拆题术（Query Decomposition）。用大白话说：先判断该走哪条路，再规划怎么拆着走，别一上来就闷头检索。这也是 RAG 实战里最常被忽略的一环。本文适合两类人：一类是搭过 RAG 知识库但总被效果卡住的人，另一类是准备从简单 RAG 向 RAG 智能体方向过渡的开发者。我会把我自己实现时踩过的坑、用过的提示词和代码骨架都写出来，你照着改就能用。

1. 先搞清楚：RAG 的瓶颈在哪，为什么要加一道“分诊台”

1.1 让我印象深刻的 RAG 翻车现场

先讲一个我实际遇到的案例。当时给一个企业做客服问答，知识库有一万多份文档，涵盖产品说明、常见故障、物流售后。系统上线后第一个星期，用户问“退货流程需要多久？”，系统从某个产品说明里召回了一段关于“纯棉材质”的描述，然后一本正经地回答“退货流程具体时长取决于材质成分”。这个答案放在测试集里会被直接判死刑，但它确实发生了。

问题出在哪？一眼看过去是召回错了，本质上是整个链路没有判断力。传统 RAG 的流程很机械：用户 query 做向量化，去向量库里找 top_k 个相似片段，把片段拼进 prompt，再让大模型生成答案。这里每一步都“看似合理”，但注意它把所有问题都当成同一种问题处理。问“退货流程多久”和“这款路由器的 lan 口速率是多少”在链路里走的路一模一样，都是同一个 embedding 模型，同一个向量库，同一个 top_k 参数。

这就必然出现两个结果。第一，高频简单问题也被迫走一遍完整检索链路，延迟高、成本没省下来；第二，长 query 或复杂 query 的语义太密，很容易跟知识库里的多个片段都“沾边但不精准”，于是召回一堆噪音。噪音进入上下文之后，生成模型只能在里面挑顺眼的，答案自然开始飘。这就是我理解的 RAG 瓶颈：不是检索算法不够先进，而是链路缺少一个入口层的把关机制。

1.2 链路里缺的不是检索精度，是“判断”

我后来反思了很久，发现 RAG 这个缩写里其实藏着一个隐含假设——所有问题都该被检索增强。但现实世界的问题并非如此。有些问题跟知识库完全无关，比如“早上好”和“今天几号”；有些问题属于某个单一知识库，比如“你们家路由器支持 WiFi 6 吗”明显对应产品文档；有些问题需要跨两个知识库综合回答；还有些问题根本不需要检索现成文档，比如“帮我算一下 15 个订单的平均金额”或者“查一下当前天气”。

如果链路里没有分诊层，那么所有问题都会被一股脑塞进同一个管道。后果就是：该直接回答的走了检索，白白增加延迟；该检索一个库的跑到所有库里捞了一遍，捞回来一堆置信度差不多的片段；该跨库的又因为每个库都只取 top_k，把关键信息挤出了窗口。这些问题不是靠优化 embedding 能解决的，因为它们的根子在“路由策略”和“查询粒度”上。

这里我习惯用一个类比：医院分诊台。医院不会让所有病人都直接去做 CT，而是先由分诊护士问几句，判断去内科、外科还是直接回家休息。RAG 的分诊台做的是同一件事：它先看用户问题属于哪一类，决定后续路由。判断做对了，后面每一步才有意义；判断错了，再好的检索模型也只是把一个错误的方向执行得更充分而已。

1.3 分诊台分级：从“检不检”到“拆不拆”

在我实现的版本里，分诊台没有做成“一个问题对应一个动作”的粗暴分类，而是做成了多级判断，每一级都在解决上一级处理不了的情况。

第一级最基础，判断“要不要检索”。如果问题不需要外部知识，比如闲聊、常识、与业务无关的日常问题，就直接让大模型回答，不查任何知识库。第二级判断“去哪个知识库查”。前提是问题确实需要检索，而且指向明确，比如“产品文档”或“故障手册”。第三级处理的是跨库问题，比如“产品保修卡丢了怎么补办”，既涉及产品政策，又涉及售后流程，这时需要路由到多个知识库分别取片段。第四级是今天说的拆题，判断“这个问题是否需要拆开处理”。典型代表是多跳问题，比如“A 公司的创始人的毕业院校是哪所”，你得先查出创始人是谁，再去查这个人的教育背景。

分级不需要一步到位。你完全可以先只做“要不要检索”和“去哪个库检索”这两层，等系统稳定了再加“拆题”。把分级做成分层的另一个好处是便于排查——问题出在哪一级，直接看哪一级的日志就行。我项目里最后用的是一份 JSON 结构：action 表示动作，kb 数组表示要去的知识库，need_decompose 表示是否拆题，reason 字段记录判断理由，方便回溯。

2. 分诊台与拆题术的整体设计：先判断，再规划

2.1 分诊层到底在分什么

分诊层看起来是给问题分个类，但真正设计时你会发现，它其实是在替整个 RAG 系统做“资源调度”。传统链路里，一次问答的成本基本固定：向量检索一次，生成一次。加入分诊层之后，成本模型变成了动态的：简单问题走轻量路径，复杂问题走重型路径。从效率角度看，这是一笔很划算的账。

实现分诊层有三种主流方案。第一种是纯规则，用关键词和正则做意图匹配，优点是快、稳、可解释，缺点是覆盖不了开放域问题，企业知识库里的业务问法千奇百怪，规则很容易漏。第二种是小模型分类器，比如用 BERT、fasttext 微调一个文本分类模型，效果不错，但冷启动需要标注数据，业务一变模型就得重训。第三种是让大模型充当 Router，直接输入用户问题和知识库描述，要求输出一个结构化 JSON。我最终选的是第三种，原因很实际：上线快，零样本就能跑，而且在新领域里可以先用大模型路由收集一批数据，以后真要换小模型，这些数据正好当成训练集。

大模型当 Router 的关键不是提示词多复杂，而是信息要给够。我踩过一次坑：最初我只把用户问题发给大模型，让它判断“是否检索”，结果它经常瞎猜，因为根本不知道知识库里有什么。后来我在提示词里加了一个知识库清单，每个库配两到三句话描述，例如“product_docs：产品功能说明、版本更新、使用教程；troubleshooting：故障排查手册、报错原因、解决办法”。它才知道自己手里有哪些“科室”，判断准确率立刻上了一个台阶。

2.2 拆题术：把多跳问题拆成单跳检索

拆题术要解决的是 RAG 在复杂问题面前的失效问题。你可能试过拿一个很长的问题直接去检索，结果召回片段东一段西一段，谁都没答到点子上。原因不复杂：embedding 相似度检索擅长的是“一段文本和另一段文本的语义接近”，但多跳问题的信息太密了，query 里同时出现 A 公司、创始人、毕业院校三个实体，向量空间里它跟任何一段只包含部分内容的文档都只有部分相似，检索分数被摊薄，真正的关键片段反而排不到前面。

拆题的本质，就是把一个需要多步推理的问题拆成若干个可以独立检索的单跳问题。比如上面的问题可以拆成三个子问题：A 公司是谁创立的；这个创始人是谁；他的毕业院校是哪所。前两个是中间步骤，最后一个才是终点。每个子问题都是单跳检索，候选片段只需要回答“一个事实点”，命中率自然高得多。

这里有个设计要点：子问题之间可能有依赖关系。有些可以并行拆，比如“A 公司的主要业务和总部城市”，两个子问题互不依赖，可以同时检索；有些必须顺序拆，比如必须先知道创始人的名字才能查他的毕业院校。我在实现时没有一上来就做复杂的 DAG 调度，而是做了一个简单约定：让拆题提示词尽量拆成“可并行检索”的原子子问题，如果确实存在依赖，就在子问题里显式带上中间信息，比如拆题结果直接写成“A 公司的创始人是张三，张三的毕业院校在哪”，这样虽然第二个子问题依赖第一个的结果，但拆题时已经替它算好了前置变量。

2.3 一套可落地的 Pipeline 编排

分诊和拆题不是独立组件，而是要编排进原有的 RAG 流程里。我最终跑的流程是这样的：

用户问题进来之后，先过 LLM Router，输出结构化结果。如果 action 是 direct_answer，直接把用户问题和“你是一个客服助手”之类的系统提示交给生成模型，不再碰向量库。如果 action 是 retrieve，就根据 kb 数组确定去哪些库检索。如果 need_decompose 为 true，先走拆题，把子问题列表拿去并行检索，每个子问题各自取少量片段，再生成一个子答案。最后把所有子答案（或者普通检索的片段）交给最终生成环节，输出答案。

这套编排我们可以用一个简表来看：

我这里没有把 tool_call 展开太多，因为项目重心在于分诊和拆题，但分诊层顺手把它预留了。经验是：分诊层把“需要工具”的动作先暴露出来，后续接入 Agent 工具调用会平滑很多。这也符合你从 RAG 框架往 RAG 智能体过渡的路径——先有判断，再有规划，最后才有工具。

3. 逐步实现：让 RAG 既会分诊，又会拆题

3.1 分诊提示词的写法与结构化输出

我先把分诊提示词写出来，你直接复制就能改。这里的关键是：输出必须是结构化 JSON，而且要有 reason 字段，否则出问题你连它为什么这么判断都不知道。

你是知识问答系统的分诊员。系统可用的知识库如下： - product_docs：产品功能说明、版本更新、使用教程，覆盖型号参数、功能操作。 - troubleshooting：故障排查手册、报错原因、解决办法，覆盖异常现象和维修指引。 - order_after_sales：订单状态、退换货、物流查询，覆盖购买后的所有流程。 请判断用户问题应该走哪条处理路径，并输出JSON： {"action": "direct_answer" | "retrieve" | "tool_call", "kb": ["product_docs"], "need_decompose": true/false, "reason": "判断理由"} 约束： 1. direct_answer 表示无需检索知识库，直接回答即可。仅用于与业务无关的闲聊、问候、常识问题。 2. retrieve 表示需要检索知识库，kb 数组给出要检索的库名，可以多个。 3. tool_call 表示需要调用外部工具，比如实时信息、计算器，不进入知识库检索。 4. need_decompose 为 true 时，表示该问题需要拆分成多个子问题才能回答，例如多跳问题、跨实体关联问题。

配合这段提示词，我建议 temperature 设为 0，让输出尽量稳定。解析时别直接 json.loads，因为本地部署的模型经常在 JSON 前后夹带解释性文字。我的做法是用正则把 response 里第一个“{”到最后一个“}”之间的内容截出来，再交给 json.loads。解析失败时不要静默兜底，要打一条 warn 日志，方便后面发现问题。

下面是一段解析代码，很短，但我在生产里实际用了很久：

import json import re def parse_triage_result(text: str) -> dict: match = re.search(r"\{.*\}", text, re.DOTALL) if not match: return {"action": "retrieve", "kb": [], "need_decompose": False, "reason": "parse_failed"} try: data = json.loads(match.group(0)) return data except json.JSONDecodeError: return {"action": "retrieve", "kb": [], "need_decompose": False, "reason": "parse_failed"}

解析失败时我故意让它默认走 retrieve 而不是 direct_answer，这是我从教训里学到的：漏检比多检的危害大得多。宁愿多检索一次浪费一点资源，也不要因为解析失败把一个需要知识库的问题直接跳过检索。

3.2 拆题提示词与子问题检索细节

拆题提示词也要结构化，但约束更细。我会在提示词里要求模型在指定的业务领域里拆解，并把子问题数量限制在四五个以内。我常用的拆题提示词长这样：

你是问题拆解助手。请把用户问题拆分成可以独立检索的子问题，每个子问题必须简短、单跳、可单独检索。 要求： 1. 子问题数量不超过4个，能少则少。 2. 每个子问题只能询问一个事实点，禁止出现“既要又要”的复合问法。 3. 子问题不要重复，含义接近的只保留一个。 4. 输出JSON：{"sub_questions": ["子问题1", "子问题2"]}

拆题结果的质量直接决定检索效果。我测下来，一个需要控制的地方是子问题的“粒度”。如果拆得太粗，比如“介绍一下这家公司”，它还是包含公司背景、业务、地址一堆信息，检索时精度依然上不去；如果拆得太细，比如把“创始人是谁”再拆成“这个创始人叫什么”和“这个创始人是做什么的”，就纯属浪费检索名额。我的经验是靠提示词约束加强力去重，而不是靠模型自觉。

子问题检索的代码不难，但有一个参数要特别注意：每个子问题的 top_k 不要设太大。整段 query 检索可能需要 top_k=10 才能覆盖信息点，但子问题已经是原子问题，top_k 设 3 到 5 就够了。因为拆题之后目标更聚焦，少量精准片段比一堆相关片段更有用。多余的片段塞进上下文，只会增加噪声。

如果有多个子问题，强烈建议并行检索。这里有个隐藏坑：如果你用的是同一个向量库客户端，要确认它是否线程安全。我之前图省事直接用线程池同时查同一个 chroma 客户端，结果出现过连接冲突。后来改成每个线程单独初始化一个只读客户端，问题就消失了。并行之后拆题链路的总延迟基本等于最慢那个子问题的检索耗时，体感好了很多。

3.3 多知识库路由与兜底策略

多知识库路由是分诊层里最容易被低估的环节。很多人觉得只要把数据库描述写清楚，大模型自然能选对。实际上在业务库里，不同知识库的主题常常重叠，比如“product_docs”和“troubleshooting”都可能会提到“开机失败”，这时候靠描述选库就容易翻车。

我的方案是双保险：大模型分诊为主，向量路由做校验。也就是在分诊输出的 kb 数组之外，再用 query 的 embedding 分别跟每个知识库的代表性标题或摘要向量算相似度，看哪两个库最接近。如果大模型选了库 A，但向量路由强烈指向库 B，我会按“同时检索两个库”处理，而不是让它们二选一。多召回一两个片段，后面反正有重排序兜底。

兜底策略里另一个关键是路由到多库时的 top_k 分配。假设上下文窗口允许 8 个片段，路由到两个库时我不是每个库取 8 个，而是每个库取 4 个，然后合并在一起过一个 reranker，保留与问题最相关的 5 到 6 个。这个做法的好处是避免单个库霸占上下文，让跨库信息都有机会参与生成。

3.4 完整串接：dispatch_and_plan 骨架代码

把上面这些串起来，你最终得到的核心函数大概长这样。我把它压成一个简单的骨架，去掉了具体向量库细节，你看了就能理解执行顺序：

import json from concurrent.futures import ThreadPoolExecutor def load_triage_prompt(): # 包含知识库描述和分诊JSON要求，这里省略实际文本 pass def load_decompose_prompt(): # 包含子问题拆解的JSON要求，这里省略实际文本 pass def call_llm(prompt: str, temperature: float = 0.0) -> str: # 调用本地模型或API，返回原始文本 pass def triage(query: str) -> dict: prompt = load_triage_prompt() + f"\n用户问题：{query}\n请输出JSON：" text = call_llm(prompt, temperature=0.0) result = parse_triage_result(text) # 兜底：解析失败时默认检索 if result["action"] == "direct_answer": return result return result def decompose(query: str) -> list[str]: prompt = load_decompose_prompt() + f"\n用户问题：{query}\n请输出JSON：" text = call_llm(prompt, temperature=0.0) match = re.search(r"\{.*\}", text, re.DOTALL) if not match: return [query] data = json.loads(match.group(0)) return data.get("sub_questions", [query])[:4] def search_single(sub_query: str, kb_names: list[str], top_k: int = 3): # 在指定知识库中检索，返回片段列表 pass def parallel_search(sub_questions: list[str], kb_names: list[str]): with ThreadPoolExecutor(max_workers=len(sub_questions)) as executor: futures = [ executor.submit(search_single, q, kb_names, 3) for q in sub_questions ] return [f.result() for f in futures] def generate_answer(context, query: str) -> str: # 将上下文与query交给最终生成模型 pass def dispatch_and_plan(query: str) -> str: triage_result = triage(query) if triage_result["action"] == "direct_answer": return generate_answer([], query) kb_names = triage_result.get("kb", []) if not kb_names: kb_names = ["default"] if triage_result.get("need_decompose"): sub_questions = decompose(query) fragments = parallel_search(sub_questions, kb_names) # 先为每个子问题生成简短子答案，再汇总 sub_answers = [ generate_answer(one_group, sub_questions[i]) for i, one_group in enumerate(fragments) ] return generate_answer(sub_answers, query) fragments = search_single(query, kb_names, top_k=8) return generate_answer(fragments, query)

这里面有一个值得注意的细节：拆题分支里我没有直接把所有子问题的检索片段合并成一个 context 丢给最终模型，而是先为每个子问题生成一个“子答案”，再把子答案列表交给最终模型。直接拼片段的问题在于，上下文太长之后，模型容易丢失关键证据，而且不同片段可能互相矛盾。子答案相当于做了一次中间摘要，把每个子问题的结论提取出来，最终生成阶段只需要综合这些结论，负担小很多。

有人会问，拆题之后先生成子答案，会不会丢失信息？我的经验是，丢失的通常是噪音，而不是关键信息。关键证据一旦被子问题定向检索到，几乎都会出现在子答案里。相比一次性拼接原始片段，这种“检索-子答-汇总”的流程更可控，也更容易在每个阶段加日志查问题。

4. 问题排查与效果评估实录

4.1 常见问题速查表

项目跑起来之后，至少有半年我都在跟各种奇怪的故障搏斗。很多问题表面上看是“模型不够聪明”，实际上都是链路设计和解析兜底的问题。我整理了一个速查表，你可以直接当排查手册用：

这些问题的共性都是“链路设计不清晰”而不是“模型能力不足”。分诊和拆题两个环节给你加上了判断，但判断本身也需要调试。我的习惯是给每条调用都打 structured log，把分诊 result、拆题子问题列表、每路子问题检索的片段 ID 都记录下来。出了 case 再回看日志，定位到具体环节，解决问题就只是改提示词或调参数的事。

4.2 三个印象深刻的踩坑教训

第一个教训是分诊误判“直接回答”导致漏检。上线初期，我把答疑库里的高频问题都当成“常识问题”处理，让分诊层直接回答，结果发现模型经常把业务规则答错。后来我改了一条策略：只有分诊结果里 reason 明确显示“与知识库无关”时，才允许走 direct_answer；一旦模型对是否检索犹豫不决，就默认转 retrieve。别怕多检索，检索一次的成本远低于答错一次。

第二个教训是拆题后的子答案互相矛盾。场景是这样的：用户问“两个型号的保修期分别是多久”，子问题分别检索了两个型号的说明文档，但文档版本不同，一份说过保一年，一份说过保两年。最终汇总时模型选择了“各打五十大板”的输出，说“保修期可能是一年或两年”。这个答案没有错，但没有价值。改进办法是让最终生成阶段必须引用子答案的原始片段编号，同时要求它“如果子答案之间存在冲突，需要明确指出冲突并给出倾向性结论”。实测下来，明确要求引用原文之后，模型糊弄的概率降低了不少。

第三个教训是路由到多个库之后片段总量超窗。一开始我在多库路由时每个库都取 top_k=8，三个库就是 24 个片段，很快就把上下文撑爆了，生成质量反而下降。后来我把多库场景下的每个库 top_k 改成 3 到 4，然后统一过一个 rerank，只保留 6 个以内片段，效果立刻恢复。多库场景跟单库完全不同，它讲究的是“平衡”，而不是“越多越好”。

4.3 评估指标与本地工具选型建议

评估分诊和拆题，不能只看端到端最终答案对不对，要分阶段看。分诊阶段的评估我通常准备一份带标注的 query 集，每个 query 标注了“该走 direct_answer / 单库 / 多库 / 拆题”，然后看 action 命中率。拆题阶段的评估我主要看两点：子问题是否覆盖原始问题的信息需求，以及子问题是否都能独立检索。这两个指标不需要太复杂，抽几十条评估样本人工看一遍就知道问题在哪。端到端评估则是老办法：检索命中率（黄金答案是否出现在召回片段里）加最终答案准确率，有条件就用 LLM-as-judge，没条件就人工抽检。

工具选型上，如果你的目标场景是本地部署，我建议优先用 Ollama 跑一个参数量至少 70 亿的模型做分诊和拆题，再配合自定义提示词和解析逻辑。别一上来就引入重框架，LangChain 和 LlamaIndex 固然提供了 Router 和 SubQuestionQueryEngine 之类的组件，但核心还是提示词和结构化输出。我见过太多人把框架搭起来之后，真正跑起来还是靠一堆 prompt protocol 和回调钩子，累得要死。先用最简单的 Python 函数把链路跑通，等业务上确实需要扩展再去接框架。Java 侧的话可以关注 LangChain4j 的 Easy RAG 思路，不过原理大同小异。

另外提一句，做拆题之前先把知识库切好。这个听着像废话，但我见过太多人花大力气优化拆题和分诊，结果原始文档切得乱七八糟，标题被切断、表格被拆碎，拆题拆得再好也检索不到正确答案。文本拆解是地基，本地 RAG 文本拆解工具不一定要多高级，先把段落和标题结构吃透，再谈 AI 拆题。

分享了这么多，我个人的核心体会是：给 RAG 加分诊台和拆题术之后，整个系统真正提升的不只是准确率，更是确定性。以前一次问答全链路匀速运转，什么问题都一个待遇；现在系统知道什么时候该快，什么时候该慢，什么时候该调工具，链路变得清清楚楚。最后再分享一个小技巧：做这套东西不要一上来就接复杂的 Agent 调度，先把分诊和拆题在两个固定业务问题上跑通，把结构化输出和兜底策略写稳，再慢慢加工具调用。判断和规划这条路走稳了，后面接什么能力都顺。