---
title: "Model routing в n8n: как отправлять каждую — Nodbot"
source_url: "https://nodbot.ru/ai/model-routing/"
canonical_url: "https://nodbot.ru/ai/model-routing/"
language: "ru"
content_type: "AIGuide"
section: "ai"
generated_at: "2026-05-30"
word_count_source: 1630
---

# Model routing в n8n: как отправлять каждую AI-задачу в правильную модель

## AI summary

Как построить model routing в n8n: классификация задач, матрица выбора моделей, cost guardrails, latency SLA, PII, RAG, JSON-output, fallback и observability.

## Best used for

Страница объясняет «Model routing в n8n: как отправлять каждую — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Короткий ответ
- Зачем routing, если можно выбрать одну модель
- Route profile, а не просто название модели
- Сигналы для выбора модели
- Пример routing matrix
- Как собрать router в n8n
- Router должен уметь сказать «не вызывать AI»
- Cost guardrails

## Source outline

# Model routing в n8n: как отправлять каждую AI-задачу в правильную модель

Обновлено: 2026-05-29

## Короткий ответ

Model routing в n8n — это слой принятия решения перед вызовом LLM: какую модель выбрать для конкретной задачи, с каким промптом, бюджетом, context window, timeout и fallback. Простые классификации и извлечения не должны идти в самую дорогую модель, а рискованные ответы клиенту не должны идти в дешёвую модель без проверки. Хороший router учитывает тип задачи, язык, чувствительность данных, требуемый JSON, наличие RAG, SLA по latency, бюджет и историю качества. Без routing AI workflow либо переплачивает, либо нестабильно отвечает там, где нужна точность.

## Зачем routing, если можно выбрать одну модель

Одна модель для всего кажется проще, но быстро создаёт проблемы. Дорогая модель на каждой email-классификации увеличивает расходы. Дешёвая модель на юридически чувствительных ответах даёт риск. Быстрая модель может не выдержать длинный RAG-контекст. Модель, которая хорошо пишет текст, может плохо держать строгий JSON. Поэтому production AI workflow должен сначала понять задачу, а уже потом выбирать model profile.

Model routing особенно полезен для:

- поддержки с разными уровнями сложности;
- AI Agent с read/write tools;
- RAG-ботов с разными типами вопросов;
- классификации лидов и писем;
- JSON extraction;
- генерации черновиков ответов;
- multilingual workflows;
- batch-задач с большим объёмом;
- платных сценариев, где нужен cost cap.

## Route profile, а не просто название модели

Маршрут должен выбирать не только модель, а профиль выполнения:

```
{
  "route": "support_rag_high_confidence",
  "model": "quality_long_context",
  "temperature": 0.2,
  "max_output_tokens": 700,
  "timeout_ms": 12000,
  "requires_sources": true,
  "requires_json": true,
  "fallback_route": "support_human_review",
  "cost_budget_usd": 0.05,
  "human_review_threshold": 0.72
}
```
Такой профиль легко тестировать, логировать и менять без переписывания всего workflow.

## Сигналы для выбора модели

Router может принимать решение по явным и вычисляемым сигналам.

- Сигнал | Пример | Как влияет на route
- task_type | classify, extract, answer, draft, agent_action | основной выбор модели
- risk_level | low, medium, high | high-risk требует quality/review
- requires_json | true/false | нужна модель с хорошим structured output
- language | ru, en, mixed | выбрать модель с сильным языком
- context_size | 2k, 20k, 80k tokens | длинный контекст требует long-context model
- pii_state | raw, redacted | raw PII может требовать локальной/approved модели
- latency_sla_ms | 3000, 10000, async | быстрый маршрут или очередь

## Пример routing matrix

- Задача | Модель/профиль | Почему
- Intent classification | fast-small-json | короткий вход, простой JSON, дешево
- PII redaction | deterministic/rules + small model fallback | безопасность важнее красивого текста
- RAG answer с источниками | quality-rag | нужна точность, source grounding
- Draft email оператору | balanced-writing | качество текста, но human review
- Tool call с записью в CRM | quality-agent + approval | side effect требует контроля
- Batch summarization | cheap-summarizer | объём важнее идеального стиля
- High-risk legal/finance answer | no direct answer + review | route в человека, не в модель

## Как собрать router в n8n

