网上 B 站有很多那种基于 LangChain 或者 LlamaIndex 十分钟搭建 RAG 系统的教程。不少团队看着挺简单照猫画虎也跟着搭了一套。跑测试数据的时候看着还凑合但只要真正接入企业的生产环境让真实的业务人员去用准确率惨不忍睹模型甚至开始一本正经地瞎编乱造。出现这种落差根本原因在于大家搞错了重点RAG 系统的核心壁垒根本不在于你用了多昂贵的大模型而在于你对数据管道Data Pipeline的处理和检索的优化。大模型本质上仅仅是一个做阅读理解的机器如果前面检索系统喂给它的参考资料全是一堆不相关的垃圾它再聪明也给不出正确的答案。最近在业务实际落地中踩了不少坑我总结了几个能把 RAG 的能力实打实拉升起来的方案今天给大家盘一盘。1. 别暴力切分做好语义分块与元数据注入挺多初级的 RAG 项目第一步就死在了长文档比如 PDF、Word处理上。最粗暴的做法就是按固定长度比如 500 个 Token 一刀切开。这种做法用在生产环境真的是灾难。设想有一份财务报表一个表格正好被这一刀从中间切成了两半。表头在上一块具体数据在下一块。当用户提问时单独被检索出来的下半块数据根本没有表头的定义别说大模型看了是一头雾水换我去看也是一样懵逼。生产上比较好的做法是采用结构化感知分块。对于文档必须先用专门的解析工具将其还原为 Markdown 等带有结构化标记的文本。切分的时候要按段落、按标题层级、甚至按完整的表格边界进行切分。此外还有极其重要的一步为切出来的每一个文本块注入上下文元数据Metadata。比如你切出来一段文本是“该设备的维护周期为六个月”。如果只把这句话存进向量库将来检索出来也是毫无意义的因为你根本不知道它说的是哪个设备。必须在构建索引时让这段文本带上它的层级信息{文件:2023维修手册, 章节:发动机保养, 内容:该设备的维护周期为六个月}。这样大模型在回答时手里才有充分的语境。2. 混合检索绝大多数的开源 RAG 默认使用的是单一的稠密向量检索。向量检索擅长处理语义相似度比如你搜“苹果手机”它能给你找出来“iPhone”这没错。但业务线上的很多提问是非常精准且死板的。比如售后人员搜“设备报错 Error-0x9F4A 是什么原因”。这里的Error-0x9F4A是一个极具特征的业务专有名词。如果纯靠向量模型这种无语义的纯字符编号在做 Embedding 之后特征往往会被严重稀释导致底层根本检索不到包含这个报错码的文档。要解决这个问题必须引入传统的关键词检索采用双路召回Hybrid Search。一方面用向量库做语义泛化召回另一方面用 ElasticSearch 或者同类全文引擎做纯文本的精确匹配召回。两路数据拿回来之后再通过 RRF倒数排序融合算法把两份结果交叉打分合并成一份列表。这就彻底兜底了“同义词找不到”和“专业词汇匹配不上”的两个极端。3. 引入重排Rerank检索结果拿回来后怎么给大模型很多团队为了提高命中率会把检索库返回的前 20 个文档全部塞进大模型的 Prompt 里让它去总结。但这会直接触发大模型一个著名的缺陷“迷失在中间Lost in the Middle”。上下文过长且包含大量无关噪音时大模型会遗忘关键信息甚至被错误信息带偏最终产生幻觉。而且超长的输入又会大量消耗 Token推高 API 成本的同时严重拉高响应延迟。标准的工程解决方案是分为两阶段检索Retrieve Rerank。第一阶段粗排利用便宜且快速的向量检索和 BM25粗略地召回 50 篇可能相关的文档。第二阶段精排引入一个专门的 Cross-Encoder 模型也就是重排模型比如 BGE-Reranker。重排模型的底层机制是将“用户提问”和“候选文档”拼在一起同时输入神经网络它对相关性的判断极其精准缺点就是计算耗时。通过重排模型对这 50 篇文档进行精准打分排序最后只挑出得分最高的 3 到 5 篇核心文档喂给大模型。这样既保证了整体速度也降低了大模型的阅读负担。4. 提问预处理Query 重写与扩展回到用户端实际业务里用户提的问题往往是极度口语化且严重缺乏上下文的。比如在一个多轮对话场景中用户第一句先问了“OA系统怎么登录” 紧接着第二句问“密码忘了怎么办”如果 RAG 系统直接拿着“密码忘了怎么办”这几个字去检索文档库召回的结果大概率是各种乱七八糟业务系统的密码找回规则毫无针对性。所以在把问题扔进检索器之前必须增加一个提问预处理层。通常的做法是调用一个轻量级、响应极快的小模型把历史聊天记录和当前提问结合起来重写成一个标准的检索词// 伪代码演示 Query Rewrite 逻辑 String userQuery 密码忘了怎么办; String chatHistory [User: OA系统怎么登录, System: 您可以通过企业微信扫码...]; // 利用小模型进行意图重写 String rewrittenQuery fastLlm.generate( 根据以下聊天历史将用户的最新提问重写为一个具体且独立的查询请求。历史 chatHistory 提问 userQuery ); // rewrittenQuery 此时变成了OA系统密码忘了怎么找回 // 用这个词再去执行底层的混合检索 ListDocument docs retrievalPipeline.search(rewrittenQuery);除了重写还可以顺手做 Query 扩展让模型根据用户的原始提问变异出三四个近义问题用多路查询去并发检索这能极大弥补用户自身表达不准导致的数据遗漏。5. 动态评估传统的 RAG 就是一条单向流水线提问 - 检索 - 生成。只要检索这个环节出了错最后生成的绝对是废话。目前更先进的做法是演进到带有评估反馈逻辑的架构。在这个架构里大模型不仅是文本生成器还充当了业务流的“裁判员”。当底层返回检索结果后先用大模型跑一次轻量级的打分机制评估检索回来的这几篇文档里到底包不包含能回答用户问题的线索如果包含进入生成环节。如果判定所有文档都不相关系统主动放弃基于知识库生成要么老老实实告诉用户“知识库暂无记录”要么触发外接的搜索引擎比如 Bing Search API去公网上找答案。总之决不允许它强行拿着无关文档去编故事。上边这几种能把企业级 RAG 的可用性拉上一个大台阶。希望能帮助到在业务一线折腾落地的大家吧。最后感慨一句这两年 AI 技术更迭太快了真的有点学不动了。不过万变不离其宗底层的工程思维吃透了遇到新东西也就是见招拆招。学习资源推荐如果你想更深入地学习大模型以下是一些非常有价值的学习资源这些资源将帮助你从不同角度学习大模型提升你的实践能力。一、全套AGI大模型学习路线AI大模型时代的学习之旅从基础到前沿掌握人工智能的核心技能​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取二、640套AI大模型报告合集这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示​因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取三、AI大模型经典PDF籍随着人工智能技术的飞速发展AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型如GPT-3、BERT、XLNet等以其强大的语言理解和生成能力正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。因篇幅有限仅展示部分资料需要点击文章最下方名片即可前往获取四、AI大模型商业化落地方案作为普通人入局大模型时代需要持续学习和实践不断提高自己的技能和认知水平同时也需要有责任感和伦理意识为人工智能的健康发展贡献力量。