RAG pentru calitate și neconformități: s-a mai întâmplat?

Reclamația de azi spune „garnitura pierde după două luni”. Raportul de neconformitate din februarie spune „etanșare deficitară pe lotul 4412”. Tichetul de service de anul trecut spune „scurgere la îmbinare, remediat pe teren”. Trei oameni, trei vocabulare, foarte probabil aceeași defecțiune — și nicio legătură între ele în niciun sistem.

Întrebarea pe care o pune inginerul de calitate când deschide o reclamație nouă nu e „ce spune procedura”. E „s-a mai întâmplat?”. De răspunsul la ea depinde dacă incidentul se închide cu o înlocuire sau escaladează într-o acțiune corectivă cu analiză de cauză-rădăcină, cu tot ce urmează după.

Ăsta e primul caz din cluster în care corpusul nu vine din afară. Nu e un set de manuale, contracte sau brevete pe care le indexezi o dată și le actualizezi rar. E produs de procesul însuși: fiecare reclamație închisă, fiecare raport de neconformitate, fiecare acțiune corectivă verificată devine document. Corpusul crește cu fiecare incident, iar utilitatea lui crește odată cu el. Dacă ai nevoie întâi de mecanica de bază, ce este RAG o acoperă.

Corpusul pe care îl scrie chiar procesul

Documentul-unitate e o înregistrare, nu un document

Un raport de neconformitate are între cincizeci și trei sute de cuvinte de text liber, înconjurate de câmpuri structurate: produs, lot, dată, client, operator, disposition, severitate. Nu e un document narativ. E o fișă.

Consecința e că problema clasică de pregătire a corpusului dispare aproape complet. Nu ai ce împărți: înregistrarea e deja mai mică decât un chunk tipic. Toată energia pe care într-o bază de cunoștințe obișnuită o consumi pe strategia de chunking se mută în altă parte — pe normalizarea vocabularului și pe metadate.

În schimb apare o problemă pe care corpusurile de documentație nu o au: aceeași defecțiune fizică e descrisă de zece operatori în zece feluri, iar niciunul nu greșește. „Zgomot la pornire”, „vibrație inițială”, „bate la demaraj” descriu, în multe cazuri, exact același simptom.

Trei tipuri de înregistrare, un singur fir

Un sistem de management al calității produce cel puțin trei familii de înregistrări, legate între ele prin proces, nu prin text:

• Reclamația — vine din exterior, în cuvintele clientului, adesea fără nomenclator de produs corect și cu detalii amestecate.
• Neconformitatea — constatată intern, cu vocabular de proces, referință la specificație și la lot.
• Acțiunea corectivă — răspunsul formal: cauza stabilită, măsura implementată, verificarea eficacității, data închiderii.

Firul care le leagă e cazul, nu asemănarea lexicală. O reclamație scrisă de client și acțiunea corectivă care a rezolvat-o nu seamănă deloc ca text — una vorbește despre „s-a udat covorul”, cealaltă despre „modificare cotă de strângere la 14 Nm”. Legătura ori o creezi la ingestie, ca relație explicită, ori nu o ai niciodată. E aceeași lecție ca la legătura dintre politică și artefactul-dovadă, pe alt tip de obiect.

Ce metadate decid dacă sistemul e util

Fără ele, orice căutare de precedent e nefolosibilă, fiindcă nu poți restrânge la ce contează: referință de produs și versiune, lot sau număr de serie, linie și schimb, furnizor al componentei incriminate, dată de fabricație și dată de apariție, canal prin care a intrat sesizarea, severitate, stare curentă.

Distanța dintre data de fabricație și data de apariție e cea mai subestimată dintre ele. Un defect care apare la două luni și unul care apare la două zile de la punerea în funcțiune au, aproape sigur, cauze diferite — chiar dacă simptomul descris e identic.

Întrebarea dominantă inversează retrievalul

Interogarea nu e o întrebare, e un incident

În toate cele nouă cazuri de până acum din cluster, tiparul a fost același: un om formulează o întrebare, sistemul caută documentul care o acoperă. Aici tiparul se rupe. Interogarea nu e o propoziție interogativă. E o înregistrare întreagă, iar căutarea se face între incidente, nu între întrebare și document.

Tehnic, asta înseamnă că textul incidentului nou devine el însuși vectorul de căutare, filtrat pe metadate înainte de similaritate: aceeași familie de produs, o fereastră de timp relevantă, eventual același furnizor. Restul e ordonare după apropiere.

Ce se strică dacă păstrezi tiparul clasic

