NLWeb protokoll: természetes nyelvű lekérdező felület a saját weboldalon

Scheo · 2026-10-30 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Ha egy több száz termékes webshopot vagy egy sok szolgáltatást felsoroló céges oldalt viszel, a látogatóid valószínűleg ma is kérdésekkel érkeznek. A belső keresőmező viszont kulcsszavakat vár, és a „melyik szűrő illik a 2018-as gépemhez, és van-e mosható változata” típusú kérdésre ritkán ad jó találatot. Az NLWeb erre a résre épít. A Microsoft által kezdeményezett nyílt protokoll és referencia-implementáció arra való, hogy a saját weboldalad természetes nyelvű kérdésekre válaszoljon, emberi látogatónak és AI-ügynöknek egyaránt. Az alábbiakban végigmegyünk azon, hogyan működik, mit kell előkészíteni hozzá, milyen kockázatai vannak, és mikor érdemes egyáltalán foglalkozni vele.

A szövegben háromféle jelölést használunk. A Hivatalosan igazolt rész a projekt vagy a szabványok dokumentációjából származik. A Saját tapasztalat a KKV-oldalak strukturált adatain végzett munkánkból jön. A Szakmai feltételezés olyan következtetés, amelyet ma még nem lehet adattal alátámasztani.

Mi az NLWeb, és ki indította el?

Az NLWeb (Natural Language Web) egy nyílt forráskódú projekt, amelyet a Microsoft a 2025-ös Build fejlesztői konferencián jelentett be. Azt célozza, hogy bármely weboldal viszonylag kevés munkával saját, természetes nyelvű lekérdező felületet kapjon, amely a webhely meglévő strukturált adataiból dolgozik.

Hivatalosan igazolt. A projektet R. V. Guha vezeti, aki korábban az RSS, az RDF és a schema.org létrehozásában is részt vett. A kód a GitHubon nyilvános. A Microsoft bejelentése szerint az NLWeb technológiasemleges, vagyis többféle nyelvi modellel (például OpenAI, Anthropic, Gemini) és többféle vektoradatbázissal (például Qdrant, Milvus, Azure AI Search, Postgres) is futtatható, Windows, macOS és Linux alatt egyaránt. A bejelentés azt a párhuzamot használta, hogy az NLWeb az ügynökök által használt weben hasonló szerepet tölthet be, mint a HTML a böngészők webjén.

Ez utóbbi a szerzők célkitűzése. Hogy valóban így lesz-e, az attól függ, mennyi webhely és mennyi AI-szolgáltatás kezdi el használni, és erről ma még nincs nyilvános, megbízható adat.

Hogyan épít az NLWeb a schema.org adatokra?

Az NLWeb abból az adatból dolgozik, amit az oldalad már most is gépileg olvasható formában közöl, elsősorban schema.org jelölésből, RSS-ből és hasonló strukturált feedekből. Ezeket betölti egy vektoradatbázisba, és egy nyelvi modell segítségével ebből válaszol a kérdésekre.

A folyamat leegyszerűsítve négy lépésből áll.

1. Betöltés. Az NLWeb beolvassa az oldal strukturált adatait, jellemzően JSON-LD jelölést vagy RSS-feedet.
2. Beágyazás. Minden elemből (termék, szolgáltatás, recept, esemény, cikk) vektor készül, és ez bekerül az adatbázisba.
3. Keresés és rangsorolás. Egy kérdésre a rendszer kikeresi a jelentésben legközelebbi elemeket, majd a nyelvi modell szűri és sorba rendezi őket, szükség esetén össze is foglalja.
4. Válasz. Az eredmény schema.org szerkezetű JSON, így egy másik program vagy ügynök is fel tudja dolgozni.

Ebből következik a legfontosabb gyakorlati tanulság. Ha a termékoldaladon a strukturált adatban nincs elérhetőség, márka vagy kategória, az NLWeb sem fogja tudni. A modell a hiányt jó esetben kihagyja, rossz esetben a szöveges tartalomból próbálja kikövetkeztetni, és ott már tévedhet. Egy egyszerű, de használható termékjelölés így néz ki (az árat és a pénznemet az offers blokkban a saját adataiddal töltsd ki).

{"@context":"https://schema.org","@type":"Product","name":"Mosható HEPA szűrő","sku":"SZ-2018-H","brand":{"@type":"Brand","name":"Példa Márka"},"description":"Mosható HEPA szűrő a 2016 és 2019 között gyártott X sorozatú porszívókhoz.","category":"Porszívó alkatrész > Szűrő","additionalProperty":[{"@type":"PropertyValue","name":"Mosható","value":"igen"}],"offers":{"@type":"Offer","availability":"https://schema.org/InStock"}}

