20 la sută din toate răspunsurile web „OK” pe care le primește AI-ul nu sunt în regulă

Experimentele mele recente cu colectarea automată de date de pe web asistată de AI mi-au arătat cât de mult se închide accesul la web. Motivul acestei retrageri este, desigur, creșterea spectaculoasă a colectării automate de date de pe web cu ajutorul AI-ului, a cărei cerere necruțătoare de date noi poate ajunge să scoată domenii din funcțiune.

Acesta este un bun prilej pentru domenii să facă ceea ce multe dintre ele și-au dorit de multă vreme: să-și facă conținutul accesibil numai utilizatorilor autentificați (deși, firește, Googlebot beneficiază de obicei de acces nerestricționat). Facebook a încheiat adoptarea treptată a acestei politici în 2023, iar Twitter/X a făcut același lucru în același an. Reddit o va adopta mai târziu în această lună.

Astfel, domeniului îi este puțin mai ușor să respecte cerințele specifice fiecărei țări privind aplicarea restricțiilor de vârstă, deoarece utilizatorul este deja înregistrat. Mai important, datele utilizatorului pot fi salvate, folosite pentru analize locale și — dacă legislația locală permite — vândute brokerilor de date și companiilor de AI.

În alte părți, măsurile destinate în mod direct protejării împotriva boților (și nu înregistrării utilizatorilor) au crescut cu peste 58% de la an la an, potrivit Cloudflare; iar toată această intensificare a activității boților încurajează, în mod firesc, site-urile să verifice cu mai multă atenție adresele VPN și ale serverelor proxy, ceea ce le-ar putea refuza accesul utilizatorilor legitimi, alături de traficul „rău intenționat”.

Partea anecdotică este că par să mă lovesc tot mai des de răspunsuri de „blocare” sau de provocări, până într-acolo încât s-ar putea chiar să renunț la un site care începe să le afișeze; iar dacă s-a constatat că pereții CAPTCHA îi descurajează pe utilizatori și pe potențialii clienți, ne putem imagina presiunea care îi determină pe proprietarii domeniilor să-i implementeze, în ciuda acestui dezavantaj.

O provocare CAPTCHA de la archive.is, unul dintre numeroasele site-uri care au adoptat astfel de provocări, adesea ca răspuns la un număr excesiv de solicitări automate (și nu umane).

Toate aceste noi obstacole și intensificarea celor existente sunt parțial de natură logistică (deoarece nu toate domeniile pot face față asaltului), dar reprezintă adesea și o tactică de negociere, menită să vadă dacă firmele de AI vor oferi o formă de remunerare individuală sau colectivă pentru toate datele pe care și le doresc atât de mult și care au fost gratuite atâta vreme, până acum.

Deoarece crawlerele AI trebuie să funcționeze la scară largă, ele tind să folosească instanțe „headless” de Chrome, în cadrul platformei Playwright. În prezent, pe un număr tot mai mare de domenii, asta va duce la o eroare 403 („interzis”) (adică gazda știe că traficul este automatizat și îți spune să pleci):

O instalare locală a changedetection.io încearcă să verifice periodic un site, dar site-ul nu acceptă browserul detectat pe care îl folosește platforma și răspunde cu o eroare 403 („Interzis”).

Ceea ce se dorește este răspunsul clientului „200” („OK”), chiar dacă, pentru a-l obține, trebuie să dai o grămadă de bani unei rețele de servere proxy rezidențiale, combinând această metodă cu diverse alte tertipuri, pe cât de ingenioase, pe atât de nelegitime, care nu implică oameni.

Nu există nimic mai bun decât răspunsul 200; cu alte cuvinte, nu există niciun cod de răspuns al clientului care să transmită un semnal pozitiv mai puternic. Nici nu este un răspuns ambiguu: nu înseamnă niciodată „aproape în regulă”, „va fi în regulă mai târziu” sau „devine tot mai în regulă”; înseamnă „totul e în regulă!”. Dacă ceva nu este în regulă, răspunsul nu este 200.

Salut! Pleacă!

Totuși, potrivit unei noi lucrări, această lipsă de nuanțe ar putea denatura semnificativ seturile de date AI, estimările statistice și raportarea unui statut „bun” atunci când lucrurile nu stau astfel.

Studiul* estimează că aproximativ o cincime dintre răspunsurile din categoria 200 nu conțin deloc conținut utilizabil al paginii, ci afișează în schimb structuri goale de site, provocări CAPTCHA, restricții de acces sau pagini de înlocuire.

