RAG peste catalogul de produse: valoarea și promisiunea

Un coleg din vânzări întreabă asistentul intern: „modelul VX-240 e rezistent la apă?”. Sistemul găsește descrierea comercială — „carcasă robustă, rezistentă la apă și praf, gândită pentru șantier” — și fișa tehnică, unde scrie IP54. Le combină elegant: „da, VX-240 este rezistent la apă (IP54)”. Clientul îl montează lângă o instalație de spălare cu jet. IP54 protejează la stropi, nu la jet.

Nimeni nu a greșit nimic în corpus. Descrierea e aprobată, fișa e corectă, retrieval-ul a adus fragmentele potrivite. Eroarea a apărut abia la sinteză, când două texte cu statut diferit au fost topite într-o singură afirmație.

Catalogul de produse e singurul corpus din serie în care aceeași entitate există simultan în patru reprezentări care nu se contrazic vizibil: atributul structurat, descrierea comercială, relația de compatibilitate și varianta. La achiziții, comparația era între ce s-a cerut și ce a venit — două documente care se contrazic pe față, iar sistemul trebuia să păstreze contradicția. Aici comparația e între ce scrie în catalog și ce e adevărat despre produs: patru texte care par să spună același lucru și nu îl spun. Mecanismul de bază rămâne același RAG. Ce se schimbă e că sursa erorii nu mai e regăsirea, ci amestecul.

Patru reprezentări ale aceluiași produs, și niciuna nu minte vizibil

Înainte de orice decizie de arhitectură, merită numit exact ce conține un catalog — fiindcă „date de produs” acoperă patru lucruri cu natură diferită.

Ce spune fiecare reprezentare și cine răspunde pentru ea

Fiecare rupe un sistem de retrieval în alt fel: atributul prin conversie tăcută, descrierea prin amestec cu specificația, compatibilitatea prin absența ei din text, varianta prin saturarea listei de rezultate. Restul articolului ia fiecare mod de eșec pe rând, cu remediul lui.

De ce lipsa contradicției e mai periculoasă decât contradicția

La specificație contra recepție, divergența e vizibilă: două documente afirmă lucruri diferite despre același obiect, iar un sistem onest o păstrează. Aici nu există divergență de păstrat. „Rezistent la apă” și „IP54” nu se contrazic — par să se confirme reciproc. Un om cu context tehnic știe că primul e o formulare comercială și al doilea o clasă de protecție măsurată după o metodă standard. Sinteza nu știe, iar textul rezultat sună mai sigur decât oricare dintre surse.

Atributul e o valoare cu unitate, nu o frază

Prima reprezentare pare cea mai sigură — e structurată, e măsurată, e scrisă de ingineri. E și cea pe care retrieval-ul semantic o strică în cel mai discret mod posibil.

Conversia tăcută

Un embedding tratează „0–10 bar” ca pe un fragment de text, nu ca pe un interval cu unitate. Consecințele sunt două, și amândouă tăcute. Prima: vecinătatea semantică nu e egalitate numerică — „0–10 bar” și „0–16 bar” sunt aproape identice ca text și incompatibile ca alegere de produs. A doua: pus să răspundă într-o altă unitate decât cea din fișă, generatorul face conversia din propriile ponderi — bar în psi, țoli în milimetri, presiune relativă confundată cu absolută — fără să semnaleze că a făcut-o și fără nicio garanție de exactitate.

E inversul problemei de la codul sursă: acolo valoarea regăsită era corectă și lipsea motivul din spatele ei. Aici motivul sună convingător — descrierea explică frumos la ce e bun produsul — iar valoarea iese dintr-o conversie pe care nimeni nu a verificat-o. Un răspuns plauzibil cu o cifră ușor greșită e mai periculos decât un refuz, fiindcă trece de orice cititor grăbit.

Modelul de date există deja: clasă, caracteristică, unitate, valoare

