RAG pentru due diligence: două companii, două vocabulare

Primești un link către o cameră de date. Înăuntru sunt patru mii de fișiere despre o companie pe care nu ai cumpărat-o încă. Ai trei săptămâni, un acord de confidențialitate semnat și o listă de întrebări la care consiliul așteaptă răspuns înainte de a aproba prețul. Asta e, în practică, o due diligence pe documente.

Restul clusterului a tratat corpusuri care aparțin organizației care întreabă: contractele tale, politicile tale, tichetele tale. Aici, pentru prima dată, corpusul e al altcuiva. Patru lucruri se schimbă deodată, iar fiecare rupe câte o presupunere pe care restul sistemelor o fac tacit.

Fereastra de acces e închisă și are ceas: se termină la semnare sau la respingere, deci prospețimea nu mai e problema — completitudinea e. Cele două organizații descriu aceleași obiecte cu cuvinte diferite, fără nomenclator comun și fără cine să-l arbitreze. Accesul e stratificat prin camere curate și camere de date, deci filtrarea la retrieval e obligație contractuală, nu preferință de produs. Iar întrebarea dominantă e negativă: „ce lipsește din setul primit?” — o întrebare la care absența unui document nu produce niciun scor de similaritate.

Nu e o variantă mai grea de RAG pe contracte. E alt tip de proiect, cu alt ciclu de viață și alt criteriu de acceptanță. Dacă ai nevoie întâi de mecanica generală, ce este RAG acoperă fundamentele; aici tratăm strict ce se schimbă când documentele nu sunt ale tale.

Ce se schimbă când corpusul e al altcuiva

Un sistem de regăsire peste documentația proprie presupune trei lucruri fără să le spună: că documentele se actualizează, că autorul lor e la un mesaj distanță și că indexul va exista și anul viitor. Într-o due diligence, niciuna nu e adevărată.

Prospețimea nu e problema, completitudinea e

Într-un corpus intern, dușmanul e documentul depășit care apare într-un răspuns — motiv pentru care prospețimea, ștergerile și reindexarea sunt o disciplină permanentă. Aici regimul e inversat. Ce ai primit e o fotografie la o dată anume. Nimic nu se schimbă sub tine, iar ce nu ți s-a dat nu apare niciodată de la sine.

Consecința e că metrica de calitate se mută. Nu întrebi „e la zi?”, ci „e tot?”. Un sistem care răspunde impecabil din documentele primite și tace despre cele nelivrate a livrat exact greșeala pe care o cumperi cu prețul tranzacției.

Nu poți întreba autorul

Într-un helpdesk intern, un document ambiguu se lămurește cu o întrebare pe chat. Într-o cameră de date, singurul canal e procesul formal de întrebări și răspunsuri: întrebările se depun, se numerotează, se răspund de avocații celeilalte părți și sunt uneori limitate ca număr sau ca frecvență.

Asta schimbă natura livrabilului. Ieșirea utilă a sistemului nu e mereu un răspuns pentru un analist, ci o întrebare bine formulată pentru cealaltă parte: ce document lipsește, la ce se referă, în ce anexă a listei de cereri era. Proiectează pentru asta din prima zi.

Cifrele de piață pe care nu le citez

Spațiul „AI în due diligence” e saturat de cifre de furnizor: ore economisite, procente de accelerare, cost mediu pe tranzacție. Sursele circulă între articole comerciale ca „un studiu” sau „o cercetare recentă”, fără numitor, fără eșantion, fără metodologie publicată. Câteva dintre ele apar în trei materiale diferite cu trei valori diferite.

Regula, aceeași ca peste tot în cluster: înainte să pui o cifră într-un document care ajunge la un consiliu, cere forma originală, anul și compoziția eșantionului. Dacă lipsește unul, omite cifra. Ce e verificabil în zona asta vine de la autorități și instanțe, nu de la furnizori — și e citat mai jos, la partea de acces.

Fereastra: un index de due diligence cu dată de expirare

Ciclul de viață al indexului nu e ciclul de viață al unui produs. E ciclul de viață al tranzacției, iar tranzacția are patru momente care contează pentru arhitectură.

