Dar a un LLM datos web frescos: SERP APIs para RAG y grounding

Todo modelo tiene una fecha de corte de entrenamiento, y la brecha entre esa fecha y hoy solo crece. El grounding soluciona esto de la misma forma que lo hace desde que retrieval-augmented generation se convirtió en un patrón estándar: buscar primero, leer lo que llega, y luego responder a partir de eso.

La mecánica es sencilla. La parte que vale la pena pensar bien es lo que cuesta ejecutarlo, porque ese número se comporta de forma muy distinta según quién controle el paso de búsqueda.

El paso de retrieval, en concreto

Consulta que entra, resultados orgánicos que salen, obtienes las páginas que vale la pena leer, y le entregas al modelo una ventana de contexto en lugar de una fecha de corte:

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)
# pasa `prompt` a tu llamada al LLM como contexto, junto con la pregunta original

/serp cuesta 5 créditos, /scrape cuesta 1 crédito para una página estática (5 con dynamic=true si una fuente necesita renderizado JS). Una respuesta con grounding y tres fuentes son 5 + 3 = 8 créditos, fijos, siempre, sin importar lo que haga el modelo con el resultado.

Por qué las herramientas de búsqueda integradas cuestan algo que no puedes calcular de antemano

Los dos grandes proveedores ya incluyen una herramienta de búsqueda que el modelo puede invocar por su cuenta. La documentación de la herramienta de búsqueda web de Anthropic, comprobada en agosto de 2026, la cotiza a “$10 per 1,000 searches, plus standard token costs for search-generated content”. La página de precios de OpenAI, comprobada el mismo mes, lista su herramienta de búsqueda web estándar a “$10.00 / 1k calls + search content tokens billed at model rates”.

Ninguno de los dos números es el problema en sí. El problema es que el modelo decide cuántas búsquedas ejecutar por solicitud, y cuánto de cada resultado leer. Un modelo con herramienta de búsqueda y una pregunta difícil puede ejecutar una búsqueda o diez, según cómo razone la tarea en ese turno. La documentación de Anthropic lo dice directamente: “simple factual queries typically use 1-3 searches; comparative or multientity research can use 10 or more”. Multiplica esa variabilidad por el contenido de página facturado a las tarifas de tokens del modelo, y la respuesta honesta a “cuánto va a costar esto por consulta” es un rango, no un número, hasta que llega la factura.

Puedes limitar el número de búsquedas por solicitud (ambos proveedores exponen un parámetro tipo max-uses), lo que acota el radio de impacto de una sola llamada. Eso no hace que el coste por consulta sea predecible, porque el coste en tokens sigue escalando con cuánto de cada página decide leer el modelo.

Ejecutar el retrieval tú mismo, en cambio

Llamar a /serp y /scrape directamente desde tu propio código evita la variabilidad de una forma concreta: tú decides top_n, tú decides cuánto de cada página conservar antes de que llegue al modelo, y el coste en créditos por llamada con grounding queda fijado en el momento en que escribes el pipeline, no decidido solicitud a solicitud por el criterio del propio modelo.

La otra palanca es la clave misma. Los créditos son finitos en una clave de FastAF y se reservan al iniciar una solicitud, así que un agente que entra en bucle (reintenta ante un mal resultado, descompone una pregunta en muchas búsquedas, se queda replanificando) choca con un tope duro en el saldo de esa clave, no con una factura sin límite. Para un agente de IA que llama a este pipeline como herramienta, ese saldo finito es el límite de gasto: dimensiona una clave al presupuesto de ese agente, y el techo lo impone la API, no la esperanza de que el prompt que le dice “busca con moderación” se sostenga.

def ground_with_budget(query, budget, top_n=3, cost_per_page=1):
    call_cost = 5 + top_n * cost_per_page  # /serp + /scrape por fuente
    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)

En resumen

Anclar un LLM en búsqueda en vivo es una llamada de búsqueda, un puñado de fetches de página y una cadena de contexto, nada más exótico que eso. La parte que decide si esto es barato y predecible o una línea desagradable en la factura de fin de mes es quién elige cuántas búsquedas y fetches ocurren: un modelo razonando turno a turno, o un pipeline que escribiste tú con un top_n fijo y una clave con un saldo finito detrás. Consulta precios para el coste en créditos por endpoint, y la documentación para la lista completa de parámetros de /serp y /scrape.