#八、评测、幻觉、安全与可观测性
#代表笔试题
- perplexity 是什么？它为什么不能代表一切？
- hallucination 的常见来源有哪些？
- faithfulness 和 helpfulness 有什么区别？
- 什么是 LLM-as-a-Judge？
- 什么是 red teaming？
- guardrail 在大模型系统中指什么？
#就地速答
- 问：perplexity 是什么？它为什么不能代表一切？
答：perplexity 可以理解为模型在预测测试文本下一个 token 时的平均不确定性，数值越低，说明模型越“觉得这些文本像自己熟悉的分布”。它是经典语言建模指标，很适合衡量一个模型在 token 预测意义上的拟合程度。详见后文“### 85. perplexity 是什么？它为什么不能代表一切？”。
- 问：hallucination 的常见来源有哪些？
答：hallucination 的来源最好分层讲。第一类是参数知识不足：模型本来就没学到相关事实；第二类是外部知识链路出错，比如 RAG 没召回到正确证据；第三类是证据利用失败，材料给到了，但模型没有忠实使用；第四类是解码导致的过度补全，模型为了连贯性瞎补缺口；第五类是任务定义本身模糊，用户问题就逼着模型猜。详见后文“### 86. hallucination 的常见来源有哪些？”。
- 问：faithfulness 和 helpfulness 有什么区别？
答：faithfulness 关心的是回答是否忠实于给定证据，也就是“你说的话是不是能在证据里找到依据”；helpfulness 关心的是回答是否真正帮助用户解决问题，包括完整性、清晰度、可执行性和表达质量。详见后文“### 87. faithfulness 和 helpfulness 有什么区别？”。
- 问：什么是 LLM-as-a-Judge？
答：LLM-as-a-Judge 指的是用一个大模型去评估另一个模型生成结果的质量，例如比较两个答案谁更好、判断回答是否有帮助、是否忠于证据、是否符合风格要求等。它之所以流行，是因为人工评测很贵、很慢，而很多生成任务又难以用单一自动指标覆盖。详见后文“### 88. 什么是 LLM-as-a-Judge？”。
- 问：什么是 red teaming？
答：red teaming 是一种主动对抗式测试方法，核心不是看系统在正常场景下表现多好，而是故意用极端、恶意、边界、越狱、误导输入去打系统，看看它在哪些地方会失守。对于大模型系统来说，red teaming 常用于发现不安全输出、提示注入、越权工具调用、隐私泄露和规避策略等问题。详见后文“### 89. 什么是 red teaming？”。
- 问：guardrail 在大模型系统中指什么？
答：guardrail 可以理解成围绕模型系统搭的一圈保护栏。它不只是一个输出过滤器，而是一整套机制：输入侧可以做风险检测、越狱识别、提示注入防护；执行侧可以做工具权限控制、敏感操作拦截；输出侧可以做安全审查、结构约束和高风险内容复核。详见后文“### 90. guardrail 在大模型系统中指什么？”。
#代表面试题
- 为什么一个模型离线 benchmark 很强，线上用户体验却不一定好？
- 如果用户说你的模型“经常胡说”，你如何定位是模型问题、RAG 问题还是提示问题？
- 你怎么看 LLM-as-a-Judge 的优点和风险？
- 一个生产系统要做哪些线上监控，才算真正“可观测”？
- 如何处理 prompt injection、数据泄露、不安全输出这些问题？
- 如果要为企业内部知识助手建立评测集，你会怎么设计？
#就地速答
- 问：为什么一个模型离线 benchmark 很强，线上用户体验却不一定好？
答：因为离线 benchmark 测到的通常只是某一小块能力，而线上用户体验是“模型能力 + 系统设计 + 产品交互 + 流量分布”共同作用的结果。离线题集往往分布干净、答案标准、上下文有限，但线上请求会有脏输入、超长上下文、模糊指令、频繁工具失败、RAG 噪声和延迟约束。详见后文“### 91. 为什么一个模型离线 benchmark 很强，线上用户体验却不一定好？”。
- 问：如果用户说你的模型“经常胡说”，你如何定位是模型问题、RAG 问题还是提示问题？
答：这类问题要先抽 bad case，再做分层诊断。第一步看有没有正确证据：如果知识库里根本没有，或本轮任务本来就不该靠 RAG，那问题可能是模型参数知识不足或产品边界没定义清楚；第二步看证据是否被召回：若知识库有答案但 top-k 没命中，问题在检索；第三步看提示和上下文组织：证据进了 prompt，但是否明确要求引用、是否被噪声淹没；第四步再看生成层：模型是不是忽略证据、强行补全。详见后文“### 92. 如果用户说你的模型“经常胡说”，你如何定位是模型问题、RAG 问题还是提示问题？”。
- 问：你怎么看 LLM-as-a-Judge 的优点和风险？
答：它的优点很明确：便宜、快、可批量扩展，尤其适合开放式生成、摘要、风格评估、偏好比较这类难以写规则指标的任务。相比全人工，它能显著降低评测成本，让团队更频繁地做实验和 A/B 迭代。详见后文“### 93. 你怎么看 LLM-as-a-Judge 的优点和风险？”。
- 问：一个生产系统要做哪些线上监控，才算真正“可观测”？
答：真正可观测，至少要覆盖三层。第一层是系统层：QPS、时延、错误率、超时、资源占用、token 消耗、成本；第二层是模型链路层：模型路由命中、缓存命中、RAG 召回率、工具调用成功率、重试率、结构化输出合规率；第三层是业务层：用户满意度、人工转接率、投诉率、坏例聚类、安全告警、关键任务完成率。详见后文“### 94. 一个生产系统要做哪些线上监控，才算真正“可观测”？”。
- 问：如何处理 prompt injection、数据泄露、不安全输出这些问题？
答：处理这类问题不能寄希望于“一条更强的 system prompt”，而要做多层防线。输入侧要检测 prompt injection、恶意内容、越狱尝试；上下文侧要隔离外部文档和系统指令，避免检索结果反向污染控制提示；工具侧要坚持最小权限原则，避免模型一旦被诱导就能执行高风险操作；输出侧要做安全审查、敏感信息过滤和高风险任务拦截。详见后文“### 95. 如何处理 prompt injection、数据泄露、不安全输出这些问题？”。
- 问：如果要为企业内部知识助手建立评测集，你会怎么设计？
答：企业内部知识助手的评测集，不能只从公开 benchmark 抄题，而要从真实业务流量和高价值任务里抽样。题目应覆盖高频任务、长尾难题、模糊提问、跨文档问题、时效性问题和高风险场景；同时最好给出标准证据、参考答案、允许的容错范围，以及失败类型标签，比如“没召回到”“引用错”“答非所问”“泄露敏感信息”。详见后文“### 96. 如果要为企业内部知识助手建立评测集，你会怎么设计？”。
#这一块真正考什么
- 是否明白“模型强”与“系统可靠”不是一回事。
- 是否能把安全、评测、观测说成一条闭环，而不是几个独立名词。
#作答抓手
回答评测题时，可以拆成三层：离线基准、任务级人工评测、线上真实行为指标。