RAG 系统上线时通常只会达到一个“可以跑通”的水平，回答质量距离业务预期往往还有明显差距。很多团队在优化时容易犯两个错误：一是凭感觉反复调整参数，缺乏方向；二是企图一步到位设计出“完美方案”，结果迟迟不能交付。实用的做法是按照一套有章法的迭代流程，快速建立基线、定向优化、用数据说话，让每轮调整都有据可依。
1. 第一步：快速建立端到端基线
“基线”是指无需任何精心调优、用默认设置就能跑通的完整流程。它的目的不是追求高分，而是尽早形成可量化、可感知的起点。
- 最小可用系统：选定一个向量数据库、一个嵌入模型、一个 LLM，用最简单的固定长度分块（如 500 字、重叠 50 字），不做任何检索策略优化或提示词雕琢。
- 准备测试集：从真实业务中收集 50～200 个有代表性的问题，人工写好期望的答案要点或评判标准。不需要追求数量，但一定要覆盖不同难度、不同类型的提问（事实查询、总结类、多步推理等）。
- 跑出基线指标：在测试集上运行系统，用预先定义的指标衡量效果，例如答案的事实准确率、召回率、是否有严重幻觉等。记录下来，这就是后续优化的参照。
基线的重要价值在于：它把无形的“质量感”变成了一组具体数字。以后任何一个改动（换了模型、调整了分块大小），都可以跑同一套测试集，立即看出是变好还是变坏。
2. 第二步：分模块定位瓶颈，逐个击破
拿到基线数据后，不要盲目尝试各种高级技巧，而是先回答一个关键问题：回答出错的根因在检索阶段，还是在生成阶段？
可以做一个简单但有效的诊断：人工查看 20～30 个回答不理想的案例，判断问题出在哪里。
- 检索没找到相关内容（召回失败）：切分方式导致关键信息被拆散、嵌入模型对领域术语理解不够、相似度阈值设得过高、知识库本身缺失这部分内容。
- 检索到了，但模型没用对（生成问题）：提示词没有有效约束模型依据资料、模型引用时截断或扭曲原意、多条资料之间有矛盾而模型无法判断。
- 答案基本正确，但格式或完整性不足：缺少要求的结构（如分点、表格）、遗漏了关键细节。
分清瓶颈后，就能有针对性地干预：
- 检索侧优化：调整 chunk 大小与重叠、尝试句子级或语义段落级切分、增加父子文档召回、混合稀疏与稠密检索、微调嵌入模型等。
- 生成侧优化：修改提示词，明确要求“依据以下资料回答，资料不足时如实说明”、加入少量示例（few-shot）、要求标注来源片段编号等。
- 知识库补全：如果是文档本身就是缺失的，则需要补充或重新整理源文件，再重新入库。
每轮只改动一个模块，做好记录，并重新在测试集上跑指标。一次只改一件事，才能清楚归因效果的提升或下降。
3. 第三步：数据驱动的持续打磨
当系统的回答准确率达到可接受水平（比如 80% 以上），用户才会开始大规模使用。此时可以引入更多真实反馈数据，进行精细化调优。
- 记录真实问题与回复：将线上系统生成的每个回答和用户后续行为（如是否点击“查看原文”、是否追问、是否点踩）记录下来。这些行为本身就是弱标注信号。
- 构建“坏案例”池：定期抽取用户反馈差或客服复核不通过的问答对，归因后加入测试集，防止同类问题重复出现。测试集不再只是初始那几十条，而是随着业务运行不断生长。
- 基于数据做策略决策：例如，统计高频出错的文档或主题，看是否是切分策略不匹配；统计模型在某些类型问题上反复出错，可以考虑对该类问题单独写提示词分支，或引入子查询分解。
- A/B 实验验证：当有两个候选方案难以抉择时（比如选哪种重排序模型、是否加入查询改写），可以在一定比例的流量上做对照实验，用真实用户指标（答案采纳率、追问率）而非仅离线测试做最终判断。
4. 实用的迭代节奏与组织建议
- 第一轮（上线前）：在测试集上准确率至少达到 70%～80%，并确保严重的幻觉（如编造法规条款、虚构产品参数）基本消除。这是安全底线。
- 第二轮（灰度发布后）：根据真实用户问题，补充测试集、修复高频召回失败，通常 2～3 周内可将答案满意度提升一个台阶。
- 长期持续：将效果优化视为运营的一部分，而非一次性项目。业务文档会变、用户提问习惯会变、底层模型也会升级，基线需要定期重新校验。
总结
“先基线、再优化、数据驱动”的核心在于避免凭直觉跳跃式调整。快速产出一个可度量的起点，定位问题到底出在检索还是生成，然后以小步快跑的方式逐项优化，每一轮都靠数据而非感觉来判断进退。这样不仅能稳定地提升回答质量，还能让整个团队对系统的运作逻辑建立起清晰且统一的认知。