RAG pentru achiziții: specificația față în față cu recepția

Comanda spune „presostat, domeniu 0–10 bar, ieșire 4–20 mA, filet G1/4”. Factura furnizorului spune „transmițător de presiune, cod 88-4412”. Pe cutia sosită în depozit e o etichetă cu un al treilea cod, tipărit de producător. Procesul-verbal de recepție, completat marți dimineață de un magaziner grăbit, spune „conform, cu observația: ieșire 0–10 V”.

Patru documente, un obiect fizic, o contradicție care nu se rezolvă singură. Cineva trebuie să decidă dacă piesa se acceptă, se acceptă cu derogare sau se returnează — iar decizia depinde de un document scris acum trei luni, într-un alt sistem, de un alt om.

Întrebarea reală într-un flux de achiziții nu e „ce cere specificația”. E „ce am cerut, ce a venit, unde diferă și cine a semnat pentru diferență” — iar cele două jumătăți ale răspunsului stau în documente cu autoritate diferită și vocabular diferit.

Ăsta e primul caz din cluster în care documentul-sursă și realitatea fizică trebuie confruntate. La licitații și achiziții publice, corpusul avea dată de expirare și întrebarea era una singură: intrăm sau nu. Aici ciclul e continuu — furnizor, comandă, livrare, recepție, plată, reclamație, din nou comandă — și se repetă de mii de ori pe an, la mii de articole. Mecanismul de bază rămâne același RAG. Ce se schimbă e că sistemul nu mai are voie să producă un singur răspuns.

Două documente care nu se pun de acord, și niciunul nu greșește

Într-un corpus de politici interne există, în principiu, o versiune corectă: cea mai nouă. Într-un flux de achiziții, nu.

Specificația are autoritate, recepția are adevărul faptic

Specificația tehnică e un document cu autoritate contractuală. E ce s-a convenit, e ce se poate pretinde și e temeiul unei reclamații. Vine din caietul de sarcini, din oferta acceptată sau dintr-o clauză a contractului-cadru — iar felul în care se indexează o clauză contractuală ca sursă a unei obligații e tratat în RAG pe contracte și documente juridice.

Documentul de recepție e altceva. Nu are autoritate contractuală, dar are ceva ce specificația nu poate avea: constatarea. Cineva a măsurat, a numărat, a citit eticheta și a scris ce a văzut. Când cele două se contrazic, contradicția nu e o eroare de date. E starea reală a unei relații comerciale la un moment dat.

Un sistem care alege între ele — fie pe recența documentului, fie pe scorul de similaritate — produce cel mai prost rezultat posibil: o afirmație unică, sigură pe ea, despre un lucru care e în litigiu.

Formularul de recepție e construit ca să țină ambele cifre

Interesant e că practica contabilă a rezolvat problema asta cu mult înainte să existe retrieval. Nota de recepție și constatare de diferențe — cod 14-3-1A în normele specifice de utilizare a documentelor financiar-contabile aprobate prin Ordinul ministrului finanțelor publice nr. 2.634/2015 — servește simultan ca document de recepție a bunurilor aprovizionate, ca document justificativ de încărcare în gestiune și ca document justificativ de înregistrare în contabilitate.

Modelul aprobat are, pentru cantitate, două rubrici distincte: una pentru cantitatea conform documentelor însoțitoare și una pentru cantitatea constatată la recepția efectivă. Nu una care o corectează pe cealaltă. Două, în paralel.

Normele merg mai departe: în situația în care se constată diferențe la recepție, entitatea stabilește prin proceduri proprii ce informații se înscriu în document — cantitatea și valoarea constatate în plus sau în minus, persoanele care au făcut recepția și alte mențiuni, în funcție de necesități. Iar întocmirea notei e obligatorie doar în anumite cazuri, printre care bunurile care prezintă diferențe la recepție și cele sosite neînsoțite de documente de livrare.

Tradus în cerință de sistem: formularul care documentează faptul are un câmp explicit pentru divergență. Indexul care îl citește trebuie să aibă și el unul.

Ce livrează un răspuns onest

Nu un verdict. Patru lucruri: ce s-a cerut, cu sursa exactă; ce s-a constatat, cu sursa exactă; unde diferă, marcat ca diferență, nu ca greșeală; și starea deciziei, dacă există una — acceptat, acceptat cu derogare, respins, în curs.

