A Google Open Knowledge Format és az ügynökségi keresőoptimalizálás jövője

A Google Open Knowledge Format és az ügynökségi keresőoptimalizálás jövője

A digitális világ csendes, de folyamatos változáson megy keresztül. Több mint két évtizeden át a keresőoptimalizálást (SEO) egyetlen, egyszerű paradigma uralta: weboldalak optimalizálása az emberi szem számára, indexelésük webes robotokon keresztül, és az adatok komplex sémajelöléssel történő strukturálása, hogy a gépek megértsék az alapvető entitásokat. De ahogy a keresőmotorok korszakából az autonóm mesterséges intelligencia ágensek korszakába lépünk, ez a paradigma gyorsan összeomlik.

Napjainkban a vállalkozások kritikus „kontextushiánnyal” szembesülnek. Míg a nagy nyelvi modellek (LLM-ek) képesek elegáns kódot írni, dokumentumokat vázlatolni vagy hatalmas adathalmazokat elemezni, alapvetően továbbra is korlátozza őket a strukturált, naprakész és saját üzleti kontextus hiánya. Ez a tudás – az adatbázis-sémáktól és az egyéni üzleti metrikáktól kezdve a belső kézikönyveken át a vezető mérnökök íratlan meglátásaiig – széttöredezetten él a különálló wikikben, megosztott meghajtókon, diavetítéseken és csevegésnaplókban.

Ennek a szakadéknak az áthidalására a Google Cloud nemrégiben bemutatta az Open Knowledge Format (OKF) v0.1-et, egy nyílt, szállítósemleges specifikációt, amelynek célja, hogy a szervezeti tudást egy interoperábilis „digitális agyként” ábrázolja. Az úgynevezett „LLM-Wiki” minta formalizálásával az OKF a hagyományos, állapot nélküli Retrieval-Augmented Generation (RAG) végét jelzi, és egy összetett, ágentikus jövőt nyit meg.

Az előremutató szervezetek és a tanácsadási úttörők, mint például a Switas számára az OKF nem csupán egy technikai frissítés. Egy vadonatúj kereskedelmi diszciplína alapja: az Agentic Search Optimization (ASO).

1. Az állapot nélküli RAG halála és az összetett tudás felemelkedése

Ahhoz, hogy megértsük, miért áttörést jelent a Google OKF-je, először meg kell vizsgálnunk, hogy a jelenlegi MI-integrációs módszereink miért ütköznek nehézségekbe.

A legtöbb modern vállalati mesterséges intelligencia megoldás a Retrieval-Augmented Generation (RAG) módszeren alapul. Amikor egy felhasználó feltesz egy kérdést, egy RAG rendszer hasonlóságkeresést futtat a vektorizált dokumentumrészletek között, kikeresi a legrelevánsabb részleteket, és betáplálja azokat az LLM kontextusablakába a válasz generálása érdekében.

Bár az RAG rendkívül hatékony a statikus kérdések és válaszok terén, számos rendszerszintű korlátozással küzd:

Állapotmentesség: Minden lekérdezést elszigetelt eseményként kezel a rendszer. A rendszer nem "tanul" a korábbi interakciókból, és nem szintetizál új kapcsolatokat.
Visszakeresési zaj és adatblokk-határ hibák: Egy 50 oldalas PDF 500 tokenből álló darabokra bontása gyakran kettévágja a kritikus kontextust, ami hiányos vagy félrevezető válaszokhoz vezet.
A szintézis hiánya: A hagyományos RAG kiválóan képes nyers információk kinyerésére, de nehezen tudja fenntartani a folyamatosan fejlődő, egyetlen „igazságforrást”.
2026 áprilisában Andrej Karpathy, a mesterséges intelligencia úttörője (az OpenAI társalapítója és a Tesla korábbi mesterséges intelligencia igazgatója) forradalmi alternatívát javasolt: az LLM Wiki mintát.

