Архітектура ШІ для підприємств: RAG знаходить інформацію, LLMs обробляють її, моделі прийняття рішень вибирають оптимальний варіант

Знаходження фактів та обґрунтування на їх основі більше не є рідкісною навичкою. Проблема відкритого проектування полягає у швидкому формуванні обмежених варіантів вибору, яким може довіряти бізнес-програмне забезпечення, не перетворюючи кожен мікрокрок на генерацію тексту у вільній формі.

Дискусії в галузі пройшли за знайомою послідовністю — фундаментальні моделі, покращення через пошук, пошук з використанням графів, а потім агенти. Кожен етап закривав іншу прогалину. Однак залишилась недостатньо розвинена сфера — прийняття рішень: не діалогове обговорення та не ще один потік прози, а набраний текст із чіткими обмеженнями, який додаток може виконати.

Системи для прийняття рішень у стилі System 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

Виникають незручні запитання. Чи потрібна для кожного дрібного вибору агента потужна модель для міркувань? Чи повинна мовна модель приймати рішення на кшталт:

„Надіслати цей замовлення до Команди А чи Команди Б?“ „Продовжити цей процес роботи?“ „Чи потрібна втручання людини?“ „Яка з п’яти заздалегідь визначених дій є придатною?“ „Чи перевищує ця транзакція поріг ескалації?“

Це часто є проблемами прийняття рішень, а не проблемами генерації мови.

Моделі прийняття рішень Системи 1

Тут важливу роль відіграє Jev. TypeSafe AI описує це як модель Системи 1. Концептуально розмежування є простим:

• LLM насамперед оптимізований для створення мови („Які слова підійдуть?“).
• Модель прийняття рішень обробляє структуровані дані та відповідає на заздалегідь визначені запитання за допомогою структурованих результатів („Яке рішення щодо програмного забезпечення є придатним?“).

У публічних матеріалах описується, що 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

Потім вимірюють точність, калібрування достовірності, затримку, витрати, використання токенів, швидкість ескалації, пояснюваність, підтримуваність, способи збоїв та бізнес-результати.

Цей експеримент кращий за інші таблиці лідерів, які стверджують, що модель просто „краща“. Метою не є обрати переможця. Мета — з’ясувати, яка примітивна форма інтелекту підходить для конкретної ситуації.

Якщо знову подивитися на цю „драбину“:

„Де знаходиться матеріал?“

„Як ці елементи пов’язані між собою?“

„Який шлях контексту слід пройти?“

„Що означає цей контекст?“

„Що має статися далі?“

Моделі прийняття рішень додають:

Інтелект прийняття рішень запитує:

«З огляду на цей стан, яку обмежену дію має обрати платформа?»

Це значуща архітектурна відмінність.

Тому корпоративний стек ШІ може стати когнітивним, а не лише технічним

Команди часто зображають архітектуру ШІ у вигляді компонентів:

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

Дизайн ШІ в компаніях відходить від концепції однієї моделі, яка керує всім до концепції портфеля примітивів інтелекту — кожен з яких налаштований для виконання різних когнітивних завдань.

Більша картина

Постійною темою у дизайні корпоративного ШІ є:

Майбутнє може бути визначене не тим, хто володіє найбільшою моделлю. Його може визначити той, хто створить найкращу систему на основі цих моделей.

Диференціація все більше залежить від поєднання ексклюзивних знань, визначених стосунків між елементами, інженерії контексту, ретельних обмірковувань, інтелекту прийняття рішень та контрольованої реалізації. Варто зазначити, що ШІ — це лише один із компонентів.

Наступна еволюція виглядає так:

Моделі генерації поступаються місцем системам розуміння, потім системам міркувань, потім системам прийняття рішень та нарешті системам дії.

Тож тривала перевага може полягати не стільки в окремому етапі розвитку, скільки у зв’язках, які поєднують знання, контекст, міркування, рішення та дії — що є складнішою інженерною проблемою, ніж просте нарахування параметрів.