Поза межами одного шляху отримання даних: канонічні знання, RAG та живі запити для корпоративних агентів

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

Усередині компанії „знання“ охоплює дуже різні речі. Рахується заява на підтримку. Так само, як і 60-сторінковий документ з проектуванням, схема бази даних, визначення показника чи посібник з реагування на інциденти. Рахується також кількість затриманих відправлень. Ці елементи поводяться по-різному, тож дивно, що штучний інтелект має можливість охопити їх усі однаковим способом.

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

Звичайна корпоративна проблема

Уявіть вигадану компанію з послуги логістики типу SaaS із приблизно 120 інженерами. Як і багато фірм, які експериментують з агентами, вона під’єднала внутрішні документи, процеси підтримки, операційні системи, показники та інструкції до платформи агентів. Для більшості запитань це працює добре.

Потім хтось запитує про рівень своєчасної доставки, і система знаходить три визначення цього показника:

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

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

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

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

Отже, справжня слабкість полягає не просто у тому, що RAG створює хибні дані. Релевантність та авторитет — це різні властивості, і корпоративним агентам все більше потрібні обидві.

Коли структура є значенням

Ще одна причина, чому не всі знання підходять до одного механізму пошуку, — це форма. Візьмімо таблицю з десятьма рядками та сімома стовпцями. Її сенс полягає не лише у словах, а й у тому, як заголовки, позначення рядків, значення, одиниці вимірювання та навколишній контекст взаємодіють між собою.

Якщо розділити цю таблицю на частини по 256 токенів, одна з фрагментів може містити лише пару заголовків, наприклад «регіон» та «дохід», тоді як інший — «Схід 2,1 млн» та «Захід 1,8 млн». Модель може правильно відтворити ці зв’язки, а може й ні.

Для прози зазвичай саме це й потрібно — розділення на частини. Однак для структурованих знань це стає дивним обхідним шляхом:

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

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

База даних типу векторів ніколи не була джерелом істини

У вигаданої компанії існувала ще одна поширена проблема: знання були розсіяні. Схеми описувалися у коментарях до баз даних, wiki на 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"

Його метод context дотримується наступного:

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 використовує поточну версію, тоді як запитання про те, чому у звіті за 1-й квартал 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% безкоштовно: контракти, перевірки та готові фрагменти коду для команд, які впроваджують цю схему.