types of rag models

你可能已经跑通了一个最小可行的 RAG（检索增强生成）demo，但一换文档类型、一加并发、一上生产就开始出问题：召回忽好忽坏、答案带不出出处、响应慢到没人用。这篇不重复讲 RAG 是什么，而是把市面上常见的 RAG 模型类型按架构差异拆开，说明每类适合什么数据、什么并发、什么成本结构，再给一份选型对照表和上线前的自查清单，帮你在动手前先把类型定下来。

先想清楚：按哪些维度给 RAG 分类才有用

给 RAG 分类，最容易掉进的坑是按论文名字记：谁提的、叫什么缩写、发在哪。结果真到选型的时候，脑子里一堆名词，手上还是不知道从哪下手。更有用的做法是换一套坐标，用几个和数据形态、交互方式直接挂钩的维度去切。这样哪怕记不住名字，也能推出一类架构大概长什么样。

检索粒度

一次去库里捞多大一块东西：整块、单句、图、表，粒度选错，后面怎么调都吃力

检索触发方式

是问一次捞一次，还是边想边补捞，还是模型自己觉得没底再回头捞

生成与检索的耦合度

先捞完再写，和写一半发现缺料再回头捞，是两种完全不同的工程结构

知识形态

库里到底存的是向量、关键词倒排、图谱关系，还是图、表这类多模态内容

这四个维度之间是可以叠加的。比如「图/表粒度 + 自省触发 + 边检边生 + 图谱形态」，组合出来就是一类专门啃结构化文档的架构；换成「句子粒度 + 一次性触发 + 先检后生 + 向量形态」，那就是最朴素的问答链路。所以别背架构名，改成问自己一句：它到底在解决哪类数据难题。这个问法能直接对上你手头的库和查询。

什么时候不用纠结分类？如果你的场景是单库、单轮提问、纯文本问答，先别上复杂结构。最小链路能跑通、答得也够用，就不要为了用上某个听起来高级的形态去加图谱、加多轮自省。分类的意义是遇到瓶颈时知道往哪个方向调，不是一上来就把四个维度的复杂档全点满。

1. 先把现状归到四个维度里拿你手上正在跑（或者要搭）的系统，对着上面四个维度各选一个档位写下来。写不出来说明需求还没想清楚，先别选型。
2. 找出真实卡点在哪一维是召回不准（粒度问题）、问答太浅（触发方式问题）、慢且难调（耦合度问题），还是数据本身不是纯文本（形态问题）。卡点之外的那几维，维持简单档。
3. 只升一维，验证一维一次只动一个维度，跑对比看有没有变好，别四维一起上。变好了再考虑下一维；没变好就退回，留个记录。
4. 去站内核对当时的实现与数据形态与工具的对应关系会变，数字别记死，到站内页面看当时的口径，避免拿旧结论套新场景。

朴素一族：一次性检索 + 生成，什么时候够用

如果你的问题很短、答案就在一两段原文里，朴素 RAG 基本够用，甚至比堆一堆花活更稳。它的链路就三步：把文档切片入库，用问题去相似度召回 Top-K，把这几段原文拼进提示词让模型作答。没有二次改写、没有多轮检索、没有反思循环，出错的地方也好定位。

表格里「该换思路」的那几列不是说朴素 RAG 不能用，而是说召回一条不等于召回全部。跨文档归纳、多跳推理、答案散落十几处这三类问题，Top-K 再大也可能只捞到片段，模型拿到的上下文本身就是残缺的，再强的模型也补不回来。这类问题不是调参能救的，得在检索环节加东西。

1. 先固定评测用例挑二十到三十个真实问题，人工标注每题的正确答案出处段落。这份用例是后面所有调整的标尺，先建好再动手，别边调边换题。
2. 确认切片边界看被召回的那段是否被切断了语义。切得太碎，答案被劈成两半；切得太大，噪声挤占上下文。改动切片粒度后跑一遍用例，看命中段是否变完整。
3. 调召回条数从较小值往上加，观察用例里「答案本来就在库里却没被召回」的题目有没有减少。加到收益趋平就停，继续加只会引入干扰段落。
4. 调拼装顺序把更可能相关的段落放前面，看答对率变化。顺序对强模型影响较小，对上下文利用率不高的模型影响明显。
5. 一次只动一个每轮只改切片、条数、顺序里的一个变量，改完立刻跑固定用例。三个一起动，出问题你分不清是谁的锅。

