RAG 从原理到实践：混合检索、重排序与效果评估的工程全解析
大模型一本正经地胡说八道，这个场景应该不陌生。问它一个具体业务问题，它逻辑顺滑地给你编了一个看似合理实则完全错误的答案。早期大家靠调整提示词，后来发现治标不治本。RAG 正是在这个背景下被推到台前——它不试图让大模型记住所有知识，而是先在外部知识库里检索到相关资料，再把这些资料作为上下文交给模型生成答案。
RAG 看起来流程直白，但每个环节都有大量工程细节：切多大块合适、用什么嵌入模型、检索召回多少条、拼装顺序怎么排——随便一个参数变动，最终效果都可能差一大截。本文聚焦检索质量这个决定 RAG 成败的核心，从数据准备、向量检索、混合检索、重排序到效果评估，给出可以落地的工程方案。
一、RAG 的核心逻辑：为什么检索比"记住"更可靠
大模型的"记忆"本质是概率，不是数据库。模型训练时把语料压缩成几十亿甚至几千亿个参数，这些参数本质上是对训练数据分布的概率建模。它"知道"一个事情，是这个事情的概率权重足够高，而不是它真的有选择性地记住了某条记录。这就带来两个问题：训练数据有截止时间，之后发生的事它不知道；低频但关键的业务知识在参数里权重不够，生成时就容易"幻觉"。
RAG 的思路完全不同。它把知识从模型参数中剥离出来，放进一个可检索的外部索引。生成时先检索，再让模型基于检索结果作答。相当于给模型配了一个可以随时翻阅的资料库，它不需要"记得"，只需要"会读"。完整跑一遍 RAG 链路，核心是四个环节：知识入库、查询检索、结果融合、生成回答。每个环节都可以理解成开卷考试的一部分：入库是准备教材目录和索引卡片，检索是定位知识点在第几页，融合是把这个知识点摘抄到答题纸上，生成是组织语言写答案。
二、数据准备：切分策略与知识库构建
文档解析远比想象中费劲。PDF 是最麻烦的，尤其是扫描版，本质是图片，需要 OCR，而 OCR 出来的文字可能丢失表格结构、把多栏排版读成一串乱文。表格是另一个重灾区：如果知识库里全是财务报表或技术参数表，直接用普通文本解析，检索时把整张表切成一堆碎片，模型根本看不出"这是同一行"。对这类内容，比较可靠的做法是先做表格识别转成结构化 Markdown，或者把表格抽出来单独存成 CSV，按行写入索引。
切块长度与重叠的取舍逻辑是 RAG 里被讨论最多也最容易被拍脑袋决定的环节。按字符数切分，常规文档块大小控制在 500 到 800 个字符，重叠区域 50 到 100 个字符，这个区间适合大多数技术文档和问答场景。但字符数只是一个粗粒度参数，真正高级的做法是按语义边界切分：先按段落切，段落超长再细化。针对代码类文档，可以用 AST 解析来切，保证切出来的每一块都是完整函数或完整类。针对 Markdown 文档，按标题层级切更合适。没有普适最优的切分参数，只有适合你文档类型的策略。
元数据设计直接影响过滤能力。很多初做 RAG 的人会忽略元数据，把所有文本块一股脑丢进向量库，只存了文本和向量。等上线后业务方说"我只想检索 2024 年以后的合同"，就傻眼了——库里根本没有时间字段。正确的做法是在入库时为每个文本块打上结构化的元数据标签：文档 ID、标题、章节路径、作者、部门、日期、文档类型、权限级别。这些标签有两个核心用途：检索阶段做前置过滤，先按元数据缩小范围再跑向量相似度计算；生成阶段用于溯源引用，告诉用户"这段话来自哪份文档的哪个章节"。元数据设计的经验是不要贪多，核心保留四五个高频使用字段就够。
三、向量检索：Embedding 选型与相似度计算的工程细节
Embedding 模型决定检索上限。选型时关注几个维度：语言覆盖度，中文为主的知识库优先选中中文效果好的模型；向量维度，768 维对中小规模知识库已经够用；最大输入长度，这个参数决定了切块长度上限。另外要注意，查询端问题和知识库文档的性质不完全一样——问题通常短而口语化，文档通常长而书面化，用同一个嵌入模型编码时可能存在域偏移。解决思路有两个：专门微调一个面向业务场景的嵌入模型，或者检索时对问题做扩展改写，把短问题扩写成更具体的表述再编码。第二种方案在实践中更常见，成本也更低。
相似度计算常用欧氏距离、余弦相似度、内积三种。使用余弦相似度时向量经归一化处理后，它与内积等价。Top-K 和阈值是最容易被忽视的召回参数。Top-K 决定返回多少条文本块作为上下文，过少容易漏答案，过大则塞入大量噪音。阈值决定相似度多低才不参与召回。但注意一个坑：阈值不是通用常量，它是你选的嵌入模型和业务数据的联合特征。最好的做法是抽取一批真实问题，人工标注正确答案，在验证集上跑不同阈值看召回率曲线，而不是凭感觉拍。
四、混合检索与重排序：接近生产级的检索质量
为什么纯向量检索不够用？纯向量检索的底层逻辑是语义匹配，但现实场景里很多需求是精确匹配。比如检索一个工单编号或者产品型号，嵌入模型未必能准确理解这种精确符号串的语义。这就是纯向量检索的瓶颈：它不擅长处理专有名词、编号、缩写、代码片段这类需要字面精确对应的场景。
解决思路是引入稀疏检索，也就是传统的 BM25 算法。BM25 基于词频和逆文档频率做关键词匹配，对专有名词、精确术语的命中能力很强。向量检索负责理解语义，BM25 负责精确匹配，两者结合就是混合检索。举个具体例子：处理设备维修知识库时，用户问"怎样更换冷却泵的密封圈"，向量检索召回的文档里几乎都是关于"冷却泵"故障排查的内容，而真正包含"密封圈更换步骤"的文档反而排名靠后。混合检索之后，BM25 对"密封圈"这个词的字面匹配把这篇文档拉回到了准确位置。语义和字面，两手都要硬。
混合检索会得到两个召回列表，怎么合并成一个有序列表？最通用的做法是 RRF 倒数排名融合。它的核心思想非常朴素：如果一个文档在两个召回列表里排名都靠前，那它大概率相关；如果只在一个列表里排名靠前，置信度低一些。公式是给每个文档的排位取倒数，再对两列表求和。RRF 实现简单，不需要调权重参数，是稳妥的起点。如果需要更精细的融合，可以用加权分数融合，比如把归一化后的余弦相似度与 BM25 得分按 7:3 加权求和，这种方式对调参能力要求高，但上限也更高。
重排序模型是最后一道质量闸门。混合检索之后，召回的候选列表通常有几十条到上百条，但真正塞进上下文的只有几条。专门的重排序模型与嵌入模型不同，它直接把"问题"和"文档"拼在一起做交互式编码，能建模二者之间更细粒度的匹配关系，效果远好于先用向量映射再做距离比较。实际项目中的收益非常明显：只跑向量检索时，正确答案进入 Top-5 的比例约六成；加上 BM25 混合检索后提升到七成；再加上重排序模型精排，最终稳定在八成五以上。每一层都在前一层基础上叠加"保命闸门"。重排序的使用要控制延迟，常见做法是把混合检索的 Top-50 经过重排选出 Top-5 再进上下文。
五、生成优化与体验设计：让答案真正"可靠"
提示词结构决定答案边界。更可靠的做法是在 Prompt 里做三层约束：第一层是角色与任务描述，告诉模型你是某个知识库的回答助手；第二层是引用规范，明确要求只基于给定的文档片段回答，不能引入外部知识；第三层是格式要求，比如要给出分点回答、标明引用来源、无法回答时直接说明。有一个值得突出的设计是"拒绝机制"——当检索结果与问题相关性整体偏低时，好的 RAG 系统应该让大模型诚实地说"知识库中没有找到相关答案"，而不是硬从只言片语里编一个回答。
多轮对话是大多数 RAG 项目绕不开的需求。用户在追问"那更换频率呢？"时，如果系统只拿这一句新问题去检索，上下文是断裂的。较简单的处理是用一个查询改写环节，结合历史对话把当前问题重写成独立表述。注意别把整个历史对话都拼进去，改写模型的输入一般只取最近两到三轮历史，设定一个 Token 上限。
六、效果评估：不能只看"感觉"
很多团队的 RAG 项目死在"感觉还不错，不知哪里不好"。评估 RAG 质量可以从两个维度拆。检索引擎的质量用命中率指标衡量：给定一批人工标注了正确答案的问题集，看正确答案是否进入前 N 个召回结果。生成质量用答案正确率和回答忠实度衡量。忠实度指的是模型生成的答案是否严格依据检索到的文档，这个可以通过大模型裁判来自动打分。
我的习惯是每个知识库维护一份至少百条以上的评测问题集，覆盖高频问题、疑难问题、边界问题三类。每次调整切分参数、换嵌入模型、改检索策略，都在同一份评测集上跑一轮离线评测，对比指标后再决定要不要上线。这件事枯燥，但它是对抗"感觉良好"的唯一办法。
七、前沿演进与落地建议
传统 RAG 是固定的流水线：先检索，再生成，一次搞定。前沿方向把模型本身变成了检索流程的决策者——由大模型根据问题自主决定：要不要检索、检索哪类数据源、一次不够要不要再查一次。这种架构适合处理需要跨文档整合的复杂问题，但工程复杂度也随之上升，上线时要给每一步动作设计明确的终止条件，避免死循环。
另一条路线是图检索增强：先对文档做实体抽取和关系抽取，把知识组织成图结构，检索时不光检索文本块，还顺着图结构往外探索关联实体。它适合"从散落的多篇文档里找出跨文档的共性结论"这类场景，但落地成本不低，实体抽取的精度、图结构的更新维护都是门槛。如果业务还停留在单文档问答阶段，上它是过度设计。
落地时遵循几个原则：从最简单能跑的方案开始，遇到问题再加机制，不要提前设计；先把消息协议、检索链路、评审反馈这三块磨扎实，再逐步扩展；每次调整只改一个变量，用评测数据说话。RAG 的价值在于把知识更新从"按月迭代"变为"分钟级生效"，掌握这套检索工程，你就握住了企业级 AI 应用的关键基础设施。
