目录

1. 基础概念与架构选型类
2. RAG 核心链路类
3. 智能体（Agent）核心类
4. 效果优化与评测类
5. 工程落地与运营类
6. 故障排查与场景题
7. 高阶与前沿方向类
8. 项目经历复盘类

一、基础概念与架构选型类

1. 简单说一下什么是 RAG？它解决了什么问题？

答题思路：RAG 全称检索增强生成（Retrieval-Augmented Generation），核心逻辑是「先检索后生成」：用户提问后先从外部私有知识库中召回相关的文档片段，再把问题 + 上下文一起喂给大模型，让大模型基于检索到的事实生成答案。 它针对性解决大模型三个原生痛点：①知识时效性差，大模型训练数据有截止日期，最新业务知识、内部制度无法覆盖；②幻觉问题，大模型会编造不存在的事实，RAG 让答案有文档依据，可溯源；③领域专业能力不足，通用大模型对企业内部的业务术语、流程规则理解差，RAG 注入私有领域知识不用重新训练模型。 相比微调，RAG 知识更新成本极低、答案可溯源、合规性强，是目前企业内部知识问答的主流落地方案。

2. 什么是大模型智能体（Agent）？和普通 RAG 对话有什么区别？

答题思路：大模型 Agent 是具备自主规划能力、工具调用能力、记忆能力，能够多步迭代完成复杂任务的智能系统，核心是「思考 - 行动 - 观察」的闭环逻辑。 和普通 RAG 的本质区别：普通 RAG 是固定单向链路，只能完成「查知识库→生成答案」这一件事，能力边界固定；Agent 是动态循环链路，能自主判断任务类型、决定要不要调用工具、调用哪个工具、要不要多步执行，能力可以通过新增工具无限扩展。 比如普通 RAG 只能回答制度问题，Agent 可以做到「用户问年假剩多少→调用 HR 系统工具查余额→再调用日历工具查最近空闲时间→最终给用户推荐请假方案」，是从问答工具到任务执行系统的升级。

3. 你们的 RAG+Agent 整体架构是怎样的？完整数据流走一遍？

答题思路：分离线预处理链路和在线推理链路两部分讲，逻辑更清晰。 离线链路：文档上传→多格式解析（Word/PDF/ 表格 / 图片）→文档清洗去重→语义分块→Embedding 向量化→写入 Milvus 向量库，同时建立文档元数据索引。 在线推理链路：用户提问→携带会话 ID 拉取对话记忆→Agent 接收任务做初步规划→判断问题类型：如果是知识类问题，调用知识库工具（query 改写→向量粗召回 Top10→Rerank 精排 Top3→拼接上下文）→大模型生成答案；如果是工具类问题，直接调用对应业务 API 工具→Agent 整合所有工具结果→输出最终答案→更新对话记忆。 整套架构基于 LangGraph 做工作流编排，每个节点状态可追踪，方便调试和故障排查。

4. 向量数据库怎么选型？Milvus、FAISS、Chroma、ES 的区别和适用场景？

答题思路：从数据规模、运维成本、扩展能力、功能特性四个维度对比选型。

• FAISS：纯算法库，不是完整数据库，没有持久化、分布式、权限控制，适合本地 Demo、十万级以内小数据量的原型验证，优点是轻量速度快，缺点是生产不可用。
• Chroma：嵌入式轻量向量库，单节点部署，运维成本极低，适合十万级数据以内的小型项目、个人原型，缺点是不支持分布式扩容，数据量大了性能下降明显。
• Elasticsearch：全文检索引擎，向量是附加功能，混合检索（关键词 + 向量）能力强，适合已经有 ES 技术栈、数据量在百万级、需要兼顾关键词匹配的场景，缺点是纯向量检索性能不如专用向量库，亿级数据扛不住。
• Milvus：分布式专用向量数据库，支持亿级向量、分片扩容、多副本高可用、标量过滤，功能完整生产级，是目前企业级 RAG 的主流选择，缺点是有一定运维成本，需要单独部署集群。 我们项目因为数据量持续增长、对可用性要求高，选了 Milvus 集群版。

5. 为什么要把 RAG 做成 Agent 的一个工具，而不是直接做 RAG 对话？

答题思路：核心是扩展性和解耦，是面向未来业务迭代的架构选择。 优势有三点：①能力解耦，知识库只是众多工具中的一个，后续加数据库查询、工单创建、HR 系统查询等工具，不用改主架构，直接注册新工具就行；②智能调度，Agent 能自主判断问题类型，简单常识问题直接回答，不用走检索链路，节省大模型成本；③复杂任务支持，多步骤任务可以串联多个工具执行，比如「查制度→算假期→查日历」，纯 RAG 做不到。 劣势也有：链路更长，单次请求延迟比纯 RAG 高 20%-30%；架构更复杂，调试和排障成本更高。如果只是纯知识库问答场景，属于过度设计；但如果后续有扩展多工具的规划，是更合理的架构。

6. RAG 和大模型微调有什么区别？分别适合什么场景？

答题思路：两者是完全不同的技术路线，核心区别在于「改不改模型参数」。

对比维度	RAG	微调（LoRA）
知识更新	更新文档即可，分钟级生效	重新训练，天级成本
可解释性	答案可溯源到具体文档	黑盒，无法解释答案来源
幻觉风险	低，有事实约束	较高，容易编造事实
适用任务	事实问答、知识查询	风格对齐、推理能力提升、格式输出
落地成本	低，不需要 GPU 训练资源	高，需要训练算力和数据

选型原则：事实类知识靠 RAG，风格能力靠微调。如果是企业内部知识库、制度问答这类需要频繁更新、要求准确可溯源的场景，优先 RAG；如果是需要统一回答风格、学习特定推理逻辑、输出固定格式，RAG 优化到瓶颈的场景，再考虑微调。落地一般是两者结合，RAG 管事实准确性，微调控领域风格和输出格式。

---

二、RAG 核心链路类

1. 文档分块用的什么策略？分块大小和重叠度怎么确定的？

答题思路：我们主用递归字符分块（RecursiveCharacterTextSplitter），是落地最均衡的方案。它会按「段落→换行→句子→字符」的优先级依次切割，尽量保证语义单元的完整性，不会把一个完整句子硬切两半。 参数方面中文场景我们设的是单块 500-800 字符，重叠度 10%-20% 也就是 50-100 字符。参数是拿业务真实测试集 AB 测出来的：块太小会把完整语义拆碎，召回率下降；块太大噪声多，单块无关内容占比高，也会影响生成效果。重叠度是为了避免跨块的知识点两头都捞不到，保证边界内容的召回。 特殊文档单独处理：长文档先按标题层级拆成章节，再做细粒度分块；代码、表格这类结构化内容，按逻辑单元拆分，不硬切字符长度。

2. 固定长度分块和语义分块有什么区别？各自适用场景？

答题思路：核心区别是切割的依据不同，一个按字符数，一个按语义完整性。 固定长度分块：按固定字符数硬切，实现最简单、速度最快、性能最稳定；缺点是很容易破坏语义完整性，跨段落、跨句子的知识点被拆分，两头都召回不到，召回率低。适合快速 Demo、对效果要求不高的场景。 语义分块：按语义单元切割，比如按段落、按标题层级、或者计算相邻句子的向量相似度，相似度低于阈值就切开，保证每个块都是完整语义单元；优点是召回率高，语义完整；缺点是实现复杂、速度慢，块长不统一，对后续处理不友好。 递归字符分块是折中方案，优先按语义边界切，实在太长再按字符切，兼顾了效率和效果，是生产环境最常用的。纯语义分块因为性能和成本问题，只有对召回率要求极高的场景才会用。

3. Embedding 模型选型看哪些指标？中文场景为什么常用 BGE 系列？

答题思路：选型核心看四个维度：①语义效果，也就是垂直领域的召回准确率，是最核心的指标，一般看 MTEB/CMTEB 评测集的分数，还要拿自己的业务数据实测；②向量维度，维度越高效果越好，但存储成本越高、检索速度越慢，要平衡；③推理性能，单条向量化速度、并发吞吐，影响全链路延迟；④授权和部署成本，能不能商用、能不能本地部署、资源要求高不高。 BGE 系列在中文场景流行的原因：一是专门针对中文语料优化，中文召回效果比通用模型好很多，在 CMTEB 榜单上排名靠前；二是尺寸齐全，从 tiny、base 到 large 都有，不同性能要求的场景都能选；三是开源可商用，支持本地部署，符合企业数据安全要求；四是生态完善，LangChain、Milvus 等框架都原生支持，接入成本低。

4. 向量相似度算法有哪些？余弦相似度和内积的区别？

