大模型rag实战原理与应用构建

很多人把 RAG 卡在「知道原理但搭不起来」这一步：文档切完不知道合不合适，检索回来接不上提示词，上线后偶发超时和空答案也说不清哪一环坏了。这篇按工程顺序拆一遍，从知识库构建到服务化上线，每步给出可照做的动作和排查顺序，并说明什么情况下这套做法不适用。

RAG 的原理几句话能讲完：把资料切块存进向量库，问题来了先检索相关块，再拼进提示词让模型照着答。难点从来不在原理，而在工程链路上——切多大切多小、召回几条、超时设几秒、答不上来怎么办。任何一环没想清楚，上线后就是偶发空答案和莫名超时。

这篇按工程顺序从进料走到上线，每一步给出可照做的动作和排查顺序。要注意的是，这套流程适合「答案基本写在文档里」的场景；如果你的问题需要跨十几个文档做多步推理，或者资料本身在快速变化，下面的做法要按节末说的方式调整。

进料与切分：决定后面能不能检索到

这一步做砸了，后面怎么调提示词都救不回来。核心原则是：切之前先洗，切的时候保证「一个问题能被完整回答」，切完带上元数据。很多人跳过清洗直接切 PDF，结果每块都夹着页眉页脚和目录残渣，检索命中率自然难看。

清洗文档把页眉页脚、页码、目录、水印、乱码去掉。扫描件先走 OCR，表格类资料单独处理，不要和正文混在一个流程里。验证方式：随机抽几页输出纯文本，肉眼扫一遍有没有噪声。
确定切分粒度段落优先、句子保底，块与块之间留少量重叠，避免答案正好被切断。判断标准是拿一个典型问题去问：这一块单独拿出来能不能回答它。不能就说明切得太碎或太大。
补齐元数据每块除了正文，至少带上来源文件名、标题路径、更新时间。后面做过滤、展示引用、判断资料新旧全靠它。缺了元数据的块，等于无法追溯。
小规模试检索入库前抽十几条真实问题跑一遍，看命中的块是不是你想给的那几块。切得不对在这步就能发现，别等全量灌完再返工，那时候改切分策略等于重来一遍。

检索不是「向量搜一下就完事」。纯向量对编号、专有名词、型号这类精确匹配容易漏，常见做法是向量召回拿候选，再用关键词或重排模型做二次筛选。拼提示词时顺序也有讲究：资料在前、问题在后，并明确要求它只依据资料回答。

本地跑通和上线服务是两回事。上线后最常见的问题是偶发超时和整条链路一起挂。解决办法是把检索和生成拆开设超时、限制并发、准备降级路径，并把关键日志记全。没有日志，出了问题只能靠猜。

# 排查顺序：先看哪一段超时，再决定改什么
1. 看日志里的耗时分解，区分检索耗时和生成耗时
2. 检索超时 → 查索引、网络、数据库连接
3. 生成超时 → 查接口额度、并发、是否触发限流
4. 两者都正常但偶发失败 → 查重试逻辑和降级开关是否生效

没有评测的调优就是玄学。你需要一组固定的问题集，每次改动前后都跑一遍对比。更关键的是把检索命中率和回答质量分开看：答错可能是没检索到，也可能是检索到了但模型没用上，这两者的修法完全不同。

知识库文档量不大，还需要向量检索吗？

几十篇以内的稳定资料，直接把全文塞进上下文加上关键词过滤往往更省事，效果也不差。只有当资料量让上下文装不下、或者更新频繁需要局部替换时，向量检索的收益才明显。判断标准是装不装得下，不是资料多高级。

检索明明命中了，模型还是答错，问题出在哪？

先看拼进去的资料是不是被截断或排序靠后被模型忽略，再看提示词有没有明确约束「只依据资料」。还有一种常见情况是命中的块本身不完整，答案被切成了两半，这属于切分环节的问题，要从进料那步回头查。

RAG 上线后需要一直维护吗？

需要，但维护量取决于资料变更频率。资料基本不动的场景，主要工作是定期看漏答样本；资料天天更新的场景，要保证增量入库和旧块失效能自动跑通，否则模型会拿着过期内容一本正经地答。