# RAG a partir da web ao vivo: recupere com uma pesquisa, responda com citações

> Pesquise na web ao vivo, leia as principais páginas como Markdown, divida em chunks e responda com citações. Código Python. Sem KYC, cripto.

- URL: https://llmwebsearch.com/pt/use-cases/rag/
- Última atualização: 2026-10-22
- Editor: LLMWebSearch (https://llmwebsearch.com)

Um índice vetorial guarda o que você carregou no mês passado. Algumas perguntas precisam do que a web diz hoje. O RAG de web ao vivo recupera no momento da pergunta: uma pesquisa, as principais páginas como Markdown, alguns chunks no prompt e citações de volta para cada página.

**Resposta rápida — Como faço RAG com resultados de pesquisa da web ao vivo?**

Faça uma pesquisa na web no momento da pergunta, leia as principais páginas, divida-as em chunks, mantenha os mais relevantes e peça ao modelo que responda com citações numeradas. **LLMWebSearch** cuida das duas primeiras etapas em uma única chamada: resultados classificados com as 3 primeiras páginas como Markdown, por um crédito, a partir de US$ 1,20/1K pesquisas. Sem KYC; pague com cripto.

## O que é RAG de web ao vivo?

É a geração aumentada por recuperação em que a etapa de recuperação é uma pesquisa na web em vez de uma consulta no seu próprio índice. A pergunta vai para uma API de pesquisa, a API retorna páginas e o modelo responde a partir dessas páginas.

O padrão serve para perguntas sobre coisas que mudam: preços, lançamentos, regras, cronogramas e notícias. Também serve para perguntas de cauda longa que seus próprios documentos nunca cobriram. O custo é uma pesquisa por pergunta, ou duas quando a primeira falha.

## Quando devo buscar dados recentes e quando devo armazenar?

Armazene o que é estável e seu; busque o que muda. Manuais de produtos, políticas internas e seus próprios documentos pertencem a um índice vetorial, atualizado em um cronograma. Preços de concorrentes, regulamentos e notícias pertencem à recuperação ao vivo.

Muitas equipes combinam os dois. Elas pesquisam primeiro no próprio índice e só consultam a web quando o índice não tem uma boa correspondência, ou quando a pergunta menciona uma data recente.

Se você decidir guardar páginas que recuperou, observe nossa posição: Não treinamos nenhum modelo com as suas consultas ou com o que a API retorna, e não adicionamos nenhuma regra própria contra armazenar resultados; os direitos dos sites cujas páginas você lê continuam valendo. Verifique os termos de cada site antes de criar uma cópia permanente do seu conteúdo.

## Como transformo resultados de pesquisa em chunks?

Divida cada página pelos seus títulos e depois corte seções longas em um comprimento fixo. O Markdown facilita isso, porque os títulos são linhas que começam com `#`. Mantenha a URL de origem e o título em cada chunk para que as citações sobrevivam à divisão.

O exemplo abaixo pesquisa, lê três páginas, as divide em chunks e escolhe os seis chunks que compartilham mais palavras com a pergunta. Substitua a contagem de palavras pelo seu modelo de embedding em produção; a estrutura permanece a mesma.

*Python: recuperação de web ao vivo com chunks e fontes 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}"
    )
