RLHF Vocabulary Guide: Human Feedback, Reward Models, and Annotation Language (англійською)
Освоєння англійської лексики, що використовується у конвеєрах RLHF — пари переваг, моделі винагород, правила анотації і угода між анотаторами для інженерів штучного інтелекту.
Праця в RLHF вимагає чіткої англійської мови
Підсилення навчання від людського зворотного зв’язку (RLHF) стало стандартною технікою для вирівнювання великих мовних моделей. Інженери, дослідники і спеціалісти з якості анотації, які працюють на трубопроводах RLHF, спілкуються в спеціалізованому словнику, який знаходиться на перетині машинного навчання, мітки даних і експериментального проектування.
Якщо ви працюєте у цьому просторі і англійська не є вашою першою мовою, у цьому довіднику ви знайдете термінологію і контекст, щоб використовувати його з впевненістю.
Основний RLHF Pipeline Vocabulary
| Term | Definition |
|---|---|
| Preference pair | A pair of model outputs shown to an annotator, who selects the preferred one |
| Comparison data | The dataset of preference pairs collected from annotators |
| Reward model | A neural network trained to predict human preferences, producing a scalar reward signal |
| Reward signal | The numerical value output by a reward model, used to guide policy training |
| Policy | The language model being fine-tuned via reinforcement learning |
| Reference model | The frozen pre-trained model used as a baseline to constrain policy updates |
| KL divergence | A measure of how far the policy has drifted from the reference model |
| Calibration | The process of aligning a model’s confidence scores to actual accuracy rates |
** Пара вимог ** — це атомарна одиниця даних RLHF. Анотатор бачить два завершення для одного і того ж запитання і вибирає краще завершення. Якість вашої моделі винагороди безпосередньо залежить від якості анотацій до настанов — саме тому так важливо дотримуватися правил анотації і контролю якості.
Анотація Pipeline Vocabulary
| Term | Definition |
|---|---|
| Annotation guideline | A document instructing annotators on how to label data for a specific task |
| Task instruction | The specific prompt given to an annotator for a single annotation job |
| Label schema | The set of possible labels or ratings an annotator can assign |
| Rubric | A structured scoring framework with criteria and examples for each score level |
| Edge case | A scenario that is difficult to label because it falls outside the guideline’s main cases |
| Annotator bias | Systematic differences in how a particular annotator labels data versus others |
| Gold standard | A set of examples with known correct labels, used to calibrate annotators |
| Calibration set | A sample of annotations reviewed together to align annotator understanding |
При написанні рекомендацій щодо анотації, слово “should” є неоднозначним — чи означає воно “must” чи “is preferred”? У написанні рекомендацій використовуйте “must” для вимог і “prefer” або “favour” для найкращих практик. Це розрізнення значно зменшує помилки анотації.
Аннотаційний словник якості
| Term | Definition |
|---|---|
| Inter-annotator agreement (IAA) | The degree to which independent annotators produce the same labels |
| Cohen’s kappa (κ) | A statistical measure of IAA that accounts for chance agreement; ranges from -1 to 1 |
| Fleiss’ kappa | An extension of Cohen’s kappa for more than two annotators |
| Intraclass correlation (ICC) | A measure of agreement for continuous ratings |
| Adjudication | The process of resolving disagreements between annotators, often by a senior reviewer |
| Consensus labelling | A label determined by majority vote among multiple annotators |
| Annotation throughput | The number of items labelled per annotator per unit of time |
| Label noise | Incorrect or inconsistent labels in a training dataset |
Каппа Коена від 0.6–0.8 вважається суттєвою погодою; вище 0.8 є майже ідеальною. При обговоренні результатів IAA з колегами, контекстуалізуйте число: * “Наша каппа становить 0,71, що є значним, але ми бачимо помітний спад на суперечливих прикладах - вони потребують переглянутих рекомендацій ”. *
Використовується для тренування мови
| Term | Definition |
|---|---|
| Reward hacking | When a policy learns to exploit weaknesses in the reward model rather than align with true intent |
| Goodhart’s Law | ”When a measure becomes a target, it ceases to be a good measure” — describes reward hacking |
| Overoptimisation | Excessive optimisation for the reward model, causing the policy to degrade in real quality |
| Regularisation | Techniques (such as KL penalty) that constrain the policy to prevent overoptimisation |
| Human preference distribution | The distribution of true human preferences the reward model is trying to approximate |
Приклади висловлювань
- “Модель винагороди занадто добре підходить для поверхневих характеристик пар переваг - багатослівні відповіді отримують високі оцінки незалежно від фактичної точності.”
-
- “Наша взаємозгода між анотатором і автором знизилась з 0, 74 до 0, 61 після того, як ми ввели нову рубрику; я підозрюю, що вимір корисності є неоднозначним і потребує прикладів.” *
-
- “Перед запуском наступного сеансу калібрування, давайте переглянемо випадки, коли анотатори найчастіше не погоджуються, і відповідно оновимо рекомендації.” *
- “Розбіжність KL між політикою та еталонною моделлю зростає з тренуванням — нам може знадобитися посилити коефіцієнт регуляризації.”
-
- “Рішення щодо найбільш суперечливих пар переваг повинні приймати експерти-рецензенти доменів, а не загальний резерв, щоб зберегти якість міток.” *
Реєстраційні дані
При презентації роботи RLHF змішаній аудиторії інженерів ML і зацікавлених осіб продукту, уникайте припущення знайомства зі статистичними термінами. Замінити “наша kappa дорівнює 0,7” на “наші анотатори погоджуються приблизно 70% часу після обчислення випадкового випадку, який вважається сильною домовленістю для цього типу завдання.”
Слово “вирівнювання” використовується як в технічному сенсі (вирівнювання вихідних даних моделі з людськими перевагами), так і в ширшому сенсі безпеки ШІ (забезпечення безпечної поведінки систем ШІ). Поясніть, який сенс ви маєте на увазі, коли контекст може бути неоднозначним.
Навигація Nuance: Common Phrases for Collaborative Feedback
Будьмо чесними - робота над вирівнюванням великої мовної моделі за допомогою підкріплення навчання від людського зворотного зв’язку (RLHF) може здатися неймовірно складною. Поза технічним жаргоном «моделей винагороди» і «пар переваг», значна частина роботи зводиться до комунікації - чіткої, точної комунікації про зворотній зв’язок і його вплив. Для розробників, які будують ці системи, особливо для тих, чия перша мова не є англійською, важливо розуміти не тільки що запитується, але і як це виражається. Це часто пов’ язано з тонкими нюансами у формулюваннях, які можуть суттєво вплинути на те, як переглядачі інтерпретують запит або як ви формулюєте свої власні спостереження.
Одна з найчастіших ситуацій виникає під час перегляду коду. Уявіть, що ви отримуєте коментар щодо запиту на витягнення, у якому описується зміна, пов’ язана з поліпшенням фактичної точності моделі. Замість того, щоб просто сказати: «Це потребує більшої заземленості», кращим підходом було б: «Чи можемо ми дослідити впровадження кроку збільшення відновлення знань тут? Поточний відгук іноді відхилявся від встановлених фактів, і явне пов’язання його з перевіряними джерелами зміцнило б його надійність. “Зауважте, що друга фраза набагато менш неоднозначна; вона пропонує конкретне технічне рішення - пошук знань - і підкреслює основну проблему: фактичний відхил. Аналогічно, у розмовах Slack, де обговорюються рекомендації щодо анотації, ви можете почути, як хтось каже: «Команда анотації повинна бути більш послідовною у своїй оцінці «корисності» — ми бачимо значні відхилення». Це не просто вказує на проблему; це вимагає певної дії і визнання кореневої причини: непослідовної інтерпретації. Під час написання описів PR уникайте нечітких слів, таких як « поліпшити якість ». Замість цього, чітко сформулюйте, * як * ви поліпшили його, наприклад, « Перероблено модуль генерації відповідей, щоб використовувати пошук за променями з температурою 0, 7 для поліпшення когерентності і зменшення повторюваності »
Ключова область, де ці нюанси стають критичним, це управління міжанотатором. Якщо різні анотатори постійно не згодні з тим, чи є вивід моделі «корисним», це сигналізує, що самі рекомендації щодо анотації потребують пояснення або вдосконалення. Недостаточно сказать, что “аннотации не согласны”. Вы должны объяснить * почему *. Наприклад: «Під час перегляду пар переваг, позначених як «корисні», ми спостерігали, що анотат А постійно приоритизував відповіді, що демонструють чітке розуміння намірів користувача, в той час як анотат Б зосередився більше на граматичній коректності. Ця невідповідність свідчить про те, що ми повинні чітко визначити «корисність» з точки зору розпізнавання намірів у рекомендаціях щодо анотації»
# Example: Using Weights & Biases API to track inter-annotator agreement metrics
wandb.log({
"inter_annotator_agreement_factual_accuracy": 0.85, # Percentage of times annotators agree on factual correctness
"inter_annotator_agreement_helpfulness": 0.72 # Percentage of times annotators agree on helpfulness
})Пам’ятайте, що мета не просто надати інформацію; це надати можливість продуктивного діалогу і забезпечити, щоб усі працювали над тими ж самими цілями - вирівнювання моделі з людськими цінностями за допомогою строгих, добре визначених петель зворотнього зв’язку.