把公司文档“喂”给模型的一周：RAG 没那么玄，但很挑食
“能不能把我们的文档做成一个能问的东西？”
这是一个听起来很简单、做起来很折磨的需求。第一次听到的时候，我脑子里浮现的是那种科幻画面：把文件夹塞进机器，机器吐出智慧。
实际做起来更像：把一堆没有贴标签的杂货，重新摆进超市货架。
第一天：我以为问题是“向量库”，后来发现问题是“文档本身”
最初我兴奋地研究向量库、embedding、chunk size。结果很快撞墙：问同一个问题，答案忽左忽右，像在打太极。
追根究底，是文档里充满了这种句子：
- “如前所述……”
- “见附件（附件丢了）”
- “最新请以群公告为准（公告在哪？）”
模型不是不聪明，它只是拿到了一堆“上下文缺失的碎片”。你给它碎片，它就只能拼碎片。
第二天：清洗比想象中更值钱
我做了三件看起来很无聊的事：
- 把重复、过期、冲突的版本标记出来（至少别混在一起）
- 给每份文档加上最基本的元信息：时间、负责人、适用范围
- 把“口头约定”“临时结论”单独归档，不让它们跟正式规范混在一起
这一天没有写多少代码，但效果立竿见影：检索出来的片段更“像一个完整段落”，而不是断头句。
第三天：切块不是越小越好，像切西瓜
切得太大，模型吃不下；切得太小，味道散了。
我用一个很生活的比喻跟同事解释：切西瓜如果只切成一粒粒西瓜籽，你当然能精确地拿到“某一粒”，但你永远吃不到“西瓜”。
我最后的做法是：
- 按自然段/小标题切，不按固定字数硬切
- 让每块尽量包含“结论 + 条件 + 例外”
- 对“流程类文档”保留步骤的连续性（不要把第 2 步切到别的地方去）
第四天：命名规则像交通标志
我给每条知识都加了一个简单的来源标识：部门/系统/文档名/章节。不是为了炫技，是为了在出错的时候能追溯。
你会发现，当模型回答“根据 XX 文档第 3.2 节……”时，团队的信任感会高很多。就像开车时看到清晰的路牌，你不一定立刻到目的地，但你知道你没有迷路。
第五天：最实用的不是“问答”，而是“反向找资料”
很多人希望知识库是“你问我答”。我反而觉得最实用的是：
我现在要做一件事，你告诉我应该看哪些资料、有哪些坑、有哪些历史决策。
当它能把“要看的 3 篇文档”列出来，而且每篇都对得上时，整个系统就开始变得可靠。
一周后我得到的结论
RAG 没那么玄。它不神秘，也不万能。它像一个认真但嘴笨的资料管理员：你把资料整理好，它就很靠谱；你把资料乱丢，它就会把错误整理得很漂亮。
如果你也要做类似的事，我最想劝的一句是：
别急着调模型参数，先把文档当成产品来做。
文档干净，模型才吃得香。