答题思路：常用的有三种：余弦相似度、内积（点积）、欧氏距离。

• 余弦相似度：衡量两个向量方向的夹角，取值范围 [-1,1]，越接近 1 越相似，不受向量本身长度（模长）的影响，只看方向是否一致，是语义匹配场景最常用的，因为语义相似度和向量长度无关。
• 内积：和向量的方向、模长都有关系，模长大的向量得分天然更高。如果所有向量都做了 L2 归一化（模长变成 1），内积的结果和余弦相似度完全等价。
• 欧氏距离：衡量向量空间中的直线距离，距离越小越相似，适合向量模长有实际意义的场景，语义检索用得少。 选型要和 Embedding 模型的训练方式对齐，绝大多数中文 Embedding 模型都是用余弦相似度训练的，所以检索时也对应选余弦。如果模型训练时做了归一化，选内积速度更快，结果一致。

5. 换了 Embedding 模型，向量库要怎么处理？能平滑迁移吗？

答题思路：必须全量重建，没有捷径。因为不同 Embedding 模型的向量空间、维度、语义分布完全不一样，是异构的，维度不匹配直接报错，维度一样语义空间不同也完全搜不准。 平滑迁移用双写 + 灰度切流方案，保证线上无感知：第一步新建一个目标模型的向量集合，用新模型全量重写所有文档的向量；第二步小流量灰度，把 10% 的请求切到新集合，验证召回率、答案效果没有下降；第三步逐步放大流量，全量切到新集合；第四步下线旧集合。 迁移期间旧集合继续提供服务，不会影响线上可用性，回滚也很方便，切回旧流量就行。绝对不能线上直接替换模型，会导致整个检索服务不可用。

6. 常见的检索方式有哪些？相似度检索和 MMR 的区别？

答题思路：常用三类检索方式，适用不同场景： ① 相似度检索：纯按向量相似度从高到低排序，实现最简单、速度最快，是最基础的检索方式，适合答案集中在少数片段的场景；缺点是返回结果高度同质化，多个相似片段重复，覆盖角度少。 ② MMR（最大边际相关性）：同时兼顾「和问题的相关性」和「结果之间的多样性」，用 lambda 参数调节两者权重，在保证相关的前提下，让返回结果覆盖更多不同角度的内容，适合答案分散在多个不同片段、需要信息全面的场景。 ③ 混合检索：BM25 关键词检索 + 向量语义检索结合，两路召回后合并重排，兼顾语义匹配和关键词精确匹配，适合专业术语多、专有名词多的领域，比如法律、医疗、技术文档，纯向量检索容易漏精确匹配的内容。 我们基础用相似度检索，专业领域的知识库开混合检索，需要全面信息的问答开 MMR。

7. Rerank 的原理是什么？为什么比向量检索更准？

答题思路：核心是双编码器和交叉编码器的架构差异。 向量检索用的是双编码器：query 和文档分别单独编码成向量，再算相似度，优点是文档可以提前编码好存在库里，检索只需要算 query 的向量，速度极快，能支持亿级库检索；缺点是两个向量独立计算，没有细粒度的交互，匹配精度有限。 Rerank 用的是交叉编码器：把 query 和候选文档拼在一起输入模型，做交叉注意力计算，逐字逐句判断两者的相关性，优点是匹配精度非常高，远高于双编码器；缺点是速度慢，每对 query 和文档都要单独推理一次，没法全库检索。 所以工业界都是两级检索架构：第一级用向量检索从全库快速召回 Top50/Top100 候选（保证召回率），第二级用 Rerank 对候选做精排，选出 Top3/Top5（保证准确率），兼顾速度和效果。

8. Rerank 的 top_n 设多少？怎么确定这个值？

答题思路：我们最终设的是 Rerank 后留 Top3 传给大模型。这个值是权衡出来的，没有标准答案，要看三个维度： ① 上下文窗口占用：单块 500 字符，3 块就是 1500 字符左右，加上问题、历史对话、系统 Prompt，总 token 控制在模型窗口的 1/3 以内，留给生成足够空间； ② 召回覆盖率：拿测试集测，Top3 能覆盖 90% 以上的相关内容，Top5 能到 93%，再往上加收益递减非常明显，属于边际效益递减； ③ 噪声和成本：传的片段越多，无关噪声越多，反而容易干扰大模型生成，同时 token 消耗变大，成本升高，延迟也变长。 确定方法是画覆盖率曲线，找拐点：也就是增加 TopN 数量，覆盖率提升非常小的那个点，就是最优值。不同业务场景不一样，内容分散的知识库可以设 Top5，内容集中的设 Top2 也够。

9. 什么是上下文压缩？除了 Rerank 还有哪些方式？

答题思路：上下文压缩就是把检索到的长文档片段，压缩成只和问题相关的核心内容，再传给大模型，核心目的是减少噪声、节省 token、提升回答准确率。 除了 Rerank 精排筛选，还有三种常见方式： ① 句子级提取：把文档拆成句子，计算每个句子和问题的相关性，只保留相关的句子，去掉无关内容，粒度更细，压缩比更高； ② 大模型抽取：让大模型读完整文档片段，提取出和问题相关的关键信息，压缩效果最好，但多一次大模型调用，成本高延迟高； ③ 关键词过滤：基于规则匹配，只保留包含问题关键词的段落，实现最简单速度最快，但准确率低，适合简单场景。 Rerank 是效果、成本、速度平衡最好的方案，也是落地用得最多的，对压缩率要求特别高的场景再叠加句子级提取。

10. 对话记忆有哪些实现方式？各自优缺点？

答题思路：常用三种实现，各有适用场景： ① 全量记忆：保存完整的所有历史对话，信息最完整，没有丢失；缺点是对话一长 token 直接爆炸，成本高还容易超限，只适合短对话场景。 ② 滑动窗口记忆：只保留最近 N 轮对话，超过的直接丢掉，实现最简单，token 可控，是绝大多数业务场景的首选；缺点是早期的关键信息会丢失，长对话上下文断层。 ③ 摘要记忆：用大模型把历史对话压缩成摘要，只保留核心信息，token 占用非常小，能保留长对话的核心内容；缺点是细节信息丢失，有额外的大模型调用成本，适合超长对话场景。 我们落地用的是滑动窗口 + 摘要混合方案：最近 5 轮用原始对话保证细节，更早的对话压缩成摘要，兼顾细节和 token 成本，效果最好。

---

三、智能体（Agent）核心类

1. Agent 工具调用的完整流程是怎样的？

答题思路：以最经典的 ReAct 模式为例，是一个多轮循环的流程，直到任务完成： 第一步：Thought（思考），大模型拿到问题、历史对话、工具列表，分析当前该做什么，要不要调用工具，调用哪个工具； 第二步：Action（行动），输出要调用的工具名称，以及对应的入参； 第三步：Action Input（参数），按照工具定义的参数格式，输出具体的参数值； 第四步：Observation（观察），执行工具调用，拿到工具返回的结果，再把结果喂回给大模型； 第五步：回到第一步，大模型基于工具返回的结果继续思考，判断任务有没有完成，没完成就继续调用下一个工具，完成了就输出最终答案。 简单问题一轮循环就能完成，复杂多步任务可能要循环 3-5 轮。如果是原生 Function Calling 模式，没有显式的 Thought 步骤，模型直接输出工具名和参数，流程更简洁。

2. ReAct 模式的核心思想是什么？Thought、Action、Observation 分别代表什么？

答题思路：ReAct 的核心思想是模拟人类解决问题的方式：边思考边行动，把推理过程和工具执行结合起来，每一步行动都基于上一步的结果动态调整，而不是一次性生成所有答案。 三个核心要素：

• Thought：思考过程，是大模型对当前问题的分析，比如「用户问的是年假规则，属于知识库内容，我需要调用知识库检索工具」，Thought 的存在让 Agent 的行为可解释，也能减少错误调用；
• Action：要执行的动作，也就是调用哪个工具，对应工具的名称；
• Observation：工具执行后的返回结果，是下一步思考的事实依据，相当于人类做完一件事得到的反馈。 本质就是「思考→行动→拿到结果→再思考→再行动」的循环，直到问题解决。

3. ReAct 和 Plan-and-Execute 各有什么优劣？怎么选型？

