Как маршрутизировать запросы между LLM по задаче, качеству и ограничениям

Когда маршрутизация моделей решает рабочую задачу

У ИИ-помощника могут быть разные запросы: извлечь реквизиты, сопоставить документы, подготовить черновик или собрать материалы для решения сотрудника. Если люди вручную выбирают модель, одинаковые задачи могут попадать на разные маршруты. Руководителю трудно восстановить причину выбора и сравнить результаты.

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

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

Составьте карту запросов и допустимых результатов

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

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

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

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

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

Определите разрешённые модели и границы каждой роли

Для каждого класса зафиксируйте не абстрактную «подходящую модель», а разрешённый маршрут:

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

Постройте правила выбора и маршрут неопределённости

Базовый маршрут выглядит так:

1. Нормализовать вход и выделить обязательные признаки.
2. Определить класс запроса и проверить разрешения.
3. Выбрать модель, выполнить запрос и проверить результат.
4. Вернуть ответ либо запросить уточнение или помощь сотрудника.

Ставьте узкие условия перед общими. Если запрос подходит под несколько правил, заранее определите приоритет. В n8n Model Selector правила проверяются последовательно, а выбор останавливается на первом совпадении. Поэтому порядок условий входит в версию маршрутизатора и должен проверяться вместе с ними.

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

Учтите поведение пакетного входа в n8n

Общую архитектуру нужно отделять от реализации в выбранном workflow. Согласно текущей документации n8n Model Selector, выражение в sub-node при нескольких входных items разрешается по первому item. Документация также указывает, что правила проверяются по порядку до первого совпадения.

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

• подавать запросы в селектор по одному;
• разделять пакет до определения маршрута;
• использовать другую архитектуру обработки.

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

Разделите качество, задержку и расходы

Не сводите три характеристики к одному рейтингу. Маршрут может лучше соблюдать формат, но требовать дополнительных проверок; другой может давать более короткий полный путь, но хуже обрабатывать пограничные случаи.

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

Ведите журнал маршрутизации без лишних данных

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

Для пакета добавьте связь исходного элемента с фактическим маршрутом. Сам текст запроса и ответа храните только в согласованном объёме. Срок хранения, маскирование, права доступа и удаление — требования будущего решения; их наличие нельзя предполагать без проверки архитектуры и настроек.

Условный маршрут одного запроса

Ниже — синтетическая проектная иллюстрация, а не клиентский кейс, выполненный тест или рекомендация конкретных моделей. Обозначения A и B условны.

Последняя строка важна для реализации через sub-node n8n: выражение может разрешиться по первому item. Поэтому пакет нельзя считать корректно маршрутизированным только потому, что workflow завершился без технической ошибки.

Как проверить маршрутизатор перед рабочим запуском

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

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

Если команда использует metric-based evaluations n8n, учитывайте документированные условия доступности на дату проверки: n8n Cloud Pro и Enterprise, self-hosted Enterprise, а Registered Community и Starter — для одного workflow. Наличие этой функции не доказывает качество маршрутизатора и не задаёт подходящую метрику или проходной балл.

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

Ограничения и подготовка к внедрению

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

Для обсуждения подготовьте:

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

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

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