RAG pe polițe de asigurare: acoperirea e în excluderi

Apa a intrat prin acoperiș în noaptea de vineri. Luni dimineață cineva deschide polița clădirii și caută un singur lucru: e acoperit?

Secțiunea de acoperiri spune da. „Daune produse de fenomene atmosferice, inclusiv ploaie torențială.” Fraza e limpede, e la locul ei și e primul lucru pe care îl scoate orice căutare pusă peste document. Douăzeci și opt de pagini mai încolo, în lista de excluderi din condițiile generale, scrie că nu se despăgubesc pagubele produse prin infiltrații la construcții cu acoperișul neîntreținut. Iar într-o clauză suplimentară semnată acum doi ani, care nu e în același fișier, scrie ceva care mută răspunsul înapoi.

Toate trei propozițiile sunt în contract. Una singură decide.

Restul cazurilor din cluster au avut corpusuri în care răspunsul util e o afirmație: valoarea măsurată, obligația asumată, ipoteza consemnată. Polițele de asigurare sunt primul în care răspunsul corect e, cel mai des, o negație — și în care negația e cea mai greu de regăsit propoziție din tot documentul. Mecanica de bază e în ce este RAG; mai jos e ce se schimbă când corpusul își definește produsul prin ce refuză să facă.

Acoperirea se citește în excluderi

Întrebarea aduce paragraful greșit

„E acoperit inundația din subsol?” seamănă semantic cu paragraful care descrie acoperirea pentru inundație. Nu seamănă aproape deloc cu propoziția care contează: o frază de excludere, formulată negativ, cu un vocabular diferit — refulare, pânză freatică, apă provenită din sol — și îngropată într-o listă de patruzeci de puncte.

Retrieval-ul semantic face exact ce a fost construit să facă și scoate secțiunea de acoperire. Modelul primește un context în care scrie da, sintetizează fidel, citează corect. Răspunsul e greșit și nimic din el nu arată greșit.

Negația nu e văzută de sistemele de regăsire

Nu e o impresie de teren, e o slăbiciune măsurată. Benchmark-ul NevIR, prezentat de Orion Weller, Dawn Lawrie și Benjamin Van Durme la EACL 2024, cere modelelor de regăsire un lucru minimal: să ordoneze două documente care diferă doar prin negație. Rezultatul e că majoritatea modelelor de information retrieval nu iau negația în calcul și se comportă la fel sau mai prost decât o ordonare aleatorie; cross-encoderele ies cel mai bine, iar arhitecturile bi-encoder și sparse ies ultimele. O reproducere prezentată la SIGIR 2025 confirmă tabloul și adaugă o nuanță: rerankerele listwise bazate pe modele de limbaj se descurcă mai bine decât restul, dar rămân sub performanța umană.

Pe partea de înțelegere, CONDAQA — setul construit de Abhilasha Ravichander, Matt Gardner și Ana Marasović, publicat la EMNLP 2022 — măsoară dacă un model deduce corect implicațiile unei propoziții negate. Cel mai bun model evaluat de autori atinge 42% pe metrica lor de consistență, față de 81% performanță umană.

Concluzia practică pentru un corpus de polițe: partea lexicală nu e opțională, iar un reranking care chiar citește perechea întrebare-fragment schimbă rezultatul mai mult decât orice ajustare de embedding. Mecanica e în hybrid search și reranking.

Absența unei excluderi nu e o dovadă

Aici e regula care schimbă arhitectura. Dacă sistemul caută excluderi cu top-k și nu găsește niciuna, singurul lucru dovedit e că nu a găsit. Nu că nu există.

O întrebare de acoperire cere parcurgerea integrală a listei de excluderi aplicabile, nu cele mai apropiate cinci fragmente. E același criteriu de acceptanță ca la registrul de obligații contractuale: recall exhaustiv pe document, nu precizie medie pe interogare. Diferența e că acolo omisiunea se plătește la scadență, iar aici se plătește în ziua în care asigurătorul răspunde motivat că nu despăgubește.

Practic, lista de excluderi se extrage o dată, la ingestie, ca structură — nu se regăsește la interogare. Fiecare excludere devine o înregistrare cu condiția ei, iar întrebarea de acoperire trece prin toate, nu prin cele care sună potrivit.

Polița e un teanc cu precedență, nu un document

Patru straturi care se citesc împreună

Ce numește lumea „polița” e, în realitate, un set: condițiile generale ale produsului, condițiile speciale sau clauzele suplimentare atașate la încheiere ori la reînnoire, specificația cu datele concrete ale contractului și actele adiționale semnate ulterior. Structura se vede direct în documentele publicate de asigurători, unde clauzele suplimentare sunt definite explicit ca acoperiri opționale atașate contractului, alături de acte adiționale și alte acorduri scrise.

