Twój scraper spala tokeny na menu nawigacyjnym. Oto co zrobić zamiast tego

Wklejasz URL do pipeline'u, model dostaje 50 000 tokenów — i połowa z nich to stopka, menu, bannery cookie i reklamy. Odpowiedź jest słaba, koszt wysoki, a ty debugujesz BeautifulSoup o 23:00. Ten problem ma nazwę i ma rozwiązanie.

Twój scraper właśnie spalił 50 000 tokenów na menu nawigacyjnym i stopce

Klasyczny stack: Google API → BeautifulSoup/Selenium → LLM i dlaczego to piekło

Większość builderów zaczyna tak samo. Google Custom Search API zwraca listę URLi, BeautifulSoup lub Selenium pobiera HTML, parser wyciąga tekst, tekst leci do LLM. Na papierze wygląda sensownie. W produkcji zaczyna się rozpadać już przy trzecim tygodniu działania.

Pierwsza warstwa problemów to blokady. Strony wykrywają boty, serwują CAPTCHAs, zwracają 403 albo cicho podają inną treść niż ta, którą widzi przeglądarka. Selenium częściowo to obchodzi, ale kosztem złożoności i czasu — każde wywołanie to uruchomienie przeglądarki, renderowanie JS, czekanie na load. [1]

Trzy warstwy szumu, które degradują jakość odpowiedzi modelu

Nawet gdy scraper działa, HTML trafiający do LLM jest pełen śmieci. Pierwsza warstwa to elementy nawigacyjne — menu, breadcrumbs, sidebar. Druga to stopki z linkami, regulaminami i informacjami o cookies. Trzecia to reklamy, pop-upy i dynamicznie ładowane elementy, które Selenium złapał w złym momencie. [5]

Każdy z tych elementów to tokeny w oknie kontekstowym modelu. Tokeny, za które płacisz. Tokeny, które rozcieńczają sygnał i obniżają jakość retrieval. Jeśli model ma odpowiedzieć na pytanie o specyfikację produktu, a połowa kontekstu to "Sprawdź nasze inne kategorie" i "Zapisz się do newslettera" — wynik będzie odpowiednio słaby. [4]

Dwa fundamentalnie różne podejścia do web search w RAG: scraper vs. API-retriever

To nie jest problem do naprawienia — to wybór architektoniczny. Zanim sięgniesz po kolejną bibliotekę do czyszczenia HTML, warto wiedzieć, że istnieją dwie różne klasy rozwiązań.

RAG lokalny (local-first): pełna kontrola, zero CAPTCHAs, ale dane musisz dostarczyć sam

Lokalny RAG działa na danych, które sam dostarczasz. Przykład z praktyki: plik tekstowy z danymi, model embeddingowy nomic-embed-text przez Ollama, LLM llama4:scout, wektorowa baza in-memory z kosinusową miarą podobieństwa. [2] Żadnych CAPTCHAs, żadnych blokad, pełna kontrola nad jakością danych wejściowych.

Ograniczenie jest oczywiste: musisz wiedzieć z góry, jakich danych potrzebujesz, i dostarczyć je do systemu. Dla wiedzy statycznej — dokumentacja produktu, baza wiedzy firmy, archiwum raportów — to idealne podejście. Dla pytań wymagających aktualnych informacji z sieci — nie wystarczy.

RAG z web search: outsourcing ekstrakcji do zewnętrznych serwisów

Drugi model zakłada, że retrieval z sieci odbywa się przez zewnętrzne API, które samo obsługuje search, fetch i cleaning. Ty dostajesz gotowy, czysty tekst. Płacisz za wywołanie zamiast za infrastrukturę scraperową i czas debugowania. [1]

Trade-off jest realny: tracisz kontrolę nad tym, jak dokładnie strona jest parsowana, i uzależniasz pipeline od dostępności zewnętrznego serwisu. Dla większości przypadków produkcyjnych to akceptowalny kompromis.

Tavily i podobne serwisy: jedno wywołanie API zamiast trzech narzędzi i pięciu błędów