答题思路：是两种完全不同的 Agent 规划模式，核心区别是「先规划再执行」还是「边想边执行」。 ReAct 模式：边思考边执行，一步一决策。优点是轻量，token 消耗少，延迟低，灵活度高，能根据中间结果动态调整方向；缺点是没有全局规划，复杂多步任务容易跑偏，走着走着忘了最初的目标，适合工具少、任务简单、单步就能完成的场景。 Plan-and-Execute 模式：先做整体规划，把大任务拆成多个子步骤，再按步骤依次执行。优点是有全局观，任务完成度高，逻辑连贯，不会跑偏；缺点是 token 消耗大，延迟高，规划错了容易一路错到底，调整不灵活，适合多工具、复杂多步骤的任务，比如做调研、写报告、多步骤业务流程。 选型看任务复杂度：80% 的简单知识库场景用 ReAct/Function Calling 就够了；复杂任务占比高的话，用 Plan-and-Execute。更合理的是做动态调度：先判断任务复杂度，简单问题走轻量模式，复杂问题自动升级到规划模式，兼顾成本和效果。

4. 怎么提升 Agent 工具调用的准确率？有哪些优化手段？

答题思路：从工具定义、Prompt、模型参数、解析层、重试机制五个维度优化，层层兜底： ① 工具定义层：工具描述写得越精准越好，明确写清楚「适用场景、不适用场景、入参格式、返回格式」，参数用 JSON Schema 严格定义，加字段说明和示例，描述越细模型选得越准； ② Prompt 层：系统 Prompt 强化格式要求，明确输出规则，加 2-3 个正确调用的 few-shot 示例，能大幅降低格式错误率； ③ 模型参数层：调低 temperature 到 0.1 以下，让模型输出更稳定，减少随机发散导致的格式错误和工具选错； ④ 解析容错层：不要严格要求模型输出完美格式，用正则从输出里提取工具名和参数，哪怕有多余的话术也能解析成功； ⑤ 重试机制：解析失败或者工具调用报错，把错误信息返回给模型，让它自己修正后重试，一般重试 1-2 次就能解决绝大多数错误。

5. 工具调用失败、解析错误怎么处理？有哪些兜底方案？

答题思路：分三层兜底，预防→重试→降级，保证服务不崩： 首先是预防层：前面说的优化工具描述、优化 Prompt、调低温度，从源头降低出错概率。 然后是重试层：如果是格式解析失败，把错误信息（比如「参数格式不对，应该是 JSON 格式」）返回给大模型，让它修正后重新输出，最多重试 2 次，大部分格式问题一次重试就能解决；如果是工具执行报错，比如参数非法、下游接口超时，也把错误信息返回，让模型判断是换参数重试还是换工具。 最后是降级层：重试多次还是失败，就触发降级：简单问题直接放弃工具调用，让大模型基于已有信息回答；复杂问题明确告诉用户「当前工具暂时不可用，请稍后再试」，绝对不能让 Agent 无限重试卡死。LangChain 里的 handle_parsing_errors 参数就是做解析错误兜底的。

6. 怎么防止 Agent 无限循环调用工具？

答题思路：三层防护，从检测到终止，保证不会死循环： ① 最基础的是最大迭代次数限制：设置 max_iterations，比如最多 5 轮循环，超过就强制终止，输出当前结果，这是最通用的方案，能覆盖 90% 的死循环场景； ② 重复调用检测：监控连续的工具调用，如果连续 3 次调用同一个工具、传入完全相同的参数，就判定为无效循环，强制终止，避免无意义的重复调用； ③ 模式检测：如果出现 A 工具→B 工具→A 工具→B 工具的交替循环，也判定为死循环，提前终止。 LangGraph 里可以通过条件边实现，在每次循环结束后判断当前迭代次数、调用历史，满足终止条件就直接跳转到结束节点，不会一直跑下去。生产环境必须加这个限制，不然异常场景会把大模型额度跑光。

7. LangGraph 和传统 LangChain Agent 有什么区别？优势是什么？

答题思路：核心区别是黑盒循环 vs 显式状态机。 传统 LangChain Agent 是黑盒的，整个思考 - 行动循环由模型内部控制，开发者只能配置工具和 Prompt，没法干预中间流程，想加个重试、加个人工介入、加个分支判断都很难，适合简单的 Demo 场景，可控性差，调试困难。 LangGraph 是显式的状态机编排，开发者自己定义节点（每个步骤）、边（流转逻辑）、条件分支、循环次数，整个流程完全可控。 优势非常明显：① 流程可控，能实现复杂的业务逻辑，比如重试、校验、人工审核、分支判断，想加什么节点就加什么；② 可观测性强，每个节点的状态都能拿到，每一步输入输出都清晰，调试排障非常方便；③ 扩展性好，新增能力只要加节点就行，不用重构整个 Agent。 对稳定性要求高、流程复杂的生产环境，LangGraph 是更合适的选择，我们项目就是从原生 Agent 重构到 LangGraph 的，稳定性提升非常明显。

8. LangGraph 的状态管理是怎么做的？怎么保证数据流转正确？

答题思路：LangGraph 用 ** 全局统一的 State（状态对象）** 来做数据流转，所有节点共享同一个状态，每个节点接收当前状态作为输入，执行完返回要更新的字段，框架自动合并到全局状态里，再传给下一个节点。 状态一般用 TypedDict 或者 Pydantic 定义，明确每个字段的类型，比如用户输入、改写后的 query、检索到的文档、工具调用结果、最终答案、迭代次数标记位等等。 保证数据流转正确的几个要点：① 节点职责单一，每个节点只修改自己负责的字段，不要乱改其他节点的字段，避免冲突；② 条件边逻辑严谨，分支判断的条件要写清楚，覆盖所有边界情况，不要出现死路；③ 加边界控制，比如循环节点加最大次数，防止无限循环；④ 复杂状态用 reducer 定义更新规则，比如列表类型的字段，定义成追加模式而不是覆盖模式，避免数据丢失。

9. 你了解哪些 Agent 编排模式？除了 ReAct 还有什么？

答题思路：从简单到复杂，常用的有五种编排模式，适用不同场景： ① 原生 Function Calling：大模型直接输出工具名和 JSON 参数，没有显式思考过程，格式稳定、速度快、token 省，是生产环境最常用的，适合绝大多数工具调用场景； ② ReAct 模式：思考 - 行动 - 观察循环，有显式 Thought，可解释性强，适合调试、需要追溯思考过程的场景，生产用得少； ③ Plan-and-Execute 模式：先规划拆分子任务再执行，适合复杂多步骤的长任务，任务完成度高； ④ 状态机模式（LangGraph）：显式定义节点和分支，完全可控，适合复杂业务流程、有强规则要求的生产场景，稳定性最高； ⑤ 多 Agent 模式：多个不同角色的 Agent 协同工作，比如产品 Agent、开发 Agent、测试 Agent，各司其职共同完成超大型复杂任务，复杂度最高，适合企业级复杂工作流。

10. 多工具协同场景下，工具之间的数据怎么传递？

答题思路：两种主流传递方式，各有适用场景： ① 全量上下文传递：每一步工具的执行结果都追加到全局对话上下文里，后面的工具和最终生成都能看到所有历史结果，靠大模型自己从中提取需要的信息。优点是实现简单，灵活度高，不用提前定义数据流转；缺点是上下文会越来越长，token 消耗大，信息多了模型容易提取错。适合工具少、流程短的简单场景。 ② 显式变量映射：规划阶段就定义好每一步的输入来自哪一步的输出，变量按定义传递，比如第二步工具的入参是第一步工具返回的某个字段。优点是精准，不会有信息干扰，token 省；缺点是实现复杂，要提前定义好流程，灵活度差。适合固定流程的多工具任务，比如 LangGraph 状态机模式就可以这么做，每个节点明确从状态里取对应的字段。

---

四、效果优化与评测类

1. RAG 的幻觉怎么优化？有哪些全链路手段？

答题思路：幻觉优化是全链路的事，不是只改 Prompt 就能解决，分检索侧、生成侧、工程侧三层优化： 检索侧（源头控制）：① 优化分块策略，保证每个块语义完整，提升召回准确率，让传给大模型的上下文都是正确相关的；② 加 Rerank 精排，减少无关噪声片段，噪声越少幻觉越少；③ 做 query 改写，提升检索匹配度，避免上下文和问题不相关。 生成侧（过程约束）：① Prompt 强约束，明确要求「仅基于提供的上下文回答，上下文里没有的就直接回答不知道，禁止编造」，加示例强化规则；② 调低 temperature 到 0.1 以下，减少随机发散；③ 加答案校验环节，生成答案后再调用一次大模型，校验答案是不是都来自上下文，有幻觉就重生成。 工程侧（兜底保障）：① 答案加引用溯源，标注每个结论来自哪篇文档的哪个片段，提升可信度，也方便用户核对；② 敏感场景加人工审核，高风险问题人工复核后再返回。 我们落地后幻觉率从最开始的 15% 降到了 3% 以内，核心就是检索侧提准确率，生成侧加约束。

