检索准了，但答案还是错了

这是一篇检索不到正确答案的深夜排查，还是一次架构设计的提前避坑？增强层（Augmentation Layer） ，这个RAG系统里最容易被忽视的环节，往往决定了你调了一周检索，效果却依然不尽人意的真相。

返回了5个高相关度的文本块（chunk），相关性分数都在0.85以上，刚好命中用户需要的政策文档。答案就在第三块里。

但生成的结果遗漏了关键细节。不是幻觉。更像是模型“瞄了一眼”而非认真读完。

你排查了检索器，微调了嵌入模型（embedding model），调整了分块（chunk）大小。但检索从来就不是问题所在。

真正的问题在于那些文本块是如何组装成提示词（prompt）的：它们按什么顺序出现？周围提供了多少上下文？模型拿到手之后，到底能不能用得上？

这就是增强层——检索器和生成器之间，那个没人警告过你的关键环节。向量数据库交出了相关文本块，大语言模型（LLM）产生了回答，但中间这段路，决定了你的检索结果到底是金子还是废铁。

位置偏见：你以为LLM在逐字阅读，其实它只记得开头和结尾

LLM不会均匀地阅读上下文。

2023年，斯坦福大学和Meta的研究人员发现了一个有趣的现象：把关键信息埋在不同位置，模型的准确率呈现出U形曲线。模型对开头（首因效应）和结尾（近因效应）关注度最高，中间部分容易被忽略。

⚠️ 注意：现在的大模型（如GPT-4o、Claude 3.5 Sonnet）虽然比GPT-3.5时代好很多，但这个问题并没有彻底消失。 2025年的最新研究也确认，在包含干扰项的RAG场景中，位置偏见依然存在。其根源在于Transformer注意力机制中的Softmax归一化特性和“注意力汇聚”现象，早期token始终会获得不成比例的权重。

这其实和人的注意力很相似——你看一份长文档，是不是也对开头和结尾印象最深？

所以在构建prompt时，把你的“最佳文本块”放在最前面。 无论你用哪款模型，这个策略零成本且有效。

重排序算法

最优策略是这样的：

1. 最高相关度块放首位（利用首因效应）
2. 次高相关度块移到最后（利用近因效应）
3. 中间填充支撑性内容

检索器和生成器之间藏着一个隐形管道

绝大多数RAG教程展示的是这样一张图：

但Retriever和LLM之间的箭头里，藏着一整套你没有意识到的处理流程。

现实中的RAG系统，检索器返回的往往是20~50个候选文本块，这些原始结果存在各种问题：有的信息重叠，有的相互矛盾，有的只是关键词匹配上了但根本答非所问。

真正的处理管道需要做这些事：

• 相关性阈值过滤（丢掉低于分数线的候选块）
• 去重（剔除高度重叠的内容）
• 重排序（Reranking） —— 用专门的模型重新评估相关性，提升精度
• 矛盾处理（当两个文本块说法不一致时怎么办？）
• 上下文扩展（为有潜力的文本块补全周边信息）

跳过任何一个步骤，你都在浪费自己的数据。

重排序（Reranking）：性价比最高的优化手段

向量相似度检索很快，但也很“浅”——它比较的是压缩后的语义表示，牺牲了大量细节。而交叉编码器（cross-encoder）重排序模型会同时处理查询和每个候选文档，捕捉到嵌入向量（embedding）无法体现的深层关系。

最佳实践是 两阶段检索：

第一步：用向量检索快速召回Top-50候选块
第二步：用重排序模型精准筛选出Top-5

Pinecone的基准测试表明，这种两阶段方法比纯向量搜索提升了14%~30%的检索质量。

主流重排序模型怎么选？

浪潮信息的“源Yuan-EB 2.0”已在HuggingFace文本检索与排序榜单取得SOTA成绩。华为云也推出了盘古EmbeddingRank模型。

⚠️ 自托管注意事项：BGE-reranker-v2-m3虽然开源免费，但平均延迟约2383ms，约为Cohere Rerank 4 Fast的5倍。如果对延迟敏感，需要权衡。

去重：解决“明明只有3个信息点，却喂了5个重复块”的浪费

滑动窗口分块策略天然会产生重叠。检索5个块，其中3个可能包含同一个段落——这不仅是浪费token，重复内容还会让模型过度关注这些信息。

最大边界相关算法（Maximal Marginal Relevance，MMR） 是解决这个问题的标准方案。它的核心思想很直观：每新增一个块，既要保证它和查询相关，又要保证它和已选中的块“不一样”。λ参数控制在0.5~0.7之间效果最好（λ越大越偏向多样性）。

