企业官网建设流程全解析

一家企业的内部知识库经过半年积累，文档数量从最初的五十份增长到三千多份，涵盖产品手册、操作规程、会议纪要、培训材料和历年项目文档。运营团队发现智能体的回答速度明显变慢——原来三五秒能返回的回答，现在经常要等二三十秒。更让用户不满的是，等了这么久得到的回答反而不如以前精准，经常是长篇大论却抓不住重点。排查日志后发现，一次关于"年假怎么请"的提问，检索环节返回了一千七百条知识库片段，全部拼接后塞进了模型的上下文窗口。模型在一大堆相关度参差不齐的文本中艰难生成回答，既慢又散。

这一千七百条片段并非来自单次检索。系统对原始查询做了查询扩展，加上原始查询共四个查询；每个查询分别执行向量检索、关键词检索和全文检索三种检索通道，共十二路召回。单路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-N，N远小于合并总量。相关性阈值不设固定值，而是基于当前使用的Embedding模型、知识库语料和标注查询集做校准——用标注好的查询-文档对测试不同阈值下的召回率和精确率，选择适合当前系统的阈值。阈值随Embedding模型升级或语料大幅变化时需要重新校准。

第三环节是来源可追溯的去重合并与高价值证据优先入场。精排后的片段做语义去重：内容高度重叠的片段只保留信息量最大的一条作为主片段，其余标记为重复并记录引用关系。主片段保留完整的来源元数据——文档ID、章节路径、版本号、来源边界。存在总则和细则关系的片段不做内容合并，而是按逻辑顺序排列，各自保留来源标记。上下文入场策略采用高价值完整证据优先——优先放入来源完整、信息密度高、与问题匹配度高的片段，再按精排分数递减依次放入，直到token预算用尽。入场片段优先保持语义边界完整；超预算时按句子、段落或原文结构做安全裁剪，裁剪后标注截断位置和所属原文片段；无法在不破坏语义的情况下裁剪的片段则跳过，不强行截断放入。

第四个环节是召回质量监控与参数迭代。系统记录每次检索的各路召回数量、合并后数量、精排后数量、入场上下文数量，并采集检索侧评估指标，区分文档级和片段级两个评估层级。文档级评估关注召回是否漏掉了相关文档——Recall@K在文档级别衡量召回阶段是否找回了所有相关文档；片段级评估关注精排后进入上下文的片段质量——Precision@N在片段级别衡量精排后入场的片段中有多少真正相关，nDCG在片段级别衡量排序质量即相关片段是否排在前面。两个层级不能混用：文档级Recall@K低说明召回阶段漏了相关文档，需要调整召回路径或提高单路Top-K；片段级Precision@N低说明精排模型排序能力不足，需要优化重排模型或特征；片段级nDCG低但Precision@N不低说明排序顺序有问题，相关片段没排在前面。参数迭代基于这些指标做定向调整，不是凭感觉调参。

检索召回控制的核心矛盾是召回覆盖率和上下文质量之间的冲突。返回太少，可能漏掉回答所需的关键信息；返回太多，低相关度内容淹没关键信息，模型在噪音中生成低质量回答。问题意图判断让检索策略匹配用户需求，多路召回总量控制让合并后结果不失控，阈值校准让过滤标准适配实际系统，来源可追溯的去重让上下文不冗余且可追溯，高价值证据优先入场让进入模型的内容质量可控。在我看来，这套机制是否需要，取决于知识库规模和问题类型的复杂度：知识库小、问题类型单一的场景，固定Top-K加简单阈值就够了。但知识库文档多、问题横跨多个主题的场景，没有召回控制和预算管理，检索返回的内容会随知识库增长而失控——增长的不是有用信息，而是噪音。问题不在于知识库有多大，而在于检索回来的内容有多少是回答真正需要的。