Как разметить ответы AI, если эксперты не согласны
Два специалиста проверили одни ответы ассистента. Один принял короткий ответ со ссылкой на правило, второй отклонил его за отсутствие следующего шага. Если просто усреднить оценки, получится число без ясного смысла. Сначала нужно согласовать, что именно команда считает полезным ответом.
Разделите критерии, которые смешались в оценке
У ответа могут быть правильные факты, недостаточная полнота и неподходящий тон одновременно. Вместо общей кнопки «хорошо» задайте несколько независимых вопросов: подтверждены ли утверждения, решена ли просьба пользователя, понятно ли следующее действие. Для каждого вопроса определите допустимые ответы и пример.
Критерий полноты связан с задачей. Для «где находится форма?» достаточно ссылки и короткой подсказки. Для «как согласовать закупку?» нужны шаги и ответственные. Универсальное требование перечислять все детали сделает короткие справочные ответы искусственно плохими.
Проведите маленькую независимую разметку
Выберите небольшой разнообразный набор: обычные вопросы, недостающие данные, спорные правила и частичные ответы. Дайте экспертам одинаковую инструкцию и источники, но попросите сначала работать независимо. Иначе мнение первого проверяющего станет подсказкой для остальных.
Сравните разногласия по каждому критерию. На встрече обсуждайте конкретный ответ и пункт инструкции. Возможные причины: неоднозначная формулировка критерия, отсутствие знания в источнике, ошибка проверяющего или несколько допустимых решений. Не все разногласия нужно разрешать голосованием.
Выделите очередь обсуждения
Пример получает оценки двух разметчиков по критериям и выбирает пары, где они расходятся. Пропуски оценки выделяются отдельно: их нельзя молча считать согласием. Такая очередь помогает потратить время экспертов на изменение инструкции, а не на повторный просмотр всех ответов.
ratings = [
{"id": "q1", "criterion": "complete", "a": True, "b": False},
{"id": "q1", "criterion": "grounded", "a": True, "b": True},
{"id": "q2", "criterion": "complete", "a": False, "b": False},
{"id": "q3", "criterion": "complete", "a": None, "b": True},
]
missing = [r for r in ratings if r["a"] is None or r["b"] is None]
disputed = [r for r in ratings if r not in missing and r["a"] != r["b"]]
assert [(r["id"], r["criterion"]) for r in disputed] == [("q1", "complete")]
print({"discuss": disputed, "finish_annotation": missing})
Сохраните решение вместе с основанием
После обсуждения обновите инструкцию и добавьте разобранный пример. Сохраните исходные независимые оценки, итоговое решение и причину. Если критерий изменился, обозначьте новую версию и пересмотрите связанные примеры. Иначе одна часть набора будет размечена по старому правилу, другая — по новому.
Для некоторых задач допустимы несколько вариантов ответа. Например, при неполных данных можно задать уточнение или дать частичный ответ с явной границей. В эталоне лучше описать допустимые действия и обязательные факты, чем хранить одну «идеальную» фразу.
Отдельно организуйте разрешение предметных споров. Разметчики могут по-разному читать противоречивый регламент; тогда решение принимает владелец процесса и исправляет источник. Обучение судьи на неразрешённом споре только автоматизирует случайный выбор.
После обновления инструкции проведите новую независимую разметку на свежих примерах. Посмотрите, уменьшились ли разногласия по проблемным критериям. Затем этот набор можно использовать для сравнения версий ассистента или калибровки LLM-судьи. У команды появится объяснимый эталон: понятны требования, источники и причины принятия каждого спорного случая.
Продолжить проект на практике
Согласованная разметка становится основой автоматической оценки. В платном курсе LLMOps & Evaluation вы соберёте тестовые наборы, поработаете с LLM-судьями и отчётами качества. Подготовленные здесь критерии и спорные примеры помогут проверять судью и объяснять, почему версия ассистента проходит приёмку.
Откройте программу курса и выберите следующий этап своего проекта.
По теме: Версия eval-датасета: почему одной папки с вопросами недостаточно.
Продолжить на практике
- LLMOps & Evaluation: из песочницы в продакшн ↗
Практический курс по LLMOps. Соберёте продакшн-контур для LLM: eval-фреймворк (LangSmith/Ragas/OpenAI Evals), quality-гейты в CI/CD, алёрты на дрейф, монитринг скорости и стоимости, управление промпт-версиями и безопасность. Плюс профессиональные блоки: synthetic data для тестов, LLM-based judges, отчётность для релиз-комитета и runbook’и инцидентов.
