在 RAG 系统中，“检索到了相关内容”并不等于“检索到了有用的内容”。一个普遍存在但容易被忽视的问题是：返回的片段中夹杂了大量低信息密度甚至完全无效的文本，它们白白占用了宝贵的上下文窗口，却对回答毫无贡献，甚至误导模型。
1. 问题表现：信息密度低从哪里来
信息密度低的片段通常有以下几种典型来源：
- 过度切分导致语义碎片化
为了控制 chunk 大小，某些长文档被机械地按固定长度切分，一个完整的概念被拆成两半。检索时召回的可能是后半段，缺少前文定义，几乎无法独立理解。比如召回了“具体操作步骤如下：”，但前面的步骤编号被切在上一个 chunk 里，这条片段等于无效。
- 文档本身包含大量“噪音”段落
企业文档中常有目录、页眉页脚、版权声明、版本记录、大段免责声明、表格周围的空白填充文字等。这些内容在向量化时同样被编码，导致检索时可能因为某些关键词偶然命中而被召回。例如用户搜索“价格”，一个包含“价格声明：本公司保留随时调整价格的权利”的页脚被排在了前面，但这句话完全回答不了任何实质性问题。
- 格式标记残留过多
PDF 转换过程中可能混入多余换行、乱码、拼接错误，Markdown 或 HTML 标签未被清洗干净。这些符号本身不携带语义信息，但占据了 token 计数。模型在处理时需要额外“脑筋”去忽略这些噪音。
- 通用套话和背景描叙
政策文件开头常有长篇目的、范围、定义说明，而用户真正关心的操作条款埋在文档深处。如果检索系统只按表面相关性打分，这些“前奏”段落可能因为包含问题中关键词而被优先追回，导致回答上下文中有效信息比例极低。
2. 负面影响：窗口被挤占，生成质量下降
上下文冗余对系统性能的损害是连环性的：
- 有效信息被挤出窗口
LLM 的上下文窗口是有限的（例如 4K、8K、32K token）。每个检索到的无用片段都在消耗这一配额。如果最关键的说明性内容排在检索列表的第 5 位，而前 4 位都是低质量片段，很可能在拼接上下文时，真正有用的片段根本无法被容纳。
- 模型注意力被分散
生成模型需要对长上下文分配注意力权重。大量混乱或无关文本会稀释对真正答案线索的“关注”，导致模型遗漏关键信息，或者把噪音内容也当作事实来源进行引用，产生莫名其妙的答案。
- 增加延迟和成本
输入 token 越多，推理时间越长，API 调用成本越高。无效内容带来的额外开销是纯浪费。对于日均数万次调用的系统，累积影响不可忽视。
3. 根因分析：为什么会召回到低密度内容
问题根源通常不在模型，而在检索与预处理阶段的两个环节：
- 语义相似度不等于信息可用性
向量检索考量的是语义“相似性”，但高相似片段可能只是“长得像”问题，而不是“能回答问题”。比如问题“如何申请年假”，文档中“年假是指员工每年享有的带薪休假”这一句语义高度相关，但它只是定义，不是操作步骤，实际可用性很低。
- 元数据未被有效利用
很多系统在检索时没有过滤文档结构标签。如果能提前知道某些段落在原文档中属于“页眉”或“修订历史”，可以轻松排除。但实践中往往将所有文本一视同仁地嵌入和检索，导致大量结构噪音进入候选池。
4. 实用解决方案
针对上下文冗余，可从预处理、检索策略、后处理三个层面着手改进：
（1）提升文档解析与清洗质量
- 结构化解析：使用专门的文档解析工具（如针对 PDF 的 PyMuPDF、针对 HTML 的 BeautifulSoup），提取正文时剔除页眉页脚、页码、水印。
- 格式清洗：移除多余空行、修复乱码、删除纯符号表格线。对 Markdown/HTML 漂洗干净，只保留纯文本和必要标题层级。
- 智能分块：按语义边界（段落、标题、列表项）切片，而不是固定字符数。必要时保留上下文重叠（chunk overlap），确保单个 chunk 具备独立可读性。
（2）在检索时设置质量过滤
- 元数据筛选：为每个 chunk 标注来源文档类型、章节属性。检索时通过前置过滤（pre-filtering）只召回正文类内容，排除声明、目录等噪音类型。
- 相似度阈值裁剪：设定合适的最低相关性分数，低于阈值的片段直接丢弃，宁可少给几条也不给无用内容。
- 重排序（Re-ranking）：在向量召回后，接入一个重排序模型（如 cross-encoder），专门评估片段“实际回答问题的潜力”，将真正有用的片段排到前面，顶掉那些只有表面相关的低密度内容。
（3）后处理精简上下文
- 动态压缩：对已召回的片段做摘要压缩，用更少的 token 保留核心事实。适合片段本身较长但关键信息仅集中在几句话的情况。
- 片段去重：当同一个来源的不同切片都包含相似描述时，剔除冗余副本。尤其对于文档中反复出现的“注意事项”“免责条款”有效。
- 按优先级填充窗口：不采用“召回几条拼几条”的简单做法，而是以最大 token 配额为限，按重排序后的得分从高到低依次填入上下文，填满即停。这保证了窗口始终被最高质量信息占据。
真实案例
某制造企业 RAG 助手在回答设备参数问题时，频繁在回复中露出“本手册更新于 2023 年 3 月”这样的页脚内容。经检查发现，PDF 转换时页脚被保留成独立段落，且常因包含“更新”这个词与问题中的“版本”语义相似而被检索。解决措施很简单：在解析阶段用正则表达式去掉了页脚行，问题立刻消失，回答准确性也随上下文纯净度提升而改善。
上下文冗余是一个容易被忽视的“隐形成本”，但通过合理的文档清洗、智能化的检索过滤和有效的上下文编排，完全可以大幅降低无效信息的干扰，让有限窗口发挥最大价值。