Российские нейросети на рабочих задачах: честное сравнение

Правильный вопрос звучит не «какая российская нейросеть лучше», а «какая из них лучше на моей задаче, на моих документах и на сегодняшнюю дату». Разница принципиальная: первый вопрос имеет вид рейтинга и не имеет ответа, второй решается за пять рабочих дней и даёт цифры, с которыми можно идти к собственнику. Ниже — протокол, по которому мы такие сравнения проводим, и форма таблицы, в которую они сводятся.

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

Все суммы — модельные расчёты на прозрачных вводных. Ставки: инженер 3 000 ₽/час, предметный специалист 900 ₽/час, оператор 700 ₽/час, руководитель 2 500 ₽/час. Цены за токены взяты порядком величины — 0,20 ₽ за 1 000 входных и 0,60 ₽ за 1 000 выходных; подставьте прайс своего провайдера на дату расчёта.

Почему мы не публикуем рейтинг

Любая опубликованная таблица «модель А против модели Б» имеет срок годности и область применимости, и обычно ни то, ни другое рядом с таблицей не написано. Причин, по которым чужой рейтинг нельзя переносить на свой проект, четыре, и все они проверяемые.

• Версии живут кварталами. За время, пока статья с рейтингом выходит в топ выдачи, у половины участников появляется новая версия — и порядок мест меняется.
• Имя модели не равно модели. Провайдер обновляет её под прежним псевдонимом, и система, которая вчера давала 3% ошибок, сегодня даёт 6% без единой правки с вашей стороны.
• Ваши данные не участвовали в тесте. В бенчмарке нет ваших артикулов, ваших сокращений, ваших сканов с печатью поверх строки и ваших пятнадцати внутренних правил, которые сотрудник знает наизусть.
• Средняя точность скрывает главное. Две модели с одинаковой точностью 90% могут различаться втрое по доле ошибок, которые стоят денег, — а в отчёте это одна и та же цифра.

Пять задач, на которых имеет смысл сравнивать

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

Обратите внимание на последний столбец: он превращает сравнение из технического упражнения в управленческое. Именно цена ошибки определяет, какую метрику считать главной. На извлечении реквизитов вас интересует не средняя точность, а доля неверных сумм — потому что одна ошибка в сумме стоит дороже, чем двадцать ошибок в поле «срок оплаты». На карточках товаров наоборот: потерянная характеристика правится редактором за минуту, а выдуманное свойство доходит до покупателя.

Почему бенчмарк не равен рабочей задаче

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

• Чистота входа. В тесте — вычитанный текст, у вас — скан с наклоном в три градуса, письмо без пунктуации и расшифровка звонка, где половина реплик наложена друг на друга.
• Глоссарий. «Отгрузка», «резерв», «под заказ» и артикул «КР-140/2» в вашей компании значат конкретные вещи. Модель этого не знает и подставляет общеязыковое значение.
• Длина контекста. Тестовое задание умещается в пару абзацев, ваш запрос несёт пять фрагментов базы и историю диалога. Качество на длинном контексте деградирует иначе, чем на коротком, — и у разных моделей по-разному.
• Формат ответа. Вам нужен разбираемый программой JSON с обязательными полями. В тесте оценивается смысл свободного текста, и сломанная скобка ошибкой не считается.
• Отказ от ответа. В бенчмарке отказ — это потерянный балл. В вашем процессе честное «не знаю» на вопрос вне базы дороже золота, потому что оно предотвращает выдумку.
• Вес ошибок. Тест считает все ошибки одинаковыми. У вас они различаются на два порядка по стоимости, и модель-победитель по среднему может проигрывать по деньгам.

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

Протокол замера: 100 примеров, эталоны, слепая оценка

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

1. 1
   1. Собрать по 100 реальных примеров на каждую задачу

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

2. 2
   2. Записать эталонные ответы силами предметного специалиста

   Правильный ответ определяет тот, кто отвечает за результат в жизни: бухгалтер по счетам, диспетчер по звонкам, старший менеджер по письмам. Это единственная часть работы, которую нельзя отдать подрядчику. Побочный результат почти всегда одинаков: на 500 примерах обнаруживается 20–40 случаев, где сотрудники сами отвечают по-разному, — и это находка про процесс, а не про модель.

3. 3
   3. Зафиксировать промпт и параметры один раз для всех

   Одинаковая инструкция, одинаковый формат ответа, одинаковые примеры в промпте, одинаковая температура генерации. Соблазн «подкрутить промпт под каждого кандидата» надо погасить: тогда вы сравниваете не модели, а качество своей подгонки. Отдельным этапом после выбора победителя промпт действительно дорабатывают под него — но это уже не сравнение.

