在大模型公司落地中，RAG是解决大模型“知识滞后、凭空幻觉、私有知识空白”的主要方案。相比于微调，RAG低成本、可随时更新知识库、不破坏模型基座能力。是目前私有知识库问答、公司失效、长文档问答断章取义最终导致线上效果差、幻觉频发、答非所问。

很多初学者将RAG理解为“文本切片 + 向量入库 + 相似度检索”的流水线任务，这也是多数Demo级RAG效果拉胯的主要原因。真正可上线的生产级 RAG是一套覆盖「数据预处理 → 切片策略 → 结构化存储 → 检索提高 → 重排序 → 智能纠错 → 迭代闭环」的全链路工程程序。

RAG 调整的经验是：它本质上是数据、切分、索引、召回、重排、上下文、生成、评估共同组成的程序工程，不是单点调参。

一、文档切割：打好 RAG 基础。从根源减少语义丢失

文档切片是 RAG 的第一道工序，也是决定整个程序上限的主要。向量检索的本质是“语义相似度匹配”，如果切片本身语义破碎、逻辑不完整。后续无论多优质的检索或重排序模型，都无法挽回信息缺失的问题。绝大多数 RAG 幻觉，根源并非模型能力不足。而是切片语义不完整、上下文被强行截断。不同切片策略对应完全不同的业务场景，没有万能方案，只有场景适配。

Simple RAG 固定长度切分是入门最常用方案。按照固定字符数暴力切分，优点是实现简单、速度快、资源消耗低，但工程缺陷非常致命：完全不考虑语义边界和段落结构。

• ”时只命中其中一个切片。模型要么回答残缺，要么自行编造规则产生幻觉。
• 适用范围：仅适合极简单的碎片化科普文本，绝不适合公司规范、技术文档或合同手册等严谨文本。

相邻块重叠存储 是固定切分的低成本最优解。主要思路是设置重叠窗口，例如切片长度 1000 字符。重叠 200 字符，让相邻两个切片保留部分重复内容。

• 痛点缓解：产品手册中某功能介绍跨两个切片时重叠区域完美衔接两段内容，避免关键描述被彻底截断。不过，
• 轻量化个人项目、低并发环境或文本结构不规整的通用内容。是 Demo 转小型生产的过渡较好方案。

语义切分 是智能切片的主要方案。不再依赖字符规则，而是调用 LLM 识别文本语义边界，将完整语义单元独立成块。

• 痛点示例：技术博客或 FAQ 合集中的“问题+答案”“观点+论证”往往被字符划分强行拆开。语义切分能够智能识别每条问答或每个知识点。使每个切片都是独立完整的语义单元，从根源降低语义丢失。怎么说呢，
• 无结构化、高自由度文本。是目前通用场景的主流优选。

二、文档存储：精细化封装。提高检索匹配效率

很多开发者只关注“怎么切分”，却忽略了“怎么存储”。存储的信息维度直接决定检索能否精准匹配使用者真实意图. 单纯保存原始文本会导致维度单一、语义稀疏，引发“内容相似但匹配不到”“提问口语化完全失效”等痛点。生产级 RAG 会对原始切片做信息提高和衍生拓展。让每一条向量携带更丰富业务信息，明显提高命中率。

Chunk Header 切片头信息封装

• <强解决方式：
• <强适用场景：

衍生问题集存储

• <强痛点：
• <强解决方式：
• <强收益：

三、检索层调整：多维校准。实现精准高效检索

CUT 和 STORAGE 是 “备料”，而 **检索** 才是 “用料”。基础向量检索只能实现浅层匹配，在面对复杂提问、多轮上下文依赖或专业术语时往往力不从心。生产级 RAG 通过 "上下文提高 → 查询 → 窗口检索 → 压缩重排"

. 上下文提高检索