Обзоры и сравнения моделей
GLiNER2.5-Decide: классификация без большой модели
Fastino 24 сентября выпустила GLiNER2.5-Decide — открытую модель на 340 миллионов параметров для классификации и маршрутизации по заданной схеме. На внутреннем наборе разработчика из 17 датасетов она показала среднюю точность 60,1 % и обошла две модели на 4 млрд параметров. Работает на обычном процессоре, лицензия Apache 2.0. Для читателя главный вывод не в цифре, а в классе задачи: выбор из закрытого списка на большом потоке не обязательно гнать через большую модель по ставке за токен.
Разберём, что это за модель, насколько доверять цифрам и где проходит граница между энкодером у себя и вызовом модели по API.
Что выпустили
GLiNER2.5-Decide — энкодер для решений по схеме. Вы даёте текст и набор типизированных вопросов, у каждого вопроса — список допустимых ответов. Модель возвращает выбранный ответ, распределение вероятностей и признак того, выполняется ли вся схема целиком.
Ключевые характеристики из анонса разработчика:
| Характеристика | Значение |
|---|---|
| Размер | 340 млн параметров |
| Лицензия | Apache 2.0 |
| Где работает | на процессоре, в закрытом контуре |
| Задержка на короткий текст, процессор 48 ядер | около 167 мс |
| Задержка на короткий текст, видеокарта | 38–47 мс в зависимости от карты |
| Средняя точность на наборе разработчика | 60,1 % |
Как читать цифру 60 %
Здесь важна честная интерпретация, иначе вывод получится неверным.
Набор внутренний: разработчик собрал 5100 примеров из 17 датасетов — обращения в поддержку, маршрутизация заявок, банковские и медицинские запросы, тональность отзывов, темы новостей. Решение засчитывается, только если выбранный набор меток в точности совпадает с эталоном.
60,1 % — лучший средний результат среди сравниваемых. Модели на 4 млрд параметров набрали 57,5 % и 56,4 %, другие энкодеры — 49,0 % и 46,6 %. Лидирует модель в 9 из 17 датасетов, особенно сильно — в определении намерения обращения: 75,3 % в поддержке и 64,3 % в банковских запросах.
Но 60 % — это ещё и почти 40 % несовпадений. Для закрытых задач с чёткими классами точность будет выше, для размытых — ниже. Сам разработчик отдельно оговаривает, что это внутренний набор и что одна из сравниваемых моделей — открытое воспроизведение, а не оригинал.
Вывод: модель интересна не абсолютной цифрой, а тем, что маленький специализированный энкодер обходит большие генеративные модели на этом классе задач. Переносить 60 % на свою задачу нельзя — нужно мерить.
Чем энкодер отличается от языковой модели
Не генерирует текст. Это главное отличие, и из него следуют все преимущества.
Ответ всегда из списка. Модель не может вернуть «я думаю, это скорее всего жалоба, но возможно и вопрос». Она выставляет оценку каждому допустимому ответу, выбирается лучший.
Вероятности вместо уверенного тона. У каждого ответа есть число. Можно поставить порог: ниже порога — отправить человеку или в большую модель.
Согласованность нескольких решений. Схема может задавать правила между ответами: если найдена угроза, вердикт обязан быть «небезопасно». Разработчик приводит пример, где раздельные решения противоречили друг другу, а совместное — нет.
Скорость. Десятки миллисекунд вместо секунд.
Когда это дешевле вызова модели по API
Считать нужно не ставку, а весь контур.
Энкодер у себя выгоднее, когда поток большой, список ответов закрытый и стабильный, а задержка критична. Стоимость запроса — это ваше железо, и на миллионах однотипных решений разница с оплатой токенов становится заметной.
Вызов по API выгоднее, когда поток небольшой или неравномерный. Модель нужно развернуть, обновлять, мониторить, дообучать при смене схемы. Для сотни запросов в день это дороже, чем платить за токены: на дешёвой позиции тысяча классификаций стоит копейки.
Классификация по закрытому списку на дешёвой позиции каталога — это вход в сотни токенов и ответ в несколько токенов. Как это устроено через API, разобрано в материале классификация текстов нейросетью.
Когда энкодер не подходит
Четыре случая.
Открытый список ответов. Если классы появляются по ходу работы, схему придётся постоянно менять.
Нужен развёрнутый ответ. Энкодер выбирает, а не пишет. Объяснение, черновик ответа клиенту, пересказ — это генеративная задача.
Редкие классы без примеров. Большая модель может разобраться по описанию класса. Специализированному энкодеру для этого нужны данные.
Язык. Модель заявлена для работы по схеме, но качество на русском языке в анонсе не измерялось. Прежде чем внедрять, это надо проверить на своих данных.
Практичный вариант: связка
Самая полезная схема на практике — не выбор между подходами, а их сочетание.
Энкодер разбирает весь поток и для каждого решения выдаёт уверенность. Всё, где уверенность выше порога, обрабатывается сразу. Всё, где ниже, уходит в большую модель через API вместе с исходным текстом. Дорогие вызовы тратятся только на трудные случаи, а основной поток идёт почти бесплатно.
Это та же идея, что и маршрутизация между дешёвой и дорогой моделью, только первый уровень — не языковая модель, а классификатор. Про маршрутизацию подробнее — в материале маршрутизация между моделями.
Для второго уровня нужен доступ к моделям, которые разберутся в неочевидном. KeyDealer даёт один ключ на 56 позиций каталога, 44 из них доступны сейчас, с оплатой российской картой в рублях и ставками от 1 ₽ за миллион токенов. Для классификации по описанию без примеров подходит и бесплатная позиция gpt-oss-20b — она открывается после первого платного пополнения.
Какие задачи разработчик называет подходящими
В анонсе перечислено семь сценариев. Полезно пройтись по ним, потому что половина из них — не про классификацию в привычном смысле.
Маршрутизация запросов. Куда отправить обращение, насколько оно сложное, нужна ли эскалация. Это классический случай для закрытого списка.
Выбор инструмента. Из разрешённого набора инструментов выбрать нужный и вытащить аргументы из запроса. Для агента это первый шаг, который можно сделать без большой модели.
Следующее действие в браузере или интерфейсе. Оценить текущее состояние экрана и выбрать действие из списка.
Защитные проверки. Безопасность запроса, тип угрозы и необходимость эскалации — вместе и согласованно, с вырезанием подозрительного фрагмента дословно.
Сокращение контекста. Решить, какие части текста относятся к делу, и вернуть их точные границы.
Оценка ответа другой модели. Критерии оценки как вопросы с фиксированными значениями, вместо просьбы к большой модели «оцени по шкале».
Игры и симуляции. Намерение, действие, исход — по состоянию игры.
Для нашего читателя самые интересные — первые два и защитные проверки: это именно те места, где сейчас обычно тратят вызов большой модели на решение, которое укладывается в выбор из списка.
Почему это касается бюджета
Коротко про арифметику, без придуманных чисел.
В типичной системе поддержки на каждое обращение приходится один-два служебных вызова модели до основного ответа: определить тему, проверить, не нужна ли эскалация, отсечь постороннее. Каждый такой вызов — это системная инструкция, текст обращения и короткий ответ. На дешёвой позиции это копейки за штуку, но на сотнях тысяч обращений в месяц складывается в заметную строку.
Если эти решения переходят к локальному классификатору, служебные вызовы исчезают из счёта целиком, а большая модель остаётся только для основного ответа и для случаев с низкой уверенностью. Насколько это выгодно именно вам, покажет журнал: посмотрите, какая доля вызовов — служебные решения из закрытого списка.
Как проверить на своих данных
Порядок из четырёх шагов.
Шаг первый: соберите двести реальных примеров с правильными ответами. Не синтетику, а то, что уже размечено людьми.
Шаг второй: прогоните через энкодер и через дешёвую позицию по API. Одинаковый список меток, одинаковые примеры.
Шаг третий: сравните точность по классам, а не среднюю. Средняя прячет классы, на которых модель проваливается.
Шаг четвёртый: посмотрите на распределение уверенности. Если у энкодера большая доля ответов с высокой уверенностью и они почти всегда верны — связка «энкодер плюс API для остального» окупится.
Чего мы не утверждаем
Три оговорки.
Мы не переносим 60 % на вашу задачу. Это внутренний набор разработчика. Ваш результат может быть заметно выше или ниже.
Мы не утверждаем, что модель хорошо работает на русском. Это в анонсе не измерялось.
Мы не утверждаем, что свой классификатор всегда дешевле. На небольшом потоке обслуживание своей модели обходится дороже, чем токены. Когда задача вообще не для языковой модели, разобрано в материале как понять, что задача не для нейросети.
Что держать в голове
Первое. Выбор из закрытого списка — отдельный класс задач, и для него существуют инструменты дешевле и быстрее языковой модели.
Второе. Уверенность в ответе — ценнее самого ответа. Порог уверенности превращает классификатор в фильтр, который отдаёт сложное тому, кто справится.
Третье. Лучшая схема на большом потоке — не «или», а «и»: дешёвый первый уровень и модель по API для остатка. Что мы за проект — на странице о проекте, ключ заводится на keydealer.ru/login.
Частые вопросы
Что выпустила Fastino?
GLiNER2.5-Decide — открытую модель на 340 миллионов параметров для принятия решений по заданной схеме: классификации, маршрутизации, сортировки обращений. Лицензия Apache 2.0, модель работает на обычном процессоре и может развёртываться в закрытом контуре. Выпуск 24 сентября 2026 года.
Насколько она точная?
На внутреннем наборе разработчика из 17 датасетов и 5100 примеров средняя точность 60,1 %. Это лучший результат среди сравниваемых моделей, включая две на 4 млрд параметров. Но 60 % означает, что почти в 40 % случаев решение не совпадает с эталоном — это важно при оценке.
Чем энкодер отличается от обычной языковой модели?
Он не генерирует текст. Он получает текст и список допустимых ответов и выставляет каждому ответу оценку совместимости. Поэтому ответ всегда из заданного списка, приходит с вероятностями и не требует разбора свободного текста.
Когда такой подход выгоднее вызова модели по API?
Когда задача — выбор из закрытого списка на большом потоке: тема обращения, маршрут, срочность, тональность. Модель запускается у вас, стоимость запроса — это ваше железо, а не токены, и задержка измеряется десятками миллисекунд.
Когда он не подходит?
Когда список ответов открытый, нужен развёрнутый ответ, рассуждение, работа с редкими классами без примеров или язык, на котором модель плохо обучена. И когда поток маленький: поднимать и обслуживать свою модель ради сотни запросов в день дороже, чем платить за токены.
Можно ли совместить оба подхода?
Да, и это самый практичный вариант. Энкодер разбирает основной поток и выдаёт уверенность; всё, где уверенность низкая, уходит в большую модель через API. Так дорогие вызовы тратятся только на трудные случаи.