9、安全、评测、部署与可观测性

Q9-1. 你会如何评估一个 RAG 或 Agent 系统的效果？

评估先拆成离线评测和在线评测，再把问题拆到具体层级，而不是只盯一个总分。

如果是 RAG，通常按两层看：

• 检索层：相关内容有没有被召回，引用片段对不对，badcase 是卡在切块、召回、重排，还是过滤。
• 生成层：答案是不是忠实于证据，引用是否正确，无依据时能不能拒答，最终回答对业务有没有帮助。

如果是 Agent，评测应分成两类：

• 轨迹级评测：有没有选对工具、参数对不对、有没有无效循环、是不是过早结束。
• 结果级评测：最终任务有没有完成，输出质量和用户体验是否达标。

在线评测则看用户满意度、转人工率、任务中断率、耗时、badcase 类型分布。对于 Agent，还要看工具调用成功率、重试率、循环次数和人工兜底比例。

自动评测上，通常不会只押某一种方案，而是把规则评测、LLM-as-a-judge 和人工抽检结合起来。规则和 LLM 评测适合放大规模、做回归，人工抽检负责兜住高风险误判和评价漂移。

更重要的是评测不能只告诉你“分数变低了”，而要能定位到底是哪一层出问题。比如召回差、上下文组装差、生成幻觉、工具失败、终止条件不合理，这些问题的修法完全不同。

更推荐的评测闭环是：先分层建指标，再沉淀 badcase，最后让 badcase 反过来驱动 Prompt、检索、工具和流程迭代。

常见追问：

• RAGAS 这类框架适合做什么？
• 如何建设 badcase 数据集？
• 自动评测和人工评测怎么配合？

重要度：必刷（出现次数：2次） | 难度：较难

**考察点：**是否有评测闭环意识。

对应章节：19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手；21 Agent智能体 §5、实操与案例

Q9-2. 什么是“幻觉”？应用层应该怎么缓解？

幻觉不只是“完全胡说八道”，更常见的是“看起来很像真的，但细节、引用、时间点、权限范围或者工具结果已经偏了”。

因此，不应把幻觉当成单纯的模型问题，而应把它视为一条链路上的系统问题。比较稳妥的缓解思路通常有四层：

• 知识层：用 RAG、外部检索、引用和无依据拒答，尽量让模型基于证据回答。
• 执行层：把计算、查库、发消息、查订单这类事情交给 Tool，不让模型纯文本瞎编结果。
• 约束层：用结构化输出、schema 校验、关键字段规则校验和低温度策略，减少“格式对了但内容错了”的情况。
• 治理层：做 badcase 回灌、人工抽检、线上监控和降级，别把“模型大概率没问题”当作上线条件。

总结来说：幻觉很难被彻底消灭，工程目标不是“保证永不出错”，而是让它 可发现、可限制、可回滚、可复盘。

常见追问：

• RAG 为什么不能彻底消灭幻觉？
• 什么叫“有引用但依然不忠实”？
• 幻觉和 Prompt Injection 是一回事吗？

重要度：高频（出现次数：2次） | 难度：中等

**考察点：**是否理解“模型能力问题”和“应用链路治理问题”的边界。

对应章节：19 RAG检索增强生成 §1、RAG 简介；14 输出解析器 §4、结构化输出

Q9-3. 多用户场景下，如何为 Agent 做安全沙箱隔离？

如果 Agent 只是单机 Demo，很多风险不会暴露出来；但一旦进入多用户场景，安全隔离就必须从“工具权限”上升到“执行环境隔离”。

一个更稳的方案通常会分三层：

• 环境层：用 Docker 或其他容器把每个任务或租户隔离开，限制 CPU、内存、网络和文件系统访问范围。
• 系统层：配合 seccomp、AppArmor、只读根目录、临时工作目录、非 root 用户运行，避免直接碰宿主机。
• 应用层：对工具、文件访问、系统命令、外部连接做白名单和审计，不让模型拿到裸权限。

如果要执行代码、命令或读文件，通常不会只靠 Prompt 或业务代码做限制，而是会把工作目录挂成最小权限空间，敏感目录不挂载，数据库密钥和主机凭据也不进容器。MCP 或 Tool 负责“能不能调”，沙箱负责“即使调了也跑不出边界”，两者职责不同，最好一起上。

重要度：高频（出现次数：2次） | 难度：较难

**考察点：**多用户 Agent 的安全隔离设计，以及协议层控制和环境层隔离的分工。

对应章节：7 企业级大模型部署 §1、企业级大模型部署概述；17 Tools工具调用 §6、从课程案例走向真实项目