4. 4
   4. Прогнать двух-трёх кандидатов и записать версии дословно

   Три кандидата — практический предел: объём оценки растёт линейно, а решение от четвёртого не меняется. Версия модели и дата прогона записываются в отчёт из ответа API, а не по памяти. Заодно фиксируется техника: сколько запросов упало по таймауту, сколько пришлось повторить, какая была худшая задержка.

5. 5
   5. Оценить вслепую

   Ответы обезличиваются и перемешиваются: оценщик не знает, где чей. Без этого оценка съезжает в сторону ожиданий — эффект устойчивый и заметный. На 20% выборки полезно провести перекрёстную проверку вторым оценщиком: если два человека расходятся чаще, чем в одном случае из десяти, значит, размыт критерий правильности, и его надо уточнять до продолжения.

6. 6
   6. Считать критические ошибки отдельной строкой

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

7. 7
   7. Свести в один отчёт и датировать

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

Пять ошибок, которые обесценивают замер

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

1. 1Промпт подкручивали под каждого кандидата. Самая частая и самая незаметная ошибка: инженер честно старается выжать максимум из каждой модели — и в результате сравниваются не модели, а его старания и запас времени. Инструкция, формат ответа и примеры в промпте должны быть общими и лежать в отчёте дословно. Доработка под победителя — отдельный этап после выбора.
2. 2Примеры выбирал тот, кто делает систему. Люди неосознанно берут случаи, на которых система работает: чистые сканы, типовые вопросы, вежливых клиентов. Правильно — случайная выборка из реального потока за период плюс заранее объявленная квота трудных случаев: скажем, 20% пограничных категорий, кривых сканов и вопросов вне базы. Квота фиксируется до того, как кто-либо увидел первые результаты.
3. 3Оценивал ответы автор промпта, зная, где чей. Эффект ожиданий устойчив и заметен: свой кандидат получает более мягкую трактовку в спорных случаях, а спорных случаев в любом замере — от десятой до пятой части. Обезличивание и перемешивание ответов занимают десять минут скриптом и снимают проблему полностью.
4. 4Кандидатов мерили в разное время и по разным версиям. Прогон должен уместиться в одно окно, лучше в один день, а версия каждой модели — быть записана дословно из ответа API. Иначе через месяц невозможно понять, отличаются кандидаты между собой или отличается июньская версия от сентябрьской.
5. 5Мерили только точность и не считали деньги и время. Кандидат-победитель по качеству вполне может оказаться в четыре раза дороже на вашем профиле запросов и вдвое медленнее в худшем случае. Стоимость тысячи обращений и худшая задержка считаются в том же прогоне — данные для этого уже есть, добавить их в отчёт стоит полчаса.

Есть и шестая ошибка, организационная: замер поручают подрядчику целиком, включая эталонные ответы. Подрядчик не знает, что в вашей компании считается правильным ответом на письмо от проблемного клиента или какой срок отгрузки допустимо назвать. В результате измеряется соответствие модели представлениям подрядчика, а не вашим. Эталоны — единственная часть работы, которая обязана остаться внутри.

Кого имеет смысл ставить в сравнение на сентябрь 2026

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

Разумный набор для замера — три кандидата: две облачные модели разных уровней и одна локальная. Локальную стоит включать, даже если вы не планируете свой контур: она бесплатна на этапе теста, ставится на арендованной GPU-машине за пару часов и даёт понятный ответ на вопрос собственника «а если через год придётся всё увезти к себе». Про зарубежные модели: прямая оплата из России для OpenAI и Anthropic невозможна, доступ идёт через посредников, и в производственный контур мы такую схему не закладываем — но как верхнюю точку отсчёта на этапе замера её иногда используют, помня, что это не вариант поставки.

Форма отчёта: семь строк, которые показывают собственнику

Результат замера должен помещаться на одну страницу и читаться человеком, который не занимается ИИ. Ниже — форма: слева строки отчёта, дальше как считается каждая и что в ней должно насторожить. Колонки под кандидатов добавляются справа; сколько кандидатов — столько колонок.

Читать таблицу нужно в определённом порядке, и он не совпадает с интуитивным. Сначала строка критических ошибок: кандидат с превышением порога выбывает, какими бы ни были остальные цифры. Потом устойчивость формата — она определяет, сколько инженерной обвязки придётся дописать. Потом деньги на вашем объёме. И только потом общая точность, потому что разница в два-три пункта почти всегда дешевле, чем разница в любом из первых трёх пунктов.

Сколько стоит замер и что он окупает

Полный протокол на пять задач — это 500 примеров, 1 500 оцененных ответов и пять рабочих дней. Основная нагрузка ложится не на инженера, а на предметного специалиста: 30 часов его времени и есть главная статья, и её нельзя ни сократить, ни передать наружу.

Теперь другая сторона весов. Допустим, выбор сделан по обзору в интернете и оказался неудачным: кандидат, который проиграл бы в замере, даёт на 4 процентных пункта больше ответов, требующих ручной правки, и на 0,3 пункта больше критических ошибок. Поток — 12 000 обращений в месяц, что для компании на 100–150 человек с клиентским потоком совершенно обычно.

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