Principiile de format și de refuz sunt în cum arată un răspuns bun de RAG. Particularitatea de aici e că sinteza nu are voie să reconcilieze. Un răspuns care spune „articolul are ieșire 4–20 mA” când recepția a constatat altceva nu e o aproximare: e o afirmație pe care cineva o va folosi într-o discuție cu furnizorul.

Cinci identificatori pentru același articol și niciunul semantic

A doua particularitate e cea care rupe retrieval-ul dens mai brutal decât orice altceva din cluster.

Același obiect, cinci nume în cinci sisteme

Un articol de catalog dintr-o firmă medie poartă, simultan:

• codul intern din ERP, moștenit de la o migrare de acum șapte ani;
• SKU-ul furnizorului, cel care apare pe comandă și pe factură;
• codul producătorului, cel tipărit pe piesă și pe cutie;
• codul tarifar vamal, folosit la import și în declarații — singurul dintre cele cinci care nu se citește, ci se argumentează pe reguli;
• denumirea comercială, care diferă între catalogul furnizorului și nomenclatorul tău.

Niciunul nu e semantic. „88-4412” și „PT-100-G14” nu sunt mai apropiate între ele decât de orice alt șir alfanumeric din corpus. Embedding-ul le tratează ca zgomot, fiindcă din perspectiva unui model antrenat pe text sunt zgomot.

GTIN-ul nu e SKU-ul tău, iar Sunrise 2027 nu e o lege

Standardele GS1 par să rezolve problema, și o rezolvă parțial, dar nu în felul în care apar în materialele comerciale.

GTIN — Global Trade Item Number — e identificatorul global al articolului comercial, iar codul de bare clasic EAN/UPC îl transportă. Inițiativa Sunrise 2027 a GS1 urmărește ca, până la sfârșitul lui 2027, sistemele de casă din retail să poată citi și procesa un GTIN dintr-un cod 2D — QR cu GS1 Digital Link sau GS1 DataMatrix — pe lângă codurile 1D existente. Codul 1D nu e interzis: perioada de tranziție presupune marcare dublă, iar din 2028 folosirea exclusivă a codului 2D rămâne o opțiune, nu o obligație.

Două lucruri de reținut, fiindcă se confundă des. Primul: Sunrise 2027 e o inițiativă a unei organizații de standardizare, coordonată cu retailerii, nu un termen legal. Obligativitatea identificării prin GS1 apare doar în regimuri sectoriale specifice, nu ca regulă generală de piață. Al doilea: codurile interne de tip SKU nu sunt GTIN-uri și nu devin GTIN-uri prin simpla existență — dacă un cod nu e înregistrat sub un prefix de companie GS1 și nu trece verificarea cifrei de control, e un identificator intern, util în firmă și fără sens în afara ei.

Consecința pentru un sistem de retrieval e utilă: GS1 îți dă, în cel mai bun caz, o ancoră stabilă pentru articolele care circulă în retail. Nu îți dă maparea către codul din ERP-ul tău. Aceea rămâne o tabelă pe care o construiești și o întreții. Iar identitatea e doar temelia: ce afirmă catalogul despre articol — atribute cu unitate, descrieri comerciale, compatibilități și variante — are regulile lui proprii, tratate în RAG peste catalogul de produse.

De ce identitatea se rezolvă înaintea căutării

Regula practică e aceeași ca la echipamentele din teren, unde procedura unui model vecin e complet nefolositoare: identitatea nu poate fi o componentă a scorului de similaritate, trebuie să fie un predicat aplicat înainte. Mecanica de filtrare pe identitate e detaliată în RAG pentru mentenanță și service pe teren; ce se schimbă aici e că nu ai un singur identificator de rezolvat, ci o clasă de echivalență între cinci.

Practic:

1. Extragi toți identificatorii din documentul interogat și din întrebare, cu reguli, nu cu model — un cod are formă, iar forma se prinde lexical.
2. Îi rezolvi la un articol canonic prin tabela de echivalențe, înainte de orice căutare semantică.
3. Filtrezi corpusul pe articolul canonic, apoi cauți semantic în ce a rămas.
4. Raportezi ambiguitatea când rezolvarea eșuează, în loc să cauți pe cel mai apropiat.

