Open Knowledge Format: stratul de cunoaștere dintre date și agenții AI

Un agent AI poate avea acces la data warehouse, fișiere, ERP și CRM și totuși să nu înțeleagă corect datele companiei. Ce înseamnă exact client activ? Din ce tabele se calculează venitul net? Când poate fi recomandat un discount? Ce excepții contractuale există în afara sistemelor? (Articol actualizat pentru OKF v0.2 - 27 iulie 2026)

„Cunoașterea internă a companiei" este un termen foarte general, dar suficient de flexibil pentru a acoperi această distanță enormă între funcționare în principiu și funcționare în producție.

Open Knowledge Format (OKF) este o specificație deschisă publicată de Google Cloud pentru organizarea metadatelor, contextului și cunoașterii utilizate de oameni și agenți AI. Pe 12 iunie 2026, s-a lansat versiunea 0.1. La numai șase săptămâni, pe 25 iulie s-a lansat versiunea 0.2, care întărește guvernanța formatului (din ce surse provine, cine l-a generat și verificat, dacă este încă actual), deși v0.1 rămâne validă.

Formatul OKF este simplu, definit de patru caracteristici, conform specificațiilor Google: Lizibilitate pentru oameni, accesibilitate pentru agenți AI fără unelte software speciale, versionabilitate pentru păstrarea unui istoric și portabilitate între sisteme IT.

Cum vom vedea, și componentele efective sunt extrem de simple: fișiere .MD cu headere YAML. Le explorăm pe acestea, apoi evaluăm locul OKF între instrumentele ecosistemului agentic și câteva proiecte care deja folosesc OKF.

Concluzia noastră va fi că OKF nu este suficient singur, pentru o arhitectură agentică sunt necesare patru straturi:

1. Date operaționale - în diferite sisteme
2. OKF - pentru înțelegerea datelor și a convențiilor interne
3. Skills - proceduri sau workflows pentru acțiunile efective AI
4. Reguli de securitate și actualitate - verifică dacă acțiunile sunt permise și informațiile folosite de AI sunt încă valabile

1. Ce este și cum funcționează Open Knowledge Format (OKF)?

1.1. Bundle-ul și documentul-concept

Unitatea de bază a OKF este un document-concept: fișier Markdown cu metadate YAML. Mai multe concepte organizate într-un director formează un Knowledge Bundle.

sales-knowledge/
├── index.md
├── log.md
├── metrics/
│   ├── index.md
│   ├── gross-margin.md
│   └── customer-value.md
├── policies/
│   ├── index.md
│   ├── discount-policy.md
│   └── overdue-invoices.md
├── products/
│   ├── index.md
│   ├── product-families.md
│   └── aliases.md
└── references/
    ├── policy-sales-3-2.md
    └── fin-07.md

Specificația OKF impune foarte puține reguli. Singurul câmp obligatoriu pentru un concept este type, de exemplu Table pentru un tabel de date. Câmpuri precum title, description, resource, tags și generated.at (în 0.1 timestamp) sunt recomandate. În plus, poți adăuga propriile metadate, iar consumatorii (printre care agenții AI) trebuie să tolereze câmpurile pe care nu le recunosc.

Asta înseamnă că implementările vor evolua diferit în contexte diferite. Și, mai mult, că două bundle-uri OKF vor avea niveluri radical diferite de detalii. Unul ar putea avea surse, responsabili (owners), aprobări, date de revizuire și sute de detalii. Altul poate conține doar un câmp type și câteva paragrafe generate și ele automat cu AI.

1.2. Relațiile sunt esențiale, dar OKF nu este un knowledge graph complet

Dincolo de headerul YAML din fiecare document, organizarea pe foldere este esențială alături de relațiile dintre concepte care sunt exprimate prin linkuri Markdown obișnuite.

„Un discount mai mare de 10% trebuie verificat conform [politicii de discount](/policies/discount-policy.md)."

Din aceste linkuri se poate construi o reprezentare de tip graph. Dar OKF nu specifică validare avansată, nefiind un knowledge graph semantic complet cu relații tipizate formal. În OKF, sensul relației (de exemplu unidirecțional) este exprimat doar prin textul care descrie linkul, fără vreo ontologie obligatorie sau un limbaj de parcurgere sau validare.

Este deci probabil ca în viitor să apară unelte de generare OKF și extinderi mai stricte ale formatului care să verifice și valideze, inclusiv linkurile rupte (en. dead links).

Trei scenarii de generare OKF

