Языковые модели (LLM): Qwen3 8B, Qwen2.5 (7B/14B/32B), Llama 3.2, Mistral Nemo, llava (vision). Админ выбирает модель в дашборде. Подробнее — Модели LLM.
| Модель | Граф | Оркестратор |
|---|---|---|
| Compliance | Extractor → Checker → Risk → Critic → Action | Нет |
| Feedback | Analyzer → Researcher → Responder → Critic → Escalation | Нет |
| Operations | Orchestrator → Resolver → Critic → Executor → Notify | Да |
Документ проходит фиксированную последовательность: извлечение сущностей, проверка на соответствие нормам, оценка рисков, верификация и финальное решение. Каждый шаг не требует разбиения на подзадачи — поток жёстко определён.
Извлекает стороны договора, суммы, даты, коды маркировки, номера сертификатов. Отдельная роль — чтобы не смешивать OCR/парсинг с логикой проверки. Ошибка извлечения не должна влиять на интерпретацию норм.
Проверяет соответствие нормативам: 152-ФЗ, ФСТЭК (приказы 17/21/117), маркировка Честный Знак. Набор нормативов настраивается под клиента. Результат — структурированный список нарушений или подтверждение соответствия.
Оценивает финансовые последствия: штрафы за единицу без маркировки, за партию без сертификата. Отдельная роль — оценка риска требует иной prompt-логики, чем проверка формальных требований.
Верифицирует результат перед финальным действием. Может вернуть задачу на Extractor при недостаточной полноте извлечения. Цикл до 3 итераций снижает долю ложных срабатываний и пропусков.
Обращение клиента проходит цепочку: анализ тональности и тем, поиск в базе знаний (RAG), генерация ответа, проверка качества и решение об эскалации. Поток жёстко определён, без оркестратора.
Определяет тональность (негатив, нейтрал, позитив), выделяет темы и срочность. Результат используется Responder и Escalation. Отдельная роль — не смешивать анализ с генерацией ответа.
Ищет в базе знаний релевантный контекст: регламенты, прецеденты, FAQ. Ответ привязывается к вашим правилам и документам, а не только к общей модели.
Генерирует ответ клиенту на основе анализа и контекста из RAG. Настраивается по тону (эмпатия, формальность) и целям пресета.
Проверяет ответ на соответствие регламенту и тону. Может вернуть на доработку. Снижает риск некорректных или грубых ответов.
Определяет, нужно ли передать обращение человеку (жалоба, негатив, сложный кейс). Флаг эскалации передаётся в CRM или тикет-систему.
Операционные процессы требуют декомпозиции: запрос на согласование договора, закупки или отпуска — разные типы с разными цепочками. Оркестратор определяет маршрут и подзадачи.
Классифицирует тип запроса (договор, закупка, отпуск, IT-запрос), декомпозирует на подзадачи и выбирает цепочку согласующих. Маршрутизация зависит от суммы, срочности и регламентов. Модель 70B для сложных решений.
Назначает конкретных согласующих по оргструктуре (LDAP/AD). Учитывает делегирование, отпуска, нагрузку. Формирует цепочку: юрист, финдир, ГД — в зависимости от типа и порога.
Пауза для решения человека. Может вернуть задачу к агенту роли Resolver при изменении маршрута или делегировании. Продолжение с любой точки графа.
Выполняет действие после одобрения: создание задачи в 1С, Bitrix24, отправка в ЭДО. Не принимает решений — только исполнение по результату Human-in-the-Loop.
Отправка уведомлений согласующим и инициатору. Интеграция с Email, Telegram, Bitrix24.
Несколько агентов одной роли (например, 4 Risk или 4 Critic) независимо дают ответ; итог определяется по большинству — уровень риска, одобрить/отклонить, тональность обращения, нужна ли эскалация. Снижает влияние случайной ошибки одного агента. В логах и диалоге отображаются реплики вида «Risk Assessor (голосование)», «Critic (голосование)».
Два агента дают разные варианты (например, «одобрить» vs «отклонить» или два варианта ответа клиенту), затем узел Judge выбирает лучший по аргументам. Используется там, где важно сравнить обоснования, а не усреднить. В диалоге видны «Critic (дебаты)», «Judge» и т.д. Точная схема отображается в дашборде в разделе «Диалог агентов».
Модуль компьютерного зрения встраивается в любую схему агентов, где это применимо. Vision-модель (llava) анализирует изображения: проверяет наличие печатей и подписей на документах, распознаёт скриншоты ошибок в обращениях клиентов, классифицирует фотографии товаров. Результат передаётся следующим агентам как дополнительный контекст. Включается флагом use_vision в конфиге или API. Примеры: Compliance — проверка печатей на договорах; Feedback — анализ скриншотов в обращении.
Когда один агент и извлекает данные, и проверяет нормы, и решает — он чаще ошибается и «галлюцинирует». Мы разбиваем работу на роли: один извлекает, другой проверяет, третий оценивает риски, четвёртый может отправить на доработку. Каждый делает своё, следующий перепроверяет. В итоге меньше пропусков и ложных срабатываний, и всегда понятно, на каком шаге что произошло. Плюс под новый сценарий можно перенастроить цепочку, а не переписывать одну большую модель.
Пилотный контур обычно поднимаем за 1–2 месяца: развёртывание на ваших серверах, подключение к ключевым системам (1С, CRM, ЭДО — по необходимости), обучение команды. Дальше — масштабирование под ваши процессы. Срок зависит от объёма интеграций и сложности регламентов.
Да. Одна из основных моделей — комплаенс: проверка договоров, актов, накладных на соответствие 152-ФЗ и маркировке Честный Знак. Цепочка агентов извлекает данные, сверяет с нормативами, оценивает риски и штрафы, верифицирует результат. Всё на вашем периметре, без отправки документов вовне.
То, что вводит пользователь, у нас не подмешивается к служебным инструкциям агентов — у ввода своё место, агенты работают уже с обработанными данными. По критичным решениям (например, «документ прошёл» или «заблокировать») всегда есть шаг с человеком: система предлагает, человек подтверждает. Всё крутится у вас на серверах, в облако ничего не уходит — значит, и подменить промпт извне по сути некуда, плюс вы видите все логи.
Всё считается у вас: ставите модели на свои серверы или в своё облако — документы и обращения за пределы вашей инфраструктуры не уходят. В публичные API мы ничего не шлём. Смотреть данные и логи могут только ваши люди. Под 152-ФЗ и отраслевые требования закладываемся с самого начала, когда проектируем контур и настраиваем проверки.
Оркестратор нужен там, где есть декомпозиция запроса на подзадачи, маршрутизация по типу запроса или параллельное выполнение. В Compliance и Feedback поток линейный с одной точкой ветвления (Critic) — роли жёстко заданы, документ или обращение проходят один путь. В Operations один запрос порождает несколько подзадач, маршрут зависит от суммы и типа — без оркестратора граф стал бы неподдерживаемым.
Да. Агенты работают с вашими нормативами, регламентами и прецедентами через RAG: база знаний настраивается под клиента, запросы к ней выполняют выделенные роли (например, Researcher в Feedback). Так ответы и проверки привязаны к внутренним правилам компании, а не к общим данным модели. Пресеты можно менять под сценарий без смены топологии графа.
Администраторы настраивают веса агентов (strictness, verbosity и др.) и общие задачи модели через конфигурацию. Пресеты задают профиль под сценарий: быстрая проверка, глубокая проверка, регрессия — с разными параметрами по ролям.
Схему менять не требуется. Гибкость достигается настройкой весов и параметров агентов под задачи клиента. Разные пресеты меняют поведение без изменения топологии графа.
Выберите модель и разверните граф агентов внутри вашего периметра.
Заказать тест