LLM-es termékadat-gazdagítás: attribútumok, bizonyítékok és felülvizsgálat

Az LLM-es termékadat-gazdagítás azt jelenti, hogy egy nyelvi modell PIM-törzsadatokat hoz létre vagy emel szintre: attribútumértékeket szállítói PDF-ekből és adatlapokból, csatornánként rövid és hosszú leírásokat, SEO-címeket, valamint hangnem- vagy nyelvi változatokat. Gondatlanul használva folyékony szöveget kapunk, amelyet senki nem tud ellenőrizni. Folyamatként működtetve olyan értékeket kapunk, amelyek mindegyike visszamutat arra a mondatra, ahonnan származik, a többihez pedig felülvizsgálati sor tartozik.

Ez a cikk a mérnöki nézőpontot képviseli: a bizonyítékhoz kötés a felépítésből következik, a kimenet sémához kötött, a megbízhatóság szerint irányítunk, minden mezőhöz tartozik eredetmegjelölés, a mezőszintű értékelés pedig egy aranyhalmaz (golden set) ellen történik. Áttekintjük a költség- és megfelelőségi határokat is, amelyek eldöntik, megéri-e futtatni a folyamatot. Az LLM-es PIM-adatminőség az osztályozást, a normalizálást és a duplikátumok kezelését tárgyalja, a szállítói adatok bevezetése pedig az árlisták és PDF-ek útját a rendszerbe. Ez a cikk ott kezdődik, ahol az adatok már bekerültek: azt kérdezi, mi kerül a termékrekordba, és hogyan derül ki, hogy helyes-e.

Mit foglalkozik az LLM-es termékadat-gazdagítás?

Azokat az attribútumokat és szövegeket fedi le, amelyek hiányoznak a katalógusból, vagy használhatatlan formában vannak meg: a műszaki értékeket, például a méreteket, a feszültséget vagy az anyagot, amelyek gyakran PDF-adatlapon szerepelnek, nem az ERP-ben; csatornánként több hosszúságú leírásokat; SEO-címeket; valamint fordítási és hangnemi változatokat. Nem tartoznak ide az árak, a készlet és mindaz, amit az ERP birtokol. Ezek az értékek egy mérvadó rendszerből származnak, és ha a modell árat ír egy termékszövegbe, az egy második, nem mérvadó árat hoz létre.

• Attribútumok: a megadott dokumentumokból kinyert értékek, mindegyik mértékegységgel és forrással.
• Szövegek: rövid és hosszú leírások, felsorolások és SEO-címek, kizárólag a jóváhagyott attribútumokból.
• Változatok: fordítások és hangnemi átírások azonos tényekkel. A fordítás működését a LLM-es fordítási folyamat írja le.

Mielőtt bármelyik modell lefut, egy előfeltétel-kapu dönti el, mely SKU-kat érdemes gazdagítani. Egy SKU akkor kész, ha van gyártói cikkszáma, a besorolásból származó kategóriája, legalább egy forrásdokumentuma, amely ténylegesen tartalmazza az attribútumokat, és van olyan csatorna, amely megjeleníti az eredményt. A kapu kihagyása olyan szöveget eredményez, amelyet senki nem tud ellenőrizni, és ez a fajta szöveg később a legdrágább javítani.

Miért bizonyítékból kinyerni, és miért nem generálni?

A kinyerés nem generálás. Ami a gazdagítást biztonságossá teszi, az a szabály: a folyamat minden kiírt értékének a forrásdokumentum egy szövegrészletére kell visszavezethetőnek lennie, a visszavezethetetlen értéket pedig nem írjuk ki. A Google nyílt forráskódú LangExtract könyvtára ezt teszi központi garanciájává: minden kinyerés egy pontos karakterintervallumra mutat a forrásszövegben, így az ellenőrző látja, hol jelölte meg a rendszer. A README nyíltan megnevezi a hibamódot, amely ellen a szabály véd: a modellek időnként a néhány példából kinyernek tartalmat a bemenet helyett. A megalapozatlan kinyerések üres (None) intervallumot kapnak, és a dokumentált szűrő eldobja őket. A könyvtár Apache-2.0 licencű, és a README szerint nem hivatalosan támogatott Google-termék (LangExtract).

