大模型不缺语言能力，缺的是企业内部的事实。检索增强生成（RAG）的思路很直接：回答之前先去资料里找依据，带着依据再作答。听起来像是加了一个搜索步骤，但真正做过的人都知道，效果差异巨大——同样的模型、同样的文档，换一套处理方式，答案质量可以完全不同。
一、切分：文档粒度决定了召回的上限
检索的单位不是「文件」，而是「片段」。片段切得太大，混入无关内容，生成时容易被干扰；切得太小，上下文被割裂，一段完整的说明被拆成互不相干的半句话。
常见的做法是按结构切，而不是按固定字数切：优先在标题、条目、表格行这些天然边界处分段，再对过长的段落做二次拆分。保留每个片段所属的章节标题，往往能显著提升后续的命中率，因为标题本身就是浓缩的语义信息。
二、召回：语义相似不等于答案相关
向量检索擅长处理表述差异——用户说「报销多久到账」，资料里写「费用结算周期」，两者能对上。但它也有盲区：型号、编号、专有名词这类精确匹配需求，纯语义检索反而容易「跑偏」，找出意思相近但对象错误的内容。
因此在企业场景里，混合检索通常比单一方式更可靠：语义检索负责理解意图，关键词检索负责锁定对象，两路结果合并后再做处理。这样做还有一个好处——专有名词写错的提问，也能被发现并澄清。
三、重排：把最该看的片段放到最前面
召回阶段追求「不漏」，通常会取回偏多的候选片段，顺序未必准确。重排阶段的任务是把真正相关的片段排到前面，并控制进入生成环节的数量。
这一步的价值常常被低估。相关资料是否出现在靠前的位置，会直接影响生成结果；而把明显无关的片段挡在外面，比事后要求模型「不要乱答」有效得多。
四、引用：让答案可以被核对
企业场景里，一个无法核对的答案约等于没有答案。引用机制需要做到三件事：标明答案依据了哪些片段、能够回到原文、并且当资料中没有相关内容时明确说「查不到」，而不是给出一个听起来合理的猜测。
把「拒答」当作一种正确行为来设计，是知识库与通用聊天工具最本质的区别之一。
一个务实的推进顺序
- 先固定一批真实问题作为评测集，用它们来衡量每一次调整，而不是凭感觉判断好坏。
- 再优化切分与召回，这部分收益通常最大，且不依赖模型更换。
- 然后是重排与引用，把准确率和可信度补齐。
- 最后才考虑换更强的模型——它往往是收益最小、成本最高的一步。
检索增强的成败，多数时候不在模型，而在资料被如何组织与取用。
这也解释了为什么知识库项目更接近一项内容工程，而不仅仅是一次技术选型。