6.6 Агентные системы

Следующий уровень - системы, где несколько моделей работают как команда:

· одна планирует;

· другая генерирует;

· третья критикует;

· четвёртая проверяет факты.

Всё это координируется роутером и обменивается данными через единую шину.

АГЕНТНАЯ СИСТЕМА: КОМАНДА МОДЕЛЕЙ

ПРИМЕР РАБОТЫ (запрос: "Напиши статью про ИИ и проверь факты"):

1. Планировщик: разбивает на секции (введение, история, технологии, вывод)

2. Исполнитель: пишет черновик каждой секции

3. Критик: проверяет стиль, логику, связность

4. Факт-чекер: сверяет каждое утверждение с базой знаний

5. Исполнитель: исправляет ошибки

6. Форматтер: приводит к нужному стилю

7. Оркестратор: отдает пользователю

Мы нарисовали красивую картину: роутер, шина, рекурсивные вызовы, агенты.

Но инженер внутри вас требует конкретики: когда и какую модель выбирать на практике?

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

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

6.7 Переключение по длине контекста

Практическая реализация идеи:

· до 100K токенов - быстрая модель с MLA (GigaChat Ultra);

· от 100K до 1M - роутер переключает на специализированную long‑context модель (DeepSeek, Kimi, GPT‑5.4);

· сверхдлинные контексты - используются RLM‑подобные архитектуры с декомпозицией.

СТРАТЕГИЯ ПЕРЕКЛЮЧЕНИЯ ПО ДЛИНЕ КОНТЕКСТА:

УРОВЕНЬ 1: 0 - 100K токенов

Модель: GigaChat Ultra (или аналогичная с MLA)

Почему: MLA дает экономию памяти ×16, дешево держать контекст

Скорость: быстрая

Стоимость: низкая

УРОВЕНЬ 2: 100K - 1M токенов

Модель: DeepSeek / Kimi / GPT-5.4

Почему: специализированы на long context, есть оптимизации

Скорость: средняя

Стоимость: высокая

УРОВЕНЬ 3: > 1M токенов

Модель: RLM-архитектура (декомпозиция)

Почему: физически невозможно обработать 1M+ одной моделью

(даже с attention оптимизациями - память взорвется)

Скорость: зависит от декомпозиции

Стоимость: настраиваемая (можно экономить)

Мы научились выбирать модель под размер контекста: для коротких и средних окон - MLAмодель, для длинных - специализированного «дальнобойщика», для гигантских - RLMдекомпозицию.

Но есть класс задач, где проблема не в длине контекста, а в его типе.

Вы можете передать модели 10 тысяч токенов, но если эти токены - сырые строки из SQLтаблицы с ID и флагами, модель не поймёт ровно ничего.

А если запросить у неё точную сумму продаж за квартал — она либо ошибётся, либо нагаллюцинирует.

Потому что модели - художники, а в корпоративных данных живёт бухгалтер. Как их подружить, не разорившись на токенах и не нарушив compliance? Это уже вопрос не архитектуры моделей, а архитектуры данных вокруг ИИ.

Переходим к DWH и ИИ: как подружить бухгалтера и художника.

6.8 DWH (Data Warehouse) и ИИ: как подружить бухгалтера и художника

Представьте себе двух специалистов, которых вы наняли в свою компанию.

Первый - бухгалтер

Он носит строгий костюм, любит порядок, цифры и отчёты. У него всё разложено по полочкам: папки с документами подписаны, каждая копейка учтена, за любой прошлый год можно восстановить любую цифру. Если спросить его: «Сколько мы потратили на кофе в прошлом квартале?» - он через минуту даст точный ответ с копейками. Но если попросить: «Опиши атмосферу наших офисных посиделок» - он растеряется.

Второй - художник

Он ходит в свитере с красками, мыслит образами и идеями. Он схватывает суть, видит связи, может нарисовать яркую картину «как мы проводим время в офисе». Но спросите его: «А сколько точно мы потратили?» - он пожмёт плечами: «Ну, тысяча... или две... какая разница, главное - передать настроение»

Ваш DWH - это бухгалтер.

Ваша LLM - это художник.

И теперь вам нужно, чтобы они работали в одной команде. Бухгалтер хранит все цифры, но не умеет красиво рассказывать. Художник умеет рассказывать, но не знает цифр. Как их подружить?

