夜雨聆风导语这篇不空讲概念，直接用“内部接口文档问答”这个真实场景，拆 RAG 为什么经常不好用。重点不是再换一个模型，而是把文档清洗、语义切块、过滤检索、证据回答这四步跑顺。 |
如果你在公司里做过 AI 知识库，应该很容易遇到一种尴尬：演示时效果不错，真正上线后，大家开始反馈回答不稳定、字段经常答错、明明文档里有却没检索出来。
所以这次不讲抽象概念，直接讲一个真实场景：给内部接口文档做问答知识库，为什么很多项目一开始看起来很厉害，上线后却总答不准。
先看真实案例 |
假设你所在团队有几十份内部接口文档，新同事经常问同样的问题，测试、前端、后端都要查字段定义，大家希望做一个“问一句就能答”的知识库。
比如常见问题是：订单确认接口里的 stockLockId 是什么时候返回的？退款申请接口里 refundReasonCode 可选值有哪些？
为什么第一版很容易做成“能答但不稳” |
很多团队会很快做出第一版：把文档全丢进去、切 chunk、建 embedding、检索 topK、把结果拼给大模型回答。链路没有错，但很多项目到这里就停了。
固定切块很容易把字段名、字段解释、返回条件和注意事项切散。于是系统可能检索到了字段定义，却没检索到‘仅在库存预占成功后返回’那一句。
真正的根因通常在文档结构 |
·检索片段缺上下文
·文档里有多个相似字段
·旧版和新版文档混在一起
·回答时没有强制带证据
很多团队把 RAG 理解成‘把文档喂进去，再加一层检索’。但更关键的是：你有没有把文档整理成适合被检索、适合被引用、适合被回答的结构。
一个更靠谱的做法 |
1.先清洗文档，去掉过期版本、重复描述和不完整示例。
2.按语义切块，不按字数乱切。
3.检索时加服务、接口、版本、字段方向等过滤条件。
4.回答时强制带出处，证据不足就明确说明。
如果是接口文档，更适合的粒度通常是：接口基本信息块、请求参数块、响应字段块、错误码块、注意事项块和示例块。
案例里更实用的问答流程 |
输入层先抽取接口名、字段名、请求或响应方向、版本信息；检索层优先查字段块、注意事项块、示例块，并附带服务、接口、版本过滤；回答层按固定格式输出答案、依据和不确定项。
下面这种提示词比一句‘请根据知识库回答’更实用：只根据检索片段回答，不要补充片段之外的推测；先给简洁答案，再列依据片段；如果片段不足以支持结论，直接说‘当前证据不足’；如果存在版本差异，明确指出。
最后一句话 |
RAG 真正好用的地方，不是把文档塞进去就能问，而是把原本散乱、重复、难查的业务资料，整理成可以稳定检索、稳定引用、稳定回答的结构。
先拿一个具体场景跑通：一类文档、一类问题、一套清晰的切块规则、一套带证据的回答格式。先把这一条链路跑顺，知识库才会真的开始有用。
如果你们团队真要做第一个知识库，你最想先拿哪一类文档试点？
