第三篇 RAG检索增强生成专项

第三篇 RAG检索增强生成专项

本篇定位：AI应用开发面试第一核心考点，占比约35%，是初中高级岗必考内容。覆盖从文档处理到答案生成的全链路技术，侧重落地细节、优化方案、问题排查能力。建议作为备考核心优先级，配合项目经验深度掌握。

---

3.1 RAG核心原理与架构演进

核心题1：RAG的核心价值是什么？和模型微调怎么选型？

背诵要点

• 核心价值：给大模型外挂私有知识库，解决模型知识过时、幻觉、无法访问内部数据的问题，实现「基于指定知识回答」
• 三大优势：
  1. 知识更新快，新增文档直接入库，无需重新训练
  2. 可溯源，答案可关联原始文档，可信度高
  3. 成本低，无需标注数据和训练算力，落地周期短

RAG vs 微调选型对比

维度	RAG	微调
核心目标	补充外部知识、解决事实性问题	对齐风格话术、优化领域能力、适配输出格式
知识更新	快，新增文档即时生效	慢，需要重新训练
可解释性	强，支持来源溯源	弱，黑盒不可控
数据要求	无需标注，原始文档即可	需要高质量标注数据
成本	低，检索+调用成本	高，训练算力+数据成本
适用场景	知识库问答、内部资料查询、事实类场景	风格对齐、话术统一、特定能力增强

• 生产级最佳实践：RAG做知识底座 + 轻量微调做风格/格式对齐，两者结合效果最优

核心题2：RAG架构经历了哪几代演进？

背诵要点

1. Naive RAG（初代基础版）

   • 流程：文档切片 → 向量化 → 相似度检索 → 送入LLM生成
   • 问题：分块粗糙、召回不准、排序简单、效果上限低
   • 仅适合Demo、简单小体量知识库

2. Advanced RAG（进阶版，生产主流）

   • 核心优化：查询改写、混合召回、Rerank重排、元数据过滤、分块优化
   • 特点：全链路各环节都有优化手段，效果显著提升
   • 现状：当前绝大多数企业级生产系统的标准架构

3. Modular RAG（模块化版）

   • 特点：全链路模块化，检索、重排、生成等各组件可插拔替换
   • 优势：灵活度高，可按需组合最优方案，适配不同业务场景

4. Agentic RAG（智能进化版，演进方向）

   • 核心：Agent主动控制检索过程，自主判断是否需要检索、检索什么、检索几次
   • 优势：复杂问题推理能力强，可自主补全信息、交叉验证
   • 适合：复杂多跳问题、深度调研类场景

核心题3：端到端RAG系统的完整流程是什么？

背诵要点

分为离线入库 和在线查询两大链路：

离线入库链路（数据准备）

1. 文档采集：对接各类数据源，获取原始文档
2. 文档解析：按格式解析内容，提取文本、表格、图片
3. 文档清洗：去重、去噪、去除页眉页脚等无效内容
4. 语义分块：按语义边界切分成合适大小的Chunk
5. 元数据打标：打上权限、分类、时间、来源等标签
6. 向量化：调用Embedding模型生成向量
7. 索引存储：文本+元数据+向量存入检索引擎

在线查询链路（用户提问）

1. 查询预处理：清洗、归一化、敏感词校验
2. 查询改写：优化为更适合检索的问句，可生成多视角查询
3. 混合召回：关键词召回 + 向量召回，两路结果去重合并
4. 权限过滤：按当前用户权限过滤无权限文档
5. 重排排序：Rerank模型精细化语义排序
6. 上下文构建：取TopN片段，按格式组装成Prompt上下文
7. 大模型生成：LLM基于参考知识生成答案
8. 后置校验：事实一致性校验、合规校验、引用标注
9. 返回结果：返回答案、引用来源、置信度

高频追问

1. RAG一定比直接问大模型效果好吗？

   • 不一定。如果是模型已知的通用常识，直接回答更快更准
   • 如果是私有知识、最新信息、事实性问题，RAG效果远好于纯模型
   • RAG做不好反而会引入错误信息，拖累效果，关键在召回质量

2. 什么场景不适合用RAG？

   • 纯创意写作、开放式创作，不需要事实依据
   • 高度依赖推理、逻辑演绎，不需要外部知识
   • 简单常识类问题，模型本身就能准确回答
   • 要求极致低延迟、对成本极度敏感的简单问答

3. RAG的效果上限由什么决定？

   • 下限由分块和召回决定，召不回一切都白搭
   • 上限由大模型和上下文构建决定，决定了信息整合和生成质量
   • 80%的效果问题都出在召回侧，优化召回性价比最高

---

3.2 文档解析与分块策略

核心题1：不同格式的文档怎么解析？有哪些最佳实践？

背诵要点

按格式走专用解析链路，不做一刀切：

1. Word/PPT类办公文档
   • 工具：python-docx、python-pptx
   • 要点：提取标题层级、段落、表格、图片，保留结构信息，不要扁平化纯文本
