Почему бенчмарки релиза не ответят на ваш вопрос
Каждый новый флагманский релиз выходит с графиком, где модель опережает конкурентов по набору стандартизированных оценок. Эти цифры реальны, но они почти бесполезны для решения, что использовать в понедельник, и вот три причины.
Разрыв мал, а задачи не ваши. Разница в два балла на бенчмарке рассуждений ничего не говорит о том, пишет ли одна модель более удачное письмо клиенту или надёжнее удерживает схему на протяжении двухсот строк.
Бенчмарки измеряют то, что легко оценить. Задачи с правильным ответом. У большей части профессиональной работы такого ответа нет: тон, структура, суждение о том, что опустить. Именно здесь модели различаются сильнее всего, и именно это никак не измеряется.
Сравнения при релизе делает сам поставщик. Не обязательно нечестно, но никто не публикует оценку, где его модель заняла второе место.
Стоящий внимания вопрос уже: на конкретных задачах, которые вы делаете двадцать раз в неделю, какая из этих двух моделей лучше? Опубликованного ответа на него нет, зато выяснить его можно примерно за час.
Что на самом деле обычно меняется между релизами
В последних флагманских релизах улучшения, которые важны в ежедневной работе, стабильно проявляются в одних и тех же областях, и они редко попадают в анонс.
| Что улучшилось | Как вы это заметите | Показывает ли это бенчмарк |
|---|---|---|
| Соблюдение инструкций | Модель перестаёт игнорировать третье условие | Редко |
| Отрицательные инструкции | «Не используй аналогии» действительно соблюдается | Нет |
| Работа с длинным контекстом | Находит нужное на 140-й странице, а не только на 3-й | Частично |
| Дисциплина форматирования | В таблице ровно те столбцы, что вы просили, каждый раз | Нет |
| Калиброванная неуверенность | Говорит «не знаю» вместо того, чтобы выдумывать | Нет |
| Контроль тона | Меньше переписываний перед тем, как текст можно отправить | Нет |
| Глубина рассуждений | Замечает граничный случай, который вы упустили | Да, это как раз и измеряют |
Пять из этих семи пунктов незаметны на графике бенчмарка, и именно из-за них новая модель кажется лучше или хуже в работе. Соблюдение инструкций особенно важно: это разница между черновиком, который вы правите, и черновиком, который вы выбрасываете.
Часовая оценка
Делайте это вместо чтения новостей о релизе. Запустите обе модели бок о бок на своём собственном материале.
- Соберите пять реальных задач за последние две недели. Настоящих, с вашим реальным контекстом, а не игрушечных промптов. Включите хотя бы одну задачу на письмо, одну на структурированный вывод и одну, где требовалось рассуждать о чём-то незнакомом.
- Запишите, что должен содержать хороший ответ для каждой задачи, одним предложением, прежде чем что либо запускать. Этот шаг не даёт вам предпочесть тот ответ, что длиннее и увереннее звучит, а это сильное и почти неосознанное искажение.
- Запустите каждую задачу на обеих моделях параллельно, чтобы ни один ответ не влиял на восприятие другого.
- Оценивайте по объёму правок, то есть сколько работы нужно между выводом модели и тем, что вы отправите. Не по тому, как это звучит.
- Отметьте размер разрыва, а не только победителя. Взаимозаменяемые результаты говорят вам перестать думать о выборе модели для этой задачи, а это по-настоящему полезно.
- Ведите журнал. Через три месяца, когда выйдет следующий релиз, вы повторите те же пять задач и получите настоящий ответ за двадцать минут.
Последний пункт самый ценный. Сохранённый набор для оценки, это единственное, что делает оценку каждого следующего релиза дешёвой.
Шесть промптов, которые разделяют передовые модели
Общие вопросы дают похожие ответы от любой способной модели. Если хотите увидеть разницу, приложите давление к конкретному навыку.
- Тон в сложной ситуации.
Напиши сообщение клиенту о том, что мы сорвали срок. Возьми ответственность без чрезмерных извинений и без оправданий. Менее 120 слов.Различия в регистре видны сразу. - Отрицательное ограничение.
Объясни [понятие] без использования аналогий или метафор.Соблюдение отрицательных инструкций различается гораздо сильнее, чем можно ожидать. - Строгое извлечение данных.
Извлеки каждую дату, сумму и сторону в JSON-массив с ровно этими ключами. Если поле отсутствует, используй null. Не додумывай.Проверяет дисциплину формата и склонность заполнять пробелы. - Работа с длинным контекстом. Загрузите длинный документ и спросите о чём-то из середины. Показывает реально используемый контекст, а это не то же самое, что заявленный контекст.
- Признание незнания. Спросите о чём-то по-настоящему малоизвестном или очень свежем. Лучший ответ, это чёткое «я не знаю» или ответ с источниками. Выдумывание здесь дисквалифицирует модель независимо от любого бенчмарка.
- Соблюдение множества условий. Задайте шесть условий сразу и посчитайте, сколько из них выполнено. Этот единственный тест предсказывает повседневную удовлетворённость лучше, чем всё остальное в списке.
Ответ обычно «обе, но для разного»
Люди подходят к релизу, желая получить вердикт, и честный итог после проведения оценки почти всегда неоднозначен. Одна модель выигрывает в письме и тоне. Другая выигрывает в строгой структуре и скорости. По общим рассуждениям они настолько близки, что это ничего не решает.
Это не увёртка, это реальный результат, и у него есть практическое следствие. Если вы можете использовать только одну модель, вы выбираете, в какой категории задач будете хуже. Если можете использовать обе, вопрос релиза перестаёт быть «стоит ли переключаться» и становится «какие задачи переместить», а это гораздо меньшее и менее рискованное решение.
Это также меняет то, что для вас значит релиз. Когда новая модель появляется в рабочем пространстве, где уже есть несколько других, вы заново прогоняете свои пять задач, корректируете маршрутизацию и продолжаете работать. Никакой миграции, никакой отменённой подписки и ни одного месяца работы с чем-то худшим только потому, что вы обязались ещё до тестирования.
Что делать в день релиза
Не переключайте настройки по умолчанию сразу. Впечатления первой недели во многом определяются новизной и тем, какие примеры разошлись первыми.
Заново прогоните свой набор для оценки. Двадцать минут, если у вас сохранён набор с прошлого раза.
Проверьте скучные вещи. Размер контекстного окна, ведут ли себя ваши текущие промпты так же, как раньше, и не изменилось ли что-то, на что вы полагались. Модель, которая лучше в целом, может оказаться хуже на вашем конкретном шаблоне, и это стоит узнать до того, как вы перенесёте на неё продакшн-задачи.
Обновляйте маршрутизацию по задачам, а не целиком. Переносите категории, где новая модель явно победила, и оставляйте остальное как есть.
Подождите две недели, чтобы увидеть ограничения. Слабые стороны новой модели проявляются примерно через две недели широкого использования, и они редко попадают в анонс.
Общий подход описан в статье как выбрать модель ИИ, а о механике запуска двух моделей на одном промпте читайте в статье сравнение моделей бок о бок.
- Составьте набор из пяти реальных задач из своей работы и сохраните его
- Запишите, что должен содержать хороший ответ, прежде чем читать любой из выводов
- Запускайте обе модели параллельно, чтобы ни одна не влияла на восприятие другой
- Оценивайте по объёму правок, а не по тому, как звучит вывод
- Фиксируйте размер разрыва, поскольку взаимозаменяемые результаты тоже полезная информация
- Отдельно тестируйте отрицательные ограничения и соблюдение множества условий
- Подождите две недели, прежде чем переносить продакшн-задачи на новую модель
- Обновляйте маршрутизацию по задачам, а не переключайтесь целиком
Частые вопросы
Стоит ли переходить на самую новую модель?
Не в день релиза и не целиком. Заново прогоните небольшой набор своих реальных задач на обеих моделях, оцените, сколько правок нужен каждый вывод, и переносите только те категории, где новая модель явно побеждает. Новая модель обычно лучше в одних вещах и иногда хуже в других, особенно для существующих промптов, настроенных под предыдущую версию.
Почему бенчмарки не совпадают с моим опытом?
Потому что они измеряют то, что можно оценить автоматически, а значит, задачи с правильным ответом. У большей части профессиональной работы нет единственного правильного ответа, а качества, которые определяют повседневную удовлетворённость, то есть соблюдение инструкций, контроль тона, дисциплина форматирования и умение сказать «я не знаю», почти никак не измеряются. Модель может лидировать в каждом опубликованном рейтинге и при этом раздражать в работе.
Как часто нужно переоценивать модели?
Каждый раз, когда используемая вами модель получает значимый релиз, а сейчас это происходит примерно раз в несколько месяцев, плюс раз в квартал в любом случае. Постоянный набор из пяти реальных задач превращает это в двадцатиминутную работу, а не в целый вечер, и это единственный способ заметить, что маршрутизация, настроенная полгода назад, уже неверна.
Можно ли просто использовать модель, которая побеждает по общему рейтингу?
Можно, и в таком случае вы соглашаетесь на предсказуемо худшие результаты на определённой части своей работы. Устойчивый вывод при оценке на собственных задачах состоит в том, что одна модель выигрывает в письме и тоне, а другая в строгой структуре и скорости, при этом по общим рассуждениям они достаточно близки, чтобы это ничего не решало. Если вам доступны обе, выбор становится не по подписке, а по задаче.
Важно ли, через какой продукт я получаю доступ к модели?
Модель есть модель, поэтому качество вывода в целом одинаково, где бы вы к ней ни обращались. Разница в том, можете ли вы сравнивать, сохраняется ли контекст при переключении и обходится ли новый релиз миграцией или становится просто ещё одним вариантом в списке выбора. Рабочее пространство с несколькими моделями превращает каждый релиз из решения в корректировку.