Что мы устойчиво наблюдаем — и чего не утверждаем

Ниже — наблюдения из наших замеров и разборов чужих внедрений. Это не рейтинг и не измеренная статистика рынка: мы не называем победителей и не переносим свои результаты на ваши данные. Но повторяющиеся закономерности стоит знать до того, как вы начнёте собственное сравнение, — они экономят один-два дня.

• Русский язык и деловой тон — самая ровная зона. Отечественные линейки уверенно держат падежи, канцелярские обороты и структуру делового письма; переводные решения здесь чаще звучат неестественно. На задачах вроде резюме звонка или ответа клиенту разница между кандидатами обычно невелика.
• На коротких структурных задачах кандидаты идут вплотную. Классификация по десятку категорий и извлечение полей из типовой формы редко расходятся больше чем на несколько пунктов — и выбор в итоге решают цена обращения и лимиты, а не качество.
• Строгий формат ломают все, вопрос только в доле. На длинной серии запросов любая модель периодически выдаёт невалидный JSON или лишний текст вокруг него. Валидатор ответа и автоматический повтор — обязательная часть контура, а не признак плохой модели; закладывайте на это 6–10 часов работы.
• Длинный контекст деградирует к концу документа. Заявленная длина окна означает, что документ поместится, а не что модель одинаково внимательна на первой и на тридцатой странице. На договорах надёжнее резать текст на части и собирать ответ из фрагментов, чем полагаться на большое окно.
• Отраслевая терминология и артикулы бьют всех одинаково. Прирост от глоссария и словаря синонимов почти всегда больше, чем прирост от перехода на более сильную модель, и стоит в разы дешевле.
• Арифметику нельзя доверять модели. Извлечь числа — да, сложить их — нет: считать должна программа. Это не особенность конкретной линейки, а общее свойство класса.
• Готовность честно отказаться различается заметно. Одни модели легче говорят «не знаю», другие достраивают ответ до последнего. Поведение подстраивается инструкцией и ограничителями, но исходную склонность стоит померить отдельной строкой — она предсказывает, сколько сил уйдёт на контур.

Чего мы не утверждаем: что какая-то из линеек лучше в целом; что наши наблюдения воспроизведутся на ваших документах; что всё написанное останется верным после следующего обновления моделей. Любая из этих закономерностей проверяется вашим замером за пять дней — и именно поэтому мы отдаём протокол, а не таблицу победителей.

Когда сравнение проводить не надо

Замер стоит денег и пяти дней чужого времени, поэтому у него есть условия применимости. В четырёх случаях он не окупится, и мы прямо говорим об этом до начала работ.

• Выбор предопределён требованием. Если у вас специальные категории персональных данных, требование заказчика по размещению или госконтракт с условием по реестру отечественного ПО — сравнивать облачных кандидатов бессмысленно, вариант остаётся один. Меряйте сразу локальную модель на своём железе и на тех же примерах.
• Объём меньше порога. При 500 обращениях в месяц разница между кандидатами в деньгах — сотни рублей, а в ручных правках — единицы случаев. Берите ту модель, которая проще подключается и от которой дешевле уйти, и потратьте эти пять дней на процесс.
• Некому дать эталоны. Если в компании нет человека, который скажет, какой ответ правильный, замер выродится в вкусовщину. Сначала нужно договориться внутри о критерии правильности — сам по себе этот разговор часто ценнее сравнения.
• Задача решается правилами. Маршрутизация по региону и сумме, разбор структурированной выгрузки, сверка справочников — это программа на несколько часов работы, а не модель. Мы регулярно закрываем такие запросы отказом от ИИ и считаем это нормальным результатом диагностики.

Как повторять замер, чтобы он не устарел

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

1. 1Раз в квартал — плановый прогон регрессионного теста на текущей версии модели. Час работы, результат подшивается к отчёту с датой.
2. 2При каждом уведомлении провайдера об обновлении модели — внеплановый прогон в тот же день. Если провайдер обновляет модель без уведомления, прогон делается по факту заметного изменения поведения.
3. 3При расширении задачи — добавление новых примеров в набор. Появился новый тип документа или новая категория обращений — 20–30 примеров дописываются к существующим.
4. 4Раз в год — полное пересравнение с двумя-тремя кандидатами. За год линейки меняются настолько, что решение годовой давности перестаёт быть обоснованным, даже если система работает.
5. 5Всегда — хранить набор примеров с эталонами как актив компании. Он переживает и модель, и подрядчика, и является единственной вещью в проекте, которая не устаревает.

Рейтинг моделей стареет за квартал, набор из пятисот ваших примеров с эталонными ответами не стареет никогда. Именно он, а не выбранная модель, и есть результат этой работы.