企业或者小团队想用AI回答自己资料里的问题，现在主流做法是搭一套检索增强生成，简称RAG。思路不复杂：把文档处理成机器能索引的形式，用户提问时先检索出最相关的几段，再连同问题一起交给大模型，让它基于这些材料作答。很多人搭完之后的感受是，模型明明不差，答案却总是差点意思，说不上错，就是用不上。
这类答非所问，原因经常不在模型身上。检索增强这套流程里，模型只负责最后一步，前面的资料怎么切、怎么存、怎么找，任何一步没做好，最后都会以模型胡说八道的形式表现出来，让人误以为是模型的问题。把责任归到模型上是最省事的解释，也是最容易让人继续用错方向的那种解释。而这几步里，最容易被草草了事、影响又最大的，是切块。
切块就是把长文档拆成一小段一小段，作为检索的基本单位。之所以要拆，一是模型一次能处理的长度有限，二是太长的段落里混着太多主题，检索的精准度会下降。就像把整本书拆成上千张小卡片，用户提问时先去对最相关的几张，再拿这几张去做答。卡片怎么拆，直接决定了后面能不能正好把有用的那张找出来。
最省事的切法是按固定长度切，比如每五百个字一段。简单是简单，问题也很明显：它不管语义，刀落下的地方可能是句子中间，一个完整的操作步骤被劈成两半，前一半和后一半分别进了不同的块里。检索时你只能捞到其中一半，模型拿着半截说明，除了硬猜没有别的办法，答案自然就飘。这种情况在长篇操作文档里特别常见，而操作步骤恰恰最怕被拆散。
更贴合内容的方式是按语义边界切，在段落、小标题、句子之间找断点，尽量让每一块本身是一个完整的意思。这样切出来的块，单独拿出来读也是通的，把它交给模型才可能被正确使用。代价是切块逻辑要按文档结构来写，比固定长度麻烦一些，但这属于资料准备阶段该花的功夫，省不得。
实际中常见的一种折中，是切块时让相邻的块之间留一段重叠。也就是后一块的开头，重复前一块结尾的一小部分。这样做的目的，是减少正好在边界处被切断带来的信息丢失。它不能根治语义被割裂的问题，但能把受影响的概率降下来，算是个成本很低的补偿手段，配置里加个参数就能生效。
切块还牵出一件容易忽略的事：每一块最好带上来源信息。它来自哪份文档、哪一节、哪个版本，这些都存下来，回答时才能把出处指给用户看，出了问题也能回溯。不带元数据的块，检索得再准也无法追责，用户看到一段没有依据的话，信还是不信全凭运气，而这恰好是这类应用最需要避免的状态。
检索这一层也有讲究。基础的向量检索靠语义相似度找块，擅长同义改写，但碰到具体型号、编号这类精确词时可能失灵；传统的关键词检索恰好相反，专治精确匹配，却读不懂换了个说法的问法。所以现在比较成熟的做法的做法，是两种一起用，再把两边找回来的结果合并，取长补短，覆盖住不同的问法。
再往上一层是重排。第一轮检索为了不漏，往往一次捞回十几个候选块，这里面难免有凑数的。重排的作用，就是用一个更精细的模型对这十几个候选重新打分排序，把最相关的几个顶到前面，再交给大模型。一轮快速寻找加一轮精挑细选，兼顾了效率和准确度，这是两级检索比较常见的搭配。
也要接受RAG本身的边界。检索这一步如果没找到相关的块，后面的模型再强也补不回来，它只能拿着不相关的材料勉强作答，或者干脆承认不知道。检索回来的内容如果超过了模型的上下文长度，会被截断。资料更新之后没有重新索引，库里还是旧的，回答自然也是旧的。这些问题都不在模型身上，而在这条流水线的上下游，需要逐段去查。
常有人把它和微调放在一起比。两者的分工其实不同：微调是把知识和行为方式刻进模型的参数里，适合稳定的领域知识和固定的表达习惯；RAG是把外部知识在提问时临时接进来，适合经常变化、需要能查到出处的内容。很多生产系统两个都用，用微调定风格，用RAG补事实，各管各的那一段。
所以搭知识库这件事，把力气花在切块、元数据、检索策略和定期重建索引上，回报通常比反复更换大模型更直接。模型是这条链路的最后一环，它只能对接到手里的那几块材料负责。你前面喂给它的卡片拆得清不清楚，往往在用户开口之前，就已经决定了他会得到一个什么样的答案。
A5创业网 版权所有
