Почему локальному ИИ не всегда нужна самая большая LLM: как работает роутер моделей

Когда компания выбирает локальную нейросеть, разговор часто начинается с размера: сколько параметров, сколько памяти, насколько модель близка к лидерам рейтингов. Но рабочий день состоит из разных задач. Найти пункт договора, распознать запись встречи и подготовить сложное объяснение — не одна и та же вычислительная работа.

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

Руководитель просит: «Посмотри запись встречи и подготовь поручения с учётом договора». За одной фразой скрываются извлечение речи, поиск документа, чтение нужных условий, сопоставление участников и формирование черновиков задач.

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

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

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

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

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

Маршрут должен учитывать и полномочия. Задача «подготовь ответ» не даёт права отправить его. Переключение модели также не должно расширять доступ пользователя к документам или незаметно выводить данные во внешний сервис.

OCR преобразует изображение текста в текст и, в зависимости от решения, помогает восстановить структуру страницы. ASR превращает речь в текст. Embeddings представляют фрагменты в числовом виде для поиска по сходству. Reranker переоценивает найденных кандидатов относительно запроса. Языковая модель формирует и объясняет ответ на предоставленном контексте.

В семействе Qwen существуют отдельные модели Qwen3 Embedding и Qwen3 Reranker для представления текста и ранжирования. Это хороший пример специализации: компоненты поиска решают другую задачу, чем диалоговый генератор. Официальное описание опубликовано 5 июня 2025 года; здесь оно используется как пример архитектуры, а не как утверждение о текущем лидерстве в рейтингах. Qwen · Qwen3 Embedding and Reranking ↗

Отдельный официальный проект Qwen3-ASR предназначен для распознавания речи. Его наличие также не означает, что любая конфигурация AI Office уже включает этот компонент или гарантирует качество на ваших записях. Модель, язык, шум, терминология и оборудование проверяются отдельно. QwenLM · Qwen3-ASR official repository ↗

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

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

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

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

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

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

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

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

Представим условный процесс обработки запроса на КП. Система извлекает позиции, ищет их в каталоге и проверяет обязательные поля. Для обычного случая готовит черновик. Если найдено несколько несовместимых вариантов или не указана единица измерения, формирует вопрос сотруднику.

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

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

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

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

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

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

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

При расчёте комплекта учитывают не только веса моделей, но и рабочую память, контекст, индексы, OCR, системные службы и ожидаемую нагрузку. Конкретные объёмы и скорость подтверждаются измерениями выбранного программного стека. Само число гигабайт не доказывает способность обслужить заданный отдел.

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

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

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

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

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

Для AI Office роутер моделей — архитектурный способ подбирать инструменты под работу компании. Конкретные локальные LLM, OCR, ASR, embeddings и допустимые облачные подключения фиксируются в проекте после проверки. Это не обещание, что любой названный компонент уже установлен и одинаково хорошо работает на каждом комплекте.

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

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