百度AI测开二面：Agent评测与检索质量

《面试题目》

1. Agent 项目的安全性方面是如何设计考虑的？
2. 项目的技术难点是什么，如何解决的？
3. 如何构建测试体系，评测效果如何？
4. 检索性能方面有考虑吗？
5. 调度模型时出现幻觉如何解决？
6. 检索重排序如何做的？召回精度方面等等。
7. Agent 协作模式是怎样的？它们的优劣？
8. 你认为现阶段测开岗位需要做哪些质量保障？
9. 为什么选择 LangGraph 框架？与其他框架的区别？
10. 设计一个自动生成测试用例的 Agent，给出方案流程。
11. Agent 协作与 workflow 有什么区别？

《参考解析》

Agent 项目的安全性设计：按「输入—决策—执行—数据」四层防。输入层：Prompt 注入防护（把用户输入与系统指令隔离、对检索到的文档做「不可信内容」标注、过滤明显的越权指令），敏感信息脱敏与合规拦截，输入长度与速率限制。决策层：给 Agent 明确的能力边界（可调用的工具白名单、参数校验与范围限制），高风险动作（删除、发消息、改配置、转账）必须走人工确认或二次校验，禁止让模型直接拼 SQL/命令（用参数化与受控 DSL）。执行层：沙箱隔离（受限用户、受限目录、禁外联或白名单出网、CPU/内存/超时限额），工具调用做幂等与限流，防止被诱导做出无限循环与批量破坏。数据层：最小权限凭据（短期 token，只读优先）,输出侧过滤（防泄漏系统提示词、其他用户数据、内部字段），全链路审计日志（谁、何时、用什么输入、调了什么工具、返回什么），以及对输出内容的合规审查。此外要有兜底机制：错误不暴露内部栈信息、异常时默认拒绝而不是默认放行。

检索性能与重排序怎么做：检索链路一般是「query 改写/扩展 → 多路召回（向量 + BM25 关键词 + 结构化过滤）→ 融合（RRF）→ 重排序（Cross-Encoder 精排）→ 截断送入生成」。重排序的要点：用交叉编码器（bge-reranker、Cohere Rerank 等）对「query + 候选文档」成对打分，精度显著高于向量相似度，但计算量大，所以只对前 50100 条候选做，输出 top 510 给模型；延迟上可以批处理、量化、缓存（相同 query 命中缓存）、异步预热，并做超时降级（精排超时就退回粗排顺序）。检索性能的优化手段：向量检索用 HNSW/IVF 索引并调 efSearch/nprobe 平衡召回与延迟、元数据预过滤减少候选集、向量维度压缩（PQ/量化）、索引分片与副本、把 embedding 计算批量化并缓存（同一文档只算一次）。召回质量的度量必须能报数：Recall@k、MRR、nDCG、Hit Rate，以及端到端的答案准确率与「有依据率」，用固定的评测集回归。常见瓶颈与对策：切分粒度过大导致语义稀释（改用小块 + 父子块检索）、query 与文档表述差异大（加 query 改写与同义词）、多跳问题单轮检索不够（拆成子问题迭代检索）。

幻觉的抑制：分「减少发生」与「发生了能兜住」两类。减少发生：强制基于检索内容作答并给出引用（要求标注来源片段 ID，无依据就说不知道）、把温度调低、限制输出长度与结构（JSON schema/固定模板）、在 prompt 里明确「不得编造接口名与数字」、给 few-shot 展示「无法回答」的正例。检索侧：提高召回质量（混合检索 + 重排序）、补全上下文（父子块、邻居扩展）、对时效性问题加时间过滤。兜住：后置校验——把答案里的关键实体/数字/引用链接抽出来与检索原文做比对（n-gram 或 NLI 模型判定蕴含关系），不一致就打回重生成或降级为「未找到依据」；事实类字段走工具查询而不是让模型复述（让 Agent 调 API 拿权威数据）；对外输出加免责与人工复核通道。评估上要能区分「检索没找到」与「找到了但模型编了」——两类的修法完全不同，所以评测要拆成检索指标与生成指标（faithfulness、answer relevancy）。

Agent 协作模式与优劣：常见模式有四类。① 主从/编排（Orchestrator-Worker）：主 Agent 拆任务、派给专职子 Agent（检索、编码、审查、测试），子 Agent 只回结论。优点是职责清晰、上下文隔离、可并行、易评测；缺点是任务描述有信息损耗、协调开销与成本高、错误可能被层层放大。② 流水线/顺序（Pipeline）：角色依次交接（产品 → 开发 → 测试），流程确定、可审计，但缺乏回退与自省，前一步错了后面全错。③ 辩论/对抗（Debate、Generator-Critic）：生成者与批评者互相挑战，能显著减少明显错误，代价是 token 翻倍且可能陷入无结论的争论，需要设置轮数上限与裁决规则。④ 群体/黑板（Blackboard、Swarm）：多个 Agent 共享一块工作区异步读写，灵活但容易冲突与重复劳动，需要锁或版本控制。选型原则：任务能拆成独立可验证的子任务就用编排式；需要快速试错与小改动用单 Agent + 工具就够，别为了架构而架构。评测要按「每个子 Agent 单独测 + 端到端测」两层做，否则出错时分不清是谁的责任。