Tot ce ai amortiza în ani, amortizezi în săptămâni

Un sistem intern își recuperează costul de construcție în doi ani de interogări. Aici ai între trei săptămâni și trei luni, iar la final indexul dispare. Orice decizie de arhitectură se judecă altfel sub constrângerea asta.

Ce nu construiești: strategie de reindexare, pipeline de OCR croit pe tipurile de document ale unei companii anume, fine-tuning pe corpus, taxonomie proprie de etichetare. Toate au perioadă de recuperare mai lungă decât tranzacția.

Ce construiești o dată și refolosești la fiecare tranzacție: schema de metadate, lista de documente așteptate, crosswalk-ul de vocabular ca șablon și setul de evaluare. Corpusul se schimbă de fiecare dată; scheletul, nu. Iar principiile generale de pregătire a documentelor rămân cele din pregătirea unei baze de cunoștințe — ce se adaugă aici e termenul.

Ștergerea e livrabil, nu igienă

Acordurile de confidențialitate cer, aproape fără excepție, returnarea sau distrugerea materialelor primite într-un termen de la încetarea discuțiilor, inclusiv a copiilor și a materialelor derivate. Un index e material derivat: text de chunk stocat lângă vectori, extracții structurate, cache de răspunsuri, jurnale de interogări.

Proiectează calea de ștergere înainte de ingestie: un spațiu de nume per tranzacție, o singură cheie de identificare, o singură operațiune de purge care acoperă vectorii, textul, extracțiile și logurile. Apoi produ o atestare scrisă a ce s-a distrus și când — exact tipul de artefact-dovadă tratat în RAG pentru conformitate și audit intern.

Un argument de evitat: „am păstrat doar embeddings-urile, nu documentele”. Vectorii sunt derivați din text și nu sunt anonimi prin construcție. Discuția asta se poartă cu juridicul înainte, nu cu auditorul după.

Două taxonomii, niciun arbitru

Aici cade partea pe care nicio alegere de model nu o repară. Două companii care fac același lucru au vocabulare interne diferite, iar diferența nu e stilistică: e de definiție.

Cazul periculos nu e cuvântul diferit

Când o parte scrie „furnizor” și cealaltă „vendor”, problema e vizibilă și se rezolvă cu un sinonim. Cazul care costă bani e același cuvânt cu granițe diferite.

„Client activ” înseamnă, la una, orice entitate cu o comandă în ultimele 24 de luni; la cealaltă, orice entitate cu un contract în vigoare. Cele două numere nu se adună și nu se compară, dar arată identic într-un tabel. „Proiect” poate fi unitatea de facturare într-o organizație și unitatea de execuție în cealaltă. „Produs” poate însemna SKU sau familie de produse, cu un ordin de mărime diferență în numărătoare.

De ce embeddings-urile nu rezolvă asta

Un model de embeddings apropie termenii care apar în contexte similare — deci chiar ajută la perechea furnizor/vendor. Exact de aceea e periculos în cazul al doilea: cele două definiții de „client activ” sunt semantic aproape identice, pasajele par reciproc relevante și ajung împreună în context, unde modelul produce o sinteză coerentă peste două numitoare diferite.

Merită delimitat de cazul multilingv. În RAG multilingv, termenul are un echivalent oficial pe fiecare piață, iar glosarul e un artefact întreținut de cineva. Aici nu există echivalent oficial, nu există glosar comun și nu există autoritate care să aprobe unul: cele două nomenclatoare sunt legitime fiecare în organizația lui, iar tranzacția poate să nici nu se închidă.

Crosswalk-ul se construiește din dovezi, nu din acord

Nu cere cuiva să decidă care definiție e corectă. Extrage definițiile din documentele care le conțin deja — secțiunile de definiții din contracte, domeniul de aplicare din politici, notele de subsol din pachetele de raportare — și consemnează relația, cu proba ei.

Fiecare rând poartă documentul și pagina unde apare definiția, plus un nivel de încredere. Termenii pentru care nu găsești nicio definiție scrisă nu se ghicesc — devin întrebări formale.

