Фабрика знань для AI-Native організації: як фреймворк GAP перетворює хаос першоджерел на довірений канон

Статтю написано спеціально для DOU.

Логічне продовження статті «Стеля третього покоління: чому в епоху ШІ організаціям потрібна двоконтурна архітектура знань». У першій частині ми зафіксували розподіл інформаційного простору на Операційний та Інституційний контури. Тут розберемо сам виробничий механізм: як саме знання народжуються, верифікуються та фіксуються в каноні організації. Розглянемо фреймворк GAP (Grounded Agentic Pipeline), порівняємо Runtime RAG із Build-time GAP, розберемо 5 стадій контролю якості, мультиформатне делівері та досвід реальних публічних проєктів.

1. Від інформаційної анатомії — до виробничого конвеєра знань

У попередній статті я показував, чому сучасні компанії масово вперлися в «стелю Організацій 3.0». Вільна комунікація в Slack чи Teams та хаос у хмарних дисках створили хронічну ентропію: документація швидко застаріває, контекст вимивається під час ротації людей, а замість надійних інструкцій накопичуються десятки несинхронізованих чернеток.

Рішенням став поділ на два простори: Операційний контур (де люди вільно спілкуються, експериментують і формулюють гіпотези) суворо відділений від Інституційного контуру (де живе перевірений цифровий канон компанії) через контрольований шлюз переходу (Promotion Gate).

       [ ОПЕРАЦІЙНИЙ КОНТУР ]
   (Чернетки, гіпотези, обговорення)
                 │
                 ▼
       ┌───────────────────┐
       │   ПРОГАЛИНА (GAP) │ ◄── ЯК САМЕ ТУТ СТВОРЮЮТЬСЯ
       │       ТА ШЛЮЗ     │     ТА ВАЛІДУЮТЬСЯ ЗНАННЯ?
       └─────────┬─────────┘
                 │
                 ▼
      [ ІНСТИТУЦІЙНИЙ КОНТУР ]
 (Довірений канон: Git, Markdown, SSOT)

Головне прикладне питання, яке постає одразу після цього:

Як саме знання мають вироблятися всередині цієї системи?
Хто і як бере сотні розрізнених первинних джерел — нормативні акти, стенограми мітингів, галузеві стандарти, експертні інтерв'ю — і перетворює їх на бездоганні регламенти, навчальні курси, енциклопедії та стратегії, за якими організація житиме роками?

Три провали неконтрольованої генерації