Lucrarea afirmă:

„20,9% dintre paginile pe care le primește un client static cu starea 200 nu conțin conținutul principal al paginii: structuri de aplicație, provocări pentru boți, pagini de blocare, pagini de eroare și pagini substitutive, precum și conținut parțial.”

În acest sens, sistemele automatizate nerăbdătoare sunt încurcate chiar de propria lor simplitate, deoarece răspunsul „200” poate fi echivalat cu o preluare reușită, chiar și atunci când aceasta afișează doar o provocare CAPTCHA, un perete de plată sau un alt obstacol.

Lucrarea descrie cele șapte tipuri de conținut care complică frecvent un răspuns 200:

Cele șapte categorii de conținut care sunt orice, numai „în regulă” nu, într-un răspuns 200. Sursa

În cadrul studiului, pe parcursul a trei zile, au fost testate 10.307 adrese web folosind atât un program elementar de preluare a paginilor web, cât și un browser capabil să încarce JavaScript, iar răspunsurile au fost clasificate în funcție de conținutul recuperat, nu de codurile lor de stare HTTP.

Cele mai numeroase categorii de răspunsuri 202 «inutilizabile» au fost paginile-schelet goale ale site-urilor și paginile de eroare sau de înlocuire, care, împreună, au reprezentat peste două treimi dintre eșecuri.

În cazul paginilor-schelet goale, un site își poate afișa meniurile și elementele de navigare, lăsând însă necompletat articolul solicitat sau lista de produse; în acest din urmă caz, poate apărea o pagină fără legătură cu solicitarea sau pagina principală, în locul conținutului cerut – însă ambele situații pot primi același cod de stare HTTP 200 ca o preluare reușită, cu conținut utilizabil și util.

Ca soluție, lucrarea recomandă ca instrumentele de preluare a paginilor web să raporteze ce anume a fost recuperat, în loc să se bazeze pe codurile de stare HTTP, deoarece verificările simple pentru pagini neobișnuit de scurte, redirecționări suspecte și conținut asemănător paginilor inexistente ar putea identifica majoritatea eșecurilor.

Instrumentele de browser care consumă mai multe resurse ar putea fi apoi folosite doar atunci când pare că o pagină nu s-a încărcat corect. În plus, evaluările IA ar putea verifica dacă sursele citate conțin într-adevăr informațiile așteptate, în loc să presupună că un răspuns HTTP 200 înseamnă că informațiile au fost recuperate cu succes.

Autorul noii lucrări mai observă că «euristicile simple» pot identifica cu ușurință aproximativ 86% dintre răspunsurile inutilizabile, prin verificări elementare ale lungimii paginilor, redirecționărilor și asemănărilor cu pagini inexistente:

Comparație între strategiile de preluare a paginilor web: randarea doar a paginilor semnalate ca suspecte a recuperat o proporție ușor mai mare de conținut utilizabil (81,4%) decât randarea tuturor paginilor (80,3%), reducând totodată timpul mediu de preluare de la 20,6 la 5,8 secunde pe pagină. 

De ce sunt atât de multe răspunsuri 200 eronate?

De-a lungul anilor, în comunitățile de dezvoltatori, a existat o oarecare dezbatere cu privire la posibilitatea ca eroarea 202 («Acceptat») («Solicitarea a fost acceptată, dar nu a fost încă finalizată») să permită diferențierea acestor solicitări cu status 200 «eșuate»; în realitate însă, codul 202 nu poate acoperi toate situațiile prezentate în noua lucrare și nu există niciun cod existent care să o poată face.

Deși lucrarea nu tratează pe larg această problemă, motivul pentru care proprietarii de domenii permit erorile 200 ar putea merita o analiză mai aprofundată în lucrări viitoare pe această temă.

Un motiv ar putea fi faptul că orice răspuns care nu este 200 reprezintă, în esență, un fel de pagină de eroare sau un obstacol, inclusiv cele mai frecvente erori 404 («nu a fost găsit») – situații în care conținutul căutat pur și simplu lipsește. Unii utilizatori cred că un număr excesiv de astfel de erori va duce la penalizări în SEO (și, probabil, în GEO), deși Google neagă acest lucru.

