RAG peste e-mail: firul, atașamentul și cine a spus ultimul

Cineva întreabă sistemul ce preț s-a agreat cu un furnizor pentru lotul din martie. Răspunsul vine cu citat dintr-un e-mail: „rămâne la 42 de lei bucata, cum am discutat” — expeditor, dată, subiect. Pare o citare curată.

Nu e. Propoziția aceea apare în index de cinci ori, fiindcă a fost citată înapoi în fiecare răspuns din fir. Sistemul a văzut cinci confirmări acolo unde a existat o singură afirmație, iar consensul aparent e un artefact de formatare.

Și prețul e greșit oricum. Cel care contează stă în grila atașată la mesajul de a doua zi, unde apare 39,50 pentru cantitatea finală. Corpul mesajului nu a fost actualizat niciodată — nimeni nu rescrie ce a scris ieri, atașează altă versiune și merge mai departe.

Un sistem de RAG peste e-mail e primul din cluster care lucrează cu o sursă adversarială față de index. Mecanismul rămâne același, dar corpusul e semi-structurat, se auto-duplică prin construcție și își ține adevărul în altă parte decât în textul pe care îl indexezi.

Unitatea nu e mesajul, ci firul

Ce se numără de mai multe ori

Un mesaj de răspuns conține, aproape întotdeauna, textul mesajului anterior. Într-un fir de opt replici, prima propoziție ajunge să existe fizic în șapte documente diferite.

Consecințele se văd în fiecare strat. La retrieval, top-k se umple cu variante ale aceluiași fragment, iar diversitatea rezultatelor scade fără ca scorul să semnaleze ceva. La generare, modelul primește aceeași frază repetată și o tratează ca pe un semnal întărit. La citare, ancora indică ultima copie, nu originalul — deci atribui unei persoane o propoziție scrisă de altcineva, cu trei zile înainte.

Ultima e cea gravă. Un citat corect ca text și greșit ca autor e mai rău decât un citat lipsă.

Firul nu e un lanț, e un arbore

Modelul mental implicit — mesaje înșirate cronologic — e fals. Un reply-all la o replică veche deschide o ramură paralelă. Cineva schimbă subiectul și rupe firul în două. Altcineva face forward către un grup nou și pornește o conversație care se întoarce, două zile mai târziu, în firul original.

Reconstrucția corectă cere anteturile Message-ID, In-Reply-To și References. Problema e că nu te poți baza pe ele: autorii corpusului Enron notează că anteturile de tip In-Reply-To apar în foarte puține mesaje din colecție, fiindcă o parte din clienții de e-mail nu le populau. Rămâne o euristică pe subiect normalizat, participanți și fereastră de timp — care greșește exact la firele lungi, adică la cele care contează.

Cât de mult e duplicat: ce arată corpusurile publice

Colecția Enron e cel mai folosit corpus public de e-mail — circa 500.000 de mesaje de la aproximativ 150 de conturi, făcute publice de FERC. Autorii ei o descriu explicit ca fiind dificilă tocmai din cauza duplicării: obiceiul de a cita mesajul original în răspuns face ca un singur mesaj să apară de zeci de ori într-un fir lung, iar orice numărătoare de cuvinte pe corpusul brut e nefolositoare.

Cifra care ilustrează scara vine din EnronSent, un sub-corpus curățat publicat de Will Styler în 2011. Pornind de la circa 96.000 de mesaje din folderele de trimise, curățarea a eliminat aproape 2,5 milioane de linii de text și a lăsat în urmă 220.500 — aproximativ 13,8 milioane de cuvinte.

Nu citi cifra ca pe un procent de citate. Curățarea aceea a scos, împreună, anteturile, secțiunile citate și forwardate, mesajele HTML și semnăturile formulare de tip disclaimer juridic, iar autorul declară că a preferat deliberat să șteargă în exces. Ordinul de mărime rămâne însă util: pe un corpus de e-mail, majoritatea liniilor nu sunt text nou scris de un om.