Regula de răspuns care decurge: sistemul folosește crosswalk-ul ca să extindă căutarea, dar declară în răspuns din al cărui vocabular provine pasajul citat. Nu normalizează tăcut. Formatul concret al unui răspuns care își arată sursele e în cum arată un răspuns bun de RAG; ce se adaugă aici e câmpul de organizație-sursă.

Întrebarea negativă: ce lipsește din set

O due diligence nu se termină cu ce ai găsit. Se termină cu ce nu ai găsit și cu ce nu ai cerut. Iar pentru amândouă, regăsirea semantică e unealta greșită folosită singură.

Absența nu produce scor de similaritate

Retrieval-ul întoarce ce seamănă cu întrebarea. „Nu există act adițional pentru prelungirea contractului cu distribuitorul principal” nu seamănă cu nimic, fiindcă lucrul căutat nu e acolo. Mai rău: un top-k întoarce mereu k rezultate. Un corpus complet și unul din care lipsesc trei documente materiale îți dau, amândouă, cinci pasaje plauzibile.

Limita e semnalată direct în RAG pe contracte și documente juridice: „nu apare nicio clauză de neconcurență” înseamnă tehnic „nu am regăsit una”, nu „nu există”. În corpus propriu e o notă de subsol. Într-o due diligence e chiar întrebarea.

Retrieval condus de listă, nu de întrebare

Inversează fluxul. Punctul de plecare nu e întrebarea analistului, ci lista de documente cerute — inventarul pe care l-ai trimis celeilalte părți. Pentru fiecare poziție din listă rulezi o căutare țintită, cu vocabularul extins prin crosswalk și cu filtru pe metadate, iar rezultatul se încadrează într-una din patru stări.

Ultimul rând e cel care se uită și cel mai scump. Un sistem care raportează doar despre ce a fost cerut confirmă completitudinea propriei liste, nu a corpusului.

Măsoară refuzul, nu doar răspunsul

Seturile de evaluare standard conțin aproape numai întrebări cu răspuns. Cercetătorii de la Salesforce Research au construit un cadru care sintetizează cereri fără răspuns pornind de la o bază de cunoștințe anume, tocmai fiindcă majoritatea cadrelor de evaluare măsoară acuratețea pe întrebări la care răspunsul există; observația lor e că refuzul provine adesea din incapacitatea de a regăsi context relevant, nu dintr-o recunoaștere reală că cererea nu poate fi îndeplinită.

Pentru due diligence, construiește setul invers: pleacă de la un corpus pe care îl cunoști complet — o tranzacție încheiată sau propria arhivă — scoate deliberat documente și verifică dacă sistemul spune „absent” în loc să producă o sinteză convingătoare din vecini.

Metrica de acceptanță e rata de fals-prezent: de câte ori sistemul a afirmat că ceva există pe baza unui document adiacent. Metodologia generală și construcția setului sunt în cum evaluezi un sistem RAG; pragul de decizie, dacă sistemul nu trece, e în când nu folosești RAG.

Accesul stratificat nu e o preferință de produs

În sistemele interne, segmentarea pe drepturi e o decizie de guvernanță. Într-o tranzacție, e o clauză semnată, iar încălcarea ei nu produce un incident intern, ci o expunere juridică.

Trei cercuri, nu unul

Deal team-ul cumpărătorului, consultanții externi și echipa curată văd trei felii diferite din același corpus. Informația comercial sensibilă — prețuri pe client, marje, condiții contractuale, structuri de cost — ajunge, în multe tranzacții, doar la echipa curată, iar oamenii operaționali ai cumpărătorului primesc exclusiv rezultate agregate, aprobate de avocații ambelor părți. McKinsey descrie echipa curată ca pe un corp neutru care lucrează sub protocoale stricte de confidențialitate și care poate analiza date sensibile în detaliu, urmând ca vederea agregată să fie împărtășită mai departe abia după avizul juridic al ambelor părți.