Pentru produse tehnice, structura corectă nu trebuie inventată. ETIM — standardul internațional de clasificare pentru produse tehnice, întreținut de ETIM International și adoptat prin organizații naționale în peste 20 de țări — definește clase de produs cu un set fix de caracteristici, fiecare cu tip declarat: alfanumeric, logic, numeric sau interval. Potrivit documentației modelului, caracteristicile numerice și de interval au obligatoriu o unitate de măsură, valorile descriptive vin din liste predefinite, nu din text liber, iar clasele, caracteristicile, valorile și unitățile au identificatori unici independenți de limbă. Versiunea 10 a modelului a fost publicată în decembrie 2024.

Consecința pentru arhitectură e directă: un atribut modelat astfel se interoghează exact — clasa X, caracteristica Y, valoarea Z, în unitatea definită — și se convertește cu o funcție, nu cu un model. Un sistem care embedează fișa tehnică în loc să interogheze modelul de atribute aruncă exact garanția pentru care modelul există.

Codul de produs se potrivește exact sau deloc

Aceeași logică se aplică identificatorilor: „88-4412” nu are vecini semantici utili, are doar potriviri exacte. Componenta lexicală a căutării rămâne obligatorie pe un corpus de catalog — hybrid search și reranking explică de ce similaritatea singură pierde exact interogările cu coduri. Iar rezolvarea identității între cele cinci coduri pe care le poartă același articol — intern, furnizor, producător, vamal, comercial — e tratată pe larg în cazul achizițiilor și rămâne o precondiție, nu o parte a căutării.

Descrierea e o promisiune, nu o specificație

A doua reprezentare e scrisă ca să convingă, nu ca să fie citată. Problema nu e că ar fi falsă — e că are alt statut.

„Rezistent la apă” și IP67 nu sunt același lucru

O clasă de protecție e o afirmație măsurată după o metodă definită, cu domeniu clar. „Rezistent la apă” e o formulare de impresie, care poate acoperi IP54, IP67 sau nimic verificabil. Câtă vreme cele două stau în texte separate, distincția supraviețuiește. Când un răspuns le topește — „da, e rezistent la apă (IP54)” — promisiunea capătă precizia specificației, iar specificația capătă generozitatea promisiunii.

În B2B, consecința nu e doar o dezamăgire: răspunsul intern ajunge în oferta trimisă clientului, iar fișa transmisă devine bază contractuală. Regimul claim-urilor aprobate — cu domeniu de valabilitate pe piață, produs și versiune — e construit în RAG pentru marketing, pe direcția generării de conținut public. Aici direcția e inversă: nu generezi copy, dar un răspuns care confundă straturile produce exact un claim neaprobat.

O parte din textul de catalog are statut legal, nu comercial

Regulamentul (UE) 2023/988 privind siguranța generală a produselor se aplică din 13 decembrie 2024, iar articolul 19 stabilește ce trebuie să conțină orice ofertă online adresată consumatorilor: numele producătorului cu adresa poștală și electronică, persoana responsabilă din UE pentru produsele fabricate în afara ei, informații de identificare a produsului — imagine, tipul produsului, orice alt identificator — plus avertismentele și informațiile de siguranță, în limba consumatorului. În noiembrie 2025, Comisia Europeană a publicat ghiduri de aplicare pentru regulament.

Pentru corpus, asta trasează o a treia categorie de text, distinctă și de atribut, și de descriere: avertismentul nu e copy și nu e caracteristică — e obligație. Lipsa lui dintr-un răspuns care descrie produsul nu e o problemă de completitudine, e una de conformitate. Fragmentele astea se marchează la ingestie ca obligatorii la afișare, nu se lasă la discreția scorului de relevanță.

Atributul care declanșează o obligație

Unele atribute nu descriu produsul — îi schimbă regimul. Codul tarifar decide taxa la import și, din 2026, apartenența la mecanismul de ajustare la frontieră pentru carbon; felul în care un astfel de cod se argumentează, nu se regăsește e un caz separat. Aceeași natură o au clasa de periculozitate a unei substanțe sau o certificare cu termen. La ingestie, atributele-declanșator se marchează ca atare: o întrebare care le atinge nu mai e o întrebare de catalog, e una de conformitate, cu alt prag de abținere.