2. PDF文档
   • 工具：PyMuPDF、PDFPlumber、布局分析模型
   • 要点：区分页眉页脚、脚注、正文、表格；处理分页断裂问题；复杂版式用布局分析
3. Excel/CSV结构化表格
   • 要点：保留行列结构和表头信息，转Markdown/JSON存储；同时生成文本描述辅助检索
4. 图片/扫描件
   • 工具：OCR识别 + 图片描述生成
   • 要点：图文绑定存储，同时保留文本和图片向量
5. 网页/Markdown
   • 要点：提取正文，去除导航、广告、侧边栏等噪声；保留标题层级

通用原则：解析结果必须保留结构化元数据（标题、章节、页码、来源），不能只存纯文本，元数据是后续优化召回、权限、引用的基础。

核心题2：文档分块有哪些核心原则和常用策略？

背诵要点

三大核心原则

1. 语义完整优先：一个Chunk包含一个完整语义单元，避免把一句话、一个知识点切成两半
2. 大小适配窗口：匹配Embedding模型最优窗口，兼顾召回精度和上下文完整性
3. 上下文信息携带：每个块附带父级标题、所属文档等信息，避免孤立无语境

四种常用分块策略

1. 固定长度分块：按字符数/Token数切割，实现简单，效果最差，仅适合原型
2. 结构化分块：按标题、段落、列表等语义边界切割，是生产首选
3. 语义分块：基于Embedding相似度判断语义边界，自动切割，效果好但成本高
4. 递归分块：先按大结构切，再逐步细化，适合长文档

进阶优化

• 重叠窗口（Overlap）：相邻块重叠10%-20%内容，避免上下文断裂
• 父子分块：父块存完整语义，子块做细粒度召回，召回子块、返回父块上下文

核心题3：父子分块（Parent-Child Chunk）是什么？解决什么问题？

背诵要点

• 背景：块太小缺上下文，块太大引入噪声、召回不准
• 核心思想：两级分块架构
  1. 子块（Child）：细粒度小片段，用于向量检索，保证召回精准度
  2. 父块（Parent）：对应更大范围的完整语义片段，用于生成答案，保证上下文完整性
• 流程：检索时匹配子块 → 找到对应的父块 → 把完整父块送入LLM生成
• 价值：同时兼顾召回精度和上下文完整性，解决「小块缺上下文、大块噪声多」的矛盾
• 适用场景：长文档、知识密度高、对答案完整性要求高的场景

核心题4：表格、图表类特殊内容怎么处理进RAG？

背诵要点

三类处理方案，按复杂度递进：

1. 文本化方案（基础）
   • 表格转Markdown/结构化文本，图表转图片描述
   • 优点：实现简单，兼容现有文本RAG
   • 缺点：复杂表格信息损失大
2. 结构化方案（进阶）
   • 表格保留行列结构，存储为JSON，同时生成自然语言摘要
   • 检索时同时匹配文本摘要和结构化字段
   • 适合：规则明确的数值表格、参数表
3. 多模态方案（高阶）
   • 用多模态Embedding直接对表格、图片向量化
   • 配合多模态大模型直接理解图表内容
   • 适合：复杂图表、示意图、设计稿等视觉内容

高频追问

1. 分块大小怎么选？有没有通用最优值？

   • 没有通用最优值，按内容类型和场景定
   • 参考值：FAQ类200-500字符，制度文档500-1000字符，长文知识1000-2000字符
   • 调优方法：固定其他变量，测试不同分块大小的召回率和答案准确率，找到最优区间
   • 核心判断标准：一个块是否只讲一件事，语义是否完整

2. 分块重叠率设多少合适？

   • 一般10%-20%，块越小重叠比例可以稍高
   • 重叠不是越多越好，过高会导致重复信息多、浪费Token
   • 重点关注章节、知识点边界处的断裂问题，边界处重叠优先

3. PDF分页导致的句子断裂怎么解决？

   • 解析时做跨页拼接，检测页首页尾是否为完整句子
   • 重叠分块天然覆盖部分断裂问题
   • 用布局分析模型识别段落边界，不以物理分页为切割依据

---

3.3 向量检索与混合召回体系

核心题1：Embedding模型怎么选型？维度越高越好吗？

背诵要点

选型核心考量维度

1. 语义效果：同维度下语义相似度准确率
2. 中文适配：对中文语义、行业术语的理解能力
3. 维度大小：影响存储、速度、效果
4. 推理速度：单条和批量的生成耗时
5. 成本：API调用价格或私有化部署成本

维度选择原则

• 不是越高越好。维度越高语义表达能力越强，但存储、检索耗时、成本线性上升
• 存在边际效应，维度高到一定程度后效果提升非常有限
• 通用场景1024维是性价比平衡点；简单任务768维足够；复杂长文本1536维
• 必须和向量数据库的字段维度严格一致，否则无法计算相似度

核心题2：为什么要做混合召回？单靠向量检索不行吗？

背诵要点

纯向量检索有天然短板，纯关键词检索也有局限，两者互补效果最优：

纯关键词检索（BM25）

• 优势：精确匹配强，专有名词、编号、人名命中率高，可解释性强，速度快
• 劣势：语义理解弱，同义词、不同表述匹配不上