```

## Quantas páginas cada pergunta deve ler?

Três é um bom começo, e mantém a pesquisa em um crédito. A maioria das perguntas factuais é respondida nas duas ou três primeiras páginas de uma boa consulta.

Peça páginas mais longas do que pediria em um agente de chat, porque o chunker vai descartar a maior parte do texto de qualquer forma. Um `max_chars` de 10.000 a 15.000 por página dá ao ranker material suficiente para escolher. Se a resposta depende de um site conhecido, adicione-o com `include_domains` em vez de ler mais páginas.

## Como faço o modelo citar suas fontes?

Numere as fontes no prompt e peça os números na resposta. Uma instrução curta funciona bem: use apenas o contexto, cite cada afirmação como [n] e diga quando o contexto não cobre a pergunta.

Mantenha a lista de fontes no final do prompt, com uma URL por número. Depois, renderize [n] como um link na sua interface. Os usuários confiam em respostas que podem verificar, e citações erradas são fáceis de identificar na revisão.

## E se uma página estiver bloqueada ou vazia?

Pule-a e use as outras. Todo resultado traz um `content_status`; apenas resultados `ok` têm texto. Uma página pode estar ausente porque Nosso leitor respeita o robots.txt: ele se identifica como LLMWebSearch, segue as regras que um site escreve para ele ou para todos os robôs e deixa de fora o conteúdo de qualquer página que não tem permissão para ler.

Quando todas as páginas de uma pesquisa voltam vazias, tente novamente uma vez com uma consulta diferente ou adicione `include_domains` para um site que você sabe estar aberto. Quando um site recusa o nosso leitor, o resultado volta sem conteúdo e com o status do site: nunca resolvemos CAPTCHAs, não entramos em contas nem contornamos um bloqueio ou um paywall.

## Quanto custa o RAG de web ao vivo?

Uma pesquisa por pergunta na maioria dos casos. Um assistente de suporte que responde 5.000 perguntas por mês, com uma segunda pesquisa para uma pergunta em cada cinco, usa cerca de 6.000 pesquisas. 25.000 pesquisas a US$ 41,25 cobre quatro meses assim.

Seu modelo também lê os chunks que você envia. Seis chunks de 1.200 caracteres acrescentam cerca de 2.000 tokens por pergunta, o que você controla pelo tamanho e pela quantidade de chunks.

## Qual pack serve para uma carga de trabalho RAG?

Um crédito por pergunta na maioria dos pipelines. Os créditos de pesquisa não têm data de expiração: o que você não usar este mês continua lá no ano que vem.

| Plano | Quantidade | Preço | Preço por unidade |
| --- | --- | --- | --- |
| Experimente | 5.000 pesquisas | US$ 9,25 | US$ 1,85/1K pesquisas |
| Desenvolvedor | 25.000 pesquisas | US$ 41,25 | US$ 1,65/1K pesquisas |
| Produção | 100.000 pesquisas | US$ 145 | US$ 1,45/1K pesquisas |

Em todos os planos: As 3 principais páginas lidas em Markdown · Filtros de país, idioma, hora e domínio · Chamadas com falha não são cobradas · Os créditos nunca expiram

**Antes de pagar**

- Recarga mínima de US$ 25. Recarregue uma vez com cripto e depois compre qualquer plano usando seu saldo.
- O dinheiro no seu saldo não expira e compra créditos de pesquisa quando você quiser. Quando um pack é mais barato que o valor mínimo de recarga, a parte que você pagou apenas para atingir esse mínimo volta para você, mediante solicitação, em até 30 dias após o pagamento, em USDT ou USDC, desde que ainda não tenha sido gasta. O restante do saldo não é devolvido, a menos que a lei exija.
- Creditado assim que seu pagamento é verificado na blockchain. Tempo habitual de confirmação da rede: 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 na web em tempo real: perguntas comuns

### Posso usar LangChain ou LlamaIndex?

Sim. A [página do LangChain e LlamaIndex](https://llmwebsearch.com/pt/docs/langchain/) encapsula a pesquisa como retriever e como ferramenta.

### Posso recuperar de URLs que já conheço?

Sim, com o [endpoint extract](https://llmwebsearch.com/pt/docs/extract/). Ler páginas cujas URLs você já tem custa 1 crédito por cada grupo iniciado de 3 páginas devolvidas com conteúdo, até 20 URLs por chamada; URLs recusadas ou com falha não são contadas.

### O LLMWebSearch armazena as páginas que lê para mim?

Não. Cada chamada deixa uma linha de log: o horário, a conta, os primeiros 60 caracteres da consulta, quantos resultados e páginas foram retornados e os créditos. As linhas são excluídas após 30 dias. O conteúdo das páginas que lemos não é mantido. Número de conta, pedidos, recargas e totais de créditos ficam enquanto a conta existir e depois apenas pelo tempo que a legislação contábil exigir. As autoridades recebem registros somente quando uma lei nos obriga.

### Posso restringir a recuperação a um idioma ou país?

Sim. Defina `language` e `country`, por exemplo `language=de` e `country=de` para resultados em alemão da Alemanha.

---

LLMWebSearch: O LLMWebSearch é uma API de pesquisa na web para agentes de IA que retorna resultados classificados com o conteúdo das principais páginas em Markdown, pago com cripto sem envio de documentos. Os créditos pré-pagos a partir de US$ 1,20/1K pesquisas nunca expiram. Sem KYC — sem documento, sem selfie, sem comprovantes. Pague com cripto.
