6.3 Аналогия с микросервисной архитектурой

В веб-разработке переход от монолита к микросервисам позволил:

· разделить ответственность;

· масштабировать части независимо;

· изолировать сбои.

В ИИ происходит то же самое: от одной модели «на всё» - к множеству специализированных моделей, взаимодействующих через шину данных (message bus).

В микросервисах после разделения на отдельные службы встаёт следующий вопрос: как они будут общаться между собой?

Просто слать друг другу сырой текст - неэффективно и ненадёжно. Поэтому придумали message bus - единую шину, через которую сервисы обмениваются структурированными сообщениями.

Та же логика работает и в мире ИИ-моделей. Если у нас есть роутер, несколько специализированных моделей, а в перспективе ещё и агенты, им нужен общий язык. Не просто текст, а контейнеры с метаданными, эмбеддингами, уверенностью и временем жизни. Так рождается единая шина для обмена контекстом - следующий кирпичик нашей архитектуры.

6.4 Единая шина для обмена контекстом

Модели общаются не через сырой текст, а через структурированные контейнеры ответов, содержащие:

· текст;

· векторы (эмбеддинги);

· метаданные (уверенность, время жизни, источник).

СТРУКТУРА СООБЩЕНИЯ В ШИНЕ:

{

"message_id": "req_123456",

"timestamp": "2025-03-14T10:30:00Z",

"source": "router",

"target": "deepseek_math",

"payload": {

"text": "Реши уравнение x^2 + 5x + 6 = 0",

"tokens": 12,

"language": "ru",

"domain": "math",

"complexity": 0.85

},

"context": {

"previous_messages": ["msg_111", "msg_222"],

"embeddings": [0.23, -0.56, ..., 0.89], // сжатый контекст (важно: эмбеддинги

// должны быть приведены к единому пространству, например, через общую

// проекцию, иначе модель-получатель их не поймет)

"kv_cache_hint": "cache_abc123" // если передаем между моделями

},

"metadata": {

"priority": "high",

"timeout": 30,

"budget": 0.05,

"required_accuracy": 0.95

}

}

ЧТО ЭТО ДАЕТ

· Не нужно прогонять контекст через LLM повторно, экономя токены и ускоряя работу

· Модели могут обмениваться не только текстом, но и внутренними состояниями

· Роутер видит полную картину и может оптимизировать маршруты

Шина уже позволяет моделям перебрасываться структурированными сообщениями, но этого мало, когда контекст достигает астрономических размеров - миллион токенов и больше.

Даже умный роутер не поможет, если ни одна модель физически не способна проглотить такой объём.

Здесь архитектура делает следующий шаг: от пассивной маршрутизации к активной декомпозиции.

Модель перестаёт читать весь контекст сама - вместо этого она пишет код, который запускает суб-модели на отдельных фрагментах данных.

Это рекурсивные языковые модели (RLM). Идея блестящая, но за ней скрывается тёмная сторона: код, написанный моделью, может случайно (или намеренно) натворить бед. Поэтому, прежде чем восторгаться, разберём риски и способы защиты.

6.5 RLM - Recursive Language Models (Рекурсивные языковые модели)

Архитектура, в которой основная модель не обрабатывает весь контекст сама, а пишет код, который выполняется в специальном окружении. Из окружения вызываются суб‑модели, каждая для своей части данных.

Результаты

· контекст в 100 раз больше нативного окна;

· расход токенов основной модели в 2–3 раза меньше;

· точность на сложных задачах растёт.

RLM НА ПРИМЕРЕ: АНАЛИЗ НАУЧНОЙ СТАТЬИ (1M ТОКЕНОВ)

Тёмная сторона RLM: безопасность выполнения кода

Идея RLM звучит красиво: модель пишет код, код выполняется, вызываются суб-модели. Но есть одна проблема: код, написанный моделью, может быть опасным. Не потому что модель злая, а потому что она может ошибиться - и ошибиться катастрофически.

Риски, о которых нельзя забывать

Бесконечные циклы

Модель может написать код, который никогда не завершится. Ваш рантайм зависнет, а токены будут гореть зря.

Рекурсивные вызовы самих себя

Модель может случайно вызвать саму себя, создав бесконечную рекурсию, которая убьёт всю систему.

Доступ к файловой системе

Если код выполняется с правами пользователя, модель может случайно (или специально, если её взломали) удалить файлы, прочитать конфиденциальные данные.

Сетевые вызовы

Код может попытаться скачать что-то из интернета или отправить данные вовне. Хорошо, если это часть задачи, а если нет?

Инъекции

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

Как инженеры решают эти проблемы

Песочница ( sandbox ) - обязательное условие

· Код, сгенерированный моделью, никогда не должен выполняться в основном окружении. Только в изолированной среде с минимальными правами:

· Нет доступа к файловой системе (кроме специально выделенной временной папки)

· Нет сетевых запросов (кроме явно разрешённых API)

· Ограничение по времени (если код не уложился в 5 секунд - убить процесс)

· Ограничение по памяти (чтобы не положить сервер)

Валидация кода перед выполнением

Можно прогнать сгенерированный код через статический анализатор, который ищет опасные паттерны. Например, запретить вызовы eval(), exec(), os.system() и подобные.

Белый список разрешённых операций

Вместо того чтобы разрешать модели писать произвольный код, можно дать ей ограниченный набор «инструментов» - предопределённых функций с чётко заданным поведением. Тогда модель не пишет код с нуля, а комбинирует готовые безопасные блоки.

Аудит и логирование

Все сгенерированные и выполненные фрагменты кода должны логироваться. Если что-то пойдёт не так, у вас будет улика.

Практический вывод

RLM - мощный инструмент, но использовать его без защиты - всё равно что запустить незнакомца в серверную. Обязательно изолируйте выполнение, ограничивайте права и следите за тем, что происходит. Только тогда рекурсивные модели станут не опасной игрушкой, а рабочим инструментом.

ШАГ 3: Результат

Итоговый расход:

• Основная модель: 1000 токенов (написание кода)

• Специализированные модели: ~100K токенов всего

• Экономия: в 10 раз меньше, чем если бы основная модель читала всё.

RLM - это частный случай более широкой парадигмы: несколько моделей работают в связке, передавая друг другу управление.

Но если в RLM модель пишет код, который вызывает другие модели, то следующий уровень - это агентные системы, где модели выступают как равноправные члены команды.

Одна планирует, другая генерирует, третья критикует, четвёртая проверяет факты. И вся эта команда координируется через ту же единую шину, но уже с более сложными протоколами взаимодействия.

Это уже не просто «разделяй и властвуй», а настоящий оркестр. Посмотрим, как дирижёр (оркестратор) управляет этим ансамблем.