测试之家

AI测试 豆包评测 02A 篇：从豆包 JD 拆解算法评测岗：5 模块能力地图

哞小妞 · 2026年07月16日 · 62 次阅读

（主读者：做功能测试、测试开发，想转 Agent 评测的人；产品转评测的朋友，这是你的「另一半地图」，关键处我标了「产品视角看这段」。）

写这个系列，我一直在想从哪个口子切进去最顺。第 01 篇把豆包的能力盘子摊开了，但那是从产品视角看。这一篇换个角度，从一份真实的招聘 JD 看。

为什么拿 JD 当入口？我自己的体会是，JD 是一家团队最诚实的战略文档。产品文档写的是「我们要做什么」，技术文档写的是「我们怎么做」，只有 JD 写的是「我们缺什么人、在担心什么风险」。你招一个算法评测专家，说明团队已经有个自己搞不定的质量窟窿。把这个窟窿反向画出来，就是一份现成的评测能力地图。

所以本篇不空谈「评测岗需要什么能力」，而是锚定一份截至 2026.07 仍在招的真实 JD，把它一行行拆开，再映射到豆包的五大能力评测上。它同时也是整个系列的学习导航：后面每一篇，差不多都能在这张地图里找到自己的位置。

一、测试转评测的人，最该先搞清什么

如果从功能测试、测试开发岗转过来，你第一反应大概是：要不要去补一堆算法课？我当年的答案踩过坑。不是先补算法，是先搞清「我这个岗位到底要补哪几块」。

JD 恰好是这个问题的浓缩答案。它把团队对「一个合格评测人」的全部期待，压缩成几行职责。你不用猜、不用刷一堆泛泛的「AI 测试指南」，直接读 JD，反推能力缺口，比任何二手总结都准。

后面你会看到，5 个模块里，你其实早就有 3.5 件底子。先把「我有什么、缺什么」画清楚，再动手，才不会一上来被术语吓退。这也是本篇想替你做的第一件事：把焦虑换成一张可勾选的清单。

二、先交代来源和口径

下面拆解的锚点，是字节招聘官网在招的「AI 算法测试开发专家 - 豆包手机助手」（职位 ID A162334，上海，截至 2026.07 仍可投递）。我选它做锚点，是因为它同时满足三个条件：名字里带「豆包」、职责明确是「算法测试开发」、而且把大模型评测写进了正文职责而非仅仅加分项。

同类在招的还有「AI 应用测试开发工程师 - 豆包手机助手」（职位 ID A38688，北京）、「测试开发工程师 - 模型评测及自动化」（北京，明确要求「构建端到端的 Agent 评测体系」）、以及校招的「算法评测工程师 - 质量技术」（深圳，2026 届）。这些我都列在文末参考里，方便你核对原话，避免我转述走样。

有一点要说清：JD 是会变的。今天拆的是 2026.07 这版，豆包团队下半年招人要求很可能又加新东西。所以这篇的价值不在 JD 永远正确，而在教你一套从 JD 反推评测能力的方法。方法学会了，JD 怎么变你都能自己拆。

三、把 JD 拆成 5 模块能力地图

把这份 JD 的职责和要求捋一遍，它其实天然分成 5 个模块。我做了一张地图，后面整篇就围着它转。

模块 JD 里的原话指向 对应豆包评测的哪块 你要具备的底子
1 质量风险识别与解决 「推动质量风险识别与问题解决，保障产品质量与用户体验」 横切五大能力，发现产品级风险 传统测试的风险意识、用户视角
2 质量保障智能化 「统筹质量保障智能化建设，探索 AI / 大模型在 QA 的应用」 用 Agent 编排搭评测工具、提效 自动化思维 + 对 LLM 应用有手感
3 前沿技术跟踪 「跟踪 LLM 最新研究，涵盖 LLM / MLLM / Prompt / RAG / Agents / SFT / RLHF」 理解五大能力的技术底座 愿意读论文、跟技术节奏
4 评测体系建设 「评测方案 / 指标设计、数据收集更新、评测执行、输出报告」 五大能力各一套评测体系 指标设计 + 数据构建 + 报告
5 评测工程化 「参与评测相关自动化工具的开发与维护，最大化提升效率」 搭 harness、评测平台 扎实编码（Python / Go / Java / C++）

