Доверяй, но проверяй: 12 выводов о Human‑in‑the‑Loop с LLM

Сейчас LLM всё чаще внедряют в действующие бизнес‑процессы: поиск и сбор информации, структурирование данных, проверку и публикацию. При этом цена одной ошибки ^[1] может быть высокой: потерянные деньги, время и репутация.

Снизить этот риск помогает принцип Human‑in‑the‑Loop: в процесс добавляется человек, который валидирует данные. В этой статье собраны наши выводы на примере двух реальных бизнес‑задач: автоматического перевода и поиска размерных сеток.

Контекст: бизнес‑задача

Выводы основаны на двух наших задачах, в которых мы проверяли результаты LLM:

Перевод товаров. Названия и описания товаров с английского на русский, десятки тысяч в день. Используется несколько разных моделей + LLM судья + проверка скриптом. Подробнее в предыдущей статье ^[2].

Поиск размерных сеток. Ищем сетку по связке «бренд + тип товара + размер + пол» (например, «Nike, кроссовки, 11 US, мужские»). Две модели с веб поиском независимо находят на сайте бренда размерную сетку и возвращают значения в сантиметрах, судья сравнивает ответы, человек проводит финальную проверку.

Вывод 1. Начинайте с Deep Research

Перед началом любой работы погуглите и подипсерчите, причем лучше с разными агентами. В Claude, Gemini и ChatGPT дипсерч реализован по‑разному, и результаты трёх исследований хорошо дополняют друг друга. Так вы заранее увидите большинство проблем, с которыми столкнётесь, и готовые решения.

Попросите оформить результаты в виде MD‑файла и положите его в папку проекта. Агенты, с которыми вы будете работать дальше, смогут читать его и брать оттуда информацию.

Промпту для исследования составляйте его вместе с LLM: опишите задачу и попросите помочь сформулировать, что именно нужно выяснить.

В наших задачах мы нашли множество полезной информации по автоматическим переводам (очень популярная задача) и мало полезного по поиску размерных сеток (редкая задача)

Вывод 2. Оцените цену ошибки и объём задачи

Оцените задачу в двух измерениях: сколько стоит одна ошибка и сколько записей в день. От этого зависит стратегия проверки.

Ошибка в переводе дешёвая: рядом есть английский оригинал и фотографии. Товаров десятки тысяч в день, вручную их не проверить.

Ошибка в размерной сетке дорогая. Если указать стельку 260 мм вместо 250, кроссовок не налезет, и будет возврат. Объём при этом умеренный, и человек может проверить каждую запись.

Вывод 3. Подключайте экспертов при выборе моделей и промптов

Подключайте экспертов на раннем этапе. С категорийными менеджерами мы оценивали качество переводов и найденных размеров. Прогоните 50–100 записей через разные модели с разными промптами и отдайте результаты экспертам в удобном виде, чтобы они могли сравнить варианты и выбрать лучшую связку. Мы прогоняли записи через три модели с несколькими вариациями промптов и отправляли результаты HTML‑страницей, где на одном экране можно сравнить названия, описания или найденные размерные сетки. Эксперты заметили неточности в переводах косметики и лекарств, которые мы исправили с помощью промптов.

Тестируйте именно связки «модель + промпт»: один и тот же промпт на разных моделях работает по‑разному. У каждого провайдера свои гайды по промптингу (Anthropic ^[3], OpenAI ^[4], Google ^[5]), и они меняются даже внутри одной линейки: правила написания промптов для Opus 5 отличаются от правил для Opus 4.

Разделяйте промпты по категориям. В переводах у нас разные промпты для разных категорий товаров, а в размерных сетках отдельные правила для обуви и одежды. Перед отправкой запроса скрипт собирает итоговый промпт из общей базы и нужной ветки.

Вывод 4. Дайте модели максимальный контекст

Сначала мы переводили только название. Оно часто двусмысленно: набор слов без предлогов, аббревиатуры, названия линеек. Добавили описание, и качество выросло. В итоге остановились на полном контексте: сайт, ссылка на товар, категория, размер, название и описание.

Во время Deep Research мы нашли аналогичные кейсы у крупных компаний. У Walmart ^[6] однобуквенное значение атрибута «N» (сокращение от «No») переводилось как «North», пока в запрос не добавили название атрибута. А у DoorDash ^[7] многие ошибки LLM‑судьи на деле оказались нехваткой информации: цен, настроек меню, логики отображения. Если модель или судья ошибаются, сначала проверьте, хватает ли им информации.

Вывод 5. Требуйте от модели объяснений и доказательств

Добавьте в ответ модели поле с обоснованием решения. В переводах это объяснение: какие правила из промпта модель применила (правила у нас разные для разных категорий). В размерных сетках это доказательство: указание на HTML‑блок страницы с сеткой, ссылка и дословный фрагмент текста, откуда взято значение.

