RAG termékkatalógusra: PIM-adatokból megbízható válaszok

A legtöbb RAG-oktatóanyag dokumentumokból indul: PDF-ekből, wikioldalakból, kézikönyvekből. A termékkatalógus más eset. Egy PIM-ben a tudás már strukturált: típusos attribútumok, mértékegységek, változatok, osztályozások, nyelvenkénti fordítások és értékesítési csatornánkénti értékek. Ha ezt szöveggé lapítod, és úgy chunkolod, mint egy kézikönyvet, éppen azt a szerkezetet dobod el, amitől a katalóguskérdések megválaszolhatók.

Ez a cikk egy katalógusasszisztens adatoldala: hogyan néznek ki a PIM-adatok, hogyan sorosítsd őket a visszakereséshez, mely kérdések tartoznak szűrőkhöz embeddingek helyett, és hogyan teszteld, hogy a válasz a helyes SKU-t nevezi meg. A szemantikus termékkeresés B2B-webshopokban cikkre épít, amely a rangsorolással foglalkozik, és feltételezi, hogy a Pimcore–ERP deltaszinkron problémái már előrébb meg vannak oldva.

Hogyan néznek ki valójában a PIM-adatok?

Vegyük példának az Akeneót. Egy termék values mezője attribútumkód szerint van kulcsolva, és minden kód locale, scope és data mezőkkel rendelkező értékobjektumok tömbjére mutat. Egy lokalizálható attribútumnak nyelvenként egy értéke van, egy csatornafüggőnek csatornánként egy, és ha mindkettő, akkor nyelv–csatorna páronként egy. A metrikus érték nem szám, hanem amount, unit és symbol mezőkből álló objektum, ahol a szimbólum a mértékegységcsaládból jön.

"values": {
  "name":        [{ "locale": "de_DE", "scope": null, "data": "Sechskantschraube DIN 933" }],
  "length":      [{ "locale": null, "scope": null,
                    "data": { "amount": "50", "unit": "MILLIMETER", "symbol": "mm" } }],
  "material":    [{ "locale": null, "scope": null, "data": "stainless_a2" }],
  "description": [{ "locale": "de_DE", "scope": "ecommerce", "data": "..." },
                  { "locale": "de_DE", "scope": "print",     "data": "..." }]
}

A változatok egy második réteget adnak hozzá. Az Akeneóban egy családváltozat egy vagy két változatszintet határoz meg, szintenként a tengelyeket, és azt, hogy mely attribútumok közösek és melyek változnak; így legfeljebb három gazdagítási szint lehet: gyökér termékmodell, al-termékmodell és változattermék. Csak a változatterméknek van SKU-ja, a termékmodellnek kódja van. A Pimcore a classification store-ral más utat jár: adattípusos kulcsok csoportokba rendezve, a csoportok objektumokhoz rendelve, opcionális lokalizációval, és mennyiségi értékekkel, amelyek egy számot egy mértékegységgel párosítanak.

Sok műszaki B2B-katalógus emellett ETIM szerint is osztályozott; a kiadó szerint ez a műszaki termékek nemzetközi osztályozási szabványa: osztályok egységes jellemzőlistával és előre meghatározott értékekkel, 17 nyelven. Az ETIM 10.0 2024 decemberében jelent meg, IXF, azaz XML formátumban. Ha a beszállítóid ETIM-adatot szállítanak, már van egy márkákon átívelő attribútumszókészleted, ami a szűrőkhöz aranyat ér.

Melyik katalóguskérdéshez milyen visszakeresés kell?

A leghasznosabb tervezési lépés az, hogy a várható kérdéseket aszerint rendezed, milyen visszakeresést igényelnek. Egy B2B-katalógusnál egészen más keverékre számíts, mint egy támogatási wikinél: sok kérdés kikeresés vagy feltétel, kevesebb a nyitott kérdés.