Базовый pattern:

- Input trigger принимает запрос.
- Pre-classifier определяет тип задачи. Для простых случаев достаточно правил в Code node; для сложных — дешёвая модель-классификатор.
- Risk scorer оценивает PII, деньги, юридические формулировки, запись во внешние системы.
- Context estimator оценивает длину текста и RAG-потребность.
- Route decision возвращает route profile.
- Switch node отправляет execution в нужную ветку.
- Model call выполняется по выбранному профилю.
- Validation/evaluation проверяет результат.
- Fallback router выбирает запасной маршрут при ошибке.
- Route log сохраняет decision для анализа.
Простой Code node для route decision:

```
const task = $json.task_type;
const risk = $json.risk_level || 'low';
const requiresJson = Boolean($json.requires_json);
const contextTokens = Number($json.estimated_context_tokens || 0);
const latencySla = Number($json.latency_sla_ms || 10000);
const retrievalScore = Number($json.retrieval_score || 1);

let route = 'balanced_default';

if (risk === 'high') route = 'human_review_first';
else if (task === 'classify' && requiresJson) route = 'fast_small_json';
else if (task === 'extract' && requiresJson) route = 'structured_json';
else if (task === 'rag_answer' && retrievalScore < 0.65) route = 'clarify_or_review';
else if (task === 'rag_answer' && contextTokens > 12000) route = 'quality_long_context';
else if (task === 'draft_reply') route = 'balanced_writer';
else if (latencySla < 4000) route = 'fast_low_latency';

return [{ json: { ...$json, model_route: route } }];
```

## Router должен уметь сказать «не вызывать AI»

Хороший routing иногда выбирает не модель, а безопасную ветку:

- вернуть canned response;
- спросить уточнение;
- отправить на оператора;
- выполнить обычный API-запрос;
- остановить workflow из-за PII;
- вернуть ошибку валидации;
- взять ответ из cache.
Это особенно важно для запросов, где модель не добавляет ценности: проверка статуса заказа, поиск по ID, расчёт суммы, CRUD-операция, простая маршрутизация по фиксированным правилам.

## Cost guardrails

Route decision должен учитывать бюджет до вызова модели. Минимальный набор:

- estimated_input_tokens ;
- max_output_tokens ;
- route_cost_estimate ;
- daily_budget_remaining ;
- user_plan или tenant_budget ;
- fallback_cost_limit .
Если прогнозируемая стоимость выше лимита, router может:

- уменьшить context;
- сначала сделать summarization;
- выбрать cheaper model;
- перейти в async mode;
- попросить пользователя сузить запрос;
- отправить на review.

## Latency routing

Не все запросы должны отвечать синхронно. Для чата latency критична: 2–8 секунд. Для ночного batch-отчёта можно ждать минуты. Поэтому route profile должен различать:

- sync_fast : быстрый ответ пользователю;
- sync_quality : ответ с допустимой задержкой;
- async_batch : очередь, уведомление после обработки;
- human_review : workflow останавливается до решения человека;
- degraded : короткий safe response.
Если route требует RAG по сотням документов, tool calls и JSON validation, не притворяйтесь, что это чат за 2 секунды. Лучше честно перевести в async.

## Routing для RAG

RAG-routing выбирает не только модель, но и стратегию retrieval:

- Условие | Route
- Вопрос точный, есть product/page ID | metadata filter + small answer model
- Вопрос широкий | broader retrieval + summarization
- Низкий retrieval score | clarification или human review
- Документы свежие и короткие | standard RAG
- Документы длинные и конфликтуют | multi-step retrieval + source comparison
- Пользователь просит действие | RAG answer не должен сам выполнять tool call

Для RAG важно логировать не только модель, но и top_k , filters, retrieved IDs, score, index version и final cited sources.

## Routing для JSON output

Если downstream nodes ждут JSON, выбирайте профиль, оптимизированный под schema adherence. Route должен включать:

- JSON Schema;
- required fields;
- enum values;
- пример валидного output;
- max repair attempts;
- fallback при parser error.
Нельзя отправлять raw текст в CRM, таблицу или payment workflow без schema validation. Даже если модель «почти всегда» возвращает правильный JSON, production сломается именно на исключении.

## Observability: как понять, что router работает

Логируйте каждое решение:

```
{
  "route_id": "support_rag_high_confidence",
  "route_reason": ["task=rag_answer", "risk=medium", "retrieval_score=0.82"],
  "model": "quality_long_context",
  "fallback_route": "support_human_review",
  "estimated_cost_usd": 0.024,
  "actual_cost_usd": 0.021,
  "latency_ms": 5320,
  "validation_status": "passed",
  "user_feedback": "thumbs_up"
}
```
Раз в неделю смотрите:

- какие routes самые дорогие;
- где чаще fallback;
- где низкие оценки пользователей;
- где high-risk ушёл не в review;
- где cheap route даёт parser errors;
- где long-context route используется без необходимости.

## Тесты маршрутизации

Для каждого route создайте 5–10 контрольных примеров:

- простой пример, который должен попасть в дешёвую модель;
- сложный пример, который должен попасть в quality model;
- пример с PII;
- пример с high-risk действием;
- пример с длинным контекстом;
- пример с плохим RAG score;
- пример, где AI не нужен;
- пример, где нужен human review.
Тест считается пройденным, если route decision совпал, стоимость в лимите, latency в SLA, output валиден и fallback не сработал без причины.

## FAQ

### Router должен быть rule-based или AI-based?

Начинайте с rule-based. Он дешевле, прозрачнее и проще отлаживается. AI-classifier добавляйте только там, где правила не справляются с неоднозначными запросами. Даже AI-router должен возвращать объяснимые поля, а не просто название модели.

### Можно ли routing делать в одном Code node?

Да, на старте. Но когда routes становятся бизнес-критичными, лучше вынести правила в таблицу, JSON-конфиг или отдельный sub-workflow, чтобы менять их без риска сломать всю логику.

### Как не переплачивать за RAG?

Не отправляйте весь контекст в дорогую модель. Сначала оцените вопрос, сделайте retrieval с metadata filters, ограничьте top-k, сожмите документы и только потом вызывайте quality model.

### Что делать, если дешёвая модель часто ошибается?

Не увеличивайте модель вслепую. Посмотрите, в чём ошибка: route misclassification, плохая schema, длинный вход, низкий язык, недостающие примеры. Иногда дешевле улучшить prompt/schema, чем всегда переходить на дорогую модель.

### Нужно ли учитывать язык пользователя?

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

### Как routing связан с fallback?

Routing выбирает первый путь до вызова модели. Fallback выбирает запасной путь после ошибки или плохой валидации. Но оба должны использовать общие route profiles и logging.

### Можно ли route-ить по пользователю или тарифу?

Да, если это честно отражено в продукте. Например, free-пользователь получает async cheap route, а paid-пользователь — faster quality route. Но high-risk безопасность не должна зависеть от тарифа.

### Как понять, что routing ухудшает качество?

Сравните качество route-групп: feedback, validation errors, fallback rate, human override rate, cost per success. Если cheap route экономит 30%, но вдвое чаще требует ручной правки, экономия может быть ложной.

## Контроль качества AI-workflow

AI-workflow по теме «Model routing в n8n» должен иметь измеримый контракт: что модель получает, какие действия ей разрешены, какой JSON она обязана вернуть и при каких условиях включается human review. Без этого качество нельзя отличить от удачного демо.

Отдельно фиксируйте версию prompt, модель, источники контекста и причину fallback. Главный риск — получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry.

- Слой | Что зафиксировать | Зачем
- Вход | нормализованный prompt, контекст, список источников, версия промпта и ожидаемый JSON-ответ | позволяет повторить проблему без доступа к production-секретам
- Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Model routing в n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "request_id": "req_demo_001",
  "prompt_version": "2026-05-29",
  "input": "краткое нормализованное сообщение пользователя",
  "allowed_actions": ["read", "draft", "classify"],
  "forbidden_actions": ["send_without_review", "change_payment"],
  "expected_output": {
    "intent": "technical|support|sales|unknown",
    "confidence": 0.0,
    "needs_human_review": true,
    "sources": []
  }
}
```

### Критерий готовности

- определён JSON-контракт ответа и validation step после модели
- опасные действия проходят через approval или создают только draft
- логируются prompt_version, model, sources, cost и fallback_reason
- есть eval-набор минимум для happy path, low confidence и prompt injection

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.