【面试题】AI相关测试面试题

1. LLM-as-a-Judge 怎么设计

核心思路：把Judge当成一个打分模型，固定输入结构、明确评分维度、定义打分规则、增加校验防幻觉，不要让大模型自由发挥。

整体结构

1. 输入模板（4部分）
   • 任务描述：告诉Judge它是什么角色、要干什么
   • 参考标准答案（Golden Answer，可选）
   • 用户原始query
   • 被测模型输出
2. 评分维度（RAG场景示例）
   • 事实正确性：答案是否和知识库一致，有无编造信息
   • 信息充分性：是否完整回答用户问题，有没有缺关键信息
   • 忠实度（Grounding）：所有结论是否都能溯源到检索片段，有无幻觉
   • 有用性：回答可读性、是否贴合用户意图
3. 评分规则设计
   推荐1~5分制，每一档写死判定标准，避免模糊描述：
   • 5分：完全正确，信息完整，全部内容可在参考文档找到，无额外编造
   • 4分：基本正确，少量无关信息，不影响结论，无事实错误
   • 3分：部分正确，关键信息缺失，无严重幻觉
   • 2分：存在事实错误，回答偏离问题
   • 1分：完全错误/拒绝回答/大量幻觉
4. 输出约束
   强制要求Judge先输出【思考过程】，再输出【分数】，最后输出【理由】；
   增加自校验：让Judge自查是否存在信息和参考文档冲突。
5. 一致性提升手段
   • 少量样本人工校准（Few-shot，放入2~5条人工标注好样例）
   • 重复打分：同一条样本跑2次，计算打分一致性；差异过大标记人工复核
   • 增加反事实样本测试Judge本身能力

可直接复制Prompt模板

你是RAG评测专家，需要对大模型回答进行打分。 评分维度：事实正确性、信息充分性、内容忠实度（不能编造知识库不存在信息）。 打分范围：1~5分。 评分标准： 5分：答案完全符合参考文档，信息完整，无编造，准确回答问题； 4分：答案基本正确，少量无关内容，无事实错误； 3分：部分信息正确，关键信息缺失，不存在严重幻觉； 2分：存在事实错误，回答偏离用户问题； 1分：答案完全错误，大量编造信息。 【用户问题】 {user_query} 【检索参考文档】 {retrieved_context} 【被测模型输出】 {model_response} 输出格式严格遵守： 思考过程： 总分： 理由：

2. 大模型评测数据怎么处理

分为：数据集构建 → 清洗 → 标注 → 版本管理 → 结果分析

1. 数据集来源
   • 人工编写：覆盖正常、边界、歧义、对抗、幻觉诱导case
   • 线上真实query抽样：脱敏，过滤隐私数据
   • 历史bad case：线上幻觉、回答错误、召回失败样本
2. 数据清洗
   • 脱敏：手机号、身份证、内部敏感信息剔除
   • 去重：相同query合并
   • 过滤无效样本：空白、乱码、无意义问题
3. 标注
   • 构建Golden set：人工写标准答案，标注预期行为
   • 分层：简单集、困难集、对抗集
4. 版本管理
   • 评测集像代码一样Git管理，每次模型迭代固定版本数据集
   • 记录样本标签：类别、难度、预期错误类型
5. 结果处理
   • 统计各维度指标，按样本分组看通过率
   • 错误归类：幻觉、召回错误、理解偏差、指令遵循失败
   • Bad case回流，加入下一轮评测集

3. LLM测试和传统服务端测试有什么区别

维度	传统服务端接口测试	LLM/大模型测试
输出特性	确定性：相同输入，固定输出	概率性：相同输入，多次结果不一样
校验方式	精确匹配返回字段、值，断言明确	很难精确匹配；多用LLM-as-judge、人工评估、事实校验
缺陷类型	报错、参数异常、数据库错误、超时	幻觉、逻辑错误、答非所问、事实错误，不一定抛异常
用例设计	输入输出明确，结果可预期	大量边界、歧义、对抗、诱导类用例
性能指标	响应时间、QPS、错误率	吞吐量+生成速度、召回质量、幻觉率
版本迭代	接口契约稳定	模型权重、Prompt变更都会改变输出，契约不稳定