最常见的误判是把「答得不好」全算到模型头上，然后忙着换模型、加提示词，真正的原因却在召回环节：正确上下文压根没进提示词。判断方法很直接，把模型实际收到的上下文打出来看一遍，答案段在不在里面。不在，换模型没用；在但答错，才轮到怀疑生成环节。

• 先看上下文里有没有答案段，再谈模型行不行
• 召回没命中时，优先查切片粒度和召回条数，而不是改提示词
• 命中了但答偏，才去看拼装顺序和指令表述
• 每次调整都跑同一份固定用例，用数字说话而不是凭感觉
• 切片、条数、顺序都可调，但一次只动一个，动完记录结果

召回 + 重排一族：多一路排序模型值不值

粗召回只管「宁滥勿缺」，从向量库或关键词索引里捞回一批候选；重排模型再对这批候选挨个算一次相关性，按分数重新排队，只把最靠前的几条塞进提示词。召回端因此可以放宽阈值，精度交给重排兜底，这是这一族结构上最实质的变化。

代价要说清楚：多一路排序就多一次调用，延迟和成本都跟着涨，而且重排通常排在召回之后，串行叠加，对低延迟场景不友好。候选集太小更尴尬——重排面对三五条近乎全对的输入，几乎没有发挥空间，加了等于白加。反过来，候选给太多，重排本身就成了瓶颈。

• 文档库规模大、单靠关键词排序明显不够用时，重排收益明显；
• 术语、缩写、中英混排与用户口语差异大时，重排能把语义对上的段落顶上去；
• 候选集常年只有个位数、或查询本身极简单时，先别急着加，加了也看不出差别；
• 接口要对用户秒回、延迟预算很紧时，重排要么降级要么异步，不能硬塞进主链路。

多轮与自省一族：让检索自己决定检几次

这一族 RAG 的共同点是「把判断权交给模型自己」：先决定这次要不要检索，再决定查询怎么改写，检索完自评够不够，不够就再来一轮。典型形态就是四步循环——判需不需要查、改写查询、检索、自评补齐。它解决的是单次检索「一次没查准就完事」的问题，代价是链路变长，延迟和调用次数同步上涨。

它不是什么场景都划算。问题复杂、需要多跳推理、知识散在好几个来源里，这时候自省能明显提升答案完整度。但如果用户问题本身就很直接，比如问一个明确的名词解释或单一事实，这套机制只会把一次能答完的事拆成三四次调用，响应时间成倍拉长，收益却是零。判断标准很简单：预估需要几次检索才能答全，如果答案是一到两次，就别上自省。

1. 先设轮数硬上限在编排层写死最大检索轮数，比如两到三轮，到点就强制收口出答案，不允许模型自己决定继续。
2. 再加超时兜底给整条链路设总超时，超时就退回用已有材料作答，而不是让请求挂着。验证方式是压测一个永远不会满足的问题，看它是否在预期时间内返回。
3. 对着单次成本算上限轮数每加一轮，token 和调用次数都翻倍。上限具体设多少，要到站内模型与价格页把单次调用成本乘上最坏轮数算一遍，看是否还在可接受范围。
4. 留一个降级开关线上按问题类型分流：模板化、延迟敏感的问题直接走朴素单次检索，只有复杂多跳问题才开自省。

还有一种容易被忽略的坑：自评环节本身也会消耗模型判断力。如果自评提示写得太松，模型几乎每次都判定「够了」，自省就退化成走过场；写得太严，又会反复补检停不下来。这两个方向的排查，可以到站内指南中心找对应的调试思路。

结构化与图谱一族：关系型问题怎么接

有一类问题，向量的相似度天生帮不上忙。比如「这个模块归哪个团队维护」「改了这张表会影响哪些下游报表」「这份合同里的甲方和上次那份是不是同一家」。这些问题的答案不在某一段文字里，而在实体之间的连线上。纯向量检索会把所有提到过这些名字的段落都捞出来，看着都很相关，但没有一段能直接回答。这时候要考虑的就是结构化与图谱这一族做法。

纯向量检索

把文本切块后比语义相似度，擅长「哪段话在讲这个意思」

图谱检索

先抽出实体和它们之间的关系，查询时沿着连线走，擅长「谁连着谁、谁影响谁」

结构化检索

把表格、字段、层级关系保留下来按条件筛，擅长「满足条件的记录有哪些」

