为什么大模型需要知识库：从私有资料到 RAG 问答链路

很多人第一次做知识库问答，会先问一个很自然的问题：既然大模型已经会总结、翻译、编写程序、回答常识问题，为什么还要额外接一个知识库？答案其实不复杂。通用大模型的能力来自训练数据，它能学到大量公开文本里的语言规律和常见知识，但它并不会自动知道你公司的制度、产品手册、客服政策、项目文档，也不会天然跟着你今天刚更新的资料一起变化。

相关概念 在前言里提到一个很关键的限制：主流大语言模型主要依赖通用训练数据，无法直接使用用户自身的数据，也无法获得用户最新产生的实时资料。放到业务里，这个限制会立刻变成具体问题。比如用户问“这款产品现在能不能退货”，模型如果只靠通用常识，很容易写出一段像样但不一定准确的回答；而业务真正需要的是它查看当前有效的退货政策，再按资料回答。

所以，知识库不是给模型加一个装饰性的资料夹，而是把回答的依据从“模型记忆”拉回“可管理的业务资料”。资料更新了，知识库可以更新；制度下线了，旧文档可以移出有效范围；答案来自哪一段内容，也能给人工复核留下线索。这就是 RAG 的出发点。它不是让模型变成另一种数据库，而是让模型在回答前先拿到该看的材料。

RAG 的全称是 Retrieval-Augmented Generation，通常译作检索增强生成。把这个词拆开看更容易理解：Retrieval 是检索，先从资料里找到相关概念；Generation 是生成，再让大模型基于这些内容组织答案。也就是说，RAG 不是单纯聊天，它更像一个开卷答题流程：先翻资料，再作答。

相关的“基于文档的问答”章节给了一个典型场景：把公司内部文档、产品说明书等文字资料导入系统，用户围绕这些文档提问时，系统先在文档中检索相关信息，再交给语言模型生成答案。这样模型既能用自己的通用语言能力，也能用外部文档里的专业信息，回答就更贴近具体业务。

这里要特别注意一个边界：RAG 适合处理“答案应该来自资料”的问题，比如制度问答、产品说明、客服知识库、技术文档、合同条款、内部流程。它不适合替代所有业务系统。如果用户问订单状态，应该查订单数据库；如果用户要改地址，应该走业务接口和权限校验。RAG 能解释资料，但不能凭空拥有业务状态。

第一步是文档加载。资料可能来自 资料、CSV、Markdown、网页、Word、客服 FAQ 或内部知识库页面。文中的示例用 CSVLoader 导入户外服装商品数据，每一行被加载成一个文档对象，后面才能被索引和检索。真实应用中，同时要处理页眉页脚、断行、表格错位和扫描件 OCR 等问题，不能把乱文本直接塞进去。

第二步是文档切分。大模型有上下文长度限制，一整本手册或一份长制度不适合直接放进提示词。更稳的做法是按标题、段落和语义边界切成较小片段，让每个片段尽量只讲一个问题，同时保留必要的小标题和上下文。切得太大，检索回来信息混杂；切得太小，模型拿到的内容又可能不完整。

第三步是向量化。文中演示了用 Embedding 模型把文本转成一组数字向量，示例中一个查询文本会得到长度为 1536 的向量。你不需要记住每个数字的含义，只要理解它们是文本语义的一种表示。两个表达方式不同但意思接近的问题，在向量空间里可能距离更近，这就给语义检索提供了基础。

第四步是向量存储。被切分后的文档片段会连同向量一起进入向量库或向量索引。第五步是检索。用户提问后，系统也会把问题转成向量，再从向量库中找出最相近的几个片段。第六步是生成。系统把问题和检索到的片段一起交给模型，让它根据上下文写出答案。

很多 RAG 问答看起来是模型答错了，实际问题出在检索。资料 在调试 RetrievalQA 链时展示了一个细节：打开 debug 后，可以看到用户问题、系统检索到的上下文，以及最终传给模型的完整提示。如果上下文里根本没有正确资料，后面再怎么改回答语气都没有意义。

这也是 RAG 项目最容易被低估的地方。大家常常盯着模型版本、温度参数和提示词模板，却忽略资料本身。标题缺失、重复段落、旧政策未下线、同一问题有多个冲突答案、资料 抽取后断句混乱，都会让检索命中错误片段。模型拿到一堆不相关或互相矛盾的上下文，写得越流畅，误导性反而越强。

一个实用的判断方法是把失败样本拆开看：用户问了什么，系统检索了哪些片段，片段里有没有正确依据，模型有没有按依据回答。如果第一步检索就错了，优先改资料清洗、切分、元数据过滤、召回数量和重排策略；如果检索对了但回答仍不稳，再看提示词、回答格式和模型能力。

初做 RAG，不建议一开始把全公司文档都接进去。资料越多，权限、版本、重复、冲突和评估成本都会上升。更稳的路径是先选一个高频且边界清楚的场景，比如售后政策问答、产品参数查询、内部报销制度、技术文档助手。先把一类问题答准，再逐步扩范围。

落地前要做三件事。第一，整理资料，把 资料、网页和表格尽量转成结构清楚的文本，标题、编号、表格说明要保留。第二，设计测试问题，不只写标准问法，也要写口语化问法、模糊问法、边界问题和资料中没有答案的问题。第三，记录失败样本，把错误分成资料错、检索错、提示词错、权限错、模型生成错，而不是笼统地说“AI 不准”。

后文的评估章节也提醒了这一点：问答系统需要测试集，需要看真实答案、预测答案和评估结果。实际项目不一定一开始就做复杂自动评估，但至少要准备几十个真实问题，每次调整切分、检索参数或提示词后重新跑一遍。RAG 不是一次搭好就结束，它更像一套持续维护的资料系统。

第一版不一定要上复杂架构。你可以先选几十篇高质量资料，清洗成 Markdown 或结构化文本，按标题和段落切分，放进一个简单向量库，再做一个基础检索问答页面。关键不是工具多高级，而是链路完整：资料能更新，片段能追溯，回答能看到依据，失败能定位到环节。

真正可用的知识库问答，至少要有三个约束。第一，模型只能基于检索到的资料回答，不要把常识和猜测包装成业务结论。第二，资料不足时要明确说明没有找到依据。第三，涉及权限的资料要在检索前过滤，不能把不该看的片段交给模型后再指望它保密。

这样看，RAG 的价值并不是把聊天窗口做得更热闹，而是把大模型接到一套可维护的知识流程里。资料负责事实，检索负责找到相关片段，模型负责把片段解释清楚。三者分工清楚，知识库问答才有机会从演示走向真实使用。