De fapt, Google consideră erorile 200 eronate drept erori 404 aparente, care, în mod clar, pot fi tratate ca o problemă mai gravă decât erorile 404 obișnuite, deoarece sunt, în esență, rezultate «înșelătoare», intenționat sau nu.

Deriva citărilor

Dacă toate acestea par pedanterie, trebuie luată în considerare scara de ordinul petaocteților a datelor colectate în mod obișnuit (sau a căror colectare este încercată) în scopul antrenării IA. Dacă o cincime întreagă din aceste date nu este fiabilă sau este de-a dreptul înșelătoare, consecințele ulterioare sunt greu de trecut cu vederea ca un fel de «inexactitate colaterală»; astfel de răspunsuri false ar putea, dimpotrivă, să afecteze semnificativ și negativ distribuția datelor din seturile de date și rezultatele antrenării modelelor IA cu aceste date.

De exemplu, o problemă importantă legată de răspunsurile 200 eronate este «deriva citărilor», situația în care un răspuns generat de IA nu mai este susținut de pagina web citată inițial ca dovadă; cu alte cuvinte, este posibil ca pagina să se fi schimbat, ca textul relevant să fi fost eliminat sau ca linkul să ducă acum în altă parte.

Noul studiu a constatat că deriva aparentă a citărilor a crescut de la 5,8% la 21,9% atunci când toate răspunsurile HTTP 200 au fost acceptate drept preluări reușite, indiferent de conținutul lor.

Asta înseamnă că s-ar putea considera în mod eronat că o sursă s-a schimbat, a dispărut sau nu mai susține o afirmație generată de IA, doar pentru că, în locul materialului original, a fost recuperată o CAPTCHA, o pagină goală sau un alt obstacol.

Spune pur și simplu că așa este!

Problema a fost demonstrată și prin teste cu adrese web inexistente în mod deliberat. Atunci când au fost solicitate căi aleatorii, inventate, de pe site-uri web, 13,1% dintre cele care au răspuns au returnat statusul 200 («OK»), deși paginile solicitate nu existau^†.

«13,1% dintre site-urile care au răspuns la testul cu o cale aleatorie au returnat statusul 200 (S1 10,5%, S2 13,3%, S3 17,3%, S4 13,7%, S5 13,1%). Prin definiție, fiecare astfel de răspuns este o eroare 404 aparentă, dar nu toate o indică drept atare.»

„Într-o analiză exploratorie a celor 172 de răspunsuri soft 404, adnotatorul a clasificat 98 drept pagini de eroare sau de înlocuire, 32 drept pagini-cadru și 28 drept conținut: o pagină de pornire sau o listă afișată la o cale aleatorie pare o pagină obișnuită.”

Concluzie

Dacă problema ar fi recunoscută la un nivel superior, IANA ar putea, eventual, crea un nou cod de stare HTTP, mai potrivit, precum [X] („Cererea a reușit, dar conținutul solicitat nu a fost livrat”). Deși acest cod ar descrie într-adevăr ceea ce se întâmplă, ar necesita, în mod firesc, un nivel improbabil de înțelegere a tranzacției din partea gazdei.

Există deja coduri similare, deși niciunul nu se potrivește cu adevărat: 451 („Indisponibil din motive juridice”) este ambiguu și destul de alarmant (!); 206 („Conținut parțial”) este adecvat din punct de vedere tehnic, dar este destinat datelor (preluărilor) incomplete; iar surprinzătorul cod 203 („Informații fără autoritate”), creat în 1997, are doar o legătură tangențială cu cazul de utilizare în discuție.

Poate că cel mai apropiat candidat este, de fapt, codul 103 („Indicii timpurii”), denumit într-un mod contraintuitiv, care indică faptul că nu au fost încă încărcate toate resursele URL-ului (deși aceasta ar fi, în mod clar, o interpretare profund greșită a intenției codului).

* Intitulat „Când 200 OK nu este un răspuns: eșecuri silențioase în preluarea autonomă a conținutului web.”‘ Vă rugăm să rețineți că lucrarea este scrisă, aparent, în primul rând pentru a putea fi citită automat, poate pentru a fi interogată de AI, și nu este ușor de parcurs.

^† Îmi cer scuze pentru citatul formulat mecanic, dar întreaga lucrare este scrisă în acest fel, după cum menționez mai sus, pentru a putea fi „citită automat”, nu interpretată de oameni, deși nu ajunge să fie prezentată în format JSON.

Publicat inițial miercuri, 4 noiembrie 2026