一句话总结：传统测功能是否按代码逻辑执行；LLM测输出内容质量、事实可靠性、意图理解能力。

4. RAG测试集怎么设计和迭代

设计思路（分4大类样本）

1. 正向标准样本：问题答案明确存在知识库，测试正常召回+回答
2. 信息缺失样本：知识库没有答案，预期模型应该说不知道，不能编造（重点测幻觉）
3. 模糊/歧义样本：问题描述不清，测试模型是否合理追问或者区分意图
4. 干扰样本：知识库存在相似但是冲突的文档，测试会不会被干扰，召回错误片段

测试集字段建议：query、golden_answer、expected_behavior、reference_docs、difficulty、label

迭代流程

1. 初始版本：人工编写，覆盖业务核心场景
2. 模型跑评测集，收集bad case：幻觉、召回错误
3. 把失败样本清洗后加入评测集，扩充困难集
4. 定期引入线上真实query，持续补充
5. 定期清理过时文档对应的样本（知识库更新后同步更新测试集）
6. 保持测试集固定子集作为基准集，每次版本对比，保证指标可横向对比

5. Agent怎么找到正确的Skill

Skill = 工具（查询数据库、发邮件、调用接口等）
Agent选择Skill完整链路：

1. 用户输入 → Agent意图识别：解析用户需求，判断需要什么能力
2. Skill描述库检索：每个Skill有自然语言描述（功能、入参、适用场景、限制）
3. 匹配：LLM根据用户问题，对比Skill描述，选出候选Skill列表
4. 校验：判断参数是否齐全；缺少参数就向用户询问
5. 执行选中Skill，拿到返回结果，整理回答

关键点：Skill描述写得好不好，直接影响选择准确率；描述要清晰、区分度高，避免多个Skill描述相似混淆。

6. Agent 和 Skill 的匹配机制怎么验证

分三层验证：单元级、链路级、评测集评测

① 单元测试：Skill选择能力

构造评测query集合，覆盖：

• 需要调用A工具
• 需要调用B工具
• 不需要调用任何工具（直接大模型回答）
• 多个工具可选，只能选其中一个
• 需要连续调用多个Skill（多步工具调用）
  统计指标：工具选择准确率、参数提取准确率

② 边界&对抗case

• 用户问题模糊，缺少入参：验证Agent是否会询问缺失参数
• 用户需求超出所有Skill能力：验证Agent不强行调用工具，不编造结果
• 用户诱导调用危险工具：安全校验拦截

③ 链路完整评测

端到端评测：从用户提问 → 选Skill → 参数生成 → 调用工具 → 结果整理
指标：

1. Skill选择命中率
2. 参数生成正确率（参数名称、格式、取值）
3. 完整任务成功率（最终结果是否满足用户目标）
4. 错误类型归类：选错工具、参数错、多调用/漏调用工具

④ LLM-as-Judge辅助评估

Judge判断：Agent选择的工具，是否是当前问题最合适的Skill；参数是否合理。

7. Agent 输出怎么评测

Agent 不是只看最终一句话回答，要分层评测：意图→工具选择→参数→中间步骤→最终结果

评测维度

1. 意图识别：是否正确理解用户诉求
2. Skill/工具选择：选对工具、不瞎调用、不多调用、不漏调用
3. 参数生成：参数名、类型、取值正确；缺参数时主动询问用户
4. 多步规划能力：复杂任务能否拆解成合理步骤，顺序是否正确
5. 工具结果处理：拿到工具返回后，能否正确解析，不编造工具返回之外信息
6. 最终答案质量：事实正确性、完整性、忠实度（LLM-as-Judge打分）
7. 安全指标：拒绝越权、危险调用，防止指令注入

评测方式

• 黄金集（Golden Set）：人工标注样本，包含预期工具调用序列+预期输出
• LLM-as-Judge：Judge判断：工具调用序列是否合理、最终结果是否满足用户目标
• 指标：工具选择准确率、参数提取正确率、任务完成率、幻觉率、多余调用率

