Poza jedną ścieżką pobierania danych: kanoniczna wiedza, RAG i zapytania w czasie rzeczywistym dla agentów korporacyjnych

Tytuł główny twierdzący, że nowy otwarty format zastępuje bazę danych wektorowych, wzbudza sceptycyzm. Część tej informacji, którą warto zachować, to nie sama historia zastąpienia, lecz bardziej zasadnicze pytanie architektoniczne: czy zbyt wiele różnych rodzajów wiedzy przedsiębiorstwa jest przetwarzanych za pomocą tego samego mechanizmu wyszukiwania?

Wewnątrz firmy „wiedza” obejmuje bardzo różne rzeczy. Liczy się ticket obsługi klienta. Również 60-stronicowy dokument projektowy, schemat bazy danych, definicja metryki czy podręcznik postępowania w przypadku incydentów. Liczy się również obecna liczba opóźnionych dostaw. Te elementy zachowują się inaczej, więc dziwne jest, że agent AI miałby do nich dotrzeć w ten sam sposób.

Przydatne ujęcie nie polega na konfrontacji OKF z RAG, ani też nie oznacza, że bazy danych wektorowych przestały istnieć. Chodzi o praktyczną klasyfikację w trzy kategorie: wiedzę do odzyskiwania, wiedzę do przechowywania jako standardową oraz wiedzę do bieżących zapytań.

Zwykły problem przedsiębiorstwa

Wyobraźmy sobie fikcyjną firmę SaaS zajmującą się logistyką, zatrudniającą około 120 inżynierów. Podobnie jak wiele firm eksperymentujących z agentami, połączyła ona wewnętrzne dokumenty, procesy obsługi klienta, systemy operacyjne, wskaźniki oraz instrukcje z platformą agentów. W przypadku większości pytań to rozwiązanie działa dobrze.

Następnie ktoś pyta o wskaźnik terminowej dostawy, a system pokazuje trzy różne definicje:

• Zespół ds. danych liczy przesyłki, które przybywają w wyznaczonym terminie.
• Panel sterowania produktu stosuje nieco inny sposób obliczeń.
• Dokumentacja skierowana do klientów pomija zamówienia anulowane oraz zwroty.

Żadne z tych rozwiązań nie jest bezsensowne. Różne zespoły stworzyły je z różnych powodów. Problemy pojawiają się, gdy agent musi zdecydować, które z nich ma autorytet. Baza danych wektorowych może wskazać to, co jest semantycznie bliskie, ale nie ma sposobu, by dowiedzieć się, która wersja została uznana przez firmę za oficjalną definicję. To jest odrębny problem.

Relevancja to nie autorytet

Standardowy proces RAG zwraca wszystkie dokumenty, które pasują. Jeśli trzy dokumenty opisują jedną miarę na trzy różne sposoby, wszystkie trzy trafiają do wyników. Lepsze sortowanie, dodatkowe metadane, ponowne sortowanie, większa wartość top_k lub szersze okno kontekstowe mogą pomóc. Żadne z tych rozwiązań nie odpowiada na pytanie organizacyjne dotyczące tego, która definicja jest oficjalna.

Zatem prawdziwą słabością nie jest po prostu to, że RAG tworzy iluzje. Relevancja i autorytet to różne właściwości, a agenci korporacyjni coraz częściej potrzebują obu.

Gdy struktura jest znaczeniem

Kolejnym powodem, dla którego nie cała wiedza pasuje do jednego procesu wydobywania informacji, jest forma. Weźmy tabelę z dziesięcioma wierszami i siedmioma kolumnami. Jej znaczenie nie polega wyłącznie na samych słowach – pochodzi z relacji między nagłówkami, etykietami wierszy, wartościami, jednostkami oraz otaczającym kontekstem.

Gdy podzielimy tę tabelę na fragmenty po 256 tokenów, jeden z nich może zawierać tylko parę nagłówków, na przykład region i przychody, podczas gdy inny – wartości East 2.1M i West 1.8M. Model może poprawnie odtworzyć te relacje, a może też tego nie zrobić.

