Crawler, motori di ricerca e lo squallore delle società di intelligenza artificiale generativa
Pubblicato: 2023-07-13Il boom dei prodotti di intelligenza artificiale generativa negli ultimi mesi ha spinto molti siti Web a prendere contromisure.
La preoccupazione di base è questa:
I prodotti AI dipendono dal consumo di grandi volumi di contenuti per addestrare i loro modelli linguistici (i cosiddetti modelli linguistici di grandi dimensioni, o LLM in breve), e questo contenuto deve provenire da qualche parte. Le aziende di intelligenza artificiale ritengono che l'apertura del Web consenta il crawling su larga scala per ottenere dati di addestramento, ma alcuni operatori di siti Web non sono d'accordo, tra cui Reddit, Stack Overflow e Twitter.
Questa risposta a questa interessante domanda sarà senza dubbio discussa nei tribunali di tutto il mondo.
Questo articolo esplorerà questa domanda, concentrandosi sugli aspetti commerciali e tecnici. Ma prima di addentrarci, alcuni punti:
- Sebbene questo argomento tocchi, e includa in questo articolo, alcuni argomenti legali, non sono un avvocato, non sono il tuo avvocato e non ti do alcun consiglio di alcun tipo. Parla con il tuo gatto avvocato preferito se hai bisogno di consulenza legale.
- Ho lavorato in Google molti anni fa, principalmente nella ricerca web. Non parlo a nome di Google in alcun modo o forma, anche quando cito alcuni esempi di Google di seguito.
- Questo è un argomento in rapido movimento. È garantito che tra il momento in cui ho finito di scrivere questo e tu lo stai leggendo, sarebbe successo qualcosa di importante nel settore, ed è garantito che mi sarei perso qualcosa!
L'accordo tra motori di ricerca e siti web
Iniziamo con come funziona un motore di ricerca moderno, come Google o Bing. In termini eccessivamente semplificati, un motore di ricerca funziona così:
- Il motore di ricerca ha un elenco di URL. Ogni URL ha metadati (a volte chiamati "segnali") che indicano che l'URL può essere importante o utile da mostrare nelle pagine dei risultati del motore di ricerca.
- Sulla base di questi segnali, il motore di ricerca ha un crawler, un bot, che è un programma che recupera questi URL in un certo ordine di "importanza" in base a ciò che indicano i segnali. A tale scopo, il crawler di Google si chiama Googlebot e quello di Bing è Bingbot (ed entrambi ne hanno molti altri per altri scopi, come gli annunci). Entrambi i bot si identificano nell'intestazione dell'agente utente ed entrambi possono essere verificati a livello di programmazione dai siti Web per essere sicuri che il contenuto venga offerto al vero bot del motore di ricerca e non a uno spoofing.
- Una volta che il contenuto è stato recuperato, viene indicizzato. Gli indici dei motori di ricerca sono database complicati che contengono il contenuto della pagina insieme a un'enorme quantità di metadati e altri segnali utilizzati per abbinare e classificare il contenuto rispetto alle query degli utenti. Un indice è ciò che viene effettivamente cercato quando digiti una query in Google o Bing.
I moderni motori di ricerca, almeno quelli buoni e educati, danno all'operatore del sito web il pieno controllo sulla scansione e sull'indicizzazione.
Il Robots Exclusion Protocol è il modo in cui questo controllo viene implementato, attraverso il file robots.txt e meta tag o intestazioni sulla pagina web stessa. Questi motori di ricerca obbediscono volontariamente al protocollo di esclusione dei robot, prendendo l'implementazione del protocollo da parte di un sito Web come una direttiva, un comando assoluto, non solo un semplice suggerimento.
È importante sottolineare che la posizione predefinita del protocollo è che tutte le scansioni e l'indicizzazione sono consentite: è permissiva per impostazione predefinita. A meno che il gestore del sito web non prenda attivamente provvedimenti per implementare l'esclusione, si ritiene che il sito web consenta la scansione e l'indicizzazione.
Questo ci fornisce la struttura di base dell'accordo tra motori di ricerca e siti Web: per impostazione predefinita, un sito Web verrà scansionato e indicizzato da un motore di ricerca, che, a sua volta, indirizza gli utenti direttamente al sito Web originale nei risultati di ricerca per query pertinenti .
Questo accordo è fondamentalmente uno scambio economico: i costi di produzione, hosting e servizio del contenuto sono sostenuti dal sito Web, ma l'idea è che il traffico che ottiene in cambio lo ripaghi con un profitto.
Nota : sto intenzionalmente ignorando tutta una serie di argomenti correlati qui, su chi ha più potere in questo scambio, chi guadagna più soldi, equità e molto altro. Non li sto sminuendo, semplicemente non voglio distrarre dall'argomento centrale di questo articolo.
Questo approccio all'indicizzazione per il traffico si presenta altrove, ad esempio quando i motori di ricerca possono indicizzare i contenuti dietro un paywall. È la stessa idea: il sito Web condivide i contenuti in cambio della visualizzazione nei risultati di ricerca che indirizzano gli utenti direttamente al sito Web.
E in ogni fase del processo di questo accordo, se l'editore desidera bloccare in qualsiasi modo la scansione o l'indicizzazione in tutto o in parte, l'editore dispone di diversi strumenti che utilizzano il protocollo Robots and Exclusion. Tutto ciò che può ancora essere scansionato e indicizzato è perché il sito Web ottiene un vantaggio diretto dall'essere mostrato nei risultati di ricerca.
Questo argomento in qualche forma è stato effettivamente utilizzato nei tribunali, in quella che è diventata nota come la "difesa robots.txt" ed è stato sostanzialmente sostenuto; guarda questo breve elenco di casi giudiziari, molti dei quali coinvolgono Google, e questo articolo del 2007 che non ne è del tutto felice.
Gli LLM non sono motori di ricerca
Ora dovrebbe essere molto chiaro che un LLM è una bestia diversa da un motore di ricerca.
La risposta di un modello linguistico non rimanda direttamente ai siti Web il cui contenuto è stato utilizzato per addestrare il modello. Non c'è scambio economico come vediamo con i motori di ricerca, ed è per questo che molti editori (e autori) sono sconvolti.
La mancanza di citazioni dirette alla fonte è la differenza fondamentale tra un motore di ricerca e un LLM, ed è la risposta alla domanda molto comune di "perché Google e Bing dovrebbero essere autorizzati a raschiare i contenuti ma non OpenAI?" (Sto usando una formulazione più educata di questa domanda.).
Google e Bing stanno cercando di mostrare i collegamenti alle fonti nelle loro risposte generative AI, ma queste fonti, se mostrate, non sono il set completo.
Ciò apre una domanda correlata: perché un sito Web dovrebbe consentire che il suo contenuto venga utilizzato per addestrare un modello linguistico se non ottiene nulla in cambio?
Questa è un'ottima domanda e probabilmente la più importante a cui dovremmo rispondere come società.
Gli LLM hanno vantaggi nonostante le principali carenze dell'attuale generazione di LLM (come allucinazioni, bugie agli operatori umani e pregiudizi, solo per citarne alcuni), e questi vantaggi aumenteranno solo nel tempo mentre le carenze vengono risolte.
Ma per questa discussione, il punto importante è rendersi conto che un pilastro fondamentale di come funziona il web aperto in questo momento non è adatto per i LLM.
La squallidezza
Apparentemente questo non è un problema per le aziende di intelligenza artificiale che sono interessate ad addestrare modelli di grandi dimensioni solo per il proprio vantaggio economico.
OpenAI ha utilizzato diversi set di dati come input di dati di addestramento (dettagli qui per GPT3) e OpenAI non divulga intenzionalmente i set di dati di addestramento per GPT4.
Sebbene OpenAI utilizzi molti argomenti per giustificare la mancata divulgazione di informazioni sui dati di addestramento di GPT4 (discussi qui), il punto chiave per noi rimane: non sappiamo quale contenuto è stato utilizzato per addestrarlo e OpenAI non lo mostra nelle risposte di ChatGPT.
La raccolta dei dati di OpenAI obbedisce al protocollo di esclusione dei robot? Include testo protetto da copyright, come libri di testo o altri libri? Hanno ottenuto il permesso da qualche sito web o editore? Non dicono.
L'approccio super losco di Brave Software
Se l'approccio di OpenAI è problematico, Brave Software (il creatore del browser Brave e del motore di ricerca Brave) adotta un approccio e una posizione ancora più problematici quando si tratta di ricerca e dati di addestramento AI.
Il motore di ricerca Brave dipende fortemente da quello che viene chiamato il Web Discovery Project. L'approccio è piuttosto elaborato e documentato qui, ma evidenzierò un fatto chiave: Brave non sembra avere un crawler centralizzato che gestisce e nessuno dei crawl si identifica come crawler per Brave e (siediti per questo) Brave vende il contenuto raschiato con i diritti che Brave concede all'acquirente per l'addestramento AI.
C'è molto in quella frase, quindi analizziamola.
Brave Search utilizza il browser Brave come un crawler distribuito. Come documentato in questo articolo della guida, c'è questa domanda e risposta FAQ:
Il Web Discovery Project è un crawler?
In un certo senso sì. Il progetto Web Discovery elabora i processi di recupero dal web crawler di Brave. Ogni pochi secondi o minuti, al browser potrebbe essere richiesto di recuperare una pagina Web e inviare l'HTML a Brave . Tuttavia, questo recupero non ha alcun impatto sulla cronologia di navigazione o sui cookie: viene eseguito come una chiamata API di recupero privato. Per maggiore sicurezza, i domini fetch job sono preselezionati da un piccolo insieme di domini innocui e affidabili.
Che cos'è il progetto Web Discovery? – Ricerca coraggiosa
L'API Fetch è una funzionalità standard web integrata nei moderni motori di browser, incluso quello utilizzato da Brave. Il suo uso comune è recuperare contenuti da mostrare agli utenti nel browser. Per i nostri scopi, sappiamo immediatamente che è il browser di un utente che richiede il contenuto del sito Web per conto del motore di ricerca di Brave.
È interessante notare che un thread Reddit del giugno 2021 aggiunge ulteriori dettagli e confusione. Una risposta di un rappresentante di Brave è molto interessante (mette in evidenza la mia):
Abbiamo il nostro crawler, ma non contiene una stringa user-agent (così come anche Brave, il browser, non contiene una stringa user-agent univoca ) per evitare potenziali discriminazioni . Detto questo, abbiamo parlato della potenziale identificazione del crawler per gli amministratori che vorrebbero sapere quando/dove atterra sulle loro proprietà. Rispettiamo anche robots.txt , quindi se non vuoi che Brave Search esegua la scansione del tuo sito, non lo farà.
Questa è una miniera di fatti:
- Hanno il proprio crawler, che potrebbe riferirsi a uno centralizzato o al Web Discovery Project distribuito basato su browser.
- Questo crawler non si identifica come crawler, ma in qualche modo obbedisce al Robots Exclusion Protocol (nella forma del file robots.txt). Come può un operatore di un sito web scrivere una direttiva di esclusione dei robot se il browser non si identifica? Quale token dell'agente utente (come viene chiamato) verrebbe utilizzato nel file robots.txt per specificare direttive specifiche per il crawler di Brave? Non sono riuscito a trovare alcuna documentazione da Brave.
- Ciò che chiamano discriminazione è in realtà il modo in cui gli editori controllano la scansione. Il protocollo di esclusione dei robot è un meccanismo che consente agli editori di discriminare tra ciò a cui utenti e crawler possono accedere e discriminare tra diversi crawler (ad esempio, consentire a Bingbot di eseguire la scansione ma non a Googlebot). Affermando di voler evitare la discriminazione, Brave in realtà sta dicendo che possono decidere cosa scansionare e indicizzare, non l'editore.
Tornando all'API Fetch: per impostazione predefinita, l'API Fetch utilizza la stringa dell'agente utente del browser. Sappiamo già che il browser Brave non si identifica con un'intestazione univoca dell'agente utente, ma utilizza, invece, la stringa generica dell'agente utente prodotta dal motore del browser sottostante.
La stringa user-agent può essere personalizzata, per il browser in generale e per l'API Fetch, ma non ho trovato alcuna indicazione che Brave lo faccia (e in effetti, la risposta di Reddit citata sopra dice esplicitamente che non esiste un identificatore univoco).
Inoltre, Brave continua a vendere i dati raschiati appositamente per l'addestramento AI, non solo come risultati di ricerca (ad esempio, per alimentare una funzione di ricerca del sito).
Visitando la home page dell'API di Brave Search vengono mostrati diversi livelli di prezzo, inclusi alcuni chiamati "Dati per l'IA". Questi piani dati includono opzioni per "Dati con diritti di archiviazione" che consentono all'abbonato di "memorizzare nella cache/memorizzare i dati per addestrare i modelli AI", con i dati che includono "Snippet alternativi extra per AI" e con "Diritti di utilizzare i dati per l'inferenza AI". "
In sintesi, sulla base delle dichiarazioni pubbliche di Brave e della mancanza di documentazione, Brave esegue la scansione del Web in modo furtivo, senza un modo ovvio per controllarlo o bloccarlo, e continua a rivendere il contenuto sottoposto a scansione per l'addestramento dell'IA.
O per riformulare questo in modo più schietto, Brave si è autoproclamato distributore a scopo di lucro di contenuti protetti da copyright senza licenza o autorizzazione da parte degli editori di siti web .
È accettabile? Lo vedo come uno squallido raschietto come servizio.
Iniziativa sui controlli per i publisher di Google
Potrebbe esserci presto un nuovo tipo di web crawler, uno specifico per l'IA generativa.
Sembra che Google abbia riconosciuto l'incompatibilità discussa sopra, ovvero che l'utilizzo dei contenuti recuperati da Googlebot per la ricerca sul Web potrebbe non essere adatto per l'addestramento dei modelli di intelligenza artificiale.
Google ha annunciato di voler avviare una discussione nella community per creare controlli AI Web Publisher (ehi, Google, mi sono registrato, fammi entrare per favore!). Sostengo con tutto il cuore questa conversazione e complimenti a Google per aver aperto la porta a questa conversazione.
Dato che siamo agli inizi, è importante segnalare che le impostazioni predefinite e le capacità di tali controlli saranno fondamentali per il loro successo o fallimento. Sospetto che molti editori e autori avranno opinioni forti che dobbiamo sentire su come dovrebbero funzionare questi controlli AI.
E gli LLM open source?
Un aspetto importante dell'argomentazione di cui sopra è lo scambio economico. Ma cosa succede se l'organizzazione dietro il modello linguistico rilascia il modello liberamente senza benefici per se stessa?
Esistono molti di questi modelli open source e vengono addestrati su set di dati che si sovrappongono sostanzialmente ai set di dati utilizzati per addestrare modelli proprietari commerciali. Molti modelli open source sono abbastanza buoni per alcuni casi d'uso in questo momento e stanno solo migliorando.
Tuttavia: è giusto che il contenuto di un sito Web venga utilizzato senza autorizzazione per addestrare un LLM open source?
Questa è forse una domanda più complicata e penso che la risposta attualmente si basi su ciò che consente il Protocollo di esclusione dei robot. È possibile che una risposta migliore emerga sotto forma di un approccio ben progettato da AI Web Publisher Controls di Google o qualche altra iniziativa simile.
Guarda questo spazio.
Quindi cosa può fare un editore adesso?
Questa situazione attuale è quella che molti editori non vogliono né accettano. Cosa possono fare?
Qui dobbiamo tornare al blocco dei crawler/bot della vecchia scuola. Esistono generalmente due tipi di crawler:
- Crawler che si identificano. Possono obbedire o meno al Robots Exclusion Protocol, ma almeno il server ha un identificatore da controllare per decidere se bloccare o meno la richiesta. Gli esempi includono Googlebot e Bingbot.
- Crawler invisibili, che non vengono utilizzati per i motori di ricerca educati. Non si identificano e/o non obbediscono al protocollo di esclusione dei robot. Esempi sono lo spam scraper di qualsiasi script kiddie o il crawler di Brave Search.
Ci sono due cose complementari che puoi fare:
- Se il crawler obbedisce al protocollo di esclusione dei robot, puoi bloccarlo se ritieni che il contenuto che esegue la scansione si inserisca nei dati di addestramento AI. Ci sono due approcci qui:
- Blocca tutti i crawler e consenti solo quelli che desideri consentire per le tue esigenze (come Googlebot e Bingbot). Questo è pericoloso per le prestazioni di un sito Web nella ricerca organica. Devi stare estremamente attento con esso, ma è efficace per questi crawler.
- Consenti tutte le scansioni e blocca quelle che vuoi bloccare. Questo approccio più permissivo è meno pericoloso, ma ovviamente i tuoi contenuti potrebbero essere copiati dall'intelligenza artificiale o da altri crawler che potresti non volere.
- Usa un rilevatore di bot stealth lato server e usalo per bloccare tali crawler. Molti prodotti possono farlo. Se utilizzi una rete di distribuzione dei contenuti (CDN) come fanno molti editori, è probabile che questo tipo di funzionalità sia disponibile tramite quella (ad es. Akamai, Cloudflare, Fastly).
L'approccio che sto iniziando ad adottare con i siti Web che gestisco e discuto con i clienti è una combinazione di opzioni (1a) e (2), ovvero utilizzare un file robots.txt restrittivo insieme ai controlli CDN.
Questo potrebbe non essere l'approccio migliore per ogni editore, ma penso che valga la pena prenderlo in seria considerazione.
Che cosa significa tutto questo?
Stiamo vivendo tempi che diventeranno uno dei più influenti della storia. Le persone stanno letteralmente predicendo il destino dell'umanità dall'IA. Abbiamo tutti un ruolo da svolgere nel plasmare il futuro.
Da parte nostra, come creatori di contenuti originali, dobbiamo pensare a come rispondere, tenere il passo e adattarci a questa parte in rapida evoluzione del settore. Decidere come i contenuti che creiamo vengono creati, distribuiti e consumati è ora un complicato mix di strategia, tecnologia, finanze, etica e altro ancora.
Comunque tu rispondi, stai prendendo posizione in un momento storico. Sento il tuo fardello.
Le opinioni espresse in questo articolo sono quelle dell'autore ospite e non necessariamente Search Engine Land. Gli autori dello staff sono elencati qui.