Ahelyett, hogy minden egyes alkalommal a nulláról keresnénk a nyers, strukturálatlan dokumentumokat, Karpathy azzal érvelt, hogy az LLM-eket helyesen fordítóprogramként kell használni. Ebben a paradigmában, amikor egy új dokumentum, adatkészlet vagy ügyfél-bíráskodás érkezik, az LLM egyszer elolvassa, kinyeri belőle a kulcsfogalmakat, és fokozatosan „összeállítja” azokat egy strukturált, perzisztens és szorosan összekapcsolt, Markdown-alapú wikivé.

Ha olyan új információ érkezik, amely ellentmond egy régebbi bejegyzésnek, az LLM nem csupán tárolja mindkettőt, hanem aktívan feloldja az ütközést, frissíti az entitásoldalakat, átdolgozza a témaösszefoglalókat, és megerősíti vagy megkérdőjelezi a folyamatosan fejlődő szintézist. A tudás idővel összeadódik, pontosan úgy, mint az emberi agy.

A Google Cloud OKF-je ennek a pontos LLM-Wiki mintának a formalizálása nyílt ipari szabványként.

2. A Nyílt Tudás Formátum (OKF) mítoszainak leleplezése

Az OKF lényegében rendkívül egyszerűnek készült. A Google határozott filozófiai álláspontot képviselt: nincs szükségünk komplex adatbázisokra, saját fejlesztésű SDK-kra vagy nehézkes futási környezetekre a tudás reprezentálásához. Ehelyett a tudást olyan formátumban kell tárolni, amely univerzálisan hordozható, könnyen olvasható az emberek számára, és natívan megérthető az LLM-ek számára.

Ez a formátum a Markdown YAML frontmatterrel.

Ha tudsz git klónozni egy adattárat, telepíthetsz egy OKF csomagot. Ha tudsz cat-elni egy szövegfájlt, el is olvashatod. Nincs szükség adatbázisokra, központi jogosultságra és platformfüggőségre. Gyönyörűen jelenik meg a GitHubon, olyan eszközökben rendszerezhető, mint az Obsidian vagy a Notion, és bármely modern MI-ügynök azonnal indexelheti.

Egy OKF tudáscsomag felépítése
Egy OKF csomag szerkezetileg beágyazott könyvtárakból álló könyvtárként van ábrázolva, amely egy ember által tervezett wikire hasonlít. Három fő összetevőből áll:

Belépési pontok (index.md): Minden OKF csomaghoz szükség van egy belépési pont fájlra. Ez az index fájl felvázolja a tudásbázis szerkezetét, és a bejövő ügynököket az elérhető alapvető fogalmakhoz, adatkészletekhez és forgatókönyvekhez irányítja.
Koncepciókönyvtárak: A fájlokat a származásuk alapján történő rendszerezés helyett (pl. q4_marketing_report.pdf), az OKF fogalmak szerint rendszerezi át az információkat (pl. /metrics/customer_acquisition_cost.md). Minden koncepció egyetlen, atomi markdown dokumentumként van ábrázolva.
A naplófájl (log.md): Egy élő főkönyv, ahol az autonóm ágensek rögzítik tevékenységeiket. Amikor egy ágens frissít egy koncepciót, felold egy adatellentmondást, vagy új forrást tölt be, dokumentálja a változást a naplófájlban, így egy auditálható papíralapú nyomvonalat hoz létre.
A koncepcióoldal szerkezete
Minden egyes markdown fájl, amely egy OKF kötegben lévő koncepciót reprezentál, szigorú struktúrát tartalmaz, amely két részből áll: a YAML frontmatterből és a Markdown törzsből.

---
type: concept
title: Customer Acquisition Cost (CAC)
description: The primary financial metric used to evaluate marketing efficiency at Switas.
resource: bigquery://switas-analytics/finance/cac_summary
tags:
 - finance
 - marketing-efficiency
 - saas-metrics
timestamp: 2026-06-18T14:30:00Z
---
After this structured frontmatter, the document opens into a free-form Markdown Body. This is where the magic happens. The body can contain natural language definitions, raw data tables, calculation formulas, playbooks, and—crucially—interlinks using standard markdown bracket notation (e.g., [[LTV_Calculation]]).