纯向量检索

• 优势：语义匹配强，同义词、不同表述能命中，支持模糊语义查询
• 劣势：精确匹配差，专有名词、数字、编号容易漏召，可解释性弱

混合召回（关键词+向量双路）

• 两路召回各自返回TopK结果，去重合并后进入重排
• 同时覆盖精确匹配和语义匹配场景，召回全面性大幅提升
• 是当前生产级RAG的标准架构，比单路召回召回率提升20%-40%

核心题3：查询改写（Query Rewrite）有哪些常用方法？

背诵要点

解决「用户问法和文档表述不一致」导致的漏召问题，分三层实现：

1. 规则层改写（基础必做）

   • 文本归一化：去标点、统一大小写、空格归一、中英文符号统一
   • 口语转书面语：去除语气词、填充词，转为标准书面表达
   • 同义词替换：基于行业同义词典，替换为标准术语
   • 纠错：拼写纠错、口语纠错

2. 模型层改写（进阶优化）

   • 标准问句改写：用大模型把用户口语化问题改写成标准检索问句
   • 多查询生成：一个问题生成3-5个不同视角的检索问句，多路召回合并
   • 假设性文档生成（HyDE）：让模型先生成一个假设的答案文档，再用答案去检索，解决问法和文档表述差异大的问题

3. 语义层扩展

   • 实体链接：识别问题中的实体，关联标准实体和别名
   • 查询扩展：补充相关关键词、上位词、下位词

核心题4：两路召回结果怎么融合？有哪些策略？

背诵要点

按效果从差到好排序：

1. 加权打分融合

   • 给关键词得分和向量得分分别设置权重，相加得到综合分排序
   • 优点：简单易实现
   • 缺点：分数量纲不同，权重难调，鲁棒性差

2. 倒数排位融合（RRF）

   • 核心思想：只关心排名，不关心原始分数，避免分数量纲不一致问题
   • 优点：鲁棒性强，无需调参，多路召回融合的工业界首选

3. 重排融合（效果最优）

   • 两路结果全部去重后，统一送入Rerank模型做语义重排
   • 优点：效果最好，直接用语义相似度排序，解决分数不可比问题
   • 缺点：增加耗时和成本

• 生产最佳实践：RRF做初筛 + Rerank做精排，兼顾效果和成本

高频追问

1. 召回TopK一般设多少合适？

   • 初筛召回：50-100条，保证召回率，宁可多召不要漏召
   • 重排后：取Top5-10条送入上下文，兼顾效果和Token成本
   • 原则：召回阶段保召回，重排阶段保精准，生成阶段控成本

2. 召回率和精确率怎么权衡？

   • 召回阶段优先保召回率，漏召的内容后续再怎么优化都没用
   • 精确率靠后续重排、上下文筛选来提升
   • 业务底线：核心问题必须能召回到，排在后面没关系，不能完全没有

3. 什么是HyDE？适合什么场景？

   • Hypothetical Document Embeddings，假设性文档嵌入
   • 流程：用户提问 → 让模型先生成一个假设的答案文档 → 用这个文档做向量检索
   • 解决：用户问题短、表述和文档差异大，直接检索效果差的问题
   • 适合：长答案、知识类问答场景；简单FAQ、精确查询场景没必要

---

3.4 重排机制与上下文构建

核心题1：Rerank重排的核心价值是什么？

背诵要点

• 定位：召回和生成之间的精排环节，是提升RAG效果性价比最高的手段之一
• 核心价值：
  1. 大幅提升顶部相关性，把最相关的片段排到最前面，优先进入上下文
  2. 统一排序标准，解决多路召回分数不可比的问题
  3. 过滤低相关片段，减少无效信息进入上下文，降低幻觉概率
• 效果收益：通常能让答案准确率提升15%-30%，远高于调Prompt的收益

核心题2：Rerank全链路性能怎么优化？

背诵要点

1. 控制输入规模
   • 只对初筛Top50-100条做重排，不全量排序
   • 先做粗筛过滤掉极低相关的片段，再进重排
2. 模型选型
   • 优先选轻量级CrossEncoder模型，满足绝大多数场景
   • 不用大模型做重排，成本高速度慢，收益低
3. 工程优化
   • 批量计算，单请求多条候选批量输入，充分利用算力
   • 高频相同Query+相同候选集的结果做缓存
4. 降级机制
   • 高并发、系统负载高时，可临时跳过重排，用初筛结果兜底
   • 保证核心可用性优先

核心题3：上下文构建有哪些核心原则？

背诵要点

上下文是连接召回和生成的关键环节，构建质量直接影响最终答案质量，遵循6个原则：

1. 相关性优先：按相似度从高到低排序，最相关的放在最前面
2. 去重降噪：去除高度重复、低相关、无效的片段，控制信息噪声
3. 结构保留：保留原文标题、层级、表格结构，不要纯文本扁平化
4. 边界清晰：用明确分隔符标注每个知识片段，标注来源ID，方便模型引用
5. 长度可控：控制总Token数，不超过模型窗口的安全阈值，预留输出空间
6. 优先级明确：Prompt中明确说明「只基于以下参考知识回答」，划清知识边界