Nu există standard pentru tăierea citatelor

Problema are peste douăzeci de ani. Primul corpus adnotat pe zone de e-mail — semnătură și citat — a fost publicat de Carvalho și Cohen în 2004, cu 617 mesaje, iar de atunci au apărut sisteme succesive care segmentează liniile cu modele secvențiale.

În practică se folosesc biblioteci de tip talon, care combină reguli pe marcajele clienților (blocurile Gmail, -----Original Message-----, blockquote) cu clasificatoare pentru cazurile neacoperite. Cifrele publicate diverg însă spectaculos: o documentație de furnizor raportează 93,8% pe un set de 64 de mesaje reale, alta susține că același instrument recunoaște semnăturile în 25-30% din cazuri. Nici una nu declară un eșantion pe care să poți construi.

Concluzia practică nu e că uneltele nu merg. E că singura cifră relevantă se măsoară pe corespondența ta, cu clienții de e-mail folosiți efectiv în firmă, și că treizeci de mesaje adnotate manual îți spun mai mult decât orice benchmark de produs.

Ce faci concret la ingestie

Patru reguli, toate aplicate înainte de indexare.

Segmentezi mesajul în zone, nu în chunk-uri de lungime fixă: text nou, citat, semnătură, disclaimer. Doar prima zonă intră ca text principal.

Indexezi originalul, nu copia. Când un fragment apare identic în mai multe mesaje, păstrezi o singură instanță — cea mai veche — și legi restul de ea ca apariții derivate. Ancora citării trimite la autorul real.

Păstrezi citatul ca metadată, nu ca text căutabil. Fragmentul citat înapoi tot spune ceva util: la ce s-a răspuns. Îl ții ca legătură, nu ca document.

Reții disclaimerele. Blocul juridic identic din opt mii de mesaje e zgomot pur în embeddings și se elimină cu o listă de tipare, nu cu un model.

Atașamentul e sursa, mesajul e plicul

Versiunea finală circulă ca fișier

Într-o negociere, textul se stabilizează în document, nu în corpul mesajului. Oferta e un PDF, grila e un .xlsx, specificația e un .docx cu modificări urmărite. Mesajul spune, în cel mai bun caz, „atașat, cu modificările discutate”.

Un index construit doar pe corpul mesajelor răspunde deci cu ceea ce s-a spus despre document, nu cu ce scrie în el. Iar cele două se contrazic des: corpul rezumă din memorie, atașamentul e revizuit de altcineva, nimeni nu reconciliază.

Regula de rezolvare e simplă și trebuie să existe explicit: când o afirmație din corp are corespondent într-un fișier atașat, atașamentul câștigă, iar răspunsul spune care e sursa. Tratarea atașamentului ca document versionat — cu părți, dată, versiune și clauză — e problema din RAG pe contracte și documente juridice și acolo e detaliată; ce se adaugă aici e că versiunea nu vine dintr-un sistem de gestiune a documentelor, ci din ordinea mesajelor.

Același fișier, cinci copii, un nume

Un atașament trimis către șase persoane există în șase mailboxuri. Dacă indexezi per cont, îl indexezi de șase ori. Dacă cineva îl retrimite modificat sub același nume, ai două fișiere diferite cu aceeași identitate aparentă.

Deduplicarea se face pe conținut — un hash pe fișier — nu pe nume. Iar identitatea logică a documentului se reconstruiește din fir: același oferta_final.pdf în două fire diferite sunt, cel mai probabil, două documente.

Chiar și corpusurile de cercetare taie atașamentele

Merită observat unde se oprește literatura, fiindcă explică de ce găsești puțin ajutor gata făcut. Colecția Enron nu include atașamente deloc — sunt eliminate din distribuție.

Colecția Avocado, publicată de LDC în 2015 din conturile a 279 de utilizatori ai unei companii IT desființate, conține atașamente. Dar documentația ei arată că sunt redactate integral fișierele de anumite tipuri MIME, între care application/vnd.ms-excel și application/octet-stream — adică exact foile de calcul și binarele neidentificate.

