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

Сначала измеряем работу, а не размер модели

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

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

Это не абстрактная осторожность. В официальной русскоязычной документации GigaChat быстрый класс модели отнесён к более простым задачам и меньшим аппаратным ресурсам, а Pro и Max — к более сложным инструкциям и задачам, где важнее качество. Страница выбора модели не превращает это в универсальный рецепт: она прямо связывает выбор с задачей. В той же линейке опубликованы разные показатели Lite, Pro и Max, в том числе по ruMMLU, Arena-Hard RU, следованию инструкциям и программированию. Сравнение метрик и стоимости полезно читать не как таблицу победителей, а как напоминание: «облегчённая» и «более сильная» модели отличаются не одной шкалой.

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

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

Почему узкий сценарий и открытый помощник — разные решения

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

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

Исследование Enterprise Benchmarks for Large Language Model Evaluation показывает, почему перенос общего бенчмарка в корпоративную задачу ненадёжен: авторы собирают разные enterprise-наборы и фиксируют различия результатов моделей по предметным типам работы. Это не российская норма и не доказательство результата в конкретной организации. Но методический вывод переносим: сравнение должно держаться на данных и действиях, которые действительно встретятся в процессе, а не на случайной подборке «хороших» запросов.

Владелец сценария до эксперимента фиксирует четыре границы.

1. Что именно приходит на вход. Это может быть текст обращения без вложений, структурированное поле, фрагмент базы знаний или русскоязычный документ в согласованном формате. Не стоит добавлять в первую проверку всё, что теоретически умеет API.
2. Как выглядит правильный выход. Для маршрутизации это одна из очередей и обоснование; для извлечения — значение, статус уверенности и право оставить поле пустым; для резюме — обязательные пункты и запрет на выдуманные факты.
3. Какова цена ошибки. Ошибка в предложении черновика и ошибочное изменение клиентского статуса — разные риски. Чем труднее отменить действие, тем выше роль человека и тем строже порог приемки.
4. Что считается отказом. Пустой результат, низкая уверенность, противоречие с карточкой, неизвестный тип входа, превышение времени ожидания — это не «шум, который поправим потом», а штатные исходы маршрута.

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

Как построить честное сравнение

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

В этом месте важно различать данные и доказательство. Нельзя взять всю выгрузку CRM «для реалистичности». Статья 5 Федерального закона №152-ФЗ требует ограничивать обработку конкретными, заранее определёнными и законными целями, обрабатывать данные, соответствующие цели, и не допускать избыточного объёма. Официальный текст закона не предписывает формат ML-эксперимента и не даёт порог качества. Он задаёт границу: в корпус попадает только то, что действительно нужно для проверяемой задачи и допустимо в её правовом режиме.

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

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

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

Минимальный набор результатов лучше держать раздельно:

Не нужно сводить эти измерения в один красивый балл. Он почти всегда прячет компромисс. Может оказаться, что компактная модель проходит 98% классификаций и даёт нужную задержку, но не подходит для сложных резюме. Тогда решение не «малая модель проиграла», а «вот класс задач, где она может работать; вот класс, который остаётся базовой модели или человеку». Именно такая граница и нужна для архитектуры.

Ресурсы и экономика: считать по потоку

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

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

Измеряйте задержку и пропускную способность отдельно. В документации vLLM Benchmark CLI явно разделены latency и throughput и отмечено, что терминология метрик между инструментами не стандартизована. Поэтому в протоколе указывают не только число, но и его смысл: end-to-end или время генерации; P50 или P95; размер входа и ответа; число параллельных запросов; холодный или прогретый запуск; версия модели и конфигурация. Иначе две одинаковые цифры могут описывать разные процессы.

Полезная формула расчёта несложна, но требует честных входов:

стоимость периода = число запросов × средние входные токены × ставка входа + число запросов × средние выходные токены × ставка выхода + измеримые инфраструктурные и эксплуатационные расходы.

Для self-hosted контура последняя часть не должна быть нулём «потому что сервер уже куплен». Если решение забирает ускоритель у другого сервиса, требует ночного дежурства или отдельного резервного узла, это влияет на выбор. А для API-сценария не стоит приписывать малой модели экономию, пока не зафиксированы реальный токен-профиль и доля запросов, которые всё равно уходят на базовую модель или к человеку.

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

Протокол пилота: что должно остаться после недели

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