核心题4：上下文太长塞不下怎么办？

背诵要点

四种方案，按效果从优到差：

1. 精简召回结果
   • 减少进入上下文的片段数量，只保留最相关的TopN
   • 对长片段做摘要压缩，提取核心信息，剔除冗余
2. 分层召回+按需扩展
   • 先召回核心片段，信息不足时再二次检索补充
   • 配合Agentic RAG，让模型自主判断是否需要补充信息
3. 长上下文模型
   • 换更大窗口的模型，成本更高，是兜底方案
4. 分段处理+整合
   • 把长上下文拆成多段，分别生成中间结果，最后整合
   • 实现复杂，适合超长文档总结类场景

高频追问

1. 什么时候必须加Rerank？什么时候可以不加？

   • 必须加：生产级系统、知识库体量大、查询复杂、对精度要求高
   • 可不加：简单FAQ、百级以内小知识库、Demo原型、成本极度敏感
   • 经验：千条以上文档的生产系统，Rerank都是标配

2. Rerank和Embedding模型需要同一系列吗？

   • 不需要。两者是独立的，语义空间不同也不影响
   • Rerank是成对计算相似度，和Embedding的向量空间无关
   • 可以分别选各自领域效果最好的模型组合

3. 上下文里的知识片段排序重要吗？为什么？

   • 非常重要。模型对开头和结尾的信息注意力更强，中间信息容易被忽略（Lost in the Middle）
   • 最高相关的放最前面，次相关的放最后，最低相关的放中间
   • 关键信息、强证据放在开头和结尾，能显著提升答案准确率

---

3.5 答案生成与幻觉治理

核心题1：怎么体系化治理大模型幻觉？

背诵要点

幻觉治理不能只靠Prompt，要从「检索→生成→校验」全链路防控：

1. 输入侧（检索层）：减少错误输入

   • 提升召回准确率，保证进入上下文的都是正确、相关的知识
   • 保证数据源本身的质量，定期校验知识库准确性
   • 多路信息交叉验证，单一来源降低置信度

2. 生成侧（模型层）：约束输出边界

   • Prompt强约束：明确要求「只基于参考知识回答，不知道就拒答」
   • 强制引用来源：要求每个关键结论都标注对应引用编号
   • 调低温度参数（0.1-0.3），降低模型创造性
   • 降低模型自由度，用结构化输出、格式约束减少发挥空间

3. 输出侧（校验层）：后置拦截

   • 事实一致性校验：检查答案和上下文是否一致，识别编造内容
   • 置信度打分：综合召回相似度、引用匹配度等计算答案置信度
   • 低置信度自动拒答，不输出给用户
   • 敏感内容、合规内容审核

核心题2：引用溯源功能怎么实现？

背诵要点

全链路四步实现：

1. 入库打标：每个Chunk分配全局唯一ID，关联原始文档信息（标题、页码、章节、链接）
2. 上下文标注：构建上下文时，为每个片段标注编号和来源ID
3. 生成引用：Prompt要求模型回答时，引用对应片段的编号
4. 前端展示 ：答案返回时，解析引用编号，关联回原始文档信息
   • 支持点击引用跳转到原文对应位置
   • 展示来源文档标题、章节、页码

进阶校验：后端做引用一致性校验，答案中声称引用的内容，必须能在对应片段中找到依据，未引用的信息判定为幻觉。

核心题3：拒答机制怎么设计？怎么平衡误拒答和漏拒答？

背诵要点

置信度体系（Answer Guard）

综合多维度信号计算答案置信度，按阈值分层处理：

• 高置信度：正常回答
• 中置信度：回答并标注「信息有限，仅供参考」
• 低置信度：触发拒答，返回「抱歉，知识库中未找到相关信息」

核心判断信号

1. 召回Top1相似度分数
2. Top1与Top2的分差
3. 关键词命中率
4. 实体匹配率
5. 上下文覆盖度
6. 结构化数据是否直接命中

平衡策略

1. 用标注好的测试集绘制准确率-拒答率曲线，找业务接受的平衡点
2. 按场景设定不同阈值：客服场景宁误拒不漏答，避免投诉；内部工具宁漏答不误答，提升效率
3. 拒答话术引导用户换问法，降低误拒的体验影响
4. 收集拒答反馈，持续优化召回和阈值

核心题4：事实一致性校验有哪些实现方式？

背诵要点

按实现成本和准确率从低到高：

1. 规则校验

   • 关键词匹配：检查答案中的关键实体、数字是否在上下文中出现
   • 引用校验：检查标注的引用是否有对应内容支撑
   • 优点：简单快、成本低；缺点：只能查表层，深度幻觉查不出

2. NLI自然语言推理

   • 用自然语言推理模型，判断「答案是否能被上下文蕴含」
   • 输出蕴含、中立、矛盾三类结果，矛盾则判定为幻觉
   • 优点：准确率高于规则，速度比大模型快
   • 缺点：复杂长文本效果有限

