Чому корпоративний AI буксує: моноліт знань і пастка «племінної» експертизи
У великих компаніях штучний інтелект уже давно не екзотика. За оцінкою McKinsey за 2025 рік, близько 88% компаній декларують використання AI. Але реальна віддача від цих інвестицій вражає своєю скромністю: лише близько 6% створеної цінності. Цей розрив між очікуваннями й результатом особливо добре видно в інженерних організаціях, де AI-агенти вміють писати код, аналізувати інциденти й навіть збирати повноцінні застосунки, але Jira-дошки й далі стоять, як стояли.
Про те, чому так відбувається, розповідає Радж Навакоті, staff software engineer в IKEA у домені Delivery Services, де він працює з понад сотнею інженерів у шести продуктових командах. На практичному воркшопі для каналу AI Engineer він розбирає головну причину низької ефективності корпоративного AI: те, як влаштовані знання в організаціях, і чому монолітна база знань та «племінна» експертиза ламають навіть найкращі агенти й наймодніші RAG/MCP-рішення.
6% цінності при 88% впровадження: де зникає ефект від AI
У технічних командах сьогодні важко знайти людей, які не користуються хоча б якимось агентом — від GitHub Copilot до внутрішніх чат-ботів. Моделі вражають: вони генерують код, будують full‑stack застосунки за лічені хвилини, пишуть тести, роблять рев’ю pull‑request’ів, допомагають з інцидент-менеджментом.
Але якщо подивитися не на демо, а на операційну реальність, картина інша. Ключові бізнес-метрики — виконані Jira-тикети, закриті епіки, швидкість доставки фіч — змінюються набагато повільніше, ніж обіцяють презентації. Саме це й фіксує цифра McKinsey: 88% компаній користуються AI, а відчутна цінність — лише близько 6%.
Причина не в тому, що моделі «недостатньо розумні». На рівні загальних здібностей — логіка, програмування, робота з текстом — сучасні LLM уже «вище планки» для більшості задач. Проблема в іншому: вони майже нічого не знають про конкретну компанію, її домен, процеси, історію інцидентів, приховані обмеження й неформальні правила гри. Саме тут починається розрив між вражаючими демо і мізерним впливом на реальну продуктивність.
Три шари знань: зелений, помаранчевий і червоний
Щоб зрозуміти, чому агенти так часто провалюються в реальних робочих задачах, Радж пропонує дивитися на знання як на тришарову систему.
Перший шар — «зелений». Це загальні знання, на яких уже навчені великі моделі. Стандарти HTTP, типові REST‑патерни, базові практики CI/CD, синтаксис мов програмування, типові архітектурні рішення — усе це вже є в LLM «з коробки». Коли Jira‑тикет вимагає саме такого типу роботи, агент справляється блискуче: пише код, виправляє баги, пропонує оптимізації.
Другий шар — «помаранчевий». Це те, що компанія може «навчити» агента робити по‑своєму. Наприклад, внутрішні код‑стандарти, специфічні патерни логування, прийняті структури сервісів, особливості деплойменту. Ці знання можна передати через промпти, інструкції, розширення агентів, спеціальні «skills» або інструменти. Тут AI теж працює непогано, якщо інженери витратили час на налаштування.
Третій шар — «червоний». Це інституційні, або «племінні», знання. Вони живуть у головах людей, у фрагментах старих документів, у Slack‑тредах, у неформальних домовленостях між командами. Це відповіді на питання на кшталт: чому цей сервіс поводиться так дивно після 23:00; які саме edge‑кейси колись «підпалили» прод; чому певний API не можна чіпати в пікові години; як насправді працює інтеграція зі старою системою, яку ніхто не хоче чіпати.
Саме червоний шар вирішує, чи зможе агент реально закрити робочий тикет. Він може ідеально впоратися із зеленими й помаранчевими частинами задачі, але спіткнутися на одному критичному фрагменті «племінної» логіки — і тоді людина все одно змушена втручатися, перевіряти, дописувати, пояснювати. У підсумку інженер витрачає час не менше, а іноді й більше, ніж без агента.
Монолітна база знань: коли RAG і MCP не рятують
Індустрія вже кілька років пропонує стандартну відповідь на проблему інституційних знань: побудувати «retrieval layer». Підключити Confluence, Jira, SharePoint, GitHub, Slack, бази даних; накрити все це RAG‑шаром, знання‑графом або мережею MCP‑серверів; дати агенту інструменти для пошуку й витягування потрібного контексту.
На папері це виглядає як ідеальне рішення. На практиці — ні.
Радж оцінює, що за наявності більш‑менш задокументованої бази знань RAG або knowledge graph дозволяють досягти приблизно 40% фактичної точності. Це означає, що близько сорока відсотків відповідей агента, заснованих на корпоративній документації, будуть коректними за фактами. Для демо цього достатньо. Для продакшену — ні.
Проблема в тому, що сама корпоративна база знань зазвичай є монолітом із дуже низькою якістю. Радж описує типовий розклад:
Близько 20% знань — застарілі. Документи не оновлювалися роками, описують уже неіснуючі сервіси або старі версії процесів.
Ще 20% — ненадійні. Це фрагментарні нотатки, чернетки, презентації, які ніхто не валідував і не підтримує.
Ще приблизно 10% — дублікати. Одна й та сама інформація в різних версіях розкидана по різних просторах Confluence, Google Docs, внутрішніх wiki.
І нарешті, близько 40% критично важливих знань взагалі не задокументовано. Це та сама «tribal knowledge» — те, що знають конкретні люди й конкретні команди, але що ніколи не потрапляло в офіційні системи.
У такій ситуації кількість підключених джерел майже не має значення. Можна побудувати 10, 15 чи навіть 20 MCP‑серверів, як це зробив сам Радж, але якщо вони всі дивляться в один і той самий монолітний, частково гнилий масив знань, результат буде передбачуваний: недетерміновані, ненадійні й неперевірені відповіді.
20+ MCP‑серверів пізніше: чому інтеграції не працюють як очікується
Досвід Раджа з MCP‑інтеграціями показовий саме тим, що він пройшов шлях «до кінця». Він побудував понад 20 MCP‑серверів, які підключали різні джерела інституційних знань до агентів. Логіка була проста: чим більше інструментів і конекторів, тим повніший контекст отримає агент, тим менше доведеться втручатися людині.
Реальність виявилася іншою. Вихідні дані з цих інтеграцій у більшості випадків були:
недетермінованими — одна й та сама задача з однаковим контекстом могла давати різні відповіді;
ненадійними — агент часто «витягував» не ті документи, не ті версії, не ті фрагменти, які реально потрібні для задачі;
нетестованими — у більшості інженерних команд немає практики систематичних eval’ів для агентів і retrieval‑шарів, тому якість інтеграцій оцінюють за принципом «щось вийшло — уже добре».
У підсумку замість того, щоб зняти навантаження з інженерів, агенти часто створювали додаткову роботу. Люди витрачали час на перевірку відповідей, пошук правильних документів, ручне заповнення прогалин. Радж описує ситуацію, коли він сам фактично перетворився на «оператора даних» для агентів, заповнюючи за них те, чого вони не могли знайти або зрозуміти.
Це не означає, що RAG або MCP — хибні технології. Вони корисні, але лише настільки, наскільки корисний базовий шар знань, до якого вони підключені. Якщо цей шар — моноліт із застарілою, суперечливою й неповною інформацією, жоден retrieval‑шар не перетворить його на надійне джерело правди.
Моноліт знань як структурна проблема, а не технічний баг
Ключовий висновок, до якого приходить Радж, полягає в тому, що проблема корпоративного AI — не в моделях і не в інструментах, а в структурі знань.
Сьогодні інституційні знання в більшості організацій — це моноліт. Усе змішано: старе й нове, важливе й другорядне, перевірене й «якось колись записане». Цей моноліт не має чітких меж, не розбитий на логічні, перевірені блоки, не пов’язаний прозорими відносинами. Для людини з багаторічним досвідом у компанії це ще якось працює: вона знає, які сторінки Confluence можна ігнорувати, кого спитати, як обійти «сміттєві» документи. Для агента це хаос.
Саме тому спроби «просто підключити все» через RAG або MCP дають лише частковий ефект. Агент отримує доступ до величезного масиву даних, але не розуміє, що з ним робити, які частини довіряти, як поєднувати фрагменти в цілісну картину. У кращому разі він дає частково коректні відповіді, у гіршому — впевнено галюцинує на основі застарілих або неповних документів.
Радж проводить аналогію з еволюцією архітектури програмних систем. Колись монолітні застосунки здавалися природним способом організації коду, поки не стало очевидно, що вони погано масштабуються, важко змінюються й створюють надмірні залежності. Перехід до мікросервісів був не просто технічним трендом, а відповіддю на структурні обмеження монолітів.
Зі знаннями відбувається те саме. Монолітна база знань — це «legacy‑система» організації. Поки вона не буде розбита на менші, чітко визначені, перевірені контекстні блоки, агенти не зможуть надійно працювати з інституційною інформацією. І жоден зовнішній вендор не вирішить цю проблему за компанію: постачальники LLM зосереджені на якості моделей, ринок retrieval‑інструментів — на пошуку й індексації, але ніхто не прийде й не «перепише» ваші внутрішні знання.
Від моноліту до контекстних блоків: що потрібно агентам насправді
Структурна вимога, яку формулює Радж, доволі проста, але радикальна за наслідками: щоб інституційні знання стали корисними для агентів, їх потрібно розбити з моноліту на менші, добре визначені контекстні блоки.
Контекстний блок — це не просто сторінка документації. Це одиниця знань із чіткими межами, зрозумілою метою й перевіреним змістом, яку можна безпечно «подавати» агенту як частину його робочого контексту. Для такого блоку важливо:
щоб він був актуальним — застарілі версії мають бути або видалені, або явно позначені;
щоб він був повним у межах своєї теми — не покладатися на «само собою зрозуміло» з інших, неочевидних джерел;
щоб він був пов’язаний із іншими блоками — через явні посилання, схеми, метамоделі домену;
щоб його можна було тестувати — перевіряти, чи достатньо цього блоку для розв’язання конкретного класу задач.
Лише в такому вигляді знання стають придатними для систематичного використання агентами. RAG і MCP у цьому випадку перестають бути «пилососами» по всьому Confluence й перетворюються на механізми адресної доставки потрібних блоків у потрібний момент.
Радж наголошує: це робота, яку має зробити сама організація. Моделі будуть ставати кращими, retrieval‑інструменти — розумнішими, але без структурованої, розбитої на блоки інституційної пам’яті агенти й далі будуть упиратися в ті самі обмеження. Саме тому сьогоднішній «AI‑стек» у підприємствах часто виглядає так: блискучі моделі, модні агенти, дорогий retrieval‑шар — і монолітна, хаотична база знань під ними.
Чому 40% «племінних» знань — це не дрібна прогалина, а критичний ризик
Цифра, яку наводить Радж, — близько 40% знань у вигляді «tribal knowledge» — може здаватися абстрактною, поки не подивитися на неї через призму ризиків і вартості.
По‑перше, саме в цій «червоній зоні» зазвичай живуть найкритичніші для бізнесу нюанси: обхідні шляхи для старих систем, неформальні обмеження, історія великих інцидентів, домовленості між командами, які ніколи не потрапляли в офіційні регламенти. Коли агент не знає цього, він може пропонувати рішення, які виглядають логічними на папері, але в реальності ламають прод або створюють приховані борги.
По‑друге, «племінні» знання дуже нерівномірно розподілені. Вони концентруються в окремих людях — «носіях домену». Це робить організацію вразливою: звільнення, вигорання, перехід у інший проєкт — і цілі фрагменти інституційної пам’яті просто зникають. Агенти, які покладаються лише на задокументовану частину знань, у такій ситуації стають ще менш корисними.
По‑третє, саме ця зона найгірше піддається класичним підходам до документації. Люди не люблять і не вміють систематично описувати те, що для них давно стало «фоновим знанням». Звідси й спокуса технічних команд: замість того, щоб боротися з монолітом знань, побудувати ще один RAG, ще один MCP, ще один «розумний» пошук. Але без зміни структури це лише ускладнює систему, не підвищуючи її надійності.
У підсумку 40% «племінних» знань — це не просто «дірка» в документації. Це системний бар’єр для будь‑яких спроб зробити AI реальним учасником робочих процесів, а не лише помічником у написанні коду.
Висновок: AI не виправить моноліт, якщо моноліт не виправити самому
Сьогоднішній стан корпоративного AI можна описати як парадокс. З одного боку, моделі досягли рівня, коли вони здатні будувати повноцінні застосунки, аналізувати складні інциденти й підтримувати інженерів у щоденній роботі. З іншого — бізнес бачить лише близько 6% реальної цінності від цих інвестицій, попри те, що 88% компаній уже «впровадили AI».
Розв’язання цього парадоксу лежить не в черговому поколінні LLM і не в новому фреймворку для агентів. Воно починається з чесної оцінки того, як влаштовані інституційні знання в організації. Поки вони залишаються монолітом із застарілою, суперечливою й частково «племінною» інформацією, будь‑які RAG‑ і MCP‑інтеграції будуть давати лише частковий, нестабільний ефект.
Радж Навакоті формулює просту, але жорстку вимогу: щоб агенти стали справжніми учасниками роботи, а не демонстраційними іграшками, інституційні знання потрібно розбити на менші, чітко визначені контекстні блоки. Лише тоді retrieval‑шар перестане бути «магічною чорною скринькою» й перетвориться на надійний механізм доставки правильного контексту в правильний момент.
Це не задача для вендорів моделей і не проблема, яку можна «закрити» покупкою ще одного інструмента. Це внутрішня інженерна робота над власною пам’яттю організації. І саме від того, наскільки серйозно компанії поставляться до цього моноліту знань, залежить, чи залишиться AI красивою обгорткою навколо старих процесів, чи справді змінить продуктивність і якість роботи команд.