Co robi Tavily w jednym cyklu: search → fetch → clean → LLM-ready text

Tavily to serwis zbudowany z myślą o RAG i agentach LLM. Jedno wywołanie API robi to, co w klasycznym stacku wymagało trzech narzędzi: wyszukuje, pobiera strony, czyści HTML i zwraca tekst gotowy do wrzucenia do kontekstu modelu. [1]

Społeczność LangChain jest w tej kwestii jednoznaczna. Cytat z wątku na r/LangChain: "Cease attempting to use BeautifulSoup for this particular scenario; Tavily is designed to retrieve, analyze, and extract clean content from search results, delivering that information directly within the API response." [1] To nie jest opinia jednej osoby — to konsensus builderów, którzy przeszli przez ten sam cykl debugowania.

Jak Tavily zastępuje Google Custom Search API + własny scraper w pipeline LangChain

W LangChain integracja Tavily sprowadza się do kilku linii kodu. Zamiast łańcucha: GoogleSearchAPIWrapper → requests.get() → BeautifulSoup.get_text() → własny cleaner — masz jeden retriever, który zwraca listę dokumentów z czystym tekstem i metadanymi (URL, tytuł, score relevance).

To upraszcza nie tylko kod, ale też debugowanie. Gdy pipeline zwraca złe wyniki, masz jedno miejsce do sprawdzenia zamiast pięciu. Dla polskich firm wdrażających RAG w środowisku produkcyjnym — gdzie czas developera kosztuje, a stabilność pipeline'u jest krytyczna — to różnica mierzalna w godzinach tygodniowo.

Darmowe i płatne plany: kilkaset zapytań miesięcznie gratis, co dalej

Tavily oferuje darmowy tier z limitem kilkuset zapytań miesięcznie — wystarczający do prototypowania i testowania integracji. Płatne plany skalują się wraz z liczbą wywołań.

Tu pojawia się realne ograniczenie: przy intensywnym użyciu produkcyjnym koszty API mogą rosnąć szybko, szczególnie gdy każde zapytanie użytkownika generuje kilka wywołań web search. Przed wdrożeniem warto policzyć przewidywany wolumen i porównać z kosztem utrzymania własnej infrastruktury scraperowej. Nie ma tu jednej dobrej odpowiedzi — zależy od skali.

Jak wygląda czysty pipeline RAG z web search w kodzie — bez scraperowego chaosu

Minimalny przykład: embedding, LLM, retriever zewnętrzny

Czysty pipeline RAG z web search składa się z czterech elementów: retriever (Tavily), model embeddingowy do opcjonalnego re-rankingu lub lokalnej bazy, LLM do generacji, i warstwa orchestracji (LangChain lub własna logika).

Dla lokalnego RAG bez web search, przykład z [2] pokazuje działający stack: nomic-embed-text jako model embeddingowy przez Ollama, llama4:scout jako LLM, wektorowa baza in-memory z kosinusową miarą podobieństwa. Gdy dodajesz web search, nomic-embed-text nadal może służyć do re-rankingu pobranych dokumentów przed przekazaniem do llama4:scout — zamiast wrzucać wszystko do kontekstu bez selekcji. [2]

Chunking i filtrowanie kontekstu: jak nie wrzucać całej strony do okna modelu

Nawet gdy Tavily zwraca czysty tekst, strona może mieć 10 000 słów. Wrzucenie całości do kontekstu to marnotrawstwo tokenów i ryzyko, że model "zgubi się" w długim dokumencie. [3]

Dobre praktyki: ustal maksymalną długość dokumentu przekazywanego do LLM (np. 1500–2000 tokenów na fragment), użyj score relevance zwracanego przez Tavily do selekcji najlepszych fragmentów, i przekazuj do modelu tylko top-k wyników zamiast wszystkich. [4] To nie jest skomplikowane — to kwestia jednej funkcji filtrującej w pipeline.

Kiedy jednak warto zostać przy własnym scraperze — i jak go ujarzmić

