Три бизнес-модели: Compliance — линейный поток, Feedback — анализ обращений, Operations — иерархия с оркестратором и декомпозицией задач.
Документ проходит фиксированную последовательность: извлечение сущностей, проверка на соответствие нормам, оценка рисков, верификация и финальное решение. Каждый шаг не требует разбиения на подзадачи — поток жёстко определён.
Извлекает стороны договора, суммы, даты, коды маркировки, номера сертификатов. Отдельная роль — чтобы не смешивать OCR/парсинг с логикой проверки. Ошибка извлечения не должна влиять на интерпретацию норм.
Проверяет соответствие нормативам: 152-ФЗ, ФСТЭК (приказы 17/21/117), маркировка Честный Знак. Набор нормативов настраивается под клиента. Результат — структурированный список нарушений или подтверждение соответствия.
Оценивает финансовые последствия: штрафы за единицу без маркировки, за партию без сертификата. Отдельная роль — оценка риска требует иной prompt-логики, чем проверка формальных требований.
Верифицирует результат перед финальным действием. Может вернуть задачу на Extractor при недостаточной полноте извлечения. Цикл до 3 итераций снижает долю ложных срабатываний и пропусков.
Фиксирует финальное решение: принять документ или заблокировать с указанием нарушений. Результат передаётся в вашу систему (1С, ЭДО, ЛК).
Обращение клиента проходит цепочку: анализ тональности и тем, поиск в базе знаний (RAG), генерация ответа, проверка качества и решение об эскалации. Поток жёстко определён, без оркестратора.
Определяет тональность (негатив, нейтрал, позитив), выделяет темы и срочность. Результат используется Responder и Escalation. Отдельная роль — не смешивать анализ с генерацией ответа.
Ищет в базе знаний релевантный контекст: регламенты, прецеденты, FAQ. Ответ привязывается к вашим правилам и документам, а не только к общей модели.
Генерирует ответ клиенту на основе анализа и контекста из RAG. Настраивается по тону (эмпатия, формальность) и целям пресета.
Проверяет ответ на соответствие регламенту и тону. Может вернуть на доработку. Снижает риск некорректных или грубых ответов.
Определяет, нужно ли передать обращение человеку (жалоба, негатив, сложный кейс). Флаг эскалации передаётся в CRM или тикет-систему.
Операционные процессы требуют декомпозиции: запрос на согласование договора, закупки или отпуска — разные типы с разными цепочками. Оркестратор определяет маршрут и подзадачи.
Классифицирует тип запроса (договор, закупка, отпуск, IT-запрос), декомпозирует на подзадачи и выбирает цепочку согласующих. Маршрутизация зависит от суммы, срочности и регламентов. Модель 70B для сложных решений.
Назначает конкретных согласующих по оргструктуре (LDAP/AD). Учитывает делегирование, отпуска, нагрузку. Формирует цепочку: юрист, финдир, ГД — в зависимости от типа и порога.
Пауза для решения человека. Может вернуть задачу к агенту роли Resolver при изменении маршрута или делегировании. Продолжение с любой точки графа.
Выполняет действие после одобрения: создание задачи в 1С, Bitrix24, отправка в ЭДО. Не принимает решений — только исполнение по результату Human-in-the-Loop.
Отправка уведомлений согласующим и инициатору. Интеграция с Email, Telegram, Bitrix24.
В трёх моделях — Compliance, Feedback, Operations — доступны опциональные режимы без смены основной схемы. Включаются в пресетах и задаются в дашборде или API флагами use_voting и use_debate.
Несколько агентов одной роли (например, 4 Risk или 4 Critic) независимо дают ответ; итог определяется по большинству — уровень риска, одобрить/отклонить, тональность обращения, нужна ли эскалация. Снижает влияние случайной ошибки одного агента. В логах отображаются реплики вида «Risk Assessor (голосование)», «Critic (голосование)».
Два агента дают разные варианты (например, «одобрить» vs «отклонить» или два варианта ответа клиенту), затем узел Judge выбирает лучший по аргументам. Используется там, где важно сравнить обоснования, а не усреднить. В диалоге видны «Critic (дебаты)», «Judge» и т.д. Схема отображается в дашборде в разделе «Диалог агентов».
Модуль компьютерного зрения встраивается в любую схему агентов. Vision-модель (llava) анализирует изображения: проверяет наличие печатей и подписей на документах, распознаёт скриншоты ошибок в обращениях, классифицирует фотографии товаров. Включается флагом use_vision в конфиге или API. Примеры: Compliance — проверка печатей на договорах; Feedback — анализ скриншотов в обращении.
Один агент, который и извлекает данные, и проверяет нормы, и принимает решение, чаще даёт ошибочные выводы. Мы распределяем задачи по ролям: один модуль извлекает данные, другой проверяет соответствие нормативам, третий оценивает риски, четвёртый может вернуть на доработку. Каждый этап перепроверяется следующим. В результате — меньше пропусков и ложных срабатываний, полная прослеживаемость решений. Для новых сценариев достаточно перенастроить цепочку, без переработки всей системы.
Пилотный проект разворачивается за 1–2 месяца: установка на ваших серверах, подключение к ключевым системам (1С, CRM, ЭДО — по потребности), обучение сотрудников. Далее — масштабирование под ваши процессы. Срок зависит от объёма интеграций и сложности регламентов.
Да. Одно из основных решений — комплаенс: проверка договоров, актов, накладных на соответствие 152-ФЗ и маркировке «Честный знак». Цепочка модулей извлекает данные, сверяет с нормативами, оценивает риски и штрафы, верифицирует результат. Обработка выполняется в вашем периметре, документы за его пределы не передаются.
Ввод пользователя не смешивается со служебными инструкциями агентов: данные обрабатываются в выделенном контуре, агенты получают уже подготовленный контекст. По критичным решениям (принятие документа, блокировка) предусмотрен обязательный шаг с ответственным сотрудником. Защита соответствует требованиям приказа ФСТЭК России № 117. Обработка выполняется на ваших серверах, все действия фиксируются в логах.
Обработка выполняется в вашей инфраструктуре: модели на ваших серверах или в вашем облаке, документы и обращения за пределы компании не передаются. Публичные API не используются. Доступ к данным и логам есть только у ваших сотрудников. Соответствие 152-ФЗ и отраслевым требованиям закладывается на этапе проектирования.
Оркестратор используется там, где один запрос распадается на несколько подзадач, требуется маршрутизация по типу запроса или параллельное выполнение. В сценариях проверки документов и обработки обращений поток линейный — роли фиксированы, документ проходит единый путь. В сценариях согласований один запрос порождает несколько подзадач, маршрут зависит от суммы и типа операции — без оркестратора схема была бы сложна в поддержке.
Да. Система работает с вашими нормативами, регламентами и прецедентами через базу знаний (RAG), которая настраивается под вашу компанию. Обращения к ней выполняют выделенные модули. Ответы и проверки опираются на внутренние правила компании, а не на общие данные модели. Готовые пресеты можно менять под сценарий без изменения архитектуры.
У администраторов есть возможность тонкой настройки каждого из агентов в схеме через конфигурацию с помощью весов (строгость, детализация ответов и т.д.) для лучшего соответствия задачам. Отдельно предусмотрены пресеты — заготовленные настройки под типовые сценарии, в которых для ролей уже заданы нужные веса.
Саму схему обычно менять не требуется: можно использовать пресеты под разные задачи, сохранять несколько вариантов настроек одной схемы и применять одну и ту же команду агентов в разных сценариях. При необходимости схему можно дополнить (дебаты или голосование), а также подключить дополнительные схемы — например, не только комплаенс, но и схему для операционной деятельности.
Да. Модуль Vision подключается к сценариям проверки и обращений. Анализирует изображения: печати и подписи на документах, скриншоты в обращениях клиентов. Включается в конфигурации или через API.
Запустим мультиагентную систему на вашей инфраструктуре за 1–2 месяца. Без передачи данных в облако.