Straturile nu se comportă la fel. Unele adaugă acoperire peste condițiile generale. Altele adaugă excluderi proprii, iar excluderile din condițiile generale rămân aplicabile în paralel — formularea uzuală din condițiile specifice ale unor produse este că toate excluderile din articolul respectiv al condițiilor generale se aplică în mod corespunzător și condițiilor specifice. Cumulul e regula, derogarea e excepția, iar diferența dintre ele nu se deduce din text fără să știi ce strat citești.

Documentul cel mai lizibil e cel mai periculos de indexat

Documentul de informare standardizat privind produsul de asigurare — PID, în terminologia Legii nr. 236/2018 privind distribuția de asigurări — e rezumatul de una-două pagini pe care îl primește clientul înainte de încheiere. Legea îi cere să fie succint și de sine stătător, structurat cu acuratețe și fără a crea confuzii, și să cuprindă un rezumat al acoperirii cu principalele riscuri, suma asigurată, acoperirea geografică și rezumatul riscurilor excluse.

Tot legea îi cere altceva, la fel de important: PID include declarația potrivit căreia informațiile precontractuale și contractuale complete sunt furnizate în alte documente.

Un rezumat care își declară singur incompletitudinea e cel mai bun candidat pentru un răspuns fals pozitiv. E scurt, deci intră întreg într-un fragment. E scris pe înțeles, deci se potrivește lexical cu întrebarea utilizatorului. Și enumeră doar principalele excluderi. Dacă indexul îl tratează la fel cu condițiile generale, sistemul va prefera constant sursa greșită.

Regula minimă: fiecare fragment poartă stratul din care provine și rangul lui, iar un răspuns construit exclusiv pe PID se marchează ca orientativ. Tiparul e cel din normative și standarde, unde regula aplicabilă stă adesea în alt document decât cel deschis — cu deosebirea că acolo ierarhia e publicată, iar aici e o convenție a fiecărui asigurător. Iar acolo unde rangul între documente nu e nici publicat, nici convențional, ci stabilit de lege, apare un al treilea regim — tratat în RAG pe mandate și împuterniciri.

Ce se întâmplă când textul rămâne neclar

Dubiul are o regulă de tranșare, dar nu e a sistemului

Polițele sunt contracte de adeziune: textul e preredactat, clauzele esențiale sunt impuse, iar cealaltă parte alege doar să adere sau nu. Codul civil atașează acestei categorii o regulă de interpretare proprie — stipulațiile înscrise în contractele de adeziune se interpretează împotriva celui care le-a propus (art. 1269 alin. 2), aplicabilă după epuizarea celorlalte reguli de interpretare, dacă neclaritatea persistă.

Consecința pentru un sistem de întrebări e contraintuitivă. O clauză de excludere ambiguă nu produce automat un răspuns negativ; produce un litigiu în care ambiguitatea lucrează împotriva asigurătorului. Sistemul nu are cum să anticipeze rezultatul, dar poate face singurul lucru util: să semnaleze că formularea e ambiguă, în loc să aleagă tăcut una dintre citiri.

Excluderile neclare nu sunt protejate de control

La contractele cu consumatori intervine un al doilea strat. Legea nr. 193/2000 exclude din evaluarea caracterului abuziv clauzele care definesc obiectul principal al contractului și raportul preț-prestație, însă doar în măsura în care aceste clauze sunt exprimate într-un limbaj ușor inteligibil.

Excluderile definesc obiectul principal al unei polițe — sunt chiar conturul prestației. Protecția lor față de controlul caracterului abuziv atârnă, așadar, de claritatea redactării. O excludere scrisă opac nu e doar greu de regăsit; e și mai expusă juridic. Cele două probleme au aceeași cauză și se rezolvă în același loc, la redactare, nu în index.

Ce face sistemul cu un dubiu

Ambiguitatea nu se rezolvă în index, dar se poate semnala. Sistemul marchează fragmentele de excludere care conțin formulări deschise — „de regulă”, „în măsura în care”, „cu excepția cazurilor justificate” — ca necesitând decizie umană. Nu alege între două citiri posibile, ci le prezintă pe amândouă, cu clauza-sursă citată la nivel de articol, în tiparul din RAG pe contracte și documente juridice. Și nu formulează niciodată o concluzie de acoperire ca afirmație proprie: formatul de răspuns e cel din cum arată un răspuns bun de RAG, cu o singură adăugire — verbul aparține documentului, nu sistemului.

Dosarul de daună are ceas propriu

Primul ceas pornește dintr-un eveniment pe care nu îl anunță nimeni

Codul civil obligă asiguratul să comunice asigurătorului producerea riscului asigurat, în termenul prevăzut în contract (art. 2207 alin. 1). Sancțiunea e mai nuanțată decât se crede: în caz de neîndeplinire, asigurătorul are dreptul să refuze plata indemnizației dacă din acest motiv nu a putut determina cauza producerii evenimentului asigurat și întinderea pagubei. Comunicarea se poate face și către broker, care are obligația să o transmită mai departe în termenul din contract.

