Cloudflare introduce Web Search API tramite AI Gateway, trasformando la ricerca in infrastruttura
Cloudflare introduce Web Search API tramite AI Gateway con tre provider di ricerca, portando il recupero di informazioni dal web in tempo reale sullo stesso piano di controllo dell'inferenza dei modelli. La beta supporta Ceramic.ai, Exa e Linkup attraverso un'unica interfaccia. Gli sviluppatori possono utilizzarla da un backend, da un Cloudflare Worker o da un flusso di lavoro agentico.
Il cambiamento importante non è l'esistenza di un altro endpoint di ricerca web. Cloudflare colloca la ricerca accanto al routing dei modelli, ai log, ai controlli di sicurezza, alle credenziali e alla gestione dell'utilizzo. Questo posizionamento trasforma il recupero delle informazioni da un'integrazione isolata in un'infrastruttura AI gestita.
La mossa apre inoltre una competizione chiara. Gli sviluppatori possono usare strumenti di ricerca integrati nelle piattaforme di modelli, collegarsi direttamente a società specializzate nella ricerca o collocare il recupero dietro un gateway indipendente. Cloudflare scommette che i team desiderino la terza opzione, soprattutto quando un'applicazione utilizza più modelli e provider di ricerca.
L'introduzione di Web Search API tramite AI Gateway cambia il punto di controllo
Cloudflare offre ora agli sviluppatori un'unica rotta gestita verso tre servizi di ricerca indipendenti, senza legare il recupero delle informazioni a uno specifico modello linguistico.
L'azienda ha annunciato la beta il 2 ottobre 2026. Secondo l'annuncio di lancio, le richieste possono usare Ceramic.ai, Exa o Linkup. Ceramic.ai diventa l'impostazione predefinita quando un'applicazione non specifica un provider.
Ogni risposta segue una struttura condivisa che contiene titolo, URL e descrizione per ciascun risultato. I metadati possono includere anche la query, un identificatore della richiesta e informazioni sulla latenza. Questa coerenza conta perché le differenze specifiche dei provider spesso si riflettono nel codice dell'applicazione.
Gli sviluppatori possono accedere al servizio tramite un endpoint REST standard. Gli utenti di Cloudflare Workers possono invece chiamare env.AI.websearch() tramite un AI binding. Entrambi i metodi inviano la richiesta attraverso un AI Gateway esistente.
La rotta REST accetta una query, il nome del provider, il limite dei risultati e la configurazione del gateway. Il binding Workers espone controlli equivalenti tramite JavaScript o TypeScript. La guida di implementazione di Cloudflare indica che una query può contenere fino a 1.024 caratteri, mentre una singola richiesta restituisce fino a 10 risultati.
Questo limite mostra per cosa è progettato il prodotto. È un livello di recupero del contesto per le chiamate ai modelli, non un sostituto di una pagina convenzionale di risultati di ricerca. Un'applicazione raccoglie un insieme mirato di fonti e inserisce gli estratti pertinenti nel contesto operativo di un modello.
Il servizio supporta due percorsi per le credenziali. I team possono utilizzare i propri crediti AI Gateway oppure archiviare una chiave del provider e selezionarla tramite un alias bring-your-own-key. Cloudflare recupera tale credenziale all'interno del gateway, anziché richiedere all'applicazione di trasmetterla con ogni richiesta di ricerca.
Questa architettura offre ai team un confine comune per l'autenticazione. Riduce inoltre il numero di credenziali esterne distribuite tra applicazioni, sistemi di deployment e macchine degli sviluppatori. Un token di applicazione compromesso rappresenta comunque un rischio, ma la proliferazione delle credenziali diventa più facile da contenere.
Cloudflare afferma che le richieste di ricerca web compaiono nei normali log di osservabilità di AI Gateway. I team possono ispezionare l'attività delle richieste accanto al traffico dei modelli, anziché gestire uno stack di monitoraggio separato. Le policy di accesso possono inoltre stabilire quali applicazioni raggiungono specifici provider di ricerca.
Questa integrazione crea la tensione centrale dell'articolo. Un'API di ricerca diretta offre meno intermediari, mentre un gateway offre un maggiore controllo operativo. Cloudflare deve dimostrare che il livello di controllo risparmia più complessità di quanta ne introduca.
La ricerca sta diventando parte dello stack AI Gateway
La pressione competitiva ricade sulle piattaforme di modelli e sui fornitori specializzati nella ricerca, perché Cloudflare separa il recupero di informazioni in tempo reale dal modello che le utilizza.
Molti modelli offrono già la ricerca web nativa. La documentazione esistente del gateway Cloudflare elenca strumenti di ricerca supportati da OpenAI, Anthropic, xAI e Alibaba. Questi strumenti restano collegati alle rispettive interfacce dei provider e alle capacità dei modelli.
La ricerca nativa può essere pratica quando un team si impegna con una sola famiglia di modelli. Il modello decide quando cercare, il provider formatta le evidenze e lo stesso servizio produce la risposta. Questo percorso può ridurre al minimo il lavoro di orchestrazione per un assistente semplice.
Diventa meno pratico quando un'applicazione cambia modello. Gli schemi degli strumenti, i modelli supportati, i formati delle citazioni, la disponibilità regionale e le condizioni di conservazione possono differire. Un team potrebbe aver bisogno di implementazioni separate per ogni provider, anche quando ogni percorso svolge lo stesso compito di recupero di base.
Cloudflare Web Search API cambia questo confine. La ricerca diventa un passaggio controllato dall'applicazione con un formato di risposta comune. Il materiale recuperato può alimentare un modello disponibile tramite Workers AI, un modello instradato attraverso AI Gateway o un altro servizio di inferenza.
Questa separazione è importante per gli agenti, che spesso effettuano diverse ricerche prima di produrre una risposta. Un agente di ricerca potrebbe iniziare con una query ampia, identificare un'azienda o un documento e inviare richieste di approfondimento più ristrette. Queste chiamate richiedono logging e autorizzazioni prevedibili perché possono superare in numero la richiesta finale al modello.
L'approccio gateway supporta inoltre la selezione esplicita del provider. Uno sviluppatore può instradare un carico di lavoro verso Ceramic.ai e un altro verso Exa o Linkup. L'applicazione non deve modificare la propria integrazione complessiva ogni volta che cambia il provider selezionato.
Cloudflare descrive ciascun provider come adatto a un diverso profilo di recupero. La sua documentazione sui provider afferma che Ceramic.ai gestisce un indice indipendente di oltre 40 miliardi di pagine. Restituisce descrizioni lunghe che possono fornire un contesto sostanziale a un agente.
Exa combina metodi basati su parole chiave con la ricerca basata su embedding, che confronta rappresentazioni semantiche anziché fare affidamento solo sui termini corrispondenti. Cloudflare lo configura affinché restituisca evidenziazioni pertinenti alla query dalle pagine recuperate. Questo formato si adatta ai prompt che necessitano di evidenze concise.
Linkup restituisce estratti con fonti attraverso una modalità di ricerca rapida senza generare una risposta sintetizzata. Questo mantiene il recupero separato dal ragionamento. L'applicazione può decidere quale modello analizza i risultati e come appaiono le citazioni.
Queste differenze danno a Cloudflare una ragione per supportare più provider. La qualità della ricerca non è monodimensionale. Aggiornamento, copertura dell'indice, rilevanza semantica, latenza, lunghezza degli estratti e selezione delle fonti possono essere ciascuno più importanti per compiti diversi.
La stessa diversità complica anche il prodotto. Una risposta normalizzata non rende equivalenti i provider. Gli sviluppatori necessitano comunque di valutazioni che misurino se ciascun servizio recupera le evidenze corrette per il proprio dominio.
Cloudflare esercita quindi pressione sulle società di ricerca in due direzioni. Offre loro distribuzione attraverso una piattaforma per sviluppatori consolidata, ma le presenta anche come opzioni intercambiabili dietro un'interfaccia comune. Ciò può spostare parte della relazione con il cliente verso il gateway.
I provider di modelli affrontano una sfida diversa. I loro strumenti di ricerca integrati possono ottimizzare insieme recupero e generazione. L'approccio di Cloudflare sostiene che molti team daranno più valore alla portabilità, alla scelta indipendente del provider e a policy centralizzate che a un'esperienza strettamente integrata.
Vercel persegue una strategia correlata. Il suo AI Gateway ha recentemente aggiunto strumenti di search and fetch che funzionano tra i modelli che supportano le chiamate agli strumenti. La vicinanza temporale di questi lanci suggerisce che i gateway si stanno espandendo oltre il routing dei modelli per diventare livelli completi di strumenti per agenti.
Non è una competizione su chi abbia collegato per primo un modello alla ricerca. È una competizione su quale piattaforma governi la connessione. Il vincitore controlla credenziali, log, decisioni di routing, impostazioni di conservazione e la superficie di integrazione dello sviluppatore.
Il meccanismo è semplice, ma il cambiamento architetturale è più ampio
Cloudflare trasforma la ricerca in una primitiva di recupero riutilizzabile che le applicazioni possono invocare prima, durante o tra le chiamate ai modelli.
Un flusso di lavoro di base inizia con una domanda dell'utente. L'applicazione invia tale domanda, o una query derivata, a Web Search API. Riceve risultati strutturati e inserisce le descrizioni selezionate in un prompt del modello.
Un agente può anche decidere quando invocare il servizio. Lo sviluppatore definisce uno strumento funzione web_search, ovvero un'operazione richiamabile descritta al modello. Quando il modello richiede tale strumento, il codice dell'applicazione esegue la ricerca e restituisce i risultati.
Il modello riceve quindi una seconda chiamata di inferenza contenente la domanda originale e le evidenze recuperate. Questo schema viene spesso chiamato generazione aumentata da strumenti, perché il modello raccoglie informazioni esterne mentre completa un compito. Si distingue dal fare affidamento esclusivamente sulle conoscenze memorizzate nei parametri del modello.
Cloudflare afferma che gli strumenti server nativi arriveranno in seguito. Questi strumenti sposterebbero una maggiore parte dell'orchestrazione all'interno di AI Gateway. Per ora, gli sviluppatori devono implementare il ciclo che riceve una chiamata a uno strumento, esegue una ricerca e restituisce il risultato al modello.
Questa distinzione è importante. L'attuale beta offre un servizio di ricerca e controlli gateway comuni. Non fornisce ancora un agente di ricerca completamente gestito che determini le query, filtri le evidenze, risolva fonti in conflitto e componga una risposta con citazioni.
Il design autonomo conserva comunque vantaggi utili. I team possono ispezionare i risultati grezzi prima che raggiungano il modello. Possono rifiutare domini bloccati, richiedere fonti approvate, rimuovere pagine duplicate o limitare il recupero a documenti che soddisfano una policy di fiducia interna.
Un assistente di supporto offre un esempio pratico. Quando un cliente chiede informazioni su un'API modificata di recente, l'agente può cercare la documentazione aggiornata invece di rispondere partendo da uno snapshot di addestramento più vecchio. L'applicazione può conservare gli URL recuperati per la revisione.
Un agente software può utilizzare lo stesso schema per risolvere errori. Potrebbe cercare una nuova nota di rilascio, un'opzione di configurazione modificata o un avviso di compatibilità aggiornato. I risultati della ricerca diventano evidenze, mentre il modello resta responsabile dell'interpretazione di tali evidenze.
I prodotti di ricerca e monitoraggio possono inviare diverse query mirate. Una richiesta potrebbe individuare un annuncio ufficiale, un'altra potrebbe trovare documentazione e una terza potrebbe verificare la copertura giornalistica indipendente. Un buon flusso di lavoro confronta queste fonti invece di accettare il primo risultato.
I knowledge worker affrontano un problema correlato all'interno di materiali privati. Un sistema deve combinare gli sviluppi esterni con note, documenti e contesto organizzativo consolidato. Questo processo ricorda il knowledge blending, in cui una nuova evidenza diventa utile solo dopo essere stata collegata a informazioni di cui un utente si fida già.
Il gateway può registrare le chiamate di recupero coinvolte in tali flussi di lavoro. Ciò offre agli operatori un registro più chiaro quando una risposta fallisce. Possono chiedersi se la query fosse debole, se il provider abbia mancato una pagina, se l'estratto fosse privo di contesto o se il modello abbia interpretato male buone evidenze.
Questa separazione supporta una valutazione migliore. La qualità del recupero e la qualità della risposta possono essere misurate in modo indipendente. Senza questa distinzione, una risposta di bassa qualità rivela poco sul fatto che il problema sia stato causato dalla ricerca o dalla generazione.
Consente inoltre fallback graduali. Un’applicazione potrebbe interrogare un provider, verificare il numero di risultati e riprovare con un altro quando la copertura è debole. Cloudflare non ha affermato che la beta prenda automaticamente decisioni di qualità di questo tipo, quindi gli sviluppatori devono progettarle e testarle.
Lo stesso vale per la cache. Alcune domande sull’attualità diventano rapidamente obsolete, mentre le query su documentazione stabile possono riutilizzare i risultati. Un’applicazione responsabile necessita di policy per scadenze, aggiornamenti delle fonti e richieste ripetute.
Il supporto alla ricerca del gateway esistente di Cloudflare effettua già il proxy di strumenti nativi provenienti da diversi provider di modelli. La nuova API aggiunge una strada diversa: una chiamata di recupero agnostica rispetto al provider e indipendente da tali strumenti nativi.
Ciò significa che i team hanno ora due modelli di ricerca all’interno dell’ecosistema Cloudflare più ampio. Possono mantenere il comportamento dello strumento nativo di un provider di modelli oppure utilizzare la nuova API autonoma. La scelta giusta dipende da portabilità, controllo e da quanta orchestrazione un team desidera gestire direttamente.
Il meccanismo sembra una modesta aggiunta all’API. Sul piano architetturale, attribuisce alla ricerca lo stesso status dell’inferenza, dello storage, delle code e di altri servizi componibili. Gli agenti possono trattare le informazioni web aggiornate come infrastruttura, anziché come una funzionalità speciale inclusa in un singolo modello.
AI Gateway Web Search alza la posta dell’osservabilità
I log centralizzati sono più preziosi quando i team possono collegare un’affermazione generata agli esatti passaggi di recupero che la supportano.
Cloudflare presenta AI Gateway come il piano di controllo per le applicazioni basate su modelli. Offre già visibilità sulle richieste, controlli di sicurezza e gestione dell’utilizzo. L’aggiunta del recupero estende questa osservabilità a una fase che spesso determina se una risposta è aggiornata.
Un modello può ragionare con attenzione e produrre comunque una risposta errata quando le sue prove sono incomplete. La ricerca può restituire una pagina obsoleta, un articolo copiato o un risultato che usa il vocabolario corretto ma tratta un altro argomento. Gli operatori hanno bisogno di visibilità prima di poter distinguere questi fallimenti.
Gli identificatori delle richieste e i metadati sulla latenza forniscono un punto di partenza. Possono aiutare a correlare ricerche lente o non riuscite a una specifica esecuzione dell’agente. I log possono anche rivelare se un’applicazione emette query superflue o recupera ripetutamente le stesse pagine.
Tuttavia, la registrazione del traffico di ricerca crea proprie questioni di governance. Le query degli utenti possono rivelare piani riservati, nomi di clienti, incidenti di sicurezza, preoccupazioni mediche o dettagli di progetti interni. Un gateway centralizzato deve quindi chiarire i confini di accesso e il comportamento di conservazione dei dati.
Cloudflare afferma che tutti e tre i partner di lancio supportano Zero Data Retention per le richieste instradate tramite questo servizio. Zero Data Retention significa che un provider non conserva i dati delle richieste dopo l’elaborazione secondo l’accordo applicabile. Non risponde automaticamente a ogni questione di privacy lungo l’intera applicazione.
Lo sviluppatore controlla ancora ciò che entra nella query. Cloudflare continua a gestire il gateway e i suoi log. Il provider del modello finale riceve qualsiasi contesto recuperato che l’applicazione invia. Ogni fase richiede una policy sui dati deliberata.
Anche il supporto bring-your-own-key richiede una configurazione attenta. La documentazione di Cloudflare afferma che un alias esplicito fa fallire la richiesta quando quella chiave non è disponibile. Senza un alias esplicito, il gateway può usare una chiave predefinita configurata o i crediti gateway disponibili.
Questo comportamento offre praticità, ma i team dovrebbero decidere se il fallback sia accettabile. Un carico di lavoro regolamentato può richiedere uno specifico accordo con un provider. Lo spostamento silenzioso verso un altro percorso commerciale può entrare in conflitto con i controlli interni, anche quando il risultato tecnico è valido.
L’osservabilità deve inoltre conservare dettagli sufficienti per la valutazione senza archiviare dati sensibili in eccesso. Conteggi e latenza da soli non possono spiegare i fallimenti di rilevanza. Query complete e frammenti di risultati offrono maggiore valore diagnostico, ma aumentano anche l’esposizione.
Il giusto equilibrio varierà in base all’applicazione. Un assistente pubblico per le notizie può registrare più dettagli sul recupero rispetto a un sistema interno di ricerca legale. Il vantaggio di Cloudflare dipende dalla possibilità per gli amministratori di esprimere queste differenze tramite policy comprensibili.
Il controllo operativo include anche la prevenzione degli abusi. Un agente bloccato in un ciclo di strumenti può emettere molte ricerche ripetute. Limiti di frequenza, budget per le richieste e autorizzazioni per applicazione sono importanti perché il recupero può diventare una quota significativa dell’attività di un agente.
I log centralizzati aiutano a identificare tale comportamento. Non lo prevengono da soli. I team necessitano comunque di un numero massimo di chiamate agli strumenti, timeout, policy sui domini e condizioni di arresto chiare nel proprio framework di agenti.
Lo stesso principio vale per la sicurezza. I risultati di ricerca contengono testo non attendibile e le pagine web possono includere istruzioni pensate per manipolare un agente. La prompt injection si verifica quando contenuti esterni cercano di sovrascrivere le regole previste da un’applicazione.
Una risposta di ricerca normalizzata non neutralizza i contenuti malevoli. Il modello può comunque interpretare un frammento ostile come un’istruzione. Gli sviluppatori dovrebbero etichettare il materiale recuperato come prova, limitare le azioni disponibili dopo il recupero ed evitare di inserire segreti in contesti abilitati agli strumenti.
La nuova API rende più facile centralizzare queste pratiche, ma non può sostituirle. Cloudflare sta vendendo un punto di controllo migliore. I clienti restano responsabili del comportamento dell’agente che opera dietro quel punto.
Le regole per i crawler creano una promessa utile e un test difficile
Cloudflare lega il lancio a un crawling responsabile, ma la conformità non garantisce risultati di ricerca completi, accurati o rappresentativi.
L’azienda richiede ai provider partecipanti di identificare i propri crawler, rispettare robots.txt e includere collegamenti ai contenuti recuperati. Afferma inoltre che i crawler dei provider devono soddisfare i requisiti Cloudflare per i bot verificati.
Un bot verificato è un servizio automatizzato la cui identità è stata confermata da Cloudflare. La verifica offre agli operatori dei siti un segnale più chiaro quando decidono se consentire o bloccare un crawler. Riduce l’ambiguità rispetto al traffico non identificato che afferma di rappresentare un’azienda di ricerca.
Cloudflare presenta questo come uno standard per una relazione più equa tra i servizi di ricerca AI e gli editori. La policy offre ai creatori maggiore visibilità su chi accede alle loro pagine. I link alle fonti rendono inoltre possibile per gli utenti ispezionare il materiale sottostante.
Questi impegni distinguono il lancio dallo scraping opaco. Sono particolarmente rilevanti perché gli editori mettono sempre più in discussione il modo in cui i sistemi AI acquisiscono, riassumono e commercializzano i contenuti web. I provider di ricerca necessitano di accesso, mentre i proprietari dei siti desiderano un controllo applicabile.
Il compromesso è che un crawling rispettoso può ridurre la copertura. Alcuni siti bloccano l’accesso automatizzato, limitano particolari bot o collocano il materiale dietro autenticazione. I risultati di ricerca possono riflettere solo le pagine che un provider ha indicizzato e che gli è rimasto consentito utilizzare.
I tre provider possono quindi restituire visioni diverse del web. Operano indici, sistemi di ranking, calendari di aggiornamento e processi di generazione degli snippet separati. Uno schema API condiviso nasconde questi dettagli di implementazione senza eliminarne gli effetti.
L’attribuzione delle fonti presenta un’altra sfida. Restituire un URL è necessario, ma non dimostra che una risposta generata rappresenti accuratamente la pagina. Le applicazioni devono preservare il collegamento tra ogni affermazione e il risultato che la supporta.
Il modello finale può combinare diversi snippet in una dichiarazione che nessuna fonte supporta esplicitamente. Può anche trascurare le date di pubblicazione o confondere un documento aggiornato con una versione precedente. La presenza di citazioni non deve essere scambiata per accuratezza delle citazioni.
Il ranking della ricerca aggiunge ulteriore incertezza. Le pagine altamente ottimizzate possono superare nelle classifiche le fonti primarie. Le copie distribuite in syndication possono apparire più in evidenza rispetto alla cronaca originale. Una descrizione recuperata può omettere avvertenze che diventano evidenti nella pagina completa.
L’API attuale di Cloudflare restituisce risultati di ricerca anziché una verifica dell’intera pagina. Un’applicazione che richiede un’elevata affidabilità dovrebbe recuperare le pagine importanti, ispezionarne i contenuti, confrontare le date e preferire i documenti primari. Una chiamata di ricerca è scoperta, non prova.
Anche la latenza può influenzare le decisioni sulla qualità. Gli agenti spesso operano con budget di tempo di risposta, quindi gli sviluppatori possono selezionare un provider rapido o fermarsi dopo il primo risultato plausibile. Questa ottimizzazione può entrare in conflitto con la necessità di verificare un’affermazione sensibile tramite più fonti.
Lo stato beta è importante in questo caso. Cloudflare ha documentato l’interfaccia e le caratteristiche dei provider, ma le prove pubbliche sulla rilevanza comparativa restano limitate. Gli sviluppatori dovrebbero trattare le descrizioni dei provider come indicazioni di progettazione, non come classifiche delle prestazioni verificate indipendentemente.
Non esiste inoltre un benchmark universale per ogni applicazione. Un provider che offre buone prestazioni sulla documentazione software potrebbe avere difficoltà con notizie locali, letteratura scientifica o oscure comunicazioni societarie. I team necessitano di set di test tratti dalle proprie query previste.
Una valutazione utile dovrebbe registrare se appare la pagina corretta, quanto in alto si posiziona, quanto è aggiornata e se lo snippet conserva il contesto essenziale. Dovrebbe inoltre testare pagine avversarie, nomi ambigui e query con risposte mutevoli.
Il costo appartiene a tale valutazione anche quando i termini commerciali esatti variano. I workflow agentici possono moltiplicare una domanda dell’utente in diverse ricerche e chiamate al modello. I team dovrebbero misurare il costo totale dell’attività anziché confrontare una richiesta isolata.
Il posizionamento senza ricarico di Cloudflare riduce una preoccupazione, ma non determina il valore. Un percorso di recupero più costoso può valere la pena se evita chiamate aggiuntive o migliora l’accuratezza della risposta. Un percorso più economico può diventare costoso quando risultati deboli attivano nuovi tentativi.
Lo standard per i crawler resta comunque una parte significativa dell’annuncio. Cloudflare sfrutta la propria posizione tra siti e client automatizzati per stabilire requisiti di partecipazione. Il test consiste nel verificare se tali regole producano un recupero responsabile senza creare punti ciechi che gli sviluppatori non riescono a notare.
Cosa dovrebbero osservare gli sviluppatori dopo il lancio della beta
La prossima fase mostrerà se Cloudflare Web Search API diventerà una primitiva di gateway duratura o resterà un comodo wrapper attorno agli endpoint dei partner.
Il primo segnale è l’arrivo di strumenti server nativi. Cloudflare afferma che la ricerca web sarà tra i primi strumenti integrati direttamente nel piano di controllo di AI Gateway. Questa release ridurrebbe il codice di orchestrazione che gli sviluppatori gestiscono attualmente.
Un’implementazione utile di strumenti server deve fare più che nascondere una chiamata di funzione. Gli sviluppatori dovrebbero osservare come gestisce autorizzazioni degli strumenti, utilizzi massimi, nuovi tentativi, timeout, provenienza dei risultati e selezione del provider. Questi controlli determinano se i team possano usarla in sicurezza negli agenti di produzione.
Se gli strumenti server preservano un comportamento comune tra i modelli, la tesi del gateway di Cloudflare si rafforza. La piattaforma gestirebbe sia l’accesso ai modelli sia l’orchestrazione del recupero. Se ogni modello richiede ancora una gestione personalizzata sostanziale, il vantaggio si riduce a fatturazione e osservabilità.
Il secondo segnale è una portabilità dei provider misurabile. Il formato di risposta condiviso di Cloudflare fa sembrare semplice il passaggio a livello di API. La portabilità reale richiede qualità dei risultati comparabile, gestione degli errori prevedibile e comportamento stabile sotto carico di produzione.
I team dovrebbero eseguire gli stessi set di query tramite Ceramic.ai, Exa e Linkup. Dovrebbero confrontare copertura delle fonti, aggiornamento, ranking, latenza e utilità degli snippet. Dovrebbero inoltre ispezionare come i risultati cambiano per domande ambigue o avversarie.
I punti di forza specifici dei provider sono preziosi solo quando gli sviluppatori possono selezionarli deliberatamente. Se la maggior parte delle applicazioni resta sul valore predefinito senza valutazione, l’elemento marketplace diventa meno significativo. Se i team instradano in base al carico di lavoro, Cloudflare acquisisce un ruolo di coordinamento difendibile.
Il terzo segnale è la risposta della concorrenza. Vercel espone già strumenti di ricerca a livello di gateway, mentre le aziende dei modelli continuano a migliorare la navigazione nativa. Altre piattaforme cloud possono combinare ricerca, modelli e runtime per agenti all’interno dei propri control plane.
Osservate se questi concorrenti aggiungeranno altri fornitori di retrieval indipendenti, strumenti di valutazione più solidi o formati di citazione unificati. Questa reazione indicherà se la ricerca agnostica rispetto al fornitore diventerà una funzionalità standard dei gateway o un elemento di differenziazione temporaneo.
Gli sviluppatori dovrebbero inoltre monitorare i cambiamenti nelle policy per i bot e nei controlli degli editori. La qualità del retrieval dipende dal mantenimento dell’accesso a fonti utili. Un divario crescente tra contenuti sottoponibili a crawling e contenuti con accesso limitato influenzerebbe ogni fornitore, anche quando ciascun crawler segue le regole dichiarate.
Per una prova iniziale, scegliete un’attività con risposte che cambiano spesso e con fonti primarie identificabili. Note di rilascio, stato dei servizi, documentazione dei prodotti e comunicazioni pubbliche offrono obiettivi di valutazione più chiari rispetto a quesiti generici basati su opinioni.
Create un piccolo benchmark prima di integrare la ricerca in un agente rivolto agli utenti. Registrate la fonte prevista, una data di pubblicazione accettabile e i fatti che una risposta corretta deve includere. Quindi testate separatamente il retrieval e la generazione.
Conservate gli URL delle fonti nell’interfaccia dell’applicazione ogni volta che è possibile. Gli utenti dovrebbero poter esaminare le prove, soprattutto quando una risposta influisce su una decisione significativa. Una citazione dovrebbe supportare un’affermazione specifica, anziché decorare un’intera risposta.
Stabilite un budget di ricerca per ciascuna attività. Limitate le query ripetute, interrompete le chiamate circolari agli strumenti e richiedete un’ulteriore conferma prima che un agente compia un’azione esterna. La ricerca fornisce nuove informazioni a un modello, ma non conferisce autorità a tali informazioni.
Il lancio di Introducing Web Search API via AI Gateway chiede in definitiva agli sviluppatori di riconsiderare dove debba collocarsi la ricerca. È una funzionalità di un modello, un rapporto diretto con un fornitore o un servizio condiviso controllato dalla piattaforma applicativa?
Cloudflare ha presentato un argomento credibile a favore del modello di servizio condiviso. La beta combina tre fornitori, un’unica interfaccia, log del gateway, gestione delle credenziali e standard espliciti per i crawler. Il suo valore dipenderà dall’affidabilità, dalla qualità del retrieval e dal promesso livello di strumenti server.
Per i team che utilizzano già AI Gateway o Workers, il passo pratico successivo è una valutazione controllata su query reali. Confrontate i tre fornitori, esaminate ogni fonte e misurate gli esiti completi delle attività. Un livello di ricerca indipendente migliorerà il vostro agente, oppure un ulteriore confine del gateway creerà più lavoro di quanto ne elimini?