3. 大模型校验（LLM-as-Judge）

   • 用更强的大模型做评委，对比答案和上下文，判断是否一致
   • 优点：准确率最高，能识别复杂的隐性幻觉
   • 缺点：成本高、速度慢，有自身偏见

• 生产最佳实践：规则做初筛 + 大模型抽检，兼顾成本和效果

高频追问

1. 调低温度就能消除幻觉吗？

   • 不能。温度低只能减少随机编造，降低概率，不能彻底消除
   • 幻觉的根源包括：召回错误、上下文信息不足、模型本身记忆冲突
   • 温度只是生成侧的手段之一，必须配合全链路治理

2. 幻觉能彻底消除吗？

   • 不能。幻觉是大模型的固有特性，只能降低概率，无法100%消除
   • 工程目标：把幻觉率降到业务可接受的范围内
   • 高风险场景必须加人工校验、溯源机制，不能完全依赖AI

3. 模型越强，幻觉越少吗？

   • 总体上是。强模型事实准确性更高，遵循指令能力更强，更能遵守「只按上下文回答」的约束
   • 但强模型也会产生幻觉，只是概率更低
   • 不能靠换模型解决所有幻觉问题，工程化治理才是核心

---

3.6 企业级权限与多租户隔离

核心题1：企业级RAG怎么做权限隔离？四层防护架构是什么？

背诵要点

权限控制必须在系统层实现，绝对不能只靠Prompt约束，采用四层防护架构：

第一层：入库打标（基础）

• 每个文档、每个Chunk写入时都附带完整权限元数据
• 字段包括：部门ID、业务线、租户ID、角色ACL、用户白名单、安全等级
• 权限标签和数据强绑定，贯穿全链路

第二层：检索强制过滤（核心）

• 用户查询时，自动提取当前用户的权限集合，以Filter参数强制注入检索查询
• 无权限的文档根本不会进入召回池，从源头杜绝超权
• Filter走数据库索引，不影响检索性能
• 这是权限控制的核心防线，必须100%覆盖

第三层：生成前二次校验（兜底）

• 检索结果返回后、送入Prompt前，再做一次权限校验
• 过滤掉权限标签不匹配的片段
• 兜底防止索引异常、权限变更延迟导致的漏网之鱼

第四层：审计溯源（追溯）

• 全链路留痕：记录用户查询、召回片段、最终答案
• 支持安全审计，可回溯所有访问行为
• 答案只允许引用权限内的来源，禁止输出超权内容

核心题2：Filter过滤会影响检索性能和效果吗？

背诵要点

对性能的影响

• 元数据Filter走索引，性能影响很小，几乎可以忽略
• 极端情况：过滤条件非常复杂、过滤后结果极少，可能会增加检索耗时
• 优化：对高频过滤字段建专门索引，提前做数据分区

对效果的影响

• 过滤只剔除无权限数据，不影响有权限数据的排序和相关性
• 不会降低有权限范围内的召回准确率
• 注意：过滤后候选集太小，可能导致召回结果不足，需要做兜底处理

核心题3：多租户用物理隔离还是逻辑隔离？怎么选型？

背诵要点

两种方案对比：

维度	逻辑隔离	物理隔离
实现方式	共用索引/库，加租户ID字段过滤	每个租户独立索引/独立库/独立集群
成本	低，资源利用率高	高，资源独立
隔离性	一般，依赖代码正确过滤	强，数据完全不互通
运维复杂度	低，统一运维	高，多套实例管理
定制化	弱，统一版本	强，可单独配置升级

选型原则

1. 中小租户、通用场景、成本敏感：选逻辑隔离，性价比最高
2. 大客户、数据敏感、合规要求高：选物理隔离，安全优先
3. 混合方案：大客户物理隔离，中小客户逻辑隔离，兼顾成本和安全

高频追问

1. 只靠Prompt做权限限制为什么不行？

   • 大模型存在指令逃逸、Prompt注入风险，可以被绕过
   • 非确定性输出，无法100%保证遵守规则
   • 检索层已经把敏感数据拿到了上下文里，泄露风险已经存在
   • 核心结论：Prompt中的权限指令只能做辅助，绝对不能作为唯一防线

2. 权限变更怎么同步？会有延迟吗？

   • 权限变更后，需要同步更新索引中的权限标签
   • 全量更新有延迟，实时性要求高的可以用二次校验兜底
   • 权限收回场景：先更新检索过滤，再更新索引，保证即时生效
   • 权限放开场景：更新索引后生效，可接受短暂延迟

3. 字段级、行级的细粒度权限怎么实现？

   • 结构化数据：检索时按字段权限返回对应字段，敏感字段不返回
   • 非结构化文档：文档内做分块级权限标记，不同块对应不同权限
   • 生成侧二次校验，敏感信息即使在上下文中，也不允许输出到答案
   • 极端敏感场景：不同权限的文档分不同索引存储

---

3.7 技术选型与底层原理

核心题1：RAG项目选ES还是Milvus？各自适用场景是什么？

背诵要点

企业级RAG是混合检索系统，不是纯向量检索系统，选型看业务场景：