Здавалося б, найпростіший шлях — посадити мовну модель (або зв'язку агентів), відкрити їй доступ до сховища і наказати писати регламенти. Але без жорсткої інженерної обв'язки така генерація стабільно призводить до трьох проблем:

1. Галюцинації та дрейф фактів (Hallucinations & Fact Drift): модель легко додумує деталі там, де у вихідних текстах бракує даних. Гірше того, між різними робочими сесіями агент суперечить сам собі, щоразу генеруючи відмінні версії «правди».
2. Руйнування системної узгодженості (Loss of Consistency): термінологія, структура документів і тон викладу починають «плисти». Те, що модель сформулювала у вівторок, конфліктує за термінами з тим, що інший агент чи колега створили в четвер.
3. Втрата аудиту та відповідальності (Lack of Auditability): коли у сховищі з'являється новий документ або змінюється наявний, практично неможливо відстежити, на основі якого саме джерела з'явилося конкретне формулювання і чи перевіряв його профільний спеціаліст.

Без чіткого технологічного конвеєра залучення ШІ лише прискорює засмічення документації правдоподібними, але неперевіреними текстами. Щоб подолати цей бар'єр, потрібен спеціалізований інженерний підхід — GAP (Grounded Agentic Pipeline).

2. Зміна парадигми: Runtime RAG проти Build-time GAP

Найпопулярніший сьогодні спосіб підключити ШІ до корпоративних знань — це патерн RAG (Retrieval-Augmented Generation): документи ріжуть на уривки (chunks), складають у векторну базу, і на кожне запитання користувача система шукає схожі фрагменти, передаючи їх моделі в момент генерації відповіді.

Для разових швидких підказок це працює. Але для формування базових знань організації класичний RAG має суттєву ваду: він переносить усю обробку й фільтрацію помилок у рантайм (Runtime), безпосередньо на кінцевого користувача.

[ ТРАДИЦІЙНИЙ RAG: Ризик на користувачеві ]
Сирі джерела ──► Векторизація ──► [Запит користувача] ──► Пошук шматків ──► Генерація на льоту ──► Кінцевий ризик!

[ ФРЕЙМВОРК GAP: Якість гарантована на конвеєрі ]
Сирі джерела ──► [Конвеєр GAP: Агент + Статут + Review] ──► Верифікований Канон ──► Миттєвий надійний доступ

Важливий нюанс: GAP не воює з RAG. Навпаки: структурований і взаємопов'язаний результат роботи GAP часто робить окремий векторний RAG просто непотрібним — і люди, і агенти можуть шукати точні відповіді безпосередньо у скомпільованих файлах. А там, де векторний пошук справді потрібен (наприклад, серед сотень тисяч сторінок), GAP дає йому не інформаційний шум, а вичищений, структурований контекст.

3. Архітектурне ядро GAP: 5 стадій забезпечення якості

Концепція GAP (Grounded Agentic Pipeline) розв'язує подвійне завдання: вона закриває прогалину (gap) між сирими текстами та готовими документами, а також тримає роботу агентів жорстко «заземленою» (grounded) на фактологічну основу.

Конвеєр GAP складається з 5 послідовних стадій:

┌────────────────────────────────────────────────────┐
│ 1. ДЖЕРЕЛО (Source of Truth)                       │
│   • Незмінні первинні матеріали (raw/)             │
│   • Заземлення фактів, нуль галюцинацій            │
└─────────────────────────┬──────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────┐
│ 2. СТАТУТ (Constitution)                           │
│   • Правила гри та стандарти (AGENTS.md)           │
│   • Конвенції структури, темплейтів і схем         │
└─────────────────────────┬──────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────┐
│ 3. АГЕНТ ТА НАВИЧКИ (Agent + Skills)               │
│   • Оркестратор + ізольовані субагенти             │
│   • Спеціалізовані навички (.agents/skills/)       │
└─────────────────────────┬──────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────┐
│ 4. ВЕРИФІКАЦІЯ (Review Gate)                       │
│   • Звірка з джерелами та лінтинг посилань         │
│   • Журнал аудиту log.md + Human-in-the-Loop       │
└─────────────────────────┬──────────────────────────┘
                          │
                          ▼
┌────────────────────────────────────────────────────┐
│ 5. СПОЖИВАННЯ (Delivery)                           │
│   • Верифікований канон (Markdown + YAML)          │
│   • Obsidian, вебпортали, PDF-звіти, API           │
└────────────────────────────────────────────────────┘

Стадія 1. Джерело (Source of Truth, raw/)

Усе починається з первинних матеріалів: законів, стандартів, транскриптів мітингів, регламентів чи інтерв'ю. Усі вони зберігаються в директорії raw/ або references/.

• Правило незмінності (Immutable Raw): після фіксації матеріалу в каталозі з датою будь-які його редагування суворо заборонені.
• Жодних вигадок: агенту прямо заборонено спиратися на власні здогадки з параметричної пам'яті моделі або шукати щось у мережі без явної вказівки. Першоджерело — єдиний критерій фактів.

Стадія 2. Статут проєкту (Constitution, AGENTS.md)

Агенти не можуть працювати на основі усних домовленостей. Поруч із контентом створюється версійований документ правил — Статут (AGENTS.md або CLAUDE.md).

• Це постійний інженерний закон репозиторію, зафіксований у системі контролю версій.
• Статут визначає структуру папок, формат метаданих (YAML frontmatter), обов'язкові шаблони, правила найменування файлів (латиниця в kebab-case), формат відносних посилань і список заборонених дій (наприклад, заборона прямого коміту в main чи модифікації старих записів логу).

Стадія 3. Агент-виконавець та модульні навички (Agent + Skills)

Замість спроб вкласти всі завдання в один велетенський промпт, операції розбиваються на багаторазові інструкції — навички (Skills) у каталозі .agents/skills/:

• скіл для імпорту та первинного аналізу джерела (ingest);
• скіл для синтезу статей або регламентів (create);
• скіл для перевірки цілісності зв'язків і метаданих (linter).

Патерн субагентів та ізоляція контексту:

Якщо завантажити в одне контекстне вікно 50 великих звітів, модель неминуче деградує: почне губити інструкції, плутати дати та галюцинувати. GAP вирішує це через делегування ізольованим субагентам:

• Головний оркестратор декомпозує завдання на конкретні підзавдання («Проаналізуй розділ 4 стандарту та виділи вимоги безпеки»).
• Субагент стартує з чистим вікном контексту, бере лише потрібний фрагмент першоджерела, виконує скіл і повертає структурований результат.

 ┌────────────────────────────────────────────────────────┐
 │            ГОЛОВНИЙ ОРКЕСТРАТОР (Оглядач)              │
 │  • Керується Статутом (AGENTS.md)                      │
 │  • Не перевантажує свій контекст сирими текстами       │
 └──────────────┬──────────────────────────┬──────────────┘
                │                          │
    [Делегування задачі 1]      [Делегування задачі 2]
                ▼                          ▼
 ┌──────────────────────────┐   ┌──────────────────────────┐
 │ СУБАГЕНТ А (Імпорт)      │   │ СУБАГЕНТ Б (Синтез)      │
 │ • Чисте вікно контексту  │   │ • Чисте вікно контексту  │
 │ • Фокус на джерелі #1    │   │ • Фокус на джерелі #2    │
 └──────────────────────────┘   └──────────────────────────┘

Стадія 4. Верифікація та контроль якості (Review Gate)

Результат роботи агента не вважається прийнятим за замовчанням.

• Звірка з джерелом (Grounding Check): кожне суттєве твердження маркується зворотним посиланням на вхідний файл у raw/.
• Технічний лінтинг: скрипти перевіряють коректність відносних посилань, наявність обов'язкових полів у frontmatter та шукають сторінки без вхідних лінків.
• Журнал аудиту (log.md): будь-яка дія записується в кінець файлу в режимі append-only. Змінювати чи видаляти старі записи не можна.
• Участь людини (Human-in-the-Loop): на ключових ділянках людина-експерт переглядає стандартний git diff і затверджує злиття змін.

Стадія 5. Споживання та делівері (Delivery & Consumption)

Отримані знання не замкнені у специфічному софті. Вони зберігаються у нейтральному відкритому форматі — чистий Markdown із YAML-метаданими, доступний для будь-яких інструментів компанії.

4. Мультиформатне споживання: 5 сценаріїв використання канону

Фундаментальний принцип підходу — відокремлення змісту від форми подачі (Separation of Content and Presentation).

Один раз зібраний і верифікований масив знань закриває кілька робочих сценаріїв одночасно:

                           ┌──► 1. Локальна база знань (Obsidian Vault)
                           │
                           ├──► 2. Корпоративний вебпортал (MkDocs, Docusaurus)
     ВЕРИФІКОВАНИЙ         │
    КАНОН ЗНАНЬ GAP  ──────┼──► 3. Експорт у документи (PDF, накази, слайди)
 (Markdown + frontmatter)  │
                           ├──► 4. Вхід для наступного конвеєра (Chaining)
                           │
                           └──► 5. Прямий агентний пошук (grep, метадані)

1. Інтерактивна база знань (Obsidian Vault):
   Директорію проєкту можна просто відкрити як сховище Obsidian. Завдяки стандартизованим посиланням команда одразу отримує граф зв'язків (Knowledge Graph), зворотні посилання та пошук без налаштування окремих серверів чи баз даних.
2. Детермінована публікація (Build & Publish):
   Репозиторій підключається до генераторів статичних сайтів (MkDocs, Docusaurus, Astro чи Quartz). Під час релізу в Git спрацьовує звичайний CI/CD пайплайн, який компілює файли у швидкий сайт із навігаційним деревом та пошуком. Головне правило: змінюється лише вихідний Markdown, а не згенерований HTML.
3. Експорт у нормативні та робочі артефакти:
   На основі канону працюють скрипти конвертації (через Pandoc або WeasyPrint). За потреби система генерує офіційні накази, пакети політик у PDF чи слайди для презентацій.
4. Ланцюгування конвеєрів (Pipeline Chaining):
   Верифікований результат одного конвеєра стає незмінним вхідним джерелом для наступного, вужчого завдання:
   • Пайплайн 1: Опрацювання первинного галузевого стандарту ──► Формування внутрішнього регламенту організації.
   • Пайплайн 2: Внутрішній регламент як джерело ──► Генерація навчального курсу для працівників.
   • Пайплайн 3: Матеріали курсу як джерело ──► Автоматичне створення тестових питань для перевірки знань.
5. Прямий пошук агента в базі знань (Direct Agent Search):
   Оскільки знання зберігаються у чистому тексті з чіткими заголовками та YAML-тегами, асистентам часто не потрібна окрема векторна база. Агент знаходить точні формулювання звичайним пошуком за ключовими словами чи метаданими без ризику втратити контекст.

5. Інженерний фундамент: Docs-as-Code та сила Git

Застосування зв'язки Markdown + Git замість чергової no-code бази даних — це прагматичний вибір. Інструменти розробки програмного забезпечення відточувалися десятиліттями саме для контролю змін у складних текстових системах:

• Порядковий контроль кожної думки (git diff): Рецензент не перечитує весь документ наново. Він бачить точний звіт: які слова додав чи прибрав агент, які посилання оновилися і які нові факти з'явилися.
• Ізольовані експерименти через гілки (branches): Масштабне оновлення регламенту чи стратегії ведеться в окремій гілці. Основний канон залишається стабільним, доки всі зміни не пройдуть повний цикл перевірки.
• Культура перевірки знань (Pull Requests): Додавання будь-якої нової статті або правки до канону відбувається через стандартну процедуру code review, адаптовану для управління знаннями.

6. Референсна архітектура репозиторію GAP

Для підтримання порядку сховище організовується за чіткою структурою каталогів:

.
├── AGENTS.md (та CLAUDE.md)     # СТАТУТ ПРОЄКТУ: архітектура, обмеження, правила для агентів
├── .agents/skills/              # КАТАЛОГ НАВИЧОК: багаторазові скрипти та інструкції процедур
│   ├── ingest/SKILL.md          # Процедура імпорту та первинного аналізу джерела
│   ├── linter/SKILL.md          # Процедура перевірки цілісності посилань і метаданих
│   └── query/SKILL.md           # Процедура формування синтетичних аналітичних звітів
│
├── inbox/                       # Вхідний буфер для сирих файлів до моменту їхньої фіксації
│   └── assets/                  # Вхідні медіафайли (зображення, схеми)
│
├── raw/                         # 1. ПЕРВИННІ НЕЗМІННІ ДЖЕРЕЛА (Source of Truth, Read-Only)
│   ├── YYYY-MM-DD/              # Архів матеріалів за датами імпорту
│   └── assets/                  # Архівовані вкладення першоджерел
│
├── templates/                   # ШАБЛОНИ: обов'язкові каркаси для концепцій, сутностей, звітів
│   ├── article.md
│   ├── index.md
│   └── log.md
│
└── wiki/ (або policy/, course/) # 2. ВЕРИФІКОВАНІ ЗНАННЯ (Продукт роботи конвеєра)
    ├── concepts/                # Базові концепції, теорії, технологічні стандарти
    ├── entities/                # Персоналії, організації, системи, інструменти
    ├── archives/                # Збережені комплексні аналітичні відповіді на запити
    ├── index.md                 # Навігаційний каталог-покажчик усіх одиниць знань
    └── log.md                   # Незмінний журнал аудиту операцій (хто, коли і що зробив)

Така топологія забезпечує повну прозорість: будь-яке твердження у wiki/concepts/ можна за кілька секунд простежити через запис у log.md до конкретного абзацу у вхідному файлі raw/YYYY-MM-DD/.

7. Доказова база: публічні проєкти у різних доменах

Фреймворк GAP народився як узагальнення практичного досвіду створення баз знань.

Поштовхом став концепт LLM Wiki, запропонований співзасновником OpenAI Андреєм Карпати (Andrej Karpathy). Карпати описав ідею використання мовних моделей для ведення персональної накопичувальної вікі. Я взяв цей задум і адаптував його для системної роботи: додав Статут проєкту, ізоляцію субагентів, Review Gate, журнал аудиту та делівері в різних форматах.

Цей підхід був викладений у статті «Від RAG до LLM-Wiki», яка перемогла як найкраща технічна стаття липня на DOU. Базовий каркас викладено у відкритому репозиторії llm-wiki.

Нижче наведено лише кілька публічних проєктів, про які я можу розповісти відкрито (частина масштабніших баз знань розгорнута в закритих контурах):

Різні домени — від історичних енциклопедій до персональної аналітики — показують спільний принцип: надійність системи знань тримається на передбачуваному ланцюжку: Джерело ──► Статут ──► Агент ──► Верифікація ──► Делівері.

8. Де GAP не підходить: межі застосування

У кожного інструмента є своя сфера призначення, і GAP — не виняток. Спроба використати його скрізь без розбору лише створить зайві ускладнення.

1. Людина залишається вузьким місцем (Review Bottleneck):
   GAP не прибирає людину з контуру, а переносить її увагу з моменту відповіді користувачеві на етап підготовки знань. На відповідальних ділянках експерт усе одно вичитує запропоновані правки.
2. Контент фіксується релізами (Static Snapshots):
   Підхід розрахований на періодичну компіляцію знань. Він не призначений для динамічних потоків — біржових котирувань чи моніторингу серверів.
3. Поріг входження в інструменти (Skill Barrier):
   Docs-as-Code вимагає від команди базового володіння Git, розуміння гілок і розмітки Markdown. Якщо гуманітарній команді не надати зручних інтерфейсів, поріг входу може відчуватися гостро.
4. Принцип GIGO (Garbage In — Garbage Out):
   Якщо вхідні матеріали неповні, фальшиві або внутрішньо суперечливі, конвеєр не перетворить їх на надійний канон.
5. Необхідність оновлення самого Статуту:
   Якщо бізнес-правила змінилися, а файл AGENTS.md залишився старим, агенти продовжуватимуть генерувати контент за неактуальними лекалами.

9. Чек-лист запуску: 6 практичних кроків для команди

Послідовність дій для запуску власного конвеєра знань:

• Крок 1. Зафіксуйте першоджерела (raw/): збережіть усі авторитетні матеріали вашого домену в окрему незмінну папку та суворо обмежте агента роботою виключно з цими текстами.
• Крок 2. Сформулюйте Статут проєкту (AGENTS.md): зафіксуйте структуру репозиторію, вимоги до frontmatter, правила найменування файлів і список заборонених дій.
• Крок 3. Виділіть перші навички (.agents/skills/): почніть із двох простих операцій — ingest для імпорту нових текстів і lint для перевірки посилань.
• Крок 4. Налаштуйте Review Gate та журнал (log.md): упровадьте правило перевіряти правки через git diff перед злиттям і фіксувати кожну дію в append-only лозі.
• Крок 5. Визначте формат делівері: оберіть спосіб, у який команда читатиме матеріали: локально в Obsidian, на статичному вебпорталі через MkDocs чи через експорт у PDF.
• Крок 6. Проведіть пілотний цикл: проженіть через конвеєр один невеликий документ або розділ регламенту, протестуйте процес рев'ю та оцініть результат перед масштабуванням.

10. Висновок: інституційна пам'ять замість випадкових відповідей

Поєднання обох концепцій дає практичну формулу організації, що працює з ШІ:

1. Двоконтурна модель підтримує інформаційну гігієну: чернетки, гіпотези та вільні обговорення залишаються в Операційному контурі, а підтверджені рішення переходять в Інституційний.
2. Фреймворк GAP виступає робочим конвеєром: бере сирі тексти й через субагентів, Статут та верифікацію перетворює їх на надійні цифрові активи.

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