很多人做 AI 应用时，都会想到一个很常见的方向：

把自己的资料、文档、产品手册或业务知识接入 AI，让它变成一个可以问答的知识库助手。

这个方向看起来很直接。

只要把文档上传进去，然后用户提问，AI 就能根据资料回答问题。

但真正做起来之后，很多人会发现：

• 明明文档里有答案，AI 却说不知道
• 回答看起来很流畅，但内容和资料对不上
• 用户换一种问法，结果就变了
• 文档越多，回答反而越不稳定
• 检索出来的内容不相关，导致模型答偏
• 同一个问题，有时候答对，有时候答错

这也是知识库问答类 AI 应用最常见的问题：

模型不一定是主要瓶颈，检索和上下文才是关键。

本文就从文档切分、向量检索、召回结果、上下文拼接和模型生成几个环节，聊聊为什么 AI 知识库问答总是答不准，以及应该怎么优化。

---

一、知识库问答的基本流程是什么？

常见的 AI 知识库问答，一般会采用 RAG 架构。

RAG 的全称是 Retrieval-Augmented Generation，也就是检索增强生成。

简单理解，就是：

先从知识库里找资料，再让大模型基于资料回答。

一个典型流程如下：

用户提问
  ↓
问题向量化
  ↓
检索相关文档片段
  ↓
拼接上下文
  ↓
调用大模型生成回答
  ↓
返回结果

也就是说，大模型并不是直接“知道”你的内部资料，而是通过检索系统临时把相关内容提供给它。

所以知识库问答的质量，取决于两个部分：

• 检索系统能不能找到真正相关的资料
• 大模型能不能基于这些资料生成准确回答

如果检索阶段就找错了资料，那么后面的模型再强，也很难回答准确。

---

二、为什么“文档里有答案”，AI 还是答不出来？

这是知识库问答里最常见的问题。

很多人会疑惑：

明明答案就在文档里，为什么 AI 没答出来？

原因通常有几个。

1. 文档没有被正确切分

知识库系统通常不会把整篇文档直接塞给模型，而是先把文档切成很多小片段。

如果切分方式不合理，答案可能被拆散。

例如一个完整说明原本是：

API Key 用于身份验证。Base URL 用于指定接口访问地址。模型名称用于指定当前调用的大模型。

如果切分后变成：

片段 1：API Key 用于身份验证。
片段 2：Base URL 用于指定接口访问地址。
片段 3：模型名称用于指定当前调用的大模型。

对于简单问题没问题。

但如果用户问：

API Key、Base URL 和模型名称有什么区别？

系统可能只检索到其中一个片段，导致回答不完整。

2. 用户问题和文档表达不一致

文档里写的是：

接口访问地址

用户问的是：

Base URL 是什么？

如果知识库没有做好语义检索或关键词补充，就可能匹配不到。

这类问题在技术文档、产品说明、企业内部知识库中很常见。

同一个概念，用户可能用不同说法提问。

3. 检索结果不够相关

RAG 的关键是检索。

如果检索出来的是不相关内容，模型就会被错误上下文带偏。

比如用户问：

如何配置模型名称？

但系统检索出来的是：

如何配置用户昵称？
如何设置页面名称？
如何修改项目名称？

这些内容看起来有相似词，但语义并不相关。

模型基于这些内容回答，自然容易偏。

4. 上下文拼接太长

有些系统为了避免漏召回，会一次性塞入很多文档片段。

但上下文太长时，模型可能抓不住重点。

更严重的是，如果里面有互相矛盾或过期的资料，模型可能混合生成错误答案。

所以，知识库问答不是把资料越多塞给模型越好。

关键是：

给模型最相关、最完整、最干净的上下文。

---

三、文档切分为什么这么重要？

文档切分，也叫 chunking。

它决定了知识库的基本颗粒度。

切得太大，会导致每个片段包含很多无关信息，影响检索精准度。

切得太小，又会导致语义不完整，答案被拆散。

常见切分方式有几种。

1. 按固定长度切分

这是最简单的方式。

比如每 500 字切成一段。

优点是实现简单。

缺点是可能把一个完整语义切断。

例如一个操作步骤被切成两段，检索时只召回前半部分，回答就会缺失后续步骤。

2. 按标题结构切分

对于文档、手册、技术说明，更推荐按标题层级切分。