Ошибок становится меньше: модель меньше выдумывает и пытается аргументировать свои ответы, опираясь на конкретное правило или фрагмент. Поле с обоснованием ставьте перед итоговым значением, чтобы модель сначала рассуждала, а потом отвечала. При разборе ошибок сразу видно, где сломалось, а доказательство из источника ускоряет ручную проверку.

Вывод 6. Используйте LLM‑судью, который отвечает только «да» или «нет»

В переводах два этапа: сначала модель переводит, затем LLM‑судья проверяет перевод и при необходимости улучшает его.

В размерных сетках сетку независимо ищут две модели, OpenAI и Gemini. Третья модель, Claude, выступает судьёй: сравнивает их результаты и решает, можно ли допускать сетку. Так у нас два сигнала: совпали ли ответы двух моделей и одобрил ли их судья. Если не сошёлся хотя бы один, смотрим запись внимательнее. Одного совпадения мало: разные модели часто ошибаются одинаково.

Сначала мы использовали пятибалльную шкалу, но разницы между оценками 3 и 5 не обнаружили и оставили «да / нет».

Просить модель оценить уверенность в своей работе тоже бессмысленно. Модель с оценкой 10 из 10 выдавала нам значение из женской сетки вместо мужской.

Вывод 7. Лучшая проверка: детерминированные скрипты

В американских карточках размеры и вес указаны в дюймах, фунтах и унциях, часто прямо в названии. При переводе их нужно пересчитать в метрическую систему. Модель периодически ошибается: оставляет дюймы, пересчитывает неверно или пропускает значение.

Такие ошибки мы ловим регулярными выражениями: сравниваем числа в оригинальном названии и в переводе. Если в переводе осталось то же число, что в оригинале, единица не пересчитана или пересчитана неверно, и перевод уходит на доработку.

Если значения можно перевести скриптом без LLM, делайте это: извлекайте их регулярными выражениями и пересчитывайте через коэффициенты. Модели отдавайте только то, что скрипт перевести не смог, или дополняйте регулярные выражения новыми случаями.

Вывод 8. Фиксируйте версию модели и версию промпта

Сохраняйте у всех результатов версию модели и версию промпта. Если находите дефект, сразу видно, какие результаты получены той же связкой и что нужно перепроверить.

При переходе на новую модель или новый промпт прогоните проверенный набор и сравните результаты старой и новой связки вручную или через LLM‑судью из вывода 6. Новая модель на вашей задаче может оказаться хуже.

Вывод 9. Для ручной проверки напишите удобные инструменты

При работе с размерными сетками менеджеры используют Chrome и сайты брендов, поэтому проверять сетки логично ^[8] тоже в Chrome. Для этого мы сделали расширение, которое:

• берёт на вход JSON с результатами из LLM;

• открывает страницу‑источник, прокручивает к нужному месту и подсвечивает найденное значение ИЛИ если сетка не найдена, сразу открывает поиск Google с конкретным запросом

• по горячим клавишам проверяющий подтверждает, исправляет или отклоняет результат;

• на выходе даёт JSON, который автоматически загружается в админку (после авторизации).

Коллеги работают в одном инструменте, и им не нужно переключаться между несколькими окнами. Каждое действие занимает один клик. Скорость проверки повысилась в десятки раз.

Вывод 10. Станьте проверяющим сами

Чтобы сделать по‑настоящему удобный инструмент, нужно прочувствовать контекст, а для этого лучше самому долго с ним поработать. После каждой новой версии сядьте и проведите день‑два в роли того, для кого делали инструмент. Это сразу покажет все шероховатости и возможные пути улучшения.

Вывод 11. Регулярно проверяйте вручную и собирайте обратную связь

Модели обновляются, данные меняются, и без регулярной проверки качество незаметно падает. Раз в месяц проверяйте результаты вручную и собирайте обратную связь: жалобы пользователей и обращения в техподдержку.

Вывод 12. Используйте ошибки и жалобы как сигнал для улучшения системы

Найденные ошибки и жалобы мы разбираем и правим промпты. Если ошибка повторяется систематически, перерабатываем промпт: добавляем исключения и примеры.

В Walmart ^[6] лингвистам запрещено править переводы вручную: они формулируют правило, второй лингвист его подтверждает, и правило применяется ко всему каталогу.

Чем больше контекста накоплено о вашей системе, тем лучше она работает: ошибка → разбор → правка промпта → меньше таких ошибок.

Заключение

На сегодня LLM можно доверить процессы с низкой и даже средней ценой ошибки. Но критичные процессы лучше проверять руками до тех пор, пока вы не накопите большой массив положительных результатов: например, система несколько месяцев отработает без ошибок.

Постепенно улучшая систему, вы, скорее всего, придёте к этому результату, но на отладку уйдёт достаточно много времени. Советы выше помогут пройти этот путь быстрее и эффективнее. Спасибо за внимание ^[9]!