Q9-4. Agent 部署和运维有哪些指标？

Agent 运维至少要看五类指标：

• 效果指标：任务完成率、用户满意度、引用正确率。
• 性能指标：首 token、端到端延迟、P95/P99。
• 稳定性指标：调用成功率、超时率、重试率、失败率。
• 成本指标：token 消耗、工具调用成本、单任务平均成本。
• 治理指标：人工接管率、审计日志完整性、异常任务复盘效率。

如果是多工具、多步骤 Agent，还要看每一步的成功率和卡点分布，否则你只能知道“最终失败了”，却不知道失败发生在哪一层。

重要度：高频（出现次数：1次） | 难度：中等

**考察点：**从 Demo 到生产的运维视角。

对应章节：7 企业级大模型部署 §1、企业级大模型部署概述；21 Agent智能体 §5、实操与案例

Q9-5. RAG 系统在实际部署中可能面临哪些挑战？

RAG 真正上线后，难点通常不在“能不能检索”，而在“这条从索引到回答的完整链路能不能长期稳定运行”。

这里首先要强调的是：RAG 不是单点能力，而是“索引阶段 + 检索与生成阶段”的工程链路。很多线上问题，本质上都是这两阶段里某一层出了问题。

先把挑战拆成六类：

• 数据侧：文档解析质量、切块策略、表格和 PDF 处理、知识更新时效。如果源数据脏、切块不合理，后面检索和生成都会被拖垮。
• 检索侧：Embedding 选型、召回质量、混合检索、重排效果、metadata 过滤。很多系统离线看起来能答，线上一放大就会暴露“召回不准、噪声太多、漏关键片段”的问题。
• 生成侧：上下文组装、引用溯源、忠实度控制、拒答策略。RAG 不是“检索了就不会幻觉”，如果上下文拼接差、Prompt 弱、引用不清，模型照样会编。
• 治理侧：权限隔离、版本管理、引用可追溯、知识回滚。企业里最怕的不是答错，而是答了权限外内容，或者答出来了却说不清依据来自哪里。
• 评测侧：badcase 建设、离线评测和在线指标闭环。没有评测，你很难知道问题到底出在切块、召回、重排还是生成。
• 工程侧：延迟、成本、缓存、可观测性、索引重建和线上运维。比如知识库一更新，是全量重建还是增量更新？查询慢是卡在检索、重排还是模型？这些都得拆开看。

所以面试里更稳的答法不是只说“部署会有很多工程问题”，而是明确讲出：RAG 是一条从数据接入、索引构建、检索召回到生成回答的完整链路，任何一层出问题，最终答案都会出问题。

常见追问：

• 如果 RAG 线上效果不好，你会优先从哪一层开始排查？
• 知识库频繁更新时，你怎么处理索引重建和版本回滚？

重要度：高频（出现次数：1次） | 难度：较难

**考察点：**是否有生产系统思维。

对应章节：19 RAG检索增强生成 §2、RAG 文本处理核心知识；7 企业级大模型部署 §1、企业级大模型部署概述

Q9-6. 如何确保 Agent 的行为安全、可控且符合人类意图？

这件事不能只寄希望于模型本身“够聪明”或“已经对齐过”。模型层的 SFT、RLHF / RLAIF 只能提供基础安全边界，真正落地到应用时，还必须补应用层治理。

通常会从四层做：

• 模型与提示层：用 System Message 明确角色、边界、安全规则和拒答策略。
• 工具与权限层：不给模型裸权限，所有 Tool 都要做 schema 约束、鉴权、参数校验和最小权限暴露。
• 执行与流程层：设置最大步数、超时、人工审批、转人工、失败兜底，避免无限循环和危险动作直接落地。
• 观测与审计层：保留调用日志、trace、输入输出、关键决策点和人工复盘链路。

如果再补一层生产视角，我还会把预算和熔断讲进去：

• 预算控制：最大工具调用次数、时间预算、token 预算、费用预算。
• 熔断机制：连续失败停止、异常率告警、重复无进展退出。

这些机制的价值不只是省钱，更重要的是把“模型可能一直试下去”的风险收住。

如果再往上一层总结，就是：模型对齐解决“基础行为别太离谱”，应用治理解决“在你的业务系统里别出事”。真正稳的 Agent，一定是“模型能力 + 权限边界 + 流程控制 + 人机协同”一起做，而不是只靠某一层。

常见追问：

• 模型已经做过对齐了，为什么应用层还要再做这么多安全治理？
• 哪些动作你会要求人工审批，而不是让 Agent 直接执行？