Trei lucruri, în ordinea gravității.

Filtrul dispare. O întrebare în limbaj natural nu poartă cu ea lotul, versiunea și furnizorul. Înregistrarea le poartă. Dacă tratezi incidentul ca pe o întrebare liberă, arunci exact câmpurile care fac diferența între zece precedente relevante și trei sute de rezultate plauzibile.

Redundanța se transformă din semnal în zgomot. Dacă aceeași defecțiune a fost raportată de patruzeci de ori, primele zece rezultate vor fi zece variante ale aceleiași plângeri. Vrei gruparea lor, nu enumerarea. Aici merită un pas de deduplicare pe caz înainte de afișare: un cluster de patruzeci de incidente valorează mai mult decât patruzeci de rânduri.

Pierzi partea lexicală. Codurile de produs, numerele de lot și referințele de specificație sunt exact tipul de token pe care căutarea semantică îl tratează prost. Combinația de căutare lexicală și semantică nu e o optimizare opțională în cazul ăsta, e condiția de funcționare — mecanica e în hybrid search și reranking.

Granița față de sinteza feedbackului

Cazul cel mai apropiat din cluster e sinteza feedbackului clienților, și merită trasată granița explicit, fiindcă par același lucru și nu sunt.

Acolo, întrebarea e despre volum: ce reclamă clienții, în ce proporție, cum evoluează. Unitatea de răspuns e distribuția, iar riscul e că top-k nu e un eșantion. Aici, întrebarea e despre un caz singular: acest incident are precedente și, dacă da, care. Unitatea de răspuns e mulțimea de cazuri legate, iar riscul e altul — să ratezi legătura sau să o inventezi.

Cele două se completează. Agregarea îți spune că defecțiunea X crește; căutarea de precedent îți spune că incidentul de azi aparține lui X. Nu construi al doilea sistem cu arhitectura primului.

Normalizarea vocabularului, ca strat separat

Aici stă cea mai mare parte din muncă, și e o muncă de care nimeni nu vorbește la demo.

Trei straturi peste același text

Nu înlocui textul original. Adaugă peste el:

1. Textul brut, exact cum l-a scris operatorul sau clientul. E dovada și rămâne neatins.
2. Termenul normalizat — forma canonică a simptomului și a componentei, obținută prin clasificare automată.
3. Codul din taxonomie — identificatorul stabil pe care îl folosesc rapoartele și agregarea.

Căutarea de precedent rulează pe toate trei, cu ponderi diferite. Codul dă precizie, termenul normalizat dă acoperire, textul brut prinde formulările pe care taxonomia încă nu le cunoaște.

Taxonomia se învață din date, apoi se îngheață

Un nomenclator de defecte scris într-o ședință de trei ore, fără să te uiți la înregistrările reale, va rata majoritatea formulărilor din teren. Ordinea care funcționează e inversă: rulezi o clasificare exploratorie peste câteva mii de înregistrări istorice, vezi ce grupuri apar de fapt, abia apoi fixezi taxonomia.

După fixare, versioneaz-o. O statistică pe două versiuni de nomenclator nu e comparabilă în timp, iar comparabilitatea în timp e jumătate din valoarea sistemului.

Un prag și o coadă de „nesigur”

Clasificatorul nu trebuie să ghicească. Sub un prag de încredere, înregistrarea intră într-o coadă de revizuire umană, iar deciziile de acolo alimentează următoarea versiune a taxonomiei.

Coada asta e și metrica ta de sănătate: dacă se umflă brusc, fie a apărut un mod de defectare nou, fie s-a schimbat ceva în felul în care se scriu înregistrările. Ambele merită aflate devreme.

Cauza-rădăcină: ipoteze, nu concluzii

De ce granița e mai dură decât la audit intern

La conformitate și audit intern, un răspuns greșit devine o afirmație pe care organizația o susține în fața unui auditor. Aici e mai rău: cauza-rădăcină declarată determină acțiunea corectivă, iar acțiunea corectivă e ea însăși obiect de verificare, uneori de raportare externă. O cauză greșit atribuită înseamnă o măsură care nu rezolvă nimic, plus un dosar care spune că s-a rezolvat.

Formularea din standard e explicită. ISO 9001:2015, clauza 10.2.1, cere ca organizația, atunci când apare o neconformitate — inclusiv una provenită din reclamații — să evalueze nevoia de acțiune pentru eliminarea cauzelor, analizând neconformitatea, stabilind cauzele și determinând dacă neconformități similare există sau ar putea apărea. Clauza 10.2.2 cere păstrarea de informații documentate despre natura neconformităților, acțiunile întreprinse și rezultatele acțiunii corective.