• Redactare manuală de la 0: mentenanța devine costisitoare, trebuie să aveți grijă ca noile linkuri sau concepte să fie legate corect cu cele vechi
• Generare semi-automată din documentația existentă: urmează validări sintactice (linting) și verificare umană obligatorie
• Export cvasi-automat: doar dacă folosiți o platformă mai puternică legată la sursele de adevăr, cu tooling suplimentar pentru OKF

1.3. Progressive disclosure: agentul AI nu citește tot

Fișierul index.md (din rădăcină, recomandat) va funcționa ca hartă locală a cunoașterii organizaționale capturate de bundle, împreună cu alte index.md din subfoldere.

Agentul poate începe citirea cu indexul principal. Astfel identifică domeniul relevant și apoi încarcă (sperăm) doar conceptele necesare. Dacă o politică trimite la o excepție sau la o formulă financiară, agentul sau consumatorul poate citi detaliile din linkul respectiv.

Această abordare se numește progressive disclosure, având rolul de a reduce contextul necesar și costurile aferente. Ceva asemănător se găsește în Agent Skills (de la Claude): agentul descoperă mai întâi numele și descrierea Skill-ului, apoi încarcă instrucțiunile și resursele precise pe măsură ce are nevoie de ele. O ierarhie de citire OKF arată așa:

index.md
├── metrics/index.md
│   └── [alte documente .md din director]
├── policies/index.md
│   └── [alte documente .md din director]
└── products/index.md
    └── [alte documente .md din director]

1.4. Knowledge as code

O bază de cunoaștere OKF poate fi administrată în Git la fel ca orice proiect software. Se propune o modificare, se publică într-un branch, se poate folosi diff, se poate face review de owner și apoi se publică final și reindexează în producție.

Avantajul este că în lumea AI, apare transparență pentru procedurile și definițiile interne, față de alte proceduri „magice". Știm că în multe proiecte RAG, documentele sunt reindexate, dar nu există un proces transparent care să rețină cine a modificat o regulă și când, ce texte au fost înlocuite și de ce s-a făcut schimbarea. Ca versionabilitate, OKF este similar cu Agent Skills (vezi mai jos).

