Локальная компактная модель или облачный LLM для маршрутизации
Маршрутизация — хорошая задача для ИИ: по письму, заявке или документу нужно выбрать один из заранее известных путей. Здесь часто сталкиваются два подхода. Компактная модель работает в собственном контуре и выдаёт класс. Большая облачная LLM получает инструкцию, объясняет решение и может извлечь дополнительные поля. Победителя по названию технологии нет: выбор зависит от потока и цены ошибки.
Что сравниваем
Возьмём входящие обращения интернет-магазина. Система выбирает «доставка», «возврат», «оплата», «товар», «жалоба» или «нужен человек». Она не отвечает клиенту и не меняет заказ. Для теста используются одинаковые обезличенные сообщения и одинаковая схема классов. Облачной модели запрещено придумывать новый класс, локальной разрешено возвращать низкую уверенность.
Сначала строится простая базовая линия: ключевые слова и ручная очередь. Без неё невозможно понять, окупается ли любая модель. Затем сравнивают качество, задержку, стоимость принятого решения и эксплуатационные риски.
Качество на понятных случаях
Большая LLM обычно лучше понимает длинное письмо, косвенную формулировку и несколько намерений сразу. Она может вернуть не только класс, но и фрагмент, на котором основано решение. Однако свободный язык создаёт нестабильность: модель иногда меняет название категории, объясняет вместо JSON или выбирает наиболее заметную, а не приоритетную тему.
Компактный классификатор предсказуемее по формату и быстро работает на повторяющемся потоке. Его слабость — новые формулировки и редкие случаи, которых не было в данных. Если классы меняются каждую неделю, модель приходится переобучать. Для узкого устойчивого справочника это приемлемо; для постоянно нового продукта — дорого.
Работа с неопределённостью
Обе системы должны уметь отказаться. У локальной модели можно использовать порог вероятности и расстояние между двумя лучшими классами. У LLM просьба «скажи, если не уверен» не является надёжным измерителем. Лучше требовать цитату из входа и проверять соответствие схеме, а сложные комбинации направлять человеку.
Контрольная выборка должна содержать пустые сообщения, вложения без текста, сарказм, отрицания и два намерения. Процесс её создания разобран в гайде по контрольной выборке. Средняя точность без отдельной оценки опасного класса «жалоба» мало полезна.
Задержка и доступность
Локальная компактная модель способна отвечать за десятки миллисекунд и продолжать работу без внешней сети. Но сервер, наблюдение, обновления и резервирование становятся ответственностью команды. Если поток небольшой, собственная инфраструктура может стоить дороже запросов.
Облачный API снимает обслуживание GPU и масштабируется по запросу. Взамен появляются сетевой путь, лимиты поставщика, возможная очередь и изменение версии. Для интерактивной формы важен 95-й и 99-й процентиль задержки, а не среднее. Для ночной обработки писем несколько секунд часто несущественны.
Приватность и контроль данных
Локальный запуск упрощает правило «текст не покидает контур», но не обеспечивает безопасность автоматически. Логи, резервные копии и панель администратора всё равно могут раскрыть данные. Облачный API требует проверить регион обработки, срок хранения, обучение на запросах, субподрядчиков и условия удаления.
Лучший способ снизить риск в обоих вариантах — минимизация. Для категории доставки не нужны имя, телефон и полный адрес. Перед моделью можно заменить их маркерами, а связь с обращением хранить в основной системе. Подробнее о границах локального и внешнего контура мы писали в сравнении открытых весов и закрытого API.
Стоимость без самообмана
Для облачной LLM посчитайте входные и выходные токены, повторные вызовы, векторный поиск и проверку. Короткий структурированный ответ дешевле длинного объяснения. Для локальной модели учитываются оборудование или аренда, электричество, время инженера, мониторинг и простаивающий запас мощности.
Сравнивать нужно стоимость верно направленного обращения. Если дешёвая система создаёт много ручных переводов между отделами, экономия исчезает. Полезные показатели: цена тысячи входов, доля автоматических решений, время исправления и стоимость критической ошибки.
Обслуживание и смена классов
Облачную LLM можно быстро адаптировать инструкцией и несколькими примерами. Но изменение промпта тоже является релизом: нужен тест и откат. Локальную модель обновлять медленнее, зато версия весов фиксируется и не меняется без команды. При переходе соблюдайте регламент смены модели.
Часто работает гибрид. Компактная модель обрабатывает понятные частые случаи, а низкая уверенность уходит большой LLM или человеку. Такой каскад экономит внешние вызовы, но требует единого журнала: иначе команда не увидит, на каком уровне появилась ошибка.
Практическое решение
Локальный классификатор выбирают при большом стабильном потоке, строгой границе данных и доступной инженерной поддержке. Облачную LLM — при небольшом или меняющемся потоке, сложном языке и потребности быстро проверить гипотезу. Гибрид оправдан после измерения, а не как архитектура «на всякий случай».
Проведите двухнедельный теневой тест. Системы получают один поток, но не выполняют действие. Проверяющий вслепую оценивает расхождения, а команда считает полную цену. Только после этого автоматизируйте низкорисковые классы и оставьте человеку видимый способ исправить маршрут.
Частые вопросы
Всегда ли локальная модель дешевле? Нет. При малом потоке обслуживание может превышать стоимость API.
Можно ли поручить LLM сразу отвечать клиенту? Сначала отделите маршрутизацию от ответа. У действий разные риски и критерии.
Какой минимум для пилота? Зафиксированные классы, 100–300 реальных примеров, критические ошибки, базовая линия и журнал расхождений.