大模型评测实习生到底在做什么?(含腾讯招聘)

最近在招 大模型评测 / LLM Evaluation 方向的实习生。

和一些同学聊下来，我发现很多人第一次听到「大模型评测」时，脑海里的画面大概是：

每天打开几个大模型，问同样的问题，然后看看谁回答得更好。

甚至更简单：

A 和 B 两个答案，选一个。

但如果真正做过一段时间 Evaluation，会发现事情远没有这么简单。

尤其现在大模型正在从：

Chatbot → AI Search → Deep Research → Agent

评测的问题也越来越复杂。

以前我们可能主要关心：

模型回答得对不对？

现在开始需要回答：

一个 Agent 能不能真的把事情做成？

而这也是我们接下来会重点探索的方向。

先说最基础的问题：怎么知道一个大模型到底好不好？

举个简单的例子。

用户问：

「过去一年，日本半导体行业恢复得怎么样？」

模型给了一个很完整的回答，列出了公司、产业政策、营收数据和市场份额。

——看起来非常专业。

但 Evaluation 不能停在「感觉不错」。一个看起来只有几百字的回答，背后可以拆成：

意图理解 → 搜索 → 信息筛选 → 事实核验 → 引用验证 → 信息聚合 → 结论生成

Evaluation 做的事情，就是试图把这些「感觉模型好不好」，变成一套可定义、可测量、可复现的标准。

但 Agent 出现以后，事情又复杂了一层

Chatbot 有一个很大的特点：

输入一个问题，输出一个答案。

所以过去很多 Evaluation 可以简单抽象成：

Input → Model → Output → Score

但 Agent 不一样。

假设你让一个 Agent：

「帮我找到北京未来两周适合举行 20 人团队聚餐的餐厅，预算人均 300 元以内，筛选 5 家并给出理由。」

它可能需要：

搜索餐厅→ 打开网页→ 查询营业时间→ 查询价格→ 排除订不到的→ 对比评价→ 整理结果→ 最终回答

以后更进一步，它甚至可能直接：

打电话 / 调 API / 填表 / 下单 / 发邮件 / 修改文件。

这时候只看最终答案已经远远不够了。

Agent Evaluation 到底评什么？

这是我们接下来比较关注的问题。一个 Agent 最后确实找到了正确答案，是不是就说明这个 Agent 很好？

未必。

它可能：

• 搜索了 37 次

• 调用了 15 次完全没必要的工具

• 同一个网页打开了 6 次

• 已经拿到答案了还继续搜索

• 工具参数填错以后，不断重复相同操作

• 甚至中途执行了本来不应该执行的动作

最后虽然「蒙对了」，但这仍然不应该被认为是一个优秀的 Agent。所以 Agent Evaluation 至少会涉及几个不同层面。

第一层：Task Success

最直接的问题：

任务到底完成没有？

比如：

• 文件有没有真正生成？

• 邮件有没有发给正确的人？

• 数据有没有被正确修改？

• 搜索任务有没有真正找到需要的信息？

• 预订任务有没有完成，而不是只告诉用户「已经为你找到」？

这听起来简单，但实际上是 Agent Evaluation 最基本也最重要的问题。

第二层：Trajectory Evaluation

Agent 和普通 LLM 最大的区别之一是：过程本身也非常重要。我们可能需要观察它整个执行轨迹：

Thought / Plan

↓

Tool Call

↓

Observation

↓

Next Action

↓

Tool Call

↓

Result

然后判断：

• 它有没有选择正确的工具？

• 工具参数是否正确？

• 拿到搜索结果以后有没有正确利用？

• 有没有出现死循环？

• 有没有重复调用？

• 有没有在错误方向上越走越远？

很多 Agent 的问题，并不是「不会回答」，而是：

执行过程失控了。

所以 Agent Evaluation 很大一部分工作，是研究怎么评价一条 trajectory 的质量。

第三层：Planning

例如用户让 Agent：

「调研五家公司的财报，然后做成一个 Excel 对比表。」

一个好的 Agent 应该知道：

先确认公司→ 找财报→ 提取指标→ 对齐口径→ 检查异常值→ 创建 Excel→ 验证文件

而不是一上来就随机搜索。因此我们还会研究：

Agent 是否做出了合理的任务分解？

以及：

好的计划到底应该长什么样？

这个问题其实非常有意思，因为不同任务的最佳执行路径并不一定唯一。

第四层：Error Recovery

我个人觉得这是 Agent 能力里非常值得关注的一部分，真实环境不会永远按照预期运行。例如：

• 网页打不开

• 搜索结果为空

• API 超时

• 登录失效

• 按钮的位置变化

• 工具返回异常数据

这时候真正好的 Agent 不应该直接崩掉，而应该知道：

原来的路径失败了，我需要换一个方法。

所以 Evaluation 也需要测：Agent 遇到错误以后，能不能恢复？

例如可以专门制造：

• Tool Error

• Timeout

• Missing Information

