Архитектура ИИ для предприятий: RAG находит информацию, LLMs анализируют её, модели принятия решений выбирают оптимальный вариант
Почему одних только механизмов поиска информации и языкового рассуждения недостаточно — как GraphRAG, агенты и модели принятия решений типа System 1, такие как Jev, разделяют знания, контекст, рассуждения, принятие решений и их выполнение.
Источники: The Emerging Architecture of Enterprise AI — RAG Finds, LLMs Reason, Jev Decides.
Поиск фактов и формирование выводов на их основе больше не являются редким навыком. Проблема открытой архитектуры заключается в необходимости быстрого принятия ограниченных решений, которым может доверять бизнес-программное обеспечение, без превращения каждого микрошага в генерацию текста свободного формата.
В профессиональных обсуждениях постепенно вырисовывалась определённая последовательность: фундаментальные модели, усиление поиска за счёт извлечения информации, усиленный поиск с использованием графов, а затем агенты. Каждый новый этап закрывал отдельный пробел. Оставался ещё один нерешённый аспект — принятие решений: не диалоговое обсуждение и не ещё один поток текста, а ограниченный результат в виде написанного сообщения, который приложение может выполнить.
Системы для принятия решений в стиле «Система 1», такие как Jev (TypeSafe AI), делают этот уровень более осязаемым. Они указывают на то, что в производственных средах может потребоваться отдельный путь принятия решений наряду с механизмами извлечения информации и лингвистическим анализом.
Эволюция корпоративного ИИ
Упрощённая временная шкала помогает понять, что ещё отсутствует.
1. LLM: «Какой текст можно сгенерировать?»
Модели фундаментального уровня сделали машины способными к чтению и написанию на естественном языке. То, что они «знают», по-прежнему зависит от предварительной обучаемости и окна контекста, предоставляемого во время инференса.
В компаниях эта проблема проявляется сразу. Критически важные знания редко хранятся в весах модели; они находятся в документах, репозиториях, API, базах данных, правилах, руководствах, заявках, письмах, бизнес-правилах, вики-страницах и приложениях.
Это давление побудило разработчиков перейти на следующий уровень.
2. RAG: «Где хранится материал?»
Технология Retrieval-Augmented Generation позволяет моделям обращаться к внутренним хранилищам компании. Вместо требования полного воспроизведения информации из весов модели, пайплайны загружают соответствующий материал и используют его в качестве рабочего контекста.
Структура пайплайна стала следующей:
Внутренние хранилища компании → Загрузка → Рабочий контекст → Языковая модель → Ответ
Этот шаг помог очень много. RAG по-прежнему сталкивается с структурным барьером: поиск похожих документов — это не то же самое, что понимание взаимосвязей фактов компании.
Рассмотрим спор по вопросу страхового покрытия:
«Что стало причиной отклонения этого требования, и заслуживает ли оно дальнейшего рассмотрения?»
Чтобы ответить на этот вопрос, может потребоваться проследить следующую цепочку:
Клиент → Полис → Продукт → Страховое покрытие → Требование → Диагностика → Исключение → Положение полиса → Нормативное правило
Это не просто задача поиска по ключевым словам. Это задача взаимосвязей и логического мышления.
3. GraphRAG: «Как связаны эти элементы?»
Затем появились графы и GraphRAG. Вместо изолированных фрагментов платформы моделируют сущности и связи между ними. Например:
Customer
│
├── owns → Policy
│ │
│ ├── covers → Product
│ │
│ └── governed by → Rule
│
└── submitted → Claim
│
├── relates to → Diagnosis
│
└── evaluated against → Coverage
Метод прослеживания заменяет поиск «ближайшего абзаца». Это и есть слой корпоративных знаний, лежащий в основе структурированных знаний, работы в стиле OKF и экспериментов GraphRAG.
Даже тогда остается ещё один вопрос. Как только контекст понят и проанализирован: что на самом деле должна сделать система?
4. Агенты: «Что должно произойти дальше?»
В концепциях проектирования агентов языковая модель выступает в роли дирижёра. Она может обдумывать действия, выбирать инструменты, вызывать API, анализировать результаты, определять следующий шаг, применять другие инструменты и продолжать до завершения задачи.
Такая возможность создаёт архитектурное давление: от одной и той же универсальной модели требуется обрабатывать каждый этап:
Understand
↓
Reason
↓
Choose
↓
Route
↓
Decide
↓
Call API
↓
Inspect result
↓
Decide again
↓
Call another API
После этого возникают неприятные вопросы. Нужна ли для каждого микро-выбора агента большая модель для рассуждений? Должна ли языковая модель принимать решения вроде:
«Перенаправить этот тикет команде А или команде Б?» «Продолжить этот рабочий процесс?» «Требуется ли вмешательство человека?» «Какое из пяти заранее определенных действий применимо?» «Превышает ли эта транзакция порог для передачи на более высокий уровень обработки?»
Это часто являются проблемами принятия решений, а не проблемами генерации языка.
Модели принятия решений System 1
Здесь важна концепция Jev. TypeSafe AI рассматривает ее как модель System 1. Концептуально разделение простое:
- Большая языковая модель оптимизирована прежде всего для генерации языка («Какие слова подойдут?»).
- Модель принятия решений использует структурированные данные и отвечает на заранее определенные вопросы с структурированными результатами («Какое решение по программному обеспечению применимо?»).
В публичных материалах говорится, что Jev формирует отредактированные ответы на основе состояния общего приложения, уделяя приоритет скорости перед детальным изложением. Такой подход позволяет создать более чистую архитектуру.
Отсутствующий слой
Корпоративный ИИ не обязан выглядеть только так:
Enterprise Data
↓
RAG
↓
LLM
↓
Agent
↓
Actions
Более разделенная структура выглядит так:
Enterprise Systems
↓
Knowledge Engineering
↓
Enterprise Knowledge Layer
↓
Context Engineering
↓
┌──────────────┬──────────────┐
│ │ │
▼ ▼ ▼
Reasoning Decision Rules
LLM Model Engine
│ │ │
└──────────────┴──────────────┘
↓
Agent Control
↓
Deterministic Code
↓
APIs / Workflows
Обязанности становятся более ясными.
LLM не обязаны делать всё
Рассмотрим процесс работы страховой службы. Клиент пишет:
«Эта заявка на оплату госпитализации была отклонена, но, по-видимому, заслуживает покрытия».
Сначала платформе необходимо установить контекст. Для этого она может извлекать информацию о клиенте, детали полиса, настройки продукта, условия страхования, данные заявок, информацию о больницах, исключения, положения полиса и нормативные правила. Именно здесь пригождаются корпоративный слой знаний и технология GraphRAG.
Затем ЯИ может рассуждать:
«Отклонение, по-видимому, связано с исключением X. Положение Y может создать исключение при условии Z».
Далее следуют ограниченные варианты выбора:
Does this require human review?
→ YES
Which workflow?
→ Claims InvestigationPriority?
→ HighAdditional evidence required?
→ YESCustomer communication template?
→ Coverage Review
Это структурированные решения, а не процесс генерации без четких рамок — именно здесь подходит модель принятия решений вроде Jev.
Архитектура начинает выглядеть иначе
Корпоративный ИИ можно представить как набор отдельных когнитивных функций.
Слой знаний
Какие факты известны компании?
OKF — графы знаний — документы — исходный код — API — базы данных.
Слой контекста
Какая информация релевантна для этой проблемы?
RAG, GraphRAG, инжиниринг контекста.
Слой рассуждений
Что означает эта информация?
ЯИ и модели рассуждений.
Слой принятия решений
Учитывая эту ситуацию, что должна делать платформа?
Модели принятия решений, такие как Jev.
Слой выполнения
Как следует выполнять это решение?
API, рабочие процессы, бизнес-правила, детерминистическое программное обеспечение.
Разделение имеет значение: для интеллектуальных систем не требуется одна огромная модель, выполняющая всё.
И это меняет наш подход к корпоративным знаниям
Инфраструктура корпоративных знаний — это не просто улучшение функции поиска. Она может стать основой для принятия решений машинами.
Представьте граф, содержащий:
Customer
Policy
Product
Claim
Agent
Branch
API
Business Rule
Regulation
Risk
Transaction
с такими связями, как:
Customer → owns → Policy
Policy → belongs to → ProductPolicy → covers → BenefitClaim → relates to → PolicyClaim → triggered by → EventProduct → governed by → RuleRule → derived from → Regulation
Система больше не просто извлекает «документы о требованиях». Она создаёт структурированный обзор состояния бизнеса, который могут использовать различные интеллектуальные алгоритмы:
- LLM для рассуждений
- Модель принятия решений для ограниченного выбора
- Правила для детерминистических ограничений
- Код для выполнения
Такая комбинация более удобна в обслуживании, чем один огромный промпт.
Интересная деталь: уровень уверенности становится архитектурным элементом
Модели принятия решений также отражают уровень уверенности. Многие приложения ИИ ограничиваются фразой «модель выдала X». Операторам также необходимо знать: насколько точным является результат, и что происходит, когда уровень уверенности слишком низок?
Представьте:
Decision
↓
Confidence
↓
┌───────────────┐
│ │
High Low
│ │
▼ ▼
Auto Human
execute review
Пороговые значения необходимо настраивать в зависимости от конкретного случая использования, но сама схема очень эффективна. Рассматривайте выводы ИИ как решение с неопределенностью, затем кодируйте политику автономности:
High confidence
↓
Autonomous execution
Medium confidence
↓
Secondary validationLow confidence
↓
Human intervention
Особенно в отраслях с строгим регулированием необходима именно такая структура.
Это также может изменить экономику ИИ
Если каждый микро-выбор агента потребляет значительные ресурсы для принятия решений, то при большом количестве вызовов — тысячах или миллионах — возрастают затраты и задержки. Когда множество выборов ограничены и повторяются, специализированный механизм принятия решений может изменить кривую затрат и задержек.
Это приводит к появлению ещё одного уровня маршрутизации:
Complex reasoning
↓
LLM
Bounded decision
↓
Decision ModelDeterministic rule
↓
Rule EngineExecution
↓
Code
Цель не в замене больших языковых моделей. А именно — прекратить использовать их для задач, которые им не нужно выполнять.
Это также меняет способ оценки ИИ
Современные панели управления часто отслеживают пользователей, запросы, токены, использование модели, задержки, степень внедрения и затраты. Все это остаётся полезным. Как только ИИ начинает принимать операционные решения, появляется ещё один уровень показателей.
Показатели интеллекта принятия решений
| Показатель | Что он нам показывает |
|---|---|
| Объём решений |
Это переводит дискуссию от внедрения ИИ к экономике интеллекта ИИ.
И существует важное ограничение
Jev совершенно нов. Следует отметить, что официальное представление продукта запланировано на сентябрь 2026 года, поэтому независимых доказательств пока мало. Считать Jev или любой другой новый инструмент для принятия решений заменой проверенным LLM было бы преждевременно.
Полезный экспериментальный вопрос звучит так:
В каких случаях специально разработанный инструмент для принятия решений превосходит языковую модель, классический движок правил или комбинированную систему?
Это стоит измерить, а не просто предполагать.
Эксперимент, который стоит провести
Выберите один определенный бизнес-процесс — в качестве примера направление запросов на обслуживание — и подайте одинаковый контекст в несколько различных решений.
Подход 1
LLM → структурированный результат → логика приложения
Подход 2
Движок правил → детерминированное решение
Подход 3
Модель принятия решений → типизированное решение
Подход 4
Гибридный:
Rules
↓
Decision Model
↓
LLM when ambiguity requires reasoning
↓
Human when confidence is insufficient
Затем измеряются точность, калибровка уверенности, задержка, стоимость, использование токенов, скорость эскалации, объяснимость, обслуживаемость, способы сбоев и бизнес-результаты.
Такой эксперимент превосходит другие таблицы лидеров, утверждающие, что та или иная модель просто «лучше». Цель не в том, чтобы признать Jev лучшим. Цель — понять, какая примитивная форма интеллекта подходит для конкретной задачи.
Если снова взглянуть на эту «лестницу»:
RAG задавал вопрос:
«Где находится материал?»
Графы знаний задавали вопрос:
«Как связаны эти элементы?»
GraphRAG задавал вопрос:
«Какой путь контекста следует пройти?»
LLM задавали вопрос:
«Что означает этот контекст?»
Агенты задавали вопрос:
«Что должно произойти дальше?»
Модели принятия решений добавляют:
Интеллект принятия решений задаёт вопрос:
«Учитывая текущее состояние, какое ограниченное действие должна выбрать платформа?»
Это значимое архитектурное различие.
Поэтому стек корпоративного ИИ может стать когнитивным, а не просто техническим
Команды часто изображают архитектуру ИИ в виде компонентов:
LLM
Vector DB
Embedding Model
RAG
Orchestrator
API Gateway
Guardrails
Подход, основанный на когнитивной ответственности, выглядит более так:
ENTERPRISE AI
│
┌────────────┴────────────┐
│ │
KNOWLEDGE CONTEXT
│ │
KG / OKF / Data RAG / GraphRAG
│ │
└────────────┬────────────┘
│
┌─────────┴─────────┐
│ │
REASONING DECISION
│ │
LLM/SLM Jev / similar
│ │
└─────────┬─────────┘
│
ORCHESTRATION
│
GUARDRAILS
│
HUMAN-IN-LOOP
│
EXECUTION
│
APIs / Workflows
Дизайн ИИ в компаниях отходит от концепции одной модели, управляющей всем к использованию набора примитивов интеллекта — каждый из которых настроен для выполнения разных когнитивных задач.
Более широкая картина
Повторяющаяся тема в дизайне корпоративного ИИ:
Будущее может быть определено не тем, у кого самая большая модель, а тем, кто создаст лучшую систему на основе этих моделей.
Дифференциация всё чаще заключается в сочетании эксклюзивных знаний, структурированных связей, проектирования контекста, тщательного обдумывания, интеллектуальных решений и контролируемой реализации. Следует отметить, что большие языковые модели представляют собой лишь один из компонентов.
Следующее развитие выглядит следующим образом:
Модели генерации уступают место системам понимания, затем системам рассуждения, затем системам принятия решений и, наконец, системам действий.
Поэтому устойчивое преимущество может заключаться не столько в отдельном этапе разработки, сколько в связях, объединяющих знания, контекст, рассуждения, решения и действия — это более сложная инженерная задача, чем простое увеличение количества параметров.