Skip to content

07. Мультиагентный дизайн

Навигация: Назад: Архитектура | Далее: База знаний

Оглавление

Мультиагентная архитектура

Мультиагентная архитектура — это ядро SmartSupport. Здесь мы фиксируем логические роли агентов, чтобы их можно было реализовать на любом стеке (LangGraph, свой оркестратор, Celery+RabbitMQ и т.п.) без жёсткой привязки к вендорам. Важно: в этом разделе мы сводим воедино все агенты, которые уже упоминались ранее, и показываем, как они взаимосвязаны.

Зачем мультиагенты

Почему мы идём не в сторону «одного большого бота», а в сторону набора агентов: 1. Разделение ответственности
• Один агент = одна чёткая задача.
• Проще тестировать, дорабатывать и масштабировать.
2. Масштабируемость и отказоустойчивость
• Можно отдельно наращивать мощности для «тяжёлых» агентов (RAG, генерация ответов).
• При сбое одного агента система продолжает работать частично.
3. Прозрачность и управляемость
• В логах видно: где ошибка — Router, Retrieval, Answer, Judge.
• Понятно, за что отвечает каждый компонент.
4. Гибкая эволюция
• Можно заменить реализацию конкретного агента (например, сменить модель ИИ) без ломки логики остальных.
5. Соответствие нашей стратегии
• Наша цель — максимальная автоматизация, где ИИ выполняет всё больше шагов в цепочке: понимание → уточнение → поиск → генерация ответа → создание задачи → контроль качества.

Общий дизайн LLM Service

LLM Service — это отдельный backend-сервис, внутри которого живут все агенты. Остальная система (каналы, backend, БЗ, аналитика) общается только с LLM Service через API / message queue.

Поток запроса (упрощённо): 1. Входящее событие (обращение / пост из соцсети) →
2. Agent Router — решает, какие агенты должны участвовать →
3. Classification Agent — определяет тип/категорию →
4. (При необходимости) Retrieval Agent — достаёт знания из RAG →
5. Answer Generator Agent — формирует ответ/задачу →
6. Quality/Safety Judge Agent — проверяет адекватность, тон, безопасность →
7. Результат возвращается в основной backend (ответ гражданину, задача исполнителям, запись в БЗ/аналитику).

Для внутренних задач (например, обновление БЗ, аналитика, Social Monitoring) в цепочку включаются KB Curator Agent и Analytics Agent.

Соответствие с ранее описанными агентами

Чтобы не было расхождений между разделами, фиксируем маппинг: - Agent Router ↔ ранее: Agent Router (2.2, 4, 6 разделы)
- Classification Agent ↔ ранее: Classification Agent / Classifier Agent
- Retrieval Agent (RAG) ↔ ранее: часть функций Knowledge Agent / RAG Service
- Answer Generator Agent ↔ ранее: Operator Assist Agent (формирование подсказок, ответов)
- Quality/Safety Judge Agent ↔ ранее: логическое развитие Audit Agent (контроль регламентов, качества, тональности)
- KB Curator Agent ↔ ранее: вспомогательный ИИ для Knowledge Managers (составителей БЗ)
- Analytics Agent ↔ ранее: часть функций Analytics Service, в ИИ-части — анализ паттернов, трендов
- Monitoring Agent (упоминался раньше) → по сути композиция: Retrieval Agent + Analytics Agent, работающих на данных соцсетей
- Task Creation Agent, Summarization Agent (упоминались в архитектуре) → это специализированные роли, которые можно рассматривать как подтипы Answer Generator / Analytics, и они не противоречат текущему списку, а лишь уточняют его.

Таким образом, текущий раздел описывает базовые “логические роли”, а доменные агенты (Monitoring, Task Creation, Summarization) — это конкретные применения этих ролей.

Agent Router

Задача: Определить, что это за запрос и какой pipeline агентов нужно запустить.

Вход: - текст обращения; - метаданные канала (Max/Telegram/VK/веб); - контекст пользователя (если есть).

Выход: - тип запроса (вопрос, жалоба, 59-ФЗ, инфраструктура, FAQ, системная операция и т.п.); - маршрут: какие агенты участвуют (Classification → Retrieval → Answer → Judge…), или, например, сразу в Analytics/Monitoring.

Ключевые особенности: - должен быть быстрым и лёгким (можно на более дешёвой модели); - держит в себе бизнес-логику: какой тип запросов идёт в какой pipeline; - может использовать правила + ML-модель.

Classification Agent

Задача: Перевести «сырой текст обращения» в структурную категорию и дополнительные параметры.

Примеры категорий: - ЖКХ → Освещение / Водоснабжение / Дороги / Мусор; - Социальная сфера; - Образование; - Культура; - Вопрос по услугам; - Инцидент / Авария; - Простая справка (FAQ).

Вход: - текст обращения; - результат от Agent Router.

Выход: - категория; - подкатегория; - тип срочности; - возможный тип SLA; - признаки 59-ФЗ (для госов).

Роль в системе: - определяет, в какой департамент / службу пойдёт задача; - помогает Analytics Agent строить аналитику по темам.

Retrieval Agent (RAG)

Задача: Найти релевантные знания в базе: - регламенты; - инструкции; - FAQ; - прошлые обращения; - кейсы.

Вход: - сформулированный запрос (от Router/Classification/Answer Generator); - контекст (язык, канал, тип пользователя).

Выход: - набор релевантных документов/фрагментов; - метаданные (источник, дата, качество).