Поэтому для ограниченного сценария нужен короткий, но полный протокол. Не толстый регламент и не журнал каждого токена. Достаточно одного места, где зафиксированы версия модели, дата и способ запуска, граница входа, версия инструкции, состав корпуса, метод разметки, метрика, порог, нагрузочный профиль и маршрут отказа. Рядом стоит записать, кто имеет право изменить каждый элемент. Если разработчик поменял промпт, а владелец процесса не увидел новых примеров, это уже другое испытание. Если ИБ изменила режим логирования, это меняет наблюдаемость и может изменить допустимый объём следа. Если поставщик обновил версию модели за тем же именем, результат прошлой недели нельзя механически считать результатом сегодняшней.

Практичный ритм пилота выглядит так.

1. В первый день команда замораживает контрольный корпус и отдельно помечает примеры, которые нельзя показывать в отладочных логах. Владелец процесса подтверждает эталон или правило оценки. Архитектор фиксирует, где заканчивается тестовый контур и куда разрешены сетевые вызовы. Это не бюрократия: без этих трёх решений нельзя отличить улучшение модели от изменения условий.
2. Во второй день обе альтернативы получают одинаковую инструкцию по формату ответа и одинаковую проверку выходных полей. Если для сценария требуется классификация, обе должны вернуть тот же набор допустимых классов и причину; если резюме — обе должны соблюдать одинаковую структуру и запрет на новые факты. Сильной модели нельзя давать «свободный» выход только потому, что он выглядит умнее.
3. В середине недели команда проверяет не только средний результат, но и хвосты: самые длинные обращения, смешанные языки, отсутствующие поля, редкие классы, противоречия и тайм-ауты. В отчёте эти случаи не прячут в заметку «пограничные». Для них считают долю и показывают фактический маршрут: отказ, ручная проверка, повтор или остановка.
4. В конце недели владелец сценария принимает не модель «вообще», а формулировку маршрута. Например: «модель X автоматически направляет только типовые обращения трёх очередей; остальные уходят оператору с указанной причиной; пересмотр порога — раз в месяц на новой выборке». Эту формулировку может понять и следующий руководитель смены, и инженер сопровождения. Значит, её можно запускать в ограниченном контуре.

У протокола есть важный антистимул: он не позволяет оптимизировать тест под один красивый показатель. Допустим, команда снизила температуру, добавила три примера в инструкцию и подняла точность на знакомой выборке. Это может быть полезной настройкой. Но если после этого выросла длина ответа, увеличилась P95-задержка и пять процентов запросов чаще уходят на базовую модель, решение изменилось сразу по нескольким координатам. Нельзя объявить победу по одному числу и надеяться, что операционная цена «как-нибудь растворится». В матрице важны и качество, и покрытие, и время, и ручной труд.

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

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

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

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

Данные и отказ: границы эксперимента

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

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

Для данных действуют две разные дисциплины. Первая — минимизация корпуса: в нём остаются только признаки, нужные для задачи и допустимые по её цели. Вторая — минимизация следа: протоколы, промпты, кэш, отладочные дампы и результаты проверки не должны превращаться в теневое хранилище исходных документов. Статья 5 №152-ФЗ помогает сформулировать вопрос о соответствии объёма цели; выбор конкретных мер, сроков, оснований и режима локализации проверяется по контексту организации и с профильными специалистами. Закон не отвечает на вопрос, какую модель выбрать, и его не следует использовать как доказательство технической надёжности.

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

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

Матрица решения: одна строка до закупки

Ниже не рейтинг моделей и не шаблон договора. Это минимальная строка, по которой ИТ-директор может провести предметный разговор с владельцем процесса, архитектором, ИБ и командой эксплуатации. Она заставляет назвать компромисс до того, как он станет скрытой настройкой.

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

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

Что меняется в смежных решениях

Выбор языковой модели не существует отдельно от процесса. В материале «Внедрение ИИ в бизнес-процесс» полезно сверить, где в процессе появляется решение модели и где остаётся ответственность человека. Если сценарий превращается в агента с доступом к системам, обязательна отдельная граница полномочий; её раскрывает статья «ИИ-агенты для бизнеса». А перед подготовкой корпуса стоит проверить, не уносит ли тестовая среда лишние сведения: для этого есть разбор обезличивания данных в тестовых средах и материал о рисках утечек персональных данных.

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

Тест понедельником

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

Затем возьмите компактную и базовую модель и не просите их «показать интеллект». Дайте одинаковые входы и одинаковую форму ответа. Измерьте качество на отложенной части корпуса, P95 времени и долю возвратов к человеку. Сохраните версии, конфигурацию и дату расчёта. Если компактный вариант проходит согласованные границы — он получил право на ограниченный пилот. Если нет — верните исключение человеку или другой модели и не называйте это временной мелочью.

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

Важное уведомление

Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.