Сьогодні, у світі генеративного та агентного ШІ, де ми як люди в циклі (humans-in-the-loop) маємо обробляти величезні обсяги інформації та контенту, а також створювати й контролювати ще більше даних за допомогою наших ШІ-інструментів і систем (внутрішніх і зовнішніх), немає сумнівів, що дані та знання є дуже важливим активом, а то й ресурсом.
Якість цих знань визначає релевантний контекст, у якому працюють агенти. Це можуть бути ваші власні цикли та інструменти або підключені Claude чи ChatGPT (чи що б ми не використовували). Контекст визначає результати й вихідні дані наших агентів. А вихідні дані наших агентів визначають якість того, що ми виносимо назовні: контенту, висновків, програмного коду тощо. Тож знання є наріжним каменем кожного бізнесу, цифрового рішення, сервісу та експертизи.
Це новий шар, що лежить поруч із реляційними даними, які ми зберігаємо в базах даних. Але це не одне й те саме. Важливо розрізняти дані, які продукує бізнес-система (хоч би які бізнес-процеси вона обслуговувала), і дані знань, що пояснюють, як і чому ці бізнес-процеси працюють. Реляційні дані відповідають на питання ЩО і ХТО, а дані знань відповідають на питання ЧОМУ і ЯК. ЩО і ХТО є класичними записами даних у кожній системі, а ЧОМУ і ЯК є чимось новим для систем. Вони завжди були прихованим активом, розкиданим по нескінченних документах у Google Drive і Confluence, в інструкціях з онбордингу, окремих специфікаціях і пітч-деках. Це завжди були справжні знання, що осіли в головах реальних людей.
Тепер ці знання необхідно перенести в систему, бо відповіді на ЧОМУ і ЯК потрібні для роботи процесів за участі ШІ: від планування нової функції в коді до аналізу звітів про рух грошових коштів і побудови контент-плану на наступний місяць з розбивкою за конкретними ICP для окремих каналів.
Тож очевидно, що треба розв'язати два пов'язані завдання: організувати знання та підключити знання до ШІ.
І що цікаво: те, як ви організуєте знання, впливає на те, як ви підключите їх до ШІ.
Переповнений простір і складні питання
Звісно, рішень у цьому просторі вже чимало. Але є умови, які впливають на вибір рішення: як ви хочете контролювати знання як єдине джерело правди та розподіляти їх, підключені до ШІ-інструментів, рівномірно й контрольовано між різними людьми в циклі?
Найпростіший варіант: створити, наприклад, проєкт в організації Claude Team і завантажити потрібні документи або підключити Google Drive. Але як керувати змінами? Хто вирішує, який документ додати наступним? Як загострити збагачення контексту в цьому безкінечному морі текстового контенту? А що, як це потрібно не в Claude, а всередині CRM чи ERP-системи, де ШІ-асистент має відповідати на питання, пов'язані з даними цієї системи?
Якщо ми залишаємося в Claude чи ChatGPT, як рівномірно розподілити це між чатами для дизайну, коду та інших задач?
- Як контролювати, які дані ми додали до нашого ШІ-асистента?
- Як робити ревізії та версіонувати їх?
- Як миттєво відкликати доступ до цих даних для певних конекторів чи користувачів?
- Як бачити, який агент звертався до знань, коли і з якою людиною в циклі?
- Як зробити пошук у цих знаннях якісним?
- Як із цим усім впоратися? Може, просто скласти все у векторну базу даних? І як тоді нею керувати?
- А що, як сьогодні це потрібно всередині компанії, а завтра той самий підхід треба застосувати в конкретній системі чи адаптувати під кастомне налаштування клієнта?
Знання як кодова база
Отже, відповідь на все це: знання, які можна вважати організаційним чи бізнес-активом, слід зберігати й керувати ними як кодовою базою. Прикладами такого активу можуть бути специфікації проєктів, посібники для користувачів, гайди з онбордингу, документація API, маркетингова стратегія, спеціальний глосарій, айдентика бренду, опис функціональності ERP/CRM тощо. Векторна база даних усе ще може бути корисною для пошуку, але лише як похідний індекс, побудований поверх знань, який можна перебудувати будь-коли, а не як місце, де живуть самі знання.
І саме тут відповіддю є Git. У ньому вже є всі потрібні для цього атрибути: версіонування, єдине джерело правди та процес merge/pull. Кожен актив знань можна організувати як окремий Git-репозиторій з потрібною структурою папок і файлами у форматі Markdown (.md), з атрибутами, вікі-посиланнями між документами тощо. Це ідеальний матеріал, щоб ШІ читав, розумів і тримав його як контекст.
Підключення до ШІ через MCP
У такому налаштуванні можна мати невеликий захищений вебзастосунок на власному хостингу з MCP-сервером, який надає агентам інструменти пошуку та читання.
І вся суть саме в цьому вебзастосунку. Більшість власників знань, як-от маркетинг, бренд, продажі, операції, не користуються Git, і не мусять. Вебзастосунок дає їм простий редактор поверх тих самих репозиторіїв: вони переглядають, редагують і додають Markdown-документи в браузері, а кожна зміна непомітно комітиться в Git, з тією самою історією та можливістю відкату, що й будь-який коміт розробника. Технічні люди й надалі можуть працювати з репозиторієм напряму зі своєї IDE чи Obsidian. Обидва шляхи ведуть до того самого єдиного джерела правди.
До MCP-сервера можна підключитися через OAuth або токен, залежно від зовнішнього ШІ-інструмента. Claude, наприклад, чудово працює з OAuth, де підключення прив'язане до конкретної людини в циклі. В інших випадках достатньо підключення до MCP через токен. Для кастомних підключень можна також обмежити доступ певними IP-адресами (наприклад, якщо ми знаємо, що конектор використовуватиметься лише з конкретного продакшн-сервера ERP).
Кожен MCP-конектор відповідає одному репозиторію знань і прив'язаний до свого Git-репозиторію через SSH-ключ. Коли агент підключається до репозиторію знань, вебзастосунок (якщо ще не завантажив і не закешував його нещодавно) клонує Markdown-файли з налаштованої гілки налаштованого репозиторію за допомогою SSH-ключа і переносить їх у сховище. Після цього вони доступні агенту для читання й пошуку. Кожна дія агента записується: який інструмент використано, якою людиною в циклі і коли.
Результат
І тоді все працює ідеально: кожна людина, що користується ШІ-інструментом, завжди має доступ до найсвіжішої, щойно стягнутої з Git версії конкретного активу знань. Для організації це теж вигідно: кожен актив знань налаштований, контрольований і під наглядом, а всі підключення з усіх інструментів журналюються.
У Well Digit ми побудували таке рішення для власних потреб і дуже задоволені результатами.
Стикаєтеся з тими самими питаннями? Якщо ви думаєте, як організувати знання своєї компанії, тримати їх під контролем як єдине джерело правди та безпечно підключити до Claude, ChatGPT чи власної CRM/ERP, я радо поговорю. Ми можемо проконсультувати щодо підходу або допомогти побудувати й налаштувати інфраструктуру knowledge-as-code для вашої команди чи продукту.
Пишіть нам через сторінку контактів і погляньте на наше self-hosted рішення Notedigit, де ми розв'язуємо це завдання саме так, як описано вище.