判断要不要上图谱，不看模型多先进，看你的问题里有多少是关系型的。如果用户问的大多是「怎么配置」「这个概念什么意思」，纯向量就够了；如果经常出现「归属」「上下游」「依赖」「变更影响」这类词，说明答案得靠连线拼出来。拿最近一段时间的真实提问过一遍，按关系型和非关系型分个类，比例心里就有数了。想对照不同做法的取舍，可以到 看那页的整理。

另外一个常被忽略的点是：图谱和多模态两条路，前期成本都比纯文本高。图谱要先做实体识别和关系抽取，还要处理同一实体多种叫法；多模态要先搞定表格、扫描件、图表这些非纯文本内容的解析。这两步都是脏活，而且做不好后面全白搭。所以别一上来就选最复杂的方案，先看你的文档本身干不干净。

1. 第一步：把文档进料做干净去页眉页脚、去重复水印、把跨页的表格拼回来、保留标题层级而不是拍平成一整段。验证方式是随手抽几篇，看切出来的块是不是每块都在讲一件事。
2. 第二步：统计关系型问题的占比拉一段真实提问，粗分关系型和非关系型。占比很低就别急着建图谱，先把纯检索的召回质量提上去。
3. 第三步：小范围试抽实体挑一个边界清楚的子集，比如只处理某个产品线的文档，手工核对抽出来的实体和关系准不准。这一步花的时间比想象中多，先有体感再决定要不要全量。
4. 第四步：确认有没有人维护图谱是要养的，实体合并、关系修正、新文档进料都得有人管。如果没人接手，不如不上。

哪些情况不建议走这条路：数据量本来就小、实体关系简单到一张表就能说清、文档更新又特别频繁。这种场景维护图谱的代价大概率超过收益，用关键词加字段过滤反而更稳。反过来，如果关系稳定、文档更新慢、又确实有一批关系型提问，图谱这一族才值得投入。数据量和时效相关的具体数字，以你在 和自己业务侧统计到的为准。

先问清楚问题是查内容还是查关系，再决定要不要建图；顺序反了，钱和人力都白花。

选型对照表：按数据与负载对号入座

把 RAG 当成一个筐，往里塞什么方案，取决于你手里是什么数据、卡的是什么指标。下面这张对照表按四个维度来筛：数据形态、延迟要求、并发预算、团队能力。先对号入座，再决定链路长短，能省掉很多返工。

数据形态优先

解析没做干净之前，检索和生成怎么调都白费，垃圾进垃圾出在这里最明显。

延迟倒推链路

交互式问答要的是首字快，链路越短越好；后台批处理、报告生成这类场景，才允许放宽到多轮自省、多路召回投票。

预算看链路长度

链路每多一环，就多一次模型或检索调用，同样并发下占用额度更高。具体数字到 官方价格页（/pricing） 和 额度页（/quota） 按当时口径核对，别拿旧截图做预算。

能力决定步子

没有检索评测能力时，同时推进两条技术路线，最后大概率两条都说不清好坏。

1. 第一步：先给自己的数据分类抽一批真实问题对应的文档片段，看里面纯文本、表格、图片、跨段落关联各占多少。这一步只用一两个小时，但决定了后面要不要补解析、要不要图谱。
2. 第二步：定一条硬指标从延迟、准确率、成本里挑一个当红线，其余先做参考。红线没定，后面所有「哪个方案更好」的讨论都会变成感觉之争。
3. 第三步：只跑通一条链路再谈扩展先把最简单那条链路端到端跑通，并留出固定的评测问题集。确认能稳定复现结果，再考虑加重排、加多轮、加图谱。
4. 第四步：按负载反推方案上限用接近真实的并发压一遍，记录每类请求的调用次数和额度消耗，再回站内页面核对单价。如果成本和延迟都顶不住，先砍链路，不是先换模型。

• 纯文本单库、问题直白：朴素链路通常就够，加复杂度收益递减
• 术语密集、答案要求字面精确：先加重排，比换生成模型更划算
• 表格图表占比较高：把预算花在进料解析和结构化抽取上
• 多跳、关系型问题为主：再评估图谱路线，并接受它更高的维护成本
• 团队没有评测习惯：先建评测集，再谈要不要上第二套检索方案

上线前必做的工程项：超时、降级、日志、评测

RAG 上线前最容易被跳过的一步，是把「检索、重排、生成」当成三个独立服务来管。它们各自会超时、会失败、会拖慢整体，如果只写一个 try 包住整条链路，线上出问题时你连是哪一段卡住都不知道。下面这几项属于不做也能跑、但出了事一定后悔的工程项。

