Как проверять LLM руками и скриптами: 12 уроков по переводам и размерным сеткам

Когда LLM встраивают в действующий бизнес-процесс, вопрос уже не в том, умеет ли модель переводить или искать данные. Вопрос в том, что случится, когда она ошибётся. Авторы разбора на Habr собрали 12 выводов из двух боевых задач: автоперевод товаров с английского на русский и поиск размерных сеток.

Две задачи, две стратегии

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

Вторая задача: найти размерную сетку по связке «бренд + тип товара + размер + пол», например Nike, кроссовки, 11 US, мужские. Ошибка дорогая: стелька 260 мм вместо 250 означает возврат. Объём умеренный, поэтому человек проверяет каждую запись. Две модели с веб-поиском (OpenAI и Gemini) ищут сетку независимо, Claude выступает судьёй, а человек делает финальную проверку.

Отсюда простая матрица: оцените цену ошибки и объём в день, и стратегия проверки станет очевидной.

Что реально помогает

Контекст важнее хитрых промптов. Сначала переводили только название, качество выросло после добавления описания, сайта, категории и ссылки. В Walmart однобуквенный атрибут «N» (сокращение от «No») переводился как «North», пока не добавили название атрибута. У DoorDash многие «ошибки судьи» оказались нехваткой информации. Если модель ошиблась, сначала проверьте, хватает ли ей данных.

Обоснование ставьте перед ответом. Модель выдаёт правило из промпта или дословный фрагмент страницы, и только потом значение. Выдумок меньше, а проверяющему проще найти источник.

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

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

Инструменты и процесс

Для ручной проверки команда сделала расширение для Chrome. Оно берёт JSON с результатами, открывает страницу-источник, подсвечивает найденное значение (или запускает поиск Google, если сетки нет), а решение принимается горячими клавишами. На выходе JSON уходит в админку. Скорость проверки выросла в десятки раз.

Ещё несколько практик: фиксировать версию модели и промпта у каждого результата, прогонять эталонный набор при смене связки, подключать категорийных менеджеров на раннем этапе (они нашли неточности в переводе косметики и лекарств), раз в месяц проверять выборку вручную. Тестировать нужно именно пару «модель + промпт», потому что один промпт на разных моделях ведёт себя по-разному.

Ограничения и вывод

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