Crawlerele, motoarele de căutare și nenorocirea companiilor generative de inteligență artificială

Boom-ul produselor AI generative din ultimele luni a determinat multe site-uri web să ia contramăsuri.

Preocuparea de bază este astfel:

Produsele AI depind de consumarea unor volume mari de conținut pentru a-și antrena modelele lingvistice (așa-numitele modele lingvistice mari, sau pe scurt LLM), iar acest conținut trebuie să provină de undeva. Companiile de inteligență artificială văd că deschiderea web-ului permite accesarea cu crawlere la scară largă pentru a obține date de instruire, dar unii operatori de site-uri web nu sunt de acord, inclusiv Reddit, Stack Overflow și Twitter.

Acest răspuns la această întrebare interesantă va fi, fără îndoială, contestat în instanțe din întreaga lume.

Acest articol va explora această întrebare, concentrându-se pe aspectele de afaceri și tehnice. Dar înainte de a ne arunca, câteva puncte:

• Deși acest subiect atinge, și includ în acest articol, câteva argumente juridice, nu sunt avocat, nu sunt avocatul dumneavoastră și nu vă dau niciun sfat de niciun fel. Vorbește cu pisica ta avocat favorită dacă ai nevoie de consiliere juridică.
• Am lucrat la Google în urmă cu mulți ani, mai ales în căutarea pe web. Nu vorbesc în numele Google sub nicio formă sau formă, chiar dacă citez mai jos câteva exemple Google.
• Acesta este un subiect care se mișcă rapid. Este garantat că între momentul în care am terminat de scris acest lucru și când îl citiți, s-ar fi întâmplat ceva major în industrie și este garantat că aș fi scăpat ceva!

„Afacerea” dintre motoarele de căutare și site-uri web

Începem cu modul în care funcționează un motor de căutare modern, precum Google sau Bing. În termeni prea simplificați, un motor de căutare funcționează astfel:

• Motorul de căutare are o listă de adrese URL. Fiecare adresă URL are metadate (numite uneori „semnale”) care indică faptul că adresa URL poate fi importantă sau utilă pentru a fi afișată în paginile cu rezultate ale motorului de căutare.
• Pe baza acestor semnale, motorul de căutare are un crawler, un bot, care este un program care preia aceste adrese URL într-o anumită ordine de „importanță” în funcție de ceea ce indică semnalele. În acest scop, crawler-ul Google se numește Googlebot și cel al lui Bing este Bingbot (și ambele au multe altele pentru alte scopuri, cum ar fi reclamele). Ambii roboți se identifică în antetul user-agent și ambii pot fi verificați programatic de site-uri web pentru a vă asigura că conținutul este difuzat către robotul real al motorului de căutare și nu o falsificare.
• Odată ce conținutul este preluat, acesta este indexat. Indicii motoarelor de căutare sunt baze de date complicate care conțin conținutul paginii împreună cu o cantitate imensă de metadate și alte semnale utilizate pentru a potrivi și a clasifica conținutul la interogările utilizatorilor. Un index este ceea ce este căutat de fapt atunci când introduceți o interogare în Google sau Bing.

Motoarele de căutare moderne, cele bune cel puțin politicoase, oferă operatorului site-ului web control deplin asupra accesării cu crawlere și indexare.

Protocolul de excludere a roboților este modul în care este implementat acest control, prin fișierul robots.txt și metaetichete sau anteturi de pe pagina web în sine. Aceste motoare de căutare se supun în mod voluntar Protocolului de excludere a roboților, luând implementarea protocolului de către un site web ca o directivă, o comandă absolută, nu doar un simplu indiciu.

Important este că poziția implicită a protocolului este că toate accesările cu crawlere și indexarea sunt permise - este permisiv în mod implicit. Cu excepția cazului în care operatorul site-ului web ia măsuri pentru implementarea excluderii, se consideră că site-ul web permite accesarea cu crawlere și indexarea.

Acest lucru ne oferă cadrul de bază al înțelegerii dintre motoarele de căutare și site-uri web: în mod implicit, un site web va fi accesat cu crawlere și indexat de un motor de căutare, care, la rândul său, îi direcționează pe cei care caută direct către site-ul original în rezultatele căutării lor pentru interogări relevante. .

Această tranzacție este în esență un schimb economic: costurile de producere, găzduire și difuzare a conținutului sunt suportate de site-ul web, dar ideea este că traficul pe care îl obține în schimb îl plătește înapoi cu un profit.

Notă : ignor în mod intenționat o mulțime de argumente legate aici, despre cine are mai multă putere în acest schimb, cine câștigă mai mulți bani, corectitudine și multe altele. Nu le subjug pe acestea – pur și simplu nu vreau să distrag atenția de la subiectul de bază al acestui articol.