Az Amazon Shopping Queries adathalmaza jó hivatkozási alap a fogalmakhoz. Nagyjából 130 000 lekérdezése és 2,6 millió emberi relevanciaítélete minden lekérdezés–termék párt így címkéz: Exact (a lekérdezés minden feltételét teljesíti), Substitute (néhány szempontnak nem felel meg, de helyettesítheti), Complement (nem teljesíti a lekérdezést, de egy pontos találattal együtt használható) vagy Irrelevant. Egy katalógusasszisztensnek tudnia kell, a négy közül melyiket kínálja, és ki is kell mondania: a helyettesítő termék pontos találatként való bemutatása a klasszikus módja annak, hogy elveszítsd egy B2B-beszerző bizalmát.

Mi legyen egy dokumentum: termék, modell vagy változat?

Az első ösztön a SKU-nként egy dokumentum. Változatokat tartalmazó katalógusoknál ez a szövegindexben rosszul működik. Ugyanannak a csavarnak negyven hossza osztozik a néven, a leíráson és a legtöbb attribútumon, így egy leíró lekérdezés egyetlen termék közel azonos másolataival tölti meg a legjobb találatokat, és minden alternatívát kiszorít. Negyven szinte azonos szöveg beágyazása ráadásul tárhelyet és indexelési időt visz el haszon nélkül.

Jobban működik, ha a rekordot kettéválasztod. A szövegindexbe termékmodellenként egy dokumentum kerül, a közös attribútumokból és a változattengelyek tömör összefoglalójából, például: hossz 20–120 mm, rozsdamentes A2 és A4. A változatattribútumok strukturált payloadként élnek, vagy ugyanazon a ponton a vektortárban, vagy külön táblában a modellkód szerint. A visszakeresés jelentés alapján megtalálja a modellt, a változatot pedig szűrő vagy kikeresés választja ki. A változat nélküli egyszerű termékek önmaguk modelljei.

Hogyan lesz az attribútumokból szöveg?

A sorosító a katalógus-RAG-folyamat leginkább alábecsült része. Az embedding-modellek és az LLM-ek címkéket olvasnak, nem kódokat: a stainless_a2 és a MILLIMETER keveset mond, az Anyag: rozsdamentes acél A2 és a Hossz: 50 mm sokat. Néhány szabály, amit alkalmazok:

• Minden kódot oldj fel a címkéjére a célnyelven: attribútumnevek, választható opciók, mértékegységek a szimbólumukon keresztül.
• Válassz egy csatornát. A csatornafüggő értékek csatornánként eltérnek; a webshop-scope-ot indexeld, ne a nyomtatott katalógus szövegét.
• Nyelvenként egy szöveg, kifejezett tartalék-szabállyal, hogy egy német lekérdezés véletlenül se találjon félig angol rekordot.
• Hagyd ki az üres és a belső attribútumokat: beszerzési árak, munkafolyamat-jelzők, importidőbélyegek. Zajt okoznak, és néha kiszivárognak.
• Az azonosítók a szövegbe is kerüljenek: a SKU, az EAN és a beszállítói szám a BM25-mezőbe való, mert a felhasználók bemásolják őket.

def serialize(model, variants, locale, labels, channel="ecommerce"):
    def val(values, code):
        for v in values.get(code, []):
            if v["locale"] in (locale, None) and v["scope"] in (channel, None):
                d = v["data"]
                if isinstance(d, dict) and "amount" in d:      # metric value
                    return f'{d["amount"]} {d["symbol"]}'
                return labels.option(code, d, locale) if isinstance(d, str) else d
        return None

    lines = [f'# {val(model["values"], "name")}']
    for code in labels.common_attributes(model["family"]):
        v = val(model["values"], code)
        if v not in (None, "", []):
            lines.append(f'{labels.attribute(code, locale)}: {v}')
    # summarise the variant axes instead of repeating every variant
    for axis in labels.axes(model["family_variant"]):
        seen = sorted({str(val(x["values"], axis)) for x in variants})
        lines.append(f'{labels.attribute(axis, locale)} (variants): {", ".join(seen)}')
    lines.append("SKUs: " + " ".join(x["identifier"] for x in variants))
    return "\n".join(lines)

