Jev, Laya и Gemini Flash на трёх задачах классификации в поддержке

За неделю я прогнал три задачи из своего прода через модели, которые только выбирают из списка, ставят оценку по шкале или возвращают вероятность. Jev как закрытая, Laya как опенсорсный аналог, плюс gemini flash lite как третий кандидат. Две задачи из трёх они закрывают, третью не закроет ни одна, и понять это можно было до всякого замера.

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

Контекст: финтех-продукт, поддержка с потоком в несколько десятков обращений в день (пилотный замер за неделю). Заголовок называет модели прямо: иначе статью не найдут в поиске. В теле говорю «закрытая» и «открытая», чтобы не дублировать имена, и «gemini flash lite», где она идёт как альтернатива.

Задача первая: отличить осмысленный ответ от мусора

Пользователь заполняет анкету. Надо понять, ответил ли он на вопрос по теме или прислал «ааааааа», или написал про погоду.

Смок-тест открытой модели: 12 примеров на русском, английском и испанском, четыре постановки задачи. Результат 3–5 правильных из 12 при случайном угадывании 4 из 12. Доверительный интервал для пяти из двенадцати тянется от 19% до 68%. Этого хватило, чтобы не тратить на неё вечер; полноценный замер этой модели ниже, на другой задаче. Живой ответ «На созвоны, после которых ничего не меняется» модель оценила в 0,57 по осмысленности, а «ааааааа» посчитала настоящим ответом. При старте библиотека сама предупредила, что в этом чекпоинте параметры калибровки некорректны. Скорость при этом отличная, 30 миллисекунд на процессоре ноутбука без видеокарты, но скорость без точности сама по себе значения не имеет.

Тогда я взял 80 реальных ответов и прогнал их через пять быстрых моделей одного агрегатора, добавив к сравнению свой классификатор на правилах. Оговорка по времени ответа: это latency агрегатора в конкретный день, а не свойство модели.

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

Что в этих строках решает судьбу проекта. Классификатор на правилах это длина меньше N символов, плотность осмысленных слов по словарю, наличие знаков препинания, энтропия символов, проверка на стоп-фразы типа «аааа», «???», «нет ответа». 95% мусора, ноль ложных отказов, меньше миллисекунды, ноль рублей.

Цена и качество не связаны. gpt 5 nano дороже gemini flash lite в четырнадцать раз и ловит 70% против 90%.

И главное. Llama ловит весь мусор до единого, но отклоняет 7,5% живых ответов. Формально лучшая по полноте модель для нас худшая, потому что цена двух ошибок разная: пропущенный мусор это лишняя строка в базе, отклонённый живой ответ это обиженный пользователь. Выбор модели определяется политикой ошибок, а не строкой в бенчмарке. У нас лишняя строка в базе стоит примерно 0,3 рубля на ручной разбор, а обиженный пользователь это потенциальный отток и негативный отзыв. Разница в цене ошибки порядка ста раз, и это решает выбор в пользу правил и gemini flash lite.

Попутная находка. Модели с рассуждениями при лимите в двести токенов возвращают пустой ответ: весь бюджет уходит на размышления. Им нужно от от тысячи двухсот, и отсюда их медлительность. Заодно выпала одна модель с временем 5–7 секунд и ценой 0,3 $ за тысячу ответов: единичный замер в час пиковой нагрузки у провайдера, в другие дни она быстрее; в прод её не поставили, но строка осталась в полной таблице как иллюстрация того, что цифра «время» через агрегатор это в первую очередь состояние очереди.

Схема, на которой остановились: сначала правила, а всё, что они пропустили, уходит в gemini flash lite.

Задача вторая: разобрать обращения в поддержку

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

Взял 340 уникальных обращений за 7 дней. Сто двадцать ушли на калибровку, двести двадцать на тест. Одни и те же шесть вопросов задал и закрытой модели, и открытой.

Закрытая отвечает за 563 миллисекунды на все шесть задач одним вызовом и стоит 0,027 доллара за 340 обращений, то есть около пяти центов в день на нашем потоке. Открытая работает локально, секунда на обращение на процессоре, и ничего не покидает контур.

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

Наши правила ошибаются в пятнадцати-двадцати процентах случаев. Значит, согласие с ними меряет совпадение с чужими ошибками, а качество модели остаётся неизвестным. Правильная метрика здесь AUC на ручную разбору, и она даёт совсем другую картину.

Открытая модель на русском без дообучения сигнала не даёт. Значения от 0,41 до 0,46 формально ниже 0,5, но называть это «хуже случайного» было бы неаккуратно: AUC ниже половины означает инвертированный порядок, и если развернуть знак, получится от 0,54 до 0,59. Механического объяснения инверсии я не нашёл, и на такой выборке доверительный интервал всё равно накрывает 0,5. Честная формулировка: сигнала не обнаружено.

Калибровка это не чинит, и здесь есть аргумент сильнее любых замеров. Температурное шкалирование это монотонное преобразование, а AUC зависит только от порядка, поэтому калибровка температурой не меняет AUC вообще никогда. Она делает вероятности честнее, но не улучшает способность различать. Калибровка Платта с наклоном около нуля выдаёт почти константу, равную базовой доле класса, и accuracy становится равной мажоритарной. Отсюда и 94% на вопросе про рабочую переписку: ровно столько же даёт стратегия «всегда отвечай нет».

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

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

