检索增强生成 rag 系统综述:技术、指标与挑战

你可能已经跑通了一个最简单的RAG问答，但一上真实资料就发现答非所问、找不到出处、成本还压不下来；也可能正准备动手，却被一堆分块、向量、重排、评测的名词绕晕。这篇不重复原理科普，而是把RAG当成一个要长期维护的系统来看：有哪些层、每层要盯什么指标、哪些挑战几乎一定会撞上、遇到问题按什么顺序查。看完你能列出一份自己的落地清单。

你可能已经跑通一个最简单的RAG问答，拿自己的资料一试就发现答非所问、找不到出处，成本还压不下来；也可能刚准备动手，就被分块、向量、重排、评测这一堆名词绕晕。这篇不重复原理科普，而是把RAG当成一个要长期维护的系统来看：分成哪几层、每层盯什么、哪些坑几乎一定会撞上、出问题按什么顺序查。

读完你可以直接列出一份自己的落地清单。需要说明的是，下面的分层和排查顺序在「单团队维护、语料中等规模、问答型场景」下最顺手；如果你做的是纯离线批处理、或者语料小到几百页，很多环节可以砍掉，不必照搬。

技术体系：把RAG拆成能分别验收的几层

把RAG看成一整块，出了错根本不知道改哪。按验收单元拆成四层，每层有独立的好坏判断，改一层只影响一层。顺序上从进料开始做，不要先挑模型。

进料层

解析、清洗、分块。它决定系统上限，文档乱、表格多、扫描件多的场景先解决清洗再谈别的

检索层

向量、关键词、混合、重排。它决定召回质量，先固定一种基线再逐项加，别一次全上

生成层

上下文拼装、引用、格式约束。它决定可信度，要求模型给来源编号，答不出来就说不知道

编排层

是否引入多轮或Agent式检索。按需求加，简单问答引入反而更难调试

选型时别只看宣传页的对比表，去站内的向量库与嵌入模型目录看实际支持的过滤、更新、部署方式，再结合自己的运维能力定。具体到某个方案当下的价格和规格，到 /stacks/vector-dbs 与 /embeddings 核对当时的数字。

评估指标：分三层看，别只盯最终答案

只测「最终答案对不对」是最常见的误区——答案错了你分不清是没检索到，还是检索到了但没用好。分三层看，才能定位问题。

• 检索指标重点看召回位置和重排前后的变化，不只看有没有命中
• 生成指标重点看引用是否指向正确来源、有没有编造不存在的内容
• 端到端指标用固定问题集人工抽检，记录三类结果比例
• 每次改动后重跑同一批问题，避免改A坏B
• 语料极小、问题高度集中时，靠人工抽检就够，搭自动评测反而费时

主要挑战：这几类问题几乎一定会遇到

下面几类不是偶发故障，而是RAG系统的常态。提前知道，遇到时就不会怀疑整套方案是不是错了。

• 分块边界把一个完整语义切成两半，导致检索到了却答不全；先按标题层级切，再考虑重叠
• 同义不同词、缩写与全称混用，纯向量检索会漏；补关键词检索或做查询改写
• 多跳问题（答案要串两三处资料）单次检索做不到，需要拆问题或多轮检索
• 时效与权限：文档更新后索引没同步、不同角色看到不同内容，这是工程问题不是模型问题
• 召回片段过多挤占上下文，反而让生成质量下降；控制送入的数量和顺序

出问题时的排查顺序与落地清单

排查有一个固定顺序，能省掉大量试错：先看检索结果，再看生成。把召回的片段单独打印出来，判断是「没找到」还是「找到了没说对」，这两条路要修的东西完全不同。

1. 打印召回片段把每次问答实际送入模型的片段和分数打出来，人工看一眼是否包含正确答案
2. 定位问题类型没找到就查分块、查询改写、检索方式；找到了没说对就查上下文拼装顺序和提示词约束
3. 改动后回归维护一小批固定问题集，每次改动重跑一遍，对比变化再决定是否保留
4. 上线前兜底准备好检索日志、回答引用、超时与失败降级，出问题才有据可查

日志和监控的具体做法，可以参考站内 /tools/quality-monitor 与 /tools/log 的思路，不一定要照抄工具，但「存召回片段与分数」这条建议很值得保留。

RAG的问题大多不在模型，而在「你喂进去的东西」和「你怎么判断它对不对」这两件事上。