Проблема первая

Художник не понимает бухгалтерских книг. Вы приводите художника в архив бухгалтера и говорите: «Вот все данные, рисуй». Художник открывает папку и видит:

Счёт 2654 от 15.02.2025, контрагент 789, сумма 1500.00, статья 401

Счёт 2655 от 15.02.2025, контрагент 790, сумма 2300.00, статья 401

Для бухгалтера это ясный язык: статья 401 - это «кофе», контрагент 789 - это «ООО Ромашка». Для художника - просто бессмысленный набор цифр.

Что происходит в реальности

LLM не понимает ваши схемы данных, foreign keys и ID. Если скормить ей JSON-дамп из таблицы, она либо запутается, либо начнёт галлюцинировать.

Решение: переводчик с бухгалтерского на человеческий

Перед тем как отдавать данные модели, их нужно перевести на язык, понятный художнику:

Было: {"id": 2654, "date": "2025-02-15", "contragent_id": 789, "amount": 1500.00, "article": 401}

Стало: "15 февраля 2025 года компания ООО Ромашка приобрела кофе на сумму 1500 рублей."

Как это сделать технически

· Сделать денормализованное представление данных (заменить ID на названия)

· Превратить строки таблицы в связные текстовые предложения

· Использовать шаблоны или небольшие модели для генерации текста

Плата за перевод

Вы теряете часть точности (художник может переставить слова), но получаете понимание контекста.

Проблема вторая

Бухгалтерский архив не влезает в мастерскую художника. У бухгалтера - огромный архив, годы документов, стеллажи до потолка. А художник работает в маленькой мастерской и может одновременно видеть только то, что помещается на его рабочий стол (контекстное окно).

Сейчас даже у самых продвинутых художников стол размером примерно с 100-страничную книгу (128K токенов). У некоторых - с 800-страничный том (1M токенов). Но архив бухгалтера - это тысячи таких томов.

Наивное решение

«А давайте затащим всё сразу»

Реальность

Художник либо задохнётся (память GPU кончится), либо вы потратите весь бюджет на аренду самосвалов (токенов).

Решение: многоступенчатый отбор

УРОВЕНЬ 1: БУХГАЛТЕР ДЕЛАЕТ СВОДКУ

Вместо того чтобы тащить каждую накладную, бухгалтер готовит резюме:

"За прошлый месяц было 1500 транзакций на общую сумму 2.3 млн рублей.

Топ-3 продукта: кофе (45%), чай (30%), печенье (15%)."

УРОВЕНЬ 2: ХУДОЖНИК ФОРМУЛИРУЕТ ЗАПРОС

Художник говорит: "Мне нужны детали по кофе за февраль"

Бухгалтер (через NL2SQL (Natural Language to SQL)-сервис) превращает это в точный запрос к базе.

УРОВЕНЬ 3: ТОЧНЫЙ ОТВЕТ БЕЗ ГАЛЛЮЦИНАЦИЙ

Бухгалтер возвращает точную цифру: 450 000 рублей.

Художник просто её озвучивает, ничего не додумывая.

Важный принцип

Художник НЕ считает сам. Он берёт готовые цифры у бухгалтера и только оформляет их в красивый ответ.

Проблема третья

Бухгалтер обновляет отчёты раз в день, а клиенты спрашивают каждую минуту

Бухгалтер привык работать по расписанию: в конце дня закрывает документы, ночью сводит отчёты. Утром данные актуальны на вчерашний вечер.

Художнику же звонят каждую минуту: «А что там с оплатой от Иванова, которая только что пришла?» А бухгалтер ещё не успел её учесть.

Решение: секретарь на входе

Здесь мы подходим к классической дилемме современных data-платформ: batch-обработка против real-time. Бухгалтер олицетворяет надёжные, но медленные ETL (Extract, Transform, Load) - процессы, которые строят витрины данных раз в сутки. Художник - это пользователь, который хочет ответ здесь и сейчас, включая данные, которые появились пять минут назад. Именно на стыке этих двух миров рождается гибридная архитектура.

Цена вопроса

Теперь у вас два источника правды - секретарь и бухгалтер. Нужно следить, чтобы они не противоречили друг другу.

Проблема четвёртая

