Prova
5.000 ricerche
9,25 USD
1,85 USD/1K ricerche
- Integralo in un agente
- Stessa API del pack più grande
- I crediti non scadono mai
Risposta rapida
Come faccio il RAG con i risultati di ricerca dal web live?
Esegui una ricerca web al momento della domanda, leggi le pagine principali, suddividile in chunk, tieni i più rilevanti e chiedi al modello di rispondere con citazioni numerate. LLMWebSearch gestisce i primi due passaggi in una sola chiamata: risultati ordinati con le prime 3 pagine come Markdown, per un credito, da 1,20 USD/1K ricerche. Senza KYC; paghi in criptovalute.
Cos'è il RAG sul web live?
È una retrieval-augmented generation in cui il passaggio di retrieval è una ricerca web invece di una consultazione del tuo indice. La domanda va a una API di ricerca, la API restituisce pagine e il modello risponde da quelle pagine.
Lo schema si adatta alle domande su cose che cambiano: prezzi, rilasci, regole, orari e notizie. Si adatta anche alle domande di coda lunga che i tuoi documenti non hanno mai coperto. Il costo è una ricerca per domanda, o due quando la prima non trova nulla.
Quando conviene recuperare fresco e quando conservare?
Conserva ciò che è stabile e tuo; recupera ciò che cambia. Manuali di prodotto, policy interne e i tuoi documenti vanno in un indice vettoriale, aggiornato con una cadenza. Prezzi dei concorrenti, normative e notizie richiedono il retrieval live.
Molti team combinano entrambi. Cercano prima nel proprio indice e chiamano il web solo quando l'indice non ha una buona corrispondenza o quando la domanda cita una data recente.
Se decidi di conservare le pagine recuperate, tieni presente la nostra posizione: Non addestriamo alcun modello sulle tue query né su ciò che l'API restituisce, e non aggiungiamo regole nostre contro la conservazione dei risultati; restano validi i diritti dei siti di cui leggi le pagine. Controlla i termini di ogni sito prima di costruire una copia permanente del suo contenuto.
Come trasformo i risultati di ricerca in chunk?
Suddividi ogni pagina sui suoi titoli, poi taglia le sezioni lunghe a una lunghezza fissa. Il Markdown lo rende facile, perché i titoli sono righe che iniziano con #. Mantieni URL e titolo della fonte su ogni chunk, così le citazioni sopravvivono alla suddivisione.
L'esempio sotto cerca, legge tre pagine, le suddivide in chunk e sceglie i sei chunk che condividono più parole con la domanda. In produzione sostituisci il conteggio delle parole con il tuo modello di embedding; la struttura resta la stessa.
import os
import re
import requests
API = "https://llmwebsearch.com/api/v1/search"
HEADERS = {"Authorization": "Bearer " + os.environ["LLMWEBSEARCH_API_KEY"]}
def live_chunks(query, read=3, chunk_len=1200):
"""Search, then cut each page that was read into heading-based chunks tagged with its source."""
body = {"q": query, "max_results": 5, "read": read, "max_chars": 12000}
results = requests.post(API, headers=HEADERS, json=body, timeout=60).json()["results"]
chunks = []
for r in results:
if r.get("content_status") != "ok":
continue
for section in re.split(r"\n(?=#{1,3} )", r["content"]):
section = section.strip()
for start in range(0, len(section), chunk_len):
chunks.append({"url": r["url"], "title": r["title"], "text": section[start:start + chunk_len]})
return chunks
def top_chunks(chunks, question, k=6):
"""A plain keyword score; swap in your embedding model for better ranking."""
words = set(re.findall(r"\w{4,}", question.lower()))
def score(chunk):
return sum(1 for w in re.findall(r"\w{4,}", chunk["text"].lower()) if w in words)
return sorted(chunks, key=score, reverse=True)[:k]
def build_prompt(question):
picked = top_chunks(live_chunks(question), question)
urls = list(dict.fromkeys(c["url"] for c in picked))
blocks = [f"[{urls.index(c['url']) + 1}] {c['title']}\n{c['text']}" for c in picked]
sources = "\n".join(f"[{i}] {u}" for i, u in enumerate(urls, 1))
return (
"Use only the context to answer and cite sources as [n].\n\n"
+ "\n\n".join(blocks)
+ f"\n\nSources:\n{sources}\n\nQuestion: {question}"
)Quante pagine dovrebbe leggere ogni domanda?
Tre è un buon inizio e mantiene la ricerca a un credito. La maggior parte delle domande fattuali trova risposta nelle prime due o tre pagine di una buona query.
Chiedi pagine più lunghe di quanto faresti in un agente di chat, perché il chunker scarterà comunque la maggior parte del testo. Un max_chars da 10.000 a 15.000 per pagina dà al ranker abbastanza da scegliere. Se la risposta dipende da un sito noto, aggiungilo con include_domains invece di leggere più pagine.
Come faccio a far citare le fonti al modello?
Numera le fonti nel prompt e chiedi i numeri nella risposta. Un'istruzione breve funziona bene: usa solo il contesto, cita ogni affermazione come [n] e indica quando il contesto non copre la domanda.
Tieni l'elenco delle fonti alla fine del prompt, con un URL per ogni numero. Poi rendi [n] come link nella tua interfaccia. Gli utenti si fidano delle risposte che possono verificare, e le citazioni sbagliate sono facili da individuare in revisione.
E se una pagina è bloccata o vuota?
Saltala e usa le altre. Ogni risultato porta un content_status; solo i risultati ok hanno testo. Una pagina può mancare perché Il nostro reader rispetta robots.txt: si presenta come LLMWebSearch, segue le regole che un sito scrive per lui o per tutti i robot, e lascia fuori il contenuto di qualsiasi pagina che non gli è permesso leggere.
Quando tutte le pagine di una ricerca tornano vuote, riprova una volta con una query diversa o aggiungi include_domains per un sito che sai essere aperto. Quando un sito respinge il nostro reader, il risultato torna senza contenuto e con lo status del sito: non risolviamo mai CAPTCHA, non accediamo agli account e non aggiriamo un blocco o un paywall.
Quanto costa il RAG sul web live?
Una ricerca per domanda nella maggior parte dei casi. Un assistente di supporto che risponde a 5.000 domande al mese, con una seconda ricerca per una domanda su cinque, usa circa 6.000 ricerche. 25.000 ricerche a 41,25 USD copre quattro mesi così.
Anche il tuo modello legge i chunk che gli invii. Sei chunk da 1.200 caratteri aggiungono circa 2.000 token per domanda, che controlli tramite la dimensione e il numero dei chunk.
Quale pack è adatto a un carico di lavoro RAG?
Un credito per query nella maggior parte delle pipeline. I crediti di ricerca non hanno data di scadenza: quello che non usi questo mese è ancora lì l'anno prossimo.
Builder
25.000 ricerche
41,25 USD
1,65 USD/1K ricerche
- Un agente di coding o un assistente di ricerca
- Pronto per MCP, LangChain e n8n
- I crediti non scadono mai
Produzione
100.000 ricerche
145 USD
1,45 USD/1K ricerche
- Agenti in produzione
- Rate limit più alto su richiesta
- I crediti non scadono mai
In ogni piano: Prime 3 pagine lette come Markdown · Filtri per paese, lingua, tempo e dominio · Chiamate non riuscite non addebitate · I crediti non scadono mai
RAG sul web live: domande frequenti
Posso usare LangChain o LlamaIndex?
Sì. La pagina LangChain e LlamaIndex avvolge la ricerca come retriever e come tool.
Posso recuperare da URL che conosco già?
Sì, con l'endpoint extract. Leggere pagine di cui hai già gli URL costa 1 credito per ogni gruppo iniziato di 3 pagine restituite con contenuto, fino a 20 URL per chiamata; gli URL rifiutati o falliti non vengono contati.
LLMWebSearch memorizza le pagine che legge per me?
No. Ogni chiamata lascia una riga di log: l'ora, l'account, i primi 60 caratteri della query, quanti risultati e pagine sono stati restituiti, e i crediti. Le righe vengono cancellate dopo 30 giorni. Il contenuto delle pagine che leggiamo non viene conservato. Numero di account, ordini, top-up e totali dei crediti restano finché l'account esiste, poi solo per il tempo richiesto dalla legge contabile. Le autorità ricevono i registri solo quando una legge ci obbliga.
Posso limitare il recupero a una sola lingua o a un solo paese?
Sì. Imposta language e country, per esempio language=de e country=de per risultati in tedesco dalla Germania.