Einem LLM frische Webdaten geben: SERP-APIs für RAG und Grounding

Jedes Modell hat einen Trainings-Cutoff, und die Lücke zwischen diesem Datum und heute wird nur größer. Grounding behebt das genauso, wie es das seit Retrieval-Augmented Generation ein Standardmuster wurde: erst suchen, lesen, was zurückkommt, dann daraus antworten.

Die Mechanik ist einfach. Der Teil, der es wert ist, durchdacht zu werden, sind die Betriebskosten, denn diese Zahl verhält sich sehr unterschiedlich, je nachdem, wer den Suchschritt kontrolliert.

Der Retrieval-Schritt, konkret

Query rein, organische Ergebnisse raus, die lesenswerten Seiten holen, dem Modell ein Kontextfenster statt einen Trainings-Cutoff geben:

import requests

API_KEY = "faf_live_..."

def ground(query, top_n=3):
    serp = requests.get(
        "https://api.fastaf.co/v1/serp",
        params={"query": query, "results": top_n},
        headers={"Authorization": f"Bearer {API_KEY}"},
        timeout=60,
    )
    serp.raise_for_status()
    links = [r["link"] for r in serp.json().get("organic_results", [])[:top_n]]

    context = []
    for link in links:
        page = requests.get(
            "https://api.fastaf.co/v1/scrape",
            params={"url": link},
            headers={"Authorization": f"Bearer {API_KEY}"},
            timeout=60,
        )
        if page.status_code == 200:
            context.append({"url": link, "text": page.json().get("text", "")[:4000]})

    return context


sources = ground("latest changes to the EU AI Act")
prompt = "\n\n".join(f"Source: {s['url']}\n{s['text']}" for s in sources)
# `prompt` als Kontext an deinen LLM-Call übergeben, zusammen mit der ursprünglichen Frage

/serp kostet 5 Credits, /scrape kostet 1 Credit für eine statische Seite (5 mit dynamic=true, wenn eine Quelle JS-Rendering braucht). Eine gegroundete Antwort mit drei Quellen sind 5 + 3 = 8 Credits, fest, jedes Mal, unabhängig davon, was das Modell mit dem Ergebnis macht.

Warum die eingebauten Such-Tools etwas kosten, das du nicht im Voraus kalkulieren kannst

Beide großen Anbieter liefern inzwischen ein Such-Tool aus, das das Modell selbstständig aufrufen kann. Anthropics Dokumentation zum Web-Search-Tool, geprüft im August 2026, bepreist es mit “$10 pro 1.000 Suchen, plus Standard-Tokenkosten für durch die Suche erzeugten Content.” OpenAIs Preisseite, im selben Monat geprüft, listet ihr Standard-Web-Search-Tool mit “$10,00 / 1k Calls + Suchinhalt-Tokens zu Modelltarifen abgerechnet.”

Keine der beiden Zahlen ist für sich das Problem. Das Problem ist, dass das Modell entscheidet, wie viele Suchen es pro Anfrage ausführt, und wie viel von jedem Ergebnis es liest. Ein Modell mit Such-Tool und einer schwierigen Frage kann eine Suche ausführen oder zehn, je nachdem, wie es die Aufgabe in diesem Moment einschätzt. Anthropics Docs sagen es direkt: “Einfache Faktenfragen nutzen typischerweise 1-3 Suchen; vergleichende oder Multi-Entity-Recherche kann 10 oder mehr nutzen.” Multipliziere diese Varianz mit Seiteninhalt, der zu Modell-Tokenraten abgerechnet wird, und die ehrliche Antwort auf “was wird das pro Query kosten” ist eine Spanne, keine Zahl, bis die Rechnung kommt.

Du kannst die Anzahl der Suchen pro Anfrage deckeln (beide Anbieter bieten dafür einen Parameter im Stil “max-uses”), was den Schaden eines einzelnen Calls begrenzt. Es macht die Kosten pro Query aber nicht vorhersehbar, weil die Tokenkosten weiterhin davon abhängen, wie viel von jeder Seite das Modell zu lesen entscheidet.

Retrieval selbst betreiben, stattdessen

/serp und /scrape direkt aus deinem eigenen Code aufzurufen umgeht die Varianz auf konkrete Weise: Du entscheidest top_n, du entscheidest, wie viel von jeder Seite behalten wird, bevor sie das Modell erreicht, und die Kreditkosten pro gegroundetem Call stehen in dem Moment fest, in dem du die Pipeline schreibst, nicht pro Anfrage nach dem eigenen Urteil des Modells.

Der andere Hebel ist der Key selbst. Credits sind auf einem FastAF-Key endlich und werden beim Start einer Anfrage reserviert, ein Agent, der sich verhakt (bei einem schlechten Ergebnis retryt, eine Frage in viele Suchen zerlegt, beim Replanning hängen bleibt), trifft also auf einen harten Stopp beim Guthaben dieses Keys, keine unbegrenzte Rechnung. Für einen KI-Agenten, der diese Pipeline als Tool aufruft, ist dieses endliche Guthaben der Ausgabendeckel: Bemesse einen Key nach dem Budget für diesen Agenten, und die Obergrenze wird von der API durchgesetzt, nicht davon, zu hoffen, dass der Prompt-Hinweis “sparsam suchen” hält.

def ground_with_budget(query, budget, top_n=3, cost_per_page=1):
    call_cost = 5 + top_n * cost_per_page  # /serp + /scrape pro Quelle
    if budget["spent"] + call_cost > budget["max_credits"]:
        return {"error": "grounding budget exhausted for this run"}

    budget["spent"] += call_cost
    return ground(query, top_n=top_n)

Kurzversion

Ein LLM in Live-Suche zu grounden ist ein Such-Call, eine Handvoll Seitenabrufe und ein Kontext-String, nichts Exotischeres als das. Was entscheidet, ob das billig und vorhersehbar ist oder ein unangenehmer Posten am Monatsende, ist, wer festlegt, wie viele Suchen und Abrufe passieren: ein Modell, das Zug um Zug argumentiert, oder eine Pipeline, die du mit festem top_n und einem Key mit endlichem Guthaben dahinter geschrieben hast. Die Kreditkosten pro Endpoint findest du unter Preise, und die vollständige Parameterliste für /serp und /scrape in den Docs.