За пределами одного пути получения данных: канонические знания, RAG и реальные запросы для корпоративных агентов

Заголовок, утверждающий, что новый открытый формат заменяет векторную базу данных, вызывает скептицизм. Важной частью этого утверждения является не сам факт замены, а более серьезный архитектурный вопрос: не слишком ли много различных видов корпоративных знаний обрабатываются с помощью одного и того же механизма поиска?

Внутри компании под «знаниями» понимаются совершенно разные вещи. Считается знанием тикет поддержки, а также 60-страничный документ с проектом, схема базы данных, определение метрики или руководство по реагированию на инциденты. Также считается знанием текущее количество задержек в доставке. Эти элементы ведут себя по-разному, поэтому странно, что ИИ-агент должен обрабатывать их все одинаковым способом.

Полезная классификация не заключается в противопоставлении OKF и RAG, и дело не в том, что векторные базы данных умерли. Речь идет о практическом сортировании информации на три категории: знания, которые необходимо извлекать, знания, которые следует хранить в каноническом виде, и знания, которые нужно запрашивать в реальном времени.

Обычная корпоративная проблема

Представьте вымышленную логистическую компанию на основе SaaS с примерно 120 инженерами. Как и многие компании, экспериментирующие с агентами, она связала внутренние документы, рабочие процессы поддержки, операционные системы, показатели эффективности и руководства с платформой агентов. Для большинства вопросов это работает нормально.

Затем кто-то запрашивает показатель своевременной доставки, и система выдает три разные формулы расчета:

• Команда по обработке данных учитывает посылки, прибывшие в назначенную дату.
• Панель управления продуктом использует несколько иной способ расчета.
• Документация, предназначенная для клиентов, не учитывает отмененные заказы и возвраты.

Ничто из этого не является бессмыслицей. Разные команды создавали их по разным причинам. Проблемы начинаются тогда, когда агенту приходится решать, какая версия считается авторитетной. База данных векторов может указать на то, что находится в семантической близости, но у неё нет способа узнать, какую версию компания объявила официальной. Это отдельная проблема.

Релевантность — не авторитет

Стандартный процесс RAG возвращает все документы, соответствующие запросу. Если три документа описывают один показатель тремя способами, все три будут возвращены. Лучшая классификация, дополнительные метаданные, переклассификация, увеличение значения top_k или размер окна контекста могут помочь. Ни один из этих факторов не отвечает на организационный вопрос о том, какое определение считается официальным.

Поэтому настоящая слабость заключается не просто в том, что RAG может генерировать ложную информацию. Релевантность и авторитет — это разные свойства, и корпоративным агентам всё чаще требуются оба из них.

Когда структура — это смысл

Ещё одна причина, по которой не вся информация подходит для одного механизма поиска, связана с формой данных. Возьмём таблицу с десятью строками и семью столбцами — её смысл заключается не только в самих словах, но и в взаимосвязи заголовков, меток строк, значений, единиц измерения и окружающего контекста.

Если разделить такую таблицу на фрагменты по 256 токенов, один из фрагментов может содержать лишь пару заголовков, например «регион» и «доход», в то время как другой — значения «Восток: 2,1 млн» и «Запад: 1,8 млн». Модель может правильно восстановить эти связи, а может и нет.

Для прозы обычно именно такой способ разбиения на фрагменты и требуется. Однако для структурированных данных это превращается в странный обходной путь:

1. начать с структуры
2. преобразовать её в текст
3. разделить текст на фрагменты
4. вставить фрагменты в модель
5. вызвать поиск нескольких фрагментов
6. попросить модель восстановить исходную структуру

В определённый момент возникает вопрос: действительно ли этот объект должен был быть фрагментирован вообще. То же самое касается схем баз данных, путей объединения данных, правил конфигурации, формул для расчёта показателей, SLA и процедур эксплуатации. Структурированный контент в RAG не запрещён. Суть в том, что структура требует особого обращения, если её потеря меняет смысл.

