🐍 Stanford STORM: PhD-szintű kutatás percek alatt¶
Dátum: 2026-06-19 Forrás: Stanford STORM Research Project (NAACL 2024, Yijia Shao et al.) + GitHub repo (stanford-oval/storm, 28.5K⭐)
Mi a STORM és miért fontos?¶
A STORM a Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking rövidítése — a Stanford Oval (Omni Lab for AI & Knowledge) 2024-es NAACL publikációja. Célja, hogy egy LLM a semmiből, emberi beavatkozás nélkül képes legyen Wikipedia-minőségű, hivatkozásokkal ellátott, hosszú cikket generálni. A kutatás központi kérdése: hogyan lehet a nyelvi modellek "tudáshiányát" (knowledge gap) pótolni anélkül, hogy a modellt finomhangolnánk vagy hatalmas, kézzel szerkesztett tudásbázist építenénk.
A rendszer filozófiája egyszerű: a cikkírás nem a mondatok megfogalmazásánál kezdődik, hanem a kutatásnál. Egy jó újságíró sem úgy ír cikket, hogy leül és elkezdi ontani a szöveget — előbb interjúkat készít, forrásokat olvas, vázlatot készít, és csak utána ír. A STORM ezt a munkafolyamatot formalizálta gépi szintre.
Két fázis, nem egyben az egész¶
A STORM nem egyetlen nagy prompt, hanem egy explicit pipeline. Az első fázis a pre-writing stage: a modell aktívan kutat, webes kereséseket futtat, forrásokat gyűjt, és egyre pontosabb kérdéseket tesz fel a témáról. A végén egy részletes outline-t (vázlatot) állít elő, amelyben minden egyes állítás mögött legalább egy hivatkozás áll.
A második fázis a writing stage: az outline és az összegyűjtött források alapján a modell megírja a végleges cikket. Ez a fázis már "csak" szintézis — az értékes munka (kutatás, perspektívák feltárása, tényellenőrzés) már az első fázisban megtörtént. A két fázis szétválasztása azért kulcsfontosságú, mert ha egyszerre próbáljuk a kutatást és az írást, a modell hajlamos "képzelni" a tartalom kitöltéséhez — a STORM ezt a hibát strukturálisan kerüli el.
Perspective-Guided Question Asking: nézőpontok automatikus felismerése¶
A STORM egyik legzseniálisabb trükkje, hogy nem csak "mondj többet a témáról" típusú kérdéseket tesz fel, hanem különböző perspektívákat azonosít, és mindegyikből külön kérdéssort generál. Ha például a "bitcoin" a téma, akkor a modell automatikusan felismeri, hogy vannak közgazdász, technológiai, szabályozási, történeti nézőpontok — és mindegyikből feltárja a legfontosabb kérdéseket.
Ez a megközelítés drasztikusan javítja a cikk szélességét: ahelyett, hogy egyetlen szempontból írná körül a témát, a modell több szálon halad egyszerre. A nézőpontokat a modell automatikusan generálja (nem kell kézzel megadni), és a kutatás során dinamikusan frissülnek — ha egy új perspektíva bukkan fel a forrásokban, az is beépül.
Simulated Conversation: szimulált szakértői interjú¶
A másik kulcstechnika a simulated conversation: a STORM nem csak statikus kérdéslistát generál, hanem egy szimulált beszélgetést folytat egy "témaszakértővel" (ami valójában egy retrieval-augmented QA rendszer — vagyis a modell a weben keres, és az eredmények alapján "válaszol" a saját kérdéseire).
Ennek az az előnye, hogy a modell follow-up kérdéseket tud feltenni: ha az első válaszban valami érdekeset talál, rákérdezhet, pontosíthat, mélyíthet. Ez az iteratív mélyülés sokkal természetesebb, mint ha egyszerre akarnánk minden részletet kideríteni. A valódi kutatók is így dolgoznak: az első olvasás után jönnek a "várj, de mi van akkor, ha…" típusú kérdések.
Mért eredmények: mit javít ténylegesen a STORM?¶
A NAACL 2024-es publikációban a szerzők konkrét számokat közöltek: a STORM 25%-os abszolút javulást ér el a generált cikkek strukturáltságában, és 10%-os javulást a tartalom szélességében a baseline-hoz képest. Ezeket tapasztalt Wikipedia-szerkesztők értékelték — vagyis nem gépi benchmark, hanem valódi szakértői vélemény.
A kutatás egyik legérdekesebb megállapítása, hogy a szerkesztők különösen a pre-writing stage-t találták hasznosnak — az outline-t és a forrásgyűjtést akkor is értékesnek ítélték, ha a végleges cikket végül kézzel írták meg. Ez arra utal, hogy a STORM nem csak végtermékként, hanem kutatási asszisztensként is értékes.
A fő hiba: nem hallucináció, hanem "red herrings"¶
A STORM elemzésének egyik legtanulságosabb része a hibakatalógus. Ellentétben a legtöbb LLM-alapú rendszerrel, itt a fő hiba nem a hallucináció (kitalált tények), hanem az ún. "red herrings" — irreleváns vagy lazán kapcsolódó tartalom bekerülése a cikkbe, a fontos tények túlhangsúlyozása, vagy a hangsúlyok elcsúszása.
Ennek oka, hogy a STORM retrieval-alapú: a modell valódi forrásokból dolgozik, tehát nem talál ki dolgokat — de a források között nem mindig tud jól szelektálni, és hajlamos a felszínes kapcsolatokat is "érdekesnek" minősíteni. A tanulság: a retrieval minősége fontosabb, mint a generálás minősége. Ha rossz forrásokat adunk a modellnek, akkor a kimenet is rossz lesz — de legalább nem kitalált, hanem valódi, de félrevezető tartalom.
Co-STORM: amikor az ember is részt vesz¶
Az EMNLP 2024-es follow-up, a Co-STORM (Collaborative STORM), a STORM-ot ember-AI kollaboratív rendszerré bővítette. Itt már nem egy LLM dolgozik egyedül, hanem egy LLM "experts" + Moderator + Human user hármasban működik együtt, egy explicit turn management policy alapján.
A Co-STORM legfontosabb újítása a dinamikusan frissülő "mind map" — egy hierarchikus fogalom-struktúra, amely valós időben követi a beszélgetés állapotát. Ahogy az ember kérdez, és a rendszer válaszol, a mind map automatikusan átrendeződik: az új információk beépülnek, a régiek háttérbe szorulnak, a struktúra áttekinthető marad. Ez különösen hosszú, mély beszélgetéseknél kritikus — a cél, hogy csökkentse a mentális terhet, amikor a diskurzus már több tucat lépésnél tart.
A Co-STORM gyakorlatilag egy "AI kutatási partner", akivel hangosan gondolkodhatunk: ő szolgáltatja a tényeket és a struktúrát, mi pedig irányítjuk a kérdésfeltevést és a prioritásokat.
Technikai részletek: hogyan lehet kipróbálni?¶
A STORM nyílt forráskódú, és meglepően könnyen telepíthető. A Python csomag a PyPI-n érhető el: pip install knowledge-storm. A rendszer a dspy framework-re épül (Stanford másik népszerű LLM-programozási könyvtára), és a litellm integrációnak köszönhetően számos modellt támogat.
Az alapértelmezett konfiguráció GPT-3.5-öt használ a szimulált beszélgetéshez (olcsó, gyors) és GPT-4o-t a cikkíráshoz (drágább, de jobb minőségű). A search engine oldaláról a támogatott szolgáltatások listája imponáló: You.com, Bing, VectorRM, Serper, Brave, SearXNG, DuckDuckGo, Tavily, Google, Azure AI — gyakorlatilag bármilyen keresőmotorral működik.
A live demo a storm.genie.stanford.edu címen érhető el, és a cikk írásakor 70 000+ felhasználó próbálta már ki — ez önmagában is jelzi, hogy a rendszer nem csak elméleti érdekesség, hanem valóban működő eszköz.
Korlátok és nyitott kérdések¶
A STORM sem csodaszer — több nyilvánvaló korlátja is van. Először is, a rendszer erősen függ a search engine-ek minőségétől: ha a keresőmotorok elavult vagy alacsony minőségű találatokat adnak, a STORM kimenete is romlik. A "red herrings" probléma is innen ered: a retrieval a szűk keresztmetszet, nem a generálás.
Másodszor, a STORM jelenleg angol nyelvre van optimalizálva. A magyar (vagy más nem-angol) nyelvű cikkek generálásához a keresési találatokat és a forrásokat is lokalizálni kellene, és a hivatkozási kultúra is eltérő (más domain-ek, más szerkesztési normák). A módszer elvileg működik más nyelveken is, de a gyakorlati minőség egyelőre angolul a legjobb.
Harmadszor, a költség és a sebesség sem elhanyagolható: egy átlagos, ~10 szekciós cikk generálása a pre-writing stage-ben akár több tucat webes lekérést és LLM-hívást is igényelhet, ami percekig tarthat és dollárokba kerülhet (főleg, ha GPT-4o-t használunk). A Co-STORM ezen javít az emberi beavatkozással (a felhasználó irányíthatja a kutatást, és csak a releváns lépéseket kell végrehajtani), de alapvetően a STORM nem "ingyenes és azonnali" eszköz.
Végül, a STORM egy érdekes episztemológiai kérdést is felvet: ha egy cikk forrásait a modell maga gyűjti és maga szintetizálja, akkor ki a "szerző"? A STORM kimenete formailag hasonlít egy Wikipedia-szócikkre, de a szerkesztési folyamat nem transzparens — a felhasználó nem feltétlenül tudja követni, hogy a modell melyik forrásból mit vett át, és mi maradt ki. Ez a "fekete doboz" probléma különösen érzékeny területeken (orvoslás, jog, pénzügyek) lehet problematikus.
Gyakorlati alkalmazási területek¶
A STORM-ot többféle kontextusban lehet használni. A legegyértelműbb a Wikipédia-szerű tudásbázis-építés: ahol gyorsan kell jól strukturált, hivatkozott tartalmat előállítani. A második a kutatási asszisztensi szerep: a Co-STORM ember-gép kollaborációban a modell a "kutató", az ember pedig az "igazgató", aki a hangsúlyokat és az irányt szabja meg.
Harmadik terület a tudás-gyorstérképezés (knowledge mapping): ha egy új témában kell gyorsan áttekintést kapni, a STORM kiválóan alkalmas arra, hogy percek alatt összerakjon egy vázlatot a legfontosabb szempontokkal, nézőpontokkal és hivatkozásokkal. A negyedik — kevésbé nyilvánvaló — felhasználás az oktatás: a STORM kitűnő eszköz arra, hogy egy diák vagy kutató megnézze, milyen nézőpontokat és kérdéseket kellene feltennie egy adott témáról, mielőtt nekiáll a saját kutatásának.
Modell-agnosztikus módszertan: nem a Claude a lényeg¶
A STORM egyik legfontosabb tulajdonsága, hogy modell-agnosztikus: nem kötődik egyetlen konkrét LLM-hez. A kutatás eredetileg GPT-modellekre optimalizált, de a módszer (multi-perspective kérdésgenerálás + retrieval-augmented szimulált beszélgetés + outline-alapú írás) bármilyen nyelvi modellel működik, amelyik képes strukturált kérdéseket feltenni és kontextus-érzékeny válaszokat adni.
Ez azt jelenti, hogy a GLM-5.2 (és más hasonló modellek) is alkalmazhatják a STORM paradigmát — bár a minőség természetesen függ a modell képességeitől (kontextuskezelés, kérdésmegformázás, szintézis). A lényeg nem a modell, hanem a módszer: ha a pipeline-t jól építjük fel, a gyengébb modell is produkálhat erős eredményeket; ha a pipeline rossz, a legerősebb modell is csak drága hallucinátor lesz.
Összegzés¶
A STORM legnagyobb tanulsága, hogy a hosszú, strukturált, hivatkozásokkal ellátott tartalom generálásának kulcsa nem a nagyobb modell, hanem a jobb munkafolyamat: kutatás először, írás utána, több perspektíva párhuzamosan, és iteratív mélyülés szimulált beszélgetéssel. A 25%-os strukturáltság-javulás és a Co-STORM ember-gép kollaboráció egyaránt azt mutatja, hogy a jövő nem a "még több paraméter", hanem a "még okosabb pipeline" irányába mutat — és ebben a STORM úttörő.