搞技术的朋友们好今天聊个面试高频题。你有没有这种经历RAG 系统搭完了知识库也灌进去了结果用户一问问题召回的全是不相关的碎片LLM 拿着这堆废料硬编答案输出质量惨不忍睹。你第一反应是什么换个更好的 Embedding 模型把 chunk 大小从 512 调到 256说实话我以前也这么干。调来调去效果好一点又回落像在黑箱里瞎摸。直到有一次面试被追问你有系统性的优化框架吗我才意识到零散调参是治标真正管用的是把检索通路拆成四层来逐个击破。先说结论RAG 的检索通路可以拆成四个层面每层管一件事索引层管知识怎么存进去查询层管搜索姿势对不对召回层管走几条路去找精排层管最后送进 LLM 的是不是真正有用的内容。单独优化任何一层天花板都很低。线上跑得稳的系统基本是三到四层组合着来。打个比方。你开了家连锁餐厅仓库货架分类合不合理索引、顾客点餐的说法服务员能不能听懂查询、前厅后厨同时从几个渠道找菜召回、最后端上桌的是不是顾客真正想吃的精排——四步任何一步拉胯顾客都要翻脸。下面逐层拆开来讲每层到底解决什么问题、怎么做、为什么需要它。仓库没建好后面全白搭索引层是整条检索管道的地基。道理很简单LLM 只能根据你塞进去的上下文来回答如果检索阶段就没把相关内容捞上来后面生成层做得再花哨也是白搭。地基歪了楼盖得再漂亮也是危房。但索引层真正棘手的问题不是该不该建索引而是一个天然矛盾检索需要小粒度阅读需要大粒度。你可以想象成搬家找东西。箱子贴的标签越细“厨房-调料-花椒”找起来越快但你真用的时候需要的是整个调料盒而不是单颗花椒。检索要精确定位阅读要完整上下文——这俩需求天生打架。小 chunk 语义聚焦向量匹配精度高但送给模型的信息太碎断章取义答不好。大 chunk 上下文完整模型能看懂但向量里混了太多无关语义检索时容易被稀释掉匹配不上用户的问题。两头堵。怎么破核心思路是把搜和读这两件事拆开搜索的时候用精准的小单元去匹配匹配到了再把完整的大段落交给模型阅读。业内管这叫 Small-to-Big落地方式有三种。第一种是父子分块。把文档切成两套一套大约 150 token 的精细颗粒专门建索引一套大约 500 token 的完整段落专门给模型看。精细颗粒负责被搜到搜到以后顺着 parent_id 往上溯源把对应的完整段落一整块喂给 LLM。搜用小的读用大的矛盾化解。第二种是摘要索引。让模型先给每段内容写一份摘要拿摘要去建向量。摘要比原文更凝练、语义更集中在向量空间里跟用户提问的距离天然更短。搜到摘要后回溯取原始段落给模型阅读。第三种更激进——按粒度建三级目录。章节维度、段落维度、句子维度各自建一层。概念性的问题走粗粒度细节性的问题走细粒度系统自动判断该调哪一层。这步配置省了后面调来调去的时间翻三倍。索引是地基地基歪了上面怎么搭都不稳。实际项目里父子分块是投入产出比最高的方案实现简单、效果稳定建议优先上。用户问的不是你存的索引建好了知识存进去了但还有个鸿沟用户的表达方式和知识库里的措辞经常对不上。鸿沟在哪在说法上。这跟去外国餐厅点餐一个道理——你指着菜单说那个红红的辣辣的汤服务员听不懂但你要是说Tom Yum Kung他立刻就明白了。查询优化干的就是这个翻译工作帮用户把大白话转成知识库能听懂的专业说法。来看个场景有人在搜索框里打手机咋截屏啊但你的文档里写的是移动设备屏幕捕获操作步骤。一个大白话、一个书面腔说的是同一件事。你觉得向量模型能处理这种差异短文本下信息量本来就少措辞风格的差异对相似度的影响会被放大命中率比你想象中低得多。查询优化干的事情就是在去知识库搜索之前先帮用户把问题翻译一下让问题和文档在语义维度上靠得更近。Query 改写是最基础的手段。用 LLM 把口语化、指代不清的问题转成正式表达。比如它为什么这么贵里面的它指代不明改写成某款高端手机定价策略分析之后检索命中率立刻上来。多 Query 扩展解决的是另一个问题用户问的角度和文档描述的角度不一样。怎么退货和售后服务申请流程虽然说的是一件事但遣词完全不同。做法是用 LLM 把一个问题扩展成三到五个不同角度的表述每个表述独立去检索结果合并去重。像撒网捕鱼——多甩几条线总有一条钓得上来。但要注意原始问题必须保留在检索列表里改写过程可能丢细节原始表述反而最精准。HyDE思路更野不拿问题去搜文档而是先让 LLM 根据问题虚构一段可能的回答再拿这段虚构内容的向量去检索。虚构回答和文档都是陈述体表达风格接近匹配度天然更高。风险在于如果 LLM 编错了方向检索结果也会跟着偏。知识库领域单一时效果稳领域杂乱时慎用。Step-back Prompting处理的是问题太具体、知识库只存了背景原理的情况。比如有人问attention 计算为什么要做缩放库里可能没这道题的精确解答但有注意力机制数学推导的通用内容。做法是先把具体问题往上抽象一级用抽象版本搜回背景知识再结合背景来回答原始问题。绕了一步命中率反而更高。这四种方法不是互斥的。提问质量差的场景口语多、指代不清建议上 Query 改写 Multi-Query如果知识库结构清晰、用户群体提问比较规范查询层甚至可以跳过。一条路走不通就多开几条查询层从问题这边想办法召回层从检索路径这边想办法。思路变了。向量检索有个根本局限它只擅长语义相似精确词匹配反而弱。用户问M4 Pro 芯片跑分知识库里就是写的M4 Pro向量检索可能把苹果最新处理器的向量拉得更近反而找不到包含M4 Pro这个精确字符串的那条记录。这就像超市收银台——你只开一个通道排队排到天荒地老多开几个通道总有一个能快速结账。关键词检索BM25的盲区恰好反过来它只数词频、不理解语义。怎么退货和申请售后词不重叠BM25 完全召不到。两种路径的盲区刚好互补。这就是多路召回的出发点——同时走多条路各路结果汇总覆盖更多可能性。典型配置是三路并行向量检索负责语义匹配BM25 负责精确关键词命中知识图谱或结构化查询负责实体关系。三路各自捞出一批候选但分数量纲完全不同——向量是余弦值 0 到 1BM25 是 TF-IDF 分数没法直接加权比较。这时候需要 RRF倒数排名融合来做统一裁判。RRF 的逻辑极简不看原始分数只看排名。每一路结果里排名第一的贡献最高分排名越靠后贡献越低。同一个 chunk 在多路里都排名靠前综合分就高。公式是score 求和(1 / (60 rank))。那个 60 是平滑参数给排名靠后的候选留个保底分不至于因为单路的偶然失误就被完全淘汰。所谓多路召回本质上就是别把鸡蛋放一个篮子里——你不知道哪条路能捞到金子那就每条路都派人走一趟。RRF 最大的优点是实现简单、不需要训练、计算量几乎为零。工程落地成本极低但融合效果在大多数场景下足够好是多路召回的标配方案。最后一道门槛经过前面三层优化候选池里可能有二三十个 chunk。但问题来了这些候选里难免混着不太相关的内容。不能全要。全塞给 LLM两个问题。一是 token 消耗暴涨按量计费的话成本飙升二是上下文太长LLM 容易出现中间遗忘——只关注开头和结尾中间的内容被忽略。就像你面前摆了 30 份简历让你挑人全看一遍反而谁也记不住不如先让 HR 筛到 5 份再仔细看。所以需要精排从二三十个候选里挑出最相关的三到五个只把这几个送进 prompt。你可能会问向量检索不是已经排过序了吗为什么还要再排一次关键在于模型结构不同。向量检索用的是 Bi-encoder问题和文档各自独立编码成向量再算余弦距离。快是快但双方是分开理解的词和词之间的细粒度交互看不到判断粗糙。精排用的是 Cross-encoder把问题和文档拼在一起作为整体输入模型可以观察每个词对另一边的影响。判断精度高出一截代价是每个候选都要单独跑一遍速度慢。所以只适合在小候选集上做最后一轮筛选。打个比方Bi-encoder 像只看了两份简历就判断两人适不适合合作Cross-encoder 是把两人关在一个房间里观察他们怎么互动。后者判断当然更准但要花更多时间。流程很清晰多路召回得到候选集 → Cross-encoder 逐一给每对 (问题, 文档段) 打相关度分 → 按分数降序取 top-3 到 top-5 → 拼入 prompt。开源方案里 BGE-Reranker-v2 中英双语效果都不错不想自己部署可以调 Cohere Rerank 或 Jina Reranker 的接口。加了精排之后最终回答质量通常有肉眼可见的提升。真要选一个投入产出比最高的单点优化我会选 Rerank。成本低、接入快、效果直接。实战组合我的选配思路四层全上不现实也没必要。别贪全。根据你的业务场景和当前痛点来选。如果你的知识库文档结构清晰、用户提问比较规范索引层做好父子分块 召回层做多路 精排层加 Rerank这三层组合基本够用。覆盖了大多数场景的检索质量问题。如果你的用户群体提问质量差——口语化严重、指代不清、一句话问好几件事——那查询层必须上至少做 Query 改写有余力再加 Multi-Query。几个经验父子分块是必选项效果稳定、实现简单没有理由不做。多路召回向量 BM25是低成本高收益的标配加一路 BM25 的工程量极小但能覆盖向量检索的精确匹配盲区。Rerank 是提升精度最直接的手段候选集从 30 个缩到 5 个LLM 的回答质量跳一个档次。HyDE 和 Step-back 是锦上添花领域明确、问题类型固定时才值得尝试。盲目上反而可能引入噪声。从另一个角度记住这四层的分工索引层保证存进去的能被找到查询层保证搜索姿势对召回层保证不漏精排层保证送进去的是精华。每层各管一件事组合起来才能把检索质量拉到生产可用的水准。说到底就一句话检索优化不是换个模型调调参数的事是搭系统的事。面试时把这四层的递进关系讲清楚再给出一套你实际用过的组合方案面试官就能看出你是有实战经验的人。学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%免费】