Векторная база данных никогда не была источником истины

У вымышленной компании была ещё одна распространённая проблема: знания были рассеяны. Схемы описывались в комментариях к базе данных, вики-страницах GitHub, Confluence и файлах миграции. Определения показателей находились в панелях аналитики, технических спецификациях продукта, документациях команды по обработке данных и старых презентациях. Руководства по работе были разбросаны по Notion, тикетам инцидентов, Slack и GitHub. Часть логики объединения данных хранилась в основном в голове того, кто дольше всего работал над проектом.

Создание векторной базы данных на этой основе не привело к появлению единого источника истины. В результате получился индекс существующих несоответствий, позволяющий их искать. Это имеет ценность, но это не является механизмом управления.

Что добавляет OKF

Особенность формата Open Knowledge Format заключается не в Markdown, который уже существует. Речь идет о идее сделать корпоративные знания явно читаемыми для машин, сохраняя при этом удобство их использования людьми. По сути, файл с концепцией начинается со структурированных метаданных:

type: metric
name: on_time_delivery_rate
owner: data-platform
reviewer: product
trust_tier: verified
stale_after: 1 day
related:
- shipments
- sla_definition

и продолжается объяснением, написанным для людей:

# On-Time Delivery Rate
Percentage of shipments delivered on or before the current
promised delivery date.
## Excludes
- cancelled shipments
- test orders
- returns

Агент теперь получает не просто текст о своевременной доставке. Он также может узнать, кто является владельцем определения, актуально ли оно, проверялось ли оно, от чего оно зависит и какие другие концепции с ним связаны. Вопрос меняется с того, какой фрагмент наиболее похож на ту или иную концепцию, на то, является ли она канонической, и безопасно ли её использовать.

OKF не заменяет RAG

Здесь вывод отличается от заголовка. Более точная картина — это последовательность: канонические знания хранятся в OKF, исследовательские знания — в RAG, а текущее состояние — в реальных системах.

Канонические знания включают схемы баз данных, определения метрик, SLA, бизнес-правила, руководства по эксплуатации и информацию об владельцах. Обычно задаётся вопрос о том, каково официальное, актуальное определение.

Эксплораторское знание включает в себя исторические отчеты, записи о происшествиях, переписку с поддержкой, документацию по проектированию, тематические исследования и отзывы клиентов. Вопрос заключается в том, какая информация актуальна для решения конкретной задачи. Именно здесь RAG демонстрирует высокую эффективность.

Актуальное состояние включает в себя сегодняшний показатель своевременности выполнения задач, текущий баланс клиента, активные инциденты, открытые заказы и уровень запасов. Вопрос заключается в том, какова реальная ситуация в данный момент, и векторный индекс, скорее всего, не является подходящим инструментом для ответа на него. Система управления, отвечающая за эти показатели, должна предоставлять их.

Некоторые данные не следует извлекать

Именно здесь архитектура становится более интересной. Предположим, пользователь просит показать пять лучших клиентов по доходу за этот квартал. Один из вариантов реализации заключается в загрузке документов и данных в индекс и последующей сортировке их с помощью модели. Это возможно, но существует более эффективный подход: агент находит каноническое определение понятия «доход», формирует запрос и выполняет его в системе хранения данных. Например:

SELECT
customer_name,
SUM(revenue) AS total_revenue
FROM sales_data
WHERE quarter = 'Q3_2026'
GROUP BY customer_name
ORDER BY total_revenue DESC
LIMIT 5;

Теперь агент получает два вида информации из двух источников. Значения берутся из канонического слоя знаний, а текущие значения — из системы, которая фактически хранит данные. Агент больше не загружает данные напрямую; сначала он получает структуру, а затем запрашивает информацию у активной системы.

Один агент, три пути к знаниям

Учитывая это различие, некоторые примеры вопросов обрабатываются по-разному:

• Что означает своевременная доставка? Обратитесь к каноническому определению показателя.
• Каков процент своевременной доставки сегодня? Используйте логику расчета из канонического определения, затем запросите данные из активного склада.
• Почему процент снизился в прошлом квартале? Сопоставьте каноническое определение с историческими данными склада, а также, возможно, с информацией из отчетов о инцидентах и записей перевозчиков.

Что произошло с клиентом X в 1-м квартале? Проведите поиск среди прошлых заявок, записей и отчетов.

Происходит сбой базы данных, что теперь делать? Используйте стандартное руководство по действиям.

Агент остается тем же, но пути отличаются. Обсуждение этого более полезно, чем вопрос о замене векторных баз данных.

Маршрутизатор перемещается в центр

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

class HybridKnowledgeRouter:
    def __init__(self, okf, rag):
        self.okf = okf
        self.rag = rag

    def classify(self, query: str) -> str:
        q = query.lower()

        if any(word in q for word in [
            "schema", "column", "definition",
            "metric", "sla", "runbook"
        ]):
            return "canonical"

        if any(word in q for word in [
            "history", "report", "example",
            "case study", "what happened"
        ]):
            return "exploratory"

        if any(word in q for word in [
            "today", "current", "now",
            "latest value", "how many"
        ]):
            return "live"

        return "hybrid"

Метод контекста имеет следующую структуру:

def get_context(self, query: str):
    query_type = self.classify(query)

    if query_type == "canonical":
        return self.okf.lookup(query)

    if query_type == "exploratory":
        return self.rag.search(query)

    if query_type == "live":
        concept = self.okf.lookup_relevant_schema(query)
        return {
            "concept": concept,
            "requires_live_query": True
        }

    return {
        "okf": self.okf.search(query),
        "rag": self.rag.search(query)
    }

Это не классификация производственного уровня, что является приемлемым. Первая цель — лишь выяснить, полезна ли такая сегрегация.

Почему бы просто не использовать BM25 или более совершенные метаданные?

Прежде чем добавлять ещё один механизм, эту идею следует тщательно проверить.

BM25. Для структурированного текста он может оказаться отличным инструментом. Важны точные названия полей, ключевые слова, а детерминистичная система ранжирования способствует лучшим результатам. Для запросов, похожих на схемы, он может превзойти методы эмбеддингов. Однако он не меняет основную архитектуру. Таблица, находящаяся в индексе поиска, всё равно должна быть представлена и извлечена каким-либо образом, и результатом становятся лишь улучшенные фрагменты, которые по-прежнему остаются фрагментами. BM25 улучшает процесс поиска, но не создаёт понятий авторитетности, принадлежности, свежести или канонической семантики.

Дополнительная метаинформация RAG. Это тоже разумно. Могут быть привязаны такие поля, к которым применяется строгая фильтрация:

document_type
owner
version
effective_date
trust_tier
source

Этого может хватить для многих систем. Но как только метаданные становятся механизмом, указывающим агенту, что является авторитетным, актуальным, связанным и безопасным, уже формируется структурированный слой знаний. К тому времени прямое описание концепции выглядит более упорядоченным, чем хранение её в качестве необычного документа, спрятанного в универсальном индексе.

Прямые запросы создают проблему безопасности

Как только ЯИИ получают возможность формировать запросы к операционным системам, риски резко возрастают. Никто этого не хочет:

DROP TABLE shipments;

И это тоже:

SELECT * FROM shipments;

Запуск работы с таблицей, содержащей 50 миллионов строк, из-за любопытства модели. Лучшим решением является не предоставлять агенту доступ к базе данных, а дать ему возможность выполнять ограниченные запросы. Концепция схемы может описывать допустимую структуру запроса:

data_source: analytics.shipments
allowed_columns:
  - shipment_id
  - customer_id
  - carrier_id
  - status
  - promised_delivery_date
  - actual_delivery_date

required_filters:
  - tenant_id

max_result_rows: 1000
access_mode: read_only

Затем сгенерированный запрос проверяется с учётом этой политики:

