Современные системы управления бизнес-процессами (BPM) всё чаще строятся вокруг ИИ: они должны «понимать» регламенты, связывать процессы с данными, помогать исполнителям и контролировать исполнение.
В этом контексте формируются две принципиально разные архитектурные ветки: RAG-подход (Retrieval-Augmented Generation) и подход на основе графа знаний и онтологии.
Обе ветки решают одну задачу — сделать систему «умнее» и ближе к бизнесу, — но делают это по-разному.
RAG работает прежде всего с текстом: находит релевантные фрагменты документов и передаёт их в LLM для генерации ответа.
Графовый подход работает со структурой знаний: представляет процессы, объекты, события, роли и их связи в виде структуры, по которой можно выполнять вычисления, правила, поиск зависимостей и при необходимости подключать ИИ.
Это различие особенно важно для BPM, потому что бизнес-процесс — это не просто набор текстовых документов. Это структура объектов, действий, состояний, связей, ограничений и событий, которая постоянно изменяется во времени.
RAG-подход: поиск по знаниям + генерация
Суть подхода
RAG (Retrieval-Augmented Generation) — это архитектура, в которой большая языковая модель (LLM) при каждом запросе обращается к внешней базе знаний: документам, регламентам, инструкциям, логам процессов и другим материалам.
Типичный пайплайн для BPM:
- Индексация знаний компании: регламенты, политики, SOP, описания процессов, журналы инцидентов, FAQ и другие материалы разбиваются на фрагменты и индексируются.
- Поиск релевантного контекста: при запросе система ищет фрагменты, которые наиболее соответствуют смыслу запроса.
- Передача контекста в LLM: найденные фрагменты вместе с запросом передаются языковой модели.
- Генерация ответа или действия: LLM формирует ответ, рекомендацию, черновик документа, чек-лист и т.п.
Как это выглядит в BPM-системе
- Ассистент по процессам: сотрудник спрашивает, как выполнить шаг процесса, и получает ответ на основе регламентов.
- Автоматизация поддержки: RAG ищет информацию в базе знаний и формирует ответ.
- Документооборот: система создаёт черновики документов на основе существующих шаблонов и материалов.
- Навигация по знаниям: сотрудник получает доступ к информации компании через естественный язык.
Сильные стороны для управления процессами
- Быстрый старт: существующие документы можно использовать без предварительного построения сложной модели процессов.
- Простое обновление базы знаний: новый или изменённый документ можно переиндексировать.
- Хорошая работа с неструктурированной информацией: инструкции, описания, письма, кейсы и другие тексты становятся доступными через естественный язык.
- Сильный Q&A-сценарий: RAG хорошо подходит для вопросов, ответ на которые уже содержится в документах.
Ограничения RAG в контексте BPM
Главное ограничение RAG заключается не столько в поиске информации, сколько в способе представления и обработки этой информации.
- Контекст приходится передавать модели. Найденные фрагменты документов становятся частью контекста LLM. Чем сложнее задача, тем больше информации приходится извлекать и передавать модели. Это означает дополнительные токеновые затраты и зависимость от размера контекста.
- Сложно работать со структурой процесса как с вычислительной моделью. RAG может найти описание того, что происходит в процессе, но сам текст не является удобной вычислительной структурой для анализа зависимостей, маршрутов, состояний и ограничений.
- Много операций приходится выполнять через LLM. Если вопрос можно решить обычным алгоритмом — например, проверить наличие связи, найти все связанные объекты или проверить условие, — передавать для этого большой текстовый контекст в LLM не всегда рационально.
- Изменение документов не превращает их автоматически в динамическую модель процесса. После изменения документа система получает новую текстовую информацию, но сама структура отношений между объектами процесса остаётся неявной.
Граф знаний и онтологический подход: структура + вычисление
Суть подхода
В графовом подходе знания компании представляются не только в виде текста, а в виде структуры объектов и связей между ними.
Например:
- процесс;
- шаг процесса;
- роль;
- сотрудник;
- документ;
- система;
- событие;
- ресурс;
- показатель;
- правило;
- результат.
Между ними существуют связи:
- «выполняется ролью»;
- «порождает документ»;
- «использует систему»;
- «следует за шагом»;
- «зависит от»;
- «изменяет состояние»;
- «влияет на показатель».
Онтология в этом случае задаёт семантику структуры, а граф представляет конкретные объекты и связи.
Ключевое отличие от классического представления об онтологическом подходе заключается в том, что такую структуру не обязательно создавать вручную с нуля.
Она может извлекаться из тех же документов, которые используются RAG.
Документ → извлечение сущностей и отношений → граф → динамическая структура знаний.
При этом граф может изменяться по мере поступления новой информации.
Как это выглядит в BPM-системе
Процесс представляется как динамическая структура:
объекты → связи → состояния → события → изменения.
Например:
Заявка → требует согласования → Договор → относится к → Закупке → выполняется → Менеджером → контролируется → Руководителем.
Теперь система может работать непосредственно со структурой.
Она может:
- найти все связанные объекты;
- проверить наличие необходимых связей;
- определить зависимые процессы;
- найти узкие места;
- проверить правила;
- построить маршрут;
- определить последствия изменения;
- рассчитать показатели.
И здесь появляется принципиально важное отличие:
не каждую задачу необходимо отдавать LLM.
Если задача формализуема, её можно выполнить обычным кодом непосредственно над графом.
Если требуется интерпретация текста, генерация или сложное рассуждение — можно подключить ИИ.
Таким образом, архитектура превращается из:
«всё через LLM»
в:
«код там, где достаточно алгоритма; ИИ там, где нужен интеллект».
Сильные стороны для управления процессами
- Явная структура процессов: процессы, шаги, роли, документы, системы и события существуют как связанные объекты.
- Вычислимость: по графу можно выполнять алгоритмы, поиск зависимостей, проверки и расчёты без передачи всего контекста LLM.
- Динамичность: узлы и связи могут изменяться непосредственно в процессе работы системы.
- Гибридная обработка: одна и та же структура может обрабатываться как кодом, так и ИИ.
- Трассируемость: можно восстановить цепочку связей, на основании которой получен результат.
- Связь процессов с данными: процессы можно связывать с конкретными объектами, событиями, ресурсами и метриками.
Ограничения графового подхода
Здесь важно отделить реальные ограничения от стереотипов классического онтологического моделирования.
- Необходимость построения начальной структуры. Для эффективной работы нужно определить типы объектов, отношений и правила их интерпретации. Однако эта структура не обязательно создаётся вручную: значительную часть её можно извлечь из существующих документов с помощью ИИ.
- Необходимость контроля качества структуры. Если ИИ извлекает сущности и связи из документов автоматически, требуется механизм проверки и устранения ошибок. Это аналогично контролю качества индексации в RAG, но результатом становится не набор текстовых фрагментов, а структурированное представление знаний.
- Сложность проектирования вычислительной модели. Чем больше задач должна решать система автоматически, тем важнее правильно определить правила, состояния, связи и алгоритмы обработки графа.
При этом динамичность и масштабирование сами по себе не являются недостатками графового подхода.
Изменение процесса может быть представлено изменением узлов и связей графа. Не обязательно перестраивать всю модель целиком: можно изменить только соответствующую часть структуры.
Главное различие: контекст против структуры
Именно здесь проходит наиболее важная граница между двумя архитектурами.
В RAG знания находятся преимущественно в документах.
Чтобы LLM могла использовать эти знания, необходимо:
найти → извлечь → передать в контекст → обработать моделью.
В графовом подходе знания находятся в структуре.
Чтобы выполнить многие операции, достаточно:
найти узлы → пройти связи → применить алгоритм → получить результат.
И только если задача требует интерпретации естественного языка или генеративного ответа, подключается LLM.
Это позволяет значительно сократить объём информации, который необходимо передавать языковой модели.
Сравнение подходов для создания BPM-системы
| Критерий | RAG | Граф знаний + онтология |
|---|---|---|
| Основной источник знаний | Документы и текстовые фрагменты | Объекты, связи, события и правила |
| Представление знаний | Текст + индексы | Структура узлов и связей |
| Работа с процессом | Через описание процесса в документах | Процесс является частью структуры |
| Работа с зависимостями | Через поиск и LLM | Непосредственно через связи графа |
| Вычисления | Часто через LLM или внешний код | Код непосредственно над структурой + LLM при необходимости |
| Использование токенов | Требуется передача найденного контекста в LLM | Можно выполнять часть операций без LLM |
| Изменение знаний | Обновление/переиндексация документов | Изменение соответствующих узлов и связей |
| Работа со сложной логикой | Ограничена контекстом и возможностями LLM | Может выполняться алгоритмами и правилами |
| Объяснимость | Найденные фрагменты документов | Цепочка узлов, связей и применённых правил |
| Типичные сценарии | Q&A, поиск, генерация текста | Управление, анализ, маршрутизация, зависимости, контроль |
| Сильная сторона | Работа с неструктурированным текстом | Работа со структурированными знаниями и отношениями |
Практическая рекомендация: не «RAG + граф», а правильное распределение ролей
Поэтому гибридную архитектуру имеет смысл рассматривать несколько иначе, чем просто:
онтология + RAG.
Более точная архитектура:
1. Документы — источник знаний
Регламенты, инструкции, письма, договоры, протоколы и другие материалы остаются источниками информации.
2. Граф — структурированное представление знаний
Из документов извлекаются сущности, события и отношения и формируется динамический граф.
3. Код — детерминированный вычислительный слой
Все операции, которые можно выполнить алгоритмически, выполняются без LLM:
- поиск связей;
- проверка условий;
- расчёт показателей;
- анализ маршрутов;
- поиск зависимостей;
- проверка ограничений;
- изменение состояний;
- обработка событий.
4. ИИ — интеллектуальный слой
LLM подключается там, где действительно требуется:
- понимание естественного языка;
- извлечение знаний из новых документов;
- интерпретация неоднозначных ситуаций;
- генерация текста;
- объяснение результата;
- поиск решений в неформализованных ситуациях.
5. RAG — один из механизмов работы с текстом
RAG при этом не исчезает. Он становится специализированным инструментом работы с неструктурированной информацией, а не основным механизмом представления всей логики BPM.
Итог
Главный вопрос при проектировании AI-системы для BPM — не «RAG или граф?», а:
Что в нашей системе должно быть текстом, что — структурой, что — вычислением, а где действительно нужен ИИ?
RAG хорошо работает там, где ответ находится в документах и его нужно найти и сформулировать.
Граф хорошо работает там, где важны объекты, связи, состояния, зависимости и изменения.
Код позволяет обрабатывать эту структуру детерминированно и без лишних токеновых затрат.
LLM подключается там, где требуется понимание, интерпретация или генерация.
Поэтому перспективная архитектура AI-BPM выглядит не как:
RAG → LLM → ответ
и даже не просто как:
Graph + RAG → LLM
а скорее как:
Документы → Граф → Код / ИИ → Действие
где система сама выбирает наиболее рациональный способ обработки задачи.
Именно это может стать следующим шагом развития AI в BPM: переход от систем, которые преимущественно «читают документы», к системам, которые понимают структуру бизнеса и умеют вычислять над ней.