Agent 协作与 workflow 的区别：Workflow 是「人预先编排好的确定性流程」——步骤、分支、重试规则写死在代码里，模型只负责其中某些确定性节点的转换（如分类、抽取、生成文案），路径可预测、可测试、可审计、成本可控，缺点是遇到未预料的输入就卡住或走错分支。Agent 是「模型自己决定下一步」——由 LLM 依据目标与当前状态动态选择工具与顺序，灵活、能处理长尾与开放式任务，代价是路径不可预测、成本与延迟波动大、评测与调试困难（同一个输入两次跑结果可能不同）。工程上的成熟做法是「Workflow 骨架 + Agent 填充」：外层用确定性流程控制关键节点、审批与回滚，把需要判断的自由度限制在局部（比如只让 Agent 决定调哪个检索工具、是否需要再查一次）。判断标准很实用：如果任务的步骤能被明确写出并且覆盖绝大多数情况，就用 workflow；如果长尾分支多且难以穷举、或者需要根据中间结果决定下一步，才用 Agent。

为什么选 LangGraph 及与其他框架的区别：LangGraph 把 Agent 建模成「状态图」——节点是函数（调模型、调工具、处理数据），边是转移条件，状态在节点之间显式传递，支持条件分支、循环、持久化检查点（checkpoint）、人工介入（interrupt/human-in-the-loop）与时间旅行回放。选它的理由是控制流可显式表达和测试（对比 ReAct 那种「while 循环里让模型自由发挥」的黑盒），并且能中断、恢复、重放，非常适合有审批环节或长流程的业务。与其他框架的对比可以这样讲：LangChain 的 AgentExecutor 是线性循环，灵活性高但状态不可见、长流程难控；AutoGen 偏多 Agent 对话编排（群聊模式），适合研究型协作但流程控制弱；CrewAI 是角色化的团队抽象，上手快但对复杂控制流的表达不如图；LlamaIndex 强在数据/RAG 侧的索引与检索抽象；OpenAI Swarm/Agents SDK 轻量、贴近官方工具生态但跨模型与本地化能力弱。选型的判断维度是：控制流复杂度、状态持久化需求、是否需要人工介入、可观测性/追踪生态、以及是否绑定单一模型厂商。

AI 测试开发的测试体系怎么搭：测开在 AI 项目里的质量保障可以分五层。① 数据与用例：建立分层用例集（冒烟/回归/对抗/边界），覆盖真实用户长尾，用例要带期望结果的判定方式（断言或 rubric），并随线上 badcase 持续补充。② 组件级测试：检索层测召回与排序指标（Recall@k、MRR、nDCG）；模型层测输出格式合法性、指令遵循、幻觉率（用固定集 + 人工标注）；工具层测参数校验、幂等、异常与超时。③ 端到端测试：任务成功率、平均轮数、token 成本、P95 延迟、失败类型分布，并且要多次采样（同一用例跑 N 次看通过率）来应对模型随机性。④ 线上质量与护栏：埋点与 Trace（每轮输入输出、工具调用、耗时）、A/B 对比（新旧 prompt/模型/检索策略）、灰度与回滚、用户反馈闭环（点赞点踩、转人工、投诉归因）。⑤ 工程基建：把这些评测接进 CI（核心用例不过禁止合入）、做评测报告对比与版本基线、把评测集当资产管理（版本化、冻结、防止过拟合）。核心差异在于：传统测试的「输入→确定输出」变成「输入→概率分布」，所以判分要区分确定性断言与 LLM 打分，且必须量化不确定性（通过率而非单次结果）。

设计一个自动生成测试用例的 Agent：可行方案是多 Agent 编排 + 分层产出 + 机器校验：

1. 输入解析：从需求文档/接口定义（OpenAPI、PRD、代码 diff）抽取被测对象、输入域、约束与业务规则，生成结构化「测试对象描述」。
2. 覆盖策略生成：用规则 + 模型结合设计用例维度——等价类与边界值（数值上下限、空值、超长、特殊字符、并发）、状态迁移（状态机的所有合法与非法迁移）、异常路径（超时、依赖失败、权限不足、幂等重复提交）、以及安全用例（越权、注入）。规则引擎保证「该有的维度不漏」，模型负责把维度展开成具体用例。
3. 用例生成：输出结构化 JSON（前置条件、步骤、输入数据、预期结果、优先级、可自动化标记），而不是自然语言段落，便于后续执行与去重。
4. 去重与择优：用文本相似度或语义聚类去掉重复用例，按风险与覆盖增量排序，控制用例总数（比如每个接口 ≤20 条）。
5. 自动执行与验证（闭环的关键）：能被自动化的用例直接生成可执行脚本（pytest/Playwright）并在测试环境跑；断言失败时让 Agent 判断是「产品 bug」还是「用例写错」，把结果反馈回生成环节迭代——没有执行反馈的用例生成 Agent 只能产出一堆看似合理的垃圾。
6. 人工评审与沉淀：高风险用例人工确认，把误报与漏报案例回灌到知识库（prompt 与规则），形成持续改进。
7. 评估 Agent 本身：用「生成用例相对人工基线的新增有效缺陷数、重复率、误报率、可自动化率」来衡量它的价值。