Особенности: - работает с векторной БД (Qdrant/др.) + полнотекстовым индексом; - важен hybrid search (семантика + ключевые слова + фильтры по метаданным); - должен возвращать не просто текст, а структурированный контекст для Answer Generator.

По сути, Retrieval Agent — «глаза и память» системы.

Answer Generator Agent

Задача: Сгенерировать готовое сообщение или чётко структурированную задачу.

Это логическое развитие/уточнение того, что ранее называлось Operator Assist Agent.

Варианты использования: 1. Ответ гражданину:
• дружелюбный, понятный текст;
• с учётом канала (формальность, длина);
• с отсылками на БЗ/регламенты, если нужно.
2. Задача исполнителям:
• категория + описание;
• адрес, время, вложения;
• предлагаемый SLA;
• статус (новая/срочная).
3. Внутренние комментарии оператору:
• что проверить;
• что уточнить;
• какие шаги предпринять.

Вход: - исходный текст обращения; - контекст от Retrieval Agent (фрагменты БЗ); - данные от Classification Agent.

Выход: - текст ответа; - структура задачи; - пояснительный комментарий.

Quality / Safety Judge Agent

Задача: Проверить, насколько ответ/действие агента корректны, безопасны и соответствуют политике.

Это развитие концепции Audit Agent из предыдущих разделов.

Что проверяет: - нет ли токсичности или агрессии в ответе; - нет ли разглашения лишних персональных данных; - не даёт ли ИИ «опасных» советов; - соответствует ли ответ регламентам (если есть жёсткие правила); - нет ли откровенной галлюцинации (ответ “ни о чём”).

Варианты поведения: - одобрить ответ → отправить; - отклонить ответ → запросить пересоздание; - пометить ответ оператору как «требует внимания».

Роль: - центральный элемент Guardrails & Safety; - основа для доверия к автономной обработке.

KB Curator Agent

Задача: Помогать Knowledge Managers создавать и поддерживать базу знаний.

Функции: - из реальных диалогов и кейсов формировать черновики статей; - предлагать обновления устаревших статей; - находить дубликаты; - рекомендовать, какие темы нужно закрыть статьями; - помогать структурировать БЗ (разделы, теги, онтологии).

Вход: - история обращений; - показатели повторяемости вопросов; - текущие статьи БЗ.

Выход: - предложения по новым статьям; - предложения по обновлению/слиянию статей; - draft-контент для БЗ.

KB Curator Agent превращает БЗ из «мертвого документа» в живую, постоянно улучшающуюся систему.

Analytics Agent

Задача: Использовать ИИ для выявления паттернов, трендов, аномалий.

Данные: - обращения; - задачи; - активности по районам; - сигналы от Social Monitoring; - временные ряды (динамика обращений, всплески тем).

Что делает: - выявляет новые тенденции (например, рост обращений по освещению в конкретном районе); - помогает считать индекс социальной напряжённости; - помогает формировать «умные» отчёты для руководства; - выявляет темы, по которым плохо работает БЗ или ИИ.

Связь с Monitoring Agent: Monitoring Agent в прошлых разделах — это по сути композиция Retrieval + Analytics Agent, настроенная на данные соцсетей и локальных чатов.

Guardrails & Safety

Guardrails — это набор правил, ограничений и проверок, обеспечивающих безопасную работу мультиагентной системы.

Состоит из: 1. Политик уровня продукта
• какие темы допустимы/недопустимы;
• как оформлять ответы (формально / неформально / официально).
2. Фильтров и маскирования данных
• защита персональных данных;
• сокрытие внутренних идентификаторов.
3. Механизмов пересмотра ответа
• Quality/Safety Judge Agent;
• fallback к оператору.
4. Логирования и аудита
• сохранение всех решений ИИ;
• возможность послесмертного анализа.
5. Ограничения на автономные действия
• какие действия ИИ может совершать без человека (мы определяем по этапам: Assisted → Automated → Autonomous).

Концепция «logic, not framework»

Ключевой принцип:

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

Это значит: - Агент — это роль и контракт (что принимает, что отдаёт). - Фреймворк (LangGraph, свой оркестратор, Celery-флоу) — это просто способ исполнения. - Мы не «шьём» архитектуру под конкретный продукт Google, OpenAI, Yandex и т.п. - Это критично для госов и on-premise: фреймворк можно заменить, логика останется.

Варианты реализации (без vendor lock-in)

Мы сознательно не завязываемся на Google ADK как основной фреймворк, чтобы: - не зависеть от западного вендора; - не иметь проблем с импортозамещением; - свободно разворачивать систему on-premise в закрытых контурах.

Вместо этого: 1. LangGraph / похожие open-source оркестраторы
• удобны для построения графов агентов;
• хорошо подходят для Python-стека (который мы и так используем).
2. Собственный оркестратор поверх очередей (RabbitMQ + Celery/Redis)
• полностью контролируемая логика;
• легко деплоится в гос-инфраструктуре;
• нет внешних зависимостей.
3. Смешанный подход
• часть сценариев (простых) — через лёгкий оркестратор;
• сложные флоу — через более продвинутый graph-фреймворк;
• возможность миграции без пересборки логики агентов.

Итог: В Product Handbook мы фиксируем состав и обязанности агентов, а не конкретный фреймворк. Реализация может отличаться от инсталляции к инсталляции (SaaS, регион, конкретный заказчик), но логика остаётся единой.