Ezek az összekapcsolódások lehetővé teszik az ügynökök számára, hogy strukturálisan navigáljanak a könyvtárban, egy egyszerű szövegfájl-mappát egy szorosan összekapcsolt, navigálható szemantikus tudásgráffal alakítva át.

3. „Szemantikai kibontás”: A természeti tudás filozófiája

Az OKF megjelenéséből felmerülő egyik legmélyrehatóbb kifejezés a „szemantikai kibontás”.

A technológiai ipar évekig megpróbálta az emberi tudást rendkívül merev, géppel olvasható sémákba (mint például a JSON-LD vagy a mikroadatok) erőltetni. Ez a folyamat törékeny, természetellenes és alapvetően elszakadt attól, ahogyan az emberek kifejezik az ötleteiket. Ez egy kísérlet volt arra, hogy a folyékony emberi gondolkodást hideg, kemény gépi struktúrákká „süssék”.

Az OKF a feje tetejére állítja ezt a megközelítést. Mivel a modern LLM-ek hihetetlenül jártasak a természetes nyelv olvasásában, az OKF a „szemantikai kibontás” egy formájaként működik. Lehetővé teszi a szervezetek számára, hogy üzleti szabályaikat, folyamataikat és mutatóikat természetes, kifejező nyelven dokumentálják.

Már nem kell komplex API-t írnia ahhoz, hogy elmagyarázzon egy üzleti számítást egy MI-ügynöknek. Egyszerűen írjon egy forgatókönyvet:

# Playbook: Diagnosing Mid-Funnel Conversion Drops
When an analyst agent detects a drop in mid-funnel conversion rate greater than 5% week-over-week, follow these steps:
1. Query the `conversions_db` table to isolate the traffic source.
2. Cross-reference results with our [[Marketing_Campaign_Log]].
3. If the drop is isolated to paid search, trigger the [[Google_Ads_Audit_Playbook]].
This represents a more natural way to structure knowledge. You tell the agent: "Here is where you go in my organization's brain to get this information, and here is how we want you to reason about it."

4. A Switas lehetősége: Szakértelem monetizálása és az ASO forradalom vezetése

Ahogy a vállalati mesterséges intelligencia fejlődik, a strukturált tudás iránti kereslet az egekbe szökik. A vállalkozások már nem csak a webforgalomért fognak versenyezni, hanem az ágensek általi hozzáférhetőségért is.

Ez hatalmas kereskedelmi horizontot nyit meg a Switas számára két fő vektoron keresztül:

I. Ügynöki keresőoptimalizálási (ASO) tanácsadás

Egy olyan világba lépünk, ahol a fogyasztók nem közvetlenül a weben keresnek; ezt mesterséges intelligencia által biztosított ügynökeik teszik meg helyettük. Amikor egy felhasználó arra kéri személyes ügynökét, hogy „Találja meg nekem a legjobb tanácsadó céget az adatverem OKF irányelvei szerinti átalakításához”, az ügynök feltérképezi a webet, géppel hozzáférhető tudást keresve.

Ha vállalkozásod szakértelme zárt PDF-ek vagy strukturálatlan, JavaScript-tel teli weboldalak mögé van zárva, az ügynök teljesen megkerüli a feladatot.

A Switas úttörő szerepet játszhat a hagyományos SEO-ról az ASO-ra (Agent Search Optimization) való áttérésben. Tanácsadóink segíthetnek a vállalatoknak:

  • Auditálják a meglévő strukturálatlan tudástáraikat.
  • Saját üzleti logika, forgatókönyvek és adatsémák kinyerése.
  • Fordítsa össze és strukturálja ezeket az eszközöket teljes mértékben megfelelő, könnyen feltérképezhető OKF tudáscsomagokba.
  • Irányítási útvonalakat kell integrálni az llms.txt fájlokba, hogy jelezzék a külső ügynököknek, hogy egy ellenőrzött OKF csomag készen áll a felhasználásra.

II. A Tudáscsomag Piactér