Citește a doua oară partea cu neconformitățile similare. E, cuvânt cu cuvânt, întrebarea „s-a mai întâmplat?” — ridicată la rang de cerință. Un sistem care răspunde bine la ea nu e un ajutor opțional; e o unealtă pentru o obligație pe care o ai oricum.

O notă de dată, fiindcă e o capcană frecventă: la iulie 2026, versiunea în vigoare rămâne ISO 9001:2015, împreună cu amendamentul din 2024 privind schimbările climatice. Revizuirea e la stadiul de proiect final (FDIS), iar organismele de certificare anunță publicarea în a doua jumătate a lui 2026 — lunile diferă de la sursă la sursă, urmate de o perioadă de tranziție de aproximativ trei ani. Nu codifica versiunea în conținutul indexat; ține-o ca metadată, exact ca la orice alt corpus normativ.

Ce livrează sistemul și ce nu

Un sistem util produce trei lucruri și se oprește acolo:

Coloana din dreapta rămâne la om, fiindcă e coloana cu consecințe. Diferența nu e de politețe. Un sistem care spune „cauza probabilă e strângerea insuficientă” invită la copierea propoziției în dosar; unul care spune „unsprezece cazuri similare în ultimele nouă luni, la nouă dintre ele cauza stabilită a fost strângerea insuficientă, la două materialul garniturii” pune omul în poziția de a decide.

Precedentul vine și din afara registrului de calitate

Două surse pe care majoritatea implementărilor le ignoră, deși sunt deja indexate în alte proiecte din companie.

Istoricul de intervenții pe teren conține defecțiuni care nu au devenit niciodată reclamație formală, fiindcă tehnicianul le-a rezolvat pe loc. Modul în care se indexează e tratat în RAG pentru mentenanță și service pe teren, iar pentru un sistem de calitate e cea mai bogată sursă de semnal timpuriu.

Rezultatele negative din dezvoltare sunt a doua. Dacă o variantă de material a fost testată și respinsă acum trei ani, motivul respingerii e adesea exact ipoteza de cauză pe care o cauți. Memoria tehnică internă și felul în care se face căutabilă sunt în RAG pentru cercetare și dezvoltare.

A treia sursă, cea mai rar luată în calcul, sunt rapoartele de închidere de proiect: acolo aceeași defecțiune apare descrisă ca problemă de livrare, nu de calitate. Corpusul acela nu se consultă niciodată spontan, iar felul în care îl aduci la suprafață fără ca cineva să-l caute e în RAG pentru lecțiile învățate din proiecte.

A patra apare când investigația coboară la material: rezultatele de încercări. Sunt utile, cu o rezervă pe care merită să o ții minte — un buletin de laborator vorbește doar despre proba lui, nu despre lot și cu atât mai puțin despre furnizor.

Ceasul regulatoriu schimbă cerințele de sistem

Într-o parte din industrii, un incident nu e doar o problemă de calitate. E un obiect cu termen.

Dispozitive medicale: ceasul e în zile

Regulamentul (UE) 2017/745 privind dispozitivele medicale stabilește, la articolul 87, termene de raportare a incidentelor grave către autoritatea competentă, corelate cu gravitatea: cel târziu 15 zile de la luarea la cunoștință în cazul general, cel târziu 10 zile în caz de deces sau de deteriorare gravă neanticipată a stării de sănătate, și cel târziu 2 zile în cazul unei amenințări grave la adresa sănătății publice. Vigilența e reglementată în articolele 87-92, iar articolul 88 adaugă raportarea de tendință — creșterea semnificativă a frecvenței sau gravității incidentelor nereportabile individual.

Pentru sistemul tău, articolul 88 e cel care contează cel mai mult. Raportarea de tendință presupune că poți detecta o creștere, ceea ce presupune că incidentele sunt normalizate suficient încât să se poată număra. Fără stratul de vocabular din secțiunea anterioară, nu ai ce agrega.

ISO 13485:2016 aduce cerințe proprii de procedură documentată pentru tratarea reclamațiilor și pentru raportarea către autorități — o disciplină în plus de metadate: fiecare înregistrare trebuie să poarte decizia de reportabilitate și motivarea ei.

Produse de consum: registrul de reclamații e obligatoriu