W przypadku prozy zazwyczaj właśnie takie dzielenie jest pożądane. Natomiast przy strukturyzowanej wiedzy staje się to dziwnym objazdem:

1. zacznij od struktury
2. przekształć ją w tekst
3. podziel tekst na fragmenty
4. wbuduj te fragmenty
5. wydobyj kilka z nich
6. poproś model o odtworzenie oryginalnej struktury

W pewnym momencie pojawia się pytanie, czy w ogóle należało to fragmentować. To samo dotyczy schematów bazy danych, ścieżek łączenia, zasad konfiguracji, wzorów na metryki, SLA oraz procedur operacyjnych. Strukturyzowana treść nie jest zabroniona w RAG. Chodzi o to, że struktura wymaga specjalnego traktowania, gdy jej utrata zmienia znaczenie.

Baza danych wektorowych nigdy nie była źródłem prawdy

Fikcyjna firma miała kolejny powszechny problem: wiedza była rozproszona. Schematy były opisane w komentarzach do bazy danych, wikach GitHuba, Confluence oraz plikach migracyjnych. Definicje metryk znajdowały się na panelach analitycznych, w specyfikacjach produktów, dokumentach zespołu danych oraz starych prezentacjach. Instrukcje operacyjne były rozproszone w Notion, ticketach incydentowych, Slacku i GitHubie. Część logiki łączenia znajdowała się głównie w umyśle osoby, która najdłużej pracowała nad projektem.

Budowa bazy danych wektorowej na tej podstawie nie stworzyła źródła prawdy. Stworzyła natomiast indeks umożliwiający wyszukiwanie istniejących niespójności. Ma to swoją wartość, ale nie stanowi mechanizmu zarządzania.

Co dodaje OKF

To, co wyróżnia format Open Knowledge Format, to nie Markdown, który już istnieje. Chodzi o koncepcję uczynienia wiedzy przedsiębiorstwa wyraźnie czytelną dla maszyn, jednocześnie zachowując jej przyjazność dla ludzi. W zasadzie plik koncepcyjny zaczyna się od ustrukturyzowanych metadanych:

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

i kontynuuje wyjaśnieniem napisanym dla ludzi:

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

Agent nie otrzymuje już tylko tekstu dotyczącego terminowej dostawy. Może również dowiedzieć się, kto jest właścicielem danej definicji, czy jest aktualna, czy została zweryfikowana, od czego zależy oraz jakie inne koncepcje są z nią powiązane. Pytanie zmienia się z tego, który fragment wygląda najbardziej podobnie do której koncepcji, na to, która jest kanoniczna i czy można ją bezpiecznie używać.

OKF nie zastępuje RAG

Tutaj wniosek odbiega od nagłówka. Dokładniejszy obraz przedstawia się jako proces ewolucyjny: wiedza kanoniczna znajduje się w OKF, wiedza eksploracyjna w RAG, a aktualny stan w systemach online.

Wiedza kanoniczna obejmuje schematy baz danych, definicje metryk, SLA, zasady biznesowe, instrukcje obsługi oraz informacje o właścicielach. Zwykle zadawane jest pytanie o to, jaka jest oficjalna, aktualna definicja.

Wiedza eksploracyjna obejmuje raporty historyczne, historię incydentów, rozmowy z obsługą klienta, dokumenty projektowe, studia przypadków oraz opinie klientów. Pytanie brzmi: jakie informacje są istotne w kontekście tego, czego się szuka? Właśnie w tym obszarze RAG sprawdza się najlepiej.

Stan aktualny obejmuje dzisiejszy wskaźnik terminowości, bieżący saldę klienta, aktywne incydenty, otwarte zamówienia oraz poziom zapasów. Pytanie brzmi: co jest prawdą w tym momencie? W takim przypadku indeks wektorowy prawdopodobnie nie jest odpowiednim narzędziem do znalezienia odpowiedzi. System operacyjny, który posiada te dane, powinien je dostarczyć.

Część danych nie powinna być wyświetlana