Deci pe cele două corpusuri publice majore, partea care poartă cifrele fie lipsește, fie e scoasă. Orice sistem serios de RAG peste e-mail se construiește pe un pipeline propriu de extragere din atașamente, cu aceleași porți de calitate ca la orice corpus de documente — subiectul e tratat în pregătirea documentelor pentru o bază de cunoștințe.

Unde stă adevărul, pe tip de întrebare

Regula de rezolvare devine operațională doar dacă o scrii pe tipuri de întrebare. Exercițiul durează o oră cu oamenii care folosesc arhiva și decide jumătate din arhitectură.

Doar rândul al treilea e un caz în care corpul mesajului e sursa autoritativă. Ultimul nu e un caz de regăsire deloc: enumerarea completă cere extracție structurată pe tot corpusul, nu un top-k.

Permisiunea nu se derivă din mailbox

To și Cc nu sunt o listă de acces

Într-un corpus de documente, permisiunea are o sursă: dosarul, proiectul, clientul. Într-un corpus de e-mail, tentația e să folosești destinatarii — cine a fost pe To sau Cc vede firul.

Nu funcționează, în ambele sensuri. Cineva primește un forward cu tot istoricul și devine, tehnic, destinatar al unei discuții la care nu a participat. Invers, un coleg care a preluat contul unui plecat are acces la mailbox, dar nu la relația care justifica accesul.

Permisiunea trebuie deci derivată din altceva — proiect, client, departament, rol — și aplicată la nivel de fir, nu de mesaj. Modelul general e cel din controlul accesului în RAG; specificul aici e că unitatea de permisiune se calculează, nu se citește dintr-un câmp.

Un caz concret de scurgere prin regulă de redirecționare

ANSPDCP a finalizat în iunie 2025 o investigație la un operator sancționat cu 3.000 de euro și avertisment, pentru încălcări legate de monitorizarea angajaților. Între constatări: în societate se instalase, fără știrea operatorului, un filtru care retrimitea mesajele de pe o adresă de e-mail pe alta, ceea ce a dus la divulgarea unor documente ale unei persoane vizate — inclusiv documente medicale — către persoane din afara societății.

Un filtru de redirecționare. Nu un atac, nu o breșă de infrastructură. Într-un index construit peste mailboxuri, exact acest tip de regulă invizibilă mută conținut între zone de permisiune fără să lase urmă în metadate.

Relevanță și sensibilitate sunt două axe separate

Cercetarea pe regăsire în arhive de e-mail tratează deja problema explicit. Setul de test construit pe colecția Avocado și publicat la SIGIR 2020 are, pentru fiecare rezultat, două judecăți distincte: relevanța față de întrebare și sensibilitatea conținutului, evaluată prin persona a unor donatori de arhive. Cele două nu se deduc una din alta.

Pentru un sistem intern, distincția se traduce direct: un fragment poate fi perfect relevant și, în același timp, imposibil de arătat celui care a întrebat. Filtrul se aplică înainte ca modelul să vadă ceva, iar corpusul amestecă intern cu extern în același fir — un mesaj de la un client stă lipit de comentariul intern despre acel client, în același document.

Regimul juridic al accesului la e-mailul de serviciu

Testul Bărbulescu, pe scurt

Prin hotărârea Marii Camere din 5 septembrie 2017 în cauza Bărbulescu împotriva României, Curtea Europeană a Drepturilor Omului a stabilit că instrucțiunile angajatorului nu pot reduce la zero viața privată la locul de muncă și că statul nu asigurase un echilibru corect între interesele în joc.

Hotărârea a formulat criteriile pe care instanțele naționale trebuie să le verifice: dacă salariatul a fost informat prealabil despre posibilitatea monitorizării și despre natura ei; care e întinderea monitorizării și gradul de intruziune; dacă există motive legitime pentru accesul la conținutul comunicațiilor, nu doar la date de trafic; dacă era posibilă o măsură mai puțin intruzivă; care sunt consecințele pentru salariat și dacă rezultatele au fost folosite doar în scopul declarat; și dacă salariatul a beneficiat de garanții suficiente.