Regulamentul (UE) 2023/988 privind siguranța generală a produselor se aplică din 13 decembrie 2024 și cere producătorilor să pună la dispoziție canale de contact pentru reclamații, să investigheze reclamațiile primite și să țină un registru intern al reclamațiilor, al produselor neconforme și al rechemărilor. Notificarea produselor periculoase și a accidentelor se face prin Safety Business Gateway, iar Safety Gate — fostul RAPEX — rămâne sistemul de alertă rapidă între autorități.

Merită reținut ce înseamnă asta: corpusul despre care vorbește articolul de față nu mai e o inițiativă internă opțională pentru producătorii care intră sub acest regulament. E o obligație legală. Diferența dintre a-l ține ca fișier și a-l ține ca sistem căutabil e diferența dintre conformitate formală și utilitate.

Ordinul de mărime al pieței, cu numitorul declarat: în raportul anual Safety Gate pentru 2025, prezentat de Comisia Europeană în martie 2026, autoritățile naționale din UE și SEE au notificat 4.671 de alerte pentru produse nealimentare periculoase — o creștere de 13% față de 2024 și cel mai mare număr de la lansarea sistemului, în 2003 — plus 5.794 de măsuri subsecvente, cu 35% mai multe decât în anul precedent. Riscurile chimice au reprezentat 53% dintre notificări.

România: traseul național al unei reclamații

Cadrul general e dat de Ordonanța Guvernului nr. 21/1992 privind protecția consumatorilor, iar Autoritatea Națională pentru Protecția Consumatorilor e instituția care primește și instrumentează sesizările. O reclamație ajunsă la autoritate devine petiție, cu termenul de răspuns prevăzut de Ordonanța Guvernului nr. 27/2002. Există și traseul de soluționare alternativă a litigiilor, pentru rezolvarea amiabilă fără instanță.

Ce contează pentru sistem: reclamația escaladată la autoritate e aceeași reclamație pe care o ai deja în registru, dar cu un ceas pe ea și cu o cerință de trasabilitate. Dacă înregistrarea internă și dosarul de răspuns trăiesc în două locuri fără legătură, reconstituirea se face manual, sub presiune de termen.

Ce nu face sistemul, în niciunul dintre regimuri

Nu decide reportabilitatea. Decizia că un incident e sau nu incident grav, cu ceasul care pornește odată cu ea, e o decizie de conformitate cu consecințe juridice. Sistemul poate semnala că un incident seamănă cu unele clasificate anterior ca reportabile, poate aduce motivările de atunci și poate atrage atenția că termenul se apropie. Atât.

Datele reclamantului: ștergere fără să pierzi statistica

O reclamație conține, aproape întotdeauna, date personale: nume, adresă, telefon, uneori informații despre sănătate. Iar dreptul la ștergere se aplică. Problema practică e că ștergerea naivă distruge exact ce ai construit.

Separă identitatea de incident la ingestie

Dacă identitatea reclamantului trăiește în același rând cu descrierea defecțiunii, o cerere de ștergere te obligă să alegi între a încălca dreptul și a pierde un caz din istoric. Dacă le separi de la început — un registru de persoane și un registru de incidente, legate printr-un identificator intern — ștergerea rupe legătura și lasă incidentul, deja lipsit de identificatori direcți, în statistică.

Fragmentul indexat nu trebuie să conțină niciodată date de identificare. Curățarea se face înainte de embedding, nu la afișare, iar regimul complet e în RAG și GDPR — aici se adaugă doar constrângerea că rezultatul curățării trebuie să rămână util pentru comparație tehnică.

Ce înseamnă efectiv „șters” într-un index

Trei nivele, care se confundă des:

• Șters din sistemul-sursă — rândul nu mai există în baza de date operațională.
• Șters din index — fragmentul nu mai poate fi regăsit. Necesită un proces propriu de reindexare, altfel supraviețuiește în vectori; mecanica e în prospețime, ștergeri și reindexare.
• Șters din copii — backup-uri, exporturi, seturi de evaluare. E nivelul pe care îl uită toată lumea și primul pe care îl verifică o autoritate.

Un detaliu cu efect direct: nu construi setul de evaluare din înregistrări reale copiate într-un fișier separat. Ține-l ca listă de identificatori care se rezolvă la rulare, ca să nu ai un al doilea corpus pe care ștergerea nu ajunge.

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

Patru indicatori care spun ceva

Rata de recunoaștere a precedentului. Pe un set de cazuri istorice despre care știi că sunt legate, în câte sistemul aduce legătura în primele cinci rezultate. E metrica principală și se construiește retroactiv, din dosare de acțiune corectivă deja închise.

