前段时间有个粉丝面淘天简历上写了RAG项目二面面试官看起来挺感兴趣问了他一个问题“你的RAG系统优化策略是什么”他想了想给出了一个大多数人会给的答案主要是调chunk size切小一点检索就准了。面试官听完沉默了几秒手指敲了敲桌子说“那数据质量呢检索链路呢幻觉控制呢”他有点懵挠挠头说这些……也有做但主要就是调chunk。面试官没有追问只是摇摇头说“你回去再想想。”他回来找我复盘我才告诉他RAG系统优化远不止chunk size这一件事。Demo能跑不等于系统能用这两者之间的距离正好是今天要讲的。1. 第一个模块数据清洗与离线索引在咱们开始讨论任何检索策略之前呢有一件事情是必须得先想明白的。那就是原始数据的质量它实际上就决定了整个系统的能力上限。这话说出来可能听起来有点像套话但是在RAG工程里这真的是用血泪换来的共同认识。你看根据 Databricks 的数据至少有 60% 的 LLM 应用程序已经采用了某种形式的 RAG。但是呢真正能够稳定跑在生产环境里的其实远远没有这个比例。很多问题的根源啊根本就不在模型上也不在检索算法上而是在那一堆没有洗干净的原始文档里面。垃圾进、垃圾出这个道理永远都是成立的。这也是淘天面试官问你的第一个考察点你有没有认真对待数据质量语义分块是数据处理阶段第一个值得咱们认真对待的问题。传统的那种按字符数硬切的方式比如说每段切 500 字这种方法确实是简单粗暴。但是呢它会在句子中间强行断开一个本来完整的逻辑单元就被割成了两半。检索的时候两半都不完整模型自然就会答非所问了。语义分块呢它是依据文本块嵌入向量的语义相似性来对句子进行分组的从而能够生成语义上更加内聚的文本块。而更进一步的智能体分块则是利用 LLM 自身的理解能力根据文本的语义含义和内容结构来动态决定最优的切分点。当然了这种方式也不是没有代价的。动态分块模型虽然能够提升效果但是在生成一致性和计算成本方面都更高一些。在资源有限的场景下它不一定就比结构化分块更合算这个需要根据实际情况来进行权衡。在此基础上呢还有一个更加精妙的设计叫做父子块检索。这个方法是这样的检索的时候用切得很细的子块来精准命中但是喂给模型的时候呢则要上溯到包含这个子块的父块把更加完整的上下文一并送进去。这个思路解决了一个长期存在的矛盾就是小块检索比较准大块上下文比较全而父子结构让两者不再互斥了。延迟分块也就是 Late Chunking也有类似的思路先对整个文档进行嵌入以保留全局上下文然后再分割成块从而减少局部语义损失。这两种路径可以说是殊途同归都是在试图解决分块越细上下文越碎这个根本矛盾。另外一个绕不开的难题是 PDF 表格处理。表格里面那些密密麻麻的数字和行列关系纯文本提取之后几乎就面目全非了向量化之后的检索效果更是惨不忍睹。在实践当中呢解法有两条路一是引入布局分析工具把表格结构转换为 Markdown 格式来保留行列语义二是用模型预先为每张表格生成一段自然语言摘要存入索引让表格内容以模型能够理解的形式来参与检索。后面这种方法虽然离线成本更高一些但是检索时候的准确率往往更有保障。2. 第二个模块检索策略优化数据准备好了用户问题来了检索这一关同样也是不能掉以轻心的。咱们来设想一个典型的场景用户搜索X100 Pro 固件版本纯向量检索给你返回一堆泛泛的手机评测偏偏这个型号的具体信息一条都没有。原因在哪里呢在于向量检索擅长捕捉语义相似度但是对于精确的专有名词、产品编号、版本号这类信息天然就不敏感。它更像一个理解你想要什么的人而不是一个在档案里精确查编号的图书管理员。这也是面试官追问你有没有做混合检索的原因。这正是混合检索出现的理由。除了向量相似性检索之外还要加入关键词检索等多种检索方式根据问题类型自动选择最合适的检索策略。比如说用户问2024年公司的营收是多少关键词检索直接匹配比向量检索更高效准确而如何理解公司的核心价值观这类问题呢则需要语义检索来捕捉深层含义。经典的 BM25 关键词算法和向量检索可以说是各有所长混合使用并通过算法合并排名这几乎是当前生产级 RAG 系统的标配选择了。当用户的提问本身表达含糊或者过于简短的时候呢还有另一种应对手段叫做查询变换。其中最有意思的是假设性文档嵌入也就是 HyDE让模型先根据问题凭空生成一段假答案再拿这个假答案去向量库里检索。听起来可能有点反直觉但是逻辑其实很清晰假答案和真答案在向量空间里的距离远比用户原始问题与答案的距离更近检索精度因此就能够得到显著提升。当然了Query 重写和多次检索都会带来额外的响应延迟首字返回时间也就是 TTFT会明显变慢。在对延迟敏感的场景中呢需要谨慎评估一下是否值得引入。3. 第三个模块重排与上下文压缩很多人在做完检索之后直接把召回的前十条全部塞进提示词。这其实是 RAG 优化里面最容易犯、也最容易被忽视的错误。问题出在哪里呢出在大模型处理长上下文时候的注意力分布上。来自斯坦福和伯克利的研究揭示了一个现象LLM 对提示词开头和结尾的内容会格外倚重而深埋在中间的关键信息则很容易被忽略。这就是所谓的中间迷失现象英文叫 Lost in the Middle。大模型在处理长上下文的时候呈现出U型注意力分布如果相关的文档排在中间或者末尾模型极大概率会直接忽略它们进而产生幻觉。重排序正是为了解决这个问题而生的。初步检索相当于广撒网从大量文档里粗选出候选集重排序呢则是用高精度的 Cross-Encoder 模型对候选集进行精排先粗筛出 100 条再精选出前 5 到 10 条。跟 Embedding 模型不同的是重排序模型以查询和上下文共同作为输入直接输出相似度分数能够更加全面地捕获语义信息。目前可用的选择包括 Cohere 提供的商业 API以及 bge-reranker 系列等开源模型。在 RAG 的众多优化手段里面加入重排序层几乎是投入产出比最高的单一操作了效果往往立竿见影。这也是为什么面试官会问你有没有做重排序——它真的是一个能显著提升效果的环节。上下文压缩则是另一个方向上的配套动作既然模型对冗余信息的消化能力有限那就在送进模型之前把无关的废话先过滤掉只保留真正与问题相关的句子。上下文压缩不仅能降低 Token 消耗从而节省成本还能减少无关噪声对模型生成的干扰让最终答案更加精准。两者配合起来重排序把最好的内容顶到前面压缩把多余的杂音清除掉这才是完整的后处理链路。4. 第四个模块生成与评估最后一环是生成也是最容易出幻觉的地方。对付模型一本正经地脑补这个问题工程层面的应对策略要从提示词设计开始明确写入若上下文中未提及相关内容请直接回答’我不知道’不得推断补充。这类约束看起来简单但是对降低幻觉率的实际效果是相当可观的。更进一步呢要求模型在回答的时候标注引用来源比如这句结论来自文档 A 第三段这样不仅让用户可以溯源核查也在一定程度上约束了模型随意发挥的空间。然而呢光靠主观感受来评判系统好坏是不够的这里就需要 RAGAS 评估框架出场了。RAGAS 通过四个核心指标来衡量系统表现上下文精度、上下文召回、响应相关性和忠实度。用更加直白的话来说呢就是三件事答案是不是根据文档写的检索出来的内容是不是对的以及关键信息有没有被找到。值得一提的是RAGAS 并不是唯一的选择市面上还有 ARES 和 TruLens 等评估工具它们各自的评估维度和自动化程度有所差异在选型的时候可以根据项目需求来对比参考。有一个现实问题是值得我们正视的即便评估指标全部达标幻觉在生产环境中也从未彻底消失。RAGAS 等框架能够告诉你系统在测试集上的表现但是真实用户提问的分布往往比测试集复杂得多。这是所有生产级 RAG 系统目前共同面对的未解难题而不是某个参数调对了就能一劳永逸的事。5. 总结做一个真正能跑在生产环境里的 RAG 系统跟搭一个能跑通的 Demo 之间隔着的不是模型规格而是数据质量、检索链路设计和幻觉控制这三道关卡。精准召回是地基地基不稳的话后面做再多优化都是空中楼阁深度重排是过滤器把真正有价值的内容从噪声中分离出来事实对齐是最后一道防线坚决不让模型用自信的语气说不知道的事来欺骗用户。有一句话是值得反复确认的RAG 的上限不在于模型有多大而在于数据洗得有多干净、检索链路设计得有多精细。模型是可以换的但是数据工程和链路设计的积累换不了。这才是做 RAG 系统真正的护城河也是面试时能够说出我做过、我踩过坑、我用数据证明了效果和我知道这个方法之间最本质的差距。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】