Как выбрать LLM для бизнеса в 2026 году
Почти у каждой топовой LLM есть бенчмарк, по которому она занимает первое место. Но привычное сравнение LLM по бенчмаркам не отвечает на главный вопрос — какую модель выбрать для конкретного бизнес-проекта.
В 2026 году модель не существует отдельно от архитектуры, пайплайна и бизнес-процесса, в который ее интегрируют. В России к этому добавляется еще и регуляторный контекст. В результате выбор LLM в 2026 году — это последовательность фильтров, большинство из которых не связаны с публичными метриками.
Чтобы понять, как бизнес выбирает модели под проекты, мы поговорили с командой LLM Arena — независимой платформой сравнения языковых моделей, которая летом 2025 года провела опрос российского бизнеса о критериях выбора LLM. Опытом также поделились эксперты из Авито, Lamoda Tech, 2ГИС и Just AI. Собрали фреймворк выбора модели из пяти шагов — от оценки данных и регуляторики до пересмотра конфигурации в продакшене.
Бенчмарк LLM — больше не главный критерий?
Исследование LLM Arena 2025 года показало: к публичным бенчмаркам в России относятся скептически. Фронтирные модели 2025–2026 годов показывают близкие к потолку результаты по академическим тестам. Когда все уходят в 90-й перцентиль, разница в полтора процента теряет смысл.
Зарубежные независимые бенчмарки тоже уперлись в потолок. Показательна история с SWE-bench: он появился еще в 2023 году, в 2024 году для оценки кодинг-способностей выпустили его разновидность SWE-bench Verified, а в феврале 2026 года OpenAI заявили, что больше не используют его для оценки моделей — из-за загрязнения данных.
Мы смотрим бенчмарки, когда выходит новая модель: это отправная точка, чтобы понять, стоит ли тратить на нее время. При работе над своими моделями мы адаптируем под русский язык англоязычные тесты — MATH-500, GPQA Diamond, DROP_RU и BFCL V3 — и выкладываем их в открытый доступ, чтобы в индустрии появлялись более честные инструменты сравнения русскоязычных моделей. Для нас публичные бенчмарки — это фильтр на входе, а реальное решение всегда принимается по результатам собственных замеров и A/B-тестов.
Запуск каждого проекта мы начинаем со сбора данных. Для тестирования гипотезы мы сначала берем самые сильные модели, чтобы понять возможность технической реализации. Если даже они не справляются — это сигнал, что задачу стоит переформулировать, сузить, решать по-другому. Позже при масштабировании пытаемся добиться сопоставимого результата с использованием моделей меньше.
Таким образом, бенчмарк сохраняет роль фильтра первичного отбора и позволяет оценить, реализуема ли задача в принципе. Но не отвечает на ключевой вопрос — какая модель должна работать в продакшене. Это решение формируется на следующих пяти этапах.
Шаг 1. Оценить данные и регуляторный контекст
В России при выборе LLM важно учитывать регуляторный контекст. Если используются персональные данные, команда будет ограничена ФЗ-152, согласно которому чувствительная информация не может уходить за границу. А значит отсекается большая часть зарубежных API. На практике у российских команд есть три варианта:
Вариант 1. Чистый датасет. Внутри нет ни персональной, ни чувствительной информации. В этом случае доступны и зарубежные модели через API или прокси, и российские облачные, и open-source — выбор широкий, и решение принимается уже по другим параметрам.
Вариант 2. Чувствительные данные. Часть информации подпадает под регуляторику. Зарубежные API отпадают, остаются российские облачные провайдеры (GigaChat, YandexGPT и другие) или open-source модели, развернутые внутри российского контура. Этот сценарий сегодня самый частый при выборе LLM для бизнеса в РФ.
Вариант 3. Закрытый контур. Если данные не должны покидать периметр в принципе, остается только локальная LLM на собственных мощностях — open-source модели в закрытом контуре, без обращений во внешний API.
В проекте по созданию AI-агента техподдержки для клиентов Lamoda мы разработали собственный бенчмарк качества вызова функций. Он собран из реальных кейсов, размеченных внутренними аудиторами, и оценивает выбор следующего действия. Параллельно на синтетических симуляциях диалогов через LLM-as-judge мы проверяли корректность вызова инструментов по траектории выполнения задачи, а также то, что агент отвечает строго на основе полученных данных и не нарушает политику компании. Тестировали модели от 3B до 35B параметров, ориентируясь на возможность локального запуска, скорость и качество вызова функций.
Иногда поле кандидатов сужает не только закон, но и сложившийся у команды подход.
Региональные ограничения формируют ряд условий, который нельзя игнорировать. У части корпоративных клиентов уже заключены контракты с российскими провайдерами LLM, и внутри компании действует единый стандарт: все проекты строятся на одной или нескольких моделях.
Другой типичный сценарий — клиент приходит с готовой инфраструктурой: например, у него уже развернуты модели QWEN определенной размерности и нет возможности расширять GPU-парк. В таких случаях мы вынуждены под него подбирать модели из имеющихся и строить архитектуру, которая обеспечит требуемое качество.
Безусловно, в большом количестве случаев разработчикам хочется использовать облачные модели: качество их работы обычно выше, чем у локальных, а инференс сразу нескольких клиентов на общем кластере видеокарт экономически обычно более целесообразен. Однако, ограничения, связанные с безопасностью, позволяют использовать этот подход далеко не всегда.
Когда регуляторика и инфраструктура отработали, у команды остается короткий список кандидатов — и дальше начинается сравнение по техническим параметрам.
Подробнее о том, как российский регуляторный контекст и оборотные штрафы за утечки влияют на работу с LLM и какие подходы к защите данных применимы, — в материале: «AI и защита данных для бизнеса».
Шаг 2. Провести сравнение LLM по параметрам
Когда учтены регуляторные требования, начинается сравнение LLM по базовым техническим характеристикам:
- Стоимость входа и выхода — сколько стоит обработка запроса и генерация ответа
- Задержка (latency) — как быстро от модели идет первый токен: для интерактивных сценариев это критично
- Скорость генерации (throughput) — сколько токенов в секунду уходит в момент ответа: это напрямую влияет на пользовательский опыт и пропускную способность системы
- Контекстное окно — какой объем информации можно подать за один запрос и с каким объемом данных модель в принципе работает.
В теории баланс ищется просто — цена пониже, задержка поменьше, скорость побольше, — но на практике у каждой характеристики есть подводные камни.
При выборе модели под конкретный продукт смотрим на три ключевых параметра: стоимость запроса, latency и размер контекстного окна. Но ни один из них не имеет смысла, если модель плохо справляется с самой задачей — поэтому финальное решение всегда принимается по качеству на наших продуктовых сценариях.
Контекстное окно: заявленный объем ≠ реальное внимание
На рынке уже есть модели с заявленным контекстом в миллион токенов, однако, как правило, внимания на весь этот миллион у нее не хватает.
Лучше всего проблему показывает бенчмарк needle-in-a-haystack («иголка в стоге сена»): в большой массив текста вставляется одна строка, и модель должна ее найти. До 100–200 тысяч токенов это работает хорошо, дальше даже фронтирные модели начинают теряться. Это ограничение текущей архитектуры LLM.
Но 100–200 тысяч — это приблизительный ориентир, и реальный порог нужно проверять под конкретную задачу. Бенчмарк needle-in-a-haystack показывает только способность найти нужный фрагмент (retrieval), а если по нему еще нужно рассуждать и сопоставлять источники, качество падает быстрее.
Скорость и стоимость: оптимизация под язык
Отдельный аспект — работа с русским языком. Стандартные токенизаторы заточены под английский и режут русский текст неэффективно: одна и та же фраза порождает больше токенов, чем ее английский эквивалент. Каждый запрос обходится дороже, а ответ приходит медленнее — и при масштабировании разница множится. Чтобы обойти это, в Авито пошли по нестандартному пути.
У нас есть и собственная линейка моделей — A-Vibe (текстовая) и A-Vision (мультимодальная). Мы сделали их на базе открытых моделей, но заменили в них токенизатор. Собственный токенизатор дал прирост скорости около 50% на русскоязычных запросах. В октябре 2025 мы выложили A-Vibe и A-Vision в открытый доступ — ими теперь может пользоваться любой желающий.
Способов обойти ограничение с русским текстом несколько, и они касаются не только выбора модели, но и архитектуры пайплайна вокруг нее.
Шаг 3. Спроектировать архитектуру вокруг модели
В 2025 в индустрии закрепилось понятие context engineering, и к 2026-му появились узкие термины вроде harness engineering. Идея context engineering в том, что важна не только сама модель, но и то, как устроен контекст вокруг нее. Нужно ли извлекать и структурировать данные перед подачей? Как выглядят вход и выход? Должна ли модель запоминать промежуточные результаты? Нужна ли оркестрация и долгосрочная память?
Из этого следует принцип: архитектура определяет выбор модели, а не наоборот. Сначала проектируется пайплайн под бизнес-задачу, и только потом под каждый его участок подбирается подходящая модель.
Пример пайплайна агента техподдержки:
|
Слой пайплайна |
Что требуется от модели |
Типовой выбор |
|
Классификация входящих запросов |
Скорость, стабильность, низкая стоимость |
Маленькая модель до 10B параметров, локально |
|
Генерация ответа |
Качество, следование инструкциям |
Сильная облачная или large open-source |
|
Проверка на соответствие политике |
Консистентность; иногда LLM не нужна вовсе |
Третья LLM либо rule-based без LLM |
Мультимодельный подход — когда в одном пайплайне работают несколько LLM под разные задачи — дает экономию токенов. Маленькая локальная LLM закрывает классификацию и проверку, а сильную облачную или корпоративную LLM команда вызывает через API там, где нужно качество.
Модели различаются не только качеством выходных данных, но и тем, как им нужно писать промпты, как строить архитектуру приложений на их основе. Без качественно подготовленного контекста даже топовые облачные модели выдают результат, непригодный для применения в продукте: общая постановка задачи приводит к общему ответу. Инженерия контекста — одна из ключевых компетенций в работе с LLM прямо сейчас, и зрелые подходы к решению этой задачи еще только формируются на рынке.
Параллельно с context engineering закрепился еще один термин — harness engineering. Он описывает уже не только подготовку контекста, но и всю среду, в которой модель выполняет задачу: инструменты, методы оценки, SDK для разработки агентов.
Сейчас технологии обучения LLM включают множество этапов: помимо базовых и доменных знаний, в них заложены еще и знания о процессах работы (например, через RLVR). По нашему опыту, воспроизведение этих процессов через правильную организацию среды оценки и использование современных SDK для разработки агентов дает больший вклад в результат, чем выбор конкретной LLM. Поэтому в индустрии появился термин harness engineering, который разделяет векторы развития самой LLM и среды вокруг нее.
Корпоративный датакаталог: следующий рубеж
Чтобы LLM стала по-настоящему полезной внутри компании, она должна уметь сама добывать информацию из ее систем — Jira, HR-сервисов, CRM, — а между моделью и данными нужен отдельный слой.
Часть этой задачи уже решена на уровне стандарта: в 2024 году Anthropic выпустила открытый протокол MCP (Model Context Protocol), который к 2026 году поддерживают все основные разработчики LLM. Он описывает, как дать модели управляемый доступ к корпоративным системам, не передавая данные наружу. Но MCP — это про как подключиться, а не про то, в каком виде данные лежат внутри.
Для эффективной работы LLM в корпоративной среде модель должна иметь управляемый доступ к ключевым системам компании — Jira, HR-системам, CRM, при необходимости — к финансовым данным. Чтобы это работало надежно, между LLM и продуктовым слоем следует реализовать отдельный промежуточный компонент — корпоративный датакаталог, а именно — семантический слой данных.
Это витрина данных, в которой информация не просто агрегирована из источников, а приведена к единому виду: консистентна, без противоречий, с явно выделенными сущностями и пояснениями о структуре. Именно на нее модель может опираться при формировании ответа — например, чтобы получить комплексную аггрегированную аналитику в разрезе по конкретному пользователю по HR-направлению из HRM, Jira и 1С.
Отдельным пунктом и тут возникает вопрос безопасности: корпоративный дата-каталог должен предоставлять доступ только к тем данным, который должен видеть конечный пользователь агента. Например, я как руководитель должен видеть свои собственные данные и данные своих подчиненных, но не должен видеть данные, относящиеся к моему вышестоящему руководителю или соседнему подразделению. Все это делает задачу построения корпоративного дата-каталога достаточно сложной и по-настоящему актуальной сейчас.
Шаг 4. Провести тестирование LLM на своих данных
Исследование LLM Arena 2025 года подтвердило: тестирование LLM на собственных evaluation-наборах респонденты считают самым надежным способом проверки. В 2026-м, когда архитектуры усложнились до многоступенчатых пайплайнов с роутерами, retrieval и проверками, тестировать приходится уже всю систему. Пользовательский запрос проходит цепочку шагов:
Пользовательский запрос → роутер направил в нужную модель → retrieval достал релевантные документы → модель сгенерировала ответ в рамках политики → ответ прошел проверку
Это означает, что eval-набор должен покрывать не только «правильный ли ответ», но и «правильно ли отработал каждый шаг пайплайна». Ошибка retrieval и ошибка генерации — это разные баги с разными решениями.
Рассматривая саму модель, стоит учитывать специфику ее обучения, а не только «красивые» показатели в бенчмарках и данные на аренах. Важно анализировать этапы обучения и данные, с которыми работают исследователи. В нашем случае модель на 8B обошла модель на 35B потому, что была лучше обучена работе с инструментами, а среда агента только усилила это преимущество.
Минимальный eval
Eval (от англ. evaluation) — оценка модели на собственном наборе задач. Полноценная система требует ресурсов на разметку, инструменты и продуктовые метрики, но минимум может собрать почти любая команда:
- Реальные задачи, не синтетические — берем те, которые модель будет решать каждый день.
- Один и тот же набор для всех кандидатов — несколько моделей прогоняем в одинаковых условиях.
- Не только качество — фиксируем стоимость прогона, скорость ответа и стабильность результатов при повторных запусках.
- Граничные случаи — отдельно проверяем длинные контексты, нестандартные запросы и данные: именно здесь модели ведут себя заметно по-разному.
Это минимальный уровень. По мере усложнения продакшен-системы eval вырастает:
|
Уровень зрелости |
Что добавляется |
|
Базовый |
50–100 золотых примеров из реальных задач, прогон всех кандидатов в одинаковых условиях, ручной аудит 5–10% продакшн-запросов |
|
Средний |
LLM-as-judge для автоматической оценки, eval встроен в CI/CD: любое изменение промпта или конфигурации запускает прогон на baseline-наборе |
|
Зрелый |
Трассировка каждого шага агента, автоматические алерты на деградацию метрик, регрессионное тестирование при любом обновлении |
Никакой внешний бенчмарк не учтет специфику вашего датасета, пайплайна и пользователей, поэтому даже минимальный eval окупается быстрее, чем стоит его сборка.
Шаг 5. Пересматривать решение регулярно
Рынок моделей меняется быстро: то, что было недоступно полгода назад, сегодня может стоить в разы дешевле и работать заметно лучше. Ниже — четыре сигнала, по которым стоит вернуться к выбору и пересмотреть текущую конфигурацию.
Качество в пользовательском сценарии падает
Если пользователь сталкивается с неожиданным или непонятным поведением системы, это уже повод задуматься. Проявления зависят от задачи и индустрии: где-то это неточный ответ, где-то — выход за рамки политики компании, нарушение прав пользователя или просто неподходящий тон.
Стоимость одного действия растет быстрее нагрузки
Когда счет от провайдера увеличивается быстрее, чем нагрузка на продукт, дело не всегда в количестве пользователей. Чаще причина в самой обвязке — добавили инструмент, расширили контекст под фичу, подключили память. Расхождение между ростом продуктовых метрик и ростом затрат — повод пересчитать архитектуру.
Появились более выгодные модели
Фронтирные модели постепенно дешевеют, и без регулярного пересмотра легко годами переплачивать за конфигурацию, оптимальную на момент запуска.
Изменились требования к безопасности
Законодательство тоже не стоит на месте: новые требования к обработке данных могут заставить перейти с зарубежного API на российский, а с облачного — на self-hosted, даже если по качеству и цене текущая модель полностью устраивает.
В 2025 году команда LLM Arena запустила VseLLM, единый API-шлюз к сотням моделей, и мы быстро увидели в данных: лояльности к конкретной модели у бизнеса почти нет. Средний активный клиент использует от 4 до 7 моделей параллельно, а 45% пользователей полностью сменили основную модель всего за один месяц. Сильные или дешевые новинки вроде GPT-5-mini и Gemini-3-Flash входят в топ-5 сервиса за первые два дня после подключения. Главный триггер переключения — появление модели, которая дает сопоставимый результат на конкретной задаче дешевле. Инфраструктура для работы с LLM должна закладывать смену модели как штатный сценарий.
Полная схема пути: от оценки датасета и регуляторики — до регулярного пересмотра конфигурации в продакшене
Итоги: от выбора LLM к зрелой AI‑инфраструктуре
Описанный фреймворк под выбор LLM для бизнеса 2026 — общая рамка. Реальная конфигурация у каждой компании своя: средний бизнес отталкивается от стоимости и скорости вывода в продукт, крупные игроки инвестируют в собственную инфраструктуру и open source LLM, стартапы работают на зарубежных API, пока это позволяет чувствительность данных.
При этом сам ландшафт LLM меняется быстрее, чем большинство внутренних процессов: дорогое решение становится индустриальной нормой за полгода, а устойчивая конфигурация так же быстро устаревает. Поэтому выбор LLM в 2026 году — это процесс, который регулярно сверяется с продуктовой задачей, рынком моделей и регуляторной средой.
Другие материалы
Где AI экономит бизнесу больше всего
Карта самых окупаемых сценариев внедрения
С чего начать внедрение генеративного AI
План внедрения генеративных технологий в бизнес‑процессы
Устройство стартапа по созданию презентаций с помощью нейросетей
Как придумать продукт на рынке генеративного искусственного интеллекта