完整题目
如何对RAG系统进行持续迭代与优化？可从哪些关键维度（如检索、重排、生成、评估等）进行改进？
本文目录
核心思路
RAG优化是个系统工程，需分模块迭代+数据驱动，避免单点优化陷入局部最优。
一、检索层优化（源头质量）
| 手段 | 具体做法 |
|---|---|
| 索引策略 | 按语义/结构切分（如标题+正文），关键信息冗余存储；多粒度索引（段落+句子） |
| 查询改写 | Query扩展（同义词、LLM生成变体）、意图识别后路由不同索引 |
| 混合检索 | 向量+关键词+结构化过滤联合召回，解决语义漂移和精确匹配需求 |
二、重排序层优化（精排筛选）
- Cross-Encoder精排：用轻量模型（如bge-reranker）对召回Top-K重排，比向量相似度更准
- 多路融合：不同召回源（KG、向量、倒排）按置信度加权
- 动态截断：根据query难度自适应调整送入LLM的文档数
三、生成层优化（最终输出）
- 上下文压缩：检索结果去重、摘要提取，避免超长context稀释注意力
- 引用生成：强制模型输出引用标记，便于溯源和事实校验
- 领域微调：用高质量RAG数据对基座模型SFT，提升利用检索信息的能力
四、评估与迭代闭环
离线评估
- 检索：Recall@K、MRR
- 端到端：Answer Correctness（用GPT-4判题）、Faithfulness（幻觉检测）
在线评估
- 用户满意度、点击率、人工标注bad case回流
- 关键：建立可量化的业务指标（如客服场景的问题解决率）
五、工程架构要点
- 模块化设计：检索、重排、生成独立服务，便于A/B实验
- 缓存策略：高频query结果缓存，降低延迟和成本
- 失败降级：检索失败时切换纯生成或提示用户澄清
实际落地建议：先抓大头，通常检索质量和领域SFTROI最高；评估体系必须先行，否则优化方向模糊。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服的RAG系统，上线后发现用户经常问“上次说的那款手机还有货吗”，但系统答非所问。你从哪几个方面去排查和迭代优化？
层层追问
RAG系统上线后怎么持续优化？……你先说说从哪些维度入手……那检索不准怎么调？重排模型怎么加？……再往后生成质量怎么提升？评估指标要怎么定？
直球架构
请从检索、重排、生成、评估这几个关键维度，讲讲如何对一个RAG系统做持续迭代和优化，每个维度具体有哪些改进手段？
练习口述回答 · 约4分钟
- RAG优化本质是系统工程，不能单点优化
- 检索层：混合检索与查询改写解决语义漂移
- 重排与生成：精排筛选、上下文压缩、引用生成
- 评估闭环：离线指标+在线业务指标，驱动迭代
- 落地取舍：优先检索质量与领域SFT，评估先行
这道题其实在问一个系统工程的持续优化能力，而不是罗列一堆技术点。[[RAG]] 从构建到上线，就像一个不断打磨的流程，每个环节都可能成为瓶颈，但真正落地时不能只盯着一个点改，要分模块迭代，同时用数据驱动，避免陷入局部最优。
我一般会从四个层面对齐优化：检索、[[重排]]、生成，以及贯穿始终的评估闭环。先说检索，这是源头质量，如果检索回来的东西就不对，后面再怎么调也救不回来。这里有个关键前提：你不能指望单一检索方式解决所有问题。关键词召回比如 [[BM25]] 适合精确匹配，比如订单号、错误码这种；向量检索适合语义匹配，比如用户说“退款没到账”这种口语化表达。真正落地时我会做 [[Hybrid Search]]，把关键词和向量结合起来，再配合查询改写，比如用户说“退货”，我能自动扩展成“退货退款”“退货流程”，或者用 LLM 把模糊 query 转成更明确的意图。举个例子，在客服场景里，用户问“满减怎么用”，直接向量检索可能匹配到一堆满减规则，但加上关键词和意图识别，我能把它路由到具体的满减政策文档，召回准确率明显提升。
检索回来之后是重排。向量检索的 [[Bi-Encoder]] 速度快但精度有限，所以我会用 [[Cross-Encoder]] 做精排，它能把 query 和每个候选文档一起算相似度，更准，但成本高，所以只对 Top-K 重排。这里有个坑：重排不是越多越好，要根据 query 难度动态截断。简单 query 给 3 个文档就够了，复杂 query 给 10 个，否则长上下文反而稀释注意力。
生成层我重点做两件事：上下文压缩和引用生成。上下文压缩就是去重、摘要，避免把一堆重复或无关信息塞进 LLM，导致 [[Hallucination]]。引用生成是强制模型输出时带上文档编号，这样用户能看到来源，也方便后续做事实校验。如果业务场景对格式和领域知识要求高，我还会做领域 [[SFT]]，用高质量的 RAG 数据微调基座模型，让它更会利用检索回来的信息。
然后是评估闭环，这是迭代的指南针。离线我会看检索的 Recall@K、MRR，端到端用 [[RAGAS]] 框架里的 Answer Correctness 和 [[Faithfulness]]。但光有离线不够，在线业务指标才是最终验证。比如在客服场景，问题解决率、用户满意度、人工介入率，这些能直接反映 RAG 有没有帮到用户。我会把 bad case 回流，分析是检索没找到、重排排错了，还是生成错了，然后针对性优化。
这里有个延伸点：很多人会问要不要把 RAG 和纯微调结合起来。我的看法是，RAG 适合知识频繁更新的场景，微调适合固定知识库但需要深层语义理解的场景。如果两者一起上，要特别注意冲突，微调可能让模型过度依赖参数知识，忽略检索回来的信息。所以我会用 [[Self-RAG]] 让模型自己学会什么时候该依赖检索，什么时候该用自己的知识。