Jelenleg, amikor egy vállalkozásnak speciális szakértelemre van szüksége – legyen szó jogi megfelelésről, adóstrukturálásról vagy haladó SEO-auditálásról –, drága tanácsadókat alkalmaznak manuális auditok elvégzésére.

A közeljövőben egy globális tudáspiactér kialakulását fogjuk látni, ahol a szervezetek ellenőrzött, ügynökök által futtatható OKF csomagokat vásárolhatnak és adhatnak el.

Képzeljük el, hogy a Switas saját fejlesztésű növekedési hackelési keretrendszereit, digitális transzformációs kézikönyveit vagy adatauditálási módszereit moduláris OKF csomagokba állítja össze. Az ügyfél mesterséges intelligencia alapú ügynöke megvásárolhatja a Switas Growth Playbook OKF-et, közvetlenül beillesztheti a saját rendszerfájlrendszerébe, és azonnal megkezdheti az auditok végrehajtását a Switas speciális logikájának használatával.

Továbbá ezek a csomagok nem statikusak. Ahogy a piaci körülmények, a keresési algoritmusok vagy a tanácsadási legjobb gyakorlatok fejlődnek, a közzétevő frissíti a fő OKF csomagot. Ezek a frissítések a hálózaton keresztül terjednek, biztosítva, hogy az ügyfél lokalizált MI-intelligenciája folyamatosan frissüljön.

5. Átfogó GYIK: Eligazodni az OKF technikai és stratégiai árnyalataiban

Ahogy az OKF egyre népszerűbbé válik, a vállalati csapatok, fejlesztők és marketingvezetők biztosan kritikus kérdéseket tesznek fel. Íme, amit tudnod kell:

1. kérdés: Hogyan fedezik fel és férnek hozzá a külső MI-ügynökök az OKF-csomagjainkhoz?
A felderítést nagyrészt az újonnan megjelenő llms.txt szabvány fogja kezelni. A webhely gyökerében található llms.txt fájl (hasonlóan a robots.txt-hez) a nyelvi modellek könyvtáraként működik.

Ha hozzáadsz egy közvetlen URI elérési utat, amely a nyilvános OKF csomagodra mutat az llms.txt fájlodban, azzal jelezed a feltérképező ügynököknek (mint például a GPT-Bot, a Claude-Bot vagy a Google-Extended), hogy az üzleti ismereteid strukturált, gépre optimalizált wikije elérhető közvetlen fogyasztásra.

2. kérdés: Az OKF helyettesíti-e a vektoradatbázisokat (Vector DBs) és a gráfadatbázisokat?
Nem. Az OKF nem adatbázis, hanem egy adatcsere- és tárolási specifikáció.

Személyes vagy kisvállalkozási szinten (100 dokumentum vagy nagyjából 80 000 token alatt) egy LLM közvetlenül a fájlrendszerből képes olvasni egy OKF könyvtárat, adatbázis-közvetítő nélkül.

Vállalati szinten azonban az OKF-kötegek tiszta, ember által kurált „Igazságforrásként” szolgálnak, amely a tágabb visszakereső rendszerekbe táplálkozik. Egy vállalat jellemzően beolvasztja az OKF-kötegeket, vektorizálja azokat egy vektor adatbázisba szemantikus kereséshez, és felhasználja azokat egy vállalati szintű gráf adatbázis felépítéséhez. Az OKF tiszta, strukturált szemantikai bemeneteket biztosít, amelyek megakadályozzák az adatbázis-szennyezést.

3. kérdés: Hogyan előzi meg az OKF a mesterséges intelligencia hallucinációit?
A hagyományos RAG gyakran hallucinál, mert arra kényszeríti az LLM-et, hogy töredezett, néha ellentmondásos dokumentumrészletekből generáljon válaszokat.

Az OKF ezt explicit kapcsolati térképezés, forgatókönyvek és pontos hivatkozások kikényszerítésével akadályozza meg. Mivel az OKF fogalmakat emberek gondosan összeállították és strukturálták (vagy szigorú emberi felügyelet mellett állítják össze), az ágens előre szintetizált, ellenőrzött logikára támaszkodik, ahelyett, hogy menet közben találgatná a kapcsolatokat. Továbbá az OKF natív hivatkozástámogatása biztosítja, hogy az ágens által tett minden tényszerű állítás visszakövethető legyen egy adott, ellenőrzött Markdown-fájlra vagy adatforrásra.

