Маршрутизация ИИ-ассистентов: баланс между силой модели и надежным кодом

# Принципы маршрутизации в системах ИИ-ассистентов

В разработке агентов искусственного интеллекта критически важным аспектом является не только выбор модели, но и то, как система обрабатывает входящие запросы. На практике многие разработчики сталкиваются с ситуацией, когда их ИИ-ассистент, работающий на мощных моделях вроде Qwen или Gemma, демонстрирует значительно худшие результаты, чем простые сценарии на базе Claude Code или ChatGPT. Одной из ключевых причин этой проблемы становится архитектура системы маршрутизации.

В этой статье мы рассмотрим фундаментальные принципы построения маршрутизации, разделив их на две основные стратегии: «толстый» и «тонкий» Харнесс (Harness — слой управления и выполнения). Выбор между ними определяет не только стоимость API-запросов, но и надежность работы сервиса.

Толстый и тонкий Харнесс: стратегический выбор

Концепция «толстого» и «тонкого» Харнесса описывает степень участия программного кода в интерпретации намерений пользователя перед тем, как запрос будет передан языковой модели (LLM).

Толстый Харнесс необходим, когда используется модель с ограниченными возможностями понимания контекста. В такой архитектуре система берет на себя тяжелую работу по распознаванию интентов (намерений), выбору сценария и проверке обязательных данных. Это вынужденная мера, позволяющая компенсировать недостатки модели. Такой подход подразумевает наличие множества специализированных сущностей: классификации намерений (Intent), детерминированных сокращений (Shortcut), правил маршрутизации (Route) и механизмов запроса уточнений.

Тонкий Харнесс, напротив, оптимален для работы с мощными моделями. Здесь код ограничивается предоставлением каталога доступных возможностей (Capability) и проверкой безопасности. Основную семантическую нагрузку берет на себя модель. Если модель ошибается, система не должна пытаться исправить это через сотни жестко прописанных правил, превращая архитектуру в неподдерживаемый хаос исключений.

Главный принцип: сильная модель позволяет сделать слой управления тонким, так как модель сама способна выбрать правильное действие. Слабая модель требует толстого слоя, который выступает в роли костыля, но при этом границы безопасности (политики и права доступа) никогда не должны полностью передаваться модели.

Раннее отклонение и экономия ресурсов

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

1. Нормализация ввода (Normalize input): Приведение запроса к стандартному формату. Удаление лишних полей, определение типа события (текстовое сообщение, кнопка действия, callback), проверка структуры данных. 2. Связывание сессии и контекста (Bind session and context): Определение авторизованного пользователя, связанной организации, текущей активной задачи, выбранного ресурса и истории диалога. Без этого контекста модель не сможет адекватно ответить. 3. Проверка возможностей и доступа (Check capability and access): Выявление того, какую функцию пользователь пытается выполнить, и проверка наличия у него соответствующих прав доступа. Например, если пользователь не имеет прав на анализ конкретного проекта, запрос должен быть отклонен на этом этапе. 4. Выбор рабочей модели (Select workflow): Определение сценария выполнения. Нужно ли запустить новый анализ, продолжить существующий, скачать результат или запросить уточнение данных. 5. Прохождение контрольной точки политики (Run policy gate): Проверка ограничений безопасности и бизнес-правил. Действие не должно быть запрещено политикой, не требовать дополнительного подтверждения, и пользователь должен предоставить все обязательные данные. 6. Вызов модели или инструментов (Call LLM/tools only when execution is possible): На этом финальном этапе только после успешного прохождения всех предыдущих проверок система инициирует вызов языковой модели или запускает инструменты. Если права отсутствуют или контекст неполный, ресурсы не тратятся впустую.

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

Принцип: Не использовать LLM там, где это не нужно

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

Если запрос пользователя можно точно сопоставить с известным событием или структурированным payload (например, нажатие кнопки «скачать последний результат» с четким resource_id), нет необходимости отправлять этот запрос в модель. Достаточно проверить права, найти ресурс и выполнить действие.

Вызов модели в таких случаях несет ряд негативных последствий: - Затраты: Потребление токенов и GPU-ресурсов. - Задержка: Добавление времени отклика. - Ошибки: Вероятность неправильной интерпретации однозначных данных. - Точки отказа: Модель может выбрать неверный инструмент или начать строить план там, где достаточно простого вызова функции.

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

Типы маршрутов

Полезно разделять маршруты на несколько типов для оптимальной работы системы:

• Event route: Обработка структурированных событий, поступающих из интерфейса (например, нажатие конкретной кнопки).
• Exact route: Выполнение однозначных команд с четко определенными параметрами (например, повторить конкретную задачу с известным ID).
• Semantic route: Интерпретация свободного текста, где требуется понимание смысла и контекста.

Важно отметить, что принцип «меньше вызовов LLM» не означает хардкод как можно большего количества фраз. Точный маршрут должен обслуживать стабильные возможности (capability) и события. Сложные, шумные или неоднозначные запросы должны попадать в semantic route, иначе сокращения (shortcut) начнут перехватывать чужие сценарии и нарушать логику системы.

Заключение

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

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

---

Автор статьи: @kobubu Платформа: Habr Тематика: Искусственный интеллект, Python, Разработка Теги: агент, агенты, ии-агенты, ии, ии чат-бот, ии-ассистент, ии-модель, ии помощник, ии агенты, ии-агент, harness, harness engineering Хабы: Искусственный интеллект, Машинное обучение Ссылка: [habr.com/ru/articles/835374/](https://habr.com/ru/articles/835374/) Комментарии: 0 Поделиться: [Telegram](https://t.me/share/url?url=https://habr.com/ru/articles/835374/&text=Маршрутизация%20ИИ-ассистентов:%20баланс%20между%20силой%20модели%20и%20надежным%20кодом)

Дополнительная информация - Телеграм канал автора: [t.me/kobubu_ml](https://t.me/kobubu_ml) (где публикуются статьи про ML, NLP и разработку) - Дата публикации: 2024 - Просмотры: 24/7 доступность потока бэкенда благодаря поддержке друзей Хабра