Художник может проболтаться о том, что не положено

В бухгалтерии строго с секретностью. Младшим сотрудникам нельзя смотреть зарплату директора. Бухгалтер об этом знает и не выдаёт такие данные без допуска.

Художник, получив доступ ко всем данным, может случайно (или специально) выболтать лишнее. Он же художник, ему для «полноты картины» всё интересно.

Пример

В базе есть колонка salary (зарплата) с ограниченным доступом

Художник подключается через служебный аккаунт с полными правами

Пользователь спрашивает: «А какая средняя зарплата у наших конкурентов?»

Художник лезет в данные и отвечает, хотя не должен

Решение: строгий надзиратель между художником и бухгалтером

Проблема пятая

Налоговая не принимает картины в качестве отчёта

Приходит проверка: «Почему клиенту сказали, что его кредитная история плохая? На основании каких данных? Покажите документы»

Бухгалтер привык: на любой запрос есть бумажка, подпись, расчёт. Художник же пожимает плечами: «Ну, я так почувствовал... образно...»

Решение: художник ведёт дневник

Каждый раз, когда художник обращается к бухгалтеру, он записывает:

· Какой вопрос задал

· Какие данные получил

· Какой ответ дал

· Насколько был уверен

· Когда это было и кто спрашивал

ЖУРНАЛ ХУДОЖНИКА:

[15.03.2025 14:23] Пользователь: Иванов И.И.

Вопрос: "Сколько мы продали кофе в феврале?"

Данные от бухгалтера: "450 000 руб." (запрос #4587)

Ответ: "В феврале продажи кофе составили 450 000 рублей"

Уверенность: 0.99

Проблема шестая

Содержание художника и бухгалтера стоит денег

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

Решение: умное распределение задач

Правило

чем чаще данные нужны, тем ближе к художнику они должны лежать. Чем реже - тем глубже в архиве.

Как это реализуется технически? Классический паттерн - API Gateway. Все запросы от LLM к данным проходят через единый шлюз. Этот шлюз выполняет функции и «надзирателя» (проверяет JWT-токен и права доступа на основе политик, например, Open Policy Agent), и «секретаря» (маршрутизирует запрос либо в операционную БД (Redis/ClickHouse) для горячих данных, либо в DWH для холодных). Это изолирует логику безопасности и маршрутизации от самих моделей.

Сводка: как подружить бухгалтера и художника

Инженерный итог

Бухгалтер и художник могут работать вместе. Но для этого нужно:

· Научить художника понимать бухгалтерские книги - переводить данные в текст

· Научить бухгалтера готовить выжимки - агрегировать под контекст модели

· Поставить секретаря для срочных вопросов - горячий слой данных

· Нанять надзирателя за доступом - прокси с проверкой прав

· Заставить художника вести дневник - логировать всё

· Оптимизировать расходы - хранить данные по частоте запросов

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

Проекты в LLM-платформах: та же проблема, другие данные

Мы разобрали, как подружить DWH (бухгалтера) и LLM (художника) для корпоративных данных. Но есть ровно та же проблема на уровне самого диалога с ИИ.

Ситуация

Вы обсуждаете с LLM архитектуру трансформера. Перекинулись ссылками, набросали метафоры, поправили неточности. Через неделю открываете новый чат — и модель не помнит ничего. Ни ваших любимых примеров, ни того, что вы уже отвергли метафору «внимание как прожектор».

Проблема

LLM - stateless (не имеет состояния). Каждый новый чат - чистый лист. Но у вас есть проект - книга, курс, исследование. В рамках проекта чатов может быть десяток. И вы хотите, чтобы модель помнила контекст между ними.

Решение - то же, что в DWH и LLM

Что это значит для инженера

Память в проектах - это не «улучшенная модель», а «улучшенная платформа». Модель остаётся stateless, но вокруг неё строят слой хранения, индексации и поиска.

Та же архитектура, что в RAG: файлы → эмбеддинги → векторный поиск → подстановка в контекст. Разница только в том, что данные - это не бизнес-отчёты, а ваша переписка с ИИ.

Юридический нюанс

Проекты с памятью - это ещё один шаг к «цифровому двойнику» (глава 7). Модель начинает помнить вас, ваш стиль, ваш проект. А значит - и ваши слабые места.