# RAG desde la web en vivo: recupera con una búsqueda, responde con citas > Generación aumentada por recuperación desde la web en vivo: busca, lee páginas como Markdown y responde con citas. Código Python. Sin KYC, cripto. - URL: https://llmwebsearch.com/es/use-cases/rag/ - Última actualización: 2026-10-22 - Editor: LLMWebSearch (https://llmwebsearch.com) 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. ## ¿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* ```python 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. | Plan | Cantidad | Precio | Precio por unidad | | --- | --- | --- | --- | | Probar | 5.000 búsquedas | 9,25 US$ | 1,85 US$/1K búsquedas | | Builder | 25.000 búsquedas | 41,25 US$ | 1,65 US$/1K búsquedas | | Producción | 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 **Antes de pagar** - Recarga mínima 25 US$. Recarga una vez con criptomonedas y luego compra cualquier plan con tu saldo. - El saldo de tu cuenta no caduca y compra créditos de búsqueda cuando quieras. Cuando un pack es más barato que la recarga mínima, la parte que pagaste solo para alcanzar ese mínimo se te devuelve si la solicitas en un plazo de 30 días desde el pago, en USDT o USDC, siempre que siga sin gastar. El resto del saldo no se reembolsa a menos que la ley lo exija. - Se acredita en cuanto comprobamos tu pago en la blockchain. Tiempo habitual de confirmación de la red: BTC ≈ 20 min · USDT TRC-20 ≈ 1 min · USDT ERC-20 ≈ 5 min · USDC ERC-20 ≈ 5 min · ETH ≈ 5 min · SOL ≈ 1 min · LTC ≈ 15 min ## RAG con la web en vivo: preguntas frecuentes ### ¿Puedo usar LangChain o LlamaIndex? Sí. La [página de LangChain y LlamaIndex](https://llmwebsearch.com/es/docs/langchain/) envuelve la búsqueda como un retriever y como una herramienta. ### ¿Puedo recuperar contenido de URLs que ya conozco? Sí, con el [endpoint extract](https://llmwebsearch.com/es/docs/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. --- LLMWebSearch: LLMWebSearch es una API de búsqueda web para agentes de IA que devuelve resultados clasificados con el contenido de las mejores páginas en Markdown, se paga con criptomonedas y sin subir documentos de identidad. Los créditos prepago desde 1,20 US$/1K búsquedas nunca caducan. Sin KYC: sin ID, sin selfie, sin documentos. Paga con criptomonedas.