Filtrul se aplică la retrieval, nu la afișare — principiul e cel din controlul accesului în RAG, iar partea de date personale, în RAG și GDPR. Ce se adaugă aici: lista de drepturi nu o scrii tu, o citești dintr-un acord de echipă curată.

Ce iese din camera curată e un rezultat, nu un pasaj

Aici se rupe, pentru prima dată în cluster, regula citării la sursă. În interiorul echipei curate, răspunsul poartă pasajul, documentul și pagina. În afara ei, răspunsul poartă cifra agregată și trimiterea la documentul de ieșire avizat — fără pasajul de bază.

Practic, sunt două regimuri de răspuns peste același index, nu două indexuri. Un sistem care nu distinge între ele va cita, la un moment dat, o grilă de prețuri unui om care nu avea voie să o vadă, într-un răspuns perfect corect din punct de vedere factual.

Riscul juridic e mai ales al cumpărătorului

Regulamentul (CE) nr. 139/2004 impune două obligații distincte părților unei concentrări cu dimensiune europeană: notificarea prealabilă, la articolul 4 alineatul (1), și abținerea de la punerea în aplicare până la autorizare, la articolul 7 alineatul (1). Amenzile pot ajunge la 10% din cifra de afaceri totală a întreprinderilor implicate.

Cazul de referință e Altice. Comisia Europeană a aplicat în 2018 două amenzi de câte 62,25 milioane de euro, iar printre faptele reținute a fost și schimbul prematur, cu ținta, al unui volum considerabil de informații sensibile din punct de vedere concurențial. Curtea de Justiție a UE a confirmat, prin hotărârea din 9 noiembrie 2023, interpretarea largă a noțiunii de punere în aplicare și posibilitatea sancționării separate a celor două obligații, reducând însă amenda pentru neîndeplinirea obligației de notificare la 52,9 milioane de euro, pentru motivare insuficientă a cuantumului.

În România, Legea concurenței nr. 21/1996 conține o interdicție echivalentă: punerea în aplicare a unei concentrări economice este interzisă înainte de notificare și înainte de a fi declarată compatibilă printr-o decizie a Consiliului Concurenței, cu posibilitatea unei derogări motivate acordate la cerere. Atenție la citare: numerotarea articolelor s-a schimbat între republicări, așa că verifică forma consolidată în vigoare în loc să reiei un număr de articol din memorie.

Consecința directă pentru sistem: jurnalul de interogări devine el însuși probă. Cine a căutat ce, când și ce a primit înapoi e exact materialul pe care un investigator l-ar cere. Politica lui de retenție și de acces se decide înainte de prima interogare.

După semnare: două corpusuri, un singur index — mai târziu

Momentul în care tranzacția se închide pare momentul în care unifici totul. E, de obicei, cea mai proastă zi pentru asta.

Nu unifica în ziua unu

Entitatea achiziționată rămâne, adesea, persoană juridică separată, cu propriile termene de retenție, propriul regim de acces și propriile politici în vigoare. Iar contractele ei continuă să curgă cu termenele lor: obligațiile cu scadență preluate odată cu entitatea se monitorizează ca registru de obligații contractuale, nu prin interogarea corpusului. Cazul cel mai neplăcut e proiectul cu finanțare nerambursabilă aflat în perioada de durabilitate: acolo, cheltuielile țintei rămân judecabile ani după semnare, după ghidul în vigoare la data la care au fost angajate, iar corecția se calculează pe contract întreg. Iar cele două vocabulare încă înseamnă lucruri diferite: fuziunea indexurilor nu fuzionează definițiile, doar ascunde faptul că diferă.

Ține proveniența ca dimensiune de prim rang pe fiecare chunk: ce entitate a produs documentul, sub ce regim de politici și pentru ce perioadă e valabil. E aceeași disciplină ca la câmpul de piață dintr-un sistem multilingv — corpusul e eterogen prin construcție, iar pretinderea contrariului e exact ce produce răspunsuri sigure pe sine și greșite.

Crosswalk-ul devine input de migrare

Tabelul construit sub presiune de timp în timpul verificării e cel mai valoros artefact tehnic al tranzacției. E maparea de care au nevoie consolidarea datelor de bază, raportarea comună și orice proiect de sistem unificat.

