一家企业的内部知识库经过半年积累文档数量从最初的五十份增长到三千多份涵盖产品手册、操作规程、会议纪要、培训材料和历年项目文档。运营团队发现智能体的回答速度明显变慢——原来三五秒能返回的回答现在经常要等二三十秒。更让用户不满的是等了这么久得到的回答反而不如以前精准经常是长篇大论却抓不住重点。排查日志后发现一次关于年假怎么请的提问检索环节返回了一千七百条知识库片段全部拼接后塞进了模型的上下文窗口。模型在一大堆相关度参差不齐的文本中艰难生成回答既慢又散。这一千七百条片段并非来自单次检索。系统对原始查询做了查询扩展加上原始查询共四个查询每个查询分别执行向量检索、关键词检索和全文检索三种检索通道共十二路召回。单路Top-K设的是两百十二路的理论上限是两千四百条基础去重后仍剩一千七百余条全部送进了上下文。问题不在某一路的Top-K过大而在于查询数量乘以检索通道数量乘以单路Top-K三者叠加后候选总量失控合并环节又没有总量限制和统一排序。遇到这类问题常见做法是给知识库换更大参数的模型或者增加服务器算力。但这些方向都没有触及根因检索环节返回的片段数量远超回答所需大量低相关度内容占据了上下文空间。模型不是在回答问题而是在从一堆文本里找答案——这本应该是检索环节做的事。也有团队调小单路Top-K参数但多路召回合并后总量仍然可能失控而且一些需要综合多篇文档才能回答的问题片段不够又答不全。问题可以从四个方面拆解。一类是多路召回合并后无统一总量限制。检索系统通常不是单路检索——向量检索负责语义匹配关键词检索负责精确匹配全文检索负责覆盖召回。不少系统还会对原始问题做查询扩展生成多个子查询分别检索以提升召回率。每一路各自有Top-K限制但合并时只是简单拼接去重没有对合并后的总量设上限。查询数量乘以检索通道数量乘以单路Top-K三者叠加后候选总量很容易突破预期——四个查询乘以三种检索通道乘以单路Top-K两百理论上限两千四百条去重后仍可能剩一千多条。合并环节缺少总量限制和统一重排是大量低相关度片段涌入上下文的直接原因。另一类是相关性阈值未校准。向量检索按相似度分数排序返回结果但如果阈值是一个拍脑袋设的固定值——比如0.7——在不同Embedding模型、不同语料分布、不同查询类型下效果差异很大。有的Embedding模型输出的相似度分数整体偏高0.7的阈值可能连完全不相关的内容都挡不住有的模型分数分布偏保守0.7的阈值可能把相关内容也过滤掉了。阈值需要基于实际使用的Embedding模型、知识库语料特征和真实查询集做校准——用标注好的查询-文档对做测试观察不同阈值下的召回率和精确率曲线找到适合当前系统的平衡点。不存在一个通用的固定阈值适用于所有场景。还有一类是宽泛问题处理策略单一。用户提问的颗粒度差异很大——年假怎么请是具体问题人事制度是宽泛问题。不少系统对宽泛问题一律做意图收窄把问题映射到某个子主题再检索。但收窄不一定对——用户说人事制度时可能想了解整体概况收窄到某个子主题反而漏掉了用户想要的全局信息。正确的处理是先判断用户意图是否明确目标不明确时通过澄清问题确认用户到底想了解哪个方面用户明确要求综述性回答时不收窄而是按子主题分别检索后统一重排让模型看到覆盖各子主题的高质量片段自己做综合。收窄和分域综述是两种策略选择依据是用户意图不是问题宽窄本身。还有一类是去重合并丢失来源边界。检索返回的片段中存在信息重叠——同一文档的不同切片包含相似表述不同文档对同一政策有重复描述。去重是必要的但去重方式如果只看内容相似度把多个片段的内容合并成一条新片段就丢失了来源信息这条内容来自哪份文档的哪个章节、属于哪个版本、是否包含前置条件或例外条款。模型看到的是一条来历不明的文本无法判断其适用范围和权威性。正确的去重应该保留每个片段的文档ID、章节路径、版本号和来源边界——内容重叠的片段只保留信息量最大的一条作为主片段其余标记为重复并记录与主片段的引用关系但不把多个片段的内容拼成新的不可追溯的文本。针对知识库检索返回大量低相关度片段导致回答变慢且失焦的问题青山不语AI工作室在部分项目实践中将这套处理框架归入召回重排与语义去重策略通过问题意图判断、多路召回总量控制、阈值校准、来源可追溯的去重合并和高价值证据优先入场控制进入模型上下文的片段质量和数量。起始环节是问题意图判断与检索策略选择。系统在检索前对问题做意图判断目标明确的具体问题使用精准检索策略Top-K较小阈值较高目标不明确的问题通过澄清策略确认用户意图后再选择检索策略用户明确要求综述性回答的问题按子主题分别检索后统一重排不做意图收窄。意图判断的输出不只是Top-K的值还包括检索策略的选择和召回路径的数量——精准检索可以单路或少路召回综述性检索需要多子主题多路召回但合并后总量受控。第二环节是多路召回总量控制与阈值校准。多路召回——向量检索、关键词检索、全文检索、查询扩展子查询——各自有单路Top-K限制合并后还需设置统一总量上限。合并后先用重排模型做统一二次打分按精排分数从高到低取Top-NN远小于合并总量。相关性阈值不设固定值而是基于当前使用的Embedding模型、知识库语料和标注查询集做校准——用标注好的查询-文档对测试不同阈值下的召回率和精确率选择适合当前系统的阈值。阈值随Embedding模型升级或语料大幅变化时需要重新校准。第三环节是来源可追溯的去重合并与高价值证据优先入场。精排后的片段做语义去重内容高度重叠的片段只保留信息量最大的一条作为主片段其余标记为重复并记录引用关系。主片段保留完整的来源元数据——文档ID、章节路径、版本号、来源边界。存在总则和细则关系的片段不做内容合并而是按逻辑顺序排列各自保留来源标记。上下文入场策略采用高价值完整证据优先——优先放入来源完整、信息密度高、与问题匹配度高的片段再按精排分数递减依次放入直到token预算用尽。入场片段优先保持语义边界完整超预算时按句子、段落或原文结构做安全裁剪裁剪后标注截断位置和所属原文片段无法在不破坏语义的情况下裁剪的片段则跳过不强行截断放入。第四个环节是召回质量监控与参数迭代。系统记录每次检索的各路召回数量、合并后数量、精排后数量、入场上下文数量并采集检索侧评估指标区分文档级和片段级两个评估层级。文档级评估关注召回是否漏掉了相关文档——RecallK在文档级别衡量召回阶段是否找回了所有相关文档片段级评估关注精排后进入上下文的片段质量——PrecisionN在片段级别衡量精排后入场的片段中有多少真正相关nDCG在片段级别衡量排序质量即相关片段是否排在前面。两个层级不能混用文档级RecallK低说明召回阶段漏了相关文档需要调整召回路径或提高单路Top-K片段级PrecisionN低说明精排模型排序能力不足需要优化重排模型或特征片段级nDCG低但PrecisionN不低说明排序顺序有问题相关片段没排在前面。参数迭代基于这些指标做定向调整不是凭感觉调参。检索召回控制的核心矛盾是召回覆盖率和上下文质量之间的冲突。返回太少可能漏掉回答所需的关键信息返回太多低相关度内容淹没关键信息模型在噪音中生成低质量回答。问题意图判断让检索策略匹配用户需求多路召回总量控制让合并后结果不失控阈值校准让过滤标准适配实际系统来源可追溯的去重让上下文不冗余且可追溯高价值证据优先入场让进入模型的内容质量可控。在我看来这套机制是否需要取决于知识库规模和问题类型的复杂度知识库小、问题类型单一的场景固定Top-K加简单阈值就够了。但知识库文档多、问题横跨多个主题的场景没有召回控制和预算管理检索返回的内容会随知识库增长而失控——增长的不是有用信息而是噪音。问题不在于知识库有多大而在于检索回来的内容有多少是回答真正需要的。