ES（Elasticsearch）

• 核心优势：
  1. 原生支持混合检索：倒排索引关键词检索 + dense_vector向量检索，一次查询完成
  2. 过滤能力强大：权限、时间、类型等多条件筛选，成熟稳定
  3. 可解释性强：能看到命中关键词、各字段得分，调试方便
  4. 基建复用率高：绝大多数企业已有ES运维经验
• 劣势：向量检索性能弱于专业向量库，亿级以上向量规模性能下降
• 适用场景：中小规模（百万-千万级向量）、多条件过滤多、混合检索为主、企业级RAG

Milvus

• 核心优势：
  1. 专业向量数据库，向量检索性能极强，亿级向量仍能保持高吞吐低延迟
  2. 向量索引种类丰富，支持多种量化、索引方案
  3. 云原生架构，弹性扩容能力强
• 劣势：关键词检索、过滤能力弱，需要额外做结果融合
• 适用场景：超大规模向量、纯向量检索为主、对向量性能要求极高的场景

生产高阶方案：双库架构

• ES负责关键词检索、元数据过滤
• Milvus负责向量召回
• 上层做结果融合，兼顾两者优势，适合大规模、高要求的生产系统

核心题2：常见向量数据库有哪些？怎么选型？

背诵要点

四款主流选型对比：

选型	定位	优势	适用场景
Milvus	开源专业向量库	性能强、生态成熟、中文社区活跃	中大规模生产环境、国内生态
Chroma	轻量嵌入式向量库	零部署、嵌入代码、开箱即用	本地开发、快速Demo、原型验证
pgvector	PostgreSQL扩展	复用现有数据库、不用新增组件	已有PG基建、中小规模数据
Elasticsearch	搜索引擎+向量	混合检索强、过滤能力强、基建复用	企业级RAG、多条件筛选场景

选型决策口诀

• 快速做原型：选Chroma
• 已有PG基建：选pgvector
• 企业级混合检索：选ES
• 大规模纯向量：选Milvus

核心题3：为什么高维向量不用网格划分？什么是维度灾难？

背诵要点

网格划分的适用场景

• 适合低维空间（如二维经纬度、三维坐标）
• 原理：把空间切成均匀格子，查询时只扫描相邻格子，加速检索

维度灾难（高维空间的特性）

1. 空间指数爆炸：1024维空间，每个维度切2份，会产生2^1024个格子，远超可存储范围
2. 数据极度稀疏：高维空间中所有点都近似均匀分布，没有明显的邻近区域
3. 距离失效：任意两点的距离都趋近相等，欧式距离区分度大幅下降
4. 结论：网格划分在高维空间完全失效，没有加速效果

高维向量的主流检索方案

• 近似最近邻（ANN）索引，通过牺牲极小的准确率，换取百倍以上的速度提升
• 主流索引类型：HNSW（层次化近邻图）、IVF（倒排文件）、PQ（乘积量化）
• 生产最常用HNSW，综合召回率和速度表现最优

高频追问

1. HNSW和IVF索引有什么区别？怎么选？

   • HNSW：基于图结构，多层近邻图，召回率高、查询快、构建慢、内存占用高
   • IVF：基于聚类，把向量聚类成多个簇，查询先找簇再扫描，构建快、内存小、召回率稍低
   • 选型：追求高精度、查询频繁选HNSW；数据量大、写入频繁、可接受稍低召回选IVF

2. 向量量化是什么？有什么用？

   • 用更少的比特存储向量，压缩向量体积
   • 作用：减少内存占用、提升检索速度、降低存储成本
   • 代价：损失少量语义精度，召回率略有下降
   • 常用：Scalar量化（标量量化，精度损失小）、PQ乘积量化（压缩率高，精度损失大）
   • 选型：数据量大、内存紧张时用，优先试Scalar量化

3. 向量检索的召回率和速度怎么权衡？

   • 索引参数调优：HNSW的ef_search、ef_construction参数，越大召回越高速度越慢
   • 量化压缩：压缩率越高速度越快，召回越低
   • 业务原则：在满足召回率要求的前提下，尽可能提升速度
   • 一般生产环境召回率要求95%以上，再优化速度

---

3.8 全链路性能优化

核心题1：RAG全链路性能优化有哪些手段？

背诵要点

按链路分层优化，每层对应不同手段：

1. 检索层优化

   • 向量索引优化：选合适的索引类型和参数
   • 向量量化压缩，减小体积提升速度
   • 冷热分离，热数据常驻内存
   • 分片扩容，提升并发能力

2. 重排层优化

   • 控制重排输入数量，只排TopN
   • 选用轻量模型，批量计算
   • 高频结果缓存

3. 生成层优化

   • 流式输出（SSE），降低用户感知等待时长
   • 分级模型路由，简单问题用小模型
   • 高频问题答案缓存
   • 推理加速框架提升吞吐

4. 架构层优化

   • 就近部署，减少网络传输
   • 异步化非关键步骤
   • 预计算Embedding，离线完成
   • 并行执行无依赖环节（如两路召回并行）