Látszik, hogy a kompatibilitás és a moshatóság külön, gépileg olvasható mezőben szerepel. Egy természetes nyelvű felület pont az ilyen tulajdonságokra tud jól szűrni.

Mit kap vissza a kérdező?

Hivatalosan igazolt. A projekt dokumentációja szerint a lekérdezés egy /ask végponton megy, amely a kérdés mellett a korábbi kérdéseket is fogadhatja, így a beszélgetés folytatható. Többféle válaszmód van. A list mód találati listát ad vissza, a summarize mód a lista mellé rövid összefoglalót ír, a generate mód pedig a hagyományos RAG-megoldásokhoz hasonlóan szöveges választ fogalmaz. Egy egyszerű kérés például így néz ki: GET /ask?query=mosható+szűrő+X+sorozathoz&mode=list. A végpontok és a paraméterek a projekt fejlődésével változhatnak, ezért bevezetés előtt mindig az aktuális GitHub-leírást nézd meg.

Miben különbözik egy chatbottól vagy a belső keresőtől?

A hagyományos belső kereső szavakat egyeztet, a legtöbb chatbot pedig zárt rendszer, amely csak a saját ablakában érhető el. Az NLWeb a kettő között áll, jelentés alapján keres a strukturált adatban, és ugyanazt a választ szabványos formában külső ügynököknek is átadja.

Ennek két következménye van. Az egyik, hogy a válasz minősége szinte teljesen az adatodon múlik, a modell csak rendezi és megfogalmazza azt, ami az indexben van. A másik, hogy a felületet nem csak a látogatóid használhatják. Egy AI-asszisztens, amely a felhasználója nevében vásárlási lehetőségeket hasonlít össze, ugyanúgy feltehet kérdést, mint egy ember a keresőmezőben.

Mi köze az NLWeb-nek az MCP-hez?

Minden NLWeb-példány egyben MCP-szerver is. Az MCP (Model Context Protocol) az Anthropic által 2024 végén közzétett nyílt szabvány, amelyen keresztül AI-asszisztensek és ügynökök külső eszközöket és adatforrásokat érhetnek el egységes módon.

Hivatalosan igazolt. Az NLWeb az ask műveletet MCP-eszközként is elérhetővé teszi. Egy MCP-t támogató kliens, például egy asztali AI-asszisztens vagy egy ügynök-keretrendszer, így közvetlenül kérdezheti az oldalad adatait, a HTML-oldalak letöltése és értelmezése nélkül.

Szakmai feltételezés. Ennek a gyakorlati súlya akkor nő meg, ha a nagy AI-asszisztensek rutinszerűen elkezdik keresni és használni a webhelyek saját MCP-végpontjait. Jelenleg nincs nyilvános adat arról, hogy a ChatGPT, a Gemini vagy a Copilot az NLWeb-végpontot használó oldalakat előnyben részesítené a szokásos bejárással megismert oldalakkal szemben. Ezért az NLWeb-től ne várj közvetlen AI-láthatósági hatást. Kísérleti csatornaként érdemes kezelni, amelynek értéke attól függ, kik kapcsolódnak rá.

Milyen előfeltételek kellenek egy KKV-oldalon?

Három feltétel kell hozzá, mégpedig hiánytalan strukturált adat, rendezett termék- vagy szolgáltatáslista, és olyan hosting, amelyen Python-alkalmazás, vektoradatbázis és nyelvimodell-hívások futtathatók. Ha ezek közül bármelyik hiányzik, a bevezetés előtt azt kell rendbe tenni.

Strukturált adat, amelyre építeni lehet

Az alábbi ellenőrzőlistát érdemes végigvenni, mielőtt bármilyen természetes nyelvű felületen gondolkodnál.

• Minden termék- és szolgáltatásoldalon érvényes JSON-LD van, a profilodnak megfelelő típussal (Product, Service, LocalBusiness, Event, Recipe).
• A kötelező és ajánlott mezők ki vannak töltve, termékeknél a név, a leírás, a kép, az ár, a pénznem, az elérhetőség, a márka és a cikkszám.
• A variációk (méret, szín, kiszerelés) külön is megjelennek, és a fontos tulajdonságok külön mezőben vannak, a leírás szövegébe rejtve nem elég.
• A strukturált adat megegyezik az oldalon látható tartalommal, a Google irányelvei is ezt kérik.
• A Rich Results Test és a Schema Markup Validator hiba nélkül lefut.
• A Search Console termékadat-jelentéseiben nincs tömeges figyelmeztetés.

