Google OKF, Hermes та Gbrain: папки як графи знань

Ідея Андрія Карпати «LLM-Wiki» — це ШІ, який може самостійно читати та писати Markdown-вікі, щоб працювати над проектами, викликала великий інтерес. Окремі особи та невеликі команди починають її випробовувати. Коли ви доручаєте роботу ШІ, складною частиною часто є не сама модель, а спосіб надання їй необхідної інформації.

Якщо попросити його підсумувати дані замовлень минулого місяця, він не зможе дати правильну відповідь, якщо не знає, у яких таблицях знаходяться дані, що означають стовпці та як таблиці пов’язані між собою. Формат відкритих знань (OKF) спрямований на усунення таких проблем. Його головним ворогом є інформаційні ізоляції, а не масштаб.

Внутрішні знання, такі як схеми таблиць, визначення метрик, посібники з роботи з інцидентами та шляхи об’єднання систем, зберігаються в каталогах метаданих, вікі-сайтах, коментарях до коду та у досвідчених співробітниках. Кожен новий проект агента починається зі збору та повторного опанування цього контексту з нуля. У матеріалах Google Cloud щодо OKF це називається проблемою формування контексту.

Для чого підходить OKF

Більша частина того, що потрібно агенту, є специфічною для компанії: визначення таблиць, способи обчислення метрик, процедури експлуатації, специфікації API. Ці матеріали розкидані. OKF спрямований на їх об’єднання у файли формату Markdown, якими може керувати Git, щоб агенти та співробітники могли користуватися зібраним набором інформації, замість того щоб щоразу шукати все заново. Файл index.md та посилані на нього концептуальні файли стають основою для навігації.

Якщо ви записуватимете контекст під час роботи з ШІ, ви будете накопичувати щось, що можна буде використовувати знову. Це відрізняється від необхідності вводити новий запит щоразу під час сеансу.

Як агенти це використовують

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

OKF, MCP та RAG

Кілька технологій, пов’язаних з агентами, часто плутають з OKF. Їхні функції відрізняються.

• OKF зберігає знання, написані заздалегідь: визначення, контракти, інструкції.
• MCP підключає агентів до діючих інструментів та систем під час виконання завдань.
• RAG знаходить відповідні фрагменти з великих неструктурованих баз даних під час отримання запиту.

Вони не є конкурентами. Визначення щотижневих активних користувачів може знаходитися в OKF, тоді як фактичний запит до BigQuery виконується через MCP. Пакети OKF також можуть бути об’єктами пошуку в індексі RAG. Практичне питання полягає у тому, які сфери ви вже охоплюєте та де є прогалини.

Hermes, Wiki LLM та Gbrain

Один із підходів — це запуск середовища агента, такого як Hermes, з Wiki LLM як стандартним компонентом, а потім додавання Gbrain як шару пам’яті. Gbrain, розроблений Гаррі Таном у відкритому форматі, зберігає інформацію у формі, яку агенти можуть використовувати знову. Він більше схожий на зовнішню пам’ять для LLM, ніж на вікі для людей, у дусі ідеї LLM-Wiki від Карпаті. Збережені елементи вбудовані так, щоб пізніше можна було знаходити семантично пов’язані попередні контексти: схожі рішення, пов’язані бізнес-обмеження тощо, а не лише точні збіги ключових слів.

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

Типовий шлях розгортання розміщує агента на VPS за проксі-сервером, що забезпечує доступ з будь-якого місця, а потім підтверджує перший запуск на панелі керування. Після цього робота полягає скоріше у наповненні wiki та пам’яті реальним контекстом, ніж у встановленні програмного забезпечення.

Як виглядає пакет OKF на практиці

Пакет — це каталог файлів Markdown із YAML-фронтматером. Кожен файл присвятований одній концепції: таблиці, показнику, API чи посібнику. У фронтматері містяться поля, які потрібно можливість шукати, такі як тип, назва, опис, теги та часові мітки. У тілі файлу знаходиться проза, формули та приклади, які насправді читають люди та моделі. Посилання між файлами перетворюють каталог на граф, а не лише на дерево, тож агент може перейти від показника до його вихідної таблиці, а звідти — до посібника з роботи з інцидентами.

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

Ця простота є навмисною. У примітках до дизайну Google наголошується на мінімалістичному підході: потрібне лише поле типу, а решту визначають створювачі. Люди можуть вручну створювати пакети. Механізми експорту можуть генерувати їх з існуючих каталогів. Один агент може написати концепцію, яку згодом використовує інший агент. Формат є контрактом; інструменти з обох кінців залишаються замінними.

Використання Hermes та Gbrain

Як тільки Hermes починає працювати, щоденна робота більше нагадує роботу зі знаннями, ніж з інфраструктурою. Ви додаєте нотатки, рішення та визначення у рівень wiki. Gbrain вбудовує їх та робить їх знайденими за змістом. Коли агент згодом стикається з подібним запитанням, він може скористатися цими попередніми контекстами замість того, щоб починати з порожнього запиту.

Кілька звичок роблять цей цикл корисним. Пишіть визначення так, ніби їх буде читати незнайомець через шість місяців. Використовуйте по одній концепції на файл, щоб зберігати чіткість у пошуку інформації. Створюйте посилання на пов’язані концепції замість дублювання тексту. Коли змінюється рішення, оновлюйте концепцію, а не залишайте суперечливі примітки в іншому місці. Ставіться до вікі як до продукту, а не до смітників.

Додаткові набори навичок для Gbrain розширюють можливості агента без змін основної моделі пам’яті. Важливою властивістю є те, що пам’ять та інструменти залишаються окремими: пам’ять зберігає те, що відомо; інструменти звертаються до діючих систем, коли потрібна дія. Це розділення відображає розмежування OKF та MCP, описане вище.

Вибір відправної точки

Якщо у вашій команді вже є добре підтримуваний вікі з метриками та схемами, перетворення його на пакет у форматі OKF є логічним першим кроком. Якщо основною проблемою є те, що «агенти не можуть бачити наші бази даних», спочатку можна використати сервер MCP перед цими системами. Якщо ж проблема полягає у тому, що «відповіді ховаються серед інформації в Slack», тоді індекс RAG для чатів та замовлень може стати правильним рішенням. Багато команд зрештою хочуть мати всі три рішення, але початок з найбільш очевидної проблеми допомагає залишатися чесними щодо проекту.

Яке б рішення ви не обрали, вимірюйте, чи припиняють агенти ставити одні й ті самі уточнювальні запитання. Це кращий показник успіху, ніж кількість файлів у пакеті.

Перш ніж знання стануть організованими

Якщо подивитися на OKF, стає зрозуміло одне обмеження. І OKF, і RAG допомагають після того, як знання вже організовані. До цього моменту корисний контекст все ще залишається у нотатках зустрічей, журналах чатів, сумнівах та незавершених дискусіях. Формати на кшталт OKF використовуються після того, як знання вже відсортовані. Засоби, які вказують на початкове джерело, використовуються до цього. Замість того, щоб надати моделі готову відповідь, ви даєте їй шлях назад до початкового контексту.

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