Această abordare de indexare pentru trafic apare în altă parte, de exemplu atunci când motoarele de căutare au voie să indexeze conținutul în spatele unui paywall. Este aceeași idee: site-ul web partajează conținut în schimbul faptului că este afișat în rezultatele căutării, care îi direcționează pe cei care caută înapoi direct către site.

Și la fiecare pas al procesului acestei oferte, dacă editorul dorește să blocheze în vreun fel toate sau unele accesări cu crawlere sau indexare, atunci editorul are mai multe instrumente care utilizează protocolul Robots and Exclusion. Orice lucru care încă poate fi accesat cu crawlere și indexat se datorează faptului că site-ul web beneficiază direct de a fi afișat în rezultatele căutării.

Acest argument într-o anumită formă a fost de fapt folosit în instanțe, în ceea ce a devenit cunoscut sub numele de „apărare robots.txt” și practic a fost susținut; vezi această listă scurtă de cazuri în instanță, multe care implică Google, și acest articol din 2007 care nu este în totalitate mulțumit de asta.

LLM-urile nu sunt motoare de căutare

Acum ar trebui să fie foarte clar că un LLM este o fiară diferită de un motor de căutare.

Răspunsul unui model de limbă nu indică în mod direct către site-urile web al căror conținut a fost folosit pentru a antrena modelul. Nu există schimb economic, așa cum vedem cu motoarele de căutare, și de aceea mulți editori (și autori) sunt supărați.

Lipsa citărilor directe de sursă este diferența fundamentală dintre un motor de căutare și un LLM și este răspunsul la întrebarea foarte frecventă de „de ce ar trebui să li se permită Google și Bing să analizeze conținut, dar nu OpenAI?” (Folosesc o formulare mai politicoasă a acestei întrebări.).

Google și Bing încearcă să arate link-uri sursă în răspunsurile lor generative AI, dar aceste surse, dacă sunt afișate deloc, nu reprezintă setul complet.

Aceasta deschide o întrebare conexă: de ce ar trebui un site web să permită ca conținutul său să fie folosit pentru a antrena un model lingvistic dacă nu primește nimic în schimb?

Aceasta este o întrebare foarte bună – și probabil cea mai importantă la care ar trebui să răspundem ca societate.

LLM-urile au beneficii în ciuda deficiențelor majore ale generației actuale de LLM (cum ar fi halucinațiile, minciuna operatorilor umani și părtinirile, pentru a numi câteva), iar aceste beneficii vor crește doar în timp, în timp ce deficiențele vor fi rezolvate.

Dar pentru această discuție, punctul important este să realizăm că un pilon fundamental al modului în care funcționează web deschis în acest moment nu este potrivit pentru LLM.

Scântecul

Aparent, aceasta nu este o problemă pentru companiile AI care sunt interesate să antreneze modele mari doar pentru propriul beneficiu economic.

OpenAI a folosit mai multe seturi de date ca intrări de date de antrenament (detalii aici pentru GPT3), iar OpenAI nu dezvăluie în mod intenționat seturile de date de antrenament pentru GPT4.

Deși OpenAI folosește multe argumente pentru a justifica nedezvăluirea informațiilor despre datele de antrenament ale GPT4 (discutate aici), punctul cheie pentru noi rămâne: nu știm ce conținut a fost folosit pentru a-l antrena, iar OpenAI nu arată acest lucru în răspunsurile ChatGPT.

Colectarea datelor OpenAI respectă Protocolul de excludere a roboților? Include text protejat prin drepturi de autor, cum ar fi manuale sau alte cărți? Au primit permisiunea de la vreun site web sau editor? Ei nu spun.

Abordarea super umbrită a Brave Software

Dacă abordarea OpenAI este problematică, Brave Software (producătorul browserului Brave și al motorului de căutare Brave) adoptă o abordare și o poziție și mai problematică atunci când vine vorba de căutare și de date de antrenament AI.

Motorul de căutare Brave depinde în mare măsură de ceea ce se numește Web Discovery Project. Abordarea este destul de elaborată și documentată aici, dar voi evidenția un fapt cheie: Brave nu pare să aibă un crawler centralizat pe care îl operează și niciunul dintre crawler-uri nu se identifică ca crawler pentru Brave și (stai jos pentru asta) Brave vinde conținutul răzuit cu drepturi pe care Brave le oferă cumpărătorului pentru instruirea AI.

Există multe în acea propoziție, așa că hai să o analizăm.

Brave search folosește browserul Brave ca crawler distribuit. După cum este documentat în acest articol de ajutor, există această întrebare frecventă și răspuns:

Proiectul Web Discovery este un crawler?