De ce nu funcționează invers, e explicat pe îndelete în ce este semantic search și cum diferă de full-text: un cod alfanumeric e exact clasa de interogare pentru care potrivirea lexicală bate potrivirea de sens. Combinația celor două nu e o optimizare opțională în cazul ăsta — hybrid search și reranking descrie de ce componenta lexicală rămâne obligatorie.

Ce nu se embedează: prețul, termenul, stocul

A treia decizie de arhitectură e o linie, iar dacă o tragi greșit, sistemul minte cu încredere pe cea mai sensibilă categorie de date din firmă.

Datele operaționale se interoghează, nu se indexează

Prețul curent negociat cu un furnizor, termenul de livrare confirmat pe o comandă deschisă, stocul disponibil, lead time-ul mediu pe ultimele luni — toate au două proprietăți care le exclud din index: se schimbă mai repede decât orice ciclu de reindexare rezonabil și au o sursă unică de adevăr care le poate returna exact.

Regula generală — ce merită să intre în corpus și ce nu — e formulată în cum pregătești documentele pentru o bază de cunoștințe AI. Aplicarea la achiziții e mai dură decât în alte cazuri, pentru un motiv simplu: un preț vechi de trei luni, prezentat ca răspuns, arată identic cu un preț corect. Nu există în text niciun semnal care să-l demaște.

Aceeași disciplină pe care o cere raportarea financiară se aplică aici: cifra nu se sintetizează din documente, se citește din sistemul care o deține.

Unde trece linia

Granița nu e între „vechi” și „nou”. E între ce s-a convenit sau s-a constatat, care e un fapt documentat și nu se mai schimbă, și care e situația acum, care se schimbă în fiecare zi.

Cum arată integrarea, concret

Un răspuns util amestecă ambele surse, dar le etichetează. „Specificația din contract cere ieșire 4–20 mA (anexa 2, pagina 4). Recepția din 12 martie a constatat 0–10 V, cu observație. Prețul unitar curent, citit acum din ERP, e X, actualizat ultima dată la data Y.” Trei propoziții, trei tipuri de trasabilitate: citare de document, citare de document, apel către sistem cu marcaj temporal. Utilizatorul vede care afirmație e verificabilă cum.

Iar dacă întrebările tale sunt „câte comenzi întârziate am la furnizorul X luna asta”, răspunsul corect nu e nici document, nici apel punctual: ai nevoie de un raport peste date structurate. Pragurile de decizie sunt în când NU folosești RAG.

Istoricul unui furnizor: semnalul e distribuit, nu agregat

Întrebarea care decide o reînnoire de contract e „cum s-a comportat furnizorul ăsta”. Răspunsul nu există nicăieri ca răspuns.

Trei locuri, trei formate, niciun fir comun

Semnalul de performanță al unui furnizor stă împrăștiat în cel puțin trei locuri, scrise de trei populații diferite:

• Tichetele deschise de depozit sau de producție, telegrafice, cu vocabular de proces și fără referință la comandă.
• Rapoartele de recepție cu observații, structurate, dar cu observația în text liber la finalul formularului.
• Corespondența cu furnizorul, unde se află de fapt cauza și angajamentul de remediere — și care trăiește în inbox-uri, nu în sisteme.

Firul care le leagă nu e asemănarea lexicală, e cazul: aceeași comandă, același articol, același lot. Legătura ori o creezi la ingestie, ca relație explicită pe metadate, ori nu o ai niciodată. E aceeași lecție ca la calitate și neconformități, unde reclamația clientului și acțiunea corectivă care a rezolvat-o nu seamănă deloc ca text.

Metadatele fără care nu se poate

Pe fiecare fragment indexat: furnizorul, articolul canonic, numărul comenzii, lotul, data livrării, data constatării, tipul de neconformitate, starea și decizia. Distanța dintre livrare și constatare e cea mai subestimată — un defect prins la recepție și unul prins după două luni în producție au, aproape sigur, cauze diferite și implicații contractuale diferite.

Corpusul se schimbă continuu, deci se aplică integral mecanica de prospețime, ștergeri și reindexare: un raport anulat sau o decizie revizuită trebuie să dispară din retrieval, nu doar din sistemul-sursă.

