# RAG vanaf het live web: ophalen met een zoekopdracht, antwoorden met citaties

> Retrieval-augmented generation vanaf het live web: zoek, lees de top-pagina's als Markdown en geef antwoorden met citaties. Python-code. Betaal met crypto.

- URL: https://llmwebsearch.com/nl/use-cases/rag/
- Laatst bijgewerkt: 2026-10-22
- Uitgever: LLMWebSearch (https://llmwebsearch.com)

Een vectorindex bevat wat je vorige maand hebt geladen. Sommige vragen hebben nodig wat het web vandaag zegt. Live-web RAG haalt op het moment van de vraag op: één zoekopdracht, de top-pagina's als Markdown, een paar chunks in de prompt, en citaties terug naar elke pagina.

**Snel antwoord — Hoe doe ik RAG met live webzoekresultaten?**

Voer op het moment van de vraag een webzoekopdracht uit, lees de top-pagina's, splits ze in chunks, houd de meest relevante en vraag het model om te antwoorden met genummerde citaties. **LLMWebSearch** regelt de eerste twee stappen in één call: gerangschikte resultaten met de eerste 3 pagina's als Markdown, voor één credit, vanaf US$ 1,20/1K zoekopdrachten. Zonder KYC; betalen met crypto.

## Wat is live-web RAG?

Het is retrieval-augmented generation waarbij de retrieval-stap een webzoekopdracht is in plaats van een lookup in je eigen index. De vraag gaat naar een search-API, de API retourneert pagina's en het model antwoordt op basis van die pagina's.

Het patroon past bij vragen over dingen die veranderen: prijzen, releases, regels, schema's en nieuws. Het past ook bij long-tail-vragen die je eigen documenten nooit hebben gedekt. De kosten zijn één zoekopdracht per vraag, of twee wanneer de eerste mist.

## Wanneer haal ik vers op en wanneer sla ik op?

Sla op wat stabiel en van jou is; haal op wat verandert. Producthandleidingen, intern beleid en je eigen documenten horen in een vectorindex, op schema vernieuwd. Prijzen van concurrenten, regelgeving en nieuws horen bij live retrieval.

Veel teams combineren beide. Ze doorzoeken eerst hun eigen index en roepen het web pas aan als de index geen goede match heeft, of als de vraag een recente datum noemt.

Als je besluit opgehaalde pagina's te bewaren, let op ons standpunt: We trainen geen enkel model op je zoekopdrachten of op wat de API teruggeeft, en we voegen geen eigen regel toe tegen het opslaan van resultaten; de rechten van de sites waarvan je pagina's leest, gelden nog steeds. Controleer de voorwaarden van elke site voordat je een permanente kopie van de inhoud bouwt.

## Hoe zet ik zoekresultaten om in chunks?

Splits elke pagina op de koppen en snijd lange secties af op een vaste lengte. Markdown maakt dit makkelijk, want koppen zijn regels die met `#` beginnen. Bewaar de bron-URL en titel bij elke chunk, zodat citaties de splitsing overleven.

Het voorbeeld hieronder zoekt, leest drie pagina's, splitst ze in chunks en kiest de zes chunks die de meeste woorden met de vraag delen. Vervang de woordentelling in productie door je embedding-model; de structuur blijft hetzelfde.

*Python: live-web retrieval met chunks en genummerde bronnen*

```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}"
    )
```

## Hoeveel pagina's moet elke vraag lezen?

Drie is een goed begin, en het houdt de zoekopdracht op één credit. De meeste feitelijke vragen worden beantwoord op de eerste twee of drie pagina's van een goede zoekopdracht.

Vraag langere pagina's dan je in een chat-agent zou doen, want de chunker gooit het meeste van de tekst toch weg. Een `max_chars` van 10.000 tot 15.000 per pagina geeft de ranker genoeg om uit te kiezen. Als het antwoord van één bekende site afhangt, voeg die dan toe met `include_domains` in plaats van meer pagina's te lezen.

## Hoe zorg ik dat het model zijn bronnen citeert?

Nummer de bronnen in de prompt en vraag om de nummers in het antwoord. Een korte instructie werkt goed: gebruik alleen de context, citeer elke bewering als [n], en zeg het wanneer de context de vraag niet dekt.

Zet de bronnenlijst aan het einde van de prompt, met één URL per nummer. Render [n] dan als een link in je interface. Gebruikers vertrouwen antwoorden die ze kunnen checken, en foute citaties zijn makkelijk te herkennen bij review.

## Wat als een pagina geblokkeerd of leeg is?

Sla hem over en gebruik de andere. Elk resultaat heeft een `content_status`; alleen `ok` resultaten hebben tekst. Een pagina kan ontbreken omdat Onze reader respecteert robots.txt: hij stelt zich voor als LLMWebSearch, volgt de regels die een site voor hem of voor alle robots schrijft, en laat de inhoud weg van elke pagina die hij niet mag lezen.

Wanneer alle pagina's van een zoekopdracht leeg terugkomen, probeer het dan één keer opnieuw met een andere zoekopdracht of voeg `include_domains` toe voor een site waarvan je weet dat die open is. Wanneer een site onze reader weert, komt het resultaat terug zonder inhoud en met de status van de site: we lossen nooit CAPTCHA's op, loggen nooit in op accounts en werken nooit om een blokkade of een paywall heen.

## Wat kost live-web RAG?

Eén zoekopdracht per vraag in de meeste gevallen. Een support-assistent die 5.000 vragen per maand beantwoordt, met een tweede zoekopdracht voor één op de vijf vragen, gebruikt ongeveer 6.000 zoekopdrachten. 25.000 zoekopdrachten bij US$ 41,25 dekt vier zulke maanden.

Je model leest ook de chunks die je het stuurt. Zes chunks van 1.200 tekens voegen ongeveer 2.000 tokens per vraag toe, wat je beheert via de chunkgrootte en het aantal.

## Welke pack past bij een RAG-workload?

Voor de meeste pipelines één credit per vraag. Zoekcredits verlopen niet: wat je deze maand niet gebruikt, staat er volgend jaar nog.

| Plan | Aantal | Prijs | Prijs per eenheid |
| --- | --- | --- | --- |
| Probeer | 5.000 zoekopdrachten | US$ 9,25 | US$ 1,85/1K zoekopdrachten |
| Builder | 25.000 zoekopdrachten | US$ 41,25 | US$ 1,65/1K zoekopdrachten |
| Productie | 100.000 zoekopdrachten | US$ 145 | US$ 1,45/1K zoekopdrachten |

In elk plan: Top 3 pagina's gelezen als Markdown · Filters voor land, taal, tijd en domein · Mislukte calls worden niet in rekening gebracht · Credits verlopen nooit

**Voordat je betaalt**

- Minimale storting US$ 25. Stort één keer in crypto en koop daarna elk plan vanuit je saldo.
- Saldo op je account verloopt niet en koopt zoekcredits wanneer je maar wilt. Wanneer een pack goedkoper is dan de minimale top-up, krijg je het deel dat je alleen hebt betaald om dat minimum te bereiken op verzoek terug binnen 30 dagen na betaling, in USDT of USDC, mits het nog niet is besteed. De rest van een saldo wordt niet terugbetaald, tenzij de wet dat vereist.
- Bijgeschreven zodra je betaling op de blockchain is gecontroleerd. Gebruikelijke bevestigingstijd van het netwerk: 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

## Live-web RAG: veelgestelde vragen

### Kan ik LangChain of LlamaIndex gebruiken?

Ja. De [LangChain- en LlamaIndex-pagina](https://llmwebsearch.com/nl/docs/langchain/) verpakt de zoekopdracht als een retriever en als een tool.

### Kan ik ophalen uit URL's die ik al ken?

Ja, met het [extract-endpoint](https://llmwebsearch.com/nl/docs/extract/). Het lezen van pagina's waarvan je de URL's al hebt, kost 1 credit per begonnen groep van 3 pagina's die met inhoud worden teruggegeven, tot 20 URL's per call; geweigerde of mislukte URL's tellen niet mee.

### Slaat LLMWebSearch de pagina's die het leest voor me op?

Nee. Elke call laat één logregel achter: de tijd, het account, de eerste 60 tekens van de zoekopdracht, hoeveel resultaten en pagina's er zijn teruggegeven, en de credits. Regels worden na 30 dagen verwijderd. De inhoud van de pagina's die we lezen, wordt niet bewaard. Accountnummer, bestellingen, opwaarderingen en credittotalen blijven zolang het account bestaat, daarna alleen zolang de boekhoudwet dat vraagt. Autoriteiten ontvangen gegevens alleen wanneer een wet ons daartoe verplicht.

### Kan ik het ophalen beperken tot één taal of land?

Ja. Stel `language` en `country` in, bijvoorbeeld `language=de` en `country=de` voor Duitse resultaten uit Duitsland.

---

LLMWebSearch: LLMWebSearch is een webzoek-API voor AI-agents die gerangschikte resultaten teruggeeft met de inhoud van de belangrijkste pagina's als Markdown, betaald met crypto zonder ID-upload. Voorafbetaalde credits vanaf US$ 1,20/1K zoekopdrachten verlopen nooit. Zonder KYC — geen ID, geen selfie, geen documenten. Betalen met crypto.