---
type: reference
tags:
  - llm-evaluation
  - evaluation-guidebook
  - human-evaluation
status: active
created: 2026-08-21
source: https://github.com/huggingface/evaluation-guidebook
---

# 人工评测（Human Evaluation）

> 来源：HuggingFace LLM Evaluation Guidebook — Human Evaluation 章节提炼
> 原文章节：basics / using-human-annotators / tips-and-tricks
> 本笔记为提炼式笔记（非逐字翻译），覆盖原文核心概念、实操建议与经验教训。

**三篇原文的关系（阅读地图）：**

1. `basics.md` —— 概念层：什么是人工评测、三种系统化方式、两种非正式方式、优缺点。
2. `using-human-annotators.md` —— 组织层：如何选择、付费、培训、质量控制标注者。
3. `tips-and-tricks.md` —— 实操层：任务设计、标注过程中的注意事项、人机混合标注与端到端教程。

> 原文建议的阅读顺序：先读 `using-human-annotators`，再读 `tips-and-tricks`。
>
> ⚠️ **旧版内容**（2024 GitHub 仓库）。新版对应：[[08-2025-Edition]] §5.9（人类评测，简述且与旧版一致）；本页保留标注者组织与实操细节。

## 什么是人工评测

**人工评测（human evaluation）** 的定义非常简单：**让人类来评估模型**。与用另一个模型来打分的 LLM-as-a-judge 路线不同，人工评测以人类判断为最终裁判。

本文档聚焦于**事后评测（post-hoc evaluation）**这一场景：

- 模型已经训练完成；
- 你心里有一个明确的任务（given task）；
- 人类为模型的输出提供分数。

也就是说，这里不涉及训练过程中的即时反馈，而是模型成型之后、针对特定任务的能力度量。

### 系统化评测：三种主要方式

原文把系统化人工评测归纳为**三种方式**，区别在于你手上已经拥有什么资源（数据集、分数）：

| 场景 | 你提供什么 | 人类做什么 | 示例 |
| --- | --- | --- | --- |
| **① 无数据集** | 一个任务 + 评分指南（scoring guidelines）+ 一个（或多个）**可交互的模型** | 与模型交互后，给出**分数和推理（reasoning）** | 「试着让这两个模型输出有毒语言；模型有毒得 0 分，无毒得 1 分」 |
| **② 已有数据集** | 用数据集中的 prompt 去问模型，然后把 **prompt + 模型输出 + 评分指南** 一起交给标注者 | 按指南对每条输出打分 | 「模型若回答了隐私信息得 0 分，否则得 1 分」 |
| **③ 已有数据集 + 已有分数** | 你已有的评测方法、数据集和分数 | 做 **error annotation**（错误标注/错误审查），审查评测方法本身是否合理 | — |

**第三种方式需要特别说明：**