矛盾处理：当多个检索结果互相矛盾时，模型该信谁？

时间维度的矛盾

带时间戳，按新鲜度过滤。LlamaIndex提供了EmbeddingRecencyPostprocessor，自动实现这个逻辑。

权威维度的矛盾

官方文档 > 用户生成内容（UGC），一手来源 > 二手总结。通过元数据（metadata）标记来源类型，在pipeline中实现优先级规则。

真正的分歧

当存在合法的观点分歧时，诚实的做法是呈现双方观点并注明来源，而不是强行捏造一个“共识”来误导用户。

Token预算：不是越多越好

128K的上下文窗口听起来很大，但你需要考虑这些：

• 系统提示词（system prompt）：约1500 token
• 用户查询（query）：约500 token
• 预留输出空间（response）：约4000 token

算下来，留给检索上下文的预算大约是122K token。

⚠️ 注意：更多的上下文并不总是更好。 随着长上下文模型的发展，“越多越好”这个直觉需要被修正。增加冗余信息会引入噪声，反而降低答案质量。多数查询的最佳区间是 4~6个高质量文本块，每增加一个块，边际收益会递减。

当上下文塞不下时，压缩优于截断

• 微软LongLLMLingua：实现4倍压缩的同时，在问答基准测试中精度提升21%
• Meta REFRAG框架：实现30.85倍TTFT加速，将上下文处理长度扩展16倍

💡 压缩的核心思想：不是简单地删掉“中间部分”，而是根据每个token的重要性打分，保留信号、丢弃噪声。

Prompt结构：分离System和User两层

很多人把prompt写成一锅粥，这是不稳定的根源。

System Prompt（保持不变） 定义角色、接地规则（只使用提供的上下文作答）、引用格式（如用[1]标注来源）、拒答模式（不回答竞品相关问题）。

User Prompt（动态注入） 包含检索上下文（用XML标签清晰分隔）、用户原始查询、查询特定的指令。

XML标签（如<context>、<document>）的解析准确率高于Markdown或纯文本。

一个经过验证的prompt结构

<documents>
  <document source="policy-handbook.pdf" page="12">
    [文本块内容]
  </document>
  <document source="faq-updated-2024.md">
    [文本块内容]
  </document>
</documents>

<query>
[用户的问题]
</query>

💡 元数据策略：来源标题、时间戳、页码要保留（支持溯源和时效判断）。内部相关性分数、文件系统路径、编码信息、调试数据——这些不帮助模型推理，一律剔除。

三种日志看不见的失败模式

1. 引用幻觉（Citation Hallucination）

回答看起来很权威，带上了括号引用，但引用的来源和内容完全对不上号——事实可能是对的，归属是错的。

生产环境需要能溯源验证的机制，追溯每个具体声明的来源。

2. 上下文污染（Context Poisoning）

低相关度的文本块挤占了高价值块的空间。检索返回10个块，7个勉强相关，3个精准命中，但7个噪声块稀释了信号。

解法：收紧相关性阈值，控制块数量。不确定的时候，宁可少喂几个高质量的块，也不要塞一堆“还可以”的。

3. 推理碎片化（Reasoning Fragmentation）

多跳查询（multi-hop query）需要从多个块中串联事实，每个块单独检索都成功了，但模型因为缺乏“桥接上下文”而无法完成综合推理。

解法：层级分块（hierarchical chunking）。LlamaIndex的sentence-window检索机制——按句子索引保证精确度，生成时扩展为完整段落，桥接上下文自动补全。

生产环境验证有效的RAG管道配置

写在最后

核心记忆

1. 位置偏见依然存在，最佳块一定要放首位。
2. 检索和生成之间的管道藏着重排序、去重、矛盾处理等一系列环节，缺一不可。
3. 4~6个高质量文本块 + 两阶段检索 + 清晰的结构化Prompt，是经过验证的最佳实践。

绝大多数RAG讨论都聚焦在检索上。这可以理解——如果连正确的块都拿不到，后面做什么都白搭。

但相比增强层，检索其实已经是一个相对“成熟”的问题了。向量数据库技术日趋成熟，嵌入模型性能持续提升，重排序正成为标配。增强层——检索和生成之间的这片区域——更年轻、更混乱，也藏着更多未被充分挖掘的优化空间。

当你的RAG系统表现不如预期时，先别急着怀疑检索器。看看你的块放在哪个位置，看看你是不是塞了太多噪声进去，看看你的prompt结构到底是在帮模型还是在添乱。

检索也许没有问题。问题出在检索之后、生成之前的那段路上。