При пороге 0,8 модель нашла двадцать одно из тридцати семи таких обещаний и не дала ни одного ложного срабатывания на этой выборке. Два уточнения, без которых цифра врёт. Порог я подбирал на тех же данных, значит на новом потоке он поедет. И ноль ложных на 220 примерах это не ноль в природе: верхняя граница по правилу трёх около 1,4%, то есть до трёх ложных срабатываний на каждые двести черновиков. На нашем потоке это один-два ложных баннера в день. Оператор привыкнет и начнёт их пролистывать, поэтому детектор пойдёт как тег в карточке тикета. Тег никуда не денется, и через месяц у нас будет реальная статистика по ложным срабатываниям на проде.

Шестнадцать пропущенных обещаний из тридцати семи при таком пороге это всё ещё много. Через месяц, когда наберётся реальный поток, порог и формулировка поправятся; обещаю вернуться с цифрами.

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

Я склоняюсь ко второму, и через пару абзацев будет третья задача, где ровно та же ошибка повторяется в чистом виде.

Задача третья: предсказать, хватит ли данных на ответ

Здесь я ошибся постановкой задачи.

Идея выглядела разумной. Если бы мы умели заранее понимать, что на вопрос клиента в базе знаний нет ответа, можно было бы сразу вести человека к оператору и не тратить вызов генерации.

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

Обратите внимание на последнюю строку. Длина текста и наличие вопросительного знака дают 0,56. На её фоне 0,67 перестаёт выглядеть результатом. Базовую линию в обзорах моделей почти никогда не считают. Зря: она сразу показывает, есть ли вообще сигнал.

Здесь, в отличие от первых двух замеров, выборки хватает: на трёх тысячах примеров разрыв между 0,67 и 0,56 реален, а не шум.

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

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

Это та же ошибка, что и с вопросом «можно ли отправить черновик». В обоих случаях модель не видит того, от чего зависит правильный ответ, и в обоих случаях метрика честно показывает монетку. Модель тут ни при чём.

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

Оговорки, без которых эти цифры врут

Перечисляю сам, чтобы не делать вид, что замер чище, чем он есть.

Размеры выборок маленькие. Двенадцать примеров в первом подходе это смок-тест. Восемьдесят во втором дают доверительные интервалы порядка десяти процентных пунктов, поэтому соседние строки таблицы между собой неразличимы. Двести двадцать в третьем позволяют говорить о разнице между 0,5 и 0,9, но не между 0,84 и 0,90. Семь тысяч вопросов в третьей задаче, единственная выборка, на которой разрыв между моделью и базовой линией статистически реален.

Разметка не золотая. Правду по расхождениям определял я один, без второго разметчика и без слепого режима, зная при этом ответ модели. Это лучше, чем сравнение с эвристиками, но потолок точности здесь упирается в моё собственное согласие с собой.

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

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

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

Пилот, не годовой средний. Все цифры по обращениям за неделю в конце сентября 2026; на другом срезе доля обещаний и тематика будут другими.

Рамка: какие задачи можно отдать быстрой модели

Шесть признаков, по которым я теперь смотрю на задачу до того, как что-то замерять.

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

Второй. Ответ выводится из самого текста, без предметных знаний. Вопрос «обещает ли этот черновик человека» решается, вопрос «верен ли этот ответ» нет.

Третий. Исходы перечислимы заранее, и их список стабильный. На двенадцати темах ошибка калибровки у закрытой модели 0,40, на бинарных вопросах от 0,06 до 0,10. Сравнивать эти числа между собой строго не нельзя, метрика зависит от числа классов, и порядок величин говорит сам за себя: чем длиннее список вариантов и чем сильнее он меняется от запроса к запросу, тем меньше можно верить уверенности.

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

Пятый. Задача возникает на каждом обращении в горячем потоке, а не раз в месяц по выборке. Иначе проще дождаться обычной LLM с её качеством и не плодить инфраструктуру.

Шестой. У вас есть разметка или эвристики, чтобы измерить AUC. И к ним обязательно ручной разбор расхождений, иначе вы померите совпадение с собственными ошибками. Это требование к процессу внедрения, а не к самой задаче; без него рамка не работает.

Почему я не стал дообучать открытую модель

Отложил, и только одна из трёх причин про ресурсы.

Учить не на чем. Наши метки это эвристики, которые ошибаются в пятнадцати-двадцати процентах, и дообучение на них даст дорогую копию регулярки вместе с её ошибками.

Часть задач поставлена неверно, и дообучение постановку не исправит.

И только новая причина: нужен GPU на несколько часов, и его нет.

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

Что в итоге внедряем

Детектор обещаний человека на закрытой модели, за фичефлагом, порог 0,8, при недоступности API остаются старые маркеры. Это закрывает семнадцать процентов обещаний в нашем пилотном потоке, и стоит около пяти центов в день. Как поймать момент, когда порог поехал: следить за долей подсвеченных карточек, которые оператор открыл без последствий; если больше половины открытий заканчиваются ничем, порог занижен или модель деградировала.

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

Валидацию пользовательского ввода двухступенчато: правила, а сверху gemini flash lite на остатке.

Проверку достаточности данных переносим на пару «вопрос и кандидаты» и меряем порог реранкер.

Не делаем оценку того, можно ли отправить черновик как есть. Ни одна из моделей не знает, верен ли ответ по существу.

Через месяц вернусь с цифрами по внедрённому детектору: сколько обещаний он поймал на реальном потоке, сколько раз ошибся и поехал ли порог.

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

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