Usa la ricerca web nativa del modello per prototipi rapidi e domande estemporanee, e un'API di ricerca dedicata quando la ricerca fa parte di un flusso di prodotto, deve essere verificabile o alimenta decisioni viste dall'utente. La scelta non riguarda davvero il prezzo. Riguarda controllo e osservabilità: la ricerca nativa fonde recupero e ragionamento in un'unica scatola nera, mentre un'API di ricerca ti consegna i risultati grezzi prima che il modello li tocchi.
La regola di decisione
Scegli la ricerca web nativa (ChatGPT browse, grounding di Gemini, ricerca web di Claude) quando stai prototipando, rispondi a domande isolate o costruisci un Q&A a basso rischio dove una risposta sbagliata infastidisce ma non costa cara. Si spedisce prima, non c'è nulla da cablare e il modello formula la query al posto tuo.
Scegli un'API di ricerca dedicata quando è vera anche solo una di queste:
- La ricerca è un passo ripetibile di un prodotto, non una comodità di chat.
- Devi registrare cosa è stato cercato, cosa è tornato, quanto ci ha messo e quanto è costato.
- Un errore di recupero incide su una decisione vista dall'utente (una raccomandazione, un prezzo, una citazione, una risposta di supporto).
- Devi valutare la qualità del recupero separatamente dalla qualità della risposta.
Se ne sono vere due o più, prendi il controllo del livello di recupero.
Perché la ricerca nativa nasconde proprio ciò che devi debuggare
Quando un modello naviga da solo e restituisce una risposta sbagliata, non puoi sapere dove si è rotto. Ha cercato i termini sbagliati? Ha avuto buoni risultati e ragionato male? Ha avuto risultati pessimi e ragionato bene? La ricerca nativa fonde la costruzione della query, il recupero e il ragionamento, quindi una singola risposta sbagliata non ti dà alcun segnale su quale fase abbia fallito. Non puoi registrare i risultati grezzi perché non li vedi mai. Non puoi riordinare, perché il ranking è già avvenuto dentro il modello. Non puoi aggiungere un fallback quando i risultati sono scarsi, perché non sai che lo erano.
Un'API di ricerca dedicata separa tutto questo. Costruisci la query in modo deterministico, vedi i risultati organici grezzi, le ricerche correlate e il knowledge graph prima che qualunque modello li legga, e registri ogni query con i suoi risultati, latenza e costo. Quando qualcosa va storto, rispondi "era recupero o ragionamento?" con i dati invece che con un'intuizione.
Dove la ricerca nativa vince davvero
Non aggiungere un'API che non ti serve. Per un assistente di ricerca veloce che un utente lancia un paio di volte al giorno, la ricerca nativa è la scelta migliore. Nessuna chiave da gestire, nessuna quota da sorvegliare, nessun codice di recupero da mantenere, e la riscrittura della query del modello stesso è discreta. Se stai testando se un'idea di agente funziona del tutto, la ricerca nativa ti porta a una demo in un pomeriggio. Nel momento in cui quella demo diventa un prodotto da cui le persone dipendono, i conti pendono verso il controllo del recupero.
Un'altra nota onesta: la ricerca nativa spesso basta per l'ampiezza. Se vuoi che un modello scorra dieci fonti a caso e riassuma un tema generale, la comodità di solito batte il controllo. Il controllo conta quando la stessa query gira mille volte al giorno e i risultati guidano qualcosa di reale.
Controllare il livello di recupero con una sola chiamata
Ecco il cuore. Chiami l'endpoint Google di Scavio, ricevi risultati strutturati e li registri prima che il modello veda alcunché.
import requests, json, time
API_KEY = "sk_live_your_key"
query = "best vector database for rag 2026"
start = time.time()
res = requests.post(
"https://api.scavio.dev/api/v1/google",
headers={"Authorization": f"Bearer {API_KEY}"},
json={"query": query, "light_request": False},
)
data = res.json()
latency_ms = round((time.time() - start) * 1000)
# log raw retrieval BEFORE any model reads it
log = {
"query": query,
"latency_ms": latency_ms,
"organic": [r["link"] for r in data.get("organic", [])],
"people_also_ask": data.get("people_also_ask", []),
"related_searches": data.get("related_searches", []),
}
print(json.dumps(log, indent=2))
# now hand the raw results to your model, rerank, or fall back
context = "\n".join(f"- {r['title']}: {r['snippet']}" for r in data.get("organic", []))Il corpo con light_request: False restituisce risultati organici, people_also_ask, knowledge_graph e related_searches. Poiché detieni la risposta grezza, puoi riordinare in base ai tuoi segnali, scartare domini di bassa qualità, ripiegare su una seconda query quando i risultati sono scarsi e archiviare tutto per una valutazione successiva. Il modello vede solo ciò che hai deciso di passargli.
Quanto costa farlo girare
Scavio è a crediti, a 0,005 $ a credito, con 50 crediti gratis all'iscrizione e 7.000 crediti per 30 $/mese. Abbastanza per cablare il livello di recupero e far girare traffico reale mentre misuri se controllarlo migliora davvero le tue risposte. Per confronto, il piano gratuito di Tavily è di 1.000 crediti al mese con ricerca avanzata a 2 crediti, ed Exa offre 1.000 gratis al mese con ricerca più contenuti a 7 $ ogni 1.000. Scegli quella la cui forma del risultato e prezzo si adattano al tuo flusso. La domanda non è quale fornitore, ma se puoi vedere e registrare cosa ha cercato il tuo agente.
In sintesi
Ricerca web nativa per prototipi, domande estemporanee e ampiezza. Un'API di ricerca dedicata quando la ricerca è un passo del prodotto, deve essere verificabile o guida una decisione vista dall'utente. Se non puoi rispondere "il guasto era recupero o ragionamento?", hai già superato la ricerca nativa.