02A 和 02B 两篇拆 JD，最后都撞上同一串英文：LLM、MLLM、Prompt、RAG、Agents、SFT、RLHF。我在 02A 里就埋了句，这些术语评测岗到底要懂到什么程度，放到这篇专门说；02B 的结尾也预告了，会给你一份「评测 / 产品视角最低理解门槛」的速查表。
先说说为什么前两篇要花那么大力气去拆 JD。说点我自己的看法：一个合格的评测，或者说测试角色，本质上是用户的试用员。用户没空把产品每个角落都戳一遍，你替他去戳；用户说不清哪里别扭，你替他把话讲出来；用户懒得一步步操作，你替他把流程跑通。你是在帮用户提前体验这个 agent 产品，然后诚实地告诉用户：它好在哪、能帮你把什么活干利索。
这么一想，定位就清楚了。你对这个被评 agent 产品的理解，得贴近产品、甚至要摸到产品经理之上，因为他定义「什么算好」，你得比他更早看出「哪里还不够好、哪里会翻车」；你对背后 agent 技术实现的理解，也得尽量往算法和工程研发那边靠，因为他负责把价值造出来，你得能证明价值真交付了没有。这正好回到咱们系列那句统一准绳：无论产品还是测试视角，都是在回答同一个问题，怎么保证 agent 产品给它的用户带来最大的用户价值。这篇要讲的术语，就是帮你把这两层理解力同时往上抬的梯子。
先把结论撂这，省得你焦虑：不需要变成算法研究员。评测岗、产品岗要的从来不是懂算法推导，而是另一句话：每个技术变了，我的评测方案（或产品需求）要跟着改什么。这份表就是帮你建立这种反射，表里每条都给了「评测视角」和「产品视角」两行，一个管怎么证明价值交付了、一个管怎么把价值造进需求，两边最终都落到同一句：它变了，你的下一步改什么。
一、这份表怎么用：四个原则
光有表不够，得知道怎么用才不白看。我自己的用法是四条，都是踩过坑后的实在话。
原则 1：评测视角优先，不追算法推导深度。 每个术语只学到「它对评测意味着什么」这一层就够。比如 Transformer，你不必会推导注意力公式，只要知道「模型是全局理解不是逐字理解，所以评指代消解要考虑它全局注意力能关联远近词、也会在长文本里漂移的特性」就够了（这句里的「这点」指的就是全局注意力特性，具体怎么造用例看术语表 Transformer 条）。02A 模块 3 已经把 RAG / SFT / RLHF 翻成人话了，这里从评测视角再补一刀。深度都是够用就行，这是整个系列反复说的。
一个我身边真发生的例子：有人评豆包写文案，prompt 没做版本化，同一意图换了种说法分数差了 10 分，最后归因到「模型不稳定」，其实是 prompt 模板飘了。懂「评测视角优先」的第一件事，就是先把 prompt 锁死再谈别的，否则你评的不是模型，是自己的模板。
原则 2：变化触发更新，而不是被动补功课。 模型架构、训练方法一变，先问一句「我哪些指标和用例会失效」。举个具体的，假设豆包某次升级把生成链路由「直接生成」切到「先 RAG 检索再生成」，你的评测方案就得立刻加三件事：检索召回率（找没找对）、引用准确率（引文真不真）、以及「检索到了但生成脱离」的新型幻觉。不跟着变，你评的还是旧世界，新引入的风险全漏了。这一条最该写厚，因为它就是术语从字典变工具的开关：每次模型一发版，你拿这张表过一遍，比翻任何文档都快。
原则 3：把 JD 术语清单变成你的评测知识地图。 一份 JD 里的术语串，本身就是一张现成的评测关注点清单。我们当时是这么落地的：把 JD 那串术语做成一页纸 checklist，新人入职第一周对照打勾，半有和需新学的标红，主管一眼看见短板在哪。比扔一本《深度学习》给人强。表放在文末参考里也能当 checklist 用。
那一页纸长这样：六组术语各一行，已有打绿、半有打黄、需新学打红；红得最多的那个人，第一周重点补。主管周会扫一眼红黄分布，就知道团队短板在哪、培训往哪压。这是把「术语」变成「管理抓手」的最小成本做法。
原则 4：用术语反推评测维度，而不是正向补算法。 看到 JD 里一个词，别去想「我要不要学这个算法」，去想「它对应我评测体系里的哪一根柱子」。比如看到 Agent，反推的是「我有没有多步任务完成率的评测」；看到 RAG，反推的是「我有没有检索召回和引用准确的评测」。这样 JD 不再是恐吓信，而是一张评测维度待办清单。这条和原则 2 是一对：原则 2 管「变了怎么改」，原则 4 管「看着词怎么建」，合起来你就不会被 JD 吓住。
补两个完整示范，把几条用熟。
示范 1（上下文窗口）：评测视角说「要测超长截断丢信息」，落到动作就是造一批 2 万字文档问答对，跑豆包，看后半段约束有没有失效，跌超阈值就告警；产品视角说「别让用户塞超窗口 PDF 还指望一字不差」，落到动作就是产品上做分段上传，或加「已超出可处理长度」的兜底提示。一个词，两边各自长出一条可执行的动作。
示范 2（Agent）：评测视角落到四条动作，造一个「订机票 + 改签 + 报销」三连任务看端到端做完没（多步任务完成率）、记录每步 plan-action-observation 轨迹（决策可追）、测工具调用对不对参数填对没（工具准确率）、某步挂了有没有回滚（失败兜底）；产品视角说「用户要的是事办成不是聊开心」，落到动作就是产品上做任务进度展示和中断恢复。一个词，两边各长四条可执行动作。这就是「最低理解门槛」的意思：不是懂定义，是懂「下一步改什么」。
这四条合起来一句话：术语是动态变量，你盯着「它变了改什么」这一个锚点，就不会被 JD 里那串词吓住。
二、术语速查表（按评测关注点分组）
下面分六组。每组内的术语，我都按「一句话人话 → 评测视角 → 产品视角」给。评测视角解决「它变了，我的评测方案改什么」；产品视角解决「它变了，我的需求边界改什么」。
2.1 模型架构与基础
Transformer
一句话：现在主流大模型底层的网络结构，靠注意力机制让模型读一句话时同时看清词和词的关系，不是逐字死读。
评测视角：模型是全局理解（一次性看清整句词与词关系，正是指代消解的能力来源），评「指代消解」时，简单短句区分度低不必堆，真正该造的是「远距离指代 + 多候选干扰」的 case：比如让豆包读一篇 3000 字文章，中间反复出现「他 / 该公司 / 这个方案」，看它到后半段还认不认得对；「长句逻辑」同理，长距离约束到后面可能失效，造例时把关键约束放在句首或句尾两端对照测。
产品视角：不用懂结构，但要知道模型理解靠上下文整体，别指望它严格按你给的字段顺序作答。
注意力机制 Attention
一句话：Transformer 的核心，让模型生成每个词时，去权衡前面哪些词更重要。
评测视角：注意力是软的、会漂移，长文本里前面的约束到后面可能失效，这是退化类风险的根源之一。
产品视角：理解「模型会抓重点也会跑偏」，长 prompt 里关键约束要前置或重复强调。
预训练 Pre-training
一句话：模型在海量通用数据上先练出的「基本功」，类似于上学前的广泛阅读。
评测视角：预训练能力是底座，很多「常识题」考的是这层；评测要区分这是预训练能力还是后面微调加的。
产品视角：判断一个能力是不是「通用都会」，决定你要不要为它单独做产品方案。
Token
一句话：模型读写文本的最小单位，中文里大约 1~2 个字算一个 token，不是按字算。
评测视角：延迟和成本都按 token 算，长上下文问答里 token 消耗是隐藏指标，评测要记。
产品视角：按 token 计费，长文档、多轮对话的成本估算得用它，别按字数估。
上下文窗口 Context Window
一句话：模型一次能「看到」的文本长度上限，超出部分会被截断或遗忘。
评测视角：必须测超长截断丢信息、长文档后半段约束失效；豆包长文档问答尤其要覆盖。
产品视角：产品上别让用户塞超窗口的 PDF 还指望一字不差，要做分段或兜底提示。
Embedding 向量化
一句话：把文字变成一串数字（向量），让机器能算「这两句话像不像」。
评测视角：语义相似度判分、RAG 检索都靠它；要关注向量质量影响召回和判分准不准。
产品视角：搜索、推荐、聚类这类功能的质量，底层都卡在 embedding 好不好。
2.2 生成与训练
Prompt
一句话：你给模型的指令，决定了它干什么、怎么干。
评测视角：评测必须先锁定 prompt 模板，换 prompt 等于换尺子，结果不可比。
产品视角：prompt 就是产品的「使用说明书」，写得含糊模型就答歪。
提示工程 Prompt Engineering
一句话：研究怎么把指令写得更让模型听话、更出好结果的一套方法。
评测视角：评测集里的 prompt 要版本化，同一意图写多种说法、加对抗扰动，才测得出鲁棒性。
产品视角：把用户意图翻译成好 prompt，是产品体验的一部分，值得专门打磨。
温度 Temperature
一句话：控制输出随机性的旋钮，0 像背标准答案，1 像天马行空。
评测视角：评生成任务温度必须锁定，否则同一 case 测两次分数不同，结论不可信。
产品视角：产品上创意类场景可调高、严谨类要调低，这是体验旋钮不是质量旋钮。
Top-p / Top-k 采样
一句话：模型挑下一个词时，只在「概率最高的那一批」里随机选，控制发散程度。
评测视角：和温度一样要锁参，评测生成多样性时这两个值直接决定产出分布。
产品视角：和温度配合调「稳还是活」，影响用户感知的鲜活度。
微调 Fine-tuning
一句话：在预训练基础上，用特定数据再调教一轮，让模型学会某项专长。
评测视角：要前后对比，微调可能「学会新的、忘了旧的」（灾难性遗忘），通用能力得复测。
产品视角：别以为加微调只加能力，要问「它会不会丢了原来好的」。
SFT 监督微调
一句话：拿标好的「问答对」喂模型，教它学会特定任务的回答风格。
评测视角：SFT 后重点评「风格对了没、有没有学出新毛病」，02A 模块 3 翻过人话。
产品视角：产品要的「语气、格式」主要靠 SFT 定型，验收看风格达标没。
RLHF 基于人类反馈的强化学习
一句话：用人对回答的好恶打分，把模型往「让人满意」的方向推。
评测视角：RLHF 后容易「对齐过头」：该答的不答、变套路话。要加拒答率、刻板度指标。
产品视角：模型太安全可能变「躺平」，产品的体验边界要在 RLHF 前定义清楚。
对齐 Alignment
一句话：让模型的行为符合人类期望和价值观，RLHF 是对齐的一种手段。
评测视角：对齐质量要评「安全且不躺平」的平衡，单纯压安全会伤可用性。
产品视角：产品要在「可控」和「好用」之间拍板，对齐强度是产品决策。
指令微调 Instruction Tuning
一句话：用「指令 - 回答」格式数据训练，让模型更听得懂人话指令。
评测视角：评测要覆盖指令遵循度，尤其是复杂、多约束指令有没有全做到。
产品视角：用户用自然语言下指令的体验上限，卡在这层。
涌现能力 Emergence
一句话：模型大到一定程度，突然会了小模型不会的本事，不是线性长出来的。
评测视角：小模型测不出的能力，大模型可能突然有；评测集要随模型规模升级加难度。
产品视角：别拿小模型表现推断大模型，能力跃迁会让老方案失效。
2.3 检索与增强（RAG）
RAG 检索增强生成
一句话：让模型答题前先去查资料库再开口，等于配了本可以翻的参考书。
评测视角：幻觉检测分两步，先查「检索对不对」，再查「生成有没有脱离检索结果」，02A 模块 3 翻过。
产品视角：RAG 上线，产品要判断哪些场景该上、响应速度的代价值不值。
向量数据库
一句话：存 embeddings 的数据库，专门支撑「按语义找相似内容」的检索。
评测视角：RAG 评测要单独测检索召回率，向量库质量直接决定豆包知不知道正确答案在哪。
产品视角：知识库类产品的检索体验，底层卡在向量库的选型和索引。
检索召回率 Recall
一句话：该找出的相关片段，实际找出了多少，衡量检索漏没漏。
评测视角：RAG 评测的第一道闸，召回低后面全白搭；要构造「答案藏在长文档某段」的 case。
产品视角：用户问「你刚才说的那点」答不上来，多半是召回漏了，是产品体验硬伤。
2.4 Agent 与工具
Agent 智能体
一句话：能自己定计划、调工具、多步完成任务的模型应用，不是一问一答。
评测视角：评测从「单轮答对」升级到「多步任务完成率」，要记录 plan→action→observation 轨迹。
产品视角：产品上 Agent 是「能干活的助手」，验收看任务真做完没，不是看聊得开心不。
工具调用 Tool Use / Function Calling
一句话：模型能调用外部函数（查天气、下单、跑代码），把能力伸到模型外。
评测视角：要测调用对不对、参数填对没、失败有没有兜底；对应 taxonomy 的 Agent 编排能力。
产品视角：产品能接哪些工具、接错怎么办，是产品边界设计的核心。
ReAct 推理 + 行动
一句话：一种让模型「先想一步、再做一步、看结果再想」的框架。
评测视角：评测要判「思考链和动作是否对齐」，别出现想的是 A 调的却是 B。
产品视角：理解 Agent 的工作方式，才能设合理的用户等待和进度展示。
规划 Planning
一句话：Agent 把大任务拆成可执行的步骤序列的能力。
评测视角：评测看计划合不合理、卡住会不会重规划，对应 02A 模块 5 的 harness 设计。
产品视角：复杂任务的产品流程，往往就是 Agent 的规划在人类侧的映射。
多步编排
一句话：把多个模型调用、工具调用串成一条流水线协同完成目标。
评测视角：评测要覆盖步骤间状态传递、中途失败的整体兜底，是最重的 harness 场景。
产品视角：产品上一个复杂功能背后常是多步编排，哪步挂了用户都感知得到。
2.5 多模态与生成
多模态 Multimodal
一句话：模型能同时处理文字、图、声音等多种信息，而不是只认文字。
评测视角：多了一个「跨模态一致性」指标，图里有的内容文本输出里得有，对应 taxonomy ③。
产品视角：图文、音文混合的产品体验，卡在跨模态对不对得上。
VLM 视觉语言模型
一句话：能看懂图还能聊图的模型，多模态理解的主力。
评测视角：评测用 VQA（看图问答）、图表理解、OCR 渲染检查，参考 MMBench / ChartQA。
产品视角：图片理解类功能（识图、拍题）的体验上限在这层。
ASR 语音识别
一句话：把人说的话转成文字，语音交互的第一道关。
评测视角：用 WER（词错率）衡量，对应 taxonomy ②语音交互；要测嘈杂环境、口音、断句。
产品视角：语音产品「听不准」是头号差评源，ASR 准了后面才谈得上。
TTS 语音合成
一句话：把文字变成人声播出来，语音交互的最后一环。
评测视角：用 MOS（听感评分）衡量自然度，要测断句、停顿、情绪是否诡异。
产品视角：合成音「像不像人、烦不烦」直接决定语音产品的高级感。
文生图 / 文生视频（Seedream / Seedance）
一句话：豆包的 AIGC 生成能力，给文字提示词产出图或视频。
评测视角：评「提示词遵循 + 跨模态一致性 + 安全合规」，对应 taxonomy ⑤，生成和理解评法相反。
产品视角：产品要定「什么算好图 / 好片」，审美和安全红线都是产品决策。
跨模态一致性
一句话：图里写的和文字说的内容对不对得上，多模态专属指标。
评测视角：图文不对应、视频里文字乱码，都要判失败；是生成类评测的硬指标。
产品视角：用户最不能忍「图和说的不一样」，这是多模态产品的信任底线。
2.6 评测专项
LLM-as-Judge
一句话：拿一个 LLM 当评委，按 rubric 给另一个模型的回答打分。
评测视角：02A 模块 2 讲过，judge 有 position / verbosity bias，得分要人工抽检兜底、算一致性。
产品视角：产品上可用 judge 做大规模体验初筛，但别拿它当最终结论。
幻觉 Hallucination
一句话：模型一本正经地编瞎话，事实、引用、张冠李戴都算。
评测视角：分事实性 / 忠实性 / 逻辑性三类测，参考 HaluEval / FaithEval / Ragas。
产品视角：幻觉是产品信任杀手，产品要定义「哪些场景零容忍」。
基准 Benchmark
一句话：业界通用的「体检表」，用固定考题测模型某方面能力。
评测视角：基准分是准入证不是合格证，饱和和泄露要警惕，下篇 04 专门讲怎么读。
产品视角：别拿高分当「能上线」，用户满意度和基准分不是一回事。
评测集污染 Contamination
一句话：评测题被悄悄混进了训练数据，模型「背过答案」导致虚高。
评测视角：要测 n-gram 重叠、做成员推断检测，否则分数不可信。
产品视角：产品验收别只看内部高分，要怀疑「是不是见过题」。
数据飞轮 Data Flywheel
一句话：线上 badcase 捞回来进评测集，模型优化后再上线，循环转起来。
评测视角：评测集从线上来、到评测里去，对应 02A 模块 4，是可持续评测的核心。
产品视角：你是飞轮最好的推动者，离用户最近、最知道痛点在哪。
红队 Red Teaming
一句话：专门有人扮演攻击者，想办法诱模型出岔子、越红线。
评测视角：红蓝对抗最能暴露真问题，对应 01 篇的产品质量红线，漏过率一票否决。
产品视角：安全是产品的发布闸门，红队发现的问题产品必须接住。
三、几个最容易踩的误读
表看完了，最后说几个我身边人真踩过的坑，都是把术语理解偏了导致评测或需求跑偏。
误读 1：把温度当质量旋钮。 有人觉得「温度调低点模型就更准」。不对，温度只控随机性，质量靠模型本身。它真正的作用是：评测生成任务时必须锁死，否则同一题两次分不同，你分不清是模型差还是参数飘。把温度当质量调，只会把评测搅乱。我见过有人评豆包写文案，温度没锁，同一 brief 跑两遍分数差 8 分，最后归因到参数没锁而不是模型问题，白折腾两天。
误读 2：以为上了 RAG 就不幻觉。 RAG 只解决「模型没知识」这一种幻觉（检索不到才编），解决不了「有知识但编答案」（检索到了却脱离结果瞎说）。所以幻觉检测必须分两步，上面 RAG 那条写了。我踩过：豆包接了知识库后，团队把幻觉评测撤了，结果用户问「你刚才引用的那篇说啥」，模型张冠李戴照样编，因为检索到了但生成没贴住。召回对了不等于不幻觉。这条最该记牢，它是原则 2「变化触发更新」的反面教材：你以为加了 RAG 风险少了，其实风险换了个地方冒头。
误读 3：以为微调只会加能力不会减。 微调可能灾难性遗忘，通用能力悄悄掉。评测必须做微调前后对比，通用维度复测一遍。产品上同理，加了个新技能别以为老的都还在。
误读 4：把 Benchmark 高分当能交付。 这个 02A 提过、下篇 04 展开。这里先点一句：基准分是「考试分数」不是「实际能不能用」，高于平均不等于可以发，低于平均一定不能发。
误读 5：以为懂原理等于能提任意需求。 不懂边界最容易提「让豆包永远不出错」「200 页 PDF 一字不差记住」这类做不到的需求。我见过产品同学提「让豆包把这份 200 页合同一字不差记住并随时精确引用」，算法团队当场傻眼：上下文窗口和检索精度都卡着，硬提就是埋雷。懂一点原理，是为了提得出好需求、拍得下合理板，不是把自己变成算法。这也回到开头那句：你是用户的嘴替、手替，但你得比产品经理更早发现「这个需求本身就建在流沙上」。
误读 6：把 Embedding 当黑盒不测。 RAG 和语义判分都靠向量质量，向量一歪，召回和判分跟着歪。评测要单独校一遍 embedding 在你们业务语料上的相似度准不准，别默认厂商给的就是对的。
误读 7：以为 Agent 评测等于单轮评测。 Agent 是多步的，单轮答对不代表任务完成。有人拿「每个子问题答对率」当 Agent 分数，结果整体任务跑飞了还显示高分。要评「端到端任务完成率」，记录完整轨迹，别被局部准确率骗了。这条对应工具调用、规划、多步编排那几条，是 Agent 评测和单轮对话评测最本质的分水岭。
误读 8：以为术语是评测岗的事，产品不用管。 02B 说过，产品是「定义什么算好」的人，不懂 RAG / Agent 这些，你定义的标准就会飘。最典型的，产品提「要准确」却不说是「检索准确」还是「生成准确」，评测接不住。开头我说评测对产品的理解要贴近甚至高于产品经理，这条误读就是那个意思的反面：产品自己不跨这一步，最后接不住的是整条价值链路。
误读 9：以为上下文窗口大就等于能记住一切。 窗口是「一次能看到的长度」，不是「长期记忆」。即便窗口有 50k token，关键信息若被后续大量文本冲淡、或压在长文 45k 处而后续又堆了无关内容，模型仍可能漏掉。评测不能只看「超没超窗口」，要专门造「关键信息远离当前焦点」的 case，看注意力有没有漂走。
误读 10：以为 temperature=0 就 deterministic 安全。 零温度确实更稳，但不是可复现的保证：不同推理框架、批处理并行、硬件浮点微差都可能让同输入产出略不同。评测不能假设「零温度 = 两次结果一致」，要实测复现率，把波动记进不确定区间，否则把框架噪声当模型方差。
误读 11：以为 few-shot 能补一切。 示例能提升表现，但有上限，且和 prompt 模板强耦合。评测要把 shot 数版本化：0-shot / 3-shot / 5-shot 分别测，才知道某能力是模型自带还是靠示例喂出来的。否则上线换了个 prompt 模板，原本靠 few-shot 撑住的能力塌了你还不知道为什么。
误读 12：以为评测集大就等于结论准。 量大不等于维度覆盖全。稀疏的 badcase（比如长文档后半段忠实性、跨模态一致性）漏检，比量多但维度单一的评测更危险。正确做法是数据飞轮持续补真实 badcase，而非单纯堆量刷覆盖率。这条和原则 2「变化触发更新」呼应：模型一升级，老维度可能失效，新维度得靠线上 badcase 喂出来。
四、端到端推演：把一条 JD 反推成完整评测方案
前面说「用术语反推评测维度」，这句太抽象，拿 02A 模块 1 那条真实 JD 走一遍，你就知道反推长什么样。
JD 原文意图（脱敏）：用户把一份长文档丢给豆包，追问里面的细节，要求前后回答一致、引用可查。
反推术语依赖：上下文窗口（能不能看到全篇）、RAG（细节从哪来）、幻觉（引的对不对）。
反推评测维度，我当时列了五根柱子：
- 超长截断丢信息：指标 = 后半段约束命中率；判法 = 造 2 万字文档问答对，把关键事实故意放前半和放后半各一批对照，跑豆包看后半有没有丢；数据来源 = 自建长文档集；红线 = 后半命中跌超 5% 就告警。
- 检索召回：指标 = Recall@k；判法 = 答案藏在长文档某段，构造「答案在段 17」这类 case；数据来源 = 向量库检索日志；红线 = 召回低于 0.9 整条链路重测。
- 引用准确：指标 = 引用命中率；判法 = 让豆包标出引用出处，人工抽检 100 条；数据来源 = 标注；红线 = 张冠李戴零容忍。
- 忠实性幻觉：指标 = FaithEval 类忠实度分；判法 = 专门造「检索到了但生成脱离」的对抗 case；数据来源 = Ragas；红线 = 脱离型幻觉一票否决。
- 跨段一致性：指标 = 同一事实前后一致率；判法 = 同一文档用不同措辞问两遍，比对答案；数据来源 = 数据飞轮 badcase。
落到 02A 模块 5 的 harness 四件套：采集 = 长文档问答对、执行 = 豆包 API、判定 = LLM-as-Judge + 人工抽检、报告 = 五维仪表盘。
收尾：一条 JD 短语，反推出 5 维 + 指标 + judge + 红线 + harness。这就是「反推」的成品，比背 36 个词值钱十倍。下次再看到 JD 里任何词，你就照这个模板套：术语 → 反推哪几维 → 每维给指标和红线 → 落到 harness。
五、业界怎么做的（最佳实践印证）
咱们这套「术语 → 评测维度」的笨办法，不是拍脑袋。国外评测实践早就在做类似的事，对齐一下你心里更踏实。
Stanford CRFM 的 HELM（crfm.stanford.edu/helm）核心哲学是「多维度整体评测」，不靠单一分数，而是把每个模型能力拆成场景加指标矩阵。这和咱们「反推维度」一个思路，区别只在他拆的是学术基准、我们拆的是 JD。
Allen Institute for AI（AI2）的 OLMo 开源模型配套 OLMES 评测方法论，主张评测方法本身要开源、可复现，直接呼应咱们「评测集从线上来、到评测里去」的数据飞轮，飞轮本质就是让评测方法长在自己业务上、可复现可迭代。
OpenAI 和 Anthropic 公开的 evals 文档，都强调「先定义什么算好（rubric），再评」。这和咱们开头说的「产品定义什么算好、评测证明交付了没」完全同构，他们是通用模型、我们是豆包具体产品，方法底层一致。
落到「怎么验证 judge 自己靠谱」，业界已有成熟做法。MT-Bench（Zheng et al. 2023, LMSYS）用强模型当裁判的同时，拿人类标注做校准：把 LLM 打分和人类偏好对一遍，算一致性（ICC / 相关系数），低于阈值就说明这个 judge 不可信、得换。这正好呼应术语表里 LLM-as-Judge 那条，你用豆包当裁判时，第一步不是写 prompt，而是先拿一小批人工标好的 case 验 judge 的吻合度。
评 RAG 也有现成框架。Ragas 和 DeepEval 把「检索召回率 + 引用准确性 + 答案忠实度」拆成可量化指标，直接对接你反推出来的「检索召回 + 引用准确」两项，不用自己从零造。HELM 的场景 × 指标矩阵再展开看：它不报「模型总分」，而是每个场景（摘要、问答、偏见）配一组指标，你能横向比「豆包在问答场景的引用准确」和「头部在问答场景的引用准确」，这正是咱们反推维度要的东西。
鲁棒性也有对标。微软的 PromptBench 专门测「prompt 被轻微扰动（同义改写、拼写噪声、掉字）后模型还稳不稳」，直接对应你第三节造对抗 case 的思路，区别在它把扰动标准化成基准，你能借它的扰动集当你的 case 种子库，省得每次从零想怎么折腾模型。
所以你学的不是野路子，是和头部对齐的方法。差异只在落点：他们面向通用能力榜单，我们面向用户价值链路。知道这一点，你反推出来的评测维度，底气更足。
六、新人怎么拿这份表上手
说了怎么用、给了表、点了坑、走了推演，最后给个最省力的上手路径，照着走一遍就通。
第一步，把 02A 那张 5 模块能力地图打开，对照本表的术语，标出「已有 / 半有 / 需新学」。比如 Token、Prompt 你大概率已有；RAG、Agent、LLM-as-Judge 多半需新学。
第二步，挑三个你最该补的术语（一般就是 RAG、Agent、LLM-as-Judge），每个只学到「评测视角」那一行，不动算法推导。
第三步，拿一个豆包真实场景练：比如评「豆包长文档问答一致性」，你会自然用到上下文窗口、RAG、幻觉这三个术语的评测视角。用一次，比背十遍表管用。这一步和第四节的端到端推演对上，练的就是那条反推模板。
走完这三步，这份表就从字典变成了你手里的工具。后面系列分能力讲评测时，你随时回这张表查术语，不会卡壳。
掌握程度三档自检（你处在哪层）
- 层 1 背定义：能说出「RAG 是检索增强生成」。最浅，对干活几乎没用。
- 层 2 懂评测视角：看到 RAG 能反推出「检索召回 + 引用准确」两项指标，能造一个对抗 case。合格线。
- 层 3 懂产品视角且能定边界：除层 2 外，还能告诉产品「哪些场景该上 RAG、响应速度代价值不值」，能定义红线。优秀，贴近甚至高于产品经理。
你是评测转岗，目标至少层 2、冲层 3；你是产品转岗，层 2 够用、层 3 是加分。
两份入门清单（30 秒自检）
评测岗最低门槛，五问能答「能」即入门：①看到 RAG 能反推检索召回 + 引用准确两项指标吗；②看到 Agent 能列出多步完成率 + 轨迹记录吗；③能为一个术语造一个对抗 case 吗；④能说清温度 / Top-p 为什么要锁吗；⑤能定义一条红线吗。
产品转评测最低门槛，五问能答「能」即入门：①提需求时能区分「检索准确」和「生成准确」吗；②能说清哪些场景幻觉零容忍吗；③知道上下文窗口上限意味着什么产品兜底吗；④能定义「什么算好图 / 好片」吗；⑤懂 RAG 后知道哪些场景该上吗。
7 天微计划：Day1 Token / Prompt；Day2 上下文窗口 / 注意力；Day3 RAG / 召回 / 幻觉；Day4 SFT / RLHF / 对齐；Day5 Agent / 工具调用 / ReAct；Day6 LLM-as-Judge / 红队；Day7 拿一个真实场景端到端走一遍（呼应第四节推演）。一天一个术语加一个 case，周末就能建立那个反射。
参考与延伸
评测与术语相关基准 / 框架（文中引用）
- 对话与语义判分：MT-Bench（Zheng et al., 2023）、AlpacaEval、LLM-as-Judge 及校准研究
- 多模态：MMBench、MME、ChartQA、DocVQA、TextVQA
- 幻觉：HaluEval、FaithEval、Ragas
- Agent：AgentBench、WebArena、τ-bench、ToolBench
- 鲁棒性：微软 PromptBench（prompt 扰动鲁棒性评测，正文第五节引用）
- 语音：WER（词错率标准）、MOS（ITU-T P.800 听感评分）、DNSMOS
- 评测框架：HELM、OpenCompass、LM Eval Harness、DeepEval、Ragas
基准与方法的机构出处（按需查证，非必查）
写「某个基准的来龙去脉 / 评测方法论溯源」时优先查，与附注一（论文）互补（附注一给单篇论文，这里给机构持续输出）。下列为文中涉及基准的发源地，引用时优先回溯：
- MMLU：UT Austin（Dan Hendrycks 组），论文 arXiv:2009.03300，是「大模型知识体检」最广用的基准之一。
- HELM：Stanford CRFM（Holistic Evaluation of Language Models），crfm.stanford.edu/helm，强调「多维度整体评测」而非单分。
- WildBench / OLMo / OLMES / Tulu 系列：Allen Institute for AI（AI2），开源模型与评测方法的主力，评测集污染相关研究多出自此处。
- Agent 可靠性评测（RE-Bench 等）：METR（原 ARC），做 agent 评测专项时必看，专攻「模型自主任务可靠性」。
- Agent 评测框架核心源头：AgentBench 由清华大学 THUDM（CoAI 组）主导，WebArena 与 τ-bench 由普林斯顿（Shunyu Yao 等）主导，ToolBench 由浙大等机构主导，都是该方向的代表基准。
- 大学实验室群：UC Berkeley BAIR、MIT CSAIL、University of Washington、Princeton NLP 等持续产出评测方法论文，方法篇溯源时优先扫。
- 大型公司研究院（非产品厂商官方）：Microsoft Research、NVIDIA Research、Meta AI / FAIR、Apple ML Research、Amazon Science、IBM Research，其公开技术报告是工程侧评测实践的补充信源。
前文衔接
- 02A 从算法评测 JD 拆 5 模块能力地图（模块 3 已翻 RAG / SFT / RLHF 人话，模块 2 讲 LLM-as-Judge，模块 5 讲 harness 四件套）
- 02B 从产品 JD 拆另一半地图（模块 4 讲产品视角的技术理解落点）
- 01 篇产品质量红线、五大能力 taxonomy、评测纪律红线
豆包公开能力（截至 2026.07，以官方最新口径为准）
- 文本对话、语音交互（ASR / TTS）、多模态理解（VLM）、Agent 编排、AIGC 生成（文生图 Seedream / 文生视频 Seedance / 音频 Seed-Audio）
- 具体版本号与 DAU 以豆包官网、火山引擎发布会公开信息为准
下篇预告
这篇把 JD 里的术语拆成了评测 / 产品视角的速查表，核心就一句：不用懂推导，只要懂「它变了你的方案改什么」。但术语懂了，还有个绕不开的问题：业界那些基准分数到底怎么读。下篇讲豆包在标准评测基准上的表现怎么看，MMLU、GSM8K、HumanEval 这些报告，教你建立「基准分 → 发布决策」之间的正确距离感，避免「分数高就敢发」的坑。
作者注：本系列是一边工作、一边实操、一边琢磨着写出来的，规划约 100 篇，内容和篇幅会随实际调整；为保证文章质量，不追求固定的更新频率。以上内容基于脱敏内部信息、公开权威资料和自己踩坑后的理解，不一定对，欢迎拍砖。