RAG系统从Demo到生产环境的鸿沟，往往在一次不经意的查询中暴露无遗。本文深入探讨了将RAG系统工程化的核心路径，从最容易被忽视的分块策略，到混合检索与重排序的组合拳，再到生产环境的兜底机制，旨在为解决RAG在实际应用中的“幻觉”和失效问题，提供一套体系化的解决方案。
智能速览
多数RAG故障根源在于文档分块方式，而非检索或模型本身。
将分块大小控制在300-500 tokens，并引入重叠，可解决四成检索问题。
混合检索结合语义搜索与BM25，能有效应对术语和自然语言两种查询场景。
引入重排序模块，可将正确答案出现在前三的命中率从68%提升至89%。
生产级RAG必须建立兜底机制，在信息不足时拒绝回答，避免编造事实。
通过建立测试集持续追踪指标，是RAG系统迭代改进的科学路径。
精华内容
要让RAG系统真正可靠，就不能停留在简单的“嵌入、检索、生成”流程。需要一套体系化的工程方法，从数据处理源头开始，层层加固，才能构建出稳定、可信赖的生产级应用。
分块的艺术
RAG的许多问题，如答案矛盾、事实缺失，根源常在于糟糕的分块策略。按固定长度（如500 tokens）简单切分，极易割裂上下文，让问题和答案分属两个不同的区块，导致检索失效。
分块尺寸的拿捏至关重要。100-200 tokens太碎，缺乏语境；1000+ tokens又太长，噪声太多。实践表明，300-500 tokens是一个较为理想的平衡点。
比尺寸更关键的技巧是设置重叠。例如，设定100 token的重叠区，即使一个句子被切断，相邻的两个区块也都会包含其完整内容。这确保了关键信息无论从哪一侧都能被检索到。另一个实用技巧是为每个区块附上来源元数据，如文档日期，便于后续过滤和排序，仅此一步便能解决约40%的检索故障。
混合检索的力量
语义搜索和关键词搜索（如BM25）各有千秋，也各有盲区。语义搜索擅长理解自然语言，但可能召回语义相近却无关的内容，如将“数据留存”和“员工留存”混淆。BM25则能精确命中原文关键词，但对同义词和概念理解能力弱。
将两者结合的混合检索是目前的主流方案。通过一个权重参数Alpha来调和两者的贡献。如果语料包含大量术语，可降低Alpha，让BM25主导；如果用户查询更口语化，则提高Alpha，增强语义搜索权重。
BM25虽然技术老旧，但在兜底方面功不可没，它能确保用户输入的原文表述被精准召回，这是纯向量搜索难以保证的。
精准排序的关键
检索回来的几十个候选区块，哪些才是真正回答问题的？Embedding相似度是独立计算的，而重排序模型则将查询和文档放在一起，判断“这份文档是否在回答这个问题”。
这种Cross-Encoder结构虽然计算量大，不适合做全量检索，但用于对少量候选（如20个）进行精排，其开销完全可以接受。引入重排序后，一个关键指标——“正确答案出现在前三位”的命中率，从68%显著提升到了89%。
需要明确的是，重排序救不了烂检索。如果正确的区块在初始检索阶段就被漏掉了，再强大的排序模型也无能为力。因此，夯实分块和混合检索是前提。
生产环境的兜底
即便前面几步做得再好，生产环境的RAG系统也必然会失败，因为用户总会问文档没覆盖的问题。关键不在于杜绝失败，而在于失败时系统该如何表现。
最佳实践是让模型在信息不足或置信度低时，坦率地回答“不知道”，而不是胡乱编造。Air Canada就曾因聊天机器人虚构退款政策而输掉官司，代价惨痛。
要做到这一点，首先要让失败变得可度量。建立一组包含标准答案的测试查询，每次改动后都跑一遍，追踪检索精度和答案准确率。这样，哪个环节出了问题，能被迅速定位和修复。
迭代的路径
构建一个生产级的RAG系统并非一蹴而就，而是一个循序渐进的迭代过程。不必追求一步到位实现所有层级。
最有效的路径是从最基础的分块开始，部署一个Level 1的系统。然后，通过监控和用户反馈，观察系统在哪些具体问题上翻车。是漏召了关键信息？还是排序不准？或是干脆在胡说八道？
针对暴露出的问题，再决定升级到下一个层级，例如引入混合检索或重排序。这种由问题驱动的演进方式，远比盲目堆砌技术要来得高效和稳固。
构建可靠的RAG系统是一场对细节的极致追求，远不止嵌入和检索那么简单。从巧妙的分块策略到强大的混合检索，再到精准的重排序和最后的安全兜底，每一环都是不可或缺的工程实践。这套方法论的价值在于将模糊的“效果不好”问题，拆解为可度量、可优化的具体步骤。随着技术演进，未来的RAG工程实践还会有哪些新突破？
