RAG 是什么：它适合解决哪些知识库问答问题

很多人第一次听到 RAG，会把它理解成一种更高级的大模型。更准确地说，RAG 是一种应用架构，中文常叫检索增强生成。它的核心思路很朴素：用户提问后，系统先从你的资料库里找出相关内容，再把这些内容连同问题一起交给大模型，让模型基于资料回答。

为什么需要这一步？因为通用大模型并不知道你公司的内部制度、产品最新价格、客服话术、项目文档和私有知识。即使模型知道一些公开常识，也可能过时或不符合你的业务口径。RAG 的价值，是把回答建立在可控资料上，而不是完全依赖模型记忆。

比如用户问某个套餐是否支持退款，如果你直接问模型，它可能根据常识编一个答案；如果用 RAG，系统会先找到退款规则、套餐说明、售后政策，再让模型根据这些资料回答。这样回答更可追溯，也更容易更新。资料变了，重新整理知识库即可，不一定要重新训练模型。

一个典型 RAG 流程包括五步。第一步，准备资料，比如 PDF、Markdown、网页、FAQ、飞书文档、客服话术。第二步，把资料切成较小片段，通常叫 chunk。第三步，把每个片段转成向量并存入向量数据库。第四步，用户提问时，先把问题也转成向量，检索最相关的资料片段。第五步，把检索结果和用户问题一起发给大模型生成回答。

可以把它理解成开卷考试。大模型是答题的人，知识库是参考资料，检索器负责翻到相关页。如果参考资料整理得乱，检索器翻错页，模型再会写也容易答偏。如果资料片段清楚、标题明确、内容干净，模型回答就会稳定很多。

真正落地时，不要只盯着向量数据库和模型参数。很多 RAG 项目效果差，是因为资料本身质量差：标题缺失、段落太长、重复内容多、过期文档没删除、同一问题有多个冲突答案。RAG 不是魔法，它放大的是资料管理能力。

RAG 适合回答基于资料的问题，例如企业制度问答、客服知识库、产品说明、项目文档查询、技术文档助手、合同条款检索、内部流程咨询。共同特点是：答案应该来自已有资料，而且资料会更新。

RAG 也适合降低模型胡编的概率。当回答必须引用公司政策、产品文档或知识库内容时，RAG 比直接聊天更稳。它还能减少人工维护问答对的成本，因为你不必为每个问题手写标准答案，只要资料片段足够清楚，系统就能从资料里组合回答。

但 RAG 不适合所有 AI 需求。如果你要做复杂计算、审批流、下单、查实时库存，单靠 RAG 不够，需要数据库查询、业务接口或工作流。RAG 负责找资料和解释资料，不负责替你执行业务动作。

很多人做 RAG 的第一反应是问用哪个模型、哪个向量库。其实第一阶段更该问：资料是否干净？是否有过期内容？标题是否清楚？一段内容是否只讲一个主题？同一个问题是否有冲突说法？这些问题不解决，换模型也很难有好效果。

建议把资料先整理成结构清晰的 Markdown 或纯文本。每篇文档有标题，每个小节有小标题，段落不要太长。表格、编号和步骤要尽量保留。扫描版 PDF、图片里的文字、排版混乱的网页，都要先转成可读文本再入库。

工具帮的文本清洗、Markdown 工具和关键词工具可以在前期帮你检查资料。比如先清理多余空行、重复段落和乱码，再用关键词工具看看一篇资料的核心词是否集中。资料越像一个人能读懂的文档，RAG 越容易答好。

第一个坑是切片太大。一个片段里混了多个主题，检索回来后模型不知道该用哪部分。第二个坑是切片太小，缺少上下文，模型拿到一句话也答不完整。比较稳的做法是按标题和段落切，保留必要上下文，而不是机械按固定字数切。

第二个坑是没有处理冲突资料。比如旧政策写 7 天退款，新政策写 15 天退款，如果两份都在知识库里，检索可能同时命中，模型就会回答不稳定。知识库必须有版本管理和下线机制。过期资料不处理，RAG 会把旧答案包装得很像真的。

第三个坑是没有评估集。上线前应该准备一批真实问题，覆盖常见问法、模糊问法、边界问题和无法回答的问题。逐条看系统有没有检索到正确资料、回答有没有引用依据、遇到资料不足时会不会承认不知道。没有评估，只凭感觉调参，很容易越调越乱。

第一，选一个范围小但高频的场景，比如售后政策问答，不要一开始把全公司文档都塞进去。第二，整理 20 到 50 篇高质量资料，先保证清楚、准确、不过期。第三，设计 50 个真实问题做测试集。第四，搭建基础检索和回答流程。第五，根据失败案例调整资料切片、标题、召回数量和提示词。

回答里最好带来源，比如根据《退款规则》第 3 节，当前套餐支持 7 天内申请退款。来源能增加信任，也方便人工复核。对于资料里没有答案的问题，系统应该明确说资料中没有找到依据，而不是硬编。

RAG 的成功不是一次上线，而是持续维护。每次业务规则变化，都要更新资料；每次用户问出新问题，都要看是否需要补文档；每次回答错误，都要判断是检索错、资料错、提示词错还是模型理解错。这个闭环比单次搭建更重要。