Wypróbuj
5 000 wyszukiwań
9,25 USD
1,85 USD/1K wyszukiwań
- Podłącz to do jednego agenta
- To samo API co w największym packu
- Kredyty nigdy nie wygasają
Szybka odpowiedź
Jak zrobić RAG z wynikami wyszukiwania w żywym internecie?
Uruchom wyszukiwanie w internecie w momencie pytania, odczytaj najważniejsze strony, podziel je na fragmenty, zachowaj te najbardziej trafne i poproś model o odpowiedź z numerowanymi cytowaniami. LLMWebSearch obsługuje pierwsze dwa kroki w jednym wywołaniu: uporządkowane wyniki z pierwszymi 3 stronami jako Markdown, za jeden kredyt, od 1,20 USD/1K wyszukiwań. Bez KYC; płatność kryptowalutą.
Czym jest live-web RAG?
To retrieval-augmented generation, w którym krok pozyskiwania to wyszukiwanie w internecie zamiast przeszukiwania własnego indeksu. Pytanie trafia do API wyszukiwania, API zwraca strony, a model odpowiada na podstawie tych stron.
Ten wzorzec pasuje do pytań o rzeczy, które się zmieniają: ceny, wydania, przepisy, harmonogramy i wiadomości. Pasuje też do długiego ogona pytań, których nigdy nie objęły Twoje własne dokumenty. Koszt to jedno wyszukiwanie na pytanie, albo dwa, gdy pierwsze nie trafi.
Kiedy pobierać świeże dane, a kiedy je przechowywać?
Przechowuj to, co jest stabilne i Twoje; pobieraj to, co się zmienia. Instrukcje produktów, polityki wewnętrzne i własna dokumentacja należą do indeksu wektorowego, odświeżanego według harmonogramu. Ceny konkurencji, regulacje i wiadomości należą do pozyskiwania na żywo.
Wiele zespołów łączy oba podejścia. Najpierw przeszukują własny indeks, a do internetu sięgają tylko wtedy, gdy indeks nie ma dobrego dopasowania lub gdy pytanie wspomina niedawną datę.
Jeśli zdecydujesz się przechowywać pobrane strony, zwróć uwagę na nasze stanowisko: Nie trenujemy żadnego modelu na Twoich zapytaniach ani na tym, co zwraca API, i nie dodajemy własnej reguły przeciwko przechowywaniu wyników; nadal obowiązują prawa witryn, których strony czytasz. Sprawdź warunki każdego serwisu, zanim zbudujesz trwałą kopię jego treści.
Jak zamienić wyniki wyszukiwania w fragmenty?
Dziel każdą stronę po nagłówkach, a potem tnij długie sekcje do ustalonej długości. Markdown to ułatwia, bo nagłówki to linie zaczynające się od #. Zachowaj adres URL źródła i tytuł przy każdym fragmencie, żeby cytowania przetrwały podział.
Poniższy przykład wyszukuje, odczytuje trzy strony, dzieli je na fragmenty i wybiera sześć fragmentów, które mają najwięcej wspólnych słów z pytaniem. W środowisku produkcyjnym zastąp liczenie słów swoim modelem embeddingowym; struktura pozostaje taka sama.
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}"
)Ile stron powinno odczytywać każde pytanie?
Trzy to dobry początek i utrzymuje wyszukiwanie na jednym kredycie. Większość pytań faktograficznych ma odpowiedź na pierwszych dwóch lub trzech stronach dobrego zapytania.
Proś o dłuższe strony niż w agencie czatu, bo chunker i tak odrzuci większość tekstu. max_chars od 10 000 do 15 000 na stronę daje rankerowi wystarczająco dużo do wyboru. Jeśli odpowiedź zależy od jednej znanej witryny, dodaj ją przez include_domains zamiast czytać więcej stron.
Jak sprawić, żeby model cytował źródła?
Ponumeruj źródła w promptcie i poproś o numery w odpowiedzi. Krótka instrukcja działa dobrze: używaj tylko kontekstu, cytuj każde twierdzenie jako [n] i mów, gdy kontekst nie obejmuje pytania.
Trzymaj listę źródeł na końcu promptu, z jednym adresem URL na numer. Potem renderuj [n] jako link w swoim interfejsie. Użytkownicy ufają odpowiedziom, które mogą sprawdzić, a błędne cytowania łatwo zauważyć podczas przeglądu.
Co jeśli strona jest zablokowana lub pusta?
Pomiń ją i użyj pozostałych. Każdy wynik niesie content_status; tylko wyniki ok mają tekst. Strony może brakować, ponieważ Nasz czytnik respektuje robots.txt: przedstawia się jako LLMWebSearch, przestrzega reguł, które witryna zapisuje dla niego lub dla wszystkich robotów, i pomija treść każdej strony, której nie wolno mu czytać.
Gdy wszystkie strony wyszukiwania wrócą puste, spróbuj jeszcze raz z innym zapytaniem lub dodaj include_domains dla witryny, o której wiesz, że jest otwarta. Gdy witryna odrzuca nasz czytnik, wynik wraca bez treści i ze statusem witryny: nigdy nie rozwiązujemy CAPTCHA, nie logujemy się na konta ani nie obchodzimy blokady czy paywalla.
Ile kosztuje live-web RAG?
W większości przypadków jedno wyszukiwanie na pytanie. Asystent wsparcia, który odpowiada na 5000 pytań miesięcznie, z drugim wyszukiwaniem dla jednego pytania na pięć, zużywa około 6000 wyszukiwań. 25 000 wyszukiwań przy 41,25 USD pokrywa cztery takie miesiące.
Twój model czyta też fragmenty, które mu wysyłasz. Sześć fragmentów po 1200 znaków dodaje około 2000 tokenów na pytanie, co kontrolujesz przez rozmiar i liczbę fragmentów.
Który pack pasuje do obciążenia RAG?
Jeden kredyt za pytanie w większości pipeline'ów. Kredyty na wyszukiwanie nie mają daty ważności: to, czego nie wykorzystasz w tym miesiącu, będzie tam jeszcze w przyszłym roku.
Builder
25 000 wyszukiwań
41,25 USD
1,65 USD/1K wyszukiwań
- Agent kodujący lub asystent badawczy
- Gotowe do MCP, LangChain i n8n
- Kredyty nigdy nie wygasają
Produkcja
100 000 wyszukiwań
145 USD
1,45 USD/1K wyszukiwań
- Agenci w produkcji
- Wyższy rate limit na życzenie
- Kredyty nigdy nie wygasają
W każdym planie: 3 najlepsze strony odczytane jako Markdown · Filtry kraju, języka, czasu i domeny · Nieudane wywołania nie są naliczane · Kredyty nigdy nie wygasają
RAG w czasie rzeczywistym: najczęstsze pytania
Czy mogę używać LangChain lub LlamaIndex?
Tak. Strona LangChain i LlamaIndex opakowuje wyszukiwanie jako retriever i jako narzędzie.
Czy mogę pobierać treść z URL-i, które już znam?
Tak, za pomocą endpointu extract. Odczyt stron, których adresy URL już masz, kosztuje 1 kredyt za każdą rozpoczętą grupę 3 stron zwróconych z treścią, do 20 adresów URL na wywołanie; adresy URL odrzucone lub nieudane nie są liczone.
Czy LLMWebSearch przechowuje dla mnie strony, które odczytuje?
Nie. Każde wywołanie zostawia jedną linię logu: czas, konto, pierwsze 60 znaków zapytania, liczbę zwróconych wyników i stron oraz kredyty. Linie są usuwane po 30 dniach. Treść stron, które czytamy, nie jest zachowywana. Numer konta, zamówienia, doładowania i sumy kredytów pozostają, dopóki konto istnieje, a potem tylko tak długo, jak wymaga tego prawo księgowe. Organy otrzymują zapisy tylko wtedy, gdy zmusza nas do tego prawo.
Czy mogę ograniczyć wyszukiwanie do jednego języka lub kraju?
Tak. Ustaw language i country, na przykład language=de i country=de dla wyników po niemiecku z Niemiec.