Predă-l versionat, cu întrebările rămase deschise marcate ca deschise — nu curățat de incertitudini ca să arate bine într-o prezentare. Și adaugă dimensiunea temporală: până la armonizare, două politici sunt simultan în vigoare, iar un sistem care răspunde „care e politica de concediu” fără să spună pentru ce entitate și pentru ce perioadă răspunde greșit cu aparență de precizie.

Corpusul fără cititor

După integrare, arhiva de due diligence devine un depozit pe care nu-l mai interoghează nimeni. Ce s-a pierdut nu sunt documentele, ci raționamentele: de ce s-a ajustat prețul, ce risc s-a acceptat conștient, ce garanție acoperă ce. Acelea stau în memoriile analiștilor și pleacă odată cu oamenii.

E același tipar de eșec descris în RAG pentru lecțiile învățate. Remediul e ieftin și se face o singură dată, la închidere: scrie cele douăzeci de decizii cu dovada lor în corpusul pe care echipa de integrare chiar îl folosește, înainte ca echipa de tranzacție să se desființeze.

Întrebări frecvente

Merită să construiesc un sistem propriu pentru o singură tranzacție?

Rareori. Costul se justifică dacă refolosești scheletul — schema de metadate, lista de documente așteptate, setul de evaluare — pe mai multe tranzacții pe an. Sub câteva sute de documente bine denumite, un index manual plus căutare full-text rezolvă cazul la o fracțiune din efort.

Pot folosi funcțiile de AI ale camerei de date în locul unui sistem propriu?

De obicei e punctul de plecare corect, mai ales pentru prima tranzacție. Verifică trei lucruri înainte: unde se procesează documentele și cine e subîmputernicit, ce permite acordul de echipă curată în privința prelucrării automate și dacă poți exporta rezultatele. Ce trebuie să rămână al tău, indiferent de unealtă, e lista de cereri, crosswalk-ul și setul de evaluare.

Ce fac cu documentele nesemnate sau existente în mai multe versiuni?

Tratezi „nesemnat” ca stare explicită, nu ca zgomot de curățat. Într-o verificare, întrebarea e adesea chiar care versiune a fost executată, iar un sistem care alege tăcut textul cel mai curat șterge exact informația căutată. Fiecare chunk poartă versiunea, statutul de semnare și fișierul-sursă.

Cum tratez documentele în altă limbă din camera de date?

Ca pe un corpus eterogen, cu limba atașată la nivel de fragment. Diferența față de un sistem multilingv obișnuit e că aici nu există echivalent oficial de termeni: traducerea rezolvă limba, nu definiția. Un contract tradus impecabil poate folosi în continuare „client activ” cu alt numitor.

Cine răspunde dacă sistemul ratează un document material?

Echipa cumpărătorului. Ieșirea unui sistem de regăsire e un draft, iar alocarea riscului se face prin declarații, garanții și, uneori, asigurare — discuție juridică, nu tehnică. Ce ajută concret e urma: ce s-a căutat, ce s-a găsit, ce s-a cerut formal și când. Fără ea, nu poți demonstra nici măcar că ai căutat. Iar dacă acoperirea prin asigurare intră în discuție, polițele țintei se citesc după alte reguli — tratate în RAG pe polițe de asigurare și dosare de daună.

Începe cu lista, nu cu modelul. Ia inventarul de documente cerute la ultima tranzacție, marchează pentru fiecare poziție dacă a venit, dacă a venit lizibil și dacă a fost cerut în forma corectă, apoi numără câte poziții nu erau deloc pe listă. Numărul acela îți spune, în două ore, dacă problema ta e de regăsire sau de inventar — și doar una dintre ele se rezolvă cu un sistem.

Dacă ai o tranzacție în pregătire și vrei o a doua opinie pe arhitectura corpusului, trimite un mesaj. Restul cazurilor de utilizare pe corpusuri de companie sunt adunate în hub-ul Cazuri de utilizare enterprise, iar imaginea completă a serviciului — de la arhitectură la costuri — în AI & RAG.