Разговор начался с обычной рекомендации. Один из участников посоветовал маленькую модель для перевода текстов: быстро, эффективно, целые книги переводятся за пару секунд.
Ему задали вопрос, который выглядит невинно ровно до тех пор, пока на него не нужно отвечать. В каких языковых парах она лучше специализированной модели для перевода?
Ответ был: во всех, это же очевидно, сравни словарь.
Дальше спор шел несколько часов и закончился плохо. Но внутри него лежал вопрос, который стоит любых часов. Не «какая модель лучше». А чем вообще доказывается, что модель делает работу хорошо.
Два способа доказать, и оба не бесплатные
Столкнулись две школы. И это не спор дилетанта с профессионалом, это спор о том, что считать доказательством.
Первая школа меряет результат. Один из участников описал свою процедуру. Взял носителей языка, набрал 1 000 референсных фраз, дал людям перевести их с учетом максимального контекста. Получился эталон. Потом прогнал через маленькие модели те же фразы и сравнил. Специализированная 4B-модель для переводов дала около 74% приемлемых переводов без всякого тюнинга и оказалась лучше всех моделей размером до 9B. Дальше он два месяца собирал в работе кривые переводы, набралось около 200 случаев, и на них тюнил промпт и модель.
Вторая школа меряет саму модель. Другой участник возражал, что оценка «вот это качественно, а вот это нет» субъективна по построению, и предлагал смотреть внутрь. На perplexity – меру того, насколько сильно модель сомневалась при выборе следующего токена. Если модель выбирала не из пяти-шести вариантов, а из тысячи, значит в этом месте латентного пространства у нее пробел или аномалия. Число объективное, считается автоматически, человек не нужен.
И добавлял сильный аргумент про масштаб. Пока у вас 500 проблемных кусков, вы разберете их руками. Когда их 500 000, ручной разбор невозможен физически.
Почему обе стороны правы про разное
Спор не разрешался несколько часов по простой причине: участники измеряли разные вещи и оба называли это качеством.
Perplexity – метрика уверенности, а не правильности. Модель может быть уверенно неправа. Если в обучающих данных ошибка встречалась чаще правильного варианта, модель выдаст ее с низкой perplexity. И наоборот: высокая perplexity часто означает не ошибку, а законную многовариантность. У фразы есть три хороших перевода, и модель честно колеблется между ними.
Отсюда практический вывод, который стоит выписать отдельно.
Сигналы модели – отличный маршрутизатор и плохой судья. Perplexity, логарифмические вероятности токенов, расхождение между несколькими прогонами – все это прекрасно отвечает на вопрос «куда смотреть в первую очередь». Отсортируйте 500 000 фрагментов по уверенности модели, возьмите верхние два процента, и вы получите выборку, где концентрация проблем в разы выше случайной. Ровно ради этого аргумент про масштаб и приводился. И он верный.
Но ответить на вопрос «правильно ли это переведено» такая метрика не может в принципе. Она не видела правильного ответа.
Прогон на реальных задачах – единственный судья и дорогой инструмент. Размеченный людьми эталон – единственное место, где вообще появляется понятие «верно». Плата за это – деньги, время и потолок по объему.
Отсюда честная сборка обоих подходов. Сигналы модели просеивают объем, люди выносят приговор на выборке. Не «или», а «сначала одно, потом другое».
Кстати, во время спора прозвучало наблюдение, с которым стоит согласиться, хотя произнесено оно было как укол. У обоих методов одна и та же болячка. И набор референсных фраз, и порог по perplexity выбирает человек, исходя из своих представлений о задаче. Полностью объективной оценки не существует ни там, ни там. Вопрос только в том, зафиксированы ли ваши представления явно или живут в голове.
«Это же субъективно» – и что с этим делать
Прозвучал еще один правильный вопрос: а если тот же перевод другому носителю языка покажется некорректным?
Так и будет. Но это не отменяет измерение, а задает ему погрешность. Индустрия разметки живет с этой проблемой полвека и умеет ее ограничивать.
- Несколько оценщиков на один кейс. Два человека уже дают возможность увидеть расхождения, три – разрешать их большинством.
- Согласованность как отдельная метрика. Если ваши оценщики расходятся на 40% случаев, проблема не в модели, а в инструкции для оценки.
- Попарное сравнение вместо абсолютной оценки. Человеку тяжело поставить «7 из 10», но легко ответить, какой из двух вариантов лучше. Отсюда же растут все арены, где модели сравниваются вслепую.
- Правила вместо вкуса. Инструкция «перевод считается верным, если сохранены смысл, регистр речи и терминология» дает совсем другую согласованность, чем «оцените качество».
Самый прагматичный якорь прозвучал в самом споре: правильный перевод – тот, за который платят деньги. Звучит цинично, зато операционально. У вашей системы есть заказчик, и его критерий приемки и есть определение качества. Если оценщики не сходятся, обычно это значит, что критерий приемки не сформулирован. И спорить надо не про модель.
Чужие бенчмарки: почему они бесполезны и почему их отсутствие важно
Параллельно на той же неделе в чате шел второй спор – про публичные бенчмарки вендоров. Он про то же самое, только на уровень выше.
Аргумент против: бенчмарк меряет решение чужих задач и оценку чужих результатов. Что вам дает число, полученное на наборе, который вы не выбирали и не увидите в своей работе? Плюс даже один и тот же бенчмарк в отчетах разных вендоров показывает разные цифры на одних и тех же моделях.
Аргумент за прозвучал неожиданно сильно. Он не про истину, а про обязанности продавца. Если вендор хочет внимания, бороться за пользователя должен он, а не пользователь – тратить свои деньги на проверку чужих обещаний. Аналогия из обзоров ноутбуков: зрителю неважно, что именно за тяжелый проект открывают в среде разработки и сколько там классов. Важно, что задача одна и та же для всех устройств, и цифры можно сравнить между собой.
Получается вот такая рабочая позиция:
| Что | Что оно вам дает |
|---|---|
| Публичные бенчмарки | Фильтр на входе: стоит ли тратить неделю на собственную проверку |
| Отсутствие любых цифр у вендора | Сигнал о вендоре, а не о модели |
| Свой эвал-набор | Единственное основание для решения о переходе |
Отдельный сюжет – цена ошибки. Один из участников рассказал, как купил годовую подписку на модель, которая в его работе оказалась бесполезной. Годовая подписка – ровно та ставка, которую эвал-набор на два вечера превращает в рутинную проверку.
Как собрать эвал-набор, который окупится
Хорошая новость: чтобы начать, не нужны платформы, разметочные команды и бюджет. Нужен один текстовый файл.
- Соберите 30–100 реальных случаев. Не придуманных, а тех, где система уже ошибалась. В кейсе с переводами за два месяца работы набралось около 200 – нормальная скорость накопления.
- Зафиксируйте эталонный ответ. Тот, который вы готовы показать заказчику. Там, где эталон один не бывает, зафиксируйте критерий приемки словами.
- Заморозьте условия прогона. Версия модели, промпт, температура, контекст. Меняя две вещи сразу, вы не узнаете, какая из них помогла.
- Считайте не одну цифру, а разбивку. Доля приемлемых ответов плюс типы ошибок: термин, смысл, формат, галлюцинация. Одна цифра скажет, что стало хуже, разбивка – что чинить.
- Добавьте автоматического судью, но откалибруйте его. Модель-оценщик экономит часы, но сначала сравните ее вердикты с человеческими на 50 случаях. Если совпадение ниже 80%, судью надо чинить, а не пользоваться им.
- Прогоняйте при каждой смене чего угодно: модели, версии, промпта, тюнинга. Это и есть та рутина, ради которой все затевалось.
- Отдельно ведите список случаев, где модель была уверена и неправа. Самая дорогая категория ошибок: их не поймает ни один порог по вероятностям.
Стоимость такого набора – один вечер и потом полчаса в неделю на пополнение. Стоимость его отсутствия – решения о технологическом стеке, принятые по фразе «ну у меня работает».
Что делать, когда эталона нет вовсе
Отдельный класс задач – те, где правильного ответа не существует даже в теории. Саммари встречи, ответ поддержки, черновик письма. Здесь нет тысячи референсных фраз, потому что нет референса.
Не повод отказаться от измерения. Просто судья меняется.
Отрицательные критерии вместо положительных. Сформулировать, что такое хороший ответ, невозможно. А что такое неприемлемый – вполне: выдуманный факт, потерянное решение встречи, обещание от лица компании, переход на другой язык. Считайте долю прогонов, где сработал хоть один запрет. Это оценка не качества, а риска – и для продакшена она важнее.
Сравнение вместо оценки. Старый вариант против нового, вслепую, на одних и тех же входах. Человеку не нужно знать, каким должен быть идеальный ответ, чтобы уверенно сказать, какой из двух он отправил бы клиенту.
Поведение пользователей как метрика. Доля правок после генерации, доля отказов от предложенного варианта, повторные обращения в поддержку по тому же вопросу. Сигнал шумный и запаздывающий, зато его не надо размечать. Он приходит сам.
И общее правило: чем размытее задача, тем важнее фиксировать не оценку, а границы. Полностью субъективное качество измерить нельзя. А вот заметить, что после смены модели количество выдуманных фактов выросло вдвое, вполне можно.
Вопрос, который стоит задавать себе
В том споре была одна реплика, ради которой его стоит помнить. На рекомендацию модели прозвучало: ты это тестировал или просто веришь?
Вопрос неприятный, потому что честный ответ у всех нас чаще второй. Мы рекомендуем инструменты, которые понравились. Мы переходим на модель, потому что она новее. Мы считаем свою конфигурацию промптов лучшей, потому что собирали ее сами.
Разница между инженерной позицией и верой не в уверенности, а в наличии процедуры, которая может показать, что вы неправы. У первой школы такая процедура была: 1 000 фраз, носители языка, число 74%. У второй тоже: perplexity, аномалии, распределения. Спор оказался бы полезным для обеих сторон, если бы вопрос звучал не «кто прав», а «что именно померил каждый из нас».
А чем вы докажете, что модель, на которой стоит ваш продакшен, работает лучше соседней – кроме ощущения, что она хорошая?
Статья выросла из обсуждений в сообществе «Тимлид не кодит». Контекст – в инсайтах за 10–16 августа и за 13–19 июля. Присоединяйтесь к обсуждению в Telegram.