В демонстрации AI-продукта обычно есть один Prompt и один впечатляющий ответ. В production между ними появляются поиск, камера, телефонный звонок, права доступа, база расписаний, Timeout и пользователь, который меняет решение на полуслове. Здесь одна универсальная модель перестаёт быть архитектурой и становится точкой отказа.
Июльский AI-дайджест Яндекса выглядит как список несвязанных новостей: ИИ-хостес бронирует столики, Alice AI VLM ищет события в архиве камеры, Карты строят прогулочные маршруты, модели получают ISO/IEC 42001. Но вместе они показывают важную продуктовую закономерность: полезный AI-сервис — это не чат с одной LLM, а оркестр специализированных моделей, данных и инструментов.
Один интерфейс не означает одну модель
Пользователь может видеть одну строку запроса, но внутри задачи различаются:
· понять намерение и выбрать сценарий;
· найти актуальные факты;
· проанализировать изображение или видео;
· сформулировать короткий ответ;
· вызвать внешний инструмент;
· проверить результат перед необратимым действием.
Попытка решить всё одним большим запросом удобна для прототипа. В production она ухудшает наблюдаемость: непонятно, модель ошиблась в факте, не поняла намерение или неправильно вызвала инструмент.
Мультимодельная архитектура нужна не потому, что у моделей разные бренды. Она нужна потому, что внутри одного пользовательского действия живут задачи с разной ценой, задержкой и способом проверки.
Четыре июльских продукта — четыре типа маршрута
Сценарий | Что происходит внутри | Критический выбор |
AI Search | Retrieval, ранжирование, синтез ответа, ссылки | Быстрая модель для запроса; сильная — только для сложного синтеза |
ИИ-хостес | Речь, диалог, календарь, подтверждение брони | Низкая задержка в разговоре; строгий Tool Call для записи |
Поиск по видео | VLM извлекает события, текстовая модель понимает запрос | Мультимодальная модель работает только там, где есть кадры |
Маршрут в Картах | Выбор мест, геоограничения, порядок точек, рассказ | Детерминированный геосервис строит путь; LLM не рисует географию из памяти |
AI Search: быстрый вход, дорогой ответ по необходимости
Большая часть поисковых запросов проста: навигация, факт, знакомый объект. Использовать максимальную модель для каждого запроса — всё равно что созывать редакционную коллегию, чтобы узнать часы работы магазина.
Router сначала классифицирует запрос. Для навигационного ответа достаточно Retrieval и короткого шаблона. Сравнение нескольких источников уходит в сильную модель. Если источники противоречат друг другу, система должна не «додумывать среднее», а показать расхождение.
Главная метрика здесь — не только качество текста. Нужны Citation Correctness, время до первого полезного фрагмента, доля запросов без достаточного источника и стоимость успешного ответа.
ИИ-хостес: разговор дешёвый, запись дорогая
В июльском дайджесте Яндекс описывает агента, который принимает звонки, проверяет свободные слоты и оформляет бронирования. Это хороший пример разделения языка и действия.
Модель может свободно перефразировать вопрос о времени. Но создание брони должно идти через типизированный Tool с проверкой телефона, заведения, даты, количества гостей и Idempotency Key. Если диалоговая модель недоступна, можно переключить голосовой слой. Если недоступна система бронирования, нельзя «fallback-нуть» на выдуманное подтверждение.
Fallback допустим для формулировки. Для факта или транзакции нужен источник истины, а не запасная фантазия.
Мультимодальность должна включаться по событию
Alice AI VLM позволяет искать объекты и события в видеоархиве. Но прогонять тяжёлую VLM по каждому кадру дорого и медленно. Практическая схема использует каскад: дешёвый детектор выделяет события, embeddings индексируют фрагменты, VLM подробно описывает только кандидатов, а текстовая модель формирует ответ.
Такая маршрутизация сокращает стоимость и делает ошибку локализуемой. Можно отдельно проверить детектор, поиск по индексу и финальное описание.
Карты напоминают: LLM не должна владеть всем решением
Яндекс сообщил о более чем 400 прогулочных маршрутах в 36 городах. В подобном продукте модель хорошо рассказывает об объекте и адаптирует стиль. Но длину пути, доступность улиц и порядок точек должен рассчитывать географический движок.
Полезная граница проста: детерминированная система отвечает за то, что можно вычислить; модель — за то, что нужно понять или выразить. Чем важнее ограничение, тем опаснее оставлять его только в Prompt.
Router должен видеть состояние, а не только текст
Минимальное решение принимает во внимание:
route = choose_model(
task="search_synthesis",
modality=["text", "image"],
latency_budget_ms=1800,
max_cost_usd=0.03,
context_tokens=42000,
requires_tools=True,
data_class="internal",
fallback_profile="grounded_only"
)Модель выбирается не по одному полю. Запрос с картинкой требует VLM; длинный документ — большого контекста; персональные данные ограничивают список провайдеров; голосовой сценарий задаёт жёсткий бюджет задержки.
Пять правил здоровой мультимодельной архитектуры
1. Маршрутизируйте по типу работы, а не по длине Prompt.
2. Отделяйте генерацию от источника истины. Календарь, цена и география приходят из Tool.
3. Fallback должен сохранять контракт. Если резерв не умеет цитировать источники, он не заменяет grounded-модель.
4. Логируйте решение Router. Команда должна знать, почему был выбран профиль и сколько стоил весь pipeline.
5. Оценивайте цепочку по этапам. Итоговая оценка скрывает, где именно возникла ошибка.
Где нужен OpenAI-compatible Gateway
OdiRouter.ai и другие совместимые Gateway дают единую точку доступа к разным моделям. Это позволяет менять модель внутри маршрута, не переписывая клиентский SDK, централизованно считать Token и организовать Fallback.
Но Gateway не должен угадывать продуктовый смысл. Он знает контекст, цену и доступность модели; приложение знает, является ли ответ черновиком, фактом или транзакцией. Хорошая архитектура соединяет эти два слоя, не подменяя один другим.
Пользователь хочет один понятный AI-продукт. Именно поэтому внутри продукта не должна жить одна модель.
Поиск требует Retrieval, камера — VLM, разговор — низкой задержки, сложный анализ — сильного reasoning, а бронь — строгого Tool Call. Мультимодельность не усложняет продукт ради технологии. Она не позволяет самой дорогой и непредсказуемой части системы принимать каждое решение.