Ce livrează sistemul și ce rămâne decizie

Coloana din dreapta rămâne la om, fiindcă e coloana cu consecințe comerciale. Un scor sintetizat din text liber pare obiectiv exact în măsura în care nimeni nu-i verifică numitorul.

Ce se întâmplă în aval — bucla de acțiune corectivă, analiza de cauză și verificarea eficacității — nu e obiectul unui sistem de achiziții. E procesul descris în RAG pentru calitate și neconformități, iar legătura corectă între cele două e o trimitere, nu o duplicare.

Due diligence în lanțul de aprovizionare: ce e efectiv în vigoare

Spațiul ăsta s-a schimbat de mai multe ori în trei ani, iar majoritatea materialelor care circulă citează termene care nu mai sunt valabile. Merită datele exacte, fiindcă din ele decurge o cerință de sistem.

Cadrul european, la iulie 2026

Directiva (UE) 2024/1760 privind diligența necesară în materie de durabilitate a intrat în vigoare pe 25 iulie 2024, apoi a fost modificată prin pachetul de simplificare Omnibus I — Directiva (UE) 2025/794 și Directiva (UE) 2026/470. A doua a fost publicată în Jurnalul Oficial pe 26 februarie 2026 și a intrat în vigoare pe 18 martie 2026.

Termenele actuale, conform Comisiei Europene: statele membre adoptă și publică măsurile naționale de transpunere până pe 26 iulie 2028 și le aplică de la 26 iulie 2029, cu excepția măsurilor de raportare din articolul 16, aplicabile exercițiilor financiare care încep de la 1 ianuarie 2030. Ghidurile principale ale Comisiei sunt așteptate până pe 26 iulie 2027.

Pragul de aplicare, după modificări: companiile din UE cu cel puțin 5.000 de angajați și o cifră de afaceri netă mondială de peste 1,5 miliarde EUR, respectiv companiile din afara UE cu o cifră de afaceri netă în UE de peste 1,5 miliarde EUR. Microîntreprinderile și IMM-urile nu intră în scop.

Dacă ești o firmă medie din România, nu ai deci o obligație directă din directiva asta. Ai, în schimb, un client care o are — și care îți va cere date.

„Informații rezonabil disponibile” e o cerință de retrieval

Modificările Omnibus I au recalibrat obligația: companiile din scop se pot concentra pe zonele unde impacturile sunt cele mai probabile și cele mai severe, pe baza informațiilor rezonabil disponibile.

Formularea pare o relaxare. Pentru un sistem de informații e opusul. „Rezonabil disponibil” înseamnă exact ce ai deja în casă și nu poți pretinde că nu știai: tichetele de la depozit, observațiile din rapoartele de recepție, corespondența în care un furnizor explică de ce a întârziat un lot. Un semnal care există în trei fișiere și nu e regăsibil e, în fața unei autorități sau a unui client, greu de descris ca indisponibil.

Limitele la cererile de informații schimbă direcția problemei

Directiva prevede măsuri de sprijin și de protecție pentru IMM-uri și pentru alți parteneri de afaceri mai mici, inclusiv limite ale cererilor de informații, ghiduri și clauze contractuale-model.

Consecința e contraintuitivă: calea ușoară — un chestionar de cincizeci de întrebări trimis fiecărui furnizor — devine explicit limitată. Ce rămâne e reconstituirea semnalului din datele pe care le ai deja. Adică fix problema din secțiunea anterioară.

Iar accesul la ele nu e uniform în firmă: cine vede corespondența comercială nu e neapărat cine vede rapoartele de recepție. Segmentarea se face la retrieval, nu în prompt — regimul e în RAG pentru conformitate și audit intern și în hubul de conformitate și audit.

Ce măsori și ce cifre nu merită încrederea

Patru indicatori pe care îi poți construi din datele tale

Rata de rezolvare a identității. Pe un eșantion de comenzi și recepții reale, în câte a legat sistemul documentul de articolul canonic corect. Se măsoară retroactiv, fără să aștepți nimic, și e metrica principală: o eroare aici invalidează tot ce urmează.

Rata de divergență detectată. Din cazurile în care specificația și recepția diferă și un om a confirmat diferența, în câte a semnalat-o sistemul. Ținta nu e detectarea automată a tuturor, e absența falsului negativ pe divergențele care au ajuns în litigiu.