Compatibilitatea e o relație, nu un atribut

A treia reprezentare nici măcar nu locuiește în fișa produsului. Și exact de-asta o pierde orice sistem construit doar pe text.

„Merge cu” e un graf de produse

Compatibilitatea leagă două articole canonice, cu tot ce presupune o legătură reală: accesoriul A merge pe echipamentul B, de la versiunea 2, cu adaptorul C. În text apare doar fragmentar și indirect — „compatibil cu seria K-200” — iar apartenența unui produs la seria K-200 e, la rândul ei, o relație ținută altundeva, nu o proprietate a textului. Ce pare un câmp e de fapt o rețea.

Niciun chunking nu reconstruiește graful din text

Oricum ai segmenta fișele și manualele — strategiile de chunking optimizează coerența locală a textului, nu structura dintre documente — muchiile grafului nu sunt în text. O parte stau în tabelele de compatibilitate ale furnizorilor, o parte în notele de subsol ale manualelor de instalare, o parte doar în experiența oamenilor de la suport tehnic. E lecția care revine în tot clusterul, în forma ei cea mai pură: relația se creează la ingestie, ca dată explicită între identități canonice, sau nu există deloc.

Muchia are direcție, condiție și dată

Trei proprietăți pe care textul le pierde sistematic. Direcția: accesoriul se montează pe echipament, nu invers — „compatibil” nu e simetric. Condiția: „de la firmware 2.1”, „doar cu adaptorul C” — jumătate din muchiile utile sunt condiționate. Data: revizia nouă a unui produs rupe muchii vechi fără să atingă vreun text existent. Un răspuns despre compatibilitate citează muchia cu condiția ei și cu data ultimei verificări — sau spune explicit că relația nu e documentată. „Probabil merge” nu e un răspuns; e un retur viitor.

Varianta: patruzeci de SKU-uri care saturează top-k

A patra reprezentare e o capcană pe care catalogul o întinde chiar prin felul în care e construit.

Toate sunt valide și aproape identice

Un presostat există în patruzeci de variante: același text descriptiv, aceeași fișă, un singur atribut diferit — domeniul de măsură. La codul sursă, echivalentul structural era codul mort: versiuni abandonate ale aceleiași funcții umpleau lista de rezultate. Aici e mai rău, fiindcă nimic nu e mort — toate cele patruzeci sunt în ofertă, toate la fel de „relevante” semantic pentru orice întrebare despre presostat. Top-k întoarce zece fragmente aproape identice despre zece variante diferite, iar generatorul ia valoarea din cea greșită cu deplină încredere.

Selectezi varianta înainte să cauți

Remediul nu e un retrieval mai bun, e ordinea operațiilor: varianta nu se regăsește, se selectează. Filtru structurat pe atributul diferențiator — domeniu, dimensiune, tensiune — apoi căutare în ce a rămas, de regulă un singur SKU. Modelul public de date confirmă tiparul: schema.org descrie exact această structură prin ProductGroup cu hasVariant și variesBy — grupul poartă textul comun, iar fiecare variantă poartă identificatorul propriu și atributul care o diferențiază. Potrivit documentației Google pentru Merchant Center, fiecare ofertă anotată trebuie să aibă SKU sau GTIN propriu, iar datele structurate trebuie să corespundă exact valorilor afișate utilizatorului. Structura pe care o publici oricum pentru motorul de căutare e aceeași de care are nevoie retrieval-ul intern — dacă o ai pentru unul și nu pentru celălalt, decizia e deja luată greșit.

Deduplicarea naivă șterge exact diferența