1. 先定总超时，再倒推分段从用户能忍受的等待时间反推总超时，再把额度分给检索、重排、生成。验证方法：故意让某一段慢下来，看整体是否在总超时内返回，而不是继续等。
2. 并发上限按最慢那段定整条链路的吞吐由最慢环节决定。按生成段的并发能力设上限，别按检索段设——检索很快，但请求全堵在生成上，队列只会越堆越长。验证方法：压测时看各段排队时长，最长的那段就是瓶颈。
3. 降级写成显式分支重排失败就跳过重排，多轮检索失败退回单轮，检索整段失败就给兜底话术。验证方法：用开关逐个模拟失败，确认每种情况都有确定输出，而不是抛异常给用户。

• 查询原文：用户到底输入了什么，别只存改写后的版本
• 改写后查询：用来对比改写是否偏离原意
• 召回文档标识：命中了哪些片段，方便回查是不是检索的锅
• 进提示词的片段数：召回多但只塞几条，说明截断策略有问题
• 各段耗时：检索、重排、生成分别花了多久
• token 用量：输入输出各多少，用来判断成本异常

日志字段缺一个，事后复盘就少一块拼图。很多人只记了最终回答，出了问题既不知道召回对不对，也不知道是提示词塞太多还是模型本身在胡说。上面这组字段建议在第一天就定下来，后面加字段的成本远高于一开始就带上。

评测不要等到「有空再做」。固定一批问题加标准答案，检索、重排、提示词、模型任何一环改动都跑一遍，才能知道这次改动是变好还是变差。答得准不准具体怎么度量，可以参考站内的评测思路页面 评测思路（/evaluation）；改完一轮想核对当前各家的价格与能力，到 模型资料库（/models） 看当时的数字就行，别凭记忆拍板。

效果不对时的排查顺序

RAG 效果不对时，最忌讳直接去换模型或重写提示词。真实原因里，生成端的问题占比往往比想象中低，多数坑在召回和排序。下面这个顺序的核心逻辑是：从离用户最近的地方往回查，每一步都能把嫌疑范围缩小一半，避免同时改三处最后不知道是哪处起了作用。

1. 第一步：查召回把真正送进提示词的上下文原文摊开打印出来，逐条看正确内容在不在里面。不在，就别往下看生成，直接往上追切片和向量化：片段是不是被切断了、表格和代码有没有被切碎、嵌入模型对这类文本是否合适。验证方式是拿一条已知答案的问题，人工确认召回的原文里是否包含答案句。
2. 第二步：查排序如果正确内容确实进了候选池，但排在很靠后的位置，问题就在重排或相似度度量上。先看是不是只截取了前若干条导致它被挤掉，再看重排模型是否对这类问法不敏感。验证方式是把候选集完整列出来，标注正确答案所在的位次，看它是「没召回」还是「召回了没排上」。
3. 第三步：查生成上下文里明明有正确答案，模型却答错或答非所问，这时候才轮到生成端。常见原因是提示词没约束好引用范围、上下文太长导致中间信息被忽略、或者模型本身对该领域不熟。验证方式是手动把正确段落单独喂给模型，看它能不能答对；能答对，说明问题在上下文组织而不是模型能力。
4. 第四步：查数据前面三步都正常，就回头查源头。源文档本身可能已经过期、同一内容有多个版本、扫描件结构被破坏、或者重复文档把候选池撑满。验证方式是抽查若干条召回的原文，比对它们的来源、更新时间和彼此是否重复。

• 召回问题看的是「有没有」，不看分数高低；分数只用来比较相对位置。
• 排序问题看的是「位次」，正确内容进没进最终送给模型的那几条。
• 生成问题看的是「给定正确上下文能否答对」，这是分界线。
• 数据问题看的是「源文档是否可信」，前面都正常才查到这里。
• 每一轮只改一处，改完用同一批问题回归一遍，别凭印象说变好了。

这套顺序不适用于一种情况：如果你的问题是首轮就完全没有相关文档被召回，且语料本身覆盖面就很窄，那再怎么调排序和提示词也没用，得先补数据。另外，如果系统刚上线还没建立稳定的评测集，建议先固定一批带标准答案的问题再开始排查，否则每次判断都靠感觉。想对照各类 RAG 架构的差异，可以到站内的模型资料库页面按架构类型筛一遍。