РЕЗЮМЕ К ГЛАВЕ 6
Архитектура решения
Проблема монолита: одна модель на всё - дорого, медленно, негибко; 80% простых запросов не требуют тяжёлой модели.
Роутинг моделей - классификатор перед запросом оценивает сложность, длину контекста, домен и направляет к нужной модели; экономия ресурсов до 70%.
Аналогия с микросервисами: как в веб-разработке перешли от монолита к микросервисам, так и в ИИ - от одной LLM к оркестру специализированных моделей.
Единая шина данных - модели общаются не сырым текстом, а структурированными сообщениями с эмбеддингами, метаданными, кэшем.
RLM (Recursive Language Models) - модель пишет код, который выполняется в рантайме и вызывает суб-модели; контекст в 100 раз больше, расход токенов в 2–3 раза меньше.
Агентные системы - команда моделей: планировщик, исполнитель, критик, факт-чекер, форматтер, координируемые оркестратором.
Переключение по длине контекста: до 100K - быстрая модель с MLA (GigaChat Ultra), до 1M - long-context модель (DeepSeek), выше - RLM-декомпозиция.
Роутер смотрит на 3 параметра: сложность (<0.3 → лёгкая модель), язык (не рус/англ → переводчик), домен (math → DeepSeek).
Формат сообщения в шине: содержит message_id, target, payload (текст, токены, домен), context (предыдущие сообщения, эмбеддинги), metadata (приоритет, бюджет).
Итог
Будущее не за одной гигантской моделью, а за оркестром специализированных, общающихся через шину под управлением умного роутера.
Интеграция данных
Главная проблема DWH и LLM: бухгалтер (DWH) говорит на языке цифр и ID, художник (LLM) хочет текст; нужен переводчик.
Решение 1 - денормализация: превращаем JSON-дампы в связный текст ("15 февраля компания X купила Y на сумму Z").
Решение 2 - агрегация: данные не влезают в контекст → бухгалтер готовит сводки, художник формулирует запрос, бухгалтер возвращает точную цифру.
Решение 3 - операционный слой: секретарь на входе держит горячие данные (последние часы/день), диспетчер решает, к кому идти - к секретарю или в DWH.
Решение 4 - надзиратель: прокси-слой проверяет права доступа, чтобы художник не проболтался о том, что не положено.
Решение 5 - журнал и tiered storage: художник ведёт дневник для аудита; горячие данные - в Redis, тёплые - в векторной БД, холодные - в DWH.
Практический пример
Как реализовать простой роутер на fastText? Инструкция по обучению классификатора и код для маршрутизации запросов между моделями - в Приложении 5.3.
Вопросы для самопроверки
1. Почему одна универсальная модель неэффективна для всех задач? Сколько примерно процентов запросов не требуют тяжёлой модели?
2. Как работает роутинг моделей и какие параметры он оценивает? Откуда взялась цифра 70% экономии и почему она не гарантирована?
3. В чём суть аналогии с микросервисной архитектурой? Что общего между переходом от монолита к микросервисам в веб-разработке и переходом от одной LLM к оркестру моделей?
4. Что такое RLM (Recursive Language Models) и зачем модели писать код вместо того, чтобы обрабатывать контекст самой? Какие риски безопасности при этом возникают и как их минимизировать?
5. Как устроена агентная система? Назовите роли в команде моделей и опишите пример их взаимодействия.
6. В чём заключается стратегия переключения по длине контекста? Какие модели используются на уровнях до 100K, до 1M и более 1M токенов и почему?
ГЛАВА 7. ЦИФРОВОЙ ДВОЙНИК ЧЕЛОВЕКА: ЕДИНОЕ ОКНО В ЦИФРОВОЙ МИР
7.1 Проблема: человек как узкое горлышко
Мы построили цифровой мир, но вход в него - по-прежнему человек. Он сам переключается между десятком приложений, копирует данные, помнит контексты, отслеживает дедлайны. Это неэффективно: человек тратит когнитивные ресурсы на работу коммутатора, а не на творчество и решения.
А значит, решение лежит на поверхности: нужно вынести коммутатора за скобки. Передать рутину ИИ-агенту, который станет вашим постоянным представителем в цифровой среде. Именно так рождается идея цифрового двойника как единого окна - персонального агента, который знает вас лучше, чем вы сами, и показывает только то, что действительно требует человеческого присутствия.
7.2 Идея: цифровой двойник как единое окно
Цифровой двойник - персональный ИИ-агент, который знает вас, представляет вас в цифровом мире и возвращает только то, что требует вашего внимания.
Звучит заманчиво, но за этой простотой скрывается фундаментальный вопрос: как технически построить агента, который одновременно и точен как калькулятор, и гибок как человек?
Просто взять большой языковой модель - недостаточно: он не будет вашим. Нужна многоуровневая конструкция, где личность, логика и действия не перемешаны, а строго разделены. Давайте разберём архитектуру двойника снизу вверх - от того, что делает его вами, до того, что он умеет делать.
