在基于检索增强的问答系统中，答案质量的上限往往不是由生成模型决定的，而是由检索器召回的文档决定的。近年来不少研究指出，主流问答基准的评测结果存在明显的检索依赖：当检索器表现下降时，即使是最强的生成模型也难以维持原有准确率。要真正提升问答系统的可靠性，就必须认真审视端到端参数化方案与检索增强方案之间的边界与融合方式。
一、检索依赖问题为什么会产生
经典的开放域问答采用两段式流水线：先用检索器（如BM25或双塔编码器）从大规模语料库中召回若干候选文档，再由阅读理解模型从文档中抽取或生成答案。这种架构的优点是知识可以随时更新，模型参数不需要重新训练。但它的短板同样突出：整个系统的错误会被逐级放大。如果召回的前K篇文档中没有包含答案的段落，后端模型无论多强都无法给出正确结果。
在许多公开基准上，研究者发现答案几乎总能被语料库中的某篇文档覆盖，这使得评测分数在很大程度上变成了对检索器召回率的间接度量。换句话说，我们在评测中看到的高分，可能并不是模型真正理解了问题，而是检索器恰好找到了那篇包含答案的维基百科页面。这种依赖带来的问题是：换一个语料库、换一种检索策略，排名可能完全颠倒，基准的泛化意义被削弱。
此外，检索依赖还带来工程上的脆弱性。线上系统一旦遇到长尾问题、实体别名歧义或查询表述与文档措辞不一致的情况，检索质量会显著波动，导致用户体验不稳定。这也是许多团队开始重新思考架构选择的直接原因。
二、端到端方案的思路与局限
端到端方案的核心理念是把知识压缩进模型参数中，直接从问题映射到答案，省去检索环节。大语言模型在海量语料上预训练后，确实掌握了相当可观的参数化知识，对于事实性问题的回答表现不错，且推理链路短、延迟低，不需要维护向量索引和语料更新流程。
一个最小的对比实现可以用下面的伪代码表达，两条链路的差异一目了然：
# 检索增强链路
docs = retriever.search(question, top_k=5)
context = "\n".join(docs)
answer = generator(f"基于以下资料回答：{context}\n问题：{question}")
# 端到端链路
answer = generator(f"问题：{question}")
但端到端方案有两个难以回避的局限。第一是知识时效性：参数中的知识停留在预训练数据的截止时间，无法回答新发生的事件。第二是幻觉问题：当参数化知识覆盖不足时，模型倾向于生成看似合理但实际错误的内容，而且没有任何外部证据可供校验。对于对准确性要求高的场景，这两点是硬伤。此外，让模型记住长尾知识的成本极高，训练数据的边际收益递减很快。
三、降低检索依赖的三种工程手段
第一种手段是提升检索本身的鲁棒性。常见做法包括查询改写、多路召回融合（BM25与向量检索并行、结果用RRF算法合并）、以及对抗性难例训练。多路融合的效果通常立竿见影，因为稀疏检索和稠密检索的失效模式恰好互补：
def rrf_merge(list_a, list_b, k=60):
scores = {}
for rank, doc in enumerate(list_a):
scores[doc] = scores.get(doc, 0) + 1.0 / (k + rank + 1)
for rank, doc in enumerate(list_b):
scores[doc] = scores.get(doc, 0) + 1.0 / (k + rank + 1)
return sorted(scores, key=scores.get, reverse=True)
第二种手段是无检索校验机制。当检索器对某个问题的置信度较低时，系统可以退回到参数化知识，同时触发自我校验：让模型先基于自身知识生成候选答案，再判断是否与召回证据冲突。这种设计承认了一个事实，参数化知识和外部知识不是替代关系，而是互补关系。判断哪些问题适合走哪条链路，本身可以训练一个轻量分类器来完成。
第三种手段是在评测层面去偏。构建评测集时，应当刻意加入一部分语料库中不存在答案的问题，考察模型是否有能力拒答而不是强行编造。同时可以分别报告有检索和无检索两种设定下的成绩，把检索器的贡献和生成模型的能力拆开衡量。只有这样，才能识别出真正稳健的问答系统，而不是被检索红利包装出来的高分系统。
四、如何选择适合自己的架构
对于知识更新频繁、需要可溯源的场景，例如客服知识库、法律文档问答，检索增强仍是首选，重点应放在检索质量优化和证据引用机制上。对于封闭域、知识相对稳定且追求低延迟的场景，端到端方案配合定期增量训练更为合适。多数实际系统最终会落在混合架构上：用参数化知识处理常识和高频问题，用检索处理长尾和时效性问题，再通过置信度路由和答案校验把两条链路缝合起来。
值得注意的是，混合架构的复杂度不低。路由策略设计不当会造成链路震荡，检索退回机制可能掩盖真正的知识缺口。建议在上线前做好分链路监控，分别统计检索命中率、拒答率和幻觉率，用数据驱动后续迭代，而不是一次性押注某条技术路线。