第 10 章：为什么 “把知识塞进 Prompt” 一定会失败？

在真正引入 RAG 之前，我们必须先推翻一个极其常见、也极具诱惑力的想法。

---

10.1 一个看似合理的技术直觉

很多团队在构建企业知识库助手时，都会自然地想到：

既然模型不知道公司内部知识，那我就把文档直接塞进 Prompt。

在 Demo 阶段，这个方法往往“看起来可行”：

• 文档不多（比如只有 10 页产品手册）
• 问题简单（比如 “产品 A 的核心功能是什么”）
• 回答看似准确（模型能从塞进去的文档里找到关键词）

但在真实系统中，这条路几乎必然失败。

关于这个，我们在上下文历史中，同样也提到了这一点，简单的堆砌，必然不会成功

---

10.2 工程约束：为什么这条路走不通？

把知识直接塞进 Prompt，会很快撞上三个硬性约束：

1. 上下文窗口限制：文档规模不可线性扩展

当前主流大模型的上下文窗口是有限的，一次可以塞入的文档必然存在上限

但真实企业的知识库规模往往是：

• 中型企业：数万份文档（产品手册、流程规范、历史会议纪要等）
• 大型企业：数十万甚至数百万份文档（跨部门、跨地区、跨时间维度）

这意味着：当文档数量超过窗口承载能力时，你必须人工筛选 “可能相关” 的内容塞进 Prompt—— 但这本质上是让人类代替系统做 “检索”，完全失去了自动化的意义。

2. 注意力竞争：约束信息与知识信息相互稀释

Prompt 里不仅有知识，还有对模型的行为约束（比如 “用中文回答”“语气正式”“只基于给定信息”）。当知识内容过多时，这些关键约束会被海量知识 “淹没”。

举个例子：

如果 Prompt 里塞了 10 份产品文档（共 3 万 tokens），而行为约束只有 100 tokens，模型对约束的 “注意力占比” 会从 10%（100/1000）降到 0.3%（100/30100）。此时模型很可能 “忘记” 约束，开始基于自身训练数据回答 —— 这正是我们要避免的 “幻觉”。

更危险的是：知识内部也会竞争注意力。

当一份文档里同时包含 “产品 A 的定价” 和 “产品 B 的售后政策”，而用户只问产品 A 时，模型可能被不相关的产品 B 信息干扰，导致回答出错

3. 维护成本爆炸：每次文档更新都意味着 Prompt 重写

企业知识不是静态的：

• 产品迭代会更新功能说明
• 政策调整会修改流程规范
• 员工变动会更新负责人信息

如果知识直接写在 Prompt 里，每次文档更新都需要人工修改 Prompt—— 这在大型企业中几乎不可执行。

想象一下：当某个部门每周更新 20 份文档时，团队需要每天安排专人修改 Prompt，不仅效率极低，还会引入 “漏改”“错改” 的风险。

在企业知识库助手中，这些共同导致一个致命的结果：

知识越多，回答反而越不稳定。

---

10.3 技术决策结论

到这里，我们可以给出一个明确判断：

Prompt 不是知识载体，而是行为约束载体。

当你试图让 Prompt 同时承担这两种职责时，系统一定会在规模上崩溃。

这迫使我们进入下一个问题：

如果知识不能“常驻上下文”，那它应该待在哪里？ 又该如何在需要时精准地 “请” 到上下文里？