2. query 改写是什么？为什么能提升检索效果？

答题思路：query 改写就是用大模型把用户的原始提问，转换成更适合检索的标准问句，再去向量库检索。 用户的真实提问经常有很多问题：① 口语化严重，比如「我想休年假咋弄」，和文档里的「员工年休假申请流程」表述差异大，向量匹配度低；② 多轮对话有指代，比如用户上一句问了年假规则，下一句问「那病假呢」，直接检索「病假」缺少上下文，搜不准；③ 表述模糊有歧义，改写后可以消歧。 改写的核心作用：补全省略的上下文、把口语化转成标准书面语、消除歧义、扩展同义词，让检索 query 和文档的语义匹配度更高，直接提升召回率。 实现方式有很多种，最常用的是大模型改写，还有多 query 生成（一个问题生成 3-5 个不同表述的问句一起检索），进一步提升召回覆盖率。多轮对话场景加 query 改写，召回率能提升 10%-20%，是成本极低收益很高的优化手段。

3. 怎么衡量 RAG 系统的效果好坏？有哪些核心指标？

答题思路：分三类指标，结合起来看才全面，不能只看单一指标： ① 检索侧指标：TopK 召回率、精确率。召回率是标准答案对应的内容有没有被检索出来，衡量漏不漏；精确率是检索出来的内容有多少是相关的，衡量准不准。是基础指标，检索不行生成肯定好不了。 ② 生成侧指标：忠实度（幻觉率）、答案相关性、信息完整度。忠实度看答案有没有编造内容，是不是都来自上下文；相关性看有没有答非所问；完整度看有没有覆盖所有要点。这部分最接近用户体验，一般用大模型自动评测 + 人工抽检。 ③ 线上业务指标：用户好评率、无答案率、追问率、解决率。是最真实的效果指标，直接反映用户的实际体验，所有技术优化最终都要落到业务指标提升上。 我们核心盯三个：检索 Top3 召回率、生成忠实度、线上用户好评率，分别对应检索质量、生成质量、用户真实体验。

4. 自动化评测体系怎么搭建？离线和线上分别怎么做？

答题思路：完整的评测体系是「离线基准评测 + 线上持续监控」两层，分别保障发版质量和线上稳定性。 离线基准评测：① 构建标准测试集，覆盖高频问题、边缘问题、易错场景，每个问题配标准答案和相关上下文，定期补充 bad case 进去，我们现在有 200 多条测试用例；② 建立版本基线，每个稳定版本的指标存下来作为对比基准；③ 嵌入 CI/CD 流程，每次发版前自动跑全量测试集，输出各项指标报告，核心指标低于基线 3% 就自动阻断发版，必须优化后才能上线。 线上持续监控：① 实时监控用户反馈的好评率、点踩率，下跌超过阈值自动告警；② 每日自动抽样 100 条问答，用大模型做自动评测，输出每日效果报表，监控趋势变化；③ 自动收集 bad case，定期归因分类，反哺优化。 两层结合，既保证发版不退化，又能及时发现线上的效果问题。

5. 大模型自动评测靠谱吗？怎么保证评测结果的稳定性？

答题思路：做相对对比非常靠谱，绝对分数仅做参考。大模型评测的优势是速度快、成本低、能批量跑，适合版本迭代时的对比测试；缺点是有一定的主观波动，绝对分数不能完全信。 保证稳定性的四个手段： ① 用更强的模型做评测器，比如用参数更大、能力更强的模型去评小模型的输出，一致性和准确率都更高，不要用同级别甚至更弱的模型评； ② 写严谨的评测 Prompt，明确每个维度的打分标准、扣分规则，附打分示例，减少模型的主观发挥空间，Prompt 越严谨波动越小； ③ 固定评测环境，评测模型的版本、参数、temperature 都固定死，不要随便换，保证前后版本的评测标准一致，才有对比意义； ④ 定期人工校准，抽 10%-20% 的用例人工打分，和自动评测结果对比，校准偏差，调整评测 Prompt。 核心是看相对值，也就是版本之间的分数涨跌，同一套标准下的对比是非常准的，不用纠结绝对分数是 80 分还是 85 分。

6. 召回率和准确率怎么平衡？TopK 值怎么确定？

答题思路：召回率和精确率是此消彼长的关系，TopK 越大，召回的内容越多，召回率越高，但无关内容也越多，精确率就越低；TopK 越小，精确率越高，但容易漏相关内容，召回率下降。 工业界的通用方案是两级召回架构，完美平衡两者：第一级粗召回，向量检索取 Top10/Top50，保证召回率，宁可多捞一点不要漏；第二级精排，用 Rerank 对候选做精排，只留 Top3/Top5 给大模型，保证最终上下文的准确率。这样既不会漏相关内容，又不会给大模型太多噪声。 确定 TopK 的方法：拿业务测试集做实验，画召回率随 TopK 增长的曲线，找拐点 —— 也就是 TopK 再增大，召回率提升非常小的那个点，就是最优的粗召回 TopK。精排后的 TopN 看上下文窗口和噪声容忍度，找收益递减的拐点。 最终的平衡标准是业务能接受的漏检率，比如要求 95% 的召回率，那就选能达到 95% 的最小 TopK 值。

7. 用户反馈闭环怎么做？怎么用反馈持续优化效果？

答题思路：完整的反馈闭环是「数据采集→归因分类→优化落地→效果验证」四步循环，形成持续迭代的飞轮。 第一步数据采集：不光有点赞点踩，还要让用户选点踩的原因，比如「答案不对」「答非所问」「不够详细」，同时记录当时的问题、检索结果、生成答案、用户反馈，完整存下来。 第二步归因分类：把 bad case 分成四类，对应不同的优化方向：① 检索问题：有答案但搜不到，优化分块、检索、query 改写；② 生成问题：检索到了但生成错了，优化 Prompt、调参数；③ 内容缺失：知识库没有相关内容，补文档；④ 体验问题：答案太长 / 太短，优化生成要求。 第三步优化落地：高频问题优先优化，检索类的优化分块、加改写样本；生成类的优化 Prompt；内容类的同步给运营补文档；还可以做自动优化，比如多次点踩的低质量片段自动加入检索黑名单。 第四步效果验证：优化后回归 bad case，看有没有解决，同时监控线上整体好评率的变化，确认优化有效。 闭环跑起来之后，系统效果会持续提升，不用靠开发调参数。

---

五、工程落地与运营类（企业级必问题）

1. 为什么要做 LLM 网关？它解决了什么问题？

答题思路：LLM 网关是大模型调用的统一入口，核心解决多模型场景下的「管理混乱、容灾薄弱、成本不可控、可观测性差」四大痛点。 没有网关的痛点：① 每家模型的接口、参数、SDK 都不一样，业务代码里到处都是模型调用，加个新模型要改 N 处业务代码；② 单家模型故障了只能手动切，服务中断时间长，没有容灾能力；③ Token 消耗分散在各个业务线，没法统一统计和管控，成本超了都不知道；④ 日志零散，出问题排查困难，也没法做统一的审计。 网关的核心价值：① 统一接入，屏蔽底层差异，业务层不用关心底层接的是哪家模型，加新模型不用改业务代码；② 容灾降级，单模型故障自动切备用，保障服务可用性；③ 成本管控，统一统计 Token 和费用，按业务线分摊，智能路由降本；④ 可观测性，所有调用统一日志、统一监控，方便排查问题和审计。 用户量小、只用一家模型的时候感受不明显，一旦接入多模型、对可用性有要求，网关是企业级的标配。

2. LLM 网关的核心功能有哪些？

答题思路：从基础到高级分五层，落地可以逐步叠加，不用一开始做全： ① 统一接入层：最基础的功能，适配不同厂商的大模型 API，对外提供统一的调用接口、统一的参数格式、统一的鉴权方式，屏蔽底层差异，业务接入只需要对接一次。 ② 流量管理层：限流、熔断、降级、负载均衡。限流控制每个业务的调用量，防止超额；故障模型自动熔断，不要一直发请求；故障时自动降级到备用模型；多实例负载均衡分摊流量。 ③ 智能路由层：根据问题自动选择最合适的模型，比如简单问题用便宜的小模型，复杂问题用好的大模型；或者按延迟、按成本路由，平衡效果和成本。 ④ 成本与审计层：统一统计所有调用的 Token 消耗、费用，按租户、按业务线分摊成本；所有调用留痕，支持审计追溯；统一设置配额，超额限流。 ⑤ 增强服务层：可选的高级功能，比如语义缓存、Prompt 统一管理、内容安全审核、敏感词过滤，在网关层统一做，不用每个业务都重复开发。 我们落地是先做了统一接入和容灾，再加了成本统计和智能路由，最后补了语义缓存，逐步迭代的。

