Ausprobieren
5.000 Suchanfragen
9,25 $
1,85 $/1K Suchanfragen
- In einen Agenten einbinden
- Gleiche API wie beim größten Paket
- Credits verfallen nie
Anwendungsfall · Retrieval-augmented Generation · frische Quellen
Ein Vektorindex enthält, was Sie letzten Monat geladen haben. Manche Fragen brauchen, was das Web heute sagt. Live-Web-RAG ruft zum Zeitpunkt der Frage ab: eine Suche, die Top-Seiten als Markdown, ein paar Chunks in den Prompt und Quellenangaben zurück zu jeder Seite.
Kurze Antwort
Wie mache ich RAG mit Live-Web-Suchergebnissen?
Führen Sie zum Zeitpunkt der Frage eine Websuche aus, lesen Sie die Top-Seiten, teilen Sie sie in Chunks auf, behalten Sie die relevantesten und bitten Sie das Modell, mit nummerierten Quellenangaben zu antworten. LLMWebSearch erledigt die ersten beiden Schritte in einem Aufruf: gerankte Ergebnisse mit den ersten 3 Seiten als Markdown, für einen Credit, ab 1,20 $/1K Suchanfragen. Ohne KYC; mit Krypto bezahlen.
Es ist Retrieval-augmented Generation, bei der der Retrieval-Schritt eine Websuche ist statt eines Lookups in Ihrem eigenen Index. Die Frage geht an eine Such-API, die API liefert Seiten zurück, und das Modell antwortet anhand dieser Seiten.
Das Muster eignet sich für Fragen zu Dingen, die sich ändern: Preise, Releases, Regeln, Zeitpläne und News. Es eignet sich auch für Long-Tail-Fragen, die Ihre eigenen Dokumente nie abgedeckt haben. Die Kosten sind eine Suche pro Frage, oder zwei, wenn die erste danebengreift.
Speichern Sie, was stabil und Ihr eigenes ist; rufen Sie ab, was sich ändert. Produkthandbücher, interne Richtlinien und Ihre eigenen Docs gehören in einen Vektorindex, der nach Zeitplan aktualisiert wird. Preise von Wettbewerbern, Vorschriften und News gehören zum Live-Retrieval.
Viele Teams kombinieren beides. Sie durchsuchen zuerst ihren eigenen Index und rufen das Web nur dann auf, wenn der Index keinen guten Treffer hat oder wenn die Frage ein aktuelles Datum nennt.
Wenn Sie sich entscheiden, abgerufene Seiten zu behalten, beachten Sie unsere Haltung: Wir trainieren kein Modell mit Ihren Suchanfragen oder mit dem, was die API zurückgibt, und wir stellen keine eigene Regel gegen das Speichern von Ergebnissen auf; die Rechte der Websites, deren Seiten Sie lesen, gelten weiterhin. Prüfen Sie die Bedingungen jeder Seite, bevor Sie eine dauerhafte Kopie ihrer Inhalte anlegen.
Teilen Sie jede Seite an ihren Überschriften auf und kürzen Sie lange Abschnitte auf eine feste Länge. Markdown macht das einfach, denn Überschriften sind Zeilen, die mit # beginnen. Behalten Sie Quell-URL und Titel an jedem Chunk, damit die Quellenangaben die Aufteilung überstehen.
Das folgende Beispiel sucht, liest drei Seiten, teilt sie in Chunks auf und wählt die sechs Chunks, die die meisten Wörter mit der Frage gemeinsam haben. Ersetzen Sie in der Produktion die Wortzählung durch Ihr Embedding-Modell; die Struktur bleibt gleich.
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}"
)Drei sind ein guter Anfang, und es hält die Suche bei einem Credit. Die meisten Faktenfragen werden auf den ersten zwei oder drei Seiten einer guten Suchanfrage beantwortet.
Fragen Sie längere Seiten an, als Sie es in einem Chat-Agenten tun würden, denn der Chunker verwirft ohnehin den Großteil des Textes. Ein max_chars von 10.000 bis 15.000 pro Seite gibt dem Ranker genug Auswahl. Wenn die Antwort von einer bekannten Seite abhängt, fügen Sie sie mit include_domains hinzu, statt mehr Seiten zu lesen.
Nummerieren Sie die Quellen im Prompt und verlangen Sie die Nummern in der Antwort. Eine kurze Anweisung funktioniert gut: nur den Kontext verwenden, jede Aussage als [n] zitieren und sagen, wenn der Kontext die Frage nicht abdeckt.
Halten Sie die Quellenliste am Ende des Prompts, mit einer URL pro Nummer. Rendern Sie dann [n] als Link in Ihrer Oberfläche. Nutzer vertrauen Antworten, die sie prüfen können, und falsche Quellenangaben fallen im Review leicht auf.
Überspringen Sie sie und nutzen Sie die anderen. Jedes Ergebnis trägt ein content_status; nur ok Ergebnisse haben Text. Eine Seite kann fehlen, weil Unser Reader respektiert robots.txt: Er stellt sich als LLMWebSearch vor, befolgt die Regeln, die eine Website für ihn oder für alle Roboter schreibt, und lässt den Inhalt jeder Seite aus, die er nicht lesen darf.
Wenn alle Seiten einer Suche leer zurückkommen, versuchen Sie es einmal mit einer anderen Suchanfrage erneut oder fügen Sie include_domains für eine Seite hinzu, von der Sie wissen, dass sie offen ist. Wenn eine Website unseren Reader abweist, kommt das Ergebnis ohne Inhalt und mit dem Status der Website zurück: Wir lösen niemals CAPTCHAs, melden uns nicht in Konten an und umgehen weder eine Sperre noch eine Paywall.
In den meisten Fällen eine Suche pro Frage. Ein Support-Assistent, der 5.000 Fragen im Monat beantwortet, mit einer zweiten Suche für jede fünfte Frage, verbraucht etwa 6.000 Suchen. 25.000 Suchanfragen zu 41,25 $ deckt vier solche Monate ab.
Ihr Modell liest außerdem die Chunks, die Sie ihm schicken. Sechs Chunks à 1.200 Zeichen fügen etwa 2.000 Tokens pro Frage hinzu, was Sie über Chunk-Größe und -Anzahl steuern.
Ein Credit pro Frage für die meisten Pipelines. Search-Credits verfallen nicht: Was Sie diesen Monat nicht verbrauchen, ist nächstes Jahr noch da.
5.000 Suchanfragen
9,25 $
1,85 $/1K Suchanfragen
25.000 Suchanfragen
41,25 $
1,65 $/1K Suchanfragen
100.000 Suchanfragen
145 $
1,45 $/1K Suchanfragen
In jedem Plan: Top-3-Seiten als Markdown gelesen · Filter für Land, Sprache, Zeit und Domain · Fehlgeschlagene Aufrufe werden nicht berechnet · Credits verfallen nie
Ja. Die Seite zu LangChain und LlamaIndex verpackt die Suche als Retriever und als Tool.
Ja, mit dem extract-Endpoint. Das Lesen von Seiten, deren URLs Sie bereits haben, kostet 1 Credit für jede angefangene Gruppe von 3 Seiten, die mit Inhalt zurückgegeben werden, bis zu 20 URLs pro Aufruf; abgelehnte oder fehlgeschlagene URLs werden nicht gezählt.
Nein. Jeder Aufruf hinterlässt eine Logzeile: die Zeit, das Konto, die ersten 60 Zeichen der Suchanfrage, wie viele Ergebnisse und Seiten zurückgegeben wurden und die Credits. Zeilen werden nach 30 Tagen gelöscht. Der Inhalt der von uns gelesenen Seiten wird nicht gespeichert. Kontonummer, Bestellungen, Aufladungen und Credit-Stände bleiben, solange das Konto besteht, danach nur so lange, wie es das Handelsrecht verlangt. Behörden erhalten Aufzeichnungen nur, wenn ein Gesetz uns dazu zwingt.
Ja. Setzen Sie language und country, zum Beispiel language=de und country=de für deutsche Ergebnisse aus Deutschland.
Ab 1,20 $/1K Suchanfragen · ohne KYC
API-Schlüssel erhalten