字数 2951，阅读大约需 15 分钟

大家好，许久未见，心中充满了思念。在这个不断变化的牛马世界中，每一天都有新的故事上演，繁忙而又充满激情。感谢大家的理解和支持。

相信很多做知识库问答的同学都遇到过这样的场景：用户反馈说"你们的系统搜索结果不全，明明库里还有相关资料"。这个问题让人很头疼，因为你根本不知道到底遗漏了什么，遗漏了多少。

今天笔者就和大家深入聊聊检索完整性这个技术难题。

建议读者对本文进行安静+详细的阅读和思考。

码字不易，觉得有价值的话记得点赞、关注。

场景定义与问题本质

我们在解决什么问题？

笔者首先明确这次讨论的技术场景：基于封闭域知识库的问答系统。

具体指：你有一个包含N个文档的知识库（N可能是100，也可能是10万），需要针对这个特定知识库进行问答检索。与开放域检索不同，这里有明确的信息边界。

检索完整性的技术定义

在知识库问答场景中，检索完整性指：通过单次或多次检索操作，能否覆盖知识库中所有与query相关的信息。

核心技术挑战：在没有标准答案的情况下，如何评估检索的完整程度？如何设计停止策略？

举例：query="水果种类介绍"，假设知识库中实际存在10种水果的相关文档，但检索系统只返回了4种。在不知道总数的前提下，系统如何判断是否需要继续检索？

这是一个典型的信息检索中的recall优化问题。

单次检索为什么总是"不够用"？

技术层面的根本限制

在深入策略设计之前，我们需要理解单次检索的技术天花板在哪里：

词汇匹配的天然局限：
1、关键词检索完全依赖字面匹配，用户说"水果"但文档写的是"鲜果"就匹配不上
2、即使做了同义词扩展，coverage依然很有限，特别是专业术语丰富的领域

向量检索的经典权衡难题：
1、相似度阈值设高了 → precision不错但recall很低，漏掉大量相关信息
2、相似度阈值设低了 → 一堆噪音进来，用户体验很差
3、这个平衡点很难把握，而且不同领域差异很大

混合检索的改进有限性：
1、BM25 + Vector的融合确实能改善效果，但面对复杂query时recall提升依然有限
2、参数调优非常复杂，不同知识库需要重新调试
3、融合权重的设置更像是"玄学"，比如：6:4, 7:3。而且不同的问题不同的知识库，他们的侧重面是不一样的，其参数本身是一个动态的过程。

为什么要选择多次检索？

既然单次检索有天花板，那解决思路就很清晰了：基于反馈的迭代优化。

核心思想是让每轮检索都基于前序结果进行策略调整，逐步逼近完整性目标。就像你平时搜资料一样，先搜个大概的，看看结果，然后调整关键词再搜，反复几轮直到满意。

这种 approach 在学术界叫 iterative retrieval，在工程界更多叫multi-round search。本质都是通过多次交互来突破单次检索的recall瓶颈。

两种主流的多次检索策略

基于迭代检索的框架，我们可以设计多种具体策略。笔者重点介绍两种相对比较主流的：

1. 渐进式检索策略

核心技术原理

这种策略基于 feedback loop 的思想：每轮检索后，让模型分析已有结果，识别可能遗漏的角度，然后生成下一轮的检索策略。

具体流程是这样的：
1、第一轮用原始问题检索，拿到基础结果
2、让大模型分析这些结果："当前覆盖了哪些方面？还可能缺什么？"
3、基于分析生成新的检索关键词进行第二轮
4、重复这个过程直到收敛

为什么这种方法有效？

想想你平时是怎么深度研究一个话题的：
1、先看几篇基础资料，了解大概
2、从中发现一些新的概念和线索
3、针对这些新发现继续深挖
4、逐渐构建起完整的知识图谱

渐进式检索就是把这个人类的学习过程自动化了。

与 Agent 架构的深度关联

如果有读者接触过 Agent 开发，就会发现这个策略和 ReAct pattern 几乎一致。Agent系统中 reflection 机制之所以有效，本质上就是在做渐进式的信息获取和分析。

所以说，检索完整性的技术思路其实为后来的Agent架构提供了重要启发。

技术实现的关键细节

排除机制的重要性：为了避免每轮都返回相同的结果，需要在检索层面做排除处理。可以直接排除已检索的文档ID，也可以对已发现的内容进行降权处理。这需要搜索引擎底层的支持。

对抗"即时满足"问题：大模型容易出现satisfaction bias，觉得当前结果已经足够好了。解决方案是在prompt中加入对抗性描述，强制AI去寻找遗漏角度，但是效果却受到模型本身的能力限制，笔者建议用工程化+模型的路子来解决此类问题。

