一、为什么需要RAG？
大模型知道的都是公开数据。你问它“CONC1600PP1000C001是什么型号”，它能编出一段，但十有八九是错的。它不知道你们公司的产品叫CONC，不知道PP1是材质，不知道这个配置卖多少钱。想让大模型回答公司内部的问题，就得给它“喂”公司自己的资料——产品手册、报价表、售后记录、老员工的经验。这就是RAG干的事：先检索，再生成。
不是让模型“记住”所有资料（那叫微调），是每次用户提问时，先去资料库里找相关的段落，然后连问题和资料一起交给模型，让它照着资料回答。
二、RAG的五个步骤
第一步：文档切分——把手册拆成AI能吃的块
用户手册是几十页的PDF，不能整个丢给AI，它一次装不下。需要切成小段，每段大概几百个字。我一开始直接按页切，效果很差——一页里可能有三个不相关的知识点，AI检索时全拉进来，回答就乱了。后来我按“章节→段落→句子”三级切：整个手册是书，章节是中块，段落是小块。检索时先找相关章节，再在里面找相关段落，最后定位到具体的句子。切分是RAG的地基，切不好后面全白搭。
第二步：向量化——把文字转成数字
计算机不认识“泵头漏液”，它只认识数字。需要用Embedding模型把文本转成向量（就是一堆数字，代表这段文字的“语义”）。比如“泵头漏液”和“密封圈老化”在语义上相近，它们的向量在空间里就离得近。我用的是阿里云百炼的Embedding API，一次传100条文本，每条返回1536维的向量。注意API限流，初期QPS控制在1-2，不然直接报错。
第三步：向量存储——给知识建个索引
每次检索都重新算太慢，得把向量提前存起来。我用的是ChromaDB，轻量级，本地就能跑。建一个集合（Collection），把每段文本的向量和原文一起存进去。检索时用户问题转成向量，去集合里找最相似的Top-K个结果，再把对应的原文拿出来。
第四步：检索——怎么找到最相关的内容
纯向量检索有个问题：用户问“泵头漏液怎么办”，向量检索能找到“密封圈老化”这种语义相近的内容，但如果用户问“CONC1600”，它就可能翻车——因为“CONC1600”是型号，不是自然语言。我的方案是混合检索：先用关键词匹配（BM25）召回Top50，再用向量检索重排，取Top3给大模型。关键词保证精准匹配，向量保证语义泛化，两套互补。
第五步：生成——让AI照着资料回答
这是用户感知最强的环节。把检索到的3段参考资料和用户问题一起喂给大模型，Prompt里明确写“根据以下参考资料回答，不准瞎编”。实测加了这句话之后，AI的“胡编率”直接降了一半。同时让AI在回答中注明引用来源，比如“根据MTMD操作手册第12页”。用户会自己翻书验证，验证几次发现“AI没骗我”，信任就建起来了。
三、我踩过的坑
坑1：切分粒度太粗
我一开始按页切，结果用户问“齿轮油多久换一次”，AI拉进来一整页，里面既有换油周期，又有安装说明，还有故障代码。AI分不清哪个是重点，回答里参了一堆废话。
坑2：检索结果太单一
只做向量检索，用户输型号就搜不到。只做关键词检索，用户输“泵头漏液”又搜不到。后来用了混合检索，两套互补才稳定。
坑3：AI自己编
没加引用约束之前，AI偶尔会自己编个答案，明明手册里没有，它硬说“根据手册第X页”。加上“不准瞎编”的提示词和“必须带引用”的要求之后，好多了。
四、落地效果
这套知识库用了三周。售后同事问“齿轮油多久换一次”，AI回答“5000小时”，附上第12页截图。问“VAMD怎么安装”，AI列出8条步骤，每条都带页码。现在业务员养成了一个习惯，遇到问题先问AI，查不到再翻手册。我不是在“写代码”，是在“把公司的纸面资产变成数字资产”。
五、下一步
现在只跑了五个系列的手册，还有几十个系列等着切。下一步计划：
补充产品知识库——把选型手册、报价表、售后记录都喂进去
引入混合检索优化准确率
接入大模型做故障诊断（根据现象推荐维修方案）
赵晨，RAG不难，就是一个一个坑填过去。你填完了，你的知识库就能跑了。
