大家好，我是浩哥，这是我输出AI agent面试专题第五章，后面还有五期。建议加入粉丝，后面粉丝可见。
导语：本题型考察 RAG 的本质、与微调的区别、工作流程、时效性（文档更新）、幻觉缓解、效果评估与落地难点，是 Agent 接私域知识的主通道。RAG（Retrieval-Augmented Generation，检索增强生成）的本质是"把知识从模型参数里搬到外部知识库，推理时实时检索注入"，从而在不动模型的前提下，给 LLM 开一个"开卷考试"的口子。它是当前企业 AI 落地最成熟、最实用的技术路线，也是 Agent 接入私域知识的默认主通道。
- 2026年最新AI agent面试（01）_Agent基础与推理范式
- 2026年最新AI agent面试（02）_MultiAgent与记忆
- 2026年最新AI agent面试（03）_工具协议MCP_A2A_FC
- 2026年最新AI agent面试（04）__工具工程网关外部
- 2026年最新AI agent面试（05）_RAG基础应用
- 2026年最新AI agent面试（06）_RAG文档与检索
- 2026年最新AI agent面试（07）_大模型架构基础
- 2026年最新AI agent面试（08）_大模型训练评测
- 2026年最新AI agent面试（09）_AI编程ClaudeCode
- 2026年最新AI agent面试（10）_通信与行业动态
总目录可见 2026年最新AI agent面试（0）概述篇
Q1. RAG 到底是什么？它主要用来解决 LLM 的哪些核心问题？ ［来源：快手、字节］
-
核心答案 ：
RAG 的本质是"检索增强生成"------在 LLM 生成答案之前，先去外部知识库检索与问题相关的内容片段，把这些实时检索到的资料作为上下文（context）拼进 Prompt，让模型"基于真实资料作答"而非"凭参数化记忆凭空发挥"。它和微调的根本区别在于：RAG 不改模型参数，推理时现查现用；而微调是把知识烧进参数。
它要解决的是 LLM 同一类根因衍生出的三类问题，这三者的根源都是"知识被固化在模型参数里（知识冻结 / Knowledge Frozen）"：
- 知识时效性（过期）：LLM 训练数据有截止日期，截止之后的新事实、新产品、新政策一概不知；但模型没有"我不知道"的开关，会用历史规律"推测"出一个听起来合理的错答案。
- 私有知识空白（缺失）：企业内部文档、行业规范、合同模板等根本没进过公开训练集，属于"压根没有"而非"旧了"。让 LLM 当客服回答"本公司的退款政策"，它只能瞎编。
- 幻觉（知识缺失的副产品） ：前两者叠加的后果。LLM 的核心是"预测下一个 token"，没有"信息不足就停下"的机制，当参数知识不够用时只能硬拼答案，于是产生幻觉。幻觉不是独立 bug，而是知识缺失的"应急策略"，RAG 解决的是幻觉的根源而非现象。
一句话总结：RAG 把"知识管理"和"模型能力"彻底解耦------更新知识不用碰模型，扩充领域知识只要扩库即可，且答案每条都能溯源到具体 chunk。
-
关键点 / 展开：
- 知识冻结是 LLM 架构固有特性：训练一次成本千万美元级，不可能周周重训；微调也贵且不可溯源，所以"知识冻结"不能靠重训轻易解决。
- 幻觉是"知识缺失的副产品"，不是独立病症：知识过期导致幻觉、知识缺失也导致幻觉，根因同一（参数里没对应知识）。讲 RAG 价值时要讲"治根"而非"治表"。
- RAG 对三问题的解法：① 时效------新内容随时入库即生效，无需重训；② 私有------公司文档入库后 LLM 就能"看见"；③ 幻觉------有真实依据时模型是在"复述"而非"发挥"，幻觉率显著下降，且可溯源到原文供用户核实。
- 适用场景：知识密集型、准确性要求高、知识频繁更新的场景（企业知识库问答、法律/医疗/金融文献检索、智能客服）。
- 三大价值锚点（面试必补）：知识可热更新、答案可溯源、成本低（小团队 OpenAI Embedding + Chroma 即可跑）。
- RAG 自身挑战：召回质量（检索不到=巧妇难为无米之炊）、上下文长度限制（需 Rerank/精简）、实时性与成本平衡（每次问答都需向量检索）。
-
常见追问：
- 既然 RAG 这么好，为什么不直接抛弃微调？------RAG 对复杂推理/风格定制提升有限，深度领域能力仍需微调，"说什么"靠 RAG、"怎么说"靠微调可组合。
- 知识冻结能不能靠重新训练解决？------理论上可以，但成本和不可溯源问题使生产环境不可行，见 Q2。
-
2026 延伸 ：RAG 正从"Naive RAG"演进到 RAG 2.0 （模块化、可编排的检索-生成 pipeline）、GraphRAG （微软，用知识图谱增强全局性/总结性问答）、Agentic RAG（用 Agent 做多步、自适应检索）。来源名标注：GraphRAG / RAG 2.0 / Agentic RAG。
Q2. RAG 和微调（Fine-tuning）有什么区别？各自适合什么场景？ ［来源：阿里］
-
核心答案 ：
两者解决的是不同层面的问题，不是替代关系，本质是"改参数 vs 不改参数"。
- 微调（Fine-tuning） ：用自有数据继续训练，把新知识/新风格"烧进"模型参数。擅长改变行为风格 与培养深度专业能力 （专业术语、输出格式、行业语气），推理时无额外检索步骤、延迟低。代价是训练成本高（GPU+标注）、知识更新慢（数据每周变却不可能每周重训）、不可溯源（答案来自参数，出错难定位）。
- RAG ：不改参数，推理时实时检索注入。擅长知识频繁更新 与需要溯源 的私域问答，更新知识库即生效、成本低。代价是多一次检索延迟（几百毫秒~1秒）、检索质量卡死效果上限------LLM 只是复述检索内容，没检索到的东西变不出来，调优主战场永远是检索层而非换更强 LLM。
选型决策树：
- 知识会频繁变 / 需要答案可溯源 / 是私域问答 → 首选 RAG。
- 要定制输出格式、行业语气、深度领域推理能力 → 微调。
- 既要"说什么"（知识）又要"怎么说"（风格）→ 组合：先微调定风格，再套 RAG 供知识（微调解决"怎么说"，RAG 解决"说什么"），这是生产最常见做法。
-
关键点 / 展开：
-
核心差异对照表：
维度 微调 RAG 知识更新 需重训，成本高 更新知识库即可，实时生效 推理延迟 低，无检索步骤 较高，多一次检索 实现成本 高（GPU+标注数据） 低（向量库+Embedding） 答案可溯源 不支持（来自参数） 支持（可溯到 chunk） 适合场景 定制输出风格、深度专业能力 私域知识问答、动态数据 知识上限 受限于训练数据质量/规模 受限于检索质量+context 长度 -
最忌"二选一"思维：面试官考的是你是否理解工程选型，能讲出"两者可组合"才算真懂。
-
RAG 调优铁律：很多团队一上来想用 GPT-4 换掉 GPT-3.5 提升效果，往往是南辕北辙------生成层被检索层死死卡住，真正该优化的是检索质量（Embedding、Chunking、Rerank）。
-
微调的不透明风险：模型只是"记住了训练数据的模式"，它到底记住了什么、记错了什么无从得知，而 RAG 每条答案都能定位到出问题的 chunk。
-
-
常见追问：
- 能不能只微调不 RAG？------可以，但业务数据每周变时成本不可承受，且出错无法溯源定位。
- RAG + 微调组合时，微调阶段用什么数据？------用"格式/风格/术语"样本而非事实知识，避免把易变事实烧进参数。
-
2026 延伸 ：组合范式已演进为"微调解决风格 + RAG 解决事实"的标配；评测侧可结合 RAGAs / TruLens 量化组合收益。来源名标注：RAGAs（评测框架）。
Q3. RAG 系统的完整工作流程是怎样的？（离线建库 + 在线检索生成） ［来源：鹅厂、Shopee、字节］
-
核心答案 ：
一个完整的 RAG 系统分离线 和在线两个阶段，分工明确：离线负责"建库"，只做一次；在线负责"检索+生成"，每次提问都跑一遍。核心目标是让 LLM 回答时有真实知识作依据，而非凭空发挥。
离线阶段（建库，一次性）：
- 文档加载（Loading）：用 LlamaIndex/LangChain 的 DocumentLoader 读入 PDF、Word、Markdown、网页、数据库记录等。
- 文档切割（Chunking）：切成 500~1000 token 的小片段，并做 100 token 左右的重叠（overlap），避免切断完整语义。太大语义杂、太小上下文丢。
- 向量化（Embedding）：用 Embedding 模型把每个 chunk 转成高维向量（如 1536 维），本质是"语义坐标系"------语义相近则向量相近，实现语义检索而非关键词匹配。
- 入库（Store）：向量+原文存入向量库（Chroma/Milvus/Qdrant/Weaviate），支持千万级向量的快速相似度搜索。
在线阶段（检索+生成，每次提问）：
- Query 预处理 / 改写（Rewrite） ：口语化/带指代的问题先改写（如"上次那个方案"需补上下文），或用 HyDE（先让 LLM 假设答案、用假设答案向量去搜）、多角度扩写后多路检索。
- Query 向量化 ：用与建库完全相同的 Embedding 模型（不同模型向量空间不兼容，否则距离计算无意义）。
- 向量检索（粗排）+ 多路召回 ：近似最近邻（ANN）搜索 Top-K；同时混合 BM25/全文检索 （精确命中产品型号、专有名词），双路结果用 RRF（互逆排名融合） 合并。
- Rerank（精排）：用 Cross-Encoder 把 query 与每个候选拼在一起深度打分，从粗排 Top-20 里筛出 Top-3~5，过滤噪音（精排更准但更慢，故两阶段分工）。
- Prompt 拼装：模板明确约束"只根据资料回答、资料没有就说不知道、带编号便于溯源"，抑制 LLM 凭记忆发挥。
- 大模型生成 + 溯源：LLM 基于资料生成答案并标注引用来源（如"根据资料1..."），让用户可回溯原文验证。
-
关键点 / 展开：
- 为什么必须 Chunking：向量模型有输入长度上限，且整篇压缩成一个向量会把细节"平均掉"（类比"中国菜整体偏咸"丢失具体信息）。
- 为什么需要 Rerank 而非只用向量检索：向量检索只比向量距离、不深度理解 query-doc 关系，必然混入"看着近其实不相关"的内容；Cross-Encoder 精排更准但计算量大，只能对粗排几十条约算。
- 为什么需要 BM25 混合检索：向量检索对精确词（型号、缩写、错拼）弱，BM25 正好补强；RRF 融合兼顾语义与关键词。
- Embedding 模型一致性是硬约束：离线/在线模型必须同一个，否则坐标系错位。
- 在线耗时分布：Query 改写几十 ms、向量检索几十 ms、Rerank 几百 ms、LLM 生成 1~10s。优化手段：缓存高频 Query 检索结果、向量检索与 BM25 并行（延迟取 max 而非叠加）。
- RAG ≠ Elasticsearch、≠ 微调：漏掉"G（Generation）"或把"检索注入"说成"训练进模型"都是典型踩雷。
-
常见追问：
- 为什么不直接用 Rerank 做检索？------Cross-Encoder 对百万级逐条算分延迟不可接受，必须"粗排筛几十、精排挑几条"。
- Chunk 大小怎么定？------实践 500~1000 token + overlap，需按业务调，见 Q7 落地难点。
-
2026 延伸 ：多路召回已扩展到"向量+BM25+SQL+知识图谱"；RAPTOR （递归式树状 chunk 聚合）增强摘要性问答；Agentic RAG 用 Agent 动态决定检索几轮、何时停。来源名标注：RAPTOR / Agentic RAG / HyDE / RRF。
Q4. RAG 知识库上线后，文档更新了怎么办？ ［来源：小米］
-
核心答案 ：
核心挑战是"文档变了，对应的 chunk 和向量都要跟着变，且要增量处理，不能每次全量重建"。RAG 知识库的更新比普通数据库麻烦，因为原始文档与向量库是一对多关系（一篇文档切成几十~上百 chunk），文档一改，切割边界就变，无法在旧 chunk 上"局部打补丁"。
通用方案 = 先删后增（Delete-then-Reindex）：通过内容 hash 检测变更，对新增/修改/删除三类操作分别处理------新增走完整"切割→Embedding→写入"；修改是"删掉该文档所有旧 chunk，再按新内容重新切割入库"；删除是清掉对应 chunk 避免"僵尸 chunk"。再配合变更感知（轮询或消息队列）实现增量更新。
-
关键点 / 展开：
- 为什么不能"局部更新某个 chunk"：文档内容一改，切割边界全变（原来第 3 个 chunk 可能散到第 3、4 个），无法把旧 chunk 与新 chunk 一一对应。就像拆墙重建不能指望原插座位置还能对上。所以"推倒重来"是唯一不出 bug 的做法。
- 三类变更操作：① 新增（最简单，无历史包袱）；② 修改（最易踩坑，必须先删全量旧 chunk 再重切）；③ 删除（清掉所有关联 chunk，不留失效内容）。
- 变更检测 = 内容 hash（MD5/SHA256）：入库时存文档 hash + doc_id + 对应 chunk_id 列表（放 Redis/DB）；下次检测重算 hash 比对，相同跳过、不同触发重处理。hash 极快，改一个标点也会完全不同，不会漏变更。
- 优化：mtime 粗筛 + hash 精筛：先比"最后修改时间"过滤 99% 未变文档，只对时间戳变化的算 hash，开销再降一个量级。
- chunk ID 设计规范（易忽视但关键） ：让 chunk_id 带 doc_id 前缀（如
product_v3_chunk_001）或在 metadata 存source_doc_id，这样删除时可按前缀/metadata 批量定位该文档所有 chunk。从一开始就要设计好 doc↔chunk 关联。 - 两种变更感知方式 ：
- 定时轮询（Polling）：按固定间隔扫描比对 hash。实现简单、不依赖外部系统，适合更新频率低、实时性要求不高的内部知识库；缺点有延迟、全量扫描有开销。
- 事件驱动（Event-Driven）：数据源变更主动发消息（Kafka/RabbitMQ/Webhook），订阅后秒级入库。适合实时性高的客服/新闻场景；代价是需数据源支持发消息、架构更复杂。Confluence/Notion/语鹊等原生支持 Webhook，无需重消息队列。
- 全量重建是"核弹级"兜底：把所有文档重新切+Embedding+写。逻辑最简单但耗时长、Embedding API 费钱、重建期库不可用。仅用于：库很小（几十篇）/ 换了 Embedding 模型或 Chunking 策略导致新旧向量不兼容。
- 灰度更新（蓝绿部署思路） ：核心库先并行写入
version=new保留version=old，用测试问题跑新旧对比验证无退化后，把检索过滤条件从 old 切到 new，再清旧。出问题可秒级回滚，金融/医疗等高要求场景必需。
-
常见追问：
- 能不能只更新变了的那个 chunk？------不行，切割边界会变，必须"先删后增"。
- 实时性要求高的场景怎么做到秒级生效？------事件驱动（Kafka/Webhook），数据源一变更立刻推送处理。
-
2026 延伸 ：大规模知识库的增量更新可结合向量库的 namespace/collection 版本化 与CDC（Change Data Capture） 管道；灰度更新思想与 GraphRAG 的增量图谱更新同源。来源名标注：GraphRAG / CDC。
Q5. 大模型为什么会产生幻觉？RAG 系统中幻觉的来源与缓解策略是什么？ ［来源：面试官、滴滴］
-
核心答案 ：
幻觉的本质 ：模型生成了"与训练事实/用户输入/已知世界不一致、但语言流畅合理"的内容。两个特征------内容错、听起来对（一眼看出的语法错不算幻觉）。根本元凶是：LLM 不是数据库，而是概率续写器（next-token prediction），它永远"输出点什么"，没有"查询失败"状态。
幻觉的三层根因：
- 训练数据层：互联网语料本就含错误、矛盾、过时信息（维基错误版本、谣言、互相矛盾来源），模型全学进参数且无真假区分机制。
- 生成机制层（最深根因） ：LLM 是"按概率续写"，对"自己知不知道"无显式信号 。问"鲁迅是谁的笔名"，它是在参数里算"下一个 token 最高概率"，而非查知识库；记忆模糊时按分布挑一个"合理名字"就错。→ Temperature=0 也会幻觉（贪心解码选"概率最高"≠"正确"，只是统计最常见；模型记错就是记错，降温只让错误更稳定）。参数化知识是"模糊、不可检索、不可验证"的，而 RAG 的检索式知识"有出处、找不到就返回空"------这就是 RAG 能缓解幻觉的机理。
- 对齐目标层（SFT+RLHF 副作用）：标注偏好"详细、自信、专业"，模型被训练成"不会拒答"，反而加剧幻觉。
幻觉三类：事实性幻觉（编造不存在的事实）、推理性幻觉（推理链错乱/前后矛盾）、上下文不一致（违背用户明确条件）。
RAG 系统内幻觉的两类来源与规避（分成本最低→机制最严四方案）：
- 检索层幻觉：检索没召回到相关内容，prompt 里是空的/不相关的，LLM 靠自己知识编。例：库里是"7天退款"，没召回，LLM 编出"30天"。
- 生成层幻觉：召回了但 LLM "超发挥"，在资料基础上加推断、补原文没有的细节、混不相关信息拼"更完整答案"，更隐蔽更常见。
四层缓解策略（递进）：
- Prompt 强约束（成本最低）：明确"只用参考资料、没有就说不知道、标注来源、不推断不补充"。给 LLM 合法逃生出口，压制生成层幻觉。
- 检索质量门控（成本低）：Rerank 分数低于阈值（经验 0.3~0.6，金融/医疗偏高）直接拒答"知识库无相关信息，请联系人工"，不让 LLM 在低质上下文硬撑。用已知"有答案/无答案"测试集调切点。
- 生成后引用核查（代价高）：第二次 LLM 调用当"编辑"，逐条核查答案每句在 chunk 里有无依据，无依据标注"无法核实"或删掉。多用于医疗/法律。
- 结构化输出强制溯源 ：让 LLM 输出 JSON，每条结论必须附
source_ids，系统可程序化验证来源编号是否真实存在，且"写论文必须标参考文献"会降低瞎编概率。
组合建议：方案1+方案2 是上线前基础配置 （成本最低、收效最快）；方案3+方案4 用于高准确要求场景。关键认知：幻觉不可能完全消除（概率生成机制的固有副产物），工程目标是"降低发生率 + 让用户能识别"，不是"彻底消灭"。
-
关键点 / 展开：
- Temperature 调低不能根除幻觉：只减少"同一错误重复出现的随机性"，错误本身仍在；模型记错就是记错。
- 参数化知识 vs 检索式知识：前者分布式编码、模糊、不可检索、不可验证；后者精确有出处------RAG 把"模糊记忆"换成"精确检索"，从根上降幻觉。
- 拒答优于错答：用户问覆盖不到的问题，最好答"我不知道，请联系人工"，而非编个合理错答案；答错比不答更危险。
- 引用归因（Citation/Attribution） 是 RAG 抑制幻觉的杀手锏：答案每条可溯到 chunk，用户可自行核实。
- Self-RAG 思路：让模型在生成中自省"是否需要检索/检索到的内容是否相关/生成是否有据"，按需检索并自检，是缓解生成层幻觉的前沿范式。
- 缓解须训练+推理+系统三层协同：训练层（加入"不知道就说不知道"校准样本）、推理层（分步分析、降温度、Self-Consistency 多次采样投票、约束解码）、系统层（RAG 接外库、答案后处理核查、强制引用）。
-
常见追问：
- 把 Temperature 调到 0 是不是就不幻觉了？------不是，概率最高路径本身可能错，模型记错就稳定错。
- 检索做好了 LLM 就不会编了吗？------不一定，还有生成层"超发挥"幻觉，需 Prompt 约束+引用核查兜底。
-
2026 延伸 ：前沿缓解范式包括 Self-RAG （自适应检索+自省打分）、CRAG（Corrective RAG） （检索低分时触发网络补充检索）、引用归因（Citation/Attribution） 评测。来源名标注：Self-RAG / CRAG。
Q6. 线上跑了 RAG，怎么系统化、可量化地衡量它的效果好不好？ ［来源：字节］
-
核心答案 ：
不能用"用户投诉"或"人工抽查几条"评估------前者是亡羊补牢（投诉时已被坑多人），后者样本少、主观强、无法定位环节。正确做法是把"好不好"拆成可量化、可追踪、可定位的指标，分两层（检索层 + 生成层）加一层（线上指标）。
第一层：检索层指标（只看"该召回的有没有召回到"，与 LLM 无关）
- Hit@K：Top-K 结果里是否包含正确 chunk（回答"找到没"）。Hit@5 < 0.7 说明检索层有问题（换 Embedding/调 Chunking）；> 0.8 说明检索 OK、问题在生成层。
- MRR（平均倒数排名）：正确内容排第几（回答"多快找到"）。第 1 名得 1 分、第 2 名 0.5、第 5 名 0.2。MRR < 0.5 通常说明 Rerank 不够好（召回了但没排前面）。
- 配合：Hit@K 是"找到没"，MRR 是"多快找到"，定位检索问题出在召回还是排序。
第二层：生成层指标（RAGAs 框架，LLM-as-a-Judge 自动打分）
- Faithfulness（忠实度/无幻觉）：答案每句话在 chunk 里有无出处，衡量幻觉程度。目标 > 0.8。
- Answer Relevancy（答案相关性）：答案是否回答用户所问（"说的是用户想要的"），与 Faithfulness 是两回事（可字字有据但跑题）。目标 > 0.8。
- Context Recall（上下文召回率）：答好题所需信息在检索结果里的覆盖率（需 ground_truth 参照，衡量"漏没漏"）。目标 > 0.7。
- Context Precision（上下文精确率）：召回的相关内容是否排在前面（衡量"噪音多不多"）。
线上指标（最终衡量标准）：点踩率、追问率、转人工率、解决率。离线指标只是辅助，最终看用户反应。
-
关键点 / 展开：
- 用指标定位问题（诊断矩阵） ：
- Context Recall 低 → 检索漏召 → 换更强 Embedding、调 Chunking、加多路召回。
- Context Precision 低 → 召回噪音多 → 加强 Rerank、减少送入 LLM 的 chunk 数。
- Faithfulness 低 → LLM 编造 → 加强 Prompt 约束、引用核查、检索质量门控。
- Answer Relevancy 低 → 答案跑题 → 明确 Prompt"严格回答问题本身"。
- 为什么必须"持续"评估：知识库在变、提问方式在变、Embedding/Chunking 可能调，每次改动都可能让效果变好/变坏，无评估体系就是盲飞。
- RAGAs 成本缓解：测试集抽样 200~500 条核心样本；裁判模型从 GPT-4o 降级 GPT-4o-mini，成本降 10 倍、精度损失可接受。
- 必须在本业务数据上跑：通用排行榜不能代表你的场景，评估要贴合自有语料。
- RAG 评估难点：答案是自然语言无唯一标准答案；出问题不知是检索层还是生成层锅；人工标注贵难持续------故必须分层。
- 用指标定位问题（诊断矩阵） ：
-
常见追问：
- 离线指标都好，线上用户还投诉怎么办？------离线≠线上，需补线上点踩/转人工率，并查是否评估集未覆盖真实长尾问题。
- RAGAs 每次调 LLM 打分太贵怎么办？------抽样核心集 + 降级裁判模型。
-
2026 延伸 ：评测体系已扩展到 RAGAS / TruLens / ARES 等多框架，并引入 Answer Correctness （答案正确性，综合召回与相关性）、Context Utilization （上下文利用率）等指标；基准如 RGB / CRUD 评测检索质量。来源名标注：RAGAs / TruLens / ARES / Answer Correctness。
Q7. 在实际落地中，你觉得 RAG 最难的地方是哪里？ ［来源：阿里三面］
-
核心答案 ：
RAG 最难的不是"跑起来"（基础 Demo 一两天可搭），而是"调好"------把它调到生产可用质量，往往需几周甚至几个月迭代。要分层、有体系地看难点，而非东一榔头西一棒槌。三大难点：
- 文档预处理（地基型瓶颈）：最前的一环，喂进去是垃圾出来也是垃圾。现实文档格式五花八门：PDF 表格/双栏/嵌套排版用 pypdf 通用库会解析乱序（如"型号内存价格iPhone 158GB5999"行列全失），需 pdfplumber/unstructured 专项处理；扫描件需 OCR；图片文档关键文本提取不到；代码块切坏破坏逻辑。高价值复杂文档可用 GPT-4o Vision 多模态理解（代价高几十~上百倍，只适合合同/财报/专利等少量高单价文档）。生产系统预处理代码量常比 RAG 核心逻辑还多。
- 检索质量调优（系统效果天花板）：检索召回不到，LLM 再强也白搭。难点来源交织：① Chunking 策略（退款内容被切散在十几个 chunk，单独相关度都不高）；② Query-文档语义鸿沟（口语"怎么用不了" vs 文档"故障排查指南"，相似度低，需 Query 改写或为 chunk 存"假设性问题"增强）；③ 向量检索对精确词（型号/缩写）弱，需混合 BM25 关键词检索。定位费劲。
- 效果评估困难：单条对错人工贵且标准不一；端到端指标（满意度/解决率）反馈周期长、不知是哪层锅。实用做法：检索层用 Hit@K 自动批量跑定位瓶颈；生成层用 RAGAs（Faithfulness/Answer Relevancy/Context Recall）自动打分，三层结合基本定位检索层还是生成层问题。
总结：原型易、调优难，每个环节都可成瓶颈且环环相扣（预处理→Chunking→Embedding→检索→Rerank→Prompt），任一差都拖累整体，无捷径。
-
关键点 / 展开：
- "地基型瓶颈"认知：文档预处理不是唯一瓶颈，但是最前的瓶颈------后面 Chunking/Embedding/检索/生成再强也救不回烂原料。
- PDF 解析选库原则：pypdf 定位非复杂排版；表格/复杂版面交给 pdfplumber、unstructured；高价值复杂文档用 Vision 模型（按 token 单价高几十~百倍，控量使用）。
- 检索质量三排查点：Chunking 策略、Query-文档语义鸿沟（解法：Query 改写 / 假设性问题增强）、精确词召回（解法：混合检索 BM25+向量）。
- 评估即定位：没有量化指标体系，优化=瞎猜；Hit@K + RAGAs 三层指标能把"好差"翻译成可追踪数字，指导决策。
- 工程现实：几周~几月迭代是常态，需把每个环节当作潜在瓶颈分别调优并关注相互影响。
- 关联 Q4/Q6：动态更新（Q4）和效果评估（Q6）本身就是落地难点的工程化解法------更新策略解决"知识时效性落地"，评估体系解决"调优无方向"。
-
常见追问：
- Embedding 选型是不是最难？------它是重要点之一，但只是单点；整体要分层看（预处理/检索/评估），且文档解析乱码、Chunking、评估都同样致命。
- 怎么系统性而非零散地讲难点？------按"文档预处理→检索质量→效果评估"三层递进，每层点出根因与解法。
-
2026 延伸 ：落地痛点催生了模块化 RAG / RAG 2.0 框架（把各环节组件化、可编排、可观测），以及 GraphRAG （图谱化预处理解决全局摘要难）、Agentic RAG（Agent 自主决策检索策略缓解语义鸿沟）。来源名标注：RAG 2.0 / GraphRAG / Agentic RAG。
📌 本题型速记 Checklist
- RAG 本质：检索增强生成，推理时现查知识注入 Prompt，不改模型参数，给 LLM "开卷考试"口子。
- 三大核心问题：知识时效性（过期）、私有知识空白（缺失）、幻觉（知识缺失的副产品）------根因都是"知识冻结在参数里"。
- RAG vs 微调：一个改参数、一个不改；RAG 适合频繁更新+溯源，微调适合风格/深度能力；可组合"先微调定风格、再 RAG 供知识"。
- 离线四步：文档加载 → Chunking（500~1000 token+overlap）→ Embedding 向量化 → 入库（Chroma/Milvus 等）。
- 在线六步：Query 改写（HyDE/多角度）→ Query 向量化（模型须与建库一致）→ 向量检索粗排 + BM25 多路召回（RRF 融合）→ Rerank 精排（Cross-Encoder）→ Prompt 拼装（强约束+编号溯源）→ 生成+溯源。
- 检索质量卡死上限：RAG 调优主战场是检索层，不是换更强 LLM（生成只是复述检索内容）。
- 动态更新铁律：先删后增（Delete-then-Reindex），因文档一对多 chunk、边界会变，无法局部打补丁；用 hash + mtime 检测，轮询/事件驱动感知，灰度更新可回滚。
- 幻觉根因三层：训练数据错、生成机制是续写无"不知"信号（Temperature=0 也幻觉）、对齐目标鼓励自信回答。
- RAG 幻觉两类：检索层（没召回到→靠编）、生成层（召回了但超发挥）；四方案：Prompt 约束 + 检索门控（上线必做）+ 引用核查 + 结构化溯源。
- 效果评估两层 + 线上：检索层 Hit@K / MRR；生成层 RAGAs（Faithfulness / Answer Relevancy / Context Recall / Context Precision）；线上看点踩率/转人工率。指标低→定位具体环节。
- 落地三大难点：文档预处理（地基型瓶颈，PDF/OCR/Vision）、检索质量调优（Chunking/语义鸿沟/精确词混合检索）、效果评估（无量化=瞎猜）。
- 关键认知：幻觉不可完全消除，目标是"降发生率+可识别"；原型易、调优难（几周~几月）；每个环节都可能成瓶颈且环环相扣。
- 2026 演进方向（来源名） ：RAG 2.0（模块化编排）、GraphRAG（图谱增强）、Agentic RAG（自适应检索）、Self-RAG/CRAG（自省/纠错检索）、RAPTOR（树状聚合）、评测框架 RAGAs/TruLens/ARES、Answer Correctness 指标。