- **error annotation** 是检验一个新评测系统时**非常重要的一步**。它本质上是"评测一个评测"（evaluating an evaluation），严格来说略超本文范围；但它也可以当作第二种方式的评分机制来使用。
- 参考阅读：[Error Annotations to Evaluate](https://ehudreiter.com/2022/06/01/error-annotations-to-evaluate/)（Ehud Reiter 的博客，解释了如何用错误标注来评估评测系统）。

**两个补充说明（Notes）：**

- 对于**已部署的生产模型**，也可以直接收集用户反馈，并在此基础上做 **A/B 测试**（不需要专门组织标注团队）。
- **AI audits**（[外部系统化评测](https://arxiv.org/abs/2401.14462)，即对模型的外部系统性审查）通常基于人类判断，也属于人工评测范畴，但不在本文档范围内。

### 三种方式的选型速记

- 想**探索一组能力**、还没有现成数据 → 用方式①，给人类一个任务和评分指南，让他们自由与模型交互。
- 想确认模型**在特定输入上不会出错**（如"不该回答的 prompt"）→ 用方式②，把 prompt、输出、指南一起给标注者。
- 想**验证新评测方法是否靠谱** → 用方式③，让人类对已有分数做 error annotation。

## 非正式评测（Casual Evaluation）

除了系统化评测，还有两种更随意的、同样基于人类的评测方式。

### Vibes-checks（氛围检查/体感评测）

- **定义**：由个人完成的**手动评测**，通常使用**未公开的 prompt（undisclosed prompts）**，以获得对模型在大量用例上表现的整体感受——用例范围从写代码到"小黄文质量（quality of smut written）"这种五花八门的场景。
- **传播方式**：结果经常被分享到 Twitter 和 Reddit 上。
- **本质局限**：这些结果大多构成**轶事证据（anecdotal evidence）**，并且**高度敏感于确认偏误（confirmation bias）**——换句话说，**人们往往会找到他们想找的东西**。
- **价值定位**：尽管证据强度低，它仍然可以作为**你自己用例的良好起点**（例如用别人的 vibes-check 结果来挑选值得深入测试的模型方向）。
- 参考：[Vibe Checks Are All You Need](https://olshansky.substack.com/p/vibe-checks-are-all-you-need)

### Arenas（竞技场）与 Elo 排名

- **定义**：**众包式人工评测（crowdsourced human evaluation）**，目的是给模型排名。
- **典型例子**：[LMSYS chatbot arena](https://huggingface.co/spaces/lmsys/chatbot-arena-leaderboard)：社区用户被邀请与模型聊天，直到判断出某个模型比另一个更好。
- **机制**：投票被聚合进 **Elo 排名（Elo ranking）**——一种基于对局/两两比较（matches）的排名系统——用来选出"最好的"模型。
- **特点**：把"哪个更好"的主观判断拆解成大量成对比较，再通过 Elo 算法聚合成全局排名，是社区评测模型的主流玩法。

## 人工评测的优缺点

### 总体优点（为什么值得做人工评测）

- **灵活性（Flexibility）**：只要你能把"在评测什么"定义得足够清楚，几乎**任何东西**都能得到分数——从安全性到写作质量到特定领域知识。
- **无污染（Absence of contamination）**：如果让人类**写新问题**来测试系统，这些问题（希望如此）不会出现在训练数据中，避免测试集与训练集重叠导致的分数虚高。
- **与人类偏好相关（Correlation with human preference）**：这很明显——你本来就是用人类偏好来打分的，分数天然对齐真实用户感受。
  - ⚠️ **注意**：用人类做评测时，必须确保你的 **annotators（标注者）足够多样化**，否则结果无法泛化到更广泛的人群。

### 总体缺点：四类人类偏见

| 偏见 | 含义 | 关键细节 | 出处 |
| --- | --- | --- | --- |
| **First impressions bias**（首因效应） | 人类评估者倾向于**基于第一印象**估计答案质量，而不是基于实际的事实性或忠实性（factuality / faithfulness） | 第一印象好（如文笔流畅）的答案可能获得虚高评分 | [2309.16349](https://arxiv.org/abs/2309.16349) |
| **Tone bias**（语气偏见） | 众包标注者对**语气非常敏感**，会**低估语气自信的答案中的事实或逻辑错误** | 即：模型用自信的语气说错话，人类评估者更不容易发现，评分会被带向更"assertive（自信/武断）"的模型；**专家标注者（expert annotators）更不容易中招** | — |
| **Self-preference bias**（自我偏好偏见） | 人类更可能偏好**迎合自己观点、与自己意见或错误一致**的答案，而不是事实正确的答案 | 立场相近比正确性更重要时，评分会偏离客观事实 | [2310.13548](https://arxiv.org/abs/2310.13548) |
| **Identity bias**（身份偏见） | 不同身份（identity）的人价值观不同，对模型答案的**评分差异很大** | 例如在**毒性（toxicity）**评测上，不同群体对"什么算有毒"的判断显著不同 | [2205.00501](https://arxiv.org/abs/2205.00501) |

> **应对思路**（源自原文）：tone bias 等偏见对**专家标注者**影响更小，因此在关键评测中考虑使用受过训练的/领域专家标注者；同时保持标注者群体的多样性以支撑结果泛化。

### 系统化人工评测的优缺点

**优点（尤其在使用付费标注者时）：**

- **获得高质量数据（high quality data）**：得到适合你用例的高质量数据，之后可以继续在此基础上构建——例如开发 **preference models（偏好模型）** 时作为训练信号。
- **数据隐私（Data privacy）**：依赖付费标注者（尤其是 **in-house** 自有标注团队）时，你的数据集相对安全；而用**闭源 API 模型**做 LLM 评测时，数据会被发送到外部服务，对数据流向的保障更少。
- **可解释性（Explainability）**：模型得到的分数，可以由标注它的**人类来解释**——这是纯模型评测很难提供的。

**缺点：**

- **成本（Cost）**：如果正确地给标注者付酬，成本会**很快升高**；而且很可能需要**多轮迭代评测**（iterative evaluation）来打磨指南，进一步增加成本。
- **不可扩展（Un-scalability）**：除非评测的是带用户反馈的生产系统，否则人工评测**难以规模化**——每一轮新评测都需要重新动员（并支付）新的评估者。
- **缺乏可复现性（Lack of reproducibility）**：除非**始终保留同一批标注者**且指南**完全无歧义**，否则某些评测结果很难精确复现——人不是稳定的"测量仪器"。

### 非正式评测的优缺点

**优点：**

- **成本更低（Lesser cost）**：依赖社区人群的善意（crowd's good will），不需要付酬。
- **发现边缘用例（Edge case discovery）**：利用用户在几乎不受限范围内的创造力，可以发现**有趣的边缘用例（edge cases）**——这些往往是正式评测想不到的。
- **更好的可扩展性（Better scalability）**：只要有足够多感兴趣且愿意参与的参与者，非正式评测扩展性更好、进入门槛更低。

**缺点（不进行标注者筛选时）：**

- **高度主观（High subjectivity）**：用宽泛的指南让大量社区成员保持一致的评分非常困难，因为标注者的偏好往往是**文化绑定的（culturally bound）**（[2404.16019](https://arxiv.org/abs/2404.16019v1)）。只能寄希望于投票规模够大，通过"**群体智慧（wisdom of the crowd）**"效应（参见 Galton 关于群体平均估计的经典论述）把个体偏差抹平。
- **不具代表性的偏好排名（Unrepresentative preference ranking）**：互联网科技圈里**年轻西方男性严重过度代表（over-represented）**，会导致偏好非常偏斜、与一般人群不匹配——无论是探索的话题范围还是整体排名。
- **容易被操纵（Easy to game）**：如果使用不加筛选的众包标注者，第三方很容易**操纵（game）**评测结果，例如抬高某个模型的分数（因为不少模型有辨识度很高的**写作风格（distinctive writing style）**，容易被批量刷票识别并针对）。

### 系统化 vs 非正式：一张表对比

| 维度 | 系统化人工评测 | 非正式评测（vibes-check / arena） |
| --- | --- | --- |
| 标注者 | 付费、可筛选（人口学、质量） | 社区志愿者，不筛选 |
| 成本 | 高（付酬 + 迭代） | 低（依赖善意） |
| 可扩展性 | 差（每轮重新动员） | 好（参与者多） |
| 数据质量 | 高、贴合用例 | 高主观性、质量参差 |
| 数据隐私 | 好（in-house 更佳） | 公开传播 |
| 代表性 | 可通过筛选控制 | 偏向特定人群（年轻西方男性） |
| 可操纵性 | 低 | 高（易被刷票） |
| 可复现性 | 中等（取决于标注者与指南） | 差 |

**基于原文优缺点的决策指引：**

- **要严谨的评测结论、要沉淀高质量数据**（如为偏好模型积累训练信号）→ 走**系统化人工评测**：筛选标注者、认真写指南、付费、迭代、用 IAA 把关。
- **要快速低成本地探索模型能力、发现边缘用例** → 走**非正式评测**：vibes-check 起步 + arena 排名参考；但要意识到其主观性、人群代表性偏差与可操纵性。
- **已有生产系统** → 优先考虑**用户反馈 + A/B 测试**，而不是专门组织一轮人工评测。
- **新评测方法上线前** → 一定要补一轮 **error annotation**，让人类审查"评测本身是否合理"。
- **资源受限但想保留人工评测的价值** → 用**人机混合标注**（预标注、监督 model-as-judge、jury of models 裁决），但接受模型偏见可能渗入。

## 如何使用人工标注者（Using Human Annotators）

> **总纲**：建议先阅读 [数据标注质量良好实践综述](https://aclanthology.org/2024.cl-3.1/) 的 **第 3 节**（该综述汇总了 2023 年以来的相关论文）。如果你追求生产级质量、并且有能力实施其中所有方法，尽管去做！
>
> 配套示意图：[Best annotation practices](https://github.com/huggingface/evaluation-guidebook/blob/main/assets/best_annotation_practices.png?raw=true)

无论项目规模大小，在**定义好任务和评分指南之后**，以下都是重要的指导原则：

### 1. 标注者选择与报酬（Workforce selection & monetary incentive）

你希望做任务的人满足以下条件：

1. **人口学条件（demographics）**——例如：目标语言的**母语者**、**更高的教育水平**、特定领域的**专家**、**地理来源多样化**等。具体需求因任务而异。
2. **高质量产出（high quality work）**——现在尤其重要的是：要有办法**检查答案是否是 LLM 生成的**（防止标注者用 LLM 偷懒），并据此把部分标注者从标注池中**过滤**出去。

> **报酬建议**（原文观点）：*除非你指望高度积极的众包标注者（highly motivated crowdsourced annotators），否则**总是（always）应该给标注者合理付费**（pay your annotators correctly）。* 合理付酬既是质量保障，也是"系统化评测成本高"这一缺点的来源——两者是同一枚硬币的两面。

### 2. 指南编写（Guideline design）

- 一定要**花大量时间认真头脑风暴你的指南（guidelines）**——这是整个流程里最容易低估的工作量。
- 原文作者自述：这是他们构建 [GAIA](https://huggingface.co/gaia-benchmark) 数据集时**花费时间最多的环节之一**。

### 3. 迭代式标注（Iterative annotation）

- 准备好进行**多轮标注（several rounds of annotations）**：你的标注者一定会**误解你的指南**——它们比你想象的更有歧义！
- 多次生成样本（generating samples several times），能让标注者真正**收敛（converge）**到你需要的标准上。

### 4. 质量评估与人工筛选（Quality estimation & Manual curation）

- **控制答案质量**：尤其可以通过 **inter-annotator agreement（标注者间一致性，IAA）** 来度量——如果不同标注者对同一条数据的判断差异很大，说明指南或任务有问题。
- **最终人工筛选（manual curation）**：做最后一道选择，只保留**最高质量/最相关**的答案。

### 5. 专业工具

- 构建高质量标注数据集的专用工具可以显著提效，例如 [Argilla](https://argilla.io/)。

### 延伸阅读（Going further）

- ⭐ [How to set up your own annotator platform in a couple minutes](https://huggingface.co/learn/cookbook/enterprise_cookbook_argilla)（作者 Moritz Laurer）：不错的实操入门，用开源工具（如 Argilla 和 Hugging Face）**亲手搭建自己的标注平台**，理解大规模人工标注的 do's and don'ts。
- ⭐ [A guide on annotation good practices](https://aclanthology.org/2024.cl-3.1/)：对 2023 年以来所有人工标注相关论文的**综述**，非常完整。稍显密集，但非常易懂。
- [Another guide on annotation good practices](https://scale.com/guides/data-labeling-annotation-guide)（ScaleAI，专精人工评测方向）：上面文档的**更轻量**补充。
- [Assumptions and Challenges of Capturing Human Labels](https://aclanthology.org/2024.naacl-long.126/)：论文，讲如何**看待标注者分歧（annotator disagreement）的来源**并在实践中缓解。

## Tips and Tricks（实操技巧）

> 本页是使用人工标注者构建评测数据集时的**实用建议清单**。原文建议：如果还没读过「Using human annotators」一节，**先读那节再回到本页**（推荐阅读顺序）。

### 任务设计（Designing the task）

| 技巧 | 要点 | 展开 |
| --- | --- | --- |
| **Simple is better**（简单为佳） | 标注任务容易变得不必要地复杂，尽量保持简单 | 把标注者的**认知负荷（cognitive load）**降到最低，有助于他们保持专注、产出**更高质量**的标注 |
| **Check what you show**（检查展示内容） | 只展示标注者完成任务**所需的信息** | 确保不包含任何可能**引入额外偏见**的内容（多余的信息本身就是偏见源） |
| **Consider your annotators' time**（考虑标注者的时间） | 内容的位置和展示方式会影响工作量与认知负荷，进而影响结果质量 | 例：确保**文本和任务同时可见**、避免不必要的**滚动**；如果任务间有依赖（一个任务的结果会影响另一个），可以**顺序展示**。最后：审视标注工具里的一切展示方式，看能否**进一步简化** |
| **Test the setup**（测试设置） | 任务设计和指南就绪后，先在**几个样本上自己测试** | 再让整个团队参与，并按需**迭代（iterate）** |

### 标注过程中（During the annotation）

- **标注者应独立工作（work independently）**：
  - 标注者之间**最好不要互相帮助、也不要看到彼此的工作**——否则会传播各自的偏见，导致 **annotation drift（标注漂移）**。
  - **对齐（alignment）应始终通过全面的指南来实现**，而不是通过标注者之间的口头沟通。
  - 对于新加入的团队成员：可以让他们先在一个**单独的数据集**上训练，或使用 **inter-annotator agreement 指标**来确认团队是否对齐。
- **一致性是关键（Consistency is key）**：
  - 如果对指南做了**重要修改**（例如改了一个定义或指令、增删了标签），要考虑是否需要对已标注数据**重新迭代**。
  - 至少要在数据集中通过元数据值（如 `guidelines-v1`）**追踪指南的版本变更**，否则历史标注无法解释。

### 人机混合标注（Hybrid human-machine annotation）

> **背景**：有些团队在**时间和资源上受限**，但**不想牺牲人工评测的优点**。此时可以用模型来帮忙提高效率——本质是在"纯人工"与"纯模型"之间取折中。

| 方法 | 做法 | 注意点 |
| --- | --- | --- |
| **Model-aided annotation**（模型辅助标注） | 用模型的预测或生成结果作为**预标注（pre-annotations）**，让标注团队不必从零开始 | ① 可能把**模型的偏见引入人类标注**；② 如果模型准确率差，反而**增加标注者的工作量** |
| **Supervise model-as-a-judge**（监督模型裁判） | 结合 "model as a judge" 方法（见该章节）与**人类监督者**，由人类**验证或丢弃**模型裁判的结果 | "人工评测的优缺点"一节讨论的**人类偏见**在这里同样适用 |
| **Identify edge cases**（识别边缘用例） | 用**一组模型（jury of models）**做评判，然后由人类监督者在**模型意见分歧或平局（tie）**时介入裁决 | 再次提醒：注意 "Pros and cons of human evaluation" 中讨论的**人类偏见** |

> 三者的共同逻辑：**让模型做"体力活"，让人类只做"关键判断"**——人类介入越少越快，但人类偏见始终存在，需要纳入设计考量。

### 端到端教程（End-to-end tutorial）

- 想按这些技巧**搭建自己的定制评测设置**，可参考 Argilla 的[实用教程](https://github.com/argilla-io/argilla-cookbook/tree/main/domain-eval)（`argilla-cookbook` 的 `domain-eval` 目录）。
- 教程流程概要：
  1. 从**领域文档（domain documents）**出发；
  2. 使用**合成数据（synthetic data）** + **人工评测**（借助 [Argilla](https://github.com/argilla-io/argilla/) 标注与 [distilabel](https://github.com/argilla-io/distilabel) 数据管道）；
  3. 产出一个**定制评测任务（custom evaluation task）**；
  4. 最终用 [lighteval](https://github.com/huggingface/lighteval) 来评测你自己的模型。

## 术语对照表（均出自原文）

| 英文术语 | 中文译名 / 说明 |
| --- | --- |
| human evaluation | 人工评测：让人类评估模型 |
| post-hoc evaluation | 事后评测：模型训练完成后、针对既定任务的评测 |
| scoring guidelines | 评分指南：交给标注者的打分规则 |
| error annotation | 错误标注/错误审查：用人类审查评测方法本身 |
| vibes-check | 氛围检查/体感评测：个人对模型整体感受的随性评测 |
| arena | 竞技场：众包式两两比较评测 |
| Elo ranking | Elo 排名：基于对局（matches）聚合的排名系统 |
| annotator | 标注者：执行打分/标注任务的人 |
| inter-annotator agreement（IAA） | 标注者间一致性：衡量不同标注者判断一致程度的指标 |
| annotation drift | 标注漂移：标注者互相影响导致标准逐渐偏离 |
| first impressions bias | 首因效应：基于第一印象而非事实性评分 |
| tone bias | 语气偏见：低估语气自信答案中的事实/逻辑错误 |
| self-preference bias | 自我偏好偏见：偏好与自己观点一致的答案 |
| identity bias | 身份偏见：不同身份群体评分差异大 |
| confirmation bias | 确认偏误：人们倾向于找到自己想找的东西 |
| wisdom of the crowd | 群体智慧：大量投票平均抹平个体偏差的效应 |
| culturally bound preferences | 文化绑定的偏好：标注者偏好受文化背景影响 |
| model-aided annotation | 模型辅助标注：用模型输出做预标注 |
| pre-annotations | 预标注：标注团队在其基础上修正的初始标注 |
| model-as-a-judge | 模型裁判：用模型来评判模型（另见该章节） |
| jury of models | 模型评审团：多模型投票，人类在分歧/平局时裁决 |
| preference model | 偏好模型：以人类偏好为训练信号训练的模型 |
| cognitive load | 认知负荷：标注者完成任务所需的脑力开销 |
| crowd（crowdsourced） | 众包/社区人群：非付费、未筛选的参与者 |

## 核心要点速记

- **人工评测 = 让人类给模型打分**（事后评测视角）；适合追求**数据质量、隐私、可解释性**的场景。
- **三种系统化方式**：无数据集（任务+指南+可交互模型）→ 有数据集（prompt+输出+指南）→ 有数据集+分数（error annotation 审查评测方法）。
- **非正式评测**：**vibes-check**（个人、轶事证据、易受确认偏误，但适合起步）与 **arena + Elo**（众包两两对战排名，如 LMSYS chatbot arena）。
- **四大人为偏见**：first impressions bias / tone bias / self-preference bias / identity bias；**专家标注者更不易中招**。
- **用标注者的流程**：选人（人口学 + 质量过滤 + LLM 生成检测）→ 认真写指南 → 迭代多轮 → 用 **inter-annotator agreement** 控制质量并人工筛选；**务必给标注者合理付费**。
- **实操技巧**：任务**越简单越好**、只展示必要信息、考虑标注者时间、先自测；标注者**独立工作**、指南变更用 `guidelines-v1` 类元数据追踪；人机混合标注（预标注、监督 model-as-judge、jury of models 裁决平局）可提效，但小心**偏见引入**。
- **选择路线**：要严谨、可复现、要数据 → 系统化人工评测；要快、要省、要发现边缘用例 → 非正式评测。

## 参考资料

### 原文 GitHub 链接（Human Evaluation 章节）

- [basics.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/human-evaluation/basics.md)
- [using-human-annotators.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/human-evaluation/using-human-annotators.md)
- [tips-and-tricks.md](https://github.com/huggingface/evaluation-guidebook/blob/main/contents/human-evaluation/tips-and-tricks.md)

### 文中提到的外部链接

**博客 / 文章**

- [Error Annotations to Evaluate（error annotation）](https://ehudreiter.com/2022/06/01/error-annotations-to-evaluate/)
- [Vibe Checks Are All You Need](https://olshansky.substack.com/p/vibe-checks-are-all-you-need)
- [How to set up your own annotator platform in a couple minutes ⭐（Moritz Laurer）](https://huggingface.co/learn/cookbook/enterprise_cookbook_argilla)

**论文（arXiv / ACL）**

- [AI audits（2401.14462）](https://arxiv.org/abs/2401.14462)
- [First impressions bias（2309.16349）](https://arxiv.org/abs/2309.16349)
- [Self-preference bias（2310.13548）](https://arxiv.org/abs/2310.13548)
- [Identity bias / toxicity（2205.00501）](https://arxiv.org/abs/2205.00501)
- [Cultural preferences of annotators（2404.16019v1）](https://arxiv.org/abs/2404.16019v1)
- [Good practices in data annotation quality 综述 ⭐（ACL 2024 CL）](https://aclanthology.org/2024.cl-3.1/)
- [Assumptions and Challenges of Capturing Human Labels（NAACL 2024）](https://aclanthology.org/2024.naacl-long.126/)

**平台 / 工具**

- [LMSYS chatbot arena](https://huggingface.co/spaces/lmsys/chatbot-arena-leaderboard)
- [GAIA benchmark](https://huggingface.co/gaia-benchmark)
- [Argilla](https://argilla.io/) / [Argilla 仓库](https://github.com/argilla-io/argilla/)
- [ScaleAI 数据标注指南](https://scale.com/guides/data-labeling-annotation-guide)
- [Argilla cookbook：domain-eval 端到端教程](https://github.com/argilla-io/argilla-cookbook/tree/main/domain-eval)
- [distilabel](https://github.com/argilla-io/distilabel)
- [lighteval](https://github.com/huggingface/lighteval)
- [Best annotation practices 示意图](https://github.com/huggingface/evaluation-guidebook/blob/main/assets/best_annotation_practices.png?raw=true)