Pipeline-urile de ingestie deduplichează pe similaritate — și patruzeci de variante arată ca treizeci și nouă de duplicate. Dacă dedup-ul rulează pe text, familia de variante se prăbușește într-un singur reprezentant ales arbitrar, iar atributul care le deosebea dispare din index. Regula: dedup pe conținutul textual comun e corect și chiar dorit — un singur reprezentant pe grup — dar numai dacă atributele fiecărei variante trăiesc în stratul structurat, legate de grup. Se șterge textul repetat, niciodată identitatea.

Arhitectura: interoghezi, traversezi, abia apoi regăsești

Cele patru moduri de eșec au un singur numitor: un mecanism unic — retrieval semantic peste tot — aplicat unui corpus care cere trei mecanisme diferite.

Tabelul de decizie

Routerul care alege rândul corect e mai valoros decât orice îmbunătățire de embedding, fiindcă patru din șase rânduri nici nu ating indexul vectorial.

Standardele îți dau structura — folosește-o, nu o embeda

Dacă primești date de furnizor prin canale standardizate, separarea de care ai nevoie există deja la sursă. Rețeaua GS1 GDSN sincronizează date de produs între parteneri prin data pool-uri certificate interoperabile, cu GTIN ca identificator al articolului și GLN al partenerului, iar modelul global de date GS1 definește atributele pe patru straturi, de la cele globale obligatorii la cele locale. Un flux ETIM sau GDSN îți livrează atribute cu definiție, tip și unitate, separate de textul comercial. Prima decizie de arhitectură nu e alegerea bazei vectoriale — e să nu topești straturile astea înapoi într-un singur text de embedat. Aceeași regulă urcă o treaptă când atributul nu mai stă în modelul de date, ci pe un artefact vizual: pe desene tehnice și modele BIM, valoarea poartă și toleranță, și revizie.

Răspunsul etichetează proveniența fiecărei afirmații

Forma finală arată așa: „IP54 — atribut măsurat, din fișa tehnică. «Gândit pentru șantier» — descriere comercială. Compatibil cu K-200 de la firmware 2.1 — tabela de compatibilitate, verificată la data X.” Principiile generale de format și de refuz sunt în cum arată un răspuns bun de RAG; particularitatea catalogului e că eticheta de proveniență — măsurat, promis, relaționat — e obligatorie, nu stilistică. Prețul și stocul rămân în afara indexului și se citesc live din sistemele operaționale, cu marcaj temporal — iar prețurile concurenței sunt cu totul alt flux, extern, cu pipeline-ul lui de colectare; linia exactă dintre documentul închis și data operațională e trasă la cazul achizițiilor și nu se mută aici.

Ce măsori pe un RAG de catalog

Avantajul acestui corpus la evaluare: adevărul de referință există deja, în stratul structurat. Fișa spune care era valoarea corectă.

Patru indicatori construibili din datele tale

Exactitatea valorii cu unitate. Pe un eșantion de întrebări cu răspuns numeric cunoscut, câte răspunsuri au și valoarea, și unitatea corecte — inclusiv când întrebarea cere altă unitate decât cea din fișă. Orice conversie greșită se numără ca eșec întreg, nu ca eroare parțială: o cifră aproape corectă e forma cea mai scumpă de greșeală.

Precizia pe variantă. În câte răspunsuri valoarea provine din SKU-ul întrebat, nu dintr-o variantă vecină. Se măsoară cu filtrarea de variantă pornită și oprită — diferența dintre cele două rulări e argumentul pentru toată arhitectura.

Rata de separare promisiune–specificație. Câte răspunsuri atribuie o formulare comercială ca și cum ar fi atribut măsurat. Se auditează manual, pe eșantion; ținta e zero, fiindcă fiecare caz e un claim neaprobat în circulație.

Abținerea pe compatibilitate. La întrebări despre perechi fără muchie în graf, câte răspunsuri spun explicit că relația nu e documentată, în loc să o deducă din asemănarea textelor.

Metodologia setului de referință și pragurile sunt în cum evaluezi un sistem RAG, iar restul instrumentarului în hubul de calitate a retrieval-ului.

Ce am omis deliberat

