rag 构建最小可行系统

你大概是这样卡住的：手头有一堆文档，想让模型基于它们回答问题，但一搜 RAG 就是向量库、分块、rerank、评测一大堆名词，不知道从哪下手、装哪些东西才算够。这篇不铺原理，只给一条最短路径：最小系统由哪几个零件组成、先用什么跑起来、怎么判断它真的在工作、哪些环节先别碰。目标是当天能问出第一个带出处引用的答案。

你大概是这样卡住的：手头有一堆文档，想让模型基于它们回答问题，但一搜 RAG 就是向量库、分块、rerank、评测一大堆名词，不知道从哪下手、装哪些东西才算够。这篇不铺原理，只给一条最短路径：最小系统由哪几个零件组成、先用什么跑起来、怎么判断它真的在工作、哪些环节先别碰。目标是当天能问出第一个带出处引用的答案。

先说清「最小」的意思：不是能力最强，而是零件最少、每一环都能被你亲手验证。任何在你当前数据量下还看不出差别的组件，都可以先砍掉。等你有了真实问题再回头补，代价比一开始就全套铺开小得多。下面所有做法都基于「纯文本 + 少量文档」这个前提，这个前提不成立时怎么看，最后一节单独说。

最小系统只需要四个零件

把链路拆开，能跑通的 RAG 一共就四个位置。每多一个组件，就多一处可能出错的连接点。新手最容易犯的错不是零件不够，而是在还不确定系统有没有效的时候，先堆了三四个优化组件，结果出问题时不知道是哪一环坏了。

• 进料：把文档切成小段，先只处理纯文本，PDF 和扫描件放后面；
• 向量化：调一个嵌入模型把每段变成向量，先直接用平台默认的模型，不折腾选型；
• 存放与检索：本地一个向量库文件就够，先不引入独立数据库服务；
• 拼装回答：把命中的段落塞进提示词，交给对话模型生成，并要求它标出引用的是哪一段。

从零到第一个答案的操作顺序

顺序很重要：先定验收问题，再动文档，最后才碰模型。反过来做，你会花半天调切分参数，最后发现根本不知道什么叫「答对了」。下面的步骤按这个顺序走，每一步都带了验证动作。

1. 先定问题挑 3 到 5 个你确定答案就在文档里的问题，作为全流程的验收题。验证：这些问题你能自己手写出标准答案，否则后面没法判断生成结果对不对。
2. 切分文档按段落或固定长度切，每段留一点重叠，切完人工翻几条看有没有被拦腰截断。验证：随便抽一条，能独立读懂它在说什么。
3. 逐段入库逐段调嵌入接口拿向量，存进本地库，记录每段对应的原文和来源文件名。验证：用前面某一段的原文去搜，能把它自己排到最前面。
4. 做检索用同一个嵌入模型把问题也转成向量，取相似度最高的前几段，先取 3 到 5 段。验证：拿验收问题跑一遍，看命中的段落里有没有答案。
5. 拼装生成把问题加检索结果拼进提示词，明确要求回答里带上来源标记，不确定就说不确定。验证：回答里的引用能对回原文。

怎么判断它真的在工作

最小系统最容易自欺：模型本来就能答对的问题，你没有检索它也答得出来。所以要设计几个能区分「它在读你的文档」和「它在靠记忆糊弄」的对照实验。这几个实验花不了多少时间，但能省掉后面大量的瞎调参。

• 对照实验：同一问题分别在有检索和无检索两种情况下问一遍，答案明显更具体、且引用了你的文档，才算检索起效；
• 改坏测试：故意把某段文档改掉再问，答案跟着变，说明它确实在读你的资料而不是靠模型记忆；
• 来源核对：生成结果里的引用标记，要能对上原文段落，对不上就是拼装环节出了问题；
• 记录基线：把这几个问题的回答存下来，以后换模型、换切分方式时拿它做前后对比。

改坏一条文档，答案跟着变——这是判断检索链路通没通最便宜的办法。

先别碰的几件事

下面这些不是永远不做，而是当前阶段做了也看不出收益，还平白引入新的调试面。每一项要等到对应的「该上」信号出现再动，不要因为别处文章提到就先装。

什么情况下这套做法不适用

前面整套建议建立在「纯文本、单机、自己一个人测」三个前提上。前提一变，结论就变。下面几条是常见的不适用场景，碰到了就别硬套，直接换方案，否则你会把时间花在给错误架构打补丁上。

• 文档量到一定规模：本地单个向量库文件会变慢，该换成正经的向量数据库服务；
• 多模态资料为主：图表、扫描件占大头时，纯文本切分链路直接用不了，得先做文档解析；
• 要求逐字引用出处：最小系统只能给到段落级来源，做不到字级定位，合规场景要另行设计；
• 多人协作与权限：最小系统没有权限概念，谁能问谁能答需要另做一层控制。

另外，如果模型或中转服务本身不稳定，你排查半天检索，最后发现是接口在掉包，那就白忙。选服务前可以去站内核对各家的实际情况和当时的报价数字，避免把链路问题和供应问题混在一起查。