例如：

一级标题
二级标题
正文内容
操作步骤
注意事项

这种方式能更好保留语义结构。

比如“如何配置 API Key”这一节，就应该尽量作为一个完整片段保存。

3. 按语义段落切分

对于长文章、说明文档，可以按自然段落和语义边界切分。

这样更符合人类阅读习惯，也更利于模型理解。

4. 保留适当重叠

有些内容前后段之间有关联。

切分时可以设置一定重叠，比如每个片段之间保留 50 到 100 字交叉内容。

这样可以减少关键信息被切断的问题。

不过重叠也不能太多，否则会增加存储和检索成本。

---

四、检索结果为什么会“不相关”？

很多知识库问答效果差，问题出在检索阶段。

检索不相关，通常有几类原因。

1. 文档质量不高

如果原始文档内容混乱、标题不清晰、概念不统一，检索效果也会受影响。

比如同一个功能，在不同文档里叫法不同：

中转地址
接口地址
Base URL
API 地址
服务端点

用户提问时可能只使用其中一个词。

如果系统没有建立概念映射，就可能漏检索。

2. 查询语句太短

用户提问往往很短，比如：

怎么配置？

这类问题缺少明确对象，检索系统很难判断用户想配置什么。

可以在产品设计上引导用户补充信息，也可以在系统内部做问题改写。

例如把问题改写成：

用户想了解当前页面涉及功能的配置方法。

3. 只依赖向量检索

向量检索擅长语义匹配，但并不总是完美。

在一些技术场景中，关键词非常重要。

比如：

API Key
Base URL
model
temperature
max_tokens

这些词如果被忽略，检索结果可能不准确。

实际工程中，经常会结合：

• 向量检索
• 关键词检索
• BM25
• 标签过滤
• 元数据筛选
• 重排序模型

这类混合检索方式，通常比单一检索更稳定。

---

五、召回数量是不是越多越好？

不是。

很多人会觉得，检索结果多一点更保险。

比如一次召回 10 个、20 个甚至更多片段。

但召回数量太多，会带来几个问题：

• 上下文变长
• Token 成本增加
• 相关信息被无关内容稀释
• 模型更容易引用错误资料
• 回答速度变慢

更合理的做法是控制召回数量，并对结果进行排序。

比如：

先召回 20 个候选片段
再通过重排序筛选出最相关的 3 到 5 个
最后拼接给模型

这比直接把大量片段全部塞给模型更稳。

知识库问答的关键不是“多给资料”，而是“给对资料”。

---

六、上下文拼接也会影响回答质量

检索出相关片段后，还需要把它们拼接成上下文提供给模型。

这一步看起来简单，但也很容易影响最终结果。

常见问题包括：

1. 没有标明资料来源

如果上下文中有多个片段，但没有来源信息，模型可能混合不同内容。

建议为每个片段保留来源，例如：

资料来源：产品配置文档
章节：API 接入说明
内容：……

这样不仅有利于模型理解，也方便后续展示引用来源。

2. 片段顺序混乱

如果步骤类内容顺序错乱，模型生成的回答也可能顺序不对。

例如操作流程应该是：

创建 Key → 配置 Base URL → 选择模型 → 测试调用

如果上下文里顺序混乱，回答也会不稳定。

3. 资料之间存在冲突

企业知识库经常会出现新旧文档并存。

如果旧文档没有下线，检索时可能同时召回新旧规则。

模型看到冲突内容后，可能随机选择一个回答。

所以知识库维护不仅是上传文档，还要定期清理过期内容。

4. 缺少回答约束

即使上下文正确，也需要明确告诉模型：

请只根据提供的资料回答。
如果资料中没有答案，请回答“资料中未提及”。
不要编造不存在的信息。

这类约束可以降低模型幻觉。

---

七、提示词在知识库问答中怎么写？

知识库问答的提示词不应该太随意。

一个比较基础的模板可以是：

你是一个知识库问答助手。
请根据下面提供的资料回答用户问题。

要求：
1. 只使用资料中的信息回答
2. 如果资料中没有明确答案，请说明“资料中未提及”
3. 回答要简洁清晰
4. 如果涉及步骤，请按顺序列出
5. 不要编造资料中没有的信息

资料：
{context}

用户问题：
{question}

如果是技术文档问答，可以补充：