3. 多模型容灾降级怎么设计？怎么防止雪崩？

答题思路：核心是分级降级 + 熔断保护 + 限流控制，绝对不能一故障就全量切流量，很容易把备用模型也打挂，造成雪崩，也就是两个模型都不可用，比单模型故障还严重。 完整的容灾设计： ① 故障检测与熔断：连续 N 次调用失败、超时率超过阈值（比如 5 分钟内超时率 > 20%），就判定模型故障，触发熔断，暂时不往这个模型发流量，避免无效请求堆积。熔断有半打开状态，每隔一段时间发少量请求探活，模型恢复了再逐步切回流量。 ② 分级降级策略：不要一刀切全量降级，分场景分优先级：非核心场景、简单问答先切到便宜的备用小模型；核心复杂场景保留主模型重试，优先保障核心业务。降级速率要控制，逐步把流量切过去，不要瞬间全量。 ③ 限流保护：每个备用模型都设置 QPS 上限，降级的时候严格控制流量速率，不能超过备用模型的承载上限，防止把备用模型也打挂，引发雪崩。 ④ 恢复机制：主模型恢复后，先切 10% 小流量验证，没问题再逐步放大到全量，不要一下子切回去，避免反复故障。 我们之前踩过全量降级的坑，加了熔断分级之后就再也没出现过雪崩问题。

4. 大模型调用成本优化有哪些常用手段？

答题思路：四大类优化手段，按投入产出比从高到低排序： ① 缓存优化：收益最高，投入最少。分精确缓存和语义缓存，重复问题直接返回结果，不用调用大模型。企业知识库场景重复问题很多，语义缓存命中率能到 30%-50%，相当于直接省一半成本，是首选优化。 ② Token 压缩优化：减少单次调用的 Token 数。比如精简系统 Prompt，去掉没用的套话；控制检索片段数量，做上下文压缩，只传相关内容；限制回答长度，不要生成冗余内容。单次调用 Token 减少 20%，成本就降 20%。 ③ 模型分级路由：不同难度的问题用不同等级的模型。简单常识、短问答用便宜的小模型，复杂推理、长上下文才用贵的大模型。我们统计过 80% 的简单问题用小模型就能搞定，整体成本能降 30% 以上。 ④ 架构层优化：批处理合并请求，把短时间内的多个请求合并成一批推理，提升 GPU 利用率，适合私有化部署场景；简单逻辑用规则或者小模型处理，不用都调大模型。 我们落地了缓存 + Token 压缩 + 分级路由，整体大模型成本降了 40% 多，效果几乎没有下降。

5. 语义缓存是什么？和普通 KV 缓存的区别？

答题思路：普通 KV 缓存是精确匹配，用户的问题必须和缓存的 key 一字不差才能命中，但自然语言表述非常灵活，同一个意思有 N 种问法，精确缓存的命中率非常低，可能不到 5%，几乎没用。 语义缓存是基于向量相似度匹配的：把用户的问题向量化，和缓存里的问题向量算相似度，相似度超过阈值就算命中，直接返回缓存的答案。意思相近的不同问法都能命中，命中率非常高，企业知识库场景能到 30%-50%，降本效果非常明显。 语义缓存的几个关键点：① 相似度阈值要设合理，太高命中率低，太低容易误命中，一般设 0.92-0.95；② 知识库更新的时候要主动失效对应主题的缓存，不然会返回旧答案；③ 缓存可以分层，高频问题存久一点，低频问题设短 TTL，节省存储空间。

6. 多租户场景下，向量数据有哪些隔离方案？各有什么优劣？

答题思路：三种方案，隔离等级从低到高，成本也从低到高： ① 共享集合 + 标量过滤：所有租户的向量存在同一个 Collection 里，每个向量带 tenant_id 标量字段，查询的时候强制加 tenant_id 过滤。优点是成本最低，运维最简单，资源利用率高；缺点是逻辑隔离，隔离性弱，数据量大了单集合性能会下降，适合大量中小租户的场景。 ② 每个租户独立 Collection：每个租户单独一个向量集合，物理隔离，查询性能互不影响，数据安全更有保障；缺点是运维成本高，租户多了管理麻烦，资源利用率低，小租户也占一个集合的资源，适合少量大租户、对数据安全要求高的场景。 ③ 独立部署实例：每个租户单独一套 Milvus 集群，完全物理隔离，安全等级最高；缺点是成本极高，运维复杂度拉满，只有对数据安全要求极高的大客户才会用。 我们落地是混合方案：付费大租户用独立集合，免费小租户用共享集合 + 过滤，兼顾成本和安全，是 SaaS 产品的通用方案。

7. 多租户权限管控怎么做？怎么防止越权？

答题思路：多层防护，层层校验，核心是过滤条件不能由前端控制，必须后端强制拼接。 ① 应用层身份校验：用户请求带 Token，后端解析出用户 ID、租户 ID、角色权限，绝对不接受前端传的租户 ID，防止前端篡改。 ② 数据层强制过滤：所有检索请求，后端强制拼接租户过滤条件，封装统一的检索接口，业务层不能直接调用向量库，必须走封装好的接口，从代码层面避免漏写过滤条件导致越权。独立集合模式的话，直接限制用户只能访问自己租户对应的集合。 ③ 细粒度权限控制：除了租户级，还可以做部门级、文档级的权限，向量里存部门 ID、权限标签，查询的时候一起过滤，不同角色的用户能搜到的文档范围不一样。 ④ 审计层追溯：所有查询请求留日志，记录谁、什么时候、查了什么内容，出现问题可以追溯。 最容易踩的坑就是过滤条件写在前端，或者业务代码里漏加过滤，导致跨租户数据泄露，所以一定要封装统一的底层接口，强制加过滤。

8. 全链路监控要做哪些指标？怎么分层？

答题思路：分三层监控，从业务到技术，出问题逐层定位，每层关注不同的指标： ① 业务效果层：最上层，反映用户体验。核心指标：日活用户数、总提问量、用户好评率 / 点踩率、无答案率、平均对话轮次、解决率。这层出问题说明用户体验下降了，是最需要优先关注的。 ② 链路性能层：中间层，反映服务稳定性和性能。核心指标：请求量、错误率、平均响应时间、首 token 延迟、各环节耗时（检索耗时、Rerank 耗时、大模型耗时）、Token 消耗量、Agent 工具调用成功率。这层出问题说明系统性能或者依赖服务有问题。 ③ 基础设施层：最底层，反映底层资源健康度。核心指标：Milvus 集群状态（CPU、内存、查询延迟）、大模型接口可用性、服务器 CPU / 内存 / 磁盘、缓存命中率、网关状态。这层出问题会影响上层所有服务。 告警也是分层级的，基础设施层故障优先处理，因为影响面最大。

9. 告警体系怎么设计？怎么避免告警风暴？

答题思路：核心是分级告警 + 收敛抑制，不然告警太多没人看，等于没有告警。 首先是分级：

• 紧急告警：服务不可用、错误率飙升超过 5%、核心依赖挂了，即时通知（电话 / 短信），必须马上处理；
• 重要告警：性能下降、效果指标下跌、错误率轻微上升，工作时间通知（企业微信），当天处理；
• 一般告警：消耗上涨、非核心指标波动，日报汇总，第二天看就行。 然后是收敛防风暴：
• 持续时间阈值：不是一出现就告警，比如错误率连续 3 分钟超标才告警，过滤偶发的抖动；
• 相同告警聚合：同一个告警短时间内只发一次，不要每分钟都发；
• 告警抑制：高级别告警触发的时候，抑制它导致的低级告警，比如大模型挂了，就不用再发一堆检索超时、生成失败的告警；
• 非工作时间静默：非紧急告警非工作时间不发，第二天汇总发。 还要定期清理无效告警，那些经常误报、没人处理的告警直接删掉，保持告警的有效性，不然大家都会麻木。

10. RAG 怎么和企业其他系统集成？常见方式有哪些？

