Sin KYC — sin ID, sin selfie, sin documentos. Paga con criptomonedas: BTC, USDT, USDC, ETH, SOL, LTC
Idioma: Español
Obtén una clave API

Caso de uso · generación aumentada por recuperación · fuentes recientes

RAG desde la web en vivo: recupera con una búsqueda, responde con citas

Un índice vectorial contiene lo que cargaste el mes pasado. Algunas preguntas necesitan lo que la web dice hoy. El RAG desde la web en vivo recupera en el momento de la pregunta: una búsqueda, las páginas principales como Markdown, unos fragmentos en el prompt y citas que remiten a cada página.

Última actualización: · 7 min de lectura

Respuesta rápida

¿Cómo hago RAG con resultados de búsqueda de la web en vivo?

Ejecuta una búsqueda web en el momento de la pregunta, lee las páginas principales, divídelas en fragmentos, conserva los más relevantes y pide al modelo que responda con citas numeradas. LLMWebSearch resuelve los dos primeros pasos en una sola llamada: resultados ordenados con las 3 primeras páginas como Markdown, por un crédito, desde 1,20 US$/1K búsquedas. Sin KYC; paga con criptomonedas.

¿Qué es el RAG desde la web en vivo?

Es retrieval-augmented generation en la que el paso de recuperación es una búsqueda web en lugar de una consulta a tu propio índice. La pregunta va a una search API, la API devuelve páginas, y el modelo responde a partir de esas páginas.

El patrón encaja con preguntas sobre cosas que cambian: precios, lanzamientos, normas, horarios y noticias. También encaja con preguntas de cola larga que tus propios documentos nunca cubrieron. El coste es una búsqueda por pregunta, o dos cuando la primera falla.

¿Cuándo debo obtener datos frescos y cuándo almacenarlos?

Almacena lo estable y tuyo; obtén lo que cambia. Los manuales de producto, las políticas internas y tus propios documentos van en un índice vectorial, actualizado según una programación. Los precios de la competencia, la normativa y las noticias corresponden a la recuperación en vivo.

Muchos equipos combinan ambos. Buscan primero en su propio índice y llaman a la web solo cuando el índice no tiene una buena coincidencia, o cuando la pregunta menciona una fecha reciente.

Si decides conservar las páginas que recuperaste, ten en cuenta nuestra postura: No entrenamos ningún modelo con tus consultas ni con lo que devuelve la API, y no añadimos ninguna regla propia contra almacenar resultados; los derechos de los sitios cuyas páginas lees siguen aplicándose. Revisa los términos de cada sitio antes de crear una copia permanente de su contenido.

¿Cómo convierto los resultados de búsqueda en fragmentos?

Divide cada página por sus encabezados y recorta las secciones largas a una longitud fija. Markdown lo facilita, porque los encabezados son líneas que empiezan por #. Conserva la URL de origen y el título en cada fragmento para que las citas sobrevivan a la división.

El ejemplo siguiente busca, lee tres páginas, las divide en fragmentos y elige los seis fragmentos que comparten más palabras con la pregunta. En producción, sustituye el recuento de palabras por tu modelo de embeddings; la estructura sigue igual.

Python: recuperación desde la web en vivo con fragmentos y fuentes numeradas
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}"
    )

¿Cuántas páginas debe leer cada pregunta?

Tres es un buen comienzo y mantiene la búsqueda en un crédito. La mayoría de las preguntas fácticas se responden en las dos o tres primeras páginas de una buena consulta.

Pide páginas más largas de lo que harías en un agente de chat, porque el divisor de fragmentos descartará la mayor parte del texto de todos modos. Un max_chars de 10.000 a 15.000 por página da suficiente al ranker para elegir. Si la respuesta depende de un sitio conocido, añádelo con include_domains en lugar de leer más páginas.

¿Cómo hago que el modelo cite sus fuentes?

Numera las fuentes en el prompt y pide los números en la respuesta. Una instrucción breve funciona bien: usa solo el contexto, cita cada afirmación como [n] e indica cuándo el contexto no cubre la pregunta.