如果涉及配置项，请说明配置项含义、使用位置和注意事项。

如果是客服问答，可以补充：

回答语气要礼貌，避免使用不确定承诺。

如果是企业内部知识库，可以补充：

涉及制度、流程、权限类问题时，必须以资料内容为准。

提示词的目标不是写得很长，而是让模型清楚知道：

• 它应该依据什么回答
• 它不能做什么
• 它应该以什么格式输出

---

八、如何判断知识库问答效果好不好？

不能只靠主观感觉判断。

更好的方式是建立一套测试问题集。

比如整理 50 到 100 个典型问题：

• 高频问题
• 容易答错的问题
• 不同问法的问题
• 跨章节问题
• 无答案问题
• 步骤类问题
• 概念解释类问题

然后观察每个问题的结果：

• 是否检索到正确片段
• 回答是否基于资料
• 是否遗漏关键步骤
• 是否引用过期内容
• 无答案时是否拒绝编造
• 格式是否稳定

这样才能明确问题出在哪一层。

如果检索片段就是错的，应该优化检索。
如果检索片段是对的但回答错了，应该优化提示词或模型。
如果有些问法召回不到，应该优化问题改写和关键词。

---

九、开发时可以记录哪些日志？

知识库问答应用建议记录完整调用链路。

至少包括：

用户问题
问题改写结果
检索关键词
召回片段 ID
召回片段内容
相似度分数
重排序分数
最终上下文
使用模型
提示词版本
模型回答
响应时间
Token 消耗

这些日志对于排查问题非常有用。

比如用户反馈“答错了”，你可以快速判断：

• 是没检索到正确文档
• 是文档本身内容错误
• 是上下文拼接有问题
• 是模型没有遵守资料
• 是提示词约束不够
• 是旧文档干扰了新文档

没有日志，知识库问答优化会非常困难。

---

十、统一接入层在知识库问答中的作用

知识库问答通常不只是一次模型调用。

它可能涉及：

• 问题改写
• 意图识别
• 文档摘要
• 检索结果重排
• 最终答案生成
• 多轮追问处理

不同环节可能适合不同模型。

例如：

问题改写 → 轻量模型
答案生成 → 通用大模型
长文档总结 → 长上下文模型
复杂推理 → 更强推理模型

如果每个环节都单独接入不同模型，配置和管理会变得复杂。

这时候可以考虑通过统一接入层管理模型调用，例如统一 API Key、Base URL、模型名称和日志记录。

在实际场景中，也有一些兼容 OpenAI 接口格式的中转服务形态，例如 transitai.chat 这类平台，可以作为理解统一接入层的参考。这里重点不是介绍具体平台，而是说明：当知识库问答涉及多个模型和多个调用环节时，统一入口有助于降低接入和维护复杂度。

---

十一、一个简单的优化清单

如果你的知识库问答效果不稳定，可以按下面顺序检查：

1. 原始文档是否清晰、准确、没有过期内容
2. 文档切分是否保留完整语义
3. 是否为片段保留标题、来源和元数据
4. 检索是否同时考虑语义和关键词
5. 召回数量是否过多或过少
6. 是否需要重排序提高相关性
7. 上下文拼接是否清晰、有顺序
8. 提示词是否要求只基于资料回答
9. 无答案问题是否能拒绝编造
10. 是否记录了完整调用日志

这个清单看起来比较工程化，但知识库问答本来就不是简单的“上传文档 + 调模型”。

它是一个检索系统和生成系统共同协作的结果。

---

十二、写在最后

AI 知识库问答答不准，很多时候不是因为模型完全不行，而是因为前面的资料处理和检索链路没有做好。

真正影响效果的，往往是这些细节：

• 文档有没有切好
• 检索能不能找对
• 片段是否完整
• 上下文是否干净
• 提示词是否约束清楚
• 日志是否能支持排查
• 模型是否适合当前任务

对于个人开发者来说，知识库问答是理解 RAG 架构的好入口。

对于企业应用来说，知识库问答要想长期稳定运行，就需要把文档治理、检索优化、模型调用和日志分析一起考虑。

大模型负责生成答案，但它回答得准不准，很多时候取决于你给它的资料是否准确、相关、完整。

知识库问答的核心不是“让 AI 什么都知道”，而是让 AI 在正确的资料范围内，给出可靠的回答。