Мультиагентная команда для due diligence: кейс и цифры

Инвестфонды и корпоративные юристы всё чаще выкладывают кейсы, где проверку компании перед сделкой — due diligence — ведёт не один чат-бот, а несколько LLM-агентов¹, которые делят задачу между собой: один тянет данные из реестров, другой читает договоры, третий сводит риски в отчёт. Идея не нова, но за 2024–2025 годы под неё появились рабочие фреймворки — LangGraph, CrewAI, AutoGen от Microsoft, OpenAI Agents SDK, — и цена входа упала до нескольких дней настройки вместо месяцев разработки. Разбираем, как выглядит такая команда на практике, что она реально ускоряет и где по-прежнему нужен человек.

Что такое due diligence и почему это боль

Due diligence — это проверка компании или актива перед сделкой: финансы, юридическая чистота, налоговые долги, суды, обременения, санкционные списки, репутация. Классический процесс — это команда из аналитика, юриста и финансиста, которая неделями разбирает сотни документов из data room². Дорого, медленно, и результат сильно зависит от того, не устал ли человек к трёхсотой странице.

Отсюда интерес к агентам. Не к одному большому промпту «проверь эту компанию», а к разделению труда: у каждого агента узкая роль, свой набор инструментов и свой критерий успеха. Такую конструкцию называют мультиагентной системой — несколько LLM-экземпляров общаются между собой и с внешними API, а оркестратор следит за порядком шагов.

Как устроена команда агентов

Типовая схема, которую собирают на LangGraph или CrewAI, выглядит так:

• Оркестратор — принимает запрос («проверь ООО «Ромашка» перед покупкой доли»), раскладывает его на подзадачи и распределяет между исполнителями.
• Агент-ресёрчер — ходит по открытым источникам и API: выписки из реестров, картотека арбитражных дел, базы исполнительных производств, санкционные и негативные списки.
• Агент-юрист — читает загруженные договоры и учредительные документы, ищет нетиповые условия, обременения, залоги, права третьих лиц.
• Агент-финансист — разбирает отчётность и первичку, считает базовые коэффициенты, помечает аномалии.
• Агент-критик (reviewer) — проверяет выводы остальных на противоречия и требует ссылку на источник для каждого утверждения.
• Агент-редактор — сводит всё в единый отчёт с уровнями риска.

Ключевая деталь — не сама генерация текста, а инструменты. Агент без доступа к реестрам и без RAG³ по загруженным документам будет уверенно выдумывать реквизиты и номера дел. Поэтому в рабочих кейсах каждый факт в отчёте сопровождается ссылкой на источник, а агент-критик отклоняет утверждения без неё.

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

Где такая система ломается

Три типичные точки отказа, о которых пишут в кейсах:

1. Галлюцинации на стыках. Когда агент-редактор пересказывает выводы ресёрчера, он может исказить цифру или потерять оговорку. Лечится тем, что редактор цитирует, а не пересказывает.
2. Стоимость и время. Пять агентов, которые несколько раз обмениваются длинными сообщениями, съедают в разы больше токенов, чем один запрос. На большом data room счёт за API может уйти в десятки долларов за одну проверку.
3. Зацикливание. Без жёсткого лимита шагов агенты уходят в бесконечное «уточни — переуточни». Оркестратор обязан обрывать цикл по числу итераций.

Чем собирают: сравнение фреймворков

Готовой коробки «due diligence из четырёх агентов» на рынке пока нет — команды собирают связку на одном из фреймворков. Ниже — ориентир по трём популярным на конец 2025 года. Все три с открытым кодом и бесплатны сами по себе; платите вы за вызовы моделей.

Модель под капотом — отдельный выбор и отдельная статья расходов. Роль ресёрчера и критика часто отдают более дешёвой и быстрой модели, а сведение отчёта — топовой. Актуальные цены за токены смотрите на страницах тарифов OpenAI, Anthropic и Google — они менялись несколько раз за год, и фиксировать здесь конкретную цифру бессмысленно.

Кому это пригодится, а кому нет

Пригодится:

• Небольшим фондам и M&A-бутикам, которые делают предварительный скрининг десятков сделок и хотят отсеять явно проблемные до того, как подключать дорогих юристов.
• Внутренним комплаенс-отделам для регулярной проверки контрагентов по санкционным и негативным спискам — рутинная задача, которую агент делает быстрее человека.
• Юрфирмам — как черновик first-pass ревью договоров, который человек потом верифицирует.

Не пригодится или опасно:

• Если решение по сделке принимается по отчёту агентов без проверки человеком — юридическую ответственность за вывод несёте вы, а не модель.
• В сделках, где данные закрытые и не оцифрованы: агент силён на структурированных источниках, а не на переговорах и намёках.
• Когда объём проверок мал — двух сделок в квартал. Настройка и сопровождение связки не окупятся, дешевле отдать человеку.

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

¹ Агент — LLM, которой дали не только текст, но и инструменты (поиск, вызовы API, доступ к файлам) и право самой решать, каким инструментом воспользоваться на каждом шаге.

² Data room — защищённое хранилище документов по сделке, куда продавец выкладывает финансы, договоры и учредительные бумаги для проверки покупателем.

³ RAG (retrieval-augmented generation) — подход, при котором модель перед ответом ищет релевантные фрагменты в загруженных документах и отвечает на их основе, а не только по памяти обучения.