Зачем нужен Human-in-the-Loop и на каких задачах построены выводы
Human-in-the-Loop для LLM значит, что человек встроен в валидацию результатов модели. Стратегию проверки выбирают по двум измерениям: сколько стоит одна ошибка и сколько записей приходит в день. Оси дают четыре рабочих сценария, от полной ручной проверки каждой записи до отказа от ручной проверки с опорой на автоматику и выборочный аудит.
Выводы ниже опираются на две бизнес-задачи, в которых проверяли результаты LLM. Первая: перевод названий и описаний товаров с английского на русский, десятки тысяч позиций в день. В пайплайне несколько разных моделей, LLM-судья (модель-судья) и проверка скриптом. Вторая: поиск размерных сеток по связке «бренд + тип товара + размер + пол», например «Nike, кроссовки, 11 US, мужские». Две модели с веб-поиском независимо находят сетку на сайте бренда и возвращают значения в сантиметрах, судья сравнивает ответы, человек делает финальную проверку. Первоисточник с 12 выводами о Human-in-the-Loop описывает оба кейса.
Дальше: три вывода о подготовке, матрица стратегий, разбор автоматических проверок, бинарный формат решений с доказательствами, требования к инструменту ручной проверки и чек-лист для своей задачи.
Два измерения, от которых зависит вся стратегия проверки
Цена ошибки отвечает на вопрос, что случится, если модель ошибётся и никто этого не заметит: потерянные деньги, время поддержки, репутация. Объём отвечает на вопрос, реально ли посмотреть каждую запись глазами.
В переводах ошибка дешёвая. Рядом английский оригинал и фотографии товара, покупатель видит несоответствие, исправление стоит нескольких минут. Товаров при этом десятки тысяч в день, вручную их не проверить.
В размерных сетках ошибка дорогая: если указать стельку 260 мм вместо 250, кроссовок не налезет и придёт возврат. Объём умеренный, и человек может проверить каждую запись.
Те же две оси дают четыре квадранта, и для каждого есть свой набор действий.
Выводы 1-3: подготовка, Deep Research, оценка цены ошибки и эксперты
Почему Deep Research стоит делать в трёх агентах и как оформить результат
Вывод 1: исследование до кода. В Claude, Gemini и ChatGPT дипсерч реализован по-разному, и результаты трёх исследований хорошо дополняют друг друга. Промпт для исследования составляют вместе с LLM: описывают задачу и просят помочь сформулировать, что именно нужно выяснить. Без этого шага легко получить обзор рынка вместо ответа на свой вопрос.
Результат оформляют в MD-файл и кладут в папку проекта. Агенты, с которыми работают дальше, читают этот файл и берут оттуда информацию. Ресёрч становится частью контекста проекта, а не двадцатью открытыми вкладками.
Отдача зависит от задачи. По автоматическим переводам, популярной теме, нашлось много полезной информации. По поиску размерных сеток, редкой задаче, полезного оказалось мало. Редкая задача означает, что готовых статей не будет и основную работу придётся делать своими проверками и с помощью экспертов.
Вывод 2: до выбора стратегии оценить цену ошибки и объём. Порядок такой: сначала разобраться, что произойдёт при ошибке и сколько записей в день, потом решать, нужен ли человек на каждой записи.
Вывод 3: экспертов подключают на раннем этапе, при выборе моделей и промптов. Категорийный эксперт видит, что термин в описании переводится иначе в конкретном контексте, а размерная сетка производителя расходится с общей таблицей. После запуска такие замечания приходят дороже.
Вывод 4: матрица выбора стратегии проверки по цене ошибки и объёму
Вывод 4 самый практичный: стратегия проверки вытекает из квадранта, а не из вкусов команды.
Дорогая ошибка и небольшой объём: полная ручная проверка
Человек проверяет каждую запись. В кейсе размерных сеток автоматика сужает пространство: две модели с веб-поиском независимо находят сетку на сайте бренда и возвращают сантиметры, судья сравнивает ответы, человек ставит финальную точку. При умеренном объёме это выполнимо.
Критично, чтобы инструмент проверки был удобным. Если проверяющий прыгает между вкладками, чтобы сверить сантиметры со страницей бренда, время уходит на переключения, а не на проверку.
Дорогая ошибка и большой объём: автофильтр плюс разбор спорного
Автоматические проверки отсекают очевидное, человек разбирает спорное. Скрипты и судья отсеивают то, что точно плохо или точно хорошо, а в ручную очередь попадают записи с конфликтом ответов двух моделей, пустыми полями и нестандартными единицами.
Две опасные настройки: слишком мягкий фильтр пропускает спорное в продакшен, слишком жёсткий отправляет человеку всё похожее на норму. Границу калибруют на выборке и держат под аудитом, чтобы ловить дрейф.
Дешёвая ошибка: выборочный аудит, судья и мониторинг вместо ручной проверки
В кейсе переводов набор такой: LLM-судья, детерминированные проверки, выборочный аудит, мониторинг. Человек не смотрит десятки тысяч карточек, он смотрит выборку.
Выборочный аудит - это регулярная процедура с понятным правилом отбора (случайная выборка, все записи с конфликтом ответов, все новые бренды) и фиксацией результатов. Без правила и фиксации аудит превращается в «иногда посматриваем».
| Квадрант | Что делает человек | Автоматика до человека | Пример |
|---|---|---|---|
| Дорогая ошибка, небольшой объём | Проверяет каждую запись | Две модели с веб-поиском, судья сравнивает ответы | Размерные сетки по связке «бренд + тип товара + размер + пол» |
| Дорогая ошибка, большой объём | Разбирает только спорное | Скрипты на формат и единицы, судья на расхождения | Размерные сетки при потоке в тысячи позиций |
| Дешёвая ошибка, большой объём | Смотрит выборку по правилу | LLM-судья, детерминированные проверки, мониторинг | Перевод названий и описаний товаров |
| Дешёвая ошибка, небольшой объём | Минимальный контроль и аудит | Судья и скрипты, периодическая выборка | Небольшая категория товаров с готовым глоссарием |
Универсальных порогов «дорого/дёшево» и «мало/много» нет: границу задаёт бизнес через стоимость возврата, нагрузку на поддержку и цену ручного часа. Авторы разбора оперируют качественными оценками, без числовых порогов, и это честнее выдуманных констант.
Выводы 5-7: LLM-судья, детерминированные скрипты и версионирование промптов
Полные формулировки выводов 5-7 в доступном тексте первоисточника не раскрыты: текст обрывается на выводе 3. Ниже рабочая рамка, собранная из подтверждённых элементов пайплайна: судья и проверка скриптом в обеих задачах.
Что отдавать LLM-судье, а что скриптам
Правило простое: формальное проверяют скрипты, смысловое отдают судье.
- Скрипты: формат ответа, наличие обязательных полей, диапазон значений, единицы измерения. В размерных сетках все значения должны прийти в сантиметрах, иначе сравнение с эталоном бессмысленно.
- Судья: совпадают ли ответы двух моделей, соответствует ли перевод оригиналу, выглядит ли сетка правдоподобной для конкретного типа товара.
Судья тоже модель, он ошибается, и его решение не абсолютно. Полезно хранить его обоснование: по нему видно, почему запись ушла в ручную очередь или проскочила дальше.
Версионирование промптов закрывает вопрос «из-за чего изменилось качество». У каждого прогона фиксируют версию промпта и версию модели, а результаты проверок привязывают к этой версии: доля спорных записей, доля отсева скриптами, итоги аудита. Без такой привязки сравнить два прогона нельзя, а откат превращается в угадайку.
Выводы 8-10: почему оценки 1-5 и самоуверенность модели не работают
Выводы 8-10 о формате проверки в доступном тексте источника не раскрыты, поэтому разберу механику, которая проявляется на любой разметке такого рода.
Пятибалльная шкала плохо работает по четырём причинам:
- Критерии размыты: проверяющий не знает, чем 3 отличается от 4.
- Оценки дрейфуют между прогонами и между людьми.
- Средние по шкале плохо агрегируют: 3,8 не говорит, сколько записей сломано.
- Время уходит на выбор между 3 и 4 вместо решения «годится или нет».
Самооценка уверенности модели тоже не спасает. Модель уверенно выдаёт неверный ответ, а её confidence не откалибрована: высокий балл не означает высокую точность. Строить очередь ручной проверки на самооценке модели без калибровки на размеченной выборке рискованно.
Бинарный формат «да/нет» и требование доказательств на практике
Бинарный формат заставляет сформулировать критерий до проверки: «перевод соответствует оригиналу: да/нет», «значение в сантиметрах подтверждено страницей сайта бренда: да/нет». Ответ «нет» сразу отправляет запись в очередь исправлений. Ответ «да» требует доказательства: фрагмент английского оригинала и фото товара для перевода, фрагмент страницы бренда для размерной сетки.
Доказательство защищает от «просто нажать да»: проверяющий обязан показать основание, а следующий проверяющий может его перепроверить. Результат становится воспроизводимым, потому что два человека, глядя на одно доказательство, приходят к одному решению.
Вывод 11: удобный инструмент ручной проверки решает больше, чем кажется
Инструмент проверки - это не таблица с двадцатью колонками. Минимальный набор выглядит так:
- оригинал и результат рядом, без переключения вкладок;
- доказательства под рукой: ссылка на страницу бренда, фрагмент текста, фото товара;
- две кнопки вместо шкалы и поле для доказательства;
- быстрый переход к спорным записям и к следующей записи;
- минимум лишних полей, которые никто не заполняет.
Связь с матрицей прямая. При дорогой ошибке и небольшом объёме человек проверяет каждую запись, и секунды на переключение контекста умножаются на весь поток. При дешёвой ошибке инструмент нужен для выборочного аудита: выборка должна открываться в том же виде, что и поток, иначе аудит смотрят редко и небрежно.
Вывод 12: выборочный аудит и мониторинг как страховка
Регулярная выборка из потока, фиксация результатов, реакция на изменения. Мониторинг отвечает на вопрос «стало хуже или нет», но не заменяет проверку там, где ошибка дорогая: при дорогой ошибке и небольшом объёме полная ручная проверка остаётся основой, аудит лишь страхует автоматику.
Как связать версии промптов, судью и аудит в один контур
- Версия промпта и версия модели зафиксированы.
- Прогон на потоке или на накопленной выборке.
- Детерминированные скрипты отсекают формальный брак.
- Судья сравнивает ответы и размечает спорное.
- Человек проверяет всё или выборку в зависимости от квадранта.
- Результаты сохраняются с привязкой к версии.
- Новая версия промпта сравнивается с предыдущей по тем же метрикам.
Без версионирования аудит не отвечает на вопрос «что сломалось». С версионированием видно, что доля спорных выросла после правки промпта, и откат занимает минуты.
Как применить это к своей задаче: чек-лист внедрения HITL
- Оценить цену ошибки и объём. Что произойдёт при ошибке и сколько записей в день. Возврат из-за стельки 260 мм вместо 250 и опечатка в описании, которую видно рядом с оригиналом, дают разные стратегии.
- Провести Deep Research в нескольких агентах и оформить его в MD-файл проекта. Три дипсерча в Claude, Gemini и ChatGPT дают разные углы, файл потом читают рабочие агенты.
- Подключить категорийных экспертов к выбору моделей и промптов. Их замечания на этапе промпта дешевле правок в продакшене.
- Определить квадрант матрицы и стратегию. Дорогая ошибка и небольшой объём: проверка каждой записи. Дешёвая ошибка: аудит и мониторинг.
- Поставить скрипты и судью. Скрипты на формат, обязательные поля, диапазоны и единицы, судья на смысл и сравнение ответов двух моделей.
- Сделать бинарный инструмент проверки с доказательствами. Да/нет плюс основание решения, оригинал рядом, минимум полей.
- Завести версионирование промптов и моделей с привязкой к результатам проверок.
- Настроить выборочный аудит и мониторинг: правило отбора, фиксация, регулярность.
Границы подхода: HITL снижает риск, но не обещает нулевую ошибку и не отменяет экспертизу в предметной области. Как выбирать сам процесс для автоматизации и где проходят границы применимости ИИ-инструментов, разбираем в материале об ИИ-инструментах в разработке.