Tutaj architektura staje się ciekawsza. Załóżmy, że użytkownik prosi o pięciu największych klientów pod względem przychodów w tym kwartale. Jeden z projektów pobiera dokumenty i dane do indeksu i pozwala modelowi je posortować. To jest możliwe, ale istnieje lepszy sposób: agent sprawdza kanoniczne znaczenie pojęcia „przychód”, tworzy zapytanie i wykonuje je w systemie przechowywania danych. Na przykład:

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;

Agent otrzymuje teraz dwie rzeczy z dwóch źródeł. Znaczenie pochodzi z warstwy wiedzy kanonicznej, a aktualne wartości – z systemu, który faktycznie posiada dane. Agent już nie pobiera danych; najpierw pobiera strukturę, a następnie wysyła zapytanie do systemu w czasie rzeczywistym.

Jeden agent, trzy ścieżki wiedzy

Biorąc pod uwagę tę różnicę, niektóre przykładowe pytania są kierowane w inny sposób:

• Co oznacza terminowa dostawa? Skonsultuj się z definicją metryki kanonicznej.
• Jaki jest dzisiejszy wskaźnik terminowości? Użyj logiki obliczeniowej z definicji kanonicznej, a następnie zapytaj system magazynowy w czasie rzeczywistym.
• Dlaczego wskaźnik spadł w zeszłym kwartale? Połącz definicję kanoniczną z historycznymi danymi magazynowymi, a także, jeśli to możliwe, z informacjami z raportów o incydentach i notatkach przewoźników.

Co się stało z Klientem X w I kwartale? Przeprowadź wyszukiwanie wśród wcześniejszych zgłoszeń, notatek i raportów.

Wystąpiła awaria bazy danych, co teraz? Skorzystaj z kanonicznego podręcznika postępowania.

Agent jest ten sam, ale ścieżki się różnią. To temat bardziej przydatny do omówienia niż kwestia zastępowania baz danych wektorowych.

Router przenosi się do centrum

Gdy istnieje kilka ścieżek wiedzy, coś musi wybrać spośród nich. Pierwszy router może być celowo prosty.

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"

Jego metoda context działa w następujący sposób:

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)
    }

To nie jest klasyfikacja na poziomie produkcyjnym, co jest do przyjęcia. Pierwszym celem jest jedynie ustalenie, czy to rozdzielenie jest przydatne.

Dlaczego nie po prostu BM25 lub lepsze metadane?

Zanim dodamy kolejny mechanizm, ta idea wymaga odpowiedniego sprawdzenia.

BM25. W przypadku tekstów strukturalnych może być doskonały. Istotne są dokładne nazwy pól, słowa kluczowe, a pomocne jest deterministyczne rankowanie. W zapytaniach typu schema może przewyższać metody embeddingów. Jednak nie zmienia podstawowej architektury. Tabela umieszczona w indeksie wyszukiwania musi nadal być w jakiś sposób reprezentowana i odzyskiwana, a rezultatem są lepsze fragmenty, które wciąż pozostają fragmentami. BM25 poprawia proces odzyskiwania informacji. Nie tworzy jednak pojęć takich jak autorytet, własność, świeżość czy semantyka kanoniczna.

To również jest rozsądne. Można dołączyć takie pola jak poniżej, z dodatkowym intensywnym filtrowaniem:

document_type
owner
version
effective_date
trust_tier
source

To może wystarczyć dla wielu systemów. Ale gdy metadane stają się mechanizmem wskazującym agentowi, co jest autorytatywne, aktualne, powiązane i bezpieczne, budowana jest już strukturyzowana warstwa wiedzy. W tym momencie jasne sformułowanie koncepcji jest prostsze niż przechowywanie jej jako dziwnego dokumentu pogrzebanego w ogólnego typu indeksie.

Zapytania w czasie rzeczywistym wprowadzają problem bezpieczeństwa

W momencie, gdy LLM otrzymuje możliwość tworzenia zapytań do systemów operacyjnych, ryzyko gwałtownie rośnie. Nikt tego nie chce:

DROP TABLE shipments;

Ani to:

SELECT * FROM shipments;

Uruchomienie zapytania przeciwko tabeli zawierającej 50 milionów wierszy wynika z ciekawości modelu. Lepszym rozwiązaniem jest nie udzielanie agentowi dostępu do bazy danych, lecz zapewnienie mu ograniczonych możliwości wysyłania zapytań. Koncepcja schematu może opisać dozwolony format zapytania:

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