Judge Prompt（Agent专用，可直接复制）

你是Agent评测专家。评估Agent执行整个任务链路是否合理。 评分维度： 1.意图理解：是否理解用户问题 2.工具选择：是否选择正确工具，无多余/遗漏调用 3.参数正确性：工具入参是否合理、完整 4.步骤规划：多步骤任务顺序是否合理 5.最终结果：是否解决用户问题，无编造信息 打分：1~5分 5：完全匹配预期，步骤合理，结果正确 4：微小瑕疵，不影响任务完成 3：部分正确，关键信息有缺失 2：工具选错/参数错误，任务失败 1：完全偏离需求，大量幻觉 【用户Query】 {user_query} 【Agent Trace完整链路】 {agent_trace} 【预期Golden行为】 {golden_trace} 输出： 思考过程： 总分： 理由：

8. 并行节点冲突怎么处理（Agent workflow，多分支并行）

并行冲突：多个并行节点同时读写同一个State，出现覆盖、脏数据、状态不一致。

1. 状态隔离（优先方案）
   并行分支使用独立子State，并行节点只读写自己分支内数据；并行全部完成后，做一次合并到主State。避免并行写同一个key。
2. 加锁机制
   共享全局State增加读写锁，同一时间只允许一个节点写；读可以并发。缺点：锁会削弱并行能力。
3. 冲突合并策略
   预先定义合并规则：

• 覆盖策略：后执行结果覆盖前面（慎用）
• 追加策略：数组类数据追加，不覆盖
• 投票策略：多个并行分支产出结论不一致时，交给LLM做结果汇总裁决

4. 冲突检测
   并行全部结束时，校验同key下多分支产出是否矛盾；冲突标记告警，人工或LLM仲裁。
5. 避免长事务
   并行节点尽量无状态，业务逻辑放到Skill里执行，State只存元数据，减少并行写压力。

9. Trace 怎么做（Agent链路追踪）

Trace目标：记录Agent完整执行链路：用户输入 → 思考 → 工具选择 → 参数 → 工具返回 → 模型输出，方便调试、评测、定位bad case。

核心字段

trace_id（全局唯一）、start_time、end_time、user_query、state快照、每一步：
step_id、节点类型（LLM思考/Skill调用/判断分支）、prompt、模型输入输出、工具名称、入参、工具返回、错误信息、token消耗。

实现方式

1. 埋点：每一次大模型调用、工具调用、状态变更，自动记录日志
2. 持久化：存入数据库 / LangSmith / Langfuse / OpenTelemetry；支持按trace_id查询完整链路
3. 可视化：展示流程图，每一步耗时、输入输出、异常标红
4. 关联评测：Trace直接喂给LLM-as-Judge做自动评估；Bad case直接保存进评测集
5. 采样：线上全量采样成本高，可抽样记录；失败case强制全量保存Trace

10. Agent 结果不理想怎么定位（排障思路）

按链路从前往后逐级排查：

1. 用户Query层：query歧义、模糊、信息不足 → 看意图识别是否出错
2. Prompt/系统提示词层：Agent指令描述不清、Skill描述模糊 → 导致选错工具
3. State层：上下文丢失、历史状态污染、并行状态冲突 → 看Trace里State快照
4. Skill匹配层：Skill描述相似度太高，区分度不足；参数schema定义缺陷 → 参数提取错误
5. 工具执行层：Skill本身报错、接口返回异常、超时、返回数据格式混乱
6. 结果生成层：大模型拿到工具返回后，错误解读、编造信息（幻觉）

排查手段：

• 拉取完整Trace，逐step看输入输出
• 隔离测试：单独测意图模块、单独测Skill选择、单独测工具调用
• 消融实验：去掉某一个组件，看结果变化，定位根因
• 归类bad case：是意图问题 / 工具选择问题 / 参数问题 / 工具返回问题 / LLM幻觉

11. Checkpointer、State、Skill、MCP 怎么理解

