Як інциденти перетворюються на знання: Git, сканери прогалин і нова дисципліна для enterprise‑AI
У великих компаніях сьогодні вже нікого не здивуєш десятками MCP‑серверів, RAG‑шарів і інтеграцій з Confluence чи Slack. Але Jira‑квитки все одно рухаються повільно, а агенти поводяться як талановитий стажер, який постійно щось перепитує. На конференції AI Engineer про те, як змінити цю картину, розповідає Радж Навакоті — staff software engineer в IKEA у домені Delivery Services, де понад сотня інженерів і шість продуктових команд будують внутрішні AI‑системи.
Навакоті пропонує не черговий «чарівний» RAG, а операційну дисципліну: demand‑driven context — методологію, де реальні інциденти, провали агентів і Git‑репозиторій стають рушієм побудови знань. У цьому матеріалі — як саме інциденти перетворюються на структуровані context blocks, як автоматичний сканер прогалин виявляє «дірки» в документації, і чому GitHub стає центральним джерелом правди для корпоративного знання, навіть якщо кінцеві користувачі читають його в Confluence чи Slack.
Від розбору інциденту до нових сутностей: як агент виявляє «дірки» в знаннях
У центрі підходу — не абстрактні use case’и, а дуже конкретний сценарій: розбір кореневої причини інциденту. Це типовий для enterprise завдання, де переплітаються системна архітектура, бізнес‑логіка, внутрішні сервіси, API й неформальні процеси.
Методологія працює так: агент отримує інцидент як робочий елемент, намагається провести root cause analysis, спираючись на існуючу монолітну базу знань, і… закономірно натикається на те, чого там немає.
Спочатку агент робить стандартний крок: через RAG, MCP чи інший retrieval‑шар витягує все, що може, з наявної документації — Confluence, Jira, GitHub, внутрішні wiki. На цьому етапі він поводиться як будь‑який сучасний enterprise‑агент: збирає фрагменти, будує гіпотезу, формує пояснення.
Ключовий момент починається тоді, коли агент чесно фіксує, чого йому бракує. У процесі аналізу він стикається з:
- невідомими термінами, які не знаходить у жодному джерелі;
- внутрішніми сервісами чи API, що згадуються в логах або тікетах, але не описані в документації;
- бізнес‑правилами, які явно впливають на поведінку системи, але існують лише як «усна традиція» в команді.
У демонстраційному прогоні одного інциденту цього виявилося достатньо, щоб поверх моноліту «спливло» близько шести раніше неописаних сутностей. Це можуть бути, наприклад, внутрішні сервіси, специфічні статуси замовлень, нетривіальні правила маршрутизації чи допоміжні cron‑процеси, про які знають лише двоє людей у команді.
Агент не просто констатує, що йому чогось бракує. Він формулює це як конкретні knowledge gaps: «існує термін X, який використовується в логах і Jira, але не має визначення», «є сервіс Y, який впливає на цей інцидент, але немає опису його API», «є бізнес‑правило Z, яке змінює поведінку системи, але воно ніде не задокументоване».
Далі в гру вступає людина. Інженер або доменний експерт відповідає на ці запити, пояснює, що таке X, Y, Z, як вони пов’язані з інцидентом і з іншими частинами системи. І тут відбувається принципово важливий крок: ці пояснення не залишаються в чаті чи особистих нотатках, а перетворюються на нові context blocks — окремі, чітко структуровані фрагменти знань, які додаються до бази.
Один прогін інциденту — шість нових сутностей. Це не виглядає вражаюче, поки не починаєш масштабувати процес.
14 інцидентів і стрибок впевненості: як виміряти, що знання справді ростуть
Одна з ключових проблем enterprise‑AI — відсутність метрик, які показують, що «агент став розумнішим» не в абстрактному сенсі, а саме в контексті конкретного домену. У demand‑driven context ця проблема вирішується через повторювані цикли на реальних інцидентах.
Навакоті проганяє описаний вище процес не один раз, а на серії з 14 інцидентів. Кожен інцидент — це:
- спроба агента провести root cause analysis, використовуючи поточну базу знань;
- виявлення прогалин: невідомі терміни, відсутні описи сервісів, неформалізовані бізнес‑правила;
- уточнення цих прогалин людиною;
- перетворення уточнень на нові context blocks і додавання їх до репозиторію.
Щоб уникнути суб’єктивності, вводиться числова метрика — умовний «рівень впевненості» агента в тому, що він має достатній контекст для якісного аналізу інциденту. На старті, коли база знань ще майже не адаптована під конкретний домен, цей показник тримається на рівні близько 1,5. Це означає, що агент постійно натикається на невідомі поняття, робить припущення, які не витримують перевірки, і вимагає великої кількості уточнень від людини.
Після того як процес проходить через 14 інцидентів, картина змінюється. Впевненість агента зростає до приблизно 4,4. Це не магічне «AGI прокинулося», а наслідок дуже конкретної роботи:
- кожен інцидент додає кілька нових сутностей і зв’язків до бази;
- повторювані патерни — наприклад, одна й та сама бізнес‑логіка, яка впливає на різні інциденти, — фіксуються один раз як окремий context block;
- наступні інциденти вже «знаходять» ці блоки через retrieval‑шар, і агенту не потрібно щоразу перепитувати людину.
Важливо, що зростання впевненості — не просто суб’єктивне відчуття команди, а вимірюваний ефект від заповнення конкретних прогалин. Кожен новий context block зменшує кількість «невідомих невідомих» для агента в цьому домені.
Цей підхід нагадує test‑driven development: замість того щоб намагатися «одразу описати все», команда йде від провалів на реальних задачах. Кожен інцидент — це фактично новий тест, який або проходить, або виявляє, що в системі знань бракує ще одного блоку.
Git як джерело правди: чому контекстні блоки живуть у flat‑файлах
Щойно з’являється ідея «context blocks» як окремих одиниць знань, постає практичне питання: де й як їх зберігати. Навакоті у своїй реалізації робить вибір на користь максимально простого, але дисциплінованого підходу: Git‑репозиторій з flat‑файлами.
У демонстраційному фреймворку кожен context block — це, по суті, Markdown‑файл у Git. У ньому описується конкретна сутність або фрагмент домену: сервіс, бізнес‑процес, API, специфічне правило, яке впливає на поведінку системи. Файли організовані так, щоб їх було легко індексувати retrieval‑шаром і водночас читати людям.
Чому саме Git, а не одразу Confluence чи інша корпоративна wiki? У цього вибору кілька прагматичних причин.
По‑перше, GitHub (або інший Git‑хостинг) вже дає все, що потрібно для колективної роботи над знаннями: pull request’и, code review, історію змін, механізми вирішення конфліктів. Це означає, що контекстні блоки можна розвивати так само, як код: одна команда додає новий блок, інша — переглядає, коментує, пропонує правки. Для організацій, де інженерна культура вже побудована навколо Git, це природне продовження звичних практик.
По‑друге, Git добре підходить для сценарію, де знання спочатку формуються як «чернетка для агентів», а вже потім публікуються в більш дружніх до бізнесу інструментах. Навакоті прямо підкреслює: Git‑репозиторій з curated context blocks — це не обов’язково кінцевий інтерфейс для всіх співробітників. Це радше джерело правди, з якого можна синхронізуватися в Confluence, Slack, внутрішні портали чи інші системи.
По‑третє, Git добре масштабується для мультикомандних сценаріїв. У IKEA Delivery Services, де працює Навакоті, понад 100 інженерів у шести продуктових командах. У такому середовищі неминуче виникають конфлікти й дублювання знань. Git дозволяє їх виявляти й вирішувати на рівні pull request’ів, а не в хаотичних правках у wiki.
При цьому фреймворк не обмежується лише Git. Він може бути підключений до Confluence, Slack, GitHub чи інших джерел через MCP або RAG. Але саме Git‑репозиторій з flat‑файлами виступає як curated шар — місце, де знання проходять відбір, структурування й рев’ю, перш ніж стати частиною «офіційного» контексту для агентів.
Автоматичний сканер прогалин: як інциденти й Jira‑тікети перевіряють базу знань
Ручний розбір інцидентів — потужний, але обмежений інструмент. Щоб масштабувати demand‑driven context, Навакоті додає ще один компонент — автоматичний сканер прогалин у контексті.
Ідея проста: якщо в організації накопичилися архіви інцидентів, Jira‑квитків та інших робочих елементів, їх можна використати не лише для ретроспектив, а й як тестовий набір для бази знань. Сканер бере ці артефакти й перетворює їх на «запити до знань».
Технічно процес виглядає так. Спочатку сканер бере, наприклад, опис інциденту або Jira‑квитка і генерує з нього набір probe’ів — цільових запитів, які мають перевірити, чи достатньо в базі знань інформації, щоб агент міг розв’язати це завдання. Це можуть бути питання про конкретні сервіси, бізнес‑процеси, API, залежності між системами, нетривіальні статуси чи конфігурації.
Далі ці probe’и проганяються через retrieval‑шар проти поточної бази знань — того самого Git‑репозиторію з context blocks та інших підключених джерел. Сканер аналізує відповіді й класифікує стан документації для кожного аспекту:
- «clean» — інформація є, вона актуальна й достатньо повна;
- «stale» — інформація формально існує, але виглядає застарілою або суперечить іншим джерелам;
- «incomplete» — є часткові відомості, але не вистачає деталей, щоб агент міг упевнено діяти;
- «missing» — жодних релевантних даних не знайдено.
Результатом роботи сканера стає консолідований огляд того, чого саме бракує в знаннях для кожного інциденту чи тікета. Це не абстрактне «нам потрібно краще документувати систему», а конкретний перелік відсутніх елементів: системна інформація, API, бізнес‑процеси, «племінні» знання, які досі жили лише в головах окремих інженерів.
Такий огляд дозволяє вперше побачити монолітну базу знань не як суцільну «сіру масу», а як карту з чітко позначеними ділянками: тут усе добре, тут застаріло, тут дірка. І, що важливо, ця карта будується не з точки зору авторів документації, а з точки зору реальних робочих завдань, які мають виконувати агенти.
Пріоритизація прогалин: критичне, високе, середнє — і що документувати першим
Коли сканер проганяє десятки чи сотні інцидентів і Jira‑квитків, кількість виявлених прогалин швидко зростає. Якщо просто скласти їх у довгий список, команда ризикує опинитися в знайомій ситуації: «так, ми знаємо, що документація погана, але з чого почати?».
Щоб цього уникнути, у фреймворку вводиться ще один рівень структурування — класифікація прогалин за критичністю. Кожен виявлений gap отримує оцінку: critical, high або medium.
Критичними позначаються ті прогалини, які безпосередньо блокують розв’язання інциденту або виконання бізнес‑критичного завдання. Наприклад, відсутність опису сервісу, який є єдиною точкою входу для платежів, або неформалізоване бізнес‑правило, що визначає, коли замовлення вважається доставленим.
High‑пріоритет отримують прогалини, які не блокують завдання повністю, але суттєво знижують якість роботи агента: він змушений робити припущення, часто перепитувати людину, витрачати більше часу на уточнення. Це можуть бути, наприклад, частково описані API без прикладів реальних payload’ів або бізнес‑процеси без чітких варіантів гілкування.
Medium‑рівень — це прогалини, які впливають на зручність і ефективність, але не є критичними для основних сценаріїв. Наприклад, відсутність детального опису допоміжних сервісів або внутрішніх інструментів моніторингу.
Така класифікація перетворює amorphous «нам треба краще документуватися» на керований беклог робіт з документацією. Команди можуть планувати спринти, де поруч із фічами й техборгом з’являються задачі на створення або оновлення конкретних context blocks, прив’язаних до критичних і high‑прогалин.
Важливо, що цей беклог формується автоматично на основі реальних інцидентів і тікетів, а не з суб’єктивних відчуттів. Це дозволяє сфокусувати зусилля там, де кожен новий блок знань дає максимальний приріст до здатності агентів працювати автономно.
Висновок: знання як інфраструктура, а не побічний продукт
Історія, яку показує Радж Навакоті, — це не про черговий «правильний стек» для AI‑агентів. LLM, MCP, RAG — усе це вже є в більшості великих компаній. Проблема в тому, що вони живляться з монолітної, фрагментованої й частково усної бази знань, де 40% критичної інформації існує лише як tribal knowledge.
Demand‑driven context пропонує поставити знання на ті самі рейки, що й код: інциденти як тести, провали як сигнал про прогалини, Git‑репозиторій як джерело правди, автоматичні сканери як інструмент контролю якості, пріоритизація за критичністю як спосіб планування роботи.
У цій моделі інциденти перестають бути лише проблемами, які треба «погасити», і стають джерелом структурованого контексту. Кожен розбір додає нові блоки, кожен сканер — нові сигнали про те, де ще бракує знань. Агенти поступово переходять від ролі «талановитого, але дезорієнтованого стажера» до інструменту, який справді розуміє домен, у якому працює.
Для enterprise‑команд це означає неприємну, але неминучу істину: ніхто ззовні не прийде й не «полагодить» вашу базу знань. LLM‑провайдери покращуватимуть моделі, ринок retrieval‑інструментів зростатиме, але моноліт внутрішнього знання доведеться розбирати самим — інцидент за інцидентом, context block за context block’ом.