Przypadki użycia, gdzie Tavily i podobne API nie wystarczą

Są sytuacje, gdzie zewnętrzny API-retriever po prostu nie dotrze do danych. Intranety firmowe, systemy za VPN, strony wymagające logowania, treści za paywallem, specyficzne formaty (PDF, Excel, systemy ERP) — to wszystko wymaga własnego rozwiązania. Polska firma wdrażająca RAG na wewnętrznej bazie wiedzy w systemie klasy Confluence za SSO nie skorzysta z Tavily do tego zadania.

Podobnie, gdy potrzebujesz bardzo specyficznego parsowania — np. tabel z danymi finansowymi w konkretnym formacie — własny scraper daje kontrolę, której API nie zapewni.

Minimum viable cleaning: co usunąć z HTML zanim tekst trafi do LLM

Jeśli zostaje przy scraperze, minimum to: usunięcie tagów <nav>, <header>, <footer>, <aside>, elementów z klasami sugerującymi nawigację lub reklamy, a następnie ekstrakcja tekstu z <main> lub <article> gdy dostępne. [5]

Biblioteka trafilatura robi to lepiej niż BeautifulSoup użyty wprost — jest zoptymalizowana pod ekstrakcję treści głównej artykułów i stron webowych. Nie rozwiązuje problemu blokad i CAPTCHAs, ale znacząco redukuje szum HTML trafiający do embeddingu. [5]

Werdykt: jeden schemat decyzyjny dla web search w RAG na 2025–2026

Drzewo decyzyjne

Zacznij od pytania: czy twoje dane są dostępne publicznie w sieci i zmieniają się w czasie? Jeśli nie — lokalny RAG z własnym korpusem jest prostszy, tańszy i bardziej przewidywalny. Nomic-embed-text i llama4:scout przez Ollama to działający stack bez zewnętrznych zależności. [2]

Jeśli tak — czy strony są publicznie dostępne bez logowania? Jeśli tak, Tavily lub podobny API-retriever to wybór domyślny. Oszczędzasz czas developera, eliminujesz blokady i dostajesz czysty tekst bez własnego cleanera. [1]

Jeśli dane są za logowaniem, intranetem lub paywallem — własny scraper jest nieunikniony. Zainwestuj w porządny cleaning (trafilatura + własne reguły filtrowania) i monitoring błędów, bo blokady będą się zdarzać. [5]

Budżet API ma znaczenie przy skali. Kilkaset zapytań miesięcznie gratis wystarczy na testy. Przy produkcyjnym wolumenie policz koszt przed wdrożeniem — i porównaj z kosztem utrzymania własnej infrastruktury scraperowej, który rzadko jest zerowy.

Następny krok: jak przetestować Tavily w istniejącym pipeline w 30 minut

Jeśli masz działający pipeline z BeautifulSoup lub Selenium, możesz przetestować Tavily jako drop-in replacement w czasie jednej sesji. Zarejestruj konto, pobierz klucz API, zastąp wywołanie scrapera wywołaniem TavilySearchResults z LangChain. Uruchom te same zapytania testowe i porównaj jakość tekstu trafiającego do LLM — zanim zdecydujesz, czy migracja ma sens w twoim konkretnym przypadku.

Jeśli wyniki są lepsze, a pipeline prostszy — masz odpowiedź. Jeśli twoje dane są za intranetem i Tavily ich nie dosięgnie — też masz odpowiedź.

Źródła

[1] How do you organize web search for your RAG pipelines without going insane? — r/LangChain

[2] Building a simple RAG pipeline in 2026: a local-first approach — Dataheimer (Substack)

[3] Advanced RAG Pipeline Complete Guide 2025 - Chaos and Order — youngju.dev

[4] Data Pipelines for RAG — amazee.io

[5] Step-by-step Guide to Building a RAG (Retrieval-Augmented Generation) Pipeline — nimbleway.com

[6] What Is RAG? How Retrieval-Augmented Generation Works in 2026 — atlan.com