Wygenerowana zapytanie jest następnie weryfikowana pod kątem tej polityki:

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

W środowisku produkcyjnym należy tu uwzględnić dodatkowe kroki: oddzielne uprawnienia do wykonywania zadań, izolację użytkowników realizowaną poza modelem, uprawnienia na poziomie bazy danych, limity liczby wierszy i kosztów, a także rejestrację każdego wykonywanego zapytania. Podstawową zasadą jest to, że model proponuje działanie, a infrastruktura decyduje, czy ta propozycja może zostać zrealizowana.

Kanoniczna wiedza wymaga właściciela

Jedyny źródło prawdy brzmi wspaniale, dopóki nikt go nie aktualizuje. Właściciel i aktualność są ważniejsze niż format pliku. Koncepcja może zawierać takie pola:

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

Każdy raz, gdy edytowana jest definicja metryki, odpowiadająca aktualizacja wiedzy powinna znajdować się w tym samym dokumencie. Gdy zmienia się schemat, należy ponownie wygenerować lub przejrzeć jego kanoniczną formę. Ludzie nie powinni wpisywać ponownie tego, co baza danych już zna, dlatego generowane są fakty znane maszynie:

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

Ludzie następnie sprawdzają, co wymaga oceny: znaczenie biznesowe, własność, kolumny wrażliwe, dozwolone zastosowania, relacje oraz zastrzeżenia. Jeśli to pominąć, jedyny źródło prawdy zamienia się w kolejny zbiór danych, który stał się przestarzały.

Wersjonowanie jest ważniejsze, niż się wydaje

Kanoniczność nie oznacza wieczności. Wyobraźmy sobie, że firma zmienia definicję terminowej dostawy z liczby dostaw terminowych podzielonej przez łączną liczbę zamówień na liczbę dostaw terminowych podzieloną przez łączną liczbę dostarczonych towarów. Jeśli stara definicja zostanie po prostu nadpisana, pracownik odpowiadający na pytanie historyczne może zastosować dzisiejszą logikę do raportu z zeszłego roku. Dlatego koncepcje wymagają wersji lub dat wejścia w życie:

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

Dwie różne pytania wymagają teraz różnych odpowiedzi. Pytanie dotyczące definicji OTD odnosi się do aktualnej wersji, natomiast pytanie o to, dlaczego raport za I kwartał 2026 roku obliczył je inaczej, odnosi się do wersji obowiązującej w tym czasie. „Kanoniczny” nie oznacza niezmienny – oznacza kontrolowany.

Kiedy RAG i wiedza kanoniczna się różnią

Prędzej czy później agent pobraje stary dokument, w którym OTD określany jest jako całkowita liczba dostaw na czas w stosunku do całkowitej liczby zamówień, podczas gdy koncepcja kanoniczna mówi o dostawach na czas w stosunku do całkowitej liczby dostaw. System potrzebuje wyraźnej zasady hierarchii, a w przypadku sprzeczności odpowiedzi takiej jak:

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

Może nawet poinformować użytkownika, że starszy dokument koliduje z obecną definicją miary, a zastosowano aktualną, zweryfikowaną definicję. W ten sposób agent robi coś więcej niż tylko odpowiada – ujawnia braki w wiedzy, co może być jednym z najcenniejszych efektów ubocznych tego projektu.

Mierzenie czegoś więcej niż tylko ostatecznej odpowiedzi

W tej architekturze niewystarczające jest śledzenie jedynie wskaźnika halucynacji. Należy również mierzyć, w jaki sposób system doszedł do odpowiedzi, na przykład:

% 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

Błędna ostateczna odpowiedź może wynikać z zupełnie różnych problemów. Model mógł błędnie wyciągnąć wnioski. Router mógł wybrać rozwiązanie RAG tam, gdzie potrzebna była kanoniczna wiedza. Kanoniczny koncept mógł być przestarzały. Zapytanie może być poprawne, podczas gdy definicja metryki jest błędna. To są różne problemy inżynieryjne, a możliwość obserwacji powinna pomagać w ich rozróżnianiu.

