很多人看完了 RAG 的原理图，动手时却卡在第一步：文档怎么切、向量存哪、检索出来怎么塞进提示词，跑出来答非所问又不知道是哪一环坏了。这篇不铺垫概念，直接按跑通顺序给一套最小流程，每一步说明做什么、做到什么程度算过关、常见错误长什么样，以及哪些场景其实不该用 RAG。
很多人能把 RAG 的原理图讲得头头是道，真动手却卡在第一步：文档怎么切、向量存哪、检索出来的东西怎么塞进提示词。更麻烦的是跑出来答非所问，却不知道是切片的锅还是模型的锅。这篇不铺垫概念，直接按跑通的顺序走一遍最小流程，每一步说清做到什么程度算过关、常见错误长什么样。
先说一个前提：RAG 不是万能药。如果你的知识总共就几页、几个月才更新一次，直接把内容放进提示词往往更省事；只有当资料量大、更新频繁、又需要标注出处时，RAG 的复杂度才划得来。下面这套流程按「先跑通、再调优」的思路组织，第一版别追求效果，先让链路从头到尾通一次。
先跑通最小闭环：四步一条线
把整条链路拆成四段：资料进料、切片、向量化入库、检索拼装后提问。第一版建议只用十几份文档、只覆盖一种问题类型，比如「产品参数查询」或「内部流程问答」。链路通了再加量，不然出问题时变量太多，根本定位不到是哪一环坏了。
- 确定单一问题类型挑一个你熟悉的问答场景，准备好标准答案，后面所有改动都拿它来对比。
- 喂进十几份文档不要一上来就整库导入，文档之间尽量是同一种格式，减少变量。
- 跑通一次检索加提问用同一个问题反复跑，把每次召回的片段记下来，这是后面排错的基线。
- 按顺序定位问题能不能入库 → 能不能召回 → 召回内容对不对 → 回答有没有用，一层层往下查。
进料与切片：效果差八成出在这
效果不好，十次里有八次问题出在进料和切片。扫描件、乱码 PDF、表格错位这些脏数据进了库，后面检索再准也救不回来。清洗这一步不能省：能拿到原始文本就别用转出来的，表格单独处理，页眉页脚批量去掉。
切片长度没有标准答案。从几百字量级起步，按段落语义边界切比按固定字数硬切更稳，因为硬切很容易把一句话劈成两半。具体参数怎么选，可以到 RAG检索到底怎么实现（/guides/rag-retrieval-pipeline） 对照着调。切片太碎会丢上下文，太长会稀释关键信息，两种毛病要在评测里分开看。
- 每段切片保留来源文件名、章节标题等元信息，方便标注出处也方便排查
- 入库前做一遍去重，同一份文档重复进会挤占召回名额
- 切片后抽样读几条，看看有没有被劈断的句子或丢失的表格
- 脏数据处理单独列一个清单，别和正常文档混在一起进库
向量化与存储：选型别一上来就豪华
先确认嵌入模型的语言支持与维度。中文资料用只擅长英文的嵌入模型，召回会明显变差，这个坑很常见。向量库分本地轻量和托管两类，个人验证用轻量方案足够，团队再考虑并发和权限，选型维度可以去 向量数据库目录（/stacks/vector-dbs） 看当时的清单再决定。
| 环节 | 要确认的事 | 不适用的情况 |
|---|---|---|
| 嵌入模型 | 语言支持、维度、能不能换 | 资料以短查询为主时，维度差异影响不大 |
| 向量库 | 本地还是托管、并发、权限 | 单人验证阶段不必上托管方案 |
| 入库方式 | 幂等、去重、元信息保留 | 一次性小批量文档可以省去复杂幂等 |
| 重算成本 | 换嵌入模型要全量重算 | 几乎不可能换模型时可以忽略 |
入库要做幂等：同一份文档重复入库会产生大量近似重复片段，检索时这些片段互相挤占名额，真正有用的反而排不进来。另外要提前想清楚后续会不会换嵌入模型，因为换一次等于全量重算，代价不小。
召回与拼装：把检索结果塞进提示词
召回条数先给一个保守值，宁少勿多。塞太多无关片段，模型反而会抓错重点。提示词里要明确写「只依据给定资料回答，资料里没有就说不知道」，这一句能大幅减少编答案。输出带上引用来源，方便人工核对，也方便判断是召回错了还是模型答错了。
召回不准时，先看命中的片段本身对不对，别急着怀疑模型。如果片段对但回答偏，问题在提示词或模型；如果片段本身就不对，问题在切片或嵌入。想让排序更准，可以参考 RAG里的Rerank（/guides/rag-rerank-guide） 做二次排序，但第一版别急着加，先把基础链路跑稳。
- 召回条数
- 一次塞进提示词的片段数量，先保守，看效果再调
- 引用来源
- 回答里标注来自哪段资料，方便核对也方便排错
- 兜底话术
- 资料里没有就直说不知道，减少编造内容
RAG 的调试顺序是自下而上的：切片对了，召回才有意义；召回对了，提示词才值得调。下一步跑通第一版之后，用站内的评测和价格数据对照当时的方案，看看有没有更省成本或更稳的选型。→
常见问题
完全不懂向量和嵌入，能直接上手 RAG 吗？
可以。你不需要推导公式，只需要知道「把文本变成一串数字，内容相近的数字也相近」。第一版可以直接用现成的嵌入接口和现成的向量库，把精力放在资料整理和切片上，这部分对最终效果的影响远大于数学细节。相关名词卡住了去 AI 术语词典查一下就行。
跑出来的回答还是不对，是模型不行还是检索不行？
先看检索结果。把命中的片段单独打印出来读一遍：如果片段里根本没有答案，那是进料、切片或召回的问题；如果片段里有答案但模型没用好，才是提示词或模型的问题。这个二分能把排查范围砍掉一半，别一上来就换模型。
什么情况下不适合用 RAG？
资料量很少、每次都能整篇塞进上下文时，直接用长上下文更省事；需要模型学会某种固定风格或格式时，提示词或微调比 RAG 合适；要跨多份文档做复杂推理时，单纯检索可能不够，得配合工具调用循环。判断依据可对照 Wiki 知识库和 RAG 知识库的区别那篇看适用场景。