答题思路：四种集成方式，耦合度从低到高，开发量从小到大： ① API 接口集成：最常用的方式，RAG 系统提供标准 HTTP API 接口，其他系统通过 API 调用问答能力，耦合度最低，开发量最小，对接最快，适合所有系统的基础接入，一般配合鉴权使用。 ② 页面嵌入集成：用 iframe 或者 JS SDK 把问答页面嵌到业务系统里，用户不用跳转系统，直接在当前页面提问，体验更好，适合 OA、客服系统、内部门户这类场景，需要做单点登录打通权限。 ③ Webhook 事件驱动：双向同步，比如企业文档系统更新了，通过 Webhook 自动同步到 RAG 系统更新向量库；RAG 解决不了的问题，自动通过 Webhook 创建工单，适合和业务流程打通。 ④ 深度业务集成：把 RAG 能力深度嵌入业务流程，比如审批的时候自动校验合规性、客服坐席自动推荐答案、写文档自动引用知识库内容，价值最大，但开发量也最大，需要和业务系统深度定制。 一般项目都是先从 API 接入开始，用起来之后再逐步深化集成。

---

六、故障排查与场景题（实战经验考察）

1. 用户反馈知识库答非所问，你怎么一步步排查？

答题思路：先复现，再分层定位，从结果倒推根因，不要上来就瞎调参数。 第一步：拿用户的原始问题本地复现，打开调试日志，看完整的检索结果和生成过程。 第二步：判断是检索侧问题还是生成侧问题：看 Top3 检索结果里有没有正确答案，如果相关内容都没捞到，就是检索的问题；如果检索结果里有正确内容，但大模型没按内容答，就是生成的问题。 如果是检索侧问题，继续拆： ① 看用户问题是不是口语化、有指代，没做 query 改写，导致和文档语义匹配度低； ② 看分块是不是不合理，正确答案被拆到了不同的块里，每个块都只有一半，相似度不够； ③ 看 Embedding 或者索引是不是异常，比如模型版本不匹配、索引损坏，导致检索乱了； ④ 看 Rerank 是不是排序失真，把相关的内容压到了后面，Top3 没覆盖到。 如果是生成侧问题，继续拆： ① 看 Prompt 的幻觉约束是不是不够，大模型自由发挥了； ② 看 temperature 是不是设太高了，输出发散； ③ 看上下文是不是噪声太多，无关内容干扰了大模型判断。 定位到根因之后再针对性修复，修复后回归验证。

2. 大模型 Token 超限了怎么处理？有哪些优化方案？

答题思路：全链路分层压缩，从占比最大的部分开始优化，实在不行再换大窗口模型。 ① 对话记忆层：占比很高，优先优化。把全量记忆改成滑动窗口，只保留最近 5 轮；超长对话用摘要记忆，把早期对话压缩成摘要，能省非常多 token； ② 检索上下文层：也是大头，控制召回的片段数量，不要贪多，Rerank 后只留最相关的 Top3；做上下文压缩，去掉文档里的无关句子，只保留和问题相关的部分； ③ Prompt 层：精简系统 Prompt，去掉冗余的套话、没用的示例，只保留核心规则，系统 Prompt 一般能压缩 30%-50%； ④ 生成层：限制最大生成长度，不要让大模型输出太长的无关内容； ⑤ 兜底方案：调用前做 token 计数，如果还是超限，按优先级截断，优先保留最新的对话、最相关的上下文，防止直接报错。 如果以上都做了还是不够，再考虑换更大上下文窗口的模型，这是成本最高的方案。

3. Agent 频繁调用工具失败，可能有哪些原因？怎么解决？

答题思路：分四类原因，对应不同的解决方法，从常见到少见排查： 第一类：格式解析失败，最常见。大模型不按规定的 JSON 格式输出，夹杂多余的思考话术、 markdown 格式，导致解析报错。 解决：优化 Prompt 强化格式要求，加 few-shot 示例；加容错解析，用正则从输出里提取工具名和参数，不用严格匹配完整格式；开自动重试，把错误返回给模型让它修正。 第二类：工具定义问题。工具描述太笼统，模型不知道什么时候该用；参数说明不清楚，模型传错参数类型。 解决：细化工具描述，写清适用场景、不适用场景、入参格式、返回示例；用 JSON Schema 严格定义参数类型、必填项，减少模型发挥空间。 第三类：工具本身执行报错。比如参数非法、下游接口超时、权限不够、依赖服务挂了。 解决：工具内部加异常捕获，返回清晰的错误信息，不要直接抛异常；加重试机制，超时自动重试；做好下游服务的监控，及时发现依赖故障。 第四类：规划错误死循环。复杂问题模型规划不对，反复调用同一个工具，永远解决不了。 解决：加最大迭代次数限制，到点强制终止；复杂场景换 Plan-and-Execute 模式，先规划再执行，减少边想边做的错误。

4. 系统响应耗时突然变长，怎么排查？

答题思路：先拆解全链路耗时，看哪个环节涨了，再定位具体原因，大模型推理占 70% 以上，优先查。 第一步：看全链路耗时分布，拆成检索耗时、Rerank 耗时、大模型耗时、Agent 调度耗时，看哪个环节涨幅最大。 如果是大模型耗时涨了，最常见： ① 大模型服务商那边限流排队了，高峰时段请求多，排队时间变长，看首 token 延迟是不是涨了很多； ② 输入 token 量变多了，比如对话历史累积变长、召回的片段变多，输入越长推理越慢； ③ 模型本身性能下降，或者切到了性能差的备用模型。 如果是检索耗时涨了： ① 向量库数据量激增，索引性能跟不上，查询变慢； ② Milvus 节点负载高、内存不够、索引失效，导致查询延迟上涨； ③ Rerank 候选量变多，重排耗时增加。 如果是 Agent 耗时涨了： ① 问题变复杂，工具调用轮次变多，多轮循环导致总耗时变长； ② 工具调用超时，重试导致耗时增加。 最后查基础设施：服务器 CPU 内存跑满、网络延迟升高、依赖服务性能下降，都会导致整体耗时变长。

5. 上线反馈闭环后检索效果反而下降了，可能是什么原因？

答题思路：大概率是负反馈误伤或者优化过度，按优先级排查： ① 负反馈阈值太低，误伤正确内容。比如用户因为答案太长、排版不好、不是自己想要的角度点踩，不是内容错误，但系统把对应的文档片段拉黑了，导致正确内容搜不到。很多用户点踩并不是检索的问题。 ② 反馈类型没区分，所有点踩都作用于检索。比如生成幻觉、答案太简略这类生成侧的问题，也去拉黑检索片段，反而把正确内容搞没了，越优化越差。 ③ 反馈数据有偏差，优化过度。某一类问题反馈特别多，针对性优化的时候调得太狠，导致其他场景的检索效果下降，相当于过拟合了少数反馈样本。 ④ 黑名单粒度过粗。整篇文档、整个块都拉黑，里面其实有很多正确的内容，连带被屏蔽了，导致相关内容召回不到。 排查方法：先拉最近加入黑名单的片段，看是不是被误伤的；再看负反馈的原因分布，是不是大部分都不是检索问题；最后做 AB 测试，关掉反馈优化看效果有没有恢复。

6. 离线评测指标很好，线上用户反馈效果差，为什么？

答题思路：核心是离线评测和真实线上场景脱节，常见四个原因： ① 测试集分布不对，和真实用户提问差异大。测试集都是人工构造的标准、完整的问句，但线上用户的提问口语化、有指代、不完整，离线测的都是模型擅长的标准问法，线上真实问法就不行了。这是最常见的原因。 ② 测试集泄露，过拟合了测试集。优化的时候对着测试集调参数、加样本，离线分数刷得很高，但泛化能力差，线上没见过的问题效果就差。 ③ 线上线下环境差异。比如离线用的是最新的文档，线上文档更新不及时；离线检索参数和线上不一样；模型版本有差异，都会导致离线效果和线上不一致。 ④ 指标选择偏差，只看客观指标不关注用户体验。比如离线看忠实度很高，答案都来自上下文，但答案太啰嗦、逻辑乱、抓不住重点，用户体验还是差，客观指标和主观体验脱节。 解决方法：测试集多用线上真实的用户提问，不要全靠人工编；定期更新测试集，补充 bad case；线上做抽样人工评估，不要只信离线指标。

7. 知识库更新后，用户还收到旧答案，怎么排查？

答题思路：从缓存到数据逐层查，优先查缓存，因为缓存问题概率最高。 第一步：查缓存层。是不是语义缓存、结果缓存没失效，固定 TTL 还没到期，还在返回旧内容；网关层、CDN、前端有没有缓存。这个是最常见的，文档更新了但缓存没清，用户拿到的还是旧的。 第二步：查向量库更新任务。是不是增量更新任务失败了，旧的向量还在库里，新的没写进去；是不是只加了新的，没删掉旧的，新旧混在一起，检索到了旧片段；是不是更新有延迟，还在处理队列里没生效。 第三步：查应用层。是不是服务有本地内存缓存，文档列表、元数据缓存没刷新；是不是前端做了本地缓存，用户浏览器存了旧答案。 紧急处理：先手动失效对应问题的缓存，让用户能拿到正确答案；再完善更新机制，文档更新的时候主动触发各层缓存失效，重要内容缩短缓存时间，不要等 TTL 自动过期。