Deja la lista de fuentes al final del prompt, con una URL por número. Luego muestra [n] como enlace en tu interfaz. Los usuarios confían en las respuestas que pueden comprobar, y las citas erróneas son fáciles de detectar en revisión.

¿Y si una página está bloqueada o vacía?

Ovídala y usa las demás. Cada resultado lleva un content_status; solo los resultados ok tienen texto. Puede faltar una página porque Nuestro lector respeta robots.txt: se identifica como LLMWebSearch, sigue las reglas que un sitio escribe para él o para todos los robots, y deja fuera el contenido de cualquier página que no tenga permitido leer.

Cuando todas las páginas de una búsqueda vuelven vacías, reinténtalo una vez con una consulta distinta o añade include_domains para un sitio que sepas que está abierto. Cuando un sitio rechaza a nuestro lector, el resultado vuelve sin contenido y con el estado del sitio: nunca resolvemos CAPTCHAs, iniciamos sesión en cuentas ni sorteamos un bloqueo o un paywall.

¿Cuánto cuesta el RAG desde la web en vivo?

Una búsqueda por pregunta en la mayoría de los casos. Un asistente de soporte que responde 5.000 preguntas al mes, con una segunda búsqueda en una de cada cinco preguntas, usa unas 6.000 búsquedas. 25.000 búsquedas a 41,25 US$ cubre cuatro meses de ese tipo.

Tu modelo también lee los fragmentos que le envías. Seis fragmentos de 1.200 caracteres añaden unos 2.000 tokens por pregunta, algo que controlas con el tamaño y el número de fragmentos.

¿Qué pack se adapta a una carga de trabajo RAG?

Un crédito por pregunta en la mayoría de los pipelines. Los créditos de búsqueda no caducan: lo que no uses este mes seguirá ahí el año que viene.

Probar

5.000 búsquedas

9,25 US$

1,85 US$/1K búsquedas

  • Conéctala a un agente
  • La misma API que el pack más grande
  • Los créditos nunca caducan
Elige 5.000 búsquedas

Builder

25.000 búsquedas

41,25 US$

1,65 US$/1K búsquedas

  • Un agente de programación o un asistente de investigación
  • Listo para MCP, LangChain y n8n
  • Los créditos nunca caducan
Elige 25.000 búsquedas

Producción

100.000 búsquedas

145 US$

1,45 US$/1K búsquedas

  • Agentes en producción
  • Límite de peticiones más alto bajo solicitud
  • Los créditos nunca caducan
Elige 100.000 búsquedas

En todos los planes: 3 páginas principales leídas como Markdown · Filtros de país, idioma, hora y dominio · Las llamadas fallidas no se cobran · Los créditos nunca caducan

RAG con la web en vivo: preguntas frecuentes

¿Puedo usar LangChain o LlamaIndex?

Sí. La página de LangChain y LlamaIndex envuelve la búsqueda como un retriever y como una herramienta.

¿Puedo recuperar contenido de URLs que ya conozco?

Sí, con el endpoint extract. Leer páginas cuyas URL ya tienes cuesta 1 crédito por cada grupo iniciado de 3 páginas devueltas con contenido, hasta 20 URL por llamada; las URL rechazadas o fallidas no se cuentan.

¿LLMWebSearch almacena las páginas que lee por mí?

No. Cada llamada deja una línea de registro: la hora, la cuenta, los primeros 60 caracteres de la consulta, cuántos resultados y páginas se devolvieron, y los créditos. Las líneas se eliminan a los 30 días. El contenido de las páginas que leemos no se conserva. El número de cuenta, los pedidos, las recargas y los totales de créditos permanecen mientras exista la cuenta, y después solo durante el tiempo que exija la ley contable. Las autoridades reciben registros solo cuando una ley nos obliga.

¿Puedo restringir la recuperación a un solo idioma o país?

Sí. Configura language y country, por ejemplo language=de y country=de para obtener resultados en alemán de Alemania.

Desde 1,20 US$/1K búsquedas · sin KYC

Obtén una clave API