Hogy az attribútumokat kulcs–érték sorokként, Markdown-táblázatként vagy JSON-ként jeleníted meg, azt tesztelni kell, nem hinni. A Table Meets LLM tanulmány szerint az LLM-ek teljesítménye táblázatos feladatokon a bemeneti döntésektől, például a formátumtól és a tartalom sorrendjétől függően változott; a saját embedding-modelled és a saját lekérdezéseid döntik el, melyik formátum keresődik vissza a legjobban. Én címke: érték sorokkal kezdek, mert ezek a BM25-nek, az embeddingeknek és az LLM-nek egyaránt jók.

Miért szűrőbe valók a specifikációk, és nem embeddingbe?

Egy sűrű embedding a szöveget egy irányba tömöríti, amely azt ragadja meg, miről szól. Nem arra készült, hogy megkülönböztesse a 48 mm-t az 50 mm-től, vagy tudja, hogy a legalább 50 kizárja a 48-at. A BM25 egyezik az 50-es tokennel, de a tartományokról és a mértékegységekről ő sem tud semmit. A feltételeket ezért ki kell vonni a kérdésből, és szűrőként típusos mezőkre kell alkalmazni. A vektoradatbázisok ezt közvetlenül támogatják; a Qdrantban egy must záradék range feltétellel és gte vagy lte határokkal megoldja, a dokumentáció pedig minden szűrt mezőre payload-indexet javasol.

{
  "query": "<embedding of: stainless hex screw for outdoor use>",
  "filter": {
    "must": [
      { "key": "thread",        "match": { "value": "M8" } },
      { "key": "material",      "match": { "any": ["stainless_a2", "stainless_a4"] } },
      { "key": "length_mm",     "range": { "gte": 50 } },
      { "key": "locale",        "match": { "value": "de_DE" } }
    ]
  },
  "limit": 20
}

A szűrők kivonása egy kis LLM-hívás strukturált kimenettel: add át a modellnek a szűrhető attribútumok listáját típussal, megengedett opciókkal és kanonikus mértékegységgel, és kérj vissza egy JSON-objektumot. Utána validáld kódban. Az ismeretlen attribútumkódok kiesnek, az opcióértékeknek létezniük kell, a mértékegységeket pedig összehasonlítás előtt normalizálod, így az 5 cm-ből 50 mm lesz. Ez ugyanaz a fegyelem, mint a Text-to-SQL korlátokkal cikkben: a modell javasol, a séma dönt. Ha egy feltételt nem lehet leképezni, maradjon a szöveges lekérdezésben ahelyett, hogy csendben eltűnne, és mondd meg a felhasználónak, mely szűrők futottak.

Mi ne kerüljön soha az indexbe?

Az árak, a készlet és a szállítási határidők. B2B-webshopokban az ár gyakran ügyfélspecifikus, szerződéses árakkal, sávokkal és kedvezményekkel, a készlet pedig percről percre változik. Ezeknek az értékeknek az indexpillanatképe eleve hibás, és rosszabb esetben az egyik ügyfélnek a másik feltételeit mutatja. Ne kerüljenek se a szövegbe, se a payloadba. Ha a válaszhoz kellenek, az asszisztens a webshop ár- és elérhetőségi végpontját hívja a bejelentkezett ügyfél munkamenetével, ugyanúgy, ahogy a kirakat teszi. Ennek az eszközoldalát a MI-asszisztens B2B-webshop ügyfélszolgálathoz cikkben írtam le.

A többinél a frissesség szinkronizálási kérdés. Sorosítsd és ágyazd be újra a termékmodellt, ha bármely közös attribútuma vagy címkéje változik, és csak a payloadot frissítsd, ha egy változatattribútum változik; ez olcsó, mert nincs benne embedding. Egy megváltozott opciócímke, például egy németül átnevezett anyag, minden modellt érint, amely használja, ezért a változásérzékelést a sorosított szöveg hash-ére alapozd, ne csak a PIM módosítási időbélyegére.