4. kérdés: Manuálisan kell megírnunk és karbantartanunk ezeket az OKF csomagokat?
Egyáltalán nem. Több száz markdown fájl írása és összetett YAML sémák manuális követése szűk keresztmetszetet jelentene.

Ehelyett a folyamat kooperatív: az emberek tanulnak és irányítanak; a mesterséges intelligencia ágensei fordítanak és karbantartanak.

Speciális ügynökbeállítások (például Claude Code, Cursor vagy egyéni Python folyamatok) használatával nyers adatforrásokat – például átiratokat, tanulmányokat és adatbázis-sémákat – táplálhat a rendszerbe. Az ügynök automatikusan kinyeri a koncepciókat, megírja a YAML frontmattert, létrehozza a kereszthivatkozásokat, és naplózza a változtatásokat a log.md fájlban.

Az ember szerepe szerkesztővé változik: átnézi az összeállított wikit, stratégiai útmutatást ad hozzá, és automatizált „linter” szkripteket futtat a hibás linkek, árva oldalak vagy logikai ellentmondások ellenőrzésére.

Felkészülés az ügynöki műszakra Switas-szal

A Nyílt Tudás Formátum (Open Knowledge Format) bevezetése egyértelműen jelzi, merre tart a digitális gazdaság. Eltávolodunk az emberi görgetésre tervezett szétszórt oldalak internetétől, és egy összekapcsolt digitális agyak internetje felé haladunk, amelyeket ágensi végrehajtásra terveztek.

A vállalatok számára a választás egyértelmű: vagy már ma elkezdik strukturálni vállalati tudásukat, vagy kockáztatják, hogy láthatatlanná válnak a holnap kereskedelmét előmozdító mesterséges intelligencia ügynökei számára.

A Switasnál egyedülálló helyzetben vagyunk ahhoz, hogy segítsük szervezetét eligazodni ebben az átmenetben. A digitális stratégia, az adatmérnökség és az újonnan megjelenő mesterséges intelligencia szabványok terén szerzett mélyreható szakértelmünk ötvözésével segíthetünk Önnek abban, hogy széttagolt üzleti eszközeit egy hatékony, összetett OKF tudásmotorrá alakítsa.

A jövő decentralizált, strukturált és ügynökségi alapú. Építsük meg együtt!

 


Çağdaş Polat

Írta

Çağdaş Polat

Çağdaş Polat a Switas társalapítója, ahol technológiai és növekedési tanácsadást vezet az e-kereskedelem, az utazás, az egészségügy és az állami szektor márkái számára. A számítástechnikai végzettségű szakember az elmúlt évtizedben szoftverfejlesztésből vezető marketing-, termék- és stratégiai pozíciókba került, és most CRO-val, analitikával és olyan növekedési rendszerek építésével kapcsolatos tanácsokkal látja el a vállalatokat, amelyek mérés alatt is megállják a helyüket.

LinkedIn

Kapcsolódó cikkek

Switas, ahogy látható

Magnify: Influencer marketing skálázása Engin Yurtdakul segítségével

Tekintse meg Microsoft Clarity esettanulmányunkat

Kiemeltük a Microsoft Clarity-t, mint egy olyan terméket, amelyet gyakorlatias, valós felhasználási eseteket szem előtt tartva, valódi termékfejlesztők fejlesztettek ki, akik értik a Switashoz hasonló vállalatok kihívásait. Az olyan funkciók, mint a dühös kattintások és a JavaScript hibakövetés, felbecsülhetetlen értékűnek bizonyultak a felhasználói frusztrációk és a technikai problémák azonosításában, lehetővé téve a célzott fejlesztéseket, amelyek közvetlenül befolyásolták a felhasználói élményt és a konverziós arányokat.