一、大模型的三个根本局限
1.1局限一：知识有截止日期
所有大模型都有训练数据截止日期。GPT‑4o 的知识截止在 2024 年初，DeepSeek‑V3 类似。这意味着：
去年下半年新出的法规，模型不知道
最新版本的框架文档，模型不知道
你公司昨天上线的产品，模型不知道
对大多数企业应用来说，“最新”恰恰是最重要的东西。
1.2局限二：不包含私有数据
大模型训练数据来自公开互联网，你的私有数据它完全没有：公司内部产品手册、客户合同、历史工单、内部代码库……你没法把这些数据喂给公有云模型重新训练——成本高，数据安全也过不了。
1.3局限三：幻觉——模型会“编造”答案
这是最麻烦的。大模型不是数据库，它不会说“我不知道”——它会用流畅的语言生成一个听起来合理、但可能是假的答案。
我曾让模型回答一个特定版本的内部 API 文档问题，它给出了一个结构完整、语气自信的错误答案。用户如果没有专业背景，根本看不出来它在胡说。最可怕的不是明显的错，而是“听起来很对”的错。
二、三种解法：RAG、Fine‑tuning、长上下文
面对这三个局限，业界有三种主流解法。选错方向会走很多弯路。
2.1解法一：RAG（检索增强生成）
每次用户提问时，先从知识库里检索相关内容，把内容一起发给模型，让模型基于这些内容回答。
优点：成本低，知识库随时可更新，回答可以追溯来源
缺点：依赖检索质量，检索不准则答案不准
2.2解法二：Fine‑tuning（微调）
用私有数据对模型做二次训练，把知识“烧进”模型参数里。
优点：模型对特定领域更“懂”，语言风格可以定制
缺点：成本高（数百到数千美元），训练耗时，知识更新需要重训，无法追溯来源
我见过不少团队一开始就去搞微调，结果花了大量时间和钱，效果还不如好好调一下 RAG 的检索。
2.3解法三：长上下文（Long Context）
模型的上下文窗口越来越大（Claude 200K Token，Gemini 1M Token），直接把整个文档塞进 Prompt。
优点：操作简单，不需要搭检索系统
缺点：Token 成本高昂（每次都要传完整文档）；有“Lost in the Middle”问题——超长上下文时，模型对中间位置的内容注意力会显著下降；文档超大时仍然放不下
2.4怎么选
私有知识库问答（文档可更新） → RAG（首选） 让模型更懂特定领域的语言风格 → Fine-tuning 文档量小（几十页以内），临时用一次 → 长上下文绝大多数企业知识库场景，RAG 是最合适的起点。
三、RAG 解决什么，不解决什么
很多同学上来就问“RAG 能解决幻觉吗？”
能，但有前提。
RAG 通过把真实文档注入上下文，能显著减少幻觉——模型回答时有了参考资料，不太容易随意编造。但 RAG 不是万能药：
RAG 能解决： 知识截止问题（知识库随时更新） 私有数据问题（自己建知识库） 可追溯性（回答来自哪篇文档，可引用） 幻觉（当检索结果准确时显著减少） RAG 不能解决： 逻辑推理能力（这是模型本身的能力） 知识库里没有的问题（检索不到就没有依据） 检索不准的问题——这恰恰是 RAG 最大的挑战如果文档里没有答案，RAG 也无法凭空生成
如果文档内容本身有错，RAG 会继承错误
如果检索出来的文档与问题不相关，模型反而会被误导，答案比没有知识库还差
RAG 的核心挑战不是“能不能用”，而是“怎么用好”。
四、RAG 的核心挑战：检索质量
我把项目里最常遇到的 RAG 问题列出来：
用户问“退款政策”，检索出来的是“退货流程”
→ 语义相近但不完全一样，向量检索会混淆，需要更精确的检索策略。用户问“V2.3 版本的接口参数”，检索出来的是 V2.1 的文档
→ 没有按版本过滤，Metadata 没用好。知识库里有答案，但就是检索不出来
→ 分块策略有问题，答案被切断在了两个块的边界。检索出来 5 条，有 3 条完全不相关
→ 相似度阈值没设，什么都返回了。模型说“根据文档，答案是……”，但文档里根本没这内容
→ System Prompt 没约束好，模型在混合自有知识瞎编。
这些问题，后面的专题会一一拆解，一一给出解法。
五、学习路径
每个专题都是一个独立的优化点。在自己的项目里先把认知篇和文档处理篇做好，通常已经能解决 80% 的质量问题。
认知篇：理解 RAG 的整体架构、评估指标、常见失败模式
文档处理篇：分块策略、元数据设计、解析与清洗
检索篇：向量检索、混合检索、重排序（Reranker）
生成篇：Prompt 优化、引用溯源、幻觉抑制
工程篇：增量更新、多租户隔离、性能优化
六、小结
RAG 是让大模型落地企业知识库最主流、最实用的方案。但它不是“调几个 API 就能完美工作”的银弹。检索质量决定一切，而检索质量取决于对每个环节的理解和精细调优。
