LLM router — внутренний слой, который выбирает разрешённую модель для каждого запроса по правилам команды и записывает причину выбора. Он учитывает тип задачи, класс данных, доступность модели и бюджетный предел; отдельное правило управляет резервным маршрутом при сбое. Такой слой полезен там, где одним запросам нужен точный разбор документа, другим — короткая классификация, а доступ к данным у этих задач различается.
Роль маршрутизатора
Факт: маршрутизатор принимает решение до вызова модели, а резервный маршрут проходит те же ограничения по данным и правам, что основной.
Маршрутизатор получает описание задачи и технические признаки запроса, сверяет их с политикой, выбирает допустимый маршрут и передаёт вызов. Политика принадлежит компании: владелец процесса утверждает категории задач, инженер задаёт технические ограничения, специалист по данным определяет допустимые направления передачи. Вызов модели идёт только после этих проверок. Разрешение на передачу данных задаёт серверная политика; название сервиса в запросе остаётся текстом обращения.
Здесь важно различать внутренний LLM router и OpenRouter. Первый означает архитектурную функцию компании, второй — название внешнего продукта со своими условиями. Страница про выбор нейросети под задачу помогает составить список кандидатов; маршрутизатор превращает такой выбор в проверяемое правило для повторяющихся запросов. Архитектура работает и с одной группой разрешённых моделей, если задачи требуют разных режимов доступа или разных критериев качества.
| Входной признак | Решение политики | След для проверки |
|---|---|---|
| Класс данных | Список разрешённых направлений | Версия правила и причина допуска |
| Тип задачи | Кандидаты с нужным качеством | Код сценария и выбранная модель |
| Доступность | Основной либо резервный маршрут | Причина переключения и исход вызова |
| Бюджетный предел | Допуск вызова либо остановка | Правило ограничения и статус |
Таблица описывает проектную схему. Возможности поставщика требуют отдельной проверки. Проверки прав и разрешений выполняет серверный контур. Текст запроса способен сообщить цель работы, но полномочия из него выводить опасно: сотрудник может попросить модель обойти ограничение, ошибиться с категорией документа или вставить чужой фрагмент. Сервер сверяет идентификатор пользователя, роль и разрешённый источник до передачи содержимого.
Правила выбора
Начните с реестра сценариев; список моделей пригодится позже. Для каждого сценария запишите владельца, допустимые данные, желаемый формат ответа и критерий успешной проверки. Классификация обращения и объяснение отклонения в договоре требуют разных примеров и разных способов контроля. Если исходные данные берутся из полной выгрузки или расчётной таблицы, парсер либо скрипт обрабатывает весь массив и считает значения. Языковая модель объясняет обнаруженные исключения и предлагает гипотезы по ограниченной выдержке. Человек сверяет вывод с первичным источником.
Затем опишите кандидатные маршруты как набор разрешений. Указание «дешёвая модель» слишком расплывчато: бюджетный предел имеет смысл только рядом с классом данных, задачей и минимальным качеством. При отсутствии подходящего кандидата маршрутизатор возвращает понятный статус владельцу процесса. Такой исход защищает от тихой подмены модели на произвольную, особенно когда резерв отличается по месту обработки данных.
- Зафиксируйте тип задачи и источник данных в карточке сценария; владелец процесса утверждает набор допустимых операций.
- Сервер определяет роль пользователя и класс данных по доверенным полям, затем отбрасывает запрещённые маршруты.
- Из оставшихся кандидатов код выбирает маршрут по качеству, доступности и бюджетному правилу; версия политики попадает в журнал.
- После ответа отдельная проверка сверяет формат и обязательные поля, а содержательные выводы принимает назначенный специалист.
Доступность отражает наблюдение и конфигурацию; успешный ответ проверяют отдельно. Ошибка сети, отказ доступа и содержательно слабый ответ требуют разных действий. Первые события могут запустить техническое переключение по правилам. Слабое содержание отправляют на разбор качества: автоматическая смена модели без проверки способна скрыть проблему данных или инструкции. Материал о причинах срыва внедрения ИИ полезен для обсуждения владельцев и критериев приёмки.
Резервный маршрут
Fallback нужен как отдельная ветка политики. При техническом сбое сервер отмечает причину, проверяет допустимость резервного направления и только затем повторяет вызов. Новый адрес обработки данных может требовать другого согласования; одна лишь доступность резервной модели такое согласование заменить неспособна. Если разрешённого направления нет, сценарий завершает попытку со статусом и передаёт работу человеку. Для операций записи повтор особенно чувствителен: приложение сверяет уникальный идентификатор действия и текущее состояние объекта.
Документация LiteLLM Router описывает выбор развёртываний и механизмы маршрутизации; отдельное руководство по надёжности описывает fallback после попыток вызова. Это пример механизмов. Корпоративную политику компания проектирует самостоятельно. Связь ошибки с резервом, список разрешённых моделей, обработку данных и предел расхода компания задаёт и тестирует самостоятельно.
Резервный путь допустим только при совпадении прав, класса данных и требований к результату. Иначе система фиксирует остановку и уведомляет владельца задачи.
Для учебной проверки подготовьте синтетический запрос с разрешёнными данными и управляемый отказ основного маршрута. Наблюдайте, выбирает ли сервис только кандидатов из утверждённого набора, пишет ли причину переключения и сохраняет ли связь с исходным запросом. Затем повторите проверку с запрещённым резервом: ожидаемый исход — остановка, видимая в журнале. Проверка проводится в тестовом контуре без реальных ключей в примерах и публикациях.
Такой тест выявляет конкретное слабое место: резерв может отвечать технически успешно, но нарушать утверждённую границу данных. Владелец должен видеть оба результата — технический статус и факт допуска. По этой карте удобно сформулировать задачу на внедрение без обещания автоматической экономии.
Нужна политика резервного маршрута для ваших сценариев?
Журнал решения
Журнал помогает разобрать выбор. Полные тексты запросов остаются в источниках с отдельными правами. Запишите идентификатор обращения, версию политики, класс данных, код сценария, выбранное развёртывание модели, причину допуска, факт переключения и технический исход. Для содержательной проверки сохраните ссылку на разрешённый источник и версию результата там, где это допускает внутренняя политика. Секреты, исходные ключи и лишние персональные данные исключите из события журнала.
Разделите авторство решения. Владелец процесса утверждает требования к качеству и случаи передачи человеку. Инженер отвечает за исполняемые правила, журнал и наблюдаемость. Администратор доступа настраивает серверные разрешения и проверяет отказ при чужой роли. Ответственный специалист сверяет смысл результата с документом или записью учёта. Модель может объяснить собственную гипотезу. Правильность маршрута подтверждают серверный журнал и сверка с политикой.
- Для каждого выбора видны разрешённые кандидаты и причина исключения остальных по кодам политики, без раскрытия закрытых данных.
- Для fallback журнал связывает исходный вызов, ошибку и резервный ответ одним идентификатором обращения.
- Для остановки виден код ограничения: класс данных, право, бюджетное правило либо отсутствие допустимой модели.
- Для действия с записью сервер фиксирует подтверждение человека и проверяет право на изменение объекта.
Сценарий с формой документа особенно показателен. Сотрудник просит краткое содержание, сервис выбирает разрешённый путь и готовит черновик. Если следующий шаг меняет CRM или иной рабочий объект, приложение показывает конкретное действие человеку. Сервер отдельно проверяет права и подтверждение перед записью. Это проектный пример для будущего пилота.
Заранее договоритесь, кто просматривает спорные записи журнала и как обновляется политика после разбора. Версия правила рядом с событием позволит восстановить причину прежнего решения даже после изменения списка моделей. Сам журнал хранится по внутренним правилам доступа; открытая выгрузка с полными текстами запросов увеличит риск утечки.
Проверка пилота
Для будущего пилота соберите эталонную выборку из разрешённых или синтетических запросов. Включите разные классы задач, спорные формулировки, недоступность основного маршрута, запрет резервного направления и достижение бюджетного предела. У каждого примера заранее укажите ожидаемый маршрут, допустимый формат ответа и владельца проверки. Состав выборки фиксируют до оценки, иначе успешные ответы легко отобрать задним числом.
Проверку делите на техническую и содержательную. Код сравнивает решение маршрутизатора с утверждённой разметкой, сверяет полноту журнала, идентификаторы и случаи остановки. При работе с полными выгрузками скрипт считает показатели по всему набору. Языковая модель помогает описать причины расхождения и предложить гипотезы для разбора. Человек сверяет спорные ответы с исходными данными и решает, менять ли политику.
Критерии приёмки должны охватывать удачный ответ и корректный отказ. Проверьте, что закрытые данные передаются только в разрешённом направлении, ошибка основного вызова сохраняет объяснимый след, повтор записи требует серверного подтверждения, а остановка видна пользователю. Отдельно проверьте качество ответа на эталонных задачах. Критерий приёмки маршрутизатора — воспроизводимый выбор в рамках политики на эталонных задачах.
Стоимость такой схемы зависит от числа сценариев и моделей, состава данных, требований к журналу, проверкам и сопровождению. Расход на вызовы оценивают отдельно от работы по проектированию и поддержке, по актуальным условиям выбранных поставщиков. Для оценки собственного контура можно описать сценарии и ограничения на странице внедрения ИИ в рабочий процесс. Ожидаемый результат предлагаемого пилота — карта разрешённых маршрутов и список проверенных исключений для решения команды.