Reține construcția, fiindcă un sistem o simplifică aproape sigur greșit: întârzierea nu decade automat din drept, ci deschide un motiv de refuz condiționat. Un răspuns care spune „ai pierdut dreptul la despăgubire” acolo unde textul spune „asigurătorul poate refuza, dacă” e o eroare de modalitate, nu de regăsire.

Ce face ceasul acesta special față de scadențele din restul clusterului: nu pornește dintr-un document. Pornește dintr-un eveniment fizic, pe care niciun sistem nu îl înregistrează în momentul producerii. E aceeași tranziție ca la registrul de riscuri, unde o ipoteză se materializează și înregistrarea își schimbă natura — doar că aici materializarea declanșează un termen contractual care curge indiferent dacă cineva a observat-o.

Al doilea ceas e al asigurătorului

La asigurarea obligatorie de răspundere civilă auto, termenele sunt fixate prin lege și merg în sens invers. Legea nr. 132/2017 obligă asigurătorul RCA ca, în 30 de zile de la înaintarea cererii de despăgubire, fie să formuleze în scris o ofertă de despăgubire justificată, fie să notifice motivele pentru care nu a aprobat, total sau parțial, pretențiile. Despăgubirea se plătește în 10 zile de la acceptarea ofertei, iar neîndeplinirea obligațiilor atrage penalități de 0,2% pe zi de întârziere.

Există și un termen scurt ușor de ratat: dacă asigurătorul vrea să deschidă investigații, trebuie să notifice în scris în 5 zile lucrătoare de la deschiderea dosarului de daună și întocmirea procesului-verbal de constatare; necomunicarea în acest termen îl decade din dreptul respectiv. Înalta Curte a stabilit prin recurs în interesul legii (Decizia nr. 18/2023) modul de calcul al penalităților în raport cu termenul de 30 de zile.

Datele nu sunt metadate, sunt obiecte monitorizate

Pentru un sistem construit peste dosare de daună, fiecare dată din fluxul de mai jos are o consecință atașată și o sursă diferită. Niciuna nu se deduce din textul poliței.

Ce lipsește din tabel e la fel de important: data la care asiguratul a luat efectiv cunoștință de eveniment. La o avarie ascunsă sau la o pretenție formulată de un terț, ea diferă de data producerii și e adesea singurul lucru disputat. Sistemul o tratează ca pe un câmp declarat, cu sursa lui, nu ca pe un fapt.

Polița și registrul de riscuri sunt același obiect

Aceeași expunere, din două părți

O poliță nu apare din senin în arhiva unei companii. E rezultatul unei decizii de a transfera un risc altcuiva, în loc să îl reduci prin măsuri proprii sau să îl accepți. Rândul din registrul de riscuri și polița semnată descriu aceeași expunere, văzută din două părți: una din interior, cu proprietar și scadență de revizuire, cealaltă din exterior, cu limită și franșiză.

Corespondența contează acolo unde se rupe

Corespondența e utilă exact acolo unde se rupe. Suma asigurată nu e expunerea estimată în registru, iar franșiza nu apare niciodată în fișa de risc. Un risc marcat ca transferat, dar acoperit de o poliță cu o excludere care îl privește direct, rămâne, în fapt, netransferat — și e genul de contradicție pe care nimeni nu o caută, fiindcă cele două documente trăiesc în sisteme diferite și în echipe diferite.

Legătura se face pe un identificator, nu pe similaritate de text: enunțul riscului și obiectul asigurat sunt scrise în vocabulare diferite, de oameni diferiți, iar o potrivire semantică între ele produce perechi plauzibile și false. Cine deține fișa de risc și cine deține polița sunt, de regulă, tot doi oameni diferiți — ceea ce face din legătură o decizie, nu un calcul.

Verificarea de coerență între cele două corpusuri e livrabilul cel mai subestimat al unui asemenea proiect: pentru fiecare risc marcat ca transferat, există o poliță în vigoare, iar evenimentul descris în fișă nu se regăsește în lista de excluderi a poliței. Când o daună devine probabilă, discuția trece în alt referențial, cel de recunoaștere contabilă, tratat separat în RAG pentru finanțe și raportare.

Ce livrează sistemul, ce refuză și ce măsori

Unde câștigă timp

Scoate lista completă a excluderilor aplicabile unei situații descrise în cuvintele omului, cu stratul și articolul fiecăreia. E răspunsul cel mai puțin spectaculos și singurul care schimbă o discuție cu asigurătorul.