Într-un fel, da. Proiectul Web Discovery procesează joburi de preluare din crawler-ul web al Brave. La fiecare câteva secunde sau minute, browserul poate primi instrucțiuni să preia o pagină web și să trimită codul HTML înapoi la Brave . Cu toate acestea, această preluare nu are niciun impact asupra istoricului de navigare sau asupra cookie-urilor - se face ca un apel API de preluare privată. Pentru un plus de siguranță, domeniile de lucru de preluare sunt preselectate dintr-un set mic de domenii inofensive și de renume.

Ce este Web Discovery Project? – Căutare curajoasă

API-ul Fetch este o funcționalitate standard web încorporată în motoarele de browser moderne, inclusiv cea pe care o folosește Brave. Utilizarea sa obișnuită este de a prelua conținut pentru a-l afișa utilizatorilor în browser. În scopurile noastre, știm imediat că este browserul unui utilizator care solicită conținutul site-ului web în numele motorului de căutare Brave.

Interesant, un fir Reddit din iunie 2021 adaugă mai multe detalii și confuzie. Un răspuns de la un reprezentant Brave este foarte interesant (subliniază-l pe al meu):

Avem propriul nostru crawler, dar nu conține un șir user-agent (la fel cum Brave, browserul, nici nu conține un șir unic user-agent ) pentru a evita potențiala discriminare . Acestea fiind spuse, am vorbit despre identificarea potențială a crawler-ului pentru administratorii care ar dori să știe când/unde aterizează pe proprietățile lor. De asemenea, respectăm și robots.txt , așa că dacă nu doriți ca Brave Search să vă acceseze cu crawlere site-ul, nu o va face.

Aceasta este o mină de aur a faptelor:

1. Au propriul lor crawler, care se poate referi la unul centralizat sau la proiectul Web Discovery bazat pe browser distribuit.
2. Acest crawler nu se identifică ca crawler, dar se supune cumva Protocolului de excludere a roboților (sub forma fișierului robots.txt). Cum poate un operator de site web să scrie o directivă de excludere a roboților dacă browserul nu se identifică? Ce simbol de agent utilizator (așa cum se numește) ar fi folosit în fișierul robots.txt pentru a specifica directive specifice pentru crawler-ul Brave? Nu am reușit să găsesc nicio documentație de la Brave.
3. Ceea ce ei numesc discriminare este de fapt modul în care editorii ar controla accesul cu crawling. Protocolul de excludere a roboților este un mecanism prin care editorii pot face discriminări între ceea ce utilizatorii și crawlerele au voie să acceseze și să discrimineze între diferitele crawler-uri (de exemplu, permiteți Bingbot să acceseze cu crawlere, dar nu Googlebot). Pretinzând că vor să evite discriminarea, Brave spune de fapt că ei decid ce accesează cu crawlere și indexează, nu editorul.

Revenind la API-ul Fetch: în mod implicit, API-ul Fetch utilizează șirul user-agent al browserului. Știm deja că browserul Brave nu se identifică cu un antet unic user-agent, folosind, în schimb, șirul generic user-agent produs de motorul browser-ului de bază.

Șirul user-agent poate fi personalizat, pentru browser în general și pentru API-ul Fetch, dar nu am găsit niciun indiciu că Brave face asta (și într-adevăr, răspunsul Reddit citat mai sus spune în mod explicit că nu există un identificator unic).

În plus, Brave continuă să vândă datele răzuite special pentru instruirea AI, nu doar ca rezultate de căutare (de exemplu, pentru a alimenta o funcție de căutare pe site).

Vizitarea paginii de pornire a API-ului Brave Search arată mai multe niveluri de preț, inclusiv unele numite „Date pentru IA”. Aceste planuri de date includ opțiuni pentru „Date cu drepturi de stocare” care permit abonatului să „memoreze cache/stocare date pentru a antrena modele AI”, datele incluzând „Fragmente alternative suplimentare pentru AI” și cu „Drepturi de utilizare a datelor pentru inferența AI”. ”

În rezumat, pe baza declarațiilor publice ale lui Brave și a lipsei de documentare, Brave accesează cu crawlere web-ul într-un mod ascuns, fără o modalitate evidentă de a-l controla sau de a-l bloca și continuă să revinde conținutul accesat cu crawlere pentru antrenamentul AI.

Sau pentru a reformula acest lucru mai direct, Brave s-a numit distribuitor cu scop lucrativ de conținut protejat prin drepturi de autor, fără licență sau permisiunea editorilor de site-uri web .

Este acest lucru acceptabil? Îl văd ca pe un răzuitor slăbănog ca pe un serviciu.

Inițiativa Google Publisher Controls

Este posibil să apară în curând un nou tip de crawler web, unul special pentru IA generativă.

Se pare că Google a recunoscut incompatibilitatea discutată mai sus, că utilizarea conținutului Googlebot preluat pentru căutarea pe web poate să nu fie potrivită pentru antrenarea modelelor AI.