看到这张表你可能已经感觉到，模块 1 到 5 基本上就是从意识、到体系、再到工具的递进。下面一个模块一个模块说，重点放在「这对评豆包到底意味着什么」。

四、模块 1：质量风险识别与解决

JD 第一句就是「推动质量风险识别与问题解决」。这句话看着虚，其实最实。传统测试里你也干这个：等价类、边界值、场景法，本质都是预判哪里会出事。到了豆包这种非确定性系统，风险点从「必然崩」变成了「偶尔错」。

我习惯把豆包这类产品的质量风险先分几类，后面建评测才有抓手：

  • 幻觉类：事实性编造（把没发生过的事说成真的）、引用造假（编一个不存在的论文或网页）、张冠李戴（把 A 的功能安到 B 上）。这类在传统测试里几乎没有对应物，是 LLM 独有的。
  • 退化类：同一个 Prompt 今天答得好、明天答得歪；多轮对话后半段忘了前半段说的；长上下文里前面的约束到后面失效。本质是输出的统计漂移，不是确定性 bug。
  • 一致性塌方：某个长文档一喂进去就开始胡编引用；角色人设中途崩掉；前后回答自相矛盾。这类往往长输入、复杂指令才暴露。
  • 安全与越权类：越狱套出不该说的、敏感信息泄露、被用来生成违规内容。第 01 篇的「产品质量红线」里安全漏过率一票否决，根就在这。
  • 能力边界类：超长上下文截断丢信息、图文不匹配、多语种混输翻车。这类更接近传统「边界值」思维，只是边界从数字变成了 token 长度和模态。

举个怎么把风险变用例的具体做法。拿「多轮遗忘」来说，传统测试你会写一个「连续点击同一按钮 50 次」的用例；评豆包你就写一个「先让模型记住一个虚构偏好（比如『我喝咖啡不加糖』），隔 8 轮对话后再问『我喝咖啡加不加糖』」，看它有没有忘。风险点没变，还是「状态保持」，只是触发方式从接口调用变成了自然语言轮次。

所以模块 1 不是新能力，是你原有风险意识的迁移。区别只在于豆包的「缺陷」形态变了：从 crash 变成了上面这几类。第 01 篇说的「产品质量红线」，根就扎在这块。

五、模块 2：质量保障智能化

这一条挺有意思，它要求你「用 AI 来保障 AI 的质量」。JD 原话是探索人工智能在质量保障领域的应用。落到豆包评测上，就是第 01 篇 taxonomy 里的 Agent 编排能力：你拿 LLM 当评测员（LLM-as-Judge）、拿 Agent 当自动化执行器去批量跑 case、拿 RAG 去管评测知识库。

我理解，这是评测岗和传统测试岗最不一样的地方之一。传统测试提效靠写脚本，算法评测提效靠「造一个小评测 Agent」。下面三块是我实际踩过的，展开说一下。

LLM-as-Judge 怎么落地。 最朴素的用法：把一条评判标准写成 rubric（比如「回答是否准确引用了给定文档、有无编造」），连同被测回答一起喂给 judge 模型，让它按 rubric 打 1~5 分并给理由。比人肉看几百条快得多。但这里有个坑必须说：judge 自己会犯错，而且错得有偏好，文献里叫 position bias（放前面的答案更容易被打高分）、verbosity bias（越长越像对）、self-enhancement bias（和自己观点相近的容易被打高分）。所以 judge 出来的分不能直接当结论，得有人工抽检兜底，还要算 judge 和人工标注的一致性（比如用 agreement rate 或相关系数）来估它的可信度。后面系列有一篇专门讲 judge 校准，这里先埋着。