• State：Agent的内存，保存整个会话上下文、用户信息、中间结果、工具返回数据。贯穿整个workflow，所有节点读写State。
• Checkpointer 状态检查点：负责把State持久化。Agent中断、超时、重启后，可以从checkpoint恢复State，继续执行任务。比如LangGraph的Checkpointer。
  作用：断点续跑、会话持久化、重试、回溯历史状态。
• Skill：Agent可调用的能力单元，也就是工具。比如查数据库、调用接口、文件读取。每个Skill包含：自然语言描述、入参JSON Schema、执行函数。Agent依靠描述理解什么时候调用这个Skill。
• MCP（Model Context Protocol）模型上下文协议
  标准化协议，让大模型Agent和外部工具、数据源统一通信。
  作用：统一工具描述、参数格式、返回结构；不同Agent框架可以直接接入MCP的Skill，不用重复写适配代码。类似Agent世界的REST协议。

一句话串起来：
Agent读取State，基于State判断调用哪个Skill；执行过程中Checkpointer不断保存State快照；Skill通过MCP协议标准化对外提供能力。

12. 怎么用 Codex 做自动化测试

Codex（OpenAI，代码生成模型），擅长代码解析、生成单元测试、生成接口/自动化脚本。

使用场景

1. 根据接口文档、函数代码自动生成单元测试用例（pytest）
2. 根据业务需求，生成Playwright UI自动化、requests接口自动化脚本
3. 代码变更后，自动识别改动函数，增量生成测试代码
4. 分析代码，自动找出边界case、异常分支，生成mock代码

落地流程

1. 输入上下文：源码/接口定义 + 测试要求（pytest、mock、覆盖异常分支）
2. Codex生成测试代码
3. 自动执行代码；捕获执行报错
4. 把报错信息丢回给Codex，自动修复脚本
5. 人工Review生成代码，校验断言逻辑（重点：AI容易写出假断言）
6. 可集成CI：代码MR触发，自动生成并执行测试

局限（面试必说）

Codex生成代码容易存在幻觉：断言错误、mock逻辑不对、忽略业务隐藏规则；必须人工评审，不能直接上线；复杂业务逻辑场景效果差。

13. 你们是怎么实现LLM 可观测+可测评的？

测开面试口述版
整体思路：链路埋点采集Trace → 指标看板做可观测 → 评测引擎做质量评估，两者打通，一条Trace直接进入评测流水线

1. 埋点采集
   基于OpenTelemetry / Langfuse SDK做埋点，对RAG/Agent的每一步（query改写、检索、重排、LLM生成、工具调用）生成Span。采集内容：输入prompt、模型输出、token消耗、耗时、错误、检索文档、版本信息、用户id、trace_id。
2. 可观测（线上监控）

• 基础指标：TPM、请求量、耗时P50/P90/P99、错误率、模型拒绝率、token消耗
• 链路视图：可视化Trace，定位慢调用、异常步骤；失败样本自动标记
• 告警：超时、高错误率、token突增、幻觉类BadCase告警

3. 可测评（离线+在线评测）

• 离线：固定Golden评测集批量跑，自动生成Trace，调用LLM-as-Judge打分，计算幻觉率、召回率、忠实度
• 在线采样：线上按比例采样Trace，送入Judge自动评估；人工标注入口，标注结果回流更新评测集
• 问题归类：自动把失败样本分类：检索错误、query改写错误、模型幻觉、重排错误

4. 闭环
   评测识别的BadCase直接入库，加入下一轮回归评测集；模型/知识库版本变更时，自动跑全套评测，质量门禁卡点。

14. 如果从零设计 LLM 可观测平台，核心模块+技术选型

核心模块

1. SDK埋点采集模块
   提供多语言SDK（Python/JS/Java），兼容OpenTelemetry，自动埋点LLM调用、RAG各阶段、Agent工具调用；支持手动自定义Span。
2. Trace接收&存储模块
   接收Span事件，做数据清洗、脱敏；存储链路明细。
3. 指标计算模块
   实时聚合指标：QPS、TPM、耗时分位数、错误率、模型拒绝率。
4. 可视化链路看板
   Trace详情页、DAG流程图、时序指标大盘；按trace_id检索全链路。
5. 评测引擎模块