---

七、高阶与前沿方向类（加分深挖题）

1. 知识图谱增强 RAG 解决了什么痛点？

答题思路：纯向量 RAG 擅长非结构化文本的语义匹配，但对结构化关系类的问题有天然短板，知识图谱就是补这个短板的，核心解决三个痛点： ① 关系推理能力弱。比如审批流程有几个节点、部门的隶属关系、组件之间的依赖关系，这类问题答案散在好几个不同的文档片段里，纯向量检索只能捞到零散的碎片段，串不起来完整的关系链，大模型很容易答漏节点、说错关系。知识图谱能直接给出准确的实体 - 关系链条，保证逻辑正确。 ② 结构化信息遗漏。比如流程的多个节点、公式的多个参数、产品的多个规格，散在不同的文档块里，向量检索可能只捞到其中一部分，答案不完整。知识图谱能把某个实体的所有关联信息都完整返回，不会漏。 ③ 减少幻觉。知识图谱里的三元组是结构化的事实，可信度非常高，大模型基于图谱信息回答，比纯靠自由文本生成更不容易编造内容，相当于给了明确的事实约束。 注意知识图谱不是替代向量检索，是补充，两者结合效果最好：非结构化的长文本、描述性内容用向量检索，结构化的关系、流程、实体用知识图谱。

2. 知识图谱和向量检索的结果怎么融合？

答题思路：三种主流融合方式，在不同阶段融合，复杂度和效果依次提升： ① 检索层融合（最常用）：召回阶段就把两者的结果合并，一起传给大模型。把知识图谱查询到的结构化关系结论，当成一个特殊的文档片段，和向量检索的文本片段拼在一起，共同作为上下文。优点是实现最简单，改动最小，性价比最高，绝大多数场景用这种就够了，我们落地用的就是这种。 ② 生成层融合（高精度）：大模型先基于向量检索的内容生成第一版答案，然后再用知识图谱的事实去校验和修正答案，把错误的关系、遗漏的节点补上。优点是准确率更高，能进一步减少幻觉；缺点是多一次大模型调用，成本高延迟高，适合对准确率要求特别高的场景。 ③ 深度融合（高复杂度）：把知识图谱的实体向量和文本向量融合在一起，做联合检索，实体和文本一起召回。优点是效果最好，检索阶段就能利用图谱信息；缺点是技术复杂度最高，需要改向量表示，落地成本很高，一般只有大厂才会做。 落地选型原则：优先检索层融合，投入小见效快；效果不够再考虑生成层校验，不要一上来就搞深度融合，属于过度设计。

3. 多模态 RAG 怎么处理表格、图片这类非文本内容？

答题思路：核心原则是保留结构信息，转成可检索的语义单元，不能直接 OCR 成零散文字，不然结构全丢了，检索也没用。不同类型的内容处理方式不一样： ① 表格类：做结构化提取，转成 Markdown 或者 HTML 格式，保留行列关系、表头对应关系，再按表格整体或者按行分块，不能拆成零散的文字。比如产品参数表，转成 Markdown 之后，每一行的参数和对应值是绑定的，检索到就能看懂。 ② 普通图片（带文字的截图、配图）：用 OCR 提取所有文字，再加上所属章节的上下文，做成一个完整的文档块，不能只有 OCR 的零散文字，不然不知道对应的是哪部分内容。 ③ 流程图、架构图、组织架构图这类视觉结构化内容：纯 OCR 只能拿到一堆组件名，关系全丢了，要用多模态大模型解析图片，生成完整的文字描述，比如「这是员工入职审批流程图，节点依次是提交申请→部门负责人审批→HR 审批→入职办理」，把结构关系转换成文字描述，再做分块检索。 关键是所有非文本内容，都要带上所属的章节、上下文信息，不然检索出来孤零零的内容，不知道对应哪部分，大模型也没法用。

4. 多模态知识图谱和普通文本图谱有什么区别？

答题思路：核心区别是三元组的来源不同，能覆盖的内容范围不同。 普通文本知识图谱，只能从纯文本内容里抽取实体和关系三元组。碰到图片、图表、流程图这类非文本内容，只能先做 OCR 转成文字，但 OCR 之后结构信息全丢了，比如流程图的先后顺序、架构图的依赖关系、表格的对应关系，都抽不出来，只能拿到一堆零散的实体名，关系全错或者全丢。 多模态知识图谱，是直接用多模态大模型解析图片、表格、图表、流程图，从视觉信息里直接识别实体和它们之间的关系，抽取三元组。能完整保留视觉内容里的结构化关联信息，不会因为转文字丢失结构。 它解决的核心问题就是：非文本视觉内容的结构化知识提取，让架构图、流程图、组织图、统计表格里的关系信息，也能被检索和利用，补齐了纯文本 RAG 在多模态场景下的关系推理短板。 落地难点是多模态抽取的准确率比文本低，需要更多的人工校验，成本更高，一般优先处理高频的核心图表，不用全量做。

5. 私有化部署 RAG，核心性能瓶颈在哪？怎么优化？

答题思路：私有化部署 70% 以上的性能瓶颈都在大模型推理，其次是向量检索，工作流调度占比很低，优化按优先级从高到低来，先解决最大的瓶颈。 第一层：推理层优化，收益最高。 ① 换高性能推理引擎，比如 vLLM、TensorRT-LLM，替换原生 HuggingFace 推理，同等硬件下吞吐能提升 3-10 倍，是必做的优化； ② 模型量化，用 4bit AWQ 量化，显存占用降一半，速度还能更快，效果损失很小，几乎感知不到； ③ 批处理调度，把多个请求合并成一批推理，提升 GPU 利用率，最大化吞吐。 第二层：检索层优化。 ① 优化 Milvus 索引，数据量大用 HNSW 索引，牺牲一点精度换查询速度； ② 加查询缓存，高频问题直接返回结果，减少重复查询； ③ 控制召回数量，不要贪多，减少后续处理开销。 第三层：工作流层优化。 ① 无依赖节点并行执行，比如向量检索和知识图谱查询，两个互不依赖，同时跑，不用串行等，能省一半的检索时间，LangGraph 原生支持； ② 异步调度，所有 IO 密集型节点改成异步，提升并发处理能力。 第四层：业务层优化，加语义缓存、请求合并、限流削峰，从流量侧减少计算压力。 我们实测 7B 模型 + vLLM+AWQ 量化，单张 A10 能扛 20-30QPS，首 token 延迟 500ms 左右，完全满足中小规模企业使用。

6. vLLM 为什么能大幅提升推理速度？核心原理是什么？

答题思路：核心是解决了大模型推理里的两个老大难问题：KV 缓存显存浪费严重和请求串行处理 GPU 利用率低。 第一个核心技术：PagedAttention（分页注意力）。 大模型推理的时候，每个请求都要存 KV 缓存，原生实现是给每个请求预留连续的大显存，但生成长度不确定，会预留很多没用的空间，显存碎片非常多，利用率极低。PagedAttention 借鉴了操作系统的虚拟内存分页思想，把 KV 缓存分成固定大小的块，每个块存固定数量的 token 的 KV 值，块不需要连续，用页表记录映射关系。这样显存利用率大幅提升，能同时塞更多的请求进去做批处理，是 vLLM 高吞吐的核心。 第二个核心技术：连续批处理（Continuous Batching）。 原生批处理是静态批，要等一批所有请求都生成完，才能处理下一批，快的请求要等慢的，GPU 很多时间在空转。连续批处理是动态的，只要有请求生成完成，就立刻补新的请求进去，不用等整批结束，GPU 一直保持满负载，利用率拉得非常高。 再加上算子融合、量化支持、多卡并行这些工程优化，整体下来同等硬件下，吞吐能比原生推理高 3-10 倍，是现在私有化部署的标配推理引擎。

7. LoRA 微调的原理是什么？为什么能轻量化？