Hogyan segítenek a nyelvek és az osztályozások?

A katalógusadat gyakran jobban le van fordítva, mint bármelyik wiki, mert a PIM attribútumonként kikényszeríti a fordítást. Használd ki: nyelvenként egy sorosított szöveg, lekérdezéskor nyelv szerint szűrve, dokumentált tartalékkal hiányzó fordítás esetére. Az opciók és a mértékegységek a payloadban nyelvfüggetlenek, így a szűrők németül, angolul és magyarul ugyanúgy működnek, és csak a szövegindex nyelvspecifikus. A nyelveken átívelő visszakeresés általános kompromisszumait a többnyelvű RAG német és magyar nyelvre cikk tárgyalja.

Az olyan osztályozások, mint az ETIM, egy második előnnyel is járnak. Mivel egy osztálynak egységes jellemzőlistája van, a szűrőkivonó prompt osztályonként építhető fel: ha a kérdés mondjuk egy csavarosztályhoz kötődik, csak annak jellemzői kerülnek szűrőként a modell elé. Így a prompt rövid marad, a kivont szűrők pedig érvényesek, még olyan beszállítóknál is, akiknek saját attribútumnevei eltérnek.

Hogyan teszteld a katalógusasszisztenst?

A katalógus-RAG-nek van egy előnye a dokumentum-RAG-gel szemben: az alapigazság egyértelmű. Minden tesztlekérdezéshez leírhatod a helyes SKU-kat vagy termékmodelleket, így a visszakeresés értékelése azonosítókon mért találati arány és recall@k lesz, nem szövegrészek megítélése. A készletet keresési naplókból és értékesítési kérdésekből építem fel, a fenti táblázat kérdéstípusai szerint csoportosítva, és az elvárt eredményeket ESCI-kategóriákkal címkézem, hogy egy helyettesítő ne számítson találatnak. Magukat a metrikákat a RAG értékelése cikk tárgyalja.

• Azonosító-lekérdezések: 100% pontos találatot várj; ami ennél kevesebb, az tokenizáló- vagy mezőleképezési hiba, nem modellprobléma.
• Specifikációs lekérdezések: a kivont szűrőt vesd össze egy kézzel írt elvárt szűrővel, mielőtt az eredményeket nézed.
• Hiányzó adatra vonatkozó lekérdezések: a helyes válasz a nincs megadva; a kitalált értékek hibának számítanak.
• Kereskedelmi lekérdezések: ellenőrizd, hogy az ár az élő hívásból jön, két eltérő feltételű ügyféllel tesztelve.

Hol érdemes kezdeni?

A sorosítóval és az azonosítós útvonallal kezdj, mert olcsók, és a legkínosabb hibákat tüntetik el. Utána add hozzá a szűrőkivonást ahhoz az öt–tíz attribútumhoz, amely a valódi kérdésekben a leggyakrabban szerepel, nem mindhez. Csak ezután hangold a szövegindexet, a chunkméreteket és a rerankereket. Ha a katalógusod strukturált adatokkal is megjelenik, ugyanaz az attribútumleképezés mindkettőt táplálhatja, ahogy a Schema.org strukturált adatok B2B-webshopokhoz cikkben leírtam. A mögöttes minta egyszerű: a PIM már elvégezte a termékismeret strukturálásának nehéz munkáját, egy jó katalógusasszisztens pedig ezt a szerkezetet egészen a válaszig megőrzi.

Források

1. Akeneo API: Products, product values, metric values and product models
2. Akeneo Help Center: What about products with variants?
3. Pimcore documentation: Classification Store
4. ETIM International: Classification
5. ETIM International: ETIM releases and the IXF format
6. Reddy et al.: Shopping Queries Dataset, a large-scale ESCI benchmark for improving product search (2022)
7. Amazon Science: esci-data repository
8. Qdrant documentation: Filtering
9. Sui et al.: Table Meets LLM, can large language models understand structured table data? (WSDM 2024)