• 评测集管理：golden样本管理、版本管理
• LLM-as-Judge执行引擎，支持自定义Prompt、批量评测
• 指标报表：NDCG、召回率、幻觉率、任务成功率

6. 标注&样本管理模块
   人工标注界面，线上采样样本入库，BadCase管理，样本回流
7. 告警与通知模块
   指标告警、质量指标告警（幻觉率上涨），推送钉钉/企业微信
8. 权限&项目管理
   多项目隔离、版本管理（模型版本、知识库版本、Prompt版本）

技术选型

• 采集层：OpenTelemetry + 自研SDK封装
• 消息队列：Kafka，削峰，接收高并发Span事件
• 时序指标：Prometheus + Grafana（负责基础指标）
• Trace存储：ClickHouse（适合存储海量半结构化Span日志，查询链路明细）
• 数据库：PostgreSQL（存元数据、评测集、标注信息、项目配置）
• 后端：Python FastAPI
• 前端：React
• 评测执行：Celery异步任务，批量跑LLM-as-Judge评测任务
• 缓存：Redis，评测任务状态、限流

15. 为什么传统APM（Prometheus+Grafana）不适合LLM应用可观测？Langfuse解决哪些痛点

传统APM不足

1. 传统APM侧重结构化指标，不保存输入输出文本
   Prometheus只存数值指标（耗时、错误码），不会存储prompt、模型回答、检索文档。LLM问题大多是内容质量问题（幻觉、答非所问），不是接口报错，没有文本就无法定位。
2. Span维度简单，无法表征LLM业务链路
   普通服务是接口调用链；LLM应用是多步骤语义链路：Query改写→检索→重排→生成。传统APM没有原生支持RAG/Agent语义Span。
3. 缺少评测能力
   Prometheus只做监控，没有LLM-as-judge、评测集、人工标注、质量指标（幻觉率、忠实度）。
4. 指标维度不匹配LLM
   缺少token消耗、输入/输出token、模型版本、知识库版本、检索文档列表这类LLM专属维度。

Langfuse解决的核心痛点

1. 原生支持保存Prompt、模型输出、检索上下文，整条Trace带文本，可直接看模型回答内容
2. 原生支持RAG/Agent分层Span，可视化DAG链路
3. 内置评测能力：支持人工打分 + LLM-as-Judge自动评测，可绑定到Trace
4. 自动统计token消耗、成本估算，区分输入输出token
5. 样本采样，线上失败样本自动入库，支持人工标注，标注数据可用于微调/评测集回流
6. 多版本管理：Prompt版本、模型版本，方便对比不同版本质量差异

#4. RAG链路：Query改写 → 向量检索 → 重排 → LLM生成，Langfuse分层埋点，Span关键字段
整个RAG一次请求对应1个Trace，4个子Span
Trace：根节点，整个RAG会话
Span1：query改写
Span2：向量检索
Span3：重排（Rerank）
Span4：LLM生成

每个Span必须记录的关键字段

公共字段（所有Span都要有）
trace_id、span_id、parent_span_id、start_time、end_time、latency、status（成功/失败）、error_msg、metadata（模型版本、知识库版本、用户id、环境）

Span1：Query改写（query_rewrite）

• input：原始用户query
• output：改写之后的查询文本
• metadata：改写使用的模型名、prompt模板版本

Span2：向量检索（vector_search）

• input：改写后的query
• output：召回文档列表：doc_id、文档片段、向量相似度分数、topN数量
• metadata：向量库名称、向量模型名称、召回topK阈值

Span3：重排 rerank

• input：向量检索返回的文档列表 + query
• output：重排之后排序后的文档列表，每个文档的rerank分数，过滤掉的文档
• metadata：rerank模型名称、重排过滤阈值

Span4：LLM生成（llm_generation）

• input：最终组装的Prompt（系统提示词 + 重排后的上下文 + 用户query）
• output：大模型返回答案
• token_usage：input_tokens、output_tokens、total_tokens
• metadata：LLM模型名称、temperature、top_p、prompt版本

额外：Trace根节点层面

保存最终用户原始query、最终模型回答、本次链路全部检索文档，可直接绑定Judge评测。