• Conflicting Evidence

• Invalid Parameters

然后观察 Agent 如何处理。某种意义上，这比测试正常情况下能不能完成任务，更能拉开 Agent 的能力差距。

第五层：效率

假设两个 Agent 都完成了任务。

Agent A：

8 步完成。

Agent B：

43 步完成。

当然不能简单认为 A 一定更好，但显然完成任务需要付出的成本也是 Evaluation 的一部分。最终可能变成：

Success × Quality ÷ Cost

这类综合评价问题。

第六层：安全和边界

Agent 最大的变化是它不只是生成文字，它开始执行动作。所以很多以前影响不大的错误，现在可能变得非常严重。

比如：

用户说：

「帮我整理这些邮件。」

Agent 却顺手把邮件删掉了。

或者：

「帮我找几个航班。」

Agent 直接下单。

这时候 Evaluation 就不能只评价：

「结果正确不正确。」

还需要判断：

这个动作有没有获得授权？

这会成为 Agent Evaluation 非常重要的一部分。

Agent Evaluation 最难的地方之一：Ground Truth 不再简单

传统测试里经常有：

标准答案。

但 Agent 很多时候不存在唯一标准路径。

例如：

「找到 OpenAI 最近发布的三篇研究文章。」

Agent 可以：

• Google 搜索

• 直接打开 OpenAI 官网

• 搜索新闻

• 调用搜索 API

最后都可能得到正确结果，所以 Agent Evaluation 很难简单写成：

第一步必须 A

第二步必须 B

第三步必须 C

否则很容易出现 Agent 明明用了另一条更好的路径，却被判错。所以一个很有意思的问题是：

到底应该评价结果，还是评价过程？

答案通常是：两个都要评。但应该怎么组合，就是一个真正的 Evaluation 问题。

那 Agent 到底怎么自动评？

这也是我们比较想探索的方向。很多场景下，单纯用 LLM-as-a-Judge 已经不够了。未来 Agent Evaluation 很可能是：

• Rule-based Evaluation：检查文件是否存在、字段是否正确、API 是否执行成功。

• State-based Evaluation：检查执行前后的环境状态有没有达到目标。

• Trajectory Evaluation：检查工具选择、参数、执行路径是否合理。

• LLM-as-a-Judge：判断一些难以规则化的质量问题。

• Human Evaluation：处理真正复杂或者边界模糊的问题。

最后形成一套混合 Evaluation Pipeline。这其实比：

「写一个 Prompt，让 GPT-5.6 打个 1～5 分」

要复杂得多。

所以这个实习岗位会做什么？

目前主要会涉及几个方向：

AI Search / Deep Research Evaluation

研究：

• 搜索质量

• 信息召回

• 多跳检索

• 证据聚合

• 引用一致性

• 冲突证据

• 跨文档推理

Agent Evaluation

接下来会是比较重要的方向，包括：

• Task Success

• Tool Use

• Planning

• Trajectory

• Error Recovery

• Efficiency

• Safety

• Agent Benchmark

• Agent Evaluation Pipeline

这个岗位不是传统意义上的「数据标注」

确实会接触数据，也一定会做人工 Evaluation。但我们希望实习生逐渐经历这样一个过程：

一开始：

这个 Agent 做错了。

然后变成：

它为什么错？

再然后：

这个错误应该怎么定义？

接下来：

怎么批量发现这种错误？

最后：

能不能自动判断？

如果现有 Evaluation 判断不了：

是不是应该重新设计 Benchmark？

这其实就是 Evaluation 比较有意思的地方。

什么样的同学比较适合？

计算机、人工智能、NLP、数据科学当然很好。但比专业更重要的是几个能力：

逻辑能力

看到一个 Agent 失败，不能只说：

「它好像有点笨。」

而是能进一步说：

「它第一次 tool call 返回空结果之后，没有调整 query，而是重复调用同样的工具，所以这里属于 error recovery failure。」

这种把「感觉」变成「定义」的能力非常重要。

信息检索能力

遇到不知道的问题，知道去哪里查、怎么查、怎么交叉验证。

对 LLM / Agent 真正有兴趣

如果你折腾过下面这些东西，会比较加分：

• Prompt

• RAG

• Function Calling

• MCP

• Agent

• Workflow

• OpenClaw

• Coze

• API

• Browser Automation

最后，说一下招聘

岗位：大模型评测 / Agent Evaluation 实习生

主要方向：

LLM Evaluation / Agent Evaluation / AI Search / Deep Research / SFT

其中接下来会重点探索：

Agent Evaluation、Tool Use Evaluation、Trajectory Evaluation、Agent Benchmark 与自动化 Evaluation Pipeline。

地点：北京

实习方式：日常实习

实习时间：每周 4 天以上，连续 3 个月以上

年级：本科 / 硕士均可

如果感兴趣，可以知乎上私信：

1. 学校 / 专业 / 年级；

2. 做过哪些 AI / LLM / Agent 相关的东西