评测 Agent 长什么样。 不是一定要上框架，核心就三件事：能批量调豆包跑 case、能按规则自动判分或调 judge、能把失败 case 自动归因归类。比如你要评「长文档问答一致性」，Agent 自动生成 200 个长文档 + 问题对，并行调用豆包，再用 judge 判每个回答有没有编造，最后把「编造」的 case 聚成几类（引用缺失 / 数字错 / 张冠李戴），你只人工看这几类就行。这一圈下来，原本要一个人看两天的事，半小时出初步结论。

RAG 管评测知识库。 评测做久了，你会攒一堆 rubric、历史 bad case、判分样例。把这些塞进一个 RAG，judge 跑的时候能检索到「上次这类题是怎么判的」，判分就稳了，也方便新人接手。

模块 2 说到底，是「用 LLM 做评测」。这是传统测试没有的新一层，但底层还是你熟悉的自动化思维，只不过执行器从 selenium 换成了 Agent。

产品视角看这段：模块 2 里「评测 Agent 自动归因归类」产出的那几类 bad case，恰恰是产品定义「什么算好」时最缺的输入。评测给产品喂证据，产品拿证据定标准，两条线在这交汇。

六、模块 3：前沿技术跟踪

JD 列了一串：LLM、MLLM、Prompt 工程、RAG、Agents、SFT、RLHF。这串清单其实就是豆包五大能力的技术底座。你不需要变成算法研究员，但得知道每个技术「变了，我的评测方案要改什么」。

先把几个黑话翻译成人话，免得卡壳：

  • RAG（检索增强生成）：让模型答题前先去查资料库再开口，等于给它配了本可以翻的参考书。
  • SFT（监督微调）：拿标好的问答对喂模型，教它学会特定任务的回答风格。
  • RLHF（基于人类反馈的强化学习）：用人对回答的好恶打分，把模型往「让人满意」的方向推。

翻译完说具体的。RAG 上线了，你的评测就得加「检索召回准不准、引文是不是真的」这一项；Agents 上线了，评测维度从「单轮答对」变成「多步任务完成率」。再补一个：SFT / RLHF 上线后，你还得关心「对齐有没有过头」，模型是不是变得太安全以至于该答的不答（拒答率异常）、是不是被 RLHF 教出了刻板套话。这类「能力没退但行为变味」的问题，传统功能测试根本不会测，是算法评测特有的。

第 03 篇我会专门讲，JD 里的这些术语，评测岗到底要懂到什么程度，先在这里埋个伏笔。这块我自己在摸索，不敢说门清，但方向是清楚的：评测视角的技术理解，够用就行，不必追推导深度。

七、模块 4：评测体系建设

这是 JD 里篇幅最重的一块：设计评测方案、制定评测指标、收集更新评测数据、执行评测、输出专业报告。对应第 01 篇的结论，豆包五大能力需要五套评测体系，不是一把尺子量完，文本对话一套、语音一套、多模态一套、Agent 一套、AIGC 生成一套，指标和判法都不一样。

这里有个容易踩的坑，我得提醒一句。很多人把「评测」理解成「跑个 benchmark 出个分」。但 JD 写的是「体系建设」，这两件事差很远。一套能用的评测体系，我理解至少得有这几样：

  • 数据集持续维护：case 不是一次性造完，要随模型能力长进不断加难、加边界、加对抗样本，还要定期清掉过时的（模型已经全对的就没区分度了）。
  • 版本快照：每次评测必须记模型版本号、数据集版本号、判分器版本号。否则「这次比上次高了 3 分」根本不知道是模型好了还是数据集换了。
  • 回归看板：每次模型迭代自动跑全量，分数变化一眼可见，退化的维度自动标红。
  • 红蓝对抗：除了正向评测，还要有人专门找茬（越狱、诱导违规、边界挑衅），这部分往往最能暴露真问题。