Reconstituie versiunea aplicabilă la data evenimentului, nu cea de azi — un dosar se judecă pe condițiile în vigoare atunci, iar polițele se reînnoiesc cu texte modificate. Disciplina de versionare e cea din prospețime, ștergeri și reindexare.

Și compară două polițe pe aceeași categorie de risc, la nivel de excluderi, nu de titluri de acoperire. Diferența comercială dintre două oferte stă aproape întotdeauna acolo.

Ce nu face niciodată

Nu confirmă acoperirea. Poate spune ce scrie în fiecare strat și unde apare o excludere aplicabilă; decizia rămâne a omului care își asumă răspunsul față de client sau față de asigurător.

Nu estimează cuantumul despăgubirii și nu aplică franșize pe cazuri concrete. Nu trimite notificarea de daună: e un act cu termen și cu efecte, care cere confirmare umană și dovadă de transmitere.

Și nu răspunde nimic despre un dosar de daună corporală fără filtrare de acces aplicată înainte de retrieval. Dosarele conțin date medicale, deci categorii speciale de date personale, cu regimul din RAG și GDPR și cu permisiunile din controlul accesului în RAG.

Patru cifre care spun dacă merge

Recall pe excluderi, per poliță. Din excluderile reale ale unui contract adnotat manual, câte apar în răspunsul la o întrebare de acoperire care le vizează. E metrica principală și singura care prinde modul de eșec specific corpusului.

Corectitudinea stratului citat. În ce procent din răspunsuri clauza citată provine din stratul care chiar decide, nu din PID sau dintr-o versiune expirată.

Rata de „nu pot confirma”. Un sistem sănătos refuză des. O rată apropiată de zero pe întrebări de acoperire e un semnal de alarmă, nu de calitate.

Termene ratate după implementare. Notificări transmise peste termenul din poliță, comparate cu perioada anterioară. E singura cifră pe care o citește conducerea.

Setul de referință se construiește o dată, pe 20-30 de polițe reprezentative, cu excluderile enumerate integral de un om. Metodologia generală e în cum evaluezi un sistem RAG. Iar dacă portofoliul înseamnă patru produse standard și un tabel de excluderi care încape pe o pagină, nu ai nevoie de retrieval, ci de tabelul acela pus la vedere — pragurile sunt în când nu folosești RAG.

Întrebări frecvente

Pot indexa doar condițiile generale, ca să simplific?

Nu, fiindcă exact clauzele suplimentare sunt cele care diferențiază două contracte pe același produs. Un index construit doar pe condițiile generale dă răspunsuri corecte la nivel de produs și greșite la nivel de contract, ceea ce e mai periculos decât să nu răspundă deloc.

Cum tratez polițele scanate, fără strat de text?

Cu un prag de calitate la ingestie și cu marcarea explicită a documentelor sub prag. La un corpus de excluderi, o eroare de recunoaștere care transformă o negație într-un cuvânt vecin schimbă sensul clauzei fără să lase urmă vizibilă în răspuns.

Poate sistemul să răspundă direct clientului final?

Pe întrebări de proces — ce documente trebuie depuse, în ce termen, către cine — da. Pe întrebări de acoperire, nu fără validare umană: un răspuns afirmativ dat unui client creează o așteptare pe care asigurătorul o poate infirma motivat, iar diferența ajunge în reclamație.

Cum știu ce versiune de condiții se aplică unui dosar?

Legând fiecare dosar de versiunea de condiții în vigoare la data evenimentului, nu la data întrebării, și păstrând versiunile vechi în index, marcate cu intervalul lor de valabilitate. Fără asta, un dosar de acum doi ani primește răspunsuri din textul de anul acesta.

Ce fac cu excluderile formulate prin trimitere la alt document?

Le rezolvi la ingestie, nu la interogare. O excludere care trimite la o listă de bunuri sau la un standard tehnic devine utilizabilă doar dacă lista aceea e indexată și legată de clauză; altfel sistemul citează o normă pe care nu o poate desface și lasă omul exact unde era.

Diagnosticul cel mai rapid nu se pune pe polițe, ci pe refuzuri. Pentru ultimele trei cereri respinse motivat, caută clauza pe care s-a întemeiat refuzul: în ce strat stătea, cât de departe era de secțiunea de acoperire care părea relevantă și dacă suporta o singură citire. Dacă straturile diferă de fiecare dată, problema e de structură a documentelor. Dacă textul e ambiguu de fiecare dată, e de redactare. Regăsirea e a treia pe listă și cea mai ieftină de reparat — motiv bun să nu începi cu ea.

Dacă vrei o a doua opinie pe cum ar arăta extracția excluderilor și modelul de straturi peste portofoliul tău, trimite un mesaj. Restul corpusurilor de companie, cu problemele lor specifice, sunt în hubul Cazuri de utilizare enterprise, iar serviciul întreg în AI & RAG.