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, электронных писем, страниц вики и сообщений в чате.
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 и руководства по эксплуатации. Правдоподобный векторный поиск позволяет обрабатывать большие архивы неструктурированных данных, которые невозможно отбирать вручную. В результате получается агент, который дает точные ответы там, где это важно, и помогает в поиске новой информации там, где это необходимо.