Tot mai multe evaluări pentru modele AI se lovesc de aceeași întrebare incomodă: scorul mare arată capacitate reală sau doar faptul că modelul a mai „văzut” întrebările? Aici intră în joc benchmark contamination detection, adică verificarea dacă exemplele folosite la testare au ajuns, accidental sau nu, în datele de antrenare. Pentru companii, echipe tehnice și utilizatori obișnuiți, miza este simplă: fără o evaluare curată, comparațiile dintre modele pot fi înșelătoare.
Pe scurt, contaminarea apare când itemi din benchmark — întrebări, probleme de programare, rezumate, variante foarte apropiate sau reformulări — există deja în corpusul folosit la pretraining ori la etapele ulterioare de fine-tuning. Într-un astfel de caz, modelul poate răspunde prin memorare sau recunoaștere, nu neapărat prin generalizare reală. Studiile din ultimii ani arată că problema nu este doar teoretică. Un raport open-source publicat pe arXiv a identificat niveluri de contaminare între 1% și 45% pe mai multe benchmark-uri populare, în funcție de model și de setul de test analizat.
Primul pas responsabil este să definești clar ce vrei să verifici. Nu este suficient să cauți doar copii identice ale întrebărilor. Lucrarea Rethinking Benchmark and Contamination for Language Models with Rephrased Samples a arătat că metodele simple, bazate pe potrivire textuală, pot rata parafraze, traduceri sau reformulări care păstrează aceeași informație. Cu alte cuvinte, un benchmark poate părea „curat” la suprafață, dar să fie totuși foarte aproape de datele de training.
În practică, verificarea pornește de obicei cu o căutare de overlap lexical. Documentația EleutherAI pentru lm-evaluation-harness explică o metodă clasică: compararea n-gramelor dintre setul de evaluare și corpusul de antrenare. Ideea este simplă: dacă secvențe suficient de lungi de cuvinte apar în ambele locuri, exemplul devine suspect. Este o etapă utilă mai ales pentru depistarea copierilor aproape verbatim. Marele avantaj este că metoda rămâne relativ transparentă și poate fi repetată de alte echipe.
Totuși, acesta nu trebuie să fie și ultimul pas. O taxonomie publicată în 2024 despre contaminarea datelor la modelele mari de limbaj arată că există mai multe tipuri de contaminare, iar unele sunt mult mai greu de prins: copii parțiale, exemple modificate, variante sintetice sau date care păstrează structura logică fără a păstra exact aceeași formulare. De aceea, dacă verificarea se oprește la n-grame, riști să subestimezi problema și să declari prea repede că benchmark-ul este curat.
A doua verificare utilă este comparația comportamentului modelului pe itemul original versus variante-control. Aici intră metode precum PaCoST, propusă în 2024. Pe înțelesul tuturor, ideea este să creezi pentru fiecare exemplu un „dublu” cât mai apropiat ca dificultate și distribuție, apoi să compari cât de încrezător răspunde modelul. Dacă modelul este semnificativ mai sigur pe exemplul din benchmark decât pe varianta echivalentă, acesta poate fi un semnal de contaminare. Metoda nu oferă dovadă absolută, dar este mai puternică decât simpla căutare textuală.
Un al treilea pas este testarea pe reformulări controlate. Dacă un model obține scor excelent pe varianta originală, dar cade vizibil pe parafrazări, traduceri sau rescrieri care păstrează aceeași cerință, ai un indiciu că performanța inițială ar putea depinde de expunerea anterioară la acel benchmark. Acest tip de verificare este util mai ales la benchmark-uri foarte cunoscute, unde întrebările au circulat mult online și pot reapărea în corpuri de date derivate.
Mai există și o regulă sănătoasă de interpretare: nu trata un singur semnal ca verdict final. Overlap-ul mare de n-grame poate indica scurgere de date, dar poate apărea și la formulări standardizate. La fel, un model foarte încrezător nu este automat contaminat; poate pur și simplu să fie bine antrenat pe tipul respectiv de sarcină. De aceea, concluzia responsabilă se bazează pe mai multe dovezi puse împreună: overlap lexical, teste pe reformulări, diferențe de încredere și comparații cu benchmark-uri mai noi sau construite special pentru rezistență la contaminare.
Pentru echipele care evaluează modele în producție, mesajul practic este clar: păstrați separat seturile de test, documentați proveniența datelor, evitați benchmark-urile hiper-cunoscute ca unică măsură de performanță și raportați explicit dacă ați făcut decontaminare. Iar dacă nu aveți acces complet la datele de training, formula corectă nu este „benchmark-ul este curat”, ci „nu am găsit dovezi suficiente de contaminare prin metodele folosite”. În AI, această diferență de formulare contează mult.
Benchmark contamination detection nu înseamnă să „prinzi modelul copiind” cu orice preț, ci să verifici onest cât de credibilă este evaluarea. Într-un moment în care modelele par tot mai bune pe hârtie, exact această disciplină face diferența dintre marketing și măsurare reală.
Surse
- An Open Source Data Contamination Report for Large Language Models — arXiv:2310.17589
- PaCoST: Paired Confidence Significance Testing for Benchmark Contamination Detection in Large Language Models — arXiv:2406.18326
- A Taxonomy for Data Contamination in Large Language Models — arXiv:2407.08716
- Rethinking Benchmark and Contamination for Language Models with Rephrased Samples — arXiv:2311.04850
- EleutherAI lm-evaluation-harness, documentația de decontaminare
- Towards Contamination Resistant Benchmarks — arXiv:2505.08389