Riscul este că dacă bundle-urile OKF cresc ca dimensiuni și includ cazuri concrete și excepții punctuale (de exemplu „pentru clientul ALBIN IMPEX aplică mereu discount 4.5%"), versionabilitatea nu va ajuta, efectele practice (de exemplu discounturi acordate greșit) nefiind reversibile.

2. OKF versus RAG/GraphRAG, MCP și Agent Skills

Conceptele din ecosistemul agentic sunt frecvent prezentate ca alternative directe. În realitate, ele operează la straturi diferite și OKF va avea propriul loc.

OKF versus RAG și GraphRAG

RAG răspunde în principal la întrebarea: cum găsește AI informația relevantă? OKF va răspunde la întrebarea: cum este organizată cunoașterea pe care agentul trebuie să o găsească?

Un bundle OKF poate fi indexat într-o bază vectorială. Retrieval-ul (RAG) poate combina embeddings, keyword search, BM25, reranking, graph expansion și navigarea prin indexuri. GraphRAG folosește relațiile dintre entități și concepte pentru a recupera context care nu poate fi găsit prin simpla similaritate între fragmente. OKF poate furniza conceptele curățate, dar nu impune un algoritm și nu necesită o bază de date graph.

OKF poate fi o sursă pentru GraphRAG, dar nu este un motor complet de graph.

OKF versus MCP

Model Context Protocol și protocoalele similare facilitează conectarea agenților la instrumente și sisteme externe. Un server MCP permite agentului AI să interogheze baza de date, să citească stocul din ERP sau chiar să creeze un tichet în CRM.

OKF explică agentului conceptele companiei: care pipeline este oficial, ce stoc este eligibil sau ce reguli trebuie aplicate înaintea unei acțiuni.

„Returnează soldul curent al clientului."

„Soldul influențează politica aplicabilă clienților cu restanțe."

MCP oferă acces la date și acțiuni, în timp ce OKF oferă context conceptual persistent.

OKF versus Claude Agent Skills

Comparația cu Agent Skills este importantă deoarece ambele formate folosesc directoare, Markdown, YAML și progressive disclosure. Un Skill conține în mod normal un fișier SKILL.md cu numele Skill-ului, descrierea situațiilor în care trebuie activat și instrucțiunile pentru realizarea unei activități. Directorul poate include scripturi, referințe, template-uri și alte resurse.

Specificația a apărut în ecosistemul Anthropic, dar acum Skills este un format deschis și a fost adoptat în AI agentic.

Diferența fundamentală este între cunoaștere (OKF) și procedură (Skill):

Varianta nouă OKF v0.2 face granița puțin mai flexibilă prin conceptul de Attested Computation. Un document-concept poate preciza cum trebuie calculată o valoare, de ce executor și cum se verifică execuția, inclusiv runtime, deși nu îl execută efectiv. Noi recomandăm pe moment ca runtime-ul să rămână la Skills sau alte instrumente.

Pentru toate: reguli de securitate și conformitate (guardrails)

Fiind vorba de AI generativ, la fiecare pas (extragere date, citire cunoaștere OKF, adoptare procedură din Skill / conexiuni MCP) trebuie să existe un strat de guardrails (reguli) cu permisiuni și access management (IAM) care să verifice că AI nu poate face acțiuni dăunătoare companiei.

Recapitulând, rezultă tabelul următor:

3. OKF v0.2: cum construim un knowledge bundle verificabil

Problema de la care pleca OKF este că accesul la date nu garantează înțelegerea sensului lor pentru companie. OKF vine peste date ca strat intermediar: sintetizată informația în concepte curate (în plus interconectate și versionate), înainte de a fi folosită de agenți AI.

---
type: Metric
title: Marjă comercială
description: Definiția aprobată a marjei comerciale utilizate în ofertele B2B.
resource: erp://metrics/commercial-margin
tags: [sales, finance, pricing]

sources:
  - id: policy-sales-3-2
    resource: /references/policy-sales-3-2.md
    title: Politica comercială aprobată, versiunea 3.2

  - id: fin-07
    resource: /references/fin-07.md
    title: Procedura financiară FIN-07

generated:
  by: human:name-editor
  at: 2026-07-27T10:00:00Z

verified:
  by: human:sales-director
  at: 2026-07-27T12:00:00Z

status: stable
stale_after: 2026-09-30
---

# Definiție

Marja comercială este calculată ca diferența dintre prețul net de
vânzare și costul eligibil al produsului, raportată la prețul net.[^policy-sales-3-2]

# Excepții

Pentru produsele aflate în lichidare se utilizează costul mediu ponderat.[^fin-07]

# Relații

Vezi [politica de discount](/policies/discount-policy.md).

[^policy-sales-3-2]: Politica comercială aprobată, versiunea 3.2
[^fin-07]: Procedura financiară FIN-07

Acest fișier poate fi modificat de management și apoi citit de angajați și procesat de agenți AI. Dar OKF în sine nu garantează verificări, nici de coerență („nu există referințe lipsă"), nici factice („nu conține informație expirată").

Pentru guvernanță Google adaugă noi câmpuri în v0.2:

Recomandăm folosirea noilor câmpuri în toate documentele-concept.

3.1. Tratează explicit necunoscutul

Orice bază de cunoaștere vie (en. living wiki) e mai valoroasă dacă include explicit traseul de verificare. Poți folosi un câmp custom care să descrie acest traseu:

status: draft
missing_information:
  - delivery restriction for refrigerated products

În v0.2, câmpul verified se adaugă numai după confirmarea informației, absența sa indică un concept neverificat iar status: draft indică faptul că documentul nu este încă stabil.

În special în domenii sensibile sau reglementate ca software medical sau aspecte de securitate, necunoscutul trebuie să fie o stare validă a sistemului.

3.2. Definește precedența regulilor și fii explicit

În domeniul vânzărilor cu AI, să presupunem că există o politică generală cu discount 10%, o regulă pentru clienți strategici de 15% și un contract individual de 12%. Agentul are nevoie de o ierarhie explicită: contract individual, excepție aprobată, politică specifică, politică generală a companiei.

OKF permite documentarea acestei ierarhii prin câmpuri opționale, de unde importanța acestora. În mod similar, trebuie să fii cât mai explicit pentru a conduce agenții AI:

description: Informații despre discounturi.

description: Praguri maxime de discount și niveluri de aprobare,
în funcție de grupă de produse, segment de client și rol comercial.

aliases:
  - seringă galbenă
  - yellow syringe
  - PX747

3.3. Precizează responsabilul, politica de revizuire și pregătește un flux de aprobare

Un concept e bine să aibă un responsabil (owner) și o sursă autoritativă.

owner: sales-operations
source_of_truth: erp-policy-service

verified:
  by: human:sales-director
  at: 2026-07-27T12:00:00Z

status: stable
stale_after: 2026-09-30

Câmpurile verified, status și stale_after sunt câmpuri specificate de v0.2. Câmpurile owner și source_of_truth sunt extensii custom permise de format. Într-un mediu enterprise pot fi adăugate și alte câmpuri custom ca valid_from, valid_until, sensitivity, sau language.

Pentru bundle-uri OKF semi-automatizate dar care ating logica centrală a companiei, fluxul de aprobare este esențial.

Aveți definiții și proceduri pe care agenții AI trebuie să le interpreteze unitar? Discutați cu experții OPTI

4. Ce arată primele implementări publice

Google a prezentat de la început OKF drept o specificație în evoluție. Primele implementări publice arată atât direcțiile posibile, cât și dificultățile practice ale formatului.

4.1. Google Cloud: BigQuery și Knowledge Catalog

Google a publicat imediat după specificația OKF:

• bundle-uri demonstrative OKF și un vizualizator static
• agent de enrichment pentru BigQuery
• Folosirea informațiilor OKF în Google Cloud Knowledge Catalog.

În cazul BigQuery, un proces automat analizează schema de date și creează documente pentru tabele și views, care pot fi completate cu explicații, relații, exemple de interogări. Acesta este primul exemplu de tooling pentru generare OKF.

4.2. OpenKB: Knowledge Compilation (compilarea cunoașterii)

Proiectul open-source OpenKB transformă PDF-uri, fișiere Office, pagini web și alte surse într-un wiki interconectat compatibil cu OKF.

Conceptul central este knowledge compilation. În loc să păstreze fiecare document complet separat la adăugare, sistemul încearcă să identifice automat celelalte concepte afectate și să actualizeze documentele din bundle.

Document nou
     │
     ▼
Identificarea conceptelor din el
     │
     ▼
Compararea cu informația existentă
     │
     ▼
Actualizarea altor documente și a relațiilor
     │
     ▼
Knowledge base consolidat

Riscul este că dacă procesul automat interpretează greșit o sursă, eroarea nu rămâne într-un singur loc. De aceea, knowledge compilation trebuie supus unui flux de aprobare strict, cum am recomandat mai sus.

4.3. Import review-first

Proiectul llm-wiki-compiler experimentează cu import și export OKF, validarea linkurilor, evaluarea conținutului și retrieval hibrid pentru crearea unui wiki clasic folosit de LLM-uri.

Ideea cea mai atractivă este importul review-first: un bundle primit din exterior nu devine automat adevăr organizațional adoptat. Este introdus într-o zonă de staging, după o validare sintactică și trebuie aprobat pentru a fi considerat knowledge base activ. La fel cum un fișier CSV valid nu conține neapărat date corecte, un bundle OKF valid nu conține neapărat cunoaștere adevărată.

4.4. Abode 101: surse și necunoscut explicit

Un exemplu punctual, dar de viitor, este Abode 101, o bază de cunoaștere pentru administrarea unei locuințe (casă): echipamente, manuale, instalații, lucrări de mentenanță.

Proiectul este interesant pentru că adaugă două reguli opționale pentru OKF:

• fiecare fapt trebuie să aibă o sursă și un nivel de încredere declarat
• dacă informația nu este documentată, agentul este instructat să spună că nu știe.

Dacă acesta este standardul pentru casa personală, și în business se vor aplica standarde similare. Întrebarea „Ce baterie folosește senzorul?" devine, în vânzări, „Care este codul ERP al produsului cerut informal de client?". În domeniul financiar poate deveni „Care este formula oficială a venitului net?". Este responsabilitatea companiei garantarea corectitudinii și actualității faptelor din OKF.

Concluzie: ce rezervă viitorul pentru formatul OKF?

În doar șase săptămâni și două variante publicate, OKF a dovedit că are suficientă flexibilitate pentru un strat unificat peste date dar înainte de acțiunile efective AI.

Am identificat două riscuri principale: responsabilitatea actualizării și pericolul de bloat: a crea un data lake separat, de data asta în Markdown. Impactul operațional va depinde de cât timp investește compania în scrierea și mentenanța unui OKF curat, uneltele interoperabile care vor apărea și succesul în domenii disparate în care se folosește AI.

Exemplificăm succesul posibil cu ultimele ghiduri tehnice recente ale OPTI:

În sfârșit, așteptăm să apară măsurătorile care vor face diferența în adopție, în special rezultatele din mediul enterprise și reducerea halucinațiilor cu un procent previzibil.

Aveți reguli și proceduri distribuite în companie? OPTI le poate integra pentru a fi folosite cu succes de agenți AI

×