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 может принимать решение по явным и вычисляемым сигналам.

Пример routing matrix ¶

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

Базовый pattern:

1. Input trigger принимает запрос.
2. Pre-classifier определяет тип задачи. Для простых случаев достаточно правил в Code node; для сложных — дешёвая модель-классификатор.
3. Risk scorer оценивает PII, деньги, юридические формулировки, запись во внешние системы.
4. Context estimator оценивает длину текста и RAG-потребность.
5. Route decision возвращает route profile.
6. Switch node отправляет execution в нужную ветку.
7. Model call выполняется по выбранному профилю.
8. Validation/evaluation проверяет результат.
9. Fallback router выбирает запасной маршрут при ошибке.
10. 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:

Для 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%, но вдвое чаще требует ручной правки, экономия может быть ложной.