Saját tapasztalat. KKV-oldalak átvizsgálásakor gyakran látjuk, hogy a WordPress-bővítmény által generált jelölés csak a nevet és az árat tartalmazza, a variációk és a műszaki tulajdonságok pedig egyáltalán nem jelennek meg benne. Ilyen adatból egy természetes nyelvű felület sem tud jó választ adni, mert nincs mire szűrnie.

Tiszta termék- vagy szolgáltatáslista

A duplikált termékek, a bent felejtett tesztbejegyzések és a régi, megszűnt szolgáltatások mind bekerülnek a válaszokba, ha a betöltött adatban ott vannak. Érdemes egy külön, ellenőrzött feedet készíteni az NLWeb számára, csak az aktív elemekkel, és kizárólag azt betölteni. Szolgáltató cégnél ez lehet akár húsz jól leírt szolgáltatás is, mindegyik saját oldallal és Service jelöléssel, egyértelmű területtel és célcsoporttal.

Hosting és üzemeltetés

Az NLWeb nem egy telepíthető WordPress-bővítmény. Külön alkalmazásként fut, és Python-környezet, vektoradatbázis, valamint egy nyelvimodell-szolgáltató API-kulcsa kell hozzá. Egy átlagos osztott tárhely erre jellemzően alkalmatlan, ezért VPS, konténeres felhőszolgáltatás vagy menedzselt platform jöhet szóba. Számolj azzal is, hogy minden kérdés nyelvimodell-hívással jár, aminek folyamatos, a forgalommal együtt növekvő költsége van.

Milyen kockázatai vannak az NLWeb bevezetésének?

A három fő kockázat a szerverterhelés, a pontatlan vagy kitalált válasz és a folyamatos karbantartási igény. Mindhárom kezelhető, de egyik sem tűnik el magától.

• Terhelés és költség. Egy nyilvános /ask végpontot és MCP-felületet bármilyen ügynök hívhat. Kéréskorlát, gyorsítótár és költségplafon nélkül egy agresszív bot gyorsan felpörgetheti a modellhívások számát. Ugyanazok a szempontok érvényesek, mint az AI-crawlerek forgalmánál, csak itt minden kérés közvetlen modellköltséggel jár.
• Pontatlan válasz. A nyelvi modell félreértheti a kérdést, összemoshat két hasonló terméket, vagy állíthat olyat, ami a forrásban nincs benne. Webshopnál egy rossz elérhetőségi vagy kompatibilitási adat panaszhoz és visszaküldéshez vezethet. A list mód, amely csak meglévő elemeket ad vissza, kisebb kockázatú, mint a szabad szöveget fogalmazó generate mód.
• Karbantartás. A vektoradatbázist frissíteni kell, amikor a választék változik. Ha az index egy hete nem frissült, a felület a már elfogyott terméket is ajánlani fogja. A projekt aktív fejlesztés alatt áll, a frissítések megtörhetik a saját testreszabásaidat.
• Adatvédelem és átláthatóság. A beírt kérdések személyes adatot is tartalmazhatnak, és egy külső modellszolgáltatóhoz kerülnek. Ezt az adatkezelési tájékoztatóban jelezni kell, az EU MI-rendeletének átláthatósági szabályai szerint pedig a felhasználónak tudnia kell, hogy géppel kommunikál.

Saját tapasztalat. Chatbotok és AI-alapú keresők bevezetésénél a legtöbb munkát a tesztkérdések összegyűjtése és a hibás válaszok kijavítása viszi el, maga a telepítés ehhez képest a kisebb rész. Hogy ez az NLWeb esetén is így lesz, az szakmai feltételezés, de a működési elv alapján erősen valószínű.

Mikor korai még, és mikor érdemes kísérletezni vele?

Kis, néhány oldalas szolgáltatói weboldalnál jelenleg korai. Nagy, jól strukturált termékkatalógusnál, receptgyűjteménynél vagy eseménynaptárnál már érdemes lehet egy korlátozott kísérlet, ha van rá technikai kapacitás.

Korai még, ha

• húsznál kevesebb termék vagy szolgáltatás van az oldalon, és a menüből minden két kattintással elérhető;
• a schema.org jelölés hiányos, hibás, vagy csak a főoldalon szerepel;
• nincs, aki rendszeresen átnézze a válaszokat és frissítse az indexet;
• osztott tárhelyen fut az oldal, és nincs lehetőség külön alkalmazás üzemeltetésére;
• a mostani belső keresőt is ritkán használják a látogatók, amit a GA4 webhelyen belüli keresési adatai megmutatnak.

Érdemes kísérletezni, ha