Kiedy to jest nadmiernym projektowaniem

Zespół inżynieryjny składający się z pięciu osób, posiadający jedynie kilka wewnętrznych dokumentów, najprawdopodobniej nie potrzebuje platformy do zarządzania wiedzą. Jeśli głównym zadaniem jest znajdowanie istotnych informacji wśród tysięcy dokumentów, rozwiązanie RAG może wystarczyć. Jeśli wiedza rzadko się zmienia, mechanizmy sprawdzania aktualności mogą nie przynieść efektów. Jeśli nikt obecnie nie jest odpowiedzialny za dokumentację, dodanie elementów YAML nie stworzy kultury odpowiedzialności.

Ten model staje się atrakcyjny, gdy zachodzi kilka z tych warunków:

• kilka zespołów definiuje te same koncepcje
• agenci wykonują działania operacyjne
• schematy i metryki są często modyfikowane
• błędne informacje kosztują firmę rzeczywiste straty
• definicje wymagają odpowiedzialnych osób oraz śledzenia zmian
• dania w czasie rzeczywistym muszą być powiązane z kanoniczną semantyką

Im więcej z tych punktów dotyczy danej sytuacji, tym większe są korzyści z takiego podziału.

Gdzie pasuje MCP

Gdy agenci korzystają z kilku źródeł wiedzy i danych, MCP staje się naturalnym punktem integracji. Agent może mieć dostęp do takich funkcji jak:

get_canonical_metric_definition
get_schema
search_historical_documents
query_warehouse
get_runbook

Router wybiera odpowiednią opcję. OKF opisuje koncepcje i ograniczenia, MCP udostępnia narzędzia i zasoby, systemy w czasie rzeczywistym pozostają właścicielami aktualnych danych, a RAG funkcjonuje jako warstwa odkrywania niestrukturyzowanych danych historycznych. Te obowiązki najlepiej trzymać oddzielnie, chyba że istnieje mocny powód, by je połączyć.

Rozsądna pierwsza wersja

Początek od 300 koncepcji byłby błędem. Lepiej jest zacząć od dziesięciu, konkretnie od dziesięciu koncepcji, o których ludzie już się kłócą. Na przykład:

3 metrics
2 schemas
2 SLAs
2 runbooks
1 business rule

Następnie zmierz kilka rzeczy. Czy agent potrafi znaleźć koncepcję kanoniczną? Czy wie, kiedy ta koncepcja jest przestarzała? Czy routowanie wybiera właściwą ścieżkę? Czy zapytania w czasie rzeczywistym mogą być wykonywane bezpiecznie? Czy ludzie faktycznie aktualizują te koncepcje? Dobre wyniki uzasadniają rozszerzenie zakresu, a słabe – przerwanie pracy. Eksperyment architektoniczny powinien móc się nie powieść bez dużych strat.

Ważniejsza lekcja

Najbardziej przydatną wnioskiem nie jest nowy format pliku, lecz to, że wiedza przedsiębiorstwa ma różne formy prawdy. Część z nich ma charakter autorytatywny, część jest eksploracyjna, a część odzwierciedla aktualny stan rzeczy, przy czym każda z tych form wymaga swojego wzorca dostępu. Praktyczne mapowanie łączy każde pytanie z odpowiednią formą prawdy:

• Oficjalna definicja: wiedza kanoniczna.
• Relevantne informacje: wyszukiwanie.
• Obecna prawda: zapytanie w czasie rzeczywistym.
• To, co agent powinien zrobić: połączyć wszystko powyższe zgodnie z ustalonymi zasadami.

RAG pozostaje cenny, bazy danych wektorowych również są cenne, a OKF też może być wartościowy. Błędem architektonicznym jest założenie, że któryś z nich powinien odpowiadać na każde pytanie. Przyszłość nie polega na zastępowaniu RAG. Chodzi o to, by wiedzieć, kiedy RAG jest odpowiednim narzędziem, a kiedy nie. Gdy agenci podejmą rzeczywiste działania w firmach, wybór źródła prawdy przestaje być kwestią zarządzania wiedzą i staje się decyzją architektoniczną.