重要度：高频（出现次数：1次） | 难度：较难

**考察点：**是否理解“模型对齐”和“应用层安全治理”是两套互补机制。

Q9-7. Agent 链路耗时很长时，如何定位性能瓶颈？

Agent 一条链路跑到几分钟，不能只说“模型太慢”，要先把耗时拆开。

通常会按这几层做分解：

• 模型层：单次推理时长、首 token 延迟、输出 token 长度。
• 检索层：召回、重排、外部搜索、知识库请求耗时。
• 工具层：API 延迟、浏览器动作、代码执行、等待外部系统返回。
• 编排层：路由判断、Supervisor 判断、重复重试、串行等待。
• 结果层：后处理、校验、存储、日志落盘。

比较稳的做法是给每一步打 trace 和 span，先看 wall time 花在哪，再决定是换模型、改链路、减少步骤，还是把串行改成并行。如果用了 LangGraph，我还会看节点级耗时、是不是反复进入同一节点、有没有因为缺少明确完成信号而来回判断。

很多五分钟任务最后不是卡在单次模型调用，而是卡在多步链路过长、工具等待、监督节点重复判断，或者中间没有明确成功信号导致反复检查。也就是说，性能问题很多时候不是“模型太慢”，而是状态流转和执行闭环没有设计好。

重要度：高频（出现次数：1次） | 难度：较难

**考察点：**Agent 性能排障能力，以及把长链路延迟拆解到模型、工具、检索和编排层的能力。

Q9-8. 意图识别 / 任务路由应该怎么做？

需要先强调，这题和“模型路由”不是一回事。模型路由更接近“这次该用大模型还是小模型”，而意图识别 / 任务路由更接近“这次请求到底该走 FAQ、RAG、Tool、Agent、Workflow，还是直接转人工”。

比较稳的设计通常分三层：

• 第一层是目标分类：先定义清楚系统有哪些路由终点，比如闲聊、FAQ、知识问答、查状态、执行动作、复杂任务、人工兜底。
• 第二层是路由机制：高确定性场景先用规则和关键词兜底，模糊场景再用分类模型或 LLM 做语义判断。
• 第三层是置信度治理：低置信度不强判，允许澄清、降级或转人工，别让系统带着误判继续往下跑。

工程上通常不会做“单层万能路由器”，而是更偏好多级路由：

• 先做业务意图路由：判断这是 FAQ、RAG、Tool 还是 Agent。
• 再做子域路由：比如客服里再分订单、退款、工单、投诉。
• 最后再做模型路由：在具体链路里决定用强模型还是轻模型。

这样做的好处是更容易治理，也更容易评测。评估时重点看：路由准确率、低置信度占比、误路由成本、澄清命中率，以及每条路由分支的最终任务完成率。

常见追问：

• 什么时候先用规则路由就够了，什么时候必须上语义分类？
• 如果一个问题同时像 FAQ 又像 Tool 调用，你怎么处理？
• 如何避免错误路由把后续链路全部带偏？

重要度：高频（出现次数：1次） | 难度：较难

**考察点：**分层路由能力、意图识别落地能力，以及把 FAQ / RAG / Tool / Agent 串成统一入口的系统设计意识。

对应章节：17 Tools工具调用 §6、从课程案例走向真实项目；19 RAG检索增强生成 §3、RAG 综合案例：智能运维助手

Q9-9. 你会怎么做大模型应用的可观测性？

至少要做到三件事：有日志、有指标、有 Trace。也就是能看见请求怎么流过系统、每一步花了多久、失败在哪里、用了多少 token、最后输出了什么。

具体上，应打通 trace_id / request_id，把入口请求、Prompt 版本、模型版本、索引版本、检索结果、工具调用、异常信息、耗时和 token 用量串起来。如果用了 LangChain / LangGraph，还需要重点关注节点流转、状态更新、人工中断点、重试次数和最终退出原因。

对 Agent 系统来说，可观测性尤其重要，因为很多问题都发生在中间步骤，而不是最终输出那一刻。真正有用的可观测性，不只是“最后报错了”，而是能告诉你：它在哪个节点卡住、为什么重试、为什么结束、当时看到了什么状态。

重要度：中频（出现次数：1次） | 难度：中等

**考察点：**Trace、日志、指标意识。

Q9-10. 控制大模型应用成本，你会优先从哪些层面下手？

通常从模型、上下文、检索、流程四层入手。