def validate_query(query, policy):
    checks = [
        uses_allowed_table(query, policy),
        selects_allowed_columns(query, policy),
        contains_required_filters(query, policy),
        respects_row_limit(query, policy),
        is_read_only(query),
    ]

    if not all(checks):
        raise UnsafeQueryError()

    return True

В производственной среде здесь требуются дополнительные меры: отдельные учетные данные для выполнения операций, обеспечение изоляции тенантов вне самой модели, права доступа на уровне базы данных, лимиты на количество строк и затраты, а также логирование каждого выполняемого запроса. Основной принцип заключается в том, что модель предлагает решение, а инфраструктура решает, может ли это решение быть выполнено.

Канонические знания нуждаются в владельце

Единый источник истины звучит замечательно, пока его никто не обновляет. Важнее всего наличие владельца и актуальность информации, чем формат файла. Концепция может включать такие поля:

owner: data-platform@company.io
reviewer: product-analytics@company.io
stale_after: 7 days

Каждый раз, когда изменяется определение метрики, соответствующее обновление знаний должно входить в ту же часть работы. При изменении схемы необходимо либо воссоздать её каноническую форму, либо пересмотреть её. Люди не должны перепечатывать то, что уже известно базе данных, поэтому генерируются факты, известные машине:

for table in database.tables():
  generated = generate_okf_schema(table)
  save(generated)

Люди затем анализируют, что требует оценки: бизнес-смысл, права собственности, конфиденциальные поля, допустимое использование, взаимосвязи и ограничения. Если этого не сделать, единый источник истины превратится в ещё один устаревший репозиторий.

Версионирование важнее, чем кажется

Каноничность не означает вечности. Представьте, что компания изменяет формулу расчёта своевременной доставки с «количества своевременно отправленных заказов делённого на общее количество заказов» на «количество своевременно доставленных заказов делённое на общее количество доставленных заказов». Если старое определение просто заменяется, сотрудник, отвечающий на исторический вопрос, может применить современную логику к отчёту прошлого года. Поэтому концепции нуждаются в версиях или датах вступления в силу:

versions:
  - version: "2.0"
    active: true
    effective_from: 2026-06-10
    change: "Denominator changed to delivered shipments"

  - version: "1.0"
    active: false
    effective_from: 2025-01-01
    effective_to: 2026-06-09

Теперь на два вопроса даются разные ответы. В вопросе о определении OTD используется текущая версия, тогда как в вопросе о том, почему в отчете за первый квартал 2026 года его рассчитали иначе, применяется версия, действовавшая в то время. Термин «канонический» не означает неизменяемый; он означает контролируемый.

Когда RAG и канонические знания расходятся

Рано или поздно агент найдет старый документ, в котором OTD определяется как общее количество своевременно доставленных заказов от общего количества заказов, тогда как каноническое определение подразумевает отношение своевременно доставленных заказов к общему количеству доставленных. Системе требуется четкое правило приоритета, а в случае противоречия — ответ вроде:

if contradiction(okf_context, rag_context):
  log_conflict(…)
  prefer(okf_context)

Он даже может сообщить пользователю: более старый документ противоречит текущему определению метрики, и было использовано текущее, проверенное определение. Таким образом, агент делает нечто большее, чем просто отвечает — он выявляет «долг знаний», что может считаться одним из наиболее ценных побочных эффектов такой конструкции.

Измерение не только окончательного ответа

В данной архитектуре недостаточно отслеживать только уровень галлюцинаций. Необходимо также измерять, как система пришла к ответу, например:

% queries routed to correct source
% canonical lookups with stale concepts
% live queries rejected by policy
% RAG/OKF conflicts detected
% concepts past stale_after
% concepts with no active owne

Неверный окончательный ответ может возникнуть из-за совершенно разных проблем. Модель могла сделать неверные выводы. Маршрутизатор мог выбрать подход RAG там, где требовалось использование канонических знаний. Каноническое понятие могло устареть. Живой запрос мог быть правильным, в то время как определение метрики было неверным. Это разные инженерные проблемы, и возможность наблюдения должна помогать разделять их.

