RAG：把知识库接进对话

RAG（检索增强生成）的流程朴素得惊人： 第一步 检索：用户提问后，先用第十一章的向量（通常加上关键词）检索，从知识库里捞出最相关的几个片段； 第二步 塞入：把这些片段连同问题一起拼进提示词； 第三步 生成：要求模型「仅根据以下资料回答」。 它解决的问题非常明确：让模型在不重新训练的情况下，回答它训练时没见过的私有内容——公司制度、产品手册、法律文书。 它没解决的问题也要说清：资料本身是错的，RAG 会忠实地把错的答给你；检索没捞到的内容，模型要么说不知道，要么开始编。垃圾进，垃圾出。

知识库入库前要把长文档切成小块（chunk），这一步定生死： 切得太碎：一段完整论述被拦腰斩断，检索命中的片段残缺不全，模型只能基于半截话作答； 切得太大：一块里塞进七八个主题，向量坐标被稀释成「平均意思」，什么都像又什么都不像，还挤占上下文窗口。 基本切分原则： 按语义边界切——标题、章节、自然段，而不是机械地每五百字一刀； 相邻块之间保留一小段重叠（比如末尾两句），避免关键句正好骑在切缝上； 表格、代码块、条款尽量保持完整，宁可这一块大一点。 知识库效果不好时，先查切分，再查别的——顺序别搞反。

场景：某公司用 RAG 做了内部 HR 问答助手，员工反馈「问年假制度，回答总是不完整」。 排查第一步——看症状归类： 员工问「年假怎么算」，助手答：「入职满一年可享有年假。」 → 只答了半句，明显「话说一半」→ 症状指向切分环节 排查第二步——查切分： 打开知识库后台，找到「年假」相关的文档块。发现员工手册原文是： 「入职满一年享有 5 天年假；满 5 年享有 10 天；满 10 年享有 15 天。未休年假可折算工资。」 但自动切分把这段话从「满 5 年」处截断，分到了两个块里。 → 确认：切分不当，一段完整的制度被拦腰斩断。 修复动作——调整切分策略： 将员工手册按「章节标题」而非固定字数切分，确保同一制度条款保持完整。 年假那段从 2 块合回 1 块。 修复后效果： 员工问同样的问题，助手完整回答了三档年假天数和折算规则。 总结：没有换模型、没有改提示词、没有重训练——只调了一个切分参数，效果天差地别。这就是「先查切分」的威力。

RAG 答不准时，先看症状再定位环节： 切分坏了的症状：答案总是「话说一半」，引用的片段单看不知所云。——回去修切块策略。 召回坏了的症状：明明库里有人工确认过的答案，系统却答「未提及」，或者干脆编造。——检索没捞到目标片段，查嵌入质量、查询改写、关键词兜底。 重排坏了的症状：该找到的其实找到了，但排在候选末位被淹没，答案质量时好时坏。——加强重排序，或调整候选数量。 养成按症状定位的习惯，能省下大量「整体推倒重建」的无用功。

「要不要微调一个我们自己的模型」是决策会上最贵的问题。一条简单的分流线： 要补知识——让模型知道你的产品参数、制度条文、行业黑话——几乎总是选 RAG。知识常更新、可追溯、上线快、成本低。 要改行为——让输出永远遵循特定格式、口吻、流程——优先考虑提示词工程；提示词撑不住了，才是微调的领地。 微调的真实成本常被低估：高质量训练数据的整理、每次迭代的算力与评估、上线后的持续维护。所以成熟的判断顺序是：提示词 → RAG → 微调，跳级要有明确的理由和数据支撑。