• 模型层：高低配模型分层，大任务用强模型，小任务用轻模型。
• 上下文层：压缩 Prompt，减少无效历史，控制返回长度。
• 检索层：优化召回和重排，减少无意义进窗内容。
• 流程层：减少不必要的 LLM 调用次数，能规则化就不要全靠模型。

很多系统成本高，不是因为模型太贵，而是链路设计太浪费，比如无差别全量检索、过长历史拼接、多次重复调用大模型、工具失败后盲目重试。

常见追问：

• 什么时候应该引入模型路由？
• 如何平衡成本和效果？
• token 成本和工具成本哪个更值得先优化？

重要度：中频（出现次数：1次） | 难度：中等

**考察点：**成本优化思维。

对应章节：1-1 大模型认知与工程概览 §4、大模型的工程实现（概览）；7 企业级大模型部署 §1、企业级大模型部署概述

Q9-11. 模型路由应该怎么做？

模型路由的核心不是“让所有请求自动找最强模型”，而是让不同复杂度、不同风险等级的请求走到最合适的链路。

比较常见的做法有三层：

• 意图路由：先判断这是 FAQ、RAG、工具调用、复杂 Agent，还是应该直接转人工。
• 复杂度路由：简单分类、格式化抽取、轻量总结走小模型；多步规划、开放生成、复杂决策走大模型。
• 成本路由：热点问题先查缓存，能规则化解决的就别进大模型，高价值用户或高风险任务再给更强模型预算。

真正落地时，通常不会把“路由”做成纯主观规则，而会配合评测和线上数据来调：

• 看不同路由分支的完成率、延迟、每任务成本。
• 看是不是某类问题被错误地下沉到了小模型。
• 看路由规则是否需要引入回退机制，比如小模型失败后升级到大模型。

所以模型路由本质上是效果、成本和稳定性之间的平衡器。做得好的系统，不是每次都用最贵的模型，而是能把“该省的地方省掉，该花的地方花对”。

常见追问：

• 什么场景下适合先用规则路由，而不是一开始就做模型路由？
• 小模型路由失败后，怎样设计升级和回退策略？
• 如何避免为了省成本把系统整体效果打穿？

重要度：中频（出现次数：1次） | 难度：较难

**考察点：**成本治理、模型分层和路由策略设计能力。

对应章节：11 Model I/O 与模型接入 §2、LangChain 模型分类、参数与返回；7 企业级大模型部署 §1、企业级大模型部署概述

Q9-12. 内网环境下怎么设计 Agent / RAG 系统？

内网环境下做 Agent / RAG，核心不是“把公网方案照搬一遍”，而是先把 数据不出域、模型可控、依赖可替换、链路可观测 这几件事立住。

如果按企业级部署思路设计，通常拆成三层：

• 应用层：Dify、Coze 类平台的私有化版本，或者自研后端服务，负责工作流、Agent 编排、权限和业务接口。
• 推理层：用 Xinference 这类托管平台统一管理 LLM、Embedding、Rerank，对外暴露 OpenAI-compatible API。
• 数据层：内网向量库、关系库、对象存储、知识库索引、日志和审计系统都放在可控域内。

这类架构的关键点一般有：

• 模型接入统一：上层尽量都走兼容 API，方便替换在线模型、本地模型和不同推理引擎。
• 网络和权限隔离：Agent 能访问哪些内网系统，必须按最小权限开放，不让模型拿到一把通吃的内网钥匙。
• 知识治理：文档解析、索引重建、版本回滚、租户隔离、引用追踪都要内建，不然内网知识库很快会失控。
• 可观测与审计：请求链路、工具调用、检索结果、模型版本、token 用量、异常告警都要能在内网闭环查看。
• 降级能力：内网模型抖动时，是否有缓存、规则链路、人工兜底或备用模型，不然系统会很脆。

总结来说：内网方案不是“离线版 Demo”，而是一套更强调安全边界、运维治理和模型可替换性的生产架构。

常见追问：

• 为什么很多企业会选择“应用层 + 推理层”解耦，而不是把所有东西混在一台机器上？
• 内网环境下，LLM、Embedding、Rerank 为什么最好分开部署和管理？
• 如果不能直接访问公网搜索，动态信息怎么补？

重要度：中频（出现次数：1次） | 难度：较难

**考察点：**企业私有化部署理解、应用层与推理层解耦意识，以及内网 Agent / RAG 的安全与运维设计能力。

对应章节：7 企业级大模型部署 §1、企业级大模型部署概述；7 企业级大模型部署 §3、模型部署；12 Ollama本地部署与调用 §5、LangChain 整合 Ollama