Rata de fals pozitiv la grupare. Câte cazuri propuse ca similare sunt, la verificare, fără legătură. Un sistem care leagă prea mult e mai periculos decât unul care leagă prea puțin: produce ipoteze de cauză care par susținute de volum.

Acoperirea normalizării. Ce procent din înregistrările din fereastră au primit un cod de taxonomie peste prag. Sub o acoperire mare, orice raportare de tendință e nefondată.

Timpul până la primul precedent relevant. Măsurat pe cazuri reale, comparativ cu procedura manuală. E singurul indicator pe care îl înțelege și cineva din afara echipei tehnice.

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

Ce am omis deliberat

Spațiul „AI reduce timpul de rezolvare a neconformităților cu X%” e plin de cifre fără numitor. Le găsești în materiale de vendor, cu procente între 30% și 70%, fără să afli niciodată câte cazuri, la ce companii, măsurate cum și față de ce linie de bază. Nu le-am inclus, fiindcă o cifră fără numitor într-un document care ajunge într-un dosar de calitate e exact tipul de afirmație pe care un auditor o va cere susținută.

Regula, aceeași ca la orice afirmație volatilă: caută forma originală, verifică anul, verifică numitorul. Dacă lanțul se rupe după doi pași, nu o folosi.

Pilotul: o familie de produse, un istoric

Alege o singură familie de produse cu istoric bogat de reclamații, importă ultimii doi ani de înregistrări, construiește taxonomia din ele și rulează sistemul pe cazuri deja închise, la care știi răspunsul.

Livrabilul primelor șase săptămâni nu e un chatbot. E un tabel de coduri în care ai încredere și un răspuns onest la întrebarea „din cazurile pe care le-am investigat anul trecut, pe câte le-ar fi legat de precedentul corect?”. Dacă răspunsul e sub jumătate, problema e la normalizare, nu la model.

Iar dacă majoritatea întrebărilor tale sunt de tip raport recurent — aceleași cifre, în fiecare lună — concluzia corectă e că ai nevoie de raportare peste date structurate, nu de un strat de model. Pragurile de decizie sunt în când nu folosești RAG.

Întrebări frecvente

Cum tratez reclamațiile care descriu simptome, nu defecte?

Ca sursă primară, exact așa cum vin. Clientul nu are vocabular tehnic și nu trebuie să aibă. Stratul de normalizare are tocmai rolul de a lega simptomul descris de modul de defectare cunoscut, iar maparea simptom-defect se învață din cazurile în care ambele apar în același dosar închis.

Merită să indexez și reclamațiile respinse ca neîntemeiate?

Da, marcate ca atare. O reclamație respinsă de trei ori pentru același motiv e un semnal despre instrucțiuni de utilizare neclare, nu despre un defect. Ștergerea lor din corpus creează exact tipul de orbire pe care sistemul ar trebui să o corecteze.

Poate sistemul să completeze automat fișa de acțiune corectivă?

Poate propune un draft cu secțiunile care derivă din date: descrierea incidentului, cazurile similare, ce cauze s-au stabilit anterior. Nu poate completa câmpul de cauză stabilită și nici verificarea eficacității — primul e o decizie, al doilea e o constatare care cere date de după implementare.

Ce fac dacă reclamațiile vin în mai multe limbi?

Le clasifici în limba originală, cu un model care chiar o acoperă, și păstrezi limba ca metadată. Codul de taxonomie e comun, deci compararea între piețe rămâne posibilă fără traducere. Traducerea automată înainte de clasificare pierde tocmai nuanțele de descriere a simptomului.

Cât istoric îmi trebuie ca să merite?

Contează mai puțin numărul absolut de înregistrări și mai mult dacă defecțiunile se repetă. Câteva mii de înregistrări pe o familie de produse stabilă dau rezultate utile; zeci de mii pe un portofoliu care se schimbă complet la fiecare doi ani, mult mai puțin.

Începe cu ultimele treizeci de acțiuni corective închise. Verifică, pentru fiecare, dacă existau precedente în registru la momentul deschiderii și dacă cineva le-a găsit. Diferența dintre cele două cifre e valoarea sistemului, măsurată pe datele tale, înainte să indexezi ceva.

Dacă vrei să discuți cum ar arăta stratul de normalizare pe nomenclatorul tău de defecte, scrie-ne. Restul cazurilor de utilizare pe corpusuri de companie sunt în hubul Cazuri de utilizare enterprise, iar imaginea completă a serviciului în AI & RAG.