RAG流程优化：三大层面策略

30 秒回答

1. 检索层面：索引优化、查询改写、混合检索、重排序
2. 生成层面：上下文压缩、提示工程、引用溯源
3. 流程层面：多轮检索、自适应RAG、评估反馈闭环
4. 能结合实际场景说明取舍

回答与解析

答案要点

• 检索层面：索引优化、查询改写、混合检索、重排序
• 生成层面：上下文压缩、提示工程、引用溯源
• 流程层面：多轮检索、自适应RAG、评估反馈闭环
• 能结合实际场景说明取舍

一、检索层优化

索引构建

• 分块策略：按语义/结构分块（标题-内容、固定长度+重叠），非均匀分块优于固定长度
• 多向量表示：同一文档用摘要、关键词、问题等多角度embedding
• 元数据过滤：时间、来源、类别等字段预过滤缩小检索范围

查询侧优化

• 查询改写：HyDE（生成假设文档再检索）、Query2Doc、子查询分解
• 查询扩展：同义词、相关术语扩展召回
• 意图识别：区分事实查询/摘要/对比类问题，路由到不同索引

检索策略

• 混合检索：向量相似度 + BM25关键词，RRF融合排序
• 重排序（Rerank）：Cross-encoder精排，如bge-reranker，Top-K从100→20
• 多路召回：向量库+图谱+传统数据库并行检索

二、生成层优化

上下文处理

• 上下文压缩：LLM摘要过滤冗余，或训练专用压缩模型
• 引用溯源：要求模型标注答案来源，便于事实核查
• 动态截断：按相关性分数加权拼接，非简单Top-K截断

提示工程

• 角色设定：明确"基于提供的参考资料回答，不知道则说不知道"
• Few-shot示例：展示引用格式和拒答样例
• 思维链：先让模型分析哪些文档相关，再生成答案

三、流程层优化

自适应RAG

• 检索判断：LLM先判断是否需要检索（Self-RAG风格）
• 迭代检索：生成中发现信息不足，主动发起二次检索
• 多跳推理：复杂问题拆解子查询，链式检索

系统级

• 缓存机制：高频查询结果缓存，embedding结果缓存
• 反馈闭环：用户点赞/点踩数据回流，微调embedding或重排序模型
• 离线评估：定期用标准问答集测试召回率、答案相关性

关键取舍

实际落地建议：先做好分块和重排序这两个高性价比优化，再视情况上自适应流程。

口语版讲法(约4分钟)

• 一句话定位：RAG优化本质是检索与生成的平衡
• 检索层：分块策略、查询改写、混合检索与重排
• 生成层：上下文压缩与提示工程
• 流程层：自适应与迭代检索
• 落地取舍：高性价比优化优先，重排和分块是必选项

这道题其实问的是，怎么让RAG在真实场景下真正好用，不光是跑通流程。核心就一句话：把所有优化手段看成在检索质量和生成质量之间找平衡，而不是单纯堆技术。我分几个层面讲一下。

先说检索层。这里最容易出问题的是分块策略。很多人上来就固定切512个token，但实际效果很差。比如做客服问答，用户问“退款流程”，如果你把整个退款条款切成一个块，那没问题；但如果问“七天无理由退货的运费谁出”，答案可能散落在不同段落里。所以我会按语义结构来分，比如标题-内容层级，或者用滑动窗口加重叠，确保上下文不丢失。更激进的做法是同一份文档用多个向量表示，比如摘要、关键词、模拟问题各存一份embedding，检索时多角度召回。这有个前提：你的文档结构要清晰，否则语义分块也救不了。

再一个就是查询侧的优化。用户query经常很短或者表述模糊，比如“怎么退钱”。这时候我会用HyDE，先生成一个假设文档，再拿它去检索，效果比直接搜query好很多。但HyDE成本高，多一次LLM调用，所以适合query质量差、但延迟要求不高的场景。反过来，如果用户问的是“订单号12345”，那就完全不需要改写，直接精确匹配就行。说白了，查询改写不是无脑上，得看用户意图。

检索策略上，我倾向混合检索，把向量相似度和BM25关键词结合起来。向量擅长语义相似，BM25擅长精确匹配，比如搜“iPhone14”这种产品名，向量可能把“iPhone15”也拉进来，但BM25能精确命中。然后用RRF融合排序，简单有效。重排是性价比很高的优化，用Cross-encoder把Top-100精排到Top-20，延迟增加几十毫秒，但召回质量提升明显。如果你做企业SOP问答，文档噪声大，重排几乎是必选项，否则生成结果很容易被无关段落带偏。

再讲生成层。上下文压缩很重要，因为大模型的输入长度有限，而且噪声会直接导致幻觉。我会让LLM先对检索回来的文档做摘要，过滤掉冗余信息，只保留最相关的段落。或者用专门的压缩模型，比如LlamaIndex里的那种。提示工程上，角色设定要明确，比如“基于提供的参考资料回答，不知道就说不知道”，再加几个few-shot例子，展示正确的引用格式和拒答方式。这样能有效降低幻觉。

流程层，我比较关注自适应RAG。不是所有问题都需要检索，比如问“今天天气怎么样”，你直接让LLM回答就好，不需要去知识库里翻。所以我会用Self-RAG让模型先判断是否需要检索，如果需要，再根据生成过程中的信息缺口主动发起二次检索。这特别适合多跳推理问题，比如“苹果公司2023年的营收是多少？和2022年比增长了多少？”这种问题需要先搜2023年营收，再搜2022年营收，然后对比。如果一次检索就生成，大概率会编造数据。

说到自适应，有个点值得注意：多轮检索虽然能提升复杂问题的准确性，但延迟会翻倍甚至更多。如果业务对延迟敏感，比如实时客服，你可能得权衡，或者用缓存机制来缓解。

最后说落地取舍。我的经验是，先做好分块和重排这两个高性价比优化，它们能解决大部分质量问题。HyDE和多轮检索是锦上添花，成本高，只在特定场景下用。微调embedding成本最高，除非领域术语特别特殊，否则不优先考虑。整体上，我会把RAG优化看成一个渐进迭代的过程，上线后收集用户反馈，形成闭环，不断调优。

关键一句:多轮检索虽然提升准确性，但延迟翻倍，需要根据业务场景权衡。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做订单客服系统，用户问“我的订单什么时候发货”，你从知识库检索了物流规则和订单状态，但生成的回答还是不够准。你觉得RAG流程里哪些环节可以优化？比如检索、生成、或者整个流程设计上。

2. 问法 2 · 层层追问

   你做过RAG系统吧，检索召回这一块一般怎么搞？……那如果用户问的问题比较模糊，比如“怎么退换货”，你怎么让检索更准？……再进一步，生成的时候怎么确保答案不胡编乱造，又能利用好上下文？……整体流程上还有什么可以调优的？

3. 问法 3 · 直球架构

   请系统性地讲一下RAG流程的优化手段，包括检索层（索引、查询、重排序）、生成层（上下文压缩、提示工程）、以及流程层（自适应检索、多轮检索、反馈闭环），并说明哪些场景下你会优先选哪些优化。