Agent

Agent_RAG优化

RAG 优化学习笔记：从检索链路优化到生产闭环

English

RAG 优化学习笔记

这段时间我把 RAG 相关优化资料系统看了一遍：

RAG 的核心瓶颈早就不是“能不能跑起来”，而是“在线上能不能稳定命中、稳定可控、稳定可评估”。

我现在把 RAG 优化拆成 4 层：

  1. 检索前优化（Query + Chunk）
  2. 检索期优化（Recall + Rank）
  3. 检索后优化（Context Packing + Compression）
  4. 生产闭环优化（Evaluation + Feedback）

检索前优化：先把输入和语料质量做对

我关注的优化点

  1. 语义切片（Semantic Chunking）
  • 不要再固定 300/500 token 生切
  • 按段落语义、代码边界、标题层级切片
  • 目标是让每个 chunk 自洽、可独立被引用
  1. 查询重写（Query Rewriting）
  • 对口语化问题做术语标准化
  • 对缩写、别名、拼写错误做归一化
  • 对复杂问题做拆解（decomposition）
  1. 假设文档检索（HyDE）
  • 先让模型生成“理想答案草稿”
  • 用草稿向量去检索，而不是直接用用户短问句
  • 我会把 HyDE 当成“召回增强开关”，只在低召回场景启用

我的判断

切片方式的升级是一定要改进的，它决定了向量化后的信息准确性，和查询后的信息相关性。
当业务环境中需要查询的指令比较长，指向性不够准确 可以考虑使用小模型节点进行查询重写。
如果经过查询重写后还是搜索不到理想的结果或者由于长短矛盾查询的信息太短可以考虑假设文档检索，但实现复杂增加搜索时间。

检索期优化：多路召回 + 重排，而不是单路向量检索

我现在采用的思路

  1. 混合检索（Hybrid Search）
  • 稠密向量召回语义相关
  • 稀疏检索（BM25/关键词）兜底精确匹配
  • 融合结果后再进入重排
  1. 两阶段排序（Recall L1 -> Rank L2）
  • 第一阶段追求高召回，宁可多捞
  • 第二阶段用 reranker 做精排，压缩到 top-k
  1. Cross-Encoder / API Rerank
  • 将 query-doc 成对评分
  • 比单纯向量相似度更稳，尤其对长文档片段

我的判断

混合检索多路回归确实能提升准确召回的正确率，它更像是弥补 embedding 模型对垂直领域术语区分度不足导致的信息丢失，进而导致无法准确计算到正确的信息相关性。我认为随着未来 embedding 模型的能力提升混合搜索的提升方式会逐渐退出市场应用。
针对 线上经常不是“找不到”，而是“找到太多不准的” 的问题，可以使用重排序 Rerank 进行增强， Rerank 在生产里不是锦上添花，而是相关性质量闸门。

检索后优化：把喂给 LLM 的上下文变成“高密度证据”

我重点做的三件事

  1. 证据压缩
  • 先重排，再压缩
  • 去掉弱相关句子、模板噪声、重复段落
  • 保留可引用实体、数字、结论句
  1. 上下文打包策略（Context Packing）
  • 不按召回顺序硬拼
  • 按“问题子意图 -> 证据组块”重排
  • 给每个证据块标注来源 id，方便追溯
  1. 缓存友好拼接
  • 将稳定不变的系统前缀和知识说明前置
  • 尽量提高前缀复用和缓存命中（降低时延与成本）

我的判断

RAG 成本主要不是检索本身，而是“把低价值上下文喂给大模型”。
检索后提纯是最直接的降本手段之一。

生产闭环优化：把 RAG 从 Demo 变成系统

我采用的评估视角

  1. 检索层指标
  • Recall@k
  • MRR / nDCG
  • 命中率分桶（短问句、长问句、代码问句）
  1. 生成层指标
  • Faithfulness（是否基于证据）
  • Answer Relevance（是否答到点）
  • Context Precision（上下文里真正有用的比例）
  1. 系统层指标
  • P95 时延
  • 单次问答 token 成本
  • 缓存命中率
  • 失败路由比例（需要兜底检索/外部搜索）

我设计的反馈回路

  • 用户提问 -> 检索召回 -> 重排 -> 生成回答
  • 评估器对答案和证据做自动打分
  • 低分样本自动回流到“难例集”
  • 周期性回归测试检索参数、分块策略、重排模型

厂商/框架方的规范建议（我重点参考）

我优先看“厂商官方 + 文档级实践”资料，避免只看二手经验。

  1. Microsoft Learn: Build Advanced Retrieval-Augmented Generation Systems
  • 给出端到端 advanced RAG 流程
  • 明确强调 query rewriting、post-retrieval processing、评估回路
  1. Azure Architecture Center: Develop a RAG Solution—Information-Retrieval Phase
  • 给出检索层系统化建议
  • 明确提到 query augmentation/decomposition/rewriting/HyDE
  1. Anthropic Engineering: Contextual Retrieval
  • 强调混合检索与上下文利用策略
  • 对“检索到不等于用得好”这个问题讲得很清楚
  1. Anthropic Help: Retrieval Augmented Generation (RAG) for Projects
  • 偏实践 checklist，适合产品化阶段对照
  1. Cohere Docs: Best Practices for using Rerank
  • 系统讲了 rerank 的输入组织、chunk 处理和上线注意点
  1. 论文: Lost in the Middle
  • 给出长上下文中部信息利用率下降的证据
  • 直接支持“重排 + 压缩 + 打包”的工程必要性
  1. 论文: RAG: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
  • RAG 方法论起点，定义了“检索+生成”的基本范式

我怎么把这些优化融入实际 AI 应用改进流程

我现在用一个“按周迭代”的改进流程：

第 0 步：先定场景和基线

  • 选 100~300 条真实问答样本（按场景分桶）
  • 跑出当前基线：检索命中、答案质量、时延、成本

第 1 步：只改一个变量

每轮只动一处：

  • 分块策略
  • 查询重写开关
  • 混合检索权重
  • reranker 模型/阈值
  • 上下文压缩比例

避免多变量同时变更导致无法归因。

第 2 步：离线评估先过线

  • 离线指标不过线，不进线上灰度
  • 看三类变化：质量提升、时延变化、成本变化

第 3 步：线上灰度 + 回滚阈值

  • 小流量发布
  • 设定自动回滚阈值（如 P95、投诉率、空答率）

第 4 步：沉淀为工程资产

将有效策略写入：

  • 检索配置模板
  • Prompt/context 组装规范
  • RAG 回归评估脚本
  • 失败样本集与标注规范

我的结论

我对 RAG 优化的最终判断是：

  1. 检索前决定上限（问题是否被正确表达）
  2. 检索期决定命中率（是否真正找对证据）
  3. 检索后决定成本与可用性（是否把高密度证据交给 LLM）
  4. 生产闭环决定可持续性（是否能持续变好）

一句话总结：

RAG 优化不是“模型参数调一调”，而是“检索、重排、上下文、评估、反馈”整条链路的工程治理。