为了更具体，我给一个「单维度评测方案」的骨架，你照着填就能用。以评「长文档问答一致性」为例：

  • 目标：豆包在喂入 1 万字以上文档后，回答是否仍严格基于文档、不编造。
  • 数据集：200 个（文档，问题，标准答案片段）三元组，覆盖 5 类风险（引用缺失 / 数字错 / 张冠李戴 / 跨段矛盾 / 超长丢失）。
  • 指标：事实一致率（judge 判「未编造」占比）、引用准确率（引用的段落真存在于原文的比例）。
  • 判分：LLM-as-Judge 按 rubric 打 1~5，人工抽检 10% 算 agreement。
  • 回归：每次模型发版跑全量，事实一致率跌超 2 个点自动告警。

可复现三要素就一条：同模型版本、同数据集、同判分器，缺一个结论就不能比。这条在第 01 篇的评测纪律红线里也强调过。一次性的跑分是玩具，能持续回归的体系才是资产。

产品视角看这段：模块 4 的「红蓝对抗」「回归看板」产出的质量准出结论，是产品决定「这个版本能不能发」的核心依据。评测体系不是测试团队的私活，是产品的发版闸门。

八、模块 5：评测工程化

最后一条是「评测自动化工具的开发与维护」。说白了，评测不能靠人肉点，得有 harness、有平台、有 CI。同类在招的「测试开发工程师 - 模型评测及自动化」把这条写得更狠：要「构建端到端的 Agent 评测体系，多维度多指标全面评估 Agent」。这正好对上豆包 taxonomy 里的 Agent 编排评测。

工程化这块，传统测试转过来的人其实有优势，你本来就会写自动化。区别是评测对象从确定性接口变成了非确定性模型输出。一个评测 harness，我理解通常就四件套：

  • case 管理：评测用例从哪来、怎么版本化、怎么按维度筛。
  • 执行引擎：批量调豆包（或本地模型），支持并发、重试、超时。
  • 判分器：硬规则判分、相似度判分、或接 LLM-as-Judge，可插拔。
  • 报告：分数聚合、维度下钻、退化对比、失败 case 导出。

非确定性带来的工程难点得专门说。传统断言写 assert resp == expected，现在不行了，同一个问题模型可能给三个不同但都对的答案。所以断言要换成：相似度超阈值、或 judge 判「语义一致」、或用统计阈值（跑 N 次，一致率超 95% 算过）。而且结果有方差，一次跑出来偏低不代表模型差，要跑多次取统计。这是和我们老本行最大的不同，第一次搭 harness 很容易在这栽跟头。

不同能力的 harness 还不一样。Agent 评测的 harness 最重：要模拟工具调用环境、记录多步轨迹（plan → action → observation → 反思）、判「任务到底完成没」。多模态的 harness 要管图文对、VQA 标注。语音的 harness 要管音频采样、转写对齐。后面系列分能力讲评测时会逐个拆，这里先建立「harness 是评测的工程骨架」这个意识。

最后提一句 CI：每次模型迭代自动触发回归，分数异常自动拦，这一步做好了，评测才真正变成资产而不是一次性表演。

九、5 件事，3.5 件你已经有底子

把 5 个模块摊开，你可能会觉得「这也太多了吧」。我自己的经验是，别被吓到。传统测试转算法评测，不是推倒重来，是能力迁移。

  • 模块 1（风险识别）：你基本全有，测试思维通用。
  • 模块 4（评测体系里的方案 / 指标 / 报告）：你大半有，方法论相通，只是对象从功能变成模型。
  • 模块 5（工程化）：你有编码底子，但评测 harness 是新的。
  • 模块 2（智能化）：你半有，自动化你会，但「用 LLM 做评测」是新一层。
  • 模块 3（前沿跟踪）：你最缺，得补，但不必深，跟节奏就行。

所以算下来，5 件事里大概 3.5 件你已经有底子。你不是从零开始，是在已有测试能力上叠加 AI 这一层。剩下那 1.5 件，就是这个系列要陪你补的。

为了更直观，我把这个迁移关系压成一张小表，你可以对着标自己：

