Probeer
5.000 zoekopdrachten
US$ 9,25
US$ 1,85/1K zoekopdrachten
- Koppel het aan één agent
- Dezelfde API als het grootste pack
- Credits verlopen nooit
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.
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.
Builder
25.000 zoekopdrachten
US$ 41,25
US$ 1,65/1K zoekopdrachten
- Een coding agent of een research assistant
- Klaar voor MCP, LangChain en n8n
- Credits verlopen nooit
Productie
100.000 zoekopdrachten
US$ 145
US$ 1,45/1K zoekopdrachten
- Agents in productie
- Hogere rate limit op aanvraag
- Credits verlopen nooit
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
Live-web RAG: veelgestelde vragen
Kan ik LangChain of LlamaIndex gebruiken?
Ja. De LangChain- en LlamaIndex-pagina 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. 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.