答题思路：LoRA 全称低秩适配（Low-Rank Adaptation），核心思想是：大模型全量微调的时候，权重的更新矩阵本质是低秩的，也就是可以分解成两个小矩阵的乘积，不需要更新整个大的权重矩阵。 具体实现：冻结基座模型的所有权重，只在 Transformer 的注意力层旁边，加两个小的低秩矩阵 A 和 B，A 是降维矩阵，B 是升维矩阵，训练的时候只更新这两个小矩阵的参数。推理的时候，把两个矩阵的乘积累加到原权重上就行，和全量微调的效果类似，但可训练的参数量只有千分之几到百分之几。 为什么能轻量化：① 显存需求低，因为不用存全量参数的梯度和优化器状态，训练显存只要全量微调的几分之一，消费级显卡就能跑 7B 模型；② 训练速度快，参数量少，训练速度快很多，成本低；③ 不会灾难遗忘，基座参数不动，不会破坏模型原来的通用能力；④ 多任务切换方便，不同任务训练不同的 LoRA 适配器，用的时候加载对应的就行，不用换整个模型。 是目前企业垂直领域轻量化微调的首选方案，性价比非常高。

8. 微调后怎么防止灾难遗忘？

答题思路：灾难遗忘就是模型学了新领域的知识之后，把原来的通用能力忘了，通用问题回答效果下降。可以从几个层面预防： ① 技术选型上，优先用 LoRA 这类增量微调方法，本身就不修改基座模型的原始参数，只会加少量适配器参数，灾难遗忘的风险比全量微调小非常多，是最基础的保障。 ② 训练数据上，做混合训练，在领域训练数据里混入一定比例的通用样本，比如通用问答、指令数据，比例大概 10%-20%，训练的时候同时学习领域知识和通用能力，不会把通用的东西忘光。 ③ 训练参数上，调小学习率，不要设太大；LoRA 的秩不要选太高，秩越高可训练参数越多，越容易过拟合和遗忘；控制训练轮次，不要训太多 epoch，早停防止过拟合，过拟合也会表现为遗忘。 ④ 架构上，多领域场景用多个独立的 LoRA 适配器，每个领域一个，用哪个加载哪个，不要把所有领域都塞到一个适配器里，互相干扰最小，完全不会有跨领域的遗忘问题。

---

八、项目经历复盘类（必问开放题）

1. 这个项目里你负责了哪些部分？核心贡献是什么？

答题思路：用 STAR 结构，分模块讲，每个贡献带量化结果，不要只罗列做了什么。 我主要负责整体架构设计、核心模块开发、效果与成本优化三部分： ① 架构设计：主导了从原生 Agent 到 LangGraph 工作流的架构重构，搭建了基于 LangGraph+Milvus + 通义千问的 RAG+Agent 整体架构，支持多工具智能调度，系统稳定性提升，后续扩展新工具不用改主链路。 ② 核心模块开发：落地了文档分块、两级检索（向量 + Rerank）、query 改写、对话记忆、Agent 工具调度等核心模块；优化了分块策略和检索链路，引入 BGE Rerank 之后，Top3 检索准确率从 60% 提升到了 90%+。 ③ 效果与成本优化：搭建了自动化评测体系和用户反馈闭环，驱动效果持续迭代，线上用户好评率提升到 92%；落地了语义缓存、模型分级路由等成本优化方案，单请求大模型成本降低 40% 以上。 ④ 高阶能力落地：主导了 LLM 网关、轻量知识图谱增强等高阶模块的落地，补齐了容灾、关系类问题准确率的短板。 突出自己是主导角色，有量化的成果，体现价值。

2. 项目里你碰到的最大难点是什么？怎么解决的？

答题思路：选一个真实的、有复杂度的技术难点，完整讲清楚背景、问题、方案、结果，体现解决问题的能力。 举个例子可以这么说： 最大的难点是流程类、组织关系类问题的准确率低，用户投诉很多。 背景：公司的审批流程、部门架构这类问题非常多，纯向量检索的效果很差，经常答漏节点、说错隶属关系，这类问题的好评率只有 60% 多，是投诉重灾区。 问题根因：这类问题的答案散在不同的文档片段里，比如入职流程的五个节点，分别在三个不同的文档块里，向量检索只能捞到其中一两个片段，大模型串不起来完整的逻辑，就会答漏或者答错。 解决方案：我做了轻量知识图谱增强的方案。首先从制度、流程类文档里，用大模型批量抽取「实体 - 关系 - 实体」三元组，人工抽检校准后构建轻量知识图谱；然后改造检索链路，用户提问时先从问题里提取实体，查图谱拿到结构化的关系结论，再和向量检索的文本片段融合，一起喂给大模型。 结果：上线之后，流程关系类问题的准确率提升了 30%+，好评率从 62% 升到了 93%，这类问题的投诉基本没有了。而且用的是 NetworkX 轻量图谱，不用单独部署图数据库，落地成本很低。 重点讲清楚你怎么分析问题、怎么选方案、拿到了什么量化结果。

3. 项目的性能指标是多少？QPS、延迟大概是什么水平？

答题思路：分场景说，符合真实落地水平就行，不要吹得太离谱。 我们线上 SaaS 版本的情况：

• 平均响应时间：简单单轮问答平均 1.5 秒左右，复杂的多工具调用 Agent 任务平均 3-5 秒；
• 并发能力：单套服务稳定扛 10QPS 没问题，峰值可以到 15QPS，瓶颈在大模型接口的并发限额，扩容的话可以线性加；
• 错误率：整体错误率低于 1%，做了多模型容灾之后，可用性达到 99.9%； 私有化部署的情况：用 7B 开源模型 + vLLM 推理 + AWQ 量化，单张 A10 显卡，能扛 20-30QPS 的并发，首 token 延迟 500ms 左右，端到端简单问答 2 秒以内，完全满足中小规模企业内部使用。 可以补充说瓶颈主要在大模型推理，后续并发上来可以横向扩容推理节点，架构是支持水平扩展的。

4. 如果让你重新做这个项目，你会做哪些优化？

答题思路：体现复盘能力和技术深度，分架构、工程、效果、成本几个维度说，不要说当初做错了，要说可以做得更好、少走弯路。 ① 架构选型上：一开始就用 LangGraph 做状态机编排，不用先做原生 Agent 再重构，少走很多弯路。早期为了快用了原生 Agent，后面业务复杂了之后流程控不住，调试排障特别麻烦，重构花了不少时间，一开始就选 LangGraph 会更顺。 ② 工程体系上：更早搭 LLM 网关和自动化评测体系。最开始只有单模型，也没评测，每次发版全靠人工测，经常上线出问题，后来补了网关和评测卡点，发版质量才稳下来，早做的话能省很多线上排查的时间。 ③ 效果迭代上：更早搭用户反馈闭环，用数据驱动优化，而不是凭感觉调参数。前期都是开发自己调，效果提升很慢，后来有了反馈数据，针对性优化，效率高很多。 ④ 成本管控上：提前做语义缓存和分级路由，前期没在意成本，用户量上来之后大模型费用涨得很快，后来做了优化降了 40%，早做的话能省不少成本。 体现你有复盘反思的能力，知道不同阶段的优先级，能从项目里总结经验。

5. 这个项目接下来还有什么可以迭代的方向？

答题思路：分短期、中期、长期说，结合业务价值，体现规划能力，不要瞎列技术名词。 短期（效果体验）：做多模态 RAG，支持图片、表格、流程图的解析检索，现在很多文档里的图表还不能很好的覆盖；优化 Agent 的规划能力，复杂任务的完成率再提一提。 中期（工程能力）：完善 LLM 网关的智能路由和容灾能力，支撑更多的模型接入；做全链路的可观测平台，问题排查更方便；做多租户的精细化权限管控，支持更细粒度的文档权限。 长期（前沿探索）：积累足够的领域数据之后，做领域轻量化 LoRA 微调，进一步提升垂直领域的回答风格和推理能力；探索多 Agent 协作，支持更复杂的业务流程，比如自动写报告、自动处理审批流程；做多模态知识图谱，进一步提升结构化问题的准确率。 每个方向都要说清楚业务价值，不是为了做技术而做技术。

6. 你觉得做企业级 RAG 系统，最重要的是什么？

答题思路：体现落地思维，不要说技术越牛越好，要结合企业场景说。 我觉得最重要的是场景匹配和持续迭代，没有放之四海而皆准的最优架构。 很多人一开始就想搭最完美的架构，堆一堆技术，知识图谱、微调、多 Agent 全上，其实根本没必要。企业级系统首先要解决业务问题，初期先跑通核心链路，解决 80% 的常见问题，快速上线用起来；用户量上来了，稳定性要求高了，就补容灾、补监控、补网关；运营起来了，就补数据体系、补反馈闭环、补内容迭代；碰到特定场景的短板，再针对性加能力，比如流程类问题多就加知识图谱，成本高就加缓存和路由。 技术从来不是越复杂越好，能稳定解决业务问题、投入产出比最高的方案，才是最好的方案。而且 RAG 系统不是上线就完事了，是需要持续迭代的，靠用户反馈、靠数据驱动不断优化，才能越用越好。