Когда компания решает внедрить искусственный интеллект, один из первых вопросов — какую модель выбрать. На рынке десятки решений, регулярно выходят новые версии, а разработчики публикуют результаты тестов, в которых их модели превосходят конкурентов. Кажется, что достаточно открыть актуальный рейтинг, сравнить качество, скорость и стоимость, выбрать лидера и приступить к внедрению.
На практике всё сложнее. Модель, которая занимает первое место в универсальном рейтинге, не обязательно будет лучше остальных обрабатывать счета, отвечать клиентам или искать информацию во внутренних документах компании. И наоборот: более простая и дешёвая модель иногда показывает лучшие результаты на конкретной задаче.
Проблема в том, что публичные рейтинги и реальные бизнес-процессы измеряют разные вещи. В рейтинге оценивают способности модели, а бизнесу нужен предсказуемый результат: правильно обработанный документ, корректный ответ клиенту, работающий код или сокращение времени сотрудника на выполнение задачи.
Поэтому выбирать стоит не самую «умную» модель, а ту, которая обеспечивает необходимое качество при приемлемых затратах, скорости и рисках. И для этого одних публичных тестов недостаточно.
Почему рейтинг не даёт однозначного ответа
Большинство популярных бенчмарков проверяют отдельные способности ИИ: математическое и логическое мышление, программирование, следование инструкциям, работу с длинным контекстом или ответы на сложные вопросы. Такие тесты полезны, поскольку позволяют оценить общий уровень модели и сократить список кандидатов.
Но высокий результат в бенчмарке не гарантирует качества в конкретном бизнес-процессе.
Например, если компания хочет автоматизировать обработку счетов, её интересует не способность модели решать сложные математические задачи, а то, насколько точно она извлекает ИНН, суммы, даты и банковские реквизиты. Для службы поддержки важнее правильно определить тип обращения, не пропустить жалобу и вовремя передать сложный вопрос человеку. Для корпоративного поиска — найти нужную инструкцию, сослаться на актуальный документ и не придумать информацию, которой в источниках нет.
Даже результаты самих публичных тестов нужно интерпретировать осторожно.
В одном из открытых исследований сравнили показатели, опубликованные разработчиками моделей, с результатами независимых тестировщиков. Из более чем полутора тысяч результатов удалось сопоставить 611 пар измерений по 180 моделям и 103 тестам. Средняя относительная разница составила около 6,4% в пользу результатов разработчиков, а медианная — примерно 1,2%.
Это не означает, что разработчики намеренно завышают показатели. Расхождения могут возникать из-за разных версий моделей, настроек, бюджета рассуждений, программного окружения или особенностей тестовых наборов. Тем не менее сравнение показывает важную вещь: одинаковое название теста ещё не означает одинаковые условия его проведения.
Получается, что даже в стандартизированных проверках результаты могут различаться. В реальной бизнес-системе, где на качество влияют документы, интеграции, инструкции и особенности процесса, различий будет ещё больше.
Поэтому рейтинг имеет смысл использовать как инструмент предварительного отбора, но не как основание для окончательного решения.
Начинать нужно с задачи, а не с модели
Главная ошибка при выборе ИИ — сначала искать наиболее сильную нейросеть, а уже потом думать, куда её применить.
Гораздо продуктивнее двигаться в обратном направлении: определить конкретный процесс, который компания хочет автоматизировать, описать ожидаемый результат и только после этого сравнивать подходящие модели.
Причём для разных процессов критерии качества будут принципиально отличаться.
Обработка документов. Представим, что компания хочет автоматически извлекать данные из входящих счетов. Система получает PDF и должна вернуть структурированный набор полей: название организации, ИНН, дату, номер документа, сумму, банковские реквизиты и список позиций.
Одна модель может подробно и грамотно пересказывать содержание документа, но периодически путать расчётный и корреспондентский счета. Другая хуже справляется с генерацией текста, зато стабильно извлекает нужные реквизиты. Для этой задачи второй вариант будет предпочтительнее.
Оценивать результат нужно по каждому обязательному полю: правильно извлечено, извлечено с ошибкой, не найдено или выдумано. На контрольной выборке из ста документов уже можно получить первичную картину качества и увидеть систематические проблемы.
Однако средней точности недостаточно. Допустим, модель правильно заполняет 97% полей. На первый взгляд это отличный показатель. Но если оставшиеся 3% ошибок приходятся преимущественно на суммы, банковские счета и идентификаторы, такая система может оказаться непригодной для автоматической обработки.
Поэтому ошибки необходимо разделять по последствиям. Неправильно извлечённый комментарий и ошибка в платёжном реквизите не должны иметь одинаковый вес при принятии решения.
Клиентская поддержка. Здесь часто оценивают качество сгенерированного ответа: насколько он понятный, грамотный и вежливый. Но хороший текст сам по себе не гарантирует правильной работы системы.
Бот может убедительно ответить на вопрос, который должен был передать специалисту. Может не распознать жалобу, неверно использовать историю переписки или раскрыть сведения, которые клиенту не предназначались.
Поэтому при тестировании поддержки нужно оценивать не только содержание ответа, но и весь сценарий обслуживания: правильность классификации обращения, маршрутизацию, соблюдение ограничений, работу с контекстом и своевременную передачу человеку. В некоторых процессах доля опасных ошибок гораздо важнее литературного качества текста.
Корпоративный поиск и RAG. В системах, которые отвечают на вопросы по внутренним документам, качество зависит не только от языковой модели. Ошибка может возникнуть раньше: поисковый компонент не нашёл нужный файл, выбрал устаревшую версию инструкции или передал модели неполный фрагмент документа.
Даже самая сильная модель не сможет корректно ответить на вопрос, если ей не предоставили необходимые сведения.
Поэтому здесь важно отдельно проверять качество поиска и качество формирования ответа. Сначала выяснить, получила ли система правильные источники, а затем — насколько точно модель использовала найденную информацию. Без такого разделения можно бесконечно менять модели, хотя настоящая проблема находится в поиске или подготовке контекста.
Разработка программного обеспечения. В программировании тоже легко выбрать неправильную метрику. Модель может быстро генерировать большие объёмы кода, но это ещё не означает, что она ускоряет разработку.
Бизнесу важнее знать, какая доля задач проходит автоматические тесты и код-ревью, сколько исправлений требуется после генерации, возникают ли дефекты после внедрения и сколько времени инженер тратит на проверку результата.
Если ИИ написал тысячу строк за пять минут, а разработчик затем два часа разбирается в ошибках и переписывает архитектуру, экономия оказывается сомнительной. Измерять нужно полный цикл — от постановки задачи до принятого результата, а не скорость появления кода на экране.
Все эти примеры приводят к одному выводу: универсальной метрики качества для бизнес-задач не существует. Её необходимо определять исходя из того, какую работу выполняет система и сколько компании стоит неправильный результат.
Как организовать объективное тестирование
Чтобы сравнение моделей не превратилось в соревнование субъективных впечатлений, компании нужен собственный контрольный набор задач.
Это могут быть реальные счета и договоры, обезличенные обращения клиентов, вопросы сотрудников к внутренней базе знаний или задачи из рабочего репозитория. Использовать конфиденциальные данные в открытом виде необязательно: документы можно обезличить, а тестовую среду организовать с учётом требований безопасности.
Важно другое: примеры должны отражать реальные условия работы, а не идеальные демонстрационные сценарии.
Если в компании регулярно встречаются плохо отсканированные документы, многостраничные договоры или письма с несколькими вопросами одновременно, такие случаи обязательно должны присутствовать в выборке. Иначе тест покажет качество на упрощённой задаче, с которой система в действительности почти не сталкивается.
Не менее важно заранее определить, какой результат считается правильным. Для извлечения документов это могут быть эталонные значения полей. Для поддержки — правильная категория обращения и ожидаемое действие. Для корпоративного поиска — список документов, на которых должен основываться ответ. Для программирования — набор тестов и критерии приёмки.
Без эталона обсуждение быстро сводится к оценкам вроде «этот ответ выглядит лучше» или «кажется, модель справилась». Такие впечатления полезны при первичном знакомстве с системой, но недостаточны для бизнес-решения.
Особое внимание стоит уделить сложным и пограничным случаям. Например, документ может содержать противоречивые сведения, клиентское обращение — несколько намерений, а в базе знаний может вообще не быть ответа на поставленный вопрос.
Последний сценарий особенно важен. Хорошая ИИ-система должна уметь не только отвечать, но и распознавать ситуации, в которых автоматический ответ недопустим.
Если значение реквизита невозможно определить, лучше вернуть статус «не найдено», чем подставить правдоподобное число. Если документы противоречат друг другу, система должна сообщить о конфликте. Если для решения недостаточно информации — запросить уточнение или передать задачу сотруднику.
Поэтому в тестовом наборе должны быть примеры, где правильное поведение модели — не генерировать ответ или отказаться от автоматического действия.
Для оценки можно комбинировать несколько методов. Точные значения, числовые поля, форматы и выполнение программных тестов лучше проверять обычным кодом. Более субъективные характеристики, например полноту делового ответа или понятность объяснения, можно предварительно оценивать с помощью другой языковой модели. При этом важные решения и критичные ошибки должны проверяться человеком или надёжными формальными правилами.
Наконец, необходимо различать тестирование отдельной модели и тестирование готовой системы.
В реальной эксплуатации между входными данными и итоговым ответом могут находиться OCR, поиск, конвертация файлов, промпты, внешние сервисы, базы данных и несколько последовательных вызовов ИИ. Ошибка в любом из этих компонентов способна испортить результат даже при хорошей работе самой модели.
Поэтому полезно проводить два уровня проверки. Первый показывает способности модели в контролируемых условиях. Второй — качество всей производственной цепочки, с которой столкнётся пользователь.
Такой подход позволяет понять не только то, какая модель лучше, но и где именно возникают ошибки.
Качество — только часть экономики решения
После оценки точности появляется следующий вопрос: сколько компания готова платить за дополнительное качество?
Предположим, модель A успешно выполняет 96% задач, а модель B — 94%. При этом первая обходится в пять раз дороже.
Означает ли это, что модель A лучше для бизнеса? Не обязательно.
Если речь идёт о критичных финансовых операциях, разница в два процентных пункта может оправдывать значительно более высокую стоимость. Но если модель готовит черновики писем, которые в любом случае проверяет сотрудник, более дешёвое решение может оказаться экономически выгоднее.
Здесь важно учитывать не только стоимость API-запроса, но и стоимость всего процесса: повторной обработки, ручных исправлений, проверки сотрудником и устранения последствий ошибок.
Дешёвая модель, ответы которой приходится постоянно переделывать, в итоге может обходиться дороже качественной. И наоборот, небольшое снижение точности может дать существенную экономию, если ошибки легко обнаруживаются и исправляются.
Аналогичная ситуация со скоростью. Технические обзоры часто сравнивают количество генерируемых токенов в секунду, но сотрудника интересует время получения готового результата.
Модель может быстро генерировать текст, но долго обрабатывать входной контекст. Или работать как часть агента, который последовательно обращается к нескольким инструментам. В результате каждый отдельный шаг выполняется быстро, а вся задача занимает слишком много времени.
Поэтому стоит измерять полную задержку от запроса до результата, а также поведение системы при одновременной работе нескольких пользователей. Для бизнес-процесса с большим потоком обращений это может оказаться важнее максимальной скорости генерации.
Отдельно нужно тестировать работу с длинными документами. Заявленное окно контекста в 100 или 200 тысяч токенов ещё не гарантирует, что модель одинаково хорошо использует информацию в начале, середине и конце большого текста.
Если система предназначена для анализа договоров, технической документации или программных репозиториев, нужно проверить, насколько стабильно она находит и учитывает важные условия при разном расположении информации.
Ещё один вопрос — выбор между облачной и локальной моделью. Его часто обсуждают как принципиальное архитектурное решение, хотя здесь также полезнее начинать с прикладного теста.
Обе модели должны выполнять одинаковые задачи на сопоставимых данных. Затем для облачного варианта оцениваются стоимость API, задержки, доступность сервиса, ограничения поставщика и условия обработки данных. Для локального — оборудование, энергопотребление, сопровождение, обновления и производительность под нагрузкой.
У локальной модели может быть преимущество в контроле над инфраструктурой и данными, но это не делает её автоматически более дешёвой или качественной. Облачная модель, в свою очередь, может обеспечить высокое качество без собственной вычислительной инфраструктуры, но создавать зависимость от внешнего сервиса.
Выбор должен опираться на совокупную стоимость владения, требования безопасности и результаты тестов, а не на предпочтения в пользу определённого способа развёртывания.
Как провести пилот без большого исследовательского проекта
Для большинства компаний нет необходимости сравнивать десятки моделей и воспроизводить все публичные бенчмарки. Достаточно организовать небольшой, но правильно спроектированный пилот.
Начать стоит с короткого документа, который описывает задачу и критерии успеха.
Например, компания хочет автоматизировать извлечение реквизитов из 2 000 входящих документов в месяц. В каждом документе необходимо определить 12 полей, из которых четыре считаются критичными. Допустимая доля критичных ошибок — не более 0,5%, время обработки — до 30 секунд. При этом данные не должны использоваться внешним провайдером для обучения моделей, а стоимость одного обработанного документа должна укладываться в заданный бюджет.
Уже такие требования существенно сужают круг возможных решений.
После этого можно использовать публичные рейтинги и обзоры, чтобы сформировать короткий список из трёх-четырёх кандидатов. Например, включить в него одну сильную дорогую модель, одну более доступную, одну локальную и, при необходимости, специализированное решение.
Далее все кандидаты проходят одну контрольную выборку. Для первого пилота можно взять около ста реальных задач, включая типовые и сложные случаи. Важно обеспечить сопоставимые условия: одинаковые входные данные, единые критерии оценки, сопоставимые ограничения и заранее определённый бюджет вычислений.
При этом не всегда правильно буквально использовать одинаковый промпт для всех моделей. Разные модели могут требовать разной структуры инструкций. Поэтому полезно сначала сравнить их в единых базовых условиях, а затем отдельно проверить, улучшает ли результат настройка под конкретную модель. Главное — не подбирать условия так, чтобы искусственно помочь одному кандидату.
По итогам теста должна появиться таблица, где для каждой модели видны качество обычных и сложных задач, критичные ошибки, доля результатов без ручных исправлений, время выполнения, стоимость и объём необходимого человеческого контроля.
Например, результаты могут показать, что модель A обеспечивает максимальную точность, но стоит значительно дороже конкурентов. Модель B немного уступает ей по качеству, зато позволяет снизить стоимость обработки в несколько раз. Модель C работает локально, не требует передачи документов внешнему провайдеру, но уступает по скорости.
В такой ситуации уже можно обсуждать конкретный экономический и технологический компромисс.
Чтобы результаты оставались воспроизводимыми, нужно также фиксировать параметры тестирования: точную версию модели, системную инструкцию, настройки генерации, доступный бюджет рассуждений, объём передаваемого контекста и дату проведения теста.
Это особенно важно для облачных моделей, поведение которых может изменяться после обновлений. Если через месяц качество системы снизится, у команды должна быть возможность установить, связано ли это с новой версией модели, изменением промпта или другим компонентом.
И сам пилот не должен быть последней проверкой. После внедрения полезно регулярно прогонять контрольный набор и следить за качеством на реальном потоке задач. То, что работало на этапе выбора, не обязательно будет работать одинаково хорошо после изменений системы.
Почему иногда лучше использовать несколько моделей
Результатом пилота необязательно должен стать выбор одной универсальной модели.
Во многих случаях эффективнее распределить задачи между несколькими решениями.
Например, простая и дешёвая модель может классифицировать входящие документы, более сильная — обрабатывать сложные случаи, а критичные операции — передаваться человеку на подтверждение.
В другом сценарии локальная модель работает с конфиденциальными данными, а облачная используется для задач, где такие ограничения отсутствуют. Или недорогая модель создаёт черновик, а более мощная подключается только в ситуациях, требующих дополнительной проверки.
Подобная архитектура позволяет не платить за максимальные возможности там, где они не нужны. Однако её тоже необходимо тестировать целиком: дополнительная маршрутизация, повторные вызовы и проверки увеличивают сложность системы и могут создавать новые ошибки.
Есть и ещё один вариант, который часто упускают из виду: некоторые задачи вообще не требуют языковой модели.
Если нужно проверить формат ИНН, сравнить два числа, сложить суммы или применить однозначное правило маршрутизации, обычный программный код будет предсказуемее и нередко дешевле.
Языковые модели действительно полезны там, где есть неопределённость: неструктурированные документы, естественный язык, сложный контекст, неоднозначные формулировки и задачи, для которых трудно заранее описать все правила.
Но чем больше детерминированных операций можно вынести из модели в обычную программную логику, тем надёжнее становится система в целом.
Поэтому хороший результат внедрения ИИ — не обязательно максимальное количество задач, переданных нейросети. Иногда лучшим решением оказывается архитектура, в которой модель выполняет только ту часть работы, где она действительно создаёт дополнительную ценность.
Что бизнес должен получить в итоге
После пилота компания должна получить не абстрактный вывод о том, какая модель «умнее», а измеримую картину её работы.
Например: выбранная модель корректно обрабатывает 96% типовых документов и 91% сложных, обеспечивает точность 99,6% по критичным реквизитам, требует ручной проверки в 7% случаев, а среднее время обработки составляет 14 секунд. При переходе на альтернативную модель качество снижается на 1,5 процентного пункта, но стоимость обработки уменьшается втрое.
Это условные цифры, но именно в таком формате должно выглядеть обоснование выбора. Причём показатели необходимо сопровождать объёмом тестовой выборки и оценкой неопределённости: результат на ста документах не позволяет с высокой уверенностью судить об очень редких критичных ошибках.
Для принятия решения важно видеть не только среднюю точность, но и характер ошибок, стоимость их исправления, ограничения по данным и поведение системы при реальной нагрузке.
В таком подходе публичные рейтинги не теряют смысла. Они остаются полезным инструментом для изучения рынка, сравнения общих возможностей и предварительного отбора кандидатов. Просто им отводится правильное место в процессе принятия решения.
Бизнесу не нужна модель, которая лучше всех решает абстрактные тесты. Ему нужна система, которая надёжно выполняет конкретную работу и приносит измеримую пользу.
Это может быть правильно обработанный счёт, корректно маршрутизированное обращение, найденная инструкция, принятый разработчиком код или несколько часов рабочего времени, которые удалось сэкономить.
Поэтому главный вопрос при выборе ИИ — не «какая модель сейчас самая сильная?», а «какая модель лучше всего справляется с нашей задачей при приемлемой стоимости, скорости и рисках?».
И ответ на него обычно находится не на верхней строчке очередного рейтинга, а в результатах небольшого, хорошо организованного пилота на собственных данных.