Timpul până la dosarul complet. De la deschiderea unei discuții cu un furnizor până la momentul în care cineva are, într-un singur loc, ce s-a cerut, ce s-a livrat și ce s-a constatat, cu surse. E cifra pe care o simte echipa.

Rata de abținere corectă. Câte întrebări fără acoperire în corpus au primit un refuz explicit în loc de un răspuns plauzibil. Într-un flux unde răspunsul devine argument comercial, abținerea e o funcționalitate.

Metodologia de construire a setului de referință și pragurile sunt în cum evaluezi un sistem RAG. Avantajul specific aici e că adevărul de referință există deja: dosarele de reclamație închise îți spun ce era legat de ce.

Ce am omis deliberat

Spațiul „AI reduce costurile de achiziție cu X%” e integral comercial. Procentele circulă larg, aproape întotdeauna fără să afli la ce categorie de cheltuială se aplică, pe ce bază de comparație, la câte companii și măsurate cum. Nu apar aici.

Problema nu e că ar fi neapărat false, e că numitorul lipsește sistematic: „reducere de cost” poate însemna preț unitar negociat, cost total de achiziție, ore de muncă administrativă economisite sau economii evitate — patru numere care diferă de câteva ori.

Regula rămâne aceeași: caută forma originală, verifică anul, verifică numitorul. Dacă lanțul se rupe după doi pași, nu folosi cifra.

Un pilot care demonstrează ceva în șase săptămâni

Ia o singură familie de articole și un singur furnizor cu istoric bogat. Construiește tabela de echivalențe între identificatori, indexează contractele, specificațiile și rapoartele de recepție din ultimii doi ani, rulează sistemul pe cazuri deja închise.

Livrabilul nu e un chatbot. E răspunsul la o singură întrebare: din divergențele specificație-recepție pe care echipa le-a tratat anul trecut, pe câte le-ar fi găsit sistemul, cu sursele corecte? Dacă e sub jumătate, problema e la rezolvarea identității, nu la model — și e ieftin de aflat acum.

Întrebări frecvente

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

ERP-ul deține starea și tranzacțiile: comanda, recepția ca înregistrare, stocul, plata. Ce nu deține e conținutul documentelor din jurul lor — specificația din anexa 2, observația scrisă de mână pe procesul-verbal, mailul în care furnizorul acceptă o derogare. Întrebarea „ce s-a convenit exact despre toleranța asta” nu e o interogare pe care un ERP o acceptă. Stratul de retrieval nu înlocuiește ERP-ul; îl întreabă și citează documentele care nu încap în el.

Merge același sistem și pentru furnizorii de servicii?

Parțial. Structura se păstrează — există un document care stabilește ce s-a convenit și unul care constată ce s-a livrat — dar constatarea e mult mai puțin obiectivă. La un serviciu, „conform” e o judecată, nu o măsurătoare. Sistemul rămâne util pentru regăsirea angajamentului exact și a istoricului de sesizări; nu devine util pentru evaluarea calității livrării.

Ce fac dacă tabela de echivalențe între coduri nu există?

O construiești incremental, din datele pe care le ai deja: comenzile și facturile conțin, în același rând, codul tău și codul furnizorului. Câteva mii de perechi extrase automat acoperă de obicei majoritatea traficului, iar restul se completează pe măsură ce apar întrebări nerezolvate. Ce nu funcționează e amânarea proiectului până când cineva curăță tot nomenclatorul manual.

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

Echipa de achiziții, împreună cu calitatea. Corpusul se degradează în câteva luni dacă nimeni nu adaugă rapoartele de recepție noi și nu marchează deciziile de derogare, iar singurii care simt imediat consecința sunt oamenii care negociază. Un sistem de tipul ăsta întreținut de IT devine, previzibil, o arhivă.

Un RAG pentru achiziții și aprovizionare nu e un rezumator de contracte. E un mecanism de rezolvare a identității articolului, o linie clară între ce e document închis și ce se citește live din sistemele operaționale, și un răspuns care pune specificația și constatarea una lângă alta fără să le reconcilieze.

Pentru o discuție despre cum ar arăta tabela de echivalențe pe nomenclatorul 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.