如何教会一个小型 LLM 丢弃 68% 的 RAG 上下文
Kapa.ai 是一个基于 RAG（检索增强生成）的技术文档问答系统。他们面临一个典型问题：每次查询时，RAG 管线会检索出过多的上下文信息，导致成本上升、响应变慢，而且由于 LLM 的"中间迷失"（lost in the middle）问题，准确率反而下降。
解决方案是：训练一个小型分类模型，预测检索到的哪些文本块对回答当前问题实际有用。最终结果：在保持甚至提升回答质量的前提下，削减了 68% 的检索上下文。
为什么 RAG 上下文剪枝如此重要
RAG 系统的运作方式是：检索相关文档/文本块，然后将其塞入 LLM 的提示词中。但这样做存在几个问题：
- 当相关信息被埋在长提示词的中间位置时，LLM 的表现会明显下降
- Token 越多 = 成本越高
- Token 越多 = 响应越慢
- 不相关的上下文会混淆 LLM，甚至导致幻觉
他们的方法
他们微调了一个基于 BERT 的小型分类器（1.1 亿参数），该模型接收一个（问题，文本块）对，预测该文本块是否与问题相关。这是放置在初始检索之后、LLM 生成之前的重排序环节。
训练数据的挑战
他们需要标注好的（问题，文本块，相关性）数据。解决办法：使用 GPT-4 生成训练标签。对于每次查询，先检索 Top-K 个文本块，然后让 GPT-4 指出它在生成答案时实际使用了哪些文本块，以此作为标注的真实数据。
模型详情
- 基础模型： BERT（1.1 亿参数，可在 CPU 上运行）
- 输入格式： [CLS] 问题 [SEP] 文本块 [SEP]
- 输出： 二分类（相关/不相关）
- 训练数据： 约 5 万个来自生产 RAG 流量样本
- 训练时长： 单 GPU 约 2 小时
结果
- 上下文削减 68%（每个查询从 12 个文本块降至 4 个）
- 回答质量提升： F1 分数从 0.84 提升至 0.86
- LLM API 成本降低 45%
- 延迟降低 52%
- 分类器每次查询推理时间 <50 毫秒
关键启示
- 小型 BERT 分类器在重排序任务上的表现出人意料地好
- 以 LLM 自身的行为作为训练信号，可以构建自我改进的系统
- 上下文剪枝不仅节省成本，还能提升准确率
- "中间迷失"问题真实存在，不可忽视
生产部署
该分类器以轻量级微服务形式运行，单 CPU 实例即可承载生产流量。通过 ONNX 或 TorchScript 部署非常简单直接。