核心题2：RAG的缓存体系怎么设计？

背诵要点

三级缓存体系，逐层降低成本提升速度：

1. 一级缓存：答案缓存

   • 缓存高频标准问题的完整答案
   • 命中直接返回，不走检索和生成，性能提升最大
   • TTL：几小时到几天，按知识更新频率定
   • 注意：缓存Key包含权限、租户信息，防止数据串权

2. 二级缓存：召回结果缓存

   • 缓存相同Query的召回+重排结果
   • 命中后直接生成，跳过检索重排环节
   • 适合：查询频繁、知识库更新不频繁的场景

3. 三级缓存：Embedding缓存

   • 缓存相同文本的向量结果
   • 入库和查询时都能命中，减少Embedding调用
   • 适合：重复文本多、查询重复率高的场景

缓存通用注意事项

• 缓存Key要做文本归一化，避免相同含义不同写法命中不了
• 设置合理过期时间，配合知识库更新主动失效
• 防止缓存污染：错误答案不能长期缓存，要有更新机制

核心题3：向量检索慢怎么排查优化？

背诵要点

按从易到难的顺序排查：

1. 检查索引状态
   • 是否建了向量索引，是不是全量扫描
   • 索引类型和参数是否合理
2. 检查数据规模
   • 数据量是否过大，是否需要分片扩容
   • 是否有大量冷数据，做冷热分离
3. 检查量化配置
   • 是否开启向量量化，压缩向量体积
   • 维度是否过高，能否接受降维
4. 检查资源配置
   • 内存是否足够，是否频繁Swap
   • CPU是否打满，是否需要升级配置
5. 查询参数优化
   • TopK是否过大，是否可以缩小
   • HNSW的ef_search是否设得过高

核心题4：ES检索慢怎么排查优化？

背诵要点

1. 慢查询定位
   • 开启慢查询日志，用profile API查看执行计划
   • 定位是哪个子查询慢，是关键词还是向量部分
2. 索引优化
   • 只给检索字段建索引，减少索引体积
   • 合理设置分片数，避免分片过多
   • 热点索引预热，加载到内存
3. 查询优化
   • 过滤条件前置，先过滤再打分，减少参与打分的文档数
   • 避免深度分页，用search_after
   • 减少返回字段，只取必要字段
4. 资源优化
   • 增加节点内存，使用SSD存储
   • 冷热分离，热数据存高性能节点

高频追问

1. 首字延迟和整体延迟怎么平衡？

   • 首字延迟影响用户体验，整体延迟影响系统吞吐
   • 用流式输出，首字返回后逐字输出，用户感知等待短
   • 优化检索和首Token生成速度，优先保障首字延迟
   • 后续生成速度可以稍慢，不影响体验

2. 高并发场景下怎么保障可用性？

   • 多级缓存扛热点流量
   • 消息队列削峰，异步处理非实时请求
   • 限流熔断，保护下游服务
   • 降级机制：高并发时跳过重排、用小模型、返回缓存答案
   • 多副本部署，水平扩容

3. 知识库越来越大，性能持续下降怎么办？

   • 冷热分离：不常用的冷数据归档，减少热索引大小
   • 分片扩容：水平拆分数据，分散压力
   • 定期优化索引：合并段、清理无效数据
   • 按业务分库：不同业务线独立索引，互不影响

---

3.9 评估体系与迭代闭环

核心题1：RAG系统的核心评估指标有哪些？

背诵要点

分四大维度：

1. 召回侧指标（基础）

   • 召回率：相关文档被召回的比例，核心底线指标
   • 精准率：召回结果中相关的比例
   • TopK命中率：TopN结果中包含正确答案的比例
   • MRR：第一个相关结果的排名倒数平均值，衡量排序质量

2. 生成侧指标（效果）

   • 答案准确率：答案是否正确、符合事实
   • 引用准确率：引用是否正确、是否有对应依据
   • 拒答准确率：该拒答的是否拒答，不该拒答的是否回答
   • 幻觉率：答案中幻觉内容的占比
   • 答案完整性：是否完整回答了问题

3. 性能侧指标（体验）

   • 端到端响应耗时
   • 首字延迟
   • 吞吐量（QPS）
   • 各环节耗时占比

4. 成本侧指标（运营）

   • 单次查询成本
   • Token消耗量
   • 基础设施成本

核心题2：怎么做自动化评估？LLM-as-Judge有什么优缺点？

背诵要点

自动化评估体系架构

1. 构建测试用例集

   • 覆盖正常、异常、边界、对抗等各类场景
   • 标注标准答案和相关文档，作为金标准
   • 持续补充bad case，用例集持续迭代

2. 自动化执行

   • 批量运行所有测试用例，记录全链路输出
   • 每次版本迭代自动跑回归测试

3. 多维度打分

   • 规则打分：可量化的硬指标（召回率、引用匹配等）
   • LLM-as-Judge：用强模型做评委，从准确性、完整性、相关性等维度打分

LLM-as-Judge的优缺点