上下文管理挑战：随着轮次增加，需要传递给模型的历史信息越来越多，很快会超出context length限制。这需要专门的上下文策略，笔者后续会专门写一篇文章进行介绍。

2. 多维度并行检索

技术原理与优势

这种策略采用divide-and-conquer的思路（简单的说就是分治）：将复杂query分解为多个子维度，并行执行检索后进行结果融合。

比如"水果种类"这个查询，可以同时从多个角度检索：
1、分类维度：热带水果、温带水果、浆果类、柑橘类
2、功能维度：高维C水果、减肥水果、美容水果
3、时令维度：春季水果、夏季水果、秋季水果
4、产地维度：国产水果、进口水果、有机水果

结果融合的技术挑战

多路并行检索的核心难点：
1、相关性排序：不同维度的结果如何统一排序？
2、多样性平衡：既要保证相关性，又要保证结果的多样性
3、多维的划分问题：这是最难处理的地方，完全依赖于模型本身的参数知识进行多维的划分，但是在知识库的场景下，文档的垂直性、多样性是完全不同的。于是就非常容易出现线下和线上的测试结论存在较大gap的情况。

性能对比与适用场景

计算效率：多维度并行的时间复杂度是固定的，而渐进式检索的时间会随轮次线性增长。在对响应时间有严格要求的场景下，多维度并行更有优势。

效果深度：渐进式检索能基于实际结果调整策略，通常能发现更深层的相关信息。多维度并行更依赖预设的维度划分，在面对复杂多样的知识库，会有盲区。

完整性判断：最关键的技术难题

核心挑战：什么时候停下来？

多次检索后面临的关键问题是：如何设计收敛检测算法？

这个问题在传统信息检索研究中很少被系统性讨论，但在实际工程中却至关重要。检索轮次太少可能遗漏重要信息，太多则浪费计算资源和用户时间。

笔者推荐几种方案：

方案1：新文档发现趋势分析

技术思路

这是最直观的判断方法：追踪每轮检索中新文档的发现比例。如果连续几轮的新发现率都很低，说明"矿藏"快挖完了。

数学建模

设第i轮检索的新文档发现率为：r_i = 新发现文档数 / 本轮检索总文档数

收敛条件为：连续w轮的发现率都小于阈值θ

这种方法的局限性

单纯看文档数量有个问题：新发现的文档不一定有价值。可能都是重复内容或者低质量信息。所以需要结合其他维度来综合判断。

方案2：语义重叠度检测

技术原理

如果新一轮检索的结果与历史结果在语义层面高度重叠，说明检索已经趋于饱和。

关键技术点：这里不能简单做文本匹配，因为同一信息可能有完全不同的表达方式。需要用向量来计算语义相似度。

实现思路

使用向量模型将每轮的检索结果转换为向量表示，然后计算新结果与历史结果的cosine相似度。如果大部分新结果都能在历史结果中找到高相似度匹配（比如>0.85），就认为重叠度过高。

需要注意的细节

语义相似不等于信息重复。比如"苹果营养丰富"和"苹果含有多种维生素"语义相似，但后者提供了更具体的信息。所以在计算重叠度时，还要考虑信息的具体性和详细程度。

方案3：基于大模型的信息价值评估

为什么需要这种方法？

前两种方法都是基于统计特征，缺乏对内容质量的理解。而大模型可以分析每轮检索是否真正发现了有价值的新信息。

评估框架设计

设计专门的prompt让大模型评估新信息的价值：
1、发现了多少个新的信息点？
2、这些信息的重要程度如何？（1-10分）
3、信息类型是核心、补充还是边缘？
4、是否建议继续检索？

用户体验的考虑

有时候"完美"的完整性并不等于更好的用户体验。用户可能更希望快速得到核心信息，而不是等待一个"完美"但缓慢的结果。

这需要产品层面的权衡决策，技术只是提供支撑。

写在最后

检索完整性仍然是一个开放的技术问题，需要在实际使用中持续探索和迭代。每个领域、每个业务场景都可能需要定制化的解决方案。

但无论技术如何演进，基于反馈的迭代优化思维和多维度综合评估方法这些核心理念应该是相对稳定的。掌握了这些方法论，就能在具体项目中灵活应用和创新。

希望这篇技术分析能为正在从事相关工作的读者提供有价值的参考。如果你有其他的经验或技术洞察，也欢迎交流讨论！

技术分享不易，如果这篇文章对你有帮助，请点赞支持。有问题随时交流