De la monitorizare punctuală la index permanent

Criteriile astea au fost gândite pentru o verificare punctuală, într-o procedură disciplinară. Un index căutabil peste toată corespondența companiei e altceva: e permanent, e retroactiv și transformă conținutul în ceva interogabil de oricine are dreptul de căutare.

Pe criteriul intruziunii și pe cel al măsurii mai puțin intruzive, un index general pornește cu handicap. Iar plafonul de retenție din Legea nr. 190/2018 pentru monitorizarea prin mijloace de comunicații electronice pe temeiul interesului legitim — discutat pe larg în RAG peste ședințe — se aplică pe aceeași logică.

Asta nu blochează construcția. Schimbă însă întrebarea de pornire: nu „putem indexa e-mailul?”, ci „pentru ce scop precis, pe ce fire și cu ce durată”. Regimul general de temei, informare și minimizare e cel din RAG și GDPR și nu-l reiau.

Consecințe la ingestie

Domeniu de aplicare declarat, nu implicit. Se indexează firele legate de un scop identificat — un proiect, o relație comercială, un tip de dosar — nu tot ce există în mailbox. Restul nu intră.

Excludere pe categorii, la sursă. Corespondența cu medicina muncii, cu sindicatul, cu avocatul, cea de recrutare și cea marcată personal se exclud prin regulă, nu prin filtru la afișare.

Informarea acoperă și ce se poate căuta. Nu doar faptul că mesajele se păstrează, ci că devin regăsibile semantic de către colegi, cu ce granularitate și pe ce durată.

Ștergerea ajunge până în index. Când un fir iese din retenție, dispare din stocare, din baza vectorială și din cache — mecanica e în prospețime, ștergeri și reindexare.

Care ramură a firului a rămas activă

Timestamp fiabil, întrebare deschisă

Spre deosebire de o transcriere, e-mailul are un ordin de sosire de încredere. Problema nu e când s-a spus, ci pe ce ramură.

Ultima replică în ordine cronologică poate fi un „mulțumesc” pe o ramură laterală, în timp ce decizia reală s-a luat cu două zile înainte, pe altă ramură, între alți doi participanți. Ordonarea după timp răspunde la o întrebare pe care nimeni nu a pus-o.

„Cine a spus ultimul” e deci o funcție de ordonare aplicată pe ramura corectă, nu o funcție de similaritate. Iar identificarea ramurii se face din structură — cine răspunde cui, cine s-a adăugat, unde s-a schimbat subiectul — nu din conținut.

Semnale că o ramură a murit

Trei sunt utile și ieftin de calculat: nu mai există răspunsuri de peste un prag de timp; participanții activi au migrat pe o ramură soră cu subiect modificat; a apărut un artefact care încheie discuția — o comandă, un contract semnat, un proces-verbal.

Ultimul e cel mai valoros și cel mai des ignorat. Când discuția s-a materializat într-un document, firul devine context, nu sursă. Sistemul trebuie să trimită la document și să prezinte firul ca istoric al deciziei.

Ce afișezi când firul e încă deschis

Onest: că e deschis. Un răspuns care spune „ultima poziție exprimată, pe ramura activă, la data X” e utilizabil. Unul care spune „prețul este 39,50” pentru o negociere în curs e o afirmație pe care nimeni nu și-a asumat-o.

Distincția e aceeași ca la ședințe — ce s-a spus nu e ce s-a decis — dar aici ai un avantaj: ordinea e sigură, deci poți afirma măcar care e ultima poziție. Formatul răspunsului urmează regulile din cum arată un răspuns bun de RAG.

Măsurare și pilot pentru un RAG peste e-mail

Patru indicatori care spun ceva

Rata de duplicare în top-k. Din fragmentele returnate, câte sunt copii citate ale aceluiași text. Peste un sfert înseamnă că deduplicarea nu funcționează și că rezultatele par mai bogate decât sunt.