Когда это уже чрезмерная инженерия

Инженерная команда из пяти человек с лишь несколькими внутренними документами, скорее всего, не нуждается в платформе управления знаниями. Если основная задача — нахождение релевантной информации среди тысяч документов, подход RAG может быть достаточным. Если знания редко меняются, механизмы обеспечения актуальности могут оказаться бесполезными. Если сегодня никто не отвечает за документацию, добавление YAML-метаданных не создаст культуры ответственности.

Этот подход становится привлекательным, когда выполняется несколько из следующих условий:

• несколько команд определяют одни и те же концепции
• агенты выполняют операционные действия
• схемы и метрики часто изменяются
• неверные знания стоят бизнесу реальных убытков
• для определений необходимы ответственные лица и запись аудита
• живые данные должны сочетаться с канонической семантикой

Чем больше пунктов применимо, тем выгоднее такое разделение.

Где применим MCP

Когда агенты используют несколько источников знаний и данных, MCP становится естественной точкой интеграции. Агент может иметь доступ к таким возможностям, как:

get_canonical_metric_definition
get_schema
search_historical_documents
query_warehouse
get_runbook

Роутер выбирает подходящий вариант. OKF описывает концепции и ограничения, MCP предоставляет инструменты и ресурсы, живые системы остаются владельцами текущих данных, а RAG продолжает выполнять функцию слоя обнаружения для неструктурированной истории. Эти обязанности лучше сохранять раздельными, если только нет веской причины их объединить.

Разумный первоначальный вариант

Начинать с 300 концепций было бы ошибкой. Лучше использовать десять, а именно десять концепций, по которым уже ведутся дискуссии. Например:

3 metrics
2 schemas
2 SLAs
2 runbooks
1 business rule

Затем измерьте несколько показателей. Может ли агент найти каноническое понятие? Знает ли он, когда это понятие устаревает? Выбирает ли механизм маршрутизации правильный путь? Могут ли запросы выполняться безопасно? Действительно ли люди поддерживают эти понятия? Хорошие результаты оправдывают расширение объема работы, а плохие — прекращение ее. Эксперимент с архитектурой должен иметь возможность провалиться без больших потерь.

Более важный урок

Самым полезным выводом является не новый формат файлов, а то, что корпоративные знания имеют разные формы истинности. Часть из них является авторитетной, часть — исследовательской, а часть отражает текущее состояние, и каждая из этих форм требует собственного способа доступа. Удобная схема соответствий связывает каждый вопрос с определенной формой истинности:

• Официальное определение: канонические знания.
• Релевантная информация: поиск.
• Текущая истина: живой запрос.
• Что должен сделать агент: объединить все вышеперечисленное в рамках установленных правил.

RAG сохраняет свою ценность, векторные базы данных также сохраняют ценность, и OKF тоже может быть ценным инструментом. Архитектурная ошибка заключается в предположении, что один из этих инструментов должен отвечать на все вопросы. Будущее не связано с заменой RAG — оно заключается в понимании того, когда RAG является подходящим инструментом, а когда — нет. Как только агенты начнут принимать реальные действия внутри компаний, выбор источника истины перестает быть вопросом управления знаниями и становится архитектурным решением.

Связанные материалы

• Практические заметки: OKF — это не просто Markdown: мое мнение о портабельных решениях — Подробное руководство по практическим заметкам: OKF — это не просто Markdown: мое мнение о портабельных решениях, включающее контракты, проверки и шаблоны кода для команд, использующих эту модель.

Практические заметки: создание локальной пайплайны RAG производственного уровня — 100% бесплатно — Подробное руководство по практическим заметкам: создание локальной пайплайны RAG производственного уровня — 100% бесплатно: контракты, проверки и готовые блоки кода для команд, внедряющих эту схему.