Az Anthropic hallucináció-csökkentési útmutatója ugyanezt a gondolatot viszi a prompt szintjére. Engedje meg a modellnek, hogy azt mondja, nem tudja. Hosszú dokumentumoknál, az útmutató szerint 20 000 token felett, először szó szerinti idézeteket kérjen ki, és csak ezekből dolgozzon. Ezután jöjjön egy ellenőrző lépés, ahol minden állításhoz alátámasztó idézetet kell találni, különben visszavonják (Anthropic-dokumentáció). Az idézet-először módszer tokeneket emészt, de megéri, mert egy idézetet az ellenőrző egy pillantással végignézhet. A helyes válasz gyakran az üres érték: ha a dokumentum nem említ egy attribútumot, a kimenetnek hiányoznia kell, nem találgatásnak lennie.

Hogyan épül fel a gazdagító folyamat?

A folyamatnak öt lépése van: a forrásdokumentumok beolvasása, jelölt értékek kinyerése szövegrészletekkel, a kimenet ellenőrzése sémával szemben, mezőnkénti besorolás megbízhatóság szerint, majd az elfogadott értékek kiírása a PIM-be eredetmegjelöléssel. Ugyanazon bemeneteken újrafuttatva ugyanazoknak a rekordoknak kell kijönniük. Ezért minden írás a SKU-hoz, az attribútumhoz és a prompt verziójához kötött, az újrafuttatás pedig a korábbi jelöltet cseréli le, nem fűzi hozzá.

A kimeneti séma végzi a kontroll nagy részét. Az OpenAI és az Azure strukturált kimenete szigorú módban egy megadott JSON Schema-t követ, és refusal mezőt ad vissza, ha a kérés nem teljesíthető. A támogatott részhalmaz szűkebb, mint a teljes JSON Schema: tiltja az olyan korlátozásokat, mint a pattern, format, minimum, maximum, minItems és maxItems, megköveteli, hogy minden tulajdonság szerepeljen a sémában, az additionalProperties értéke false legyen, a séma pedig legfeljebb 100 tulajdonságot és öt beágyazási szintet tartalmazhat (Microsoft Learn). Ezért a számtartományokat és a mértékegység-mintákat a kinyerés után, saját validátorral ellenőrizze. A strukturált kimenet emellett nem működik asszisztens-eszközökkel vagy saját adat használatát jelentő (bring your own data) szcenáriókkal, és ha a gazdagító lépés eszközöket is hív, a párhuzamos függvényhívásokat ki kell kapcsolni.

{
  "type": "object",
  "properties": {
    "attribute": { "type": "string", "enum": ["voltage", "ip_rating", "weight_kg"] },
    "value": { "type": "string" },
    "source_quote": { "type": "string" },
    "confidence": { "type": "string", "enum": ["high", "medium", "low"] }
  },
  "required": ["attribute", "value", "source_quote", "confidence"],
  "additionalProperties": false
}

Minden attribútumot külön, kis objektumként tartson, ne szélesre nyúló rekordként SKU-nként. Így egy hibás mező önmagában bukik meg, és a routing-döntés mezőnként hozható meg.

Az eredetmegjelölés azt rögzíti, honnan származik egy érték. Minden kiírt attribútumhoz tárolja el az értéket, a forrásdokumentumot, az idézet karakterintervallumát, a modellt és a prompt hash-ét. Egy ellenőrző vagy auditor így a termékoldaltól egyenesen az adatlap pontos mondatáig juthat el. Az alábbi rekord illusztráció, nem valódi termékadat.

{
  "sku": "SKU-1001",
  "attribute": "max_pressure_bar",
  "value": "16 bar",
  "provenance": {
    "source_doc": "datasheet-rev3.pdf",
    "char_interval": [2184, 2199],
    "model": "<model-id>",
    "prompt_hash": "sha256:9c1e...",
    "confidence": "high"
  }
}

Hogyan dönti el a megbízhatóság-alapú útválasztás, mit lát egy ember?