Cifrele de tip „PIM plus AI crește conversia cu X%” sau „reduce retururile cu Y%” vin aproape integral de la furnizorii instrumentelor măsurate, fără numitor: pe ce categorie de produse, față de ce linie de bază, pe ce canal, pe ce durată. Regula rămâne cea din tot clusterul: caută forma originală, verifică anul, verifică numitorul. Dacă lanțul se rupe după doi pași, cifra nu intră nici în business case, nici aici.

Pilotul de șase săptămâni

O singură familie de produse cu variante multe și istoric de retururi. Construiește stratul de atribute — cu clasa ETIM a familiei ca schemă-țintă, dacă nu ai una proprie — și graful de compatibilitate doar pentru familia aleasă, apoi indexează separat manualele și descrierile. Rulează sistemul pe întrebările reale din tichetele de suport tehnic din ultimul an. Livrabilul e o singură cifră: din retururile cauzate de o compatibilitate presupusă sau de o rezistență promisă, câte ar fi fost prevenite de un răspuns cu proveniența etichetată. Dacă răspunsul e „puține”, problema familiei alese e altundeva — și ai aflat ieftin.

Întrebări frecvente

Nu ar trebui PIM-ul să facă asta deja?

PIM-ul deține atributele și le distribuie pe canale — e sursa de adevăr pentru stratul structurat. Ce nu face e să răspundă la întrebări care amestecă atribute, manuale, compatibilitate și descrieri. Stratul de retrieval nu înlocuiește PIM-ul: îl interoghează și îi respectă separarea. Fără un model de atribute disciplinat dedesubt, însă, primul proiect nu e de retrieval.

Pot lăsa descrierile generate cu AI să intre înapoi în corpus?

Nu. După câteva cicluri nu mai poți distinge afirmația care vine dintr-o măsurătoare de cea care s-a auto-confirmat — iar aici textul generat imită forma unei specificații, deci contaminarea e mai greu de văzut decât la conținutul de marketing. Output-ul sistemului nu e sursă.

Merge același sistem pentru produse configurabile?

Nu ca extensie. Un produs configurabil e guvernat de reguli de combinare — ce opțiuni sunt valide împreună — iar regulile se evaluează cu un motor de configurare, nu se regăsesc. Retrieval-ul rămâne util pentru documentația din jurul produsului; validarea unei configurații nu e treaba lui.

Cine ar trebui să dețină sistemul în firmă?

Echipa de date de produs sau de e-commerce, împreună cu suportul tehnic. Prima întreține stratul structurat și graful; a doua vede imediat unde greșesc răspunsurile, fiindcă primește retururile și reclamațiile. Un catalog întreținut de nimeni se degradează exact în straturile care nu se văd: muchiile de compatibilitate și datele de valabilitate.

Ce fac dacă tot ce am sunt PDF-urile furnizorilor?

Primul proiect e de extracție, nu de retrieval: alegi o schemă-țintă — clasa ETIM a familiei, dacă există — extragi atributele cu verificare umană pe eșantion și abia apoi indexezi textul rămas. Embedarea PDF-urilor ca atare produce exact amestecul descris în tot articolul, doar mai repede și cu mai multă încredere.

Un RAG peste catalogul de produse nu e un chatbot peste fișe PDF. E un strat care interoghează atributele exact, în unitatea lor, traversează compatibilitatea ca graf, selectează varianta înainte de căutare și etichetează fiecare afirmație după proveniență: măsurată, promisă sau relaționată. Când același preț unitar pleacă mai departe într-un deviz ofertă și apoi într-o decontare de execuție, eticheta de proveniență contează și mai mult: acolo aceeași cantitate ajunge să aibă cinci valori corecte simultan.

Pentru o discuție despre cum ar arăta stratul de atribute și graful de compatibilitate pe catalogul tău, trimite un mesaj. Restul cazurilor pe corpusuri de companie sunt în hubul Cazuri de utilizare enterprise, iar imaginea completă a serviciului în AI și RAG.