• több száz vagy több ezer terméked van, sok szűrhető tulajdonsággal (méret, anyag, kompatibilitás, felhasználási terület);
• az ügyfélszolgálatra vagy a chatre rendszeresen érkeznek összetett, több feltételes kérdések;
• a strukturált adat már most hibátlan, és automatikusan frissül a készletből;
• van fejlesztői kapacitás egy külön környezet üzemeltetésére és felügyeletére;
• az AI-ügynökök viselkedéséből is szeretnél tanulni, és vállalod, hogy a kísérlet esetleg nem hoz mérhető forgalmat.

Szakmai feltételezés. Egy nagy alkatrész-, szerszám- vagy kozmetikai katalógusnál a több feltételt egyszerre tartalmazó kérdés az, amit kulcsszavas keresővel nehéz kiszolgálni. Itt a legnagyobb az esélye annak, hogy egy természetes nyelvű felület valódi segítséget ad a vásárlónak.

Hogyan kezdj hozzá lépésről lépésre?

Kis lépésekben, éles forgalomtól elzárva. Előbb az adatot kell rendbe tenni, utána egy belső tesztkörnyezetben mérni a válaszok minőségét, és csak ezután szabad a felületet nyilvánossá tenni.

1. Auditáld a strukturált adatot a Schema Markup Validatorral, a Rich Results Testtel és a Search Console jelentéseivel, és javítsd a tömeges hibákat.
2. Készíts egy tiszta, ellenőrzött feedet, kizárólag az aktív termékekből vagy szolgáltatásokból.
3. Telepítsd az NLWeb-et a GitHub-leírás szerint egy elkülönített gépre, és válassz vektoradatbázist és modellszolgáltatót.
4. Töltsd be a feedet, és gyűjts legalább ötven valós kérdést az ügyfélszolgálati levelekből, a chatnaplókból és a belső kereső naplójából.
5. Futtasd le a kérdéseket mindhárom válaszmódban, és jelöld meg, melyik válasz pontos, hiányos vagy hibás.
6. Ha a pontosság elfogadható, kapcsolj be kéréskorlátot, naplózást és költségriasztást, és csak ezután nyisd meg a végpontot egy szűk körnek.
7. Állíts be ütemezett újraindexelést, a készletváltozások gyakoriságához igazítva.

Ha a negyedik és ötödik lépés után a válaszok jelentős része hibás, annak oka szinte mindig az adatban keresendő. Ilyenkor ne a modellt cseréld, előbb a jelölést és a feedet javítsd.

Miért térül meg a jó strukturált adat akkor is, ha az NLWeb nem terjed el?

Azért, mert ugyanaz az adat ma is több helyen dolgozik. A Google a termékadatokból kiemelt találatokat és termékmegjelenítéseket épít, a válaszmotorok a jól jelölt oldalakat könnyebben értelmezik, és a saját belső kereső, illetve a szűrők is ugyanebből az adatból javulnak.

Hivatalosan igazolt. A Google Search Central dokumentációja szerint a strukturált adat segít a Google-nek megérteni az oldal tartalmát, és jogosulttá teheti az oldalt bizonyos kiemelt találati formákra. A Google ugyanakkor azt is jelzi, hogy a jelölés megléte nem jelent automatikus megjelenést.

Saját tapasztalat. Ha egy KKV a következő hónapokban egyetlen technikai AI-SEO feladatot végez el, az a hiánytalan, a látható tartalommal egyező schema.org jelölés legyen. Ez az NLWeb előfeltétele, de nélküle is hasznos a hirdetési termékfeedtől a válaszmotorokig. Ha az NLWeb vagy egy utódja egyszer széles körben elterjed, egy ilyen oldal viszonylag gyorsan rácsatlakoztatható. Ha nem terjed el, a munka akkor sem vész kárba.

Szakmai feltételezés. Ma nem látható előre, hogy a webhelyeken belüli természetes nyelvű lekérdezés az NLWeb-en, egy másik MCP-alapú megoldáson vagy a nagy platformok saját ügynökein keresztül terjed-e el. Az adatminőség viszont mindhárom forgatókönyvben számít, ezért a befektetés iránya akkor is jó, ha a konkrét protokoll változik.

Források és további olvasnivalók

• Microsoft, az NLWeb bejelentése (Microsoft Build 2025, Microsoft Source blog)
• NLWeb GitHub-tároló és fejlesztői dokumentáció (microsoft/NLWeb)
• Model Context Protocol, hivatalos specifikáció és dokumentáció
• Schema.org, Product, Offer, Service és LocalBusiness típusok leírása
• Google Search Central, bevezetés a strukturált adatokba és a termékadatok irányelvei
• W3C, JSON-LD 1.1 ajánlás
• Az Európai Unió 2024/1689 rendelete a mesterséges intelligenciáról (MI-rendelet), 50. cikk