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
Caso de uso · generación aumentada por recuperación · fuentes recientes
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.
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.
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.
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.
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.
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}"
)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.
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.
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.
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.
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.
5.000 búsquedas
9,25 US$
1,85 US$/1K búsquedas
25.000 búsquedas
41,25 US$
1,65 US$/1K búsquedas
100.000 búsquedas
145 US$
1,45 US$/1K 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
Sí. La página de LangChain y LlamaIndex envuelve la búsqueda como un retriever y como una herramienta.
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.
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.
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