Google a anunțat că dorește să înceapă o discuție în comunitate pentru a crea AI Web Publisher Controls (hei, Google, m-am înscris, lasă-mă să intru, te rog!). Susțin din toată inima această conversație și bravo Google pentru că a deschis ușa pentru a avea această conversație.

Întrucât ne aflăm în primele zile, este important să semnalăm că valorile implicite și capabilitățile unor astfel de controale vor fi esențiale pentru succesul sau eșecul lor. Bănuiesc că mulți editori și autori vor avea păreri puternice că trebuie să auzim despre cum ar trebui să funcționeze aceste controale AI.

Ce zici de LLM-urile open-source?

Un aspect important al argumentului de mai sus este schimbul economic. Dar ce se întâmplă dacă organizația din spatele modelului lingvistic eliberează modelul în mod liber, fără beneficii pentru sine?

Există multe astfel de modele open-source și sunt instruite pe seturi de date care se suprapun în mod substanțial cu seturile de date utilizate pentru a antrena modele comerciale proprietare. Multe modele open-source sunt suficient de bune pentru unele cazuri de utilizare în acest moment și doar devin mai bune.

Totuși: este corect ca conținutul unui site web să fie folosit fără permisiunea pentru a instrui un LLM cu sursă deschisă?

Aceasta este probabil o întrebare mai dificilă și cred că răspunsul se bazează în prezent pe ceea ce permite Protocolul de excludere a roboților. Este posibil ca un răspuns mai bun să apară sub forma unei abordări bine concepute de la Google AI Web Publisher Controls sau o altă inițiativă similară.

Priveste acest spatiu.

Deci, ce poate face un editor acum?

Această situație actuală este una pe care mulți editori nici nu o doresc, nici nu o acceptă. Ce pot face ei?

Aici trebuie să ne întoarcem la blocarea crawler-ului/robot vechi. În general, există două tipuri de crawler:

1. Crawler-uri care se identifică. Aceștia pot respecta sau nu Protocolul de excludere a roboților, dar cel puțin serverul are un identificator de verificat pentru a decide dacă blochează sau nu cererea. Exemplele includ Googlebot și Bingbot.
2. Crawlerele ascunse, care nu sunt folosite pentru motoarele de căutare politicoase. Ei nu se identifică și/sau nu respectă Protocolul de excludere a roboților. Exemple sunt răzuitorul de spam al oricărui copil cu script sau crawler-ul Brave Search.

Există două lucruri complementare pe care le poți face:

1. Dacă crawler-ul respectă Protocolul de excludere a roboților, îl puteți bloca dacă credeți că conținutul pe care îl accesează cu crawlere se alimentează în datele de antrenament AI. Există două abordări aici:
   • Blocați toate crawlerele și permiteți numai celor pe care doriți să le permiteți pentru nevoile dvs. (cum ar fi Googlebot și Bingbot). Acest lucru este periculos pentru performanța unui site web în căutarea organică. Trebuie să fii extrem de atent cu el, dar este eficient pentru aceste crawler-uri.
   • Permiteți toate accesările cu crawlere și blocați-le pe cele pe care doriți să le blocați. Această abordare mai permisivă este mai puțin periculoasă, dar, desigur, conținutul dvs. poate fi răzuit de AI sau de alte crawler-uri pe care este posibil să nu vă doriți.
2. Utilizați un detector de bot stealth pe partea de server și utilizați-l pentru a bloca astfel de crawler-uri. Multe produse pot face acest lucru. Dacă utilizați o rețea de distribuție de conținut (CDN), așa cum o fac mulți editori, este posibil ca acest tip de funcționalitate să fie disponibil prin aceasta (de exemplu, Akamai, Cloudflare, Fastly).

Abordarea pe care încep să o iau cu site-urile web pe care le operez și pe care o discut cu clienții este o combinație de opțiuni (1a) și (2), și anume să folosesc un fișier robots.txt restrictiv împreună cu controalele CDN.

Poate că aceasta nu este cea mai bună abordare pentru fiecare editor, dar cred că merită luată în considerare cu seriozitate.

Ce înseamnă toate acestea?

Trăim vremuri care vor deveni una dintre cele mai influente din istorie. Oamenii prevăd literalmente soarta umanității din AI. Cu toții avem un rol de jucat în modelarea viitorului.

Din partea noastră, ca creatori de conținut original, trebuie să ne gândim la cum să răspundem și să ținem pasul și să ne adaptăm la această parte în mișcare rapidă a industriei. A decide cum este creat, distribuit și consumat conținutul pe care l-am creat este acum o combinație complicată de strategie, tehnologie, finanțe, etică și multe altele.

Oricum ai răspunde, iei o atitudine într-un moment istoric. Îți simt povara.