RAG 实战：给你的私人文档库接上大模型问答

过去一年，我被问得最多的一个工程问题是：”我有一堆内部文档，怎么让大模型基于这些内容来回答，而不是凭空编造？”这个问题的标准答案，就是检索增强生成，也就是大家常说的 RAG。它不是什么高深的前沿论文概念，而是当下把大模型真正落地到企业和个人场景最实用、也最常被用到的一套工程范式。这篇文章，我想从一个一线工程师的视角，把 RAG 到底解决什么问题、怎么从零搭一个能用的系统，讲得明明白白。

为什么需要 RAG：大模型的两个天生短板

直接把大模型当问答引擎用，会撞上两个绕不开的短板。第一是知识截止：模型的训练数据有一个明确的时间点，之后发生的事它不知道，你公司上周才更新的内部制度它更不可能知道。第二是幻觉：面对它没见过的私有知识，模型不会老实说”我不知道”，而是会一本正经地编出一个看起来很像那么回事的答案。

微调是一种解法，但成本高、更新慢，文档一变就得重新训练，显然不适合频繁变动的知识库。RAG 的思路则巧妙得多：它不去改模型本身，而是在提问的时候，先从你的文档库里把最相关的几段内容捞出来，塞进提示词里，让模型”看着资料回答”。这样一来，模型回答的依据是你给的真实材料，既解决了知识新鲜度，又大幅压低了幻觉。本质上，RAG 是把大模型从”闭卷考试”变成了”开卷考试”。

拆解一个最小可用的 RAG 系统

别看 RAG 的概念文章写得花里胡哨，一个能跑起来的最小系统，其实只有四个环节。理解了这四个环节，你就抓住了全部要害。

第一步是切块，也就是 chunking。你得先把整份文档切成一段一段的小文本块。为什么要切？因为模型的上下文窗口再大，也塞不下你整个知识库，而且塞得越多，它越抓不住重点。切块的粒度很关键：切得太大，检索回来的段落里混着无关内容；切得太小，单块又说不清楚一个完整意思。我的经验是，中文文档按 300 到 500 字一块、块与块之间保留一点点重叠，是一个比较稳妥的起点。

第二步是向量化，也就是 embedding。把每一个文本块，通过一个嵌入模型，转成一串数字向量。这个向量的神奇之处在于：语义相近的句子，向量在空间里也挨得近。这样，”怎么报销差旅费”和”出差费用如何走流程”虽然用词不同，但向量会很接近。

第三步是检索。当用户提一个问题，我们把这个问题也转成向量，然后去向量库里找距离最近的那几个文本块——通常取前五到十个，也就是所谓的 top-k。这一步就是”开卷考试”里翻书找相关页的动作。

第四步是生成。把检索到的这几段内容，连同用户的问题，一起拼进提示词，交给大模型，让它基于这些材料组织答案。一个最朴素的提示词大概是这样：”请仅根据下面提供的资料回答用户问题，如果资料里没有相关信息，就明确说不知道。”最后这句”不知道”的兜底，是压制幻觉的关键。

决定效果的，往往是那些细节

我见过太多人搭完上面四步，发现效果稀烂就放弃了。其实 RAG 的好坏，八成藏在细节里。

先说检索质量。光靠向量相似度，经常会漏掉那种”关键词精确匹配”的查询——比如用户直接问一个产品型号，这时候传统的关键词检索反而更准。务实的做法是把向量检索和关键词检索结合起来，也就是所谓的混合检索，两路结果再做融合。更进一步，还可以在粗检索之后加一个”重排序”步骤，用一个更精细的模型对召回的几十个候选块重新打分，只把最相关的几个喂给大模型。这一步往往能带来明显的效果提升。

再说可观测性。RAG 系统上线后，你必须能看到：用户问了什么、系统检索回了哪几段、模型最终答了什么。一旦用户反馈”答得不对”，你才能快速定位是检索没捞到正确段落，还是模型理解错了。没有这层日志，RAG 就是个黑盒，出了问题你根本无从下手。

最后是评测。别凭感觉说”好像变好了”。你应该准备几十上百个标准问答对，每个问题标注好正确答案应该引用哪段文档，然后自动化地跑：检索有没有命中正确段落、答案有没有忠实于材料。把这套评测固定下来，你每次调整切块大小、换嵌入模型、改提示词，都能用数据说话，而不是拍脑袋。

上线前要想清楚的几个坑

除了检索和生成本身，还有几个工程问题，是从” demo “走向”真给人用”绕不开的。其一是文档更新。你的知识库不是一成不变的，新文档进来、旧文档作废，向量库必须能增量更新，否则系统答着答着就过时了。我建议在设计之初就给每个文本块带上来源和时间戳，更新时按来源整体重建，而不是粗暴地全量重来。

其二是权限。很多公司的文档是分权限的，不是所有人都能看所有内容。如果 RAG 不做权限过滤，就可能出现”员工问 A 部门的机密，系统把 B 部门的敏感资料也检索出来喂给了模型”这种事故。把权限校验嵌进检索环节——只在当前用户有权访问的文档范围内做检索——是企业级 RAG 必须跨过的一道坎。

其三是成本。每一次问答都要先做向量检索，再让大模型读完好几段长文本生成答案，token 消耗比普通对话高不少。用户量上来之后，成本会肉眼可见地涨。务实的做法是：对高频、简单的问题，直接做缓存；对明显不需要检索的闲聊，走轻量模型。别让每一句话都走最贵的那条链路。

给想动手的人一点建议

如果你是第一次做，我的建议是别上来就追求完美。先用最朴素的四步搭一个能跑的版本，拿你自己的真实文档去试，亲手感受一下哪里不对。很多人一上来就纠结该选哪个向量数据库、哪个嵌入模型，其实这些都可以后换。先把”切块—检索—生成”这条主链路跑通，让系统真正回答出一两个你关心的问题，那种正反馈会比读十篇教程都管用。

RAG 不是终点，而是一个会随着你业务不断打磨的系统。它的价值，在于把大模型这个通用的”大脑”，和你私有的、不断变化的”知识”连接起来。在我看来，这正是大模型从一个好看的玩具变成真正生产力工具的那座关键桥梁。这座桥怎么修得又稳又好，值得每个做应用的工程师花时间去琢磨。