Corectitudinea atribuirii. Din citatele afișate, în câte autorul afișat e cel care a scris efectiv propoziția, nu cel care a citat-o. E metrica specifică acestui corpus și nu apare în niciun cadru standard.

Acoperirea atașamentelor. Din întrebările al căror răspuns stă într-un fișier, în câte sistemul a citat fișierul, nu corpul mesajului.

Rata de scurgere între zone de permisiune, măsurată cu conturi de test din departamente diferite pe același set de întrebări. Un singur fragment vizibil greșit e un eșec, nu un procent.

Cadrul general rămâne cel din cum evaluezi un sistem RAG; ce se adaugă e că adevărul de referință se construiește pe fire întregi, citite de un om, nu pe fragmente izolate.

Setul de evaluare vine din firele care s-au terminat în document

Alegi treizeci de fire încheiate cu un artefact — comandă, contract, proces-verbal. Documentul final e arbitrul: pui întrebările la care el răspunde și verifici dacă sistemul ajunge acolo.

Câștigi două lucruri dintr-o trecere. Vezi dacă distinge ramura activă de cele abandonate și vezi dacă preferă atașamentul corpului mesajului.

Pilotul: un departament, un tip de relație

Alege corespondența unui singur departament pe un singur tip de relație — achiziții cu furnizori, de obicei — unde scopul e clar și participanții externi sunt puțini. Construiește segmentarea pe zone înainte de prima indexare, nu după.

Livrabilul primelor șase săptămâni e o singură cifră: din cincizeci de citate returnate, câte au autorul corect și sursa corectă. Sub patruzeci, problema e la ingestie, și acolo se duc următoarele șase săptămâni.

Dacă întrebările reale sunt aproape toate despre documente finale, e posibil să ai nevoie de un index de documente cu metadate din e-mail, nu de un RAG peste corespondență — pragurile sunt în când nu folosești RAG.

Întrebări frecvente

Pot să indexez direct arhiva de mailboxuri, fără procesare?

Poți tehnic, dar obții un sistem care se citează pe sine. Fără segmentare pe zone și fără deduplicare, majoritatea fragmentelor regăsite vor fi copii ale aceluiași text, iar atribuirea va fi greșită sistematic.

Cum tratez firele bilingve, cu clienți externi?

Ca pe un caz de comutare de cod în interiorul aceluiași fir, nu ca pe două corpusuri. Ține limba ca metadată la nivel de mesaj, nu de fir, fiindcă un fir amestecă frecvent ambele.

Ce fac cu mesajele automate — notificări, rapoarte, newslettere?

Le excluzi prin reguli, la ingestie. Sunt formulare, se repetă și strică atât embeddings-urile, cât și orice numărătoare. Un antet Auto-Submitted sau List-Id prinde majoritatea, restul se prind cu tipare pe expeditor.

Trebuie segmentat un fir în chunk-uri sau indexat întreg?

Depinde de lungime, dar unitatea logică e mesajul curățat, cu firul ca metadată de grupare. Principiile de segmentare se aplică, cu diferența că granițele sunt date de structura firului, nu alese de tine.

Ce răspund când cineva cere „toate mesajele despre X”?

Că sistemul nu poate demonstra exhaustivitatea. Regăsirea întoarce ce seamănă cu întrebarea, nu tot ce există; pentru enumerări complete ai nevoie de extracție structurată pe tot corpusul, nu de căutare semantică.

Începe cu inventarul, nu cu modelul: câte fire, ce procent din conținut e citat înapoi, câte răspunsuri stau de fapt în atașamente și cine ar avea voie să le vadă. Cu cifrele astea, discuția de fezabilitate durează o oră.

Dacă vrei să verifici dacă arhiva de corespondență a firmei suportă un index sau doar o căutare pe metadate, trimite un mesaj. Restul cazurilor pe corpusuri de companie sunt în hubul Cazuri de utilizare enterprise, iar imaginea completă a serviciului în AI & RAG.