• 优点：能评估语义质量，不用写复杂规则，适配开放式问题
• 缺点：
  1. 自身有偏见和不稳定性，打分有波动
  2. 成本高，全量评估开销大
  3. 对细微事实错误不敏感
• 弥补方案：配合规则校验、多模型交叉评测、人工抽检校准

核心题3：用户反馈怎么形成完整的迭代闭环？

背诵要点

五步闭环，从发现问题到优化落地再到验证：

1. 反馈采集

   • 前端提供赞/踩、纠错、举报按钮
   • 支持用户标注错误点、补充正确答案
   • 全量记录用户行为：停留时长、复制、追问等隐式反馈

2. 问题归因

   • 自动分类bad case：召回错误、排序错误、生成幻觉、拒答错误、文档缺失
   • 统计各类问题占比，优先解决占比最高的问题

3. 根因优化

   • 召回问题：优化查询改写、补充同义词、调整分块、增加混合召回
   • 幻觉问题：优化Prompt、加强事实校验、提升召回质量
   • 文档缺失：触发文档入库流程，补充知识库

4. 效果验证

   • 优化后用对应case做回归测试，验证是否修复
   • 小流量灰度验证线上效果

5. 沉淀复用

   • 典型bad case加入测试用例集，后续版本自动回归
   • 沉淀优化方法论，形成知识库

高频追问

1. 没有标注数据怎么做评估？

   • 先做无标注的指标：召回率可以用人工抽样标注小批量
   • 用LLM-as-Judge做自动评估，快速搭建基线
   • 从用户反馈中积累标注数据
   • 优先建核心场景的测试集，不用追求全量覆盖

2. RAG效果一直上不去，一般排查顺序是什么？

   • 第一步：看文档质量和分块，是否解析错误、分块不合理
   • 第二步：看召回，核心问题能不能召回到相关内容，是不是漏召
   • 第三步：看重排，相关内容有没有排到前面
   • 第四步：看上下文构建，信息是否完整、排序是否合理
   • 最后：看Prompt和生成环节，是不是模型没利用好信息
   • 经验：80%的效果问题都出在召回和分块

3. 多久迭代一次RAG效果比较合理？

   • 紧急问题：即时修复，快速上线
   • 常规优化：小版本每周迭代，大版本每月迭代
   • 评估流水线自动化后，可以做到每次变更都自动跑回归
   • 核心是形成数据驱动的迭代机制，而不是凭感觉改

---

3.10 进阶方向

核心题1：什么是Agentic RAG？和普通RAG的区别是什么？

背诵要点

• 普通RAG：「一次检索 → 一次生成」的固定流水线，被动执行，不会主动判断信息是否足够
• Agentic RAG：Agent自主控制检索过程，把检索作为一个工具，根据推理需要自主决定
  • 是否需要检索
  • 检索什么关键词
  • 检索几次
  • 是否需要补充检索
• 核心优势：
  1. 复杂多跳问题能力强，可通过多轮检索补全信息
  2. 信息不足时主动补充，不会硬答
  3. 可交叉验证多份信息，降低幻觉
• 适用场景：复杂调研、深度问答、多文档推理、知识探索类场景
• 劣势：耗时更长、成本更高、流程更复杂，简单问答场景没必要

核心题2：什么是Graph RAG？有什么优势？

背诵要点

• 核心思想：从文档中提取实体、关系、事件，构建知识图谱，配合向量检索一起使用
• 优势：
  1. 复杂逻辑推理强：支持多跳关联推理，回答「A和B有什么关系」类问题
  2. 多文档关联能力好：能跨文档整合实体关系
  3. 可解释性强：推理路径清晰可见
  4. 结构化信息处理更准确
• 劣势：构建成本高，需要实体抽取、关系抽取，维护复杂
• 适用场景：知识密集型、强逻辑推理、多文档关联的场景，比如医疗、法律、金融

核心题3：RAG怎么支持多模态、多语言？

背诵要点

多模态RAG

1. 入库侧：用多模态Embedding模型，同时支持文本、图片、表格向量化
2. 检索侧：多模态混合检索，图文统一相似度计算
3. 生成侧：用多模态大模型，同时理解文本和图片内容生成答案
4. 适用：文档包含大量图片、图表、截图的场景

多语言RAG

1. 方案一：统一向量化，用多语言Embedding模型，不同语言在同一语义空间
2. 方案二：查询翻译，把用户问题翻译成文档语言再检索
3. 方案三：双语索引，每份文档同时存多种语言的向量
4. 最佳实践：优先选原生多语言Embedding，实现最简单效果也最均衡

高频追问

1. 未来RAG的演进方向是什么？

   • 从静态流水线到智能Agent化，检索更灵活更智能
   • 从纯文本到全模态，支持图文音视频统一检索
   • 从通用检索到个性化检索，结合用户画像和历史行为
   • 检索和微调深度融合，知识和能力协同优化

2. RAG和知识图谱是什么关系？

   • 互补关系，不是替代
   • RAG擅长非结构化长文本，落地快成本低
   • 知识图谱擅长结构化关系推理，精准度高但构建成本高
   • 进阶方案：两者结合，向量检索+图谱推理，兼顾广度和深度