能力维度 传统测试里的你 算法评测里的你 迁移难度
风险识别 等价类、边界值、场景法 幻觉 / 退化 / 一致性塌方预判 低，思维通用
用例设计 功能用例、异常用例 Prompt 变体、对抗样本构造 中，对象变了
缺陷管理 Bug 生命周期、严重度分级 退化监控、归因分析 中，分级思维通用
自动化 接口 / UI 自动化框架 评测 harness、CI 回归 中，断言方式变了
技术跟踪 跟版本变更 跟 LLM / RAG / Agent 演进 高，得新学

光有这张表还不够，我给你每一维一个最省力的补法，都是我自己试过的：

  • 风险识别（低难度）：把上面模块 1 那 5 类风险抄成一张检查单，每次评测前过一遍。这步几乎零成本，但立刻让你比「只看功能对不对」的人专业一档。
  • 用例设计（中难度）：建一个 Prompt 变体库，同一个意图写 10 种说法、加对抗扰动（错别字、倒装、加干扰句）。这就是你原来的「异常用例」思维，只是对象换成了自然语言。
  • 缺陷管理（中难度）：把「退化」当 bug 管，建一个退化监控看板，模型发版前后分数对比自动标红，和原来的 bug 严重度分级一脉相承。
  • 自动化（中难度）：从零写一个最小 harness（上面模块 5 四件套），先只评一个维度。写一遍就通了，比看十篇教程管用。
  • 技术跟踪（高难度）：别追推导，跟节奏。我固定看几个源：arxiv 的 LLM / Agents 新帖、QCon / AICon 的评测分享、豆包官方的模型更新日志。知道「RAG 上线了评测要加什么」就够了，不必会推导 attention。

十、横向看一眼：友商在招什么

光看豆包一家还不够。我把几份同期在招的头部厂 JD 也扫了（截至 2026.07，链接放文末），发现一个有意思的共识：这不是豆包一家的心病，是行业共性。下面这几家统一用「某头部大厂」指代，你看能力维度就能对上号。

  • 某头部大厂（社交 / 内容平台）的 AI 智能体评测岗，要求跟踪 SWE-bench、HumanEval、MMLU、AgentBench 等基准，懂 ReAct、Function Calling、Tool Use、Planning。
  • 某头部大厂（电商 / 云）的大模型评测与对齐岗，强调 LLM-as-Judge、Arena 对战评测、Rubrics 评测，还要建「数据 → 训练 → 评测 → 反馈」的数据飞轮。
  • 某头部大厂（短视频）的大语言模型评测岗，写明要做竞品对比、从可解释性角度探索评测基准、甚至「定义 AGI」。

共性能力维度就几个：LLM 通用能力评测、Agent 任务评测、多模态评测、评测工程化与平台、数据飞轮。和豆包这份 JD 的 5 模块高度重合。所以你按豆包 JD 练出来的能力，到别家也对得上，这算是个好消息。

十一、用行业一手实践印证：JD 不是画饼

JD 写得好，不代表团队真在做。这点我专门去核对了字节近一年的公开技术分享，发现 JD 里那几条，还真不是口号。

  • 史海量《AgentOps 实战》（QCon 北京 2025）：把「离线评测质量准出 + 线上在线评测持续监测」的闭环讲透了。离线侧用 LLM-as-Judge、Code Evaluator、Human-in-the-loop 做发布前准出；线上侧埋点监测真实流量里的退化、幻觉、越界。而且明确说了在 Coze 和豆包上实践。这对应模块 4（体系）+ 模块 5（工程化）。对读者的启示：评测不是发版前跑一次，而是「离线准出 + 线上监测」两头夹，这才是真体系。
  • 沈桐《Eino 框架实践》（同场）：组件抽象加业务编排，把模型调用、工具、评测做成可插拔组件，评测是集成进开发流程的，不是事后补刀。对应模块 2 的「用 AI 提效」。启示：评测越早嵌入研发链路，越不被动。
  • 尹小明《评测也很酷——Agent 自动化评测技术创新与实践》（AICon 深圳）：三层 Agent 评测框架（单能力 / 任务 / 系统）+ 数据飞轮（评测数据从线上 bad case 反哺）+ 统一评测平台。对应模块 2（智能化）+ 模块 5（工程化）。启示：评测数据要「从线上来、到评测里去」，飞轮转起来才可持续。

这些一手实践说明，JD 里「评测体系建设」「工程化」「智能化」不是写在招聘页上的漂亮话，团队确实在投入。对咱们读者来说，这意味着：照着 JD 练，练的是真需求，不是屠龙术。

十二、落地策略：把 JD 变成你的 Checklist

说完是什么，说怎么用。我的建议就三条，都是踩过坑后的实在话。

  1. 以 JD 为 Checklist。JD 每一条要求，都映射到豆包的一个风险点或评测维度。你拿这份 5 模块地图当清单，缺哪块补哪块，比漫无目的刷论文管用。
  2. 优先补齐「半有」模块。上面说模块 2（智能化）和模块 3（前沿）是你最该补的。自动化与 LLM 前沿，是传统测试转评测岗的最短路径，先啃这两块性价比最高。
  3. 里程碑驱动，别只学概念。按「用例 → Pipeline → 单维度方案」三阶段验收自己。比如先手跑 20 条 Prompt 变体看豆包答得稳不稳（用例），再写成能自动跑的脚本（Pipeline），最后形成一份单维度评测方案（维度）。只学不落地，等于没学。

为了不让上面三条悬空，我拿「评豆包长文档问答一致性」走一遍，你看落地长什么样。顺便说一句手工评测和自动 benchmark 的差别：手工评测像人肉数米粒，准但慢、还累；自动 benchmark 像电子秤，快且稳，但得先校准。两者不是谁取代谁，是米粒少时你数得过来、米粒上万时得上秤。

  • 用例阶段：先手搓 20 个长文档问答对，覆盖引用缺失、数字错、张冠李戴几类，人工看豆包答得稳不稳。这一阶段不要写代码，先建立手感。
  • Pipeline 阶段：把 20 个扩到 200 个，写成能自动调豆包、自动 collect 回答的脚本。这时候你就在搭模块 5 的 harness 了。
  • 维度阶段：给这 200 个定指标（事实一致率、引用准确率）、接 judge 判分、做成每次发版自动回归的单维度评测方案。这就是模块 4 的「体系」雏形。

走完这一圈，你同时碰了模块 1（风险分类）、模块 2（judge）、模块 4（体系）、模块 5（harness），等于拿一个小闭环把 5 个模块串了一遍。比漫无目的刷论文踏实得多。

十三、给你一张能力账本模板

开篇贴里我提过，传统测试的底层能力账本，5 件事里 3.5 件能直接复用到算法评测。顺着这个思路，找一份算法测试 JD，标注「已有 / 半有 / 需新学」，就是这份账本最具体的做法。这份 5 模块地图就是现成模板。你现在就可以把豆包这份 JD 的 5 个模块，对照第九节那张迁移表，给自己标一遍。标完你就知道，下一篇该先补哪块，而不是被一堆术语吓住。

参考与延伸

真实 JD（截至 2026.07，可核对原话）

公开技术分享（印证 JD 落地）

评测基准与框架（友商 JD 中高频出现，后续篇章展开）

  • 通用能力：MMLU、GSM8K、HumanEval、SWE-bench
  • Agent：AgentBench、WebArena
  • 方法：LLM-as-Judge、Rubrics 评测、Arena 对战评测、数据飞轮

下篇预告

本篇是从测试 / 算法评测视角，把一份豆包 JD 拆成了 5 模块能力地图。下篇换个角色，用一份真实的豆包产品经理 JD 来拆：同样对着五大能力，从一个做产品的人眼里，这张地图长什么样、和测试视角怎么互补。至于模块 3 那串术语到底要懂到什么程度、以及那份评测视角术语速查表，我们放到产品 JD 那篇之后再说。

作者注：本系列是一边工作、一边实操、一边琢磨着写出来的，规划约 100 篇，内容和篇幅会随实际调整；为保证质量，不追求固定的更新频率。以上内容基于脱敏内部信息、公开权威资料和自己踩坑后的理解，不一定对，欢迎拍砖。

「原创声明：保留所有权利，禁止转载」
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册。