A megbízhatóság-alapú útválasztás minden mezőt három kimenetelük egyikébe küld: a magas megbízhatóságú, ellenőrizhető idézettel rendelkező érték automatikusan jóváhagyódik, a közepes a felülvizsgálati sorba kerül, az alacsony vagy megalapozatlan értéket pedig eldobjuk, vagy forrással együtt egy embernek mutatjuk. A döntés a mezőhöz tartozik, nem a SKU-hoz. Egy termék tizenkét attribútuma lehet automatikusan jóváhagyva, egy pedig felülvizsgálatra vár, és a felületnek ezt a megosztást kell mutatnia, nem az egyetlen bizonytalan értéket egy „jóváhagyva” jelvény mögé rejtenie.

A kétszintű változat tartja alacsonyan a költségeket. Egy olcsó kötegelt modell végigfut a teljes katalóguson. Csak az alacsony vagy közepes megbízhatóságú mezők emelkednek egy erősebb modellhez, és csak az marad bizonytalan utána, ami embert ér el. Ugyanezt a formát használom a saját munkámban is: a jev-decide skill, amelyet használok, típusos döntéseket ad megbízhatósági értékkel, és az alacsony megbízhatóságú eseteket emberhez irányítja, vagyis pontosan azt a mintát, amire egy attribútum-felülvizsgálati sornak szüksége van.

Hogyan kerül a gazdagítás a Pimcore-ba?

Az írási útnak a PIM saját API-felületén kell keresztülmennie, nem adatbázis-kerülőúton. A Pimcore Datahub a dokumentált integrációs réteg: alapértelmezésben GraphQL API, felhasználási esetenként több végponttal, az adatok átalakítását szolgáló konfigurációval, és munkaterület- és sémadefiníciókkal, amelyek korlátozzák, mit mutat az egyes végpont. Egy gazdagító szolgáltatásnál ez a korlát hasznos, mert pontosan azokat az attribútumokat engedélyezheti, amelyeket a szolgáltatás írhat, és semmi mást (Pimcore Datahub).

A Pimcore emellett automatizálást is kínál a PIM-en belül. A Copilot-műveletek aszinkron módon, a háttérben futnak, több lépésük és felhasználói bemenetük lehet, és kézzel vagy ütemezőből indíthatók. Egy feladatáttekintő lehetővé teszi a hosszú futások követését, megszakítását és újraindítását (Pimcore Copilot). Egy katalógus tömeges utólagos feltöltésénél ez az áttekintés fontosabb, mint a modell, mert a félúton elbukó futást újra kell tudni indítani.

Tömeges körre batch API-t, a napi működéshez aszinkron, objektumonkénti jobokat használjon. Ahol van batch-ár, az alábbi táblázat a standard ár felét mutatja, de a batch-jobok aszinkronok, ezért egy új SKU, amely a leírására vár, az online utat járja. Nevezze meg a felelősöket is: ki hagy jóvá egy felülvizsgálati tételt, mely attribútumok záródnak a jóváhagyás után, és mi fut újra egy promptverzió-váltáskor. Ezek munkafolyamat-döntések, és a PIM az a hely, ahol érvényesíteni kell őket.

Az olvasási oldalt, ahol ugyanez a katalógus ügyfélkérdésekre válaszol, a RAG a termékkatalógus-adatokon cikk tárgyalja, az ERP-határt pedig a Pimcore és ERP delta szinkron.

Mibe kerül az 1000 SKU gazdagítása?

A token-költség a legkisebb tétel, de az egyetlen, amelyet pontosan ki lehet számolni. Tegyük fel, hogy SKU-nként 2500 bemeneti és 500 kimeneti token van, így 1000 SKU 2,5 millió bemeneti és 0,5 millió kimeneti tokenből áll. A költség a bemeneti tokenek száma szorozva a bemeneti árral, plusz a kimeneti tokenek száma szorozva a kimeneti árral, osztva egymillióval. Az árak 2026 októberének állapotát tükrözik: a Google-árak a Gemini API árazási oldaláról származnak, a Claude- és GPT-árak pedig az OpenRouteren közzétett listaárak, nem a szolgáltatók saját oldalai.

Számolási példa: a Gemini 3.5 Flash-Lite batch módban 2,5 × 0,15 $ plusz 0,5 × 1,25 $, vagyis 1,00 $. Ugyanez a futás Claude Haiku 5.5-tel standard áron 2,5 × 0,10 $ plusz 0,5 × 0,50 $, vagyis 0,50 $. Helyettesítse be a saját token-számait, mert ez a feltevés mozgatja meg legjobban az eredményt. Ha ugyanazt a dokumentumot három körben dolgozza fel, a bemeneti oldal nagyjából a háromszorosára nő: ha minden kör a teljes 2500 bemeneti tokent küldi és a kimenet marad 500, a Claude Haiku 5.5 standard áron 0,50 $-ról 1,00 $-ra nő 1000 SKU-nként. A Gemini 3.8 Flash ára 2026. december 31-ig 0,75 $ és 3,75 $ millió tokenenként; 2027. január 1-jétől a Google 1,50 $-t és 7,50 $-t ad meg.

A valódi költség ritkán a token-számla, hanem a felülvizsgálat ideje. Ha r a felülvizsgálatra küldött mezők aránya, t pedig az egy mezőhöz szükséges percek száma, akkor a munkaidő 1000 SKU-ra 1000 × r × t perc, minden utómunka nélkül. A felülvizsgálati arány felezése általában többet ér, mint a legolcsóbb modellre váltás, ezért a routing-küszöbök ugyanannyi hangolást érdemelnek, mint a prompt.

Hogyan értékeli a gazdagítást, és hogyan működik a felülvizsgálati sor?

Egy befagyasztott aranyhalmaz SKU-halmazán értékeljen, embertől ellenőrzött értékekkel, mezőnként: attribútumonként a precision, a recall és a pontos egyezési arány, valamint annak ellenőrzése, hogy minden elfogadott értéknek van olyan idézete, amely visszaképezhető a forrásra. Az átlagok elrejtik az egyes attribútumok visszaesését, ezért attribútumonként jelentsen. Minden prompt- vagy modellváltozást futtasson le az aranyhalmazon éles bevezetés előtt, és egy attribútum visszaesése blokkolja a változtatást. A dokumentumextrakció szakirodalma segít a szakkifejezésekben: a DocILE például 6700 annotált üzleti dokumentumot és 55 annotációs osztályt tartalmaz, továbbá a tételsorok felismerését. Dokumentumai számlák és megrendelések, nem ipari adatlapok, és nem találtam ellenőrizhető, közzétett pontossági értéket adatlapokból végzett LLM-kinyerésre. A célértékeit ezért a saját aranyhalmazából állítsa be, ne egy tanulmányból (DocILE).

• A forrás látható: a kiemelt idézet a javasolt érték mellett áll, nem egy hivatkozás mögött.
• A különbség látható: a jelenlegi PIM-érték és a javasolt érték egymás mellett áll.
• Az elutasításnak van indoka: egy kattintás a „nincs a forrásban”, „rossz mértékegység”, „rossz változat” és „egyértelmű” okokra, hogy az indokok a következő értékelésbe kerüljenek.

Az elutasítások értékelési adatok az aranyhalmaz és a prompt számára, nem csak lezárt jegyek. Minden elutasítási okot vezessen vissza az értékelésbe, hogy ugyanaz a hiba ne térjen vissza.

Milyen jogi szabályok vonatkoznak az AI-val írt katalógusszövegekre?

A rövid válasz: ez attól függ, mi a szöveg, és hol jelenik meg. Ez a cikk nem jogi tanács. Az EU-ban három szabályrendszer számít a katalógusszövegek esetében; a részletkérdéseket a jogi tanácsadóval tisztázza.

Az EU AI Act 50. cikke 2026. augusztus 2-től alkalmazandó. A 4. bekezdés szerinti szövegkészítési közzétételi kötelezettség az olyan MI-generált szövegre vonatkozik, amely azzal a céllal jelenik meg, hogy a közvéleményt közérdekű ügyekről tájékoztassa. Nem alkalmazandó, ha a tartalom emberi felülvizsgálaton vagy szerkesztői ellenőrzésen ment át, és egy természetes vagy jogi személy viseli a szerkesztői felelősséget; ennek a kivételnek feltételei vannak. A saját webshop katalógusszövege nem automatikusan közérdekű tájékoztatásnak minősül, de ez a megítélés a jogi tanácsadóra tartozik, nem általános következtetés (50. cikk).

A tisztességtelen kereskedelmi gyakorlatokról szóló irányelv, amelyet a (EU) 2024/825 irányelv módosított, 2026. szeptember 27-től alkalmazandó. Kiegészíti az eleve tiltott gyakorlatok listáját, többek között az általános környezeti állításokkal, amelyek nem bizonyítják az elismert kiemelkedő környezeti teljesítményt, és a széndioxid-kibocsátás ellensúlyozásán alapuló állításokkal (EUR-Lex). Egy LLM, amely a leírást „környezetbarát” vagy „klímasemleges” szavakkal „javítja”, jogi problémát okoz, nem jobb mondatot. Rögzítse a tilalmat a promptban és a validátorban: a tiltott kifejezések listája olcsó védelem, az attribútumsémában pedig ne legyen környezeti állítás mezője, hacsak egy forrásdokumentum nem ad ilyet.

A keresési minőség a harmadik szempont. A Google spam-szabályai a kockázatot néven nevezik: skálázott tartalommal való visszaélés. Ez azt jelenti, hogy generatív MI-eszközökkel vagy hasonló eszközökkel sok oldalt hoznak létre felhasználói érték nélkül, és tartalmakat fordítanak vagy írnak át, hogy oldalakat gyártsanak sorozatban. Ennek következménye lehet az oldal szintű visszasorolás vagy kézi intézkedés. 2026 októberében a szabály már közvetlenül nevesíti a kockázatot; nagy léptékű közzététel előtt ellenőrizze az aktuális szöveget (Google Search Central). Az a gazdagítás, amely ellenőrzött attribútumokat ad hozzá, értéket teremt; az, amely ugyanezekből az attribútumokból vékony oldalakat sokszoroz, nem.

Mikor ne használjon LLM-et a gazdagításhoz?

Ne használja, ha a forrásdokumentumok nem tartalmazzák az értéket. A modell csak azt tudja megalapozni, ami le van írva; egy hiányzó adat legyen lyuk a jelentésben, ne kitalált szám. Kerülje biztonsági, orvosi vagy megfelelőségi specifikációknál, ahol a hibás érték olyan következményekkel jár, amelyeket nem lehet időben ellenőrizni. Nagyon kis katalógusoknál hagyja el, ahol egy ember gyorsabban megírja a szöveget, mint ahogy a folyamat felépülhet és értékelhető, és ha egy tisztább ERP- vagy szállítói adatfolyam előbb megoldaná a problémát. Ezek kompromisszumok, nem tiltások; a bizonyítéktesztje dönti el a legtöbbet.

Éles indítás előtt ellenőrizze ezeket:

1. Befagyasztott aranyhalmaz, attribútumonkénti célértékekkel, a katalógus gazdáival egyeztetve.
2. Megalapozottsági ellenőrzés: nincs írás idézet nélkül, amely visszaképezhető egy forrásintervallumra.
3. Séma- és tartományellenőrzés a saját kódban, nem csak a modell kimeneti módjában.
4. Mezőnkénti routing-küszöbök, az aranyhalmazon hangolva, a felülvizsgálati felülettel, amely a forrást és a különbséget mutatja.
5. Minden kiírt értékhez eredetmegjelölés, és szabály arra, mi fut újra prompt- vagy modellváltáskor.
6. Az 1000 SKU-ra jutó költség a saját token-számokkal számolva, a fenti munkaidő-képlettel egyeztetve.
7. Megfelelőségi átvilágítás az MI-jelölésről, a környezeti állításokról és a keresési szabályokról, az első nyilvános futás előtt jóváhagyva.

Ha B2B katalógushoz építi ezt, a B2B e-kereskedelmi munkám a PIM oldalt fedi le. Egy gazdagítási út csak annyira megbízható, mint a bizonyítékok, amelyeket olvas; ott kezdje.

Források

1. Google LangExtract, GitHub README (v1.6.0)
2. Anthropic: reduce hallucinations
3. Microsoft Learn: Azure OpenAI structured outputs (updated Aug 2026)
4. DocILE: document information localization and extraction (ICDAR 2023)
5. Pimcore docs: Datahub
6. Pimcore docs: Copilot
7. Google Search Central: spam policies
8. EU AI Act, Article 50 (artificialintelligenceact.eu)
9. EUR-Lex: Directive (EU) 2024/825 amending the Unfair Commercial Practices Directive
10. Google AI for Developers: Gemini API pricing
11. OpenRouter: models API (rates as listed, Oct 2026)