OKF + RAG: гібридна архітектура для надійних штучних інтелектуальних агентів

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

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

У червні 2026 року Google Cloud представив формат відкритих знань (Open Knowledge Format, OKF) — специфікацію, нейтральну щодо постачальників, для систематизованих знань, збережених у файлах формату Markdown. Поєднавши його точні пошуки з широким охопленням технології RAG, отримуємо архітектуру, яку варто розглянути для агентів, які мають бути одночасно точними та дослідницькими.

Дві системи пам’яті

Уявіть нового співробітника у його перший день роботи. Перед ним ставлять дві речі.

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

Другий інструмент — це пошукова система, яка перевершує всі інші: тисячі повідомлень у чатах, листувань, заявок на підтримку та стенограм зустрічей. Коли їм потрібно дізнатися, що люди казали на певну тему, або просканувати неструктуровані архіви, вони шукають саме там. Це і є RAG.

Жоден з цих інструментів сам по собі недостатній. Разом вони охоплюють весь спектр інформації, якою володіє організація.

Що таке OKF

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

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

---
type: metric
title: "Monthly Churn Rate"
description: "Official formula for calculating monthly customer churn."
owner: "data-engineering"
tags: [revenue, kpi, board-report]
timestamp: 2026-06-20T10:00:00Z
---

# Monthly Churn Rate

The official churn rate formula used in all board reports and investor decks:

    Churn Rate = (Customers Lost During Month / Customers at Start of Month) × 100

### Rules
- **Do NOT** use trial accounts in the denominator.
- **Do NOT** count plan downgrades as churn.
- Source of truth: `analytics.monthly_churn_summary` table.

### Related
- [Monthly Active Users](mau.md)
- [Revenue Dashboard](revenue_dashboard.md)

Навіщо взагалі це робити?

• Без векторної математики. Коли агенту потрібна формула відтоку, він читає цей файл безпосередньо. Немає жодних ембеддингів, оцінок схожості чи механізмів типу top-k — щоразу лише схвалена відповідь.
• Інтегровано у робочі процеси Git. Зміни проходять через pull requests, перевірки та історію комітів, тож існує журнал аудиту, який показує, хто, коли та чому змінив формулу.
• Без інфраструктури. Немає векторних сховищ, пайплайнів для створення ембеддингів, стратегій розділення даних на частини чи завдань на переіндексацію. Файли знаходяться у папці.

Що таке RAG

RAG з’єднує модель із великими неструктурованими даними у шести кроках:

1. Збирає документи, такі як PDF-файли, електронні листи, сторінки wiki та повідомлення в чаті.
2. Розділяє їх на менші фрагменти.
3. Створює ембеддинги для кожного фрагмента за допомогою моделі ембеддингів.
4. Зберігає ці ембеддинги у базі даних, такій як Pinecone, Weaviate чи pgvector.

Під час запиту вбудовуйте запит у ту саму структуру та отримуйте найбільш схожі фрагменти тексту.

Додайте ці фрагменти до запиту, щоб модель могла відповісти з урахуванням контексту.

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

Гібридний дизайн

У поєднаній архітектурі перед обома типами пам’яті розміщується маршрутизатор. Маршрутизатор аналізує кожен надійшлий запит та вирішує, куди його направити: до підготовленого набору даних, якщо запит стосується офіційного визначення, або до векторного пошуку, якщо запит є відкритим та дослідницьким.

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

from openai import OpenAI
import os
import glob
import yaml

client = OpenAI()

# 1. Load the OKF knowledge bundle from the local directory
def load_okf_bundle(bundle_path: str) -> dict:
    """Reads all Markdown files in the OKF directory into a searchable dict."""
    knowledge = {}
    for filepath in glob.glob(f"{bundle_path}/**/*.md", recursive=True):
        with open(filepath) as f:
            content = f.read()
            # Extract the title from YAML frontmatter
            if content.startswith("---"):
                _, frontmatter, body = content.split("---", 2)
                meta = yaml.safe_load(frontmatter)
                title = meta.get("title", os.path.basename(filepath))
                knowledge[title.lower()] = body.strip()
    return knowledge

# 2. Search OKF (deterministic, keyword-based)
def search_okf(query: str, okf_knowledge: dict) -> str | None:
    """Simple keyword match against OKF titles."""
    for title, content in okf_knowledge.items():
        if title in query.lower():
            return content
    return None

# 3. Search RAG (probabilistic, vector-based)
def search_rag(query: str) -> str:
    """Placeholder for your vector DB search (Pinecone, Weaviate, etc.)."""
    # results = vector_db.similarity_search(query, top_k=5)
    return "RAG context: [retrieved chunks would appear here]"

# 4. The Intelligent Router
def answer_query(query: str, okf_bundle_path: str) -> str:
    okf_knowledge = load_okf_bundle(okf_bundle_path)

    # Try OKF first (deterministic path)
    okf_result = search_okf(query, okf_knowledge)

    if okf_result:
        context = f"[SOURCE: Official Knowledge Base (OKF)]\n{okf_result}"
    else:
        # Fall back to RAG (probabilistic path)
        context = f"[SOURCE: Document Search (RAG)]\n{search_rag(query)}"

    # Send to LLM with the retrieved context
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "Answer using ONLY the provided context."},
            {"role": "user", "content": f"Context:\n{context}\n\nQuestion: {query}"}
        ]
    )
    return response.choices[0].message.content

Тут відповідність обробляється навмисно примітивно — шляхом пошуку за заголовком, щоб ідея залишалася видимою. У продакшн-системах використовується краще маршрутизування, наприклад класифікатор чи фільтр метаданих, які дозволяють ефективно керувати ситуацією, коли обидві джерела повертають щось релевантне.

Висновок

Для корпоративних агентів не існує вибору між OKF та RAG. Найкращий підхід — використання обох. Детерміністична база знань, керована Git, захищає ті факти, які ніколи не повинні бути неправильними: KPI, контракти API та посібники з експлуатації. Ймовірнісний векторний пошук охоплює величезні архіви неструктурованих матеріалів, які неможливо опрацювати вручну. Результатом є агент, який забезпечує точність там, де це важливо, та допомагає у пошуку нового там, де це необхідно.