Most RAG tutorials end at the notebook. They load a few polished PDFs, split the text every thousand characters, stuff the fragments into a vector database, and call it an architecture. On a Friday afternoon, that demo runs perfectly. In production, the same pipeline quietly turns into a liability.
The real bottleneck in a retrieval system is rarely the model or the prompt. It is ingestion. A RAG pipeline can only retrieve what it has been fed, and if the feed is noisy, stale, or incomplete, the model will deliver confident nonsense. When users complain that the bot hallucinated, the fault often lies miles upstream in a data pipeline that nobody monitors closely.
The Whiteboard Trap
Architecture diagrams make ingestion look like a single arrow labeled “Documents → Vector DB.” Reality is messier. Source systems change without notice. HTML layouts get redesigns. URLs redirect to generic landing pages. JavaScript frameworks swap out the content after the initial HTTP response. Treating ingestion as a one-time setup task is the first mistake. It is an ongoing data engineering problem that deserves the same rigor as any ETL pipeline.
Why RAG Failures Are Usually Feed Failures
Picture this: a user asks your internal assistant about the current refund policy. The model pulls the top chunk from the vector store and states a 30-day window. The actual policy changed to 60 days last quarter. The LLM did not invent the wrong answer. It trusted bad input. The retrieval layer served an old page, and because the embedding looked semantically close enough, the model treated it as ground truth.
This pattern repeats constantly. Teams burn hours tweaking temperature and top-k when their corpus is full of navigation footers, duplicate press releases, and chunks that split tables in half. Before you optimize generation, audit what your system is allowed to know.
Seven Traps That Destroy Ingestion
1. The First Run Is a Lie
A green checkmark on your initial crawl means almost nothing. Production data is alive. Documentation pages get refactored, blog permalinks break, and sitemaps quietly drop sections. If you only validate that the pipeline completed without throwing an error, you are flying blind. You need to validate the output. Check that the expected documents are present, that their structure still parses, and that the total volume of text hasn't collapsed because a source decided to paginate results differently.
2. Crawling Is Not Ingestion
Fetching HTML is the easy part. A raw crawl captures everything: cookie banners, "Related Articles" sidebars, ad blocks, and footer copyright notices. If you chunk that raw HTML naively, every single piece of text carries along fragments of the navigation menu. When a user asks about API rate limits, the retriever might surface a chunk that is 40 percent sidebar links. Clean extraction matters. You need to identify the main content area, strip boilerplate, and remove elements that repeat across every page. Otherwise you are not building a knowledge base. You are building a search engine for website chrome.
3. Chunking Breaks Meaning
Fixed-size chunking is the default in nearly every quickstart guide, and it is dangerous. Split a document purely by character count and you will slice tables down the middle, separate steps 4 and 5 in a numbered procedure, and orphan bullet points from their headings. A chunk containing only the second half of a pricing table is semantically useless. Structure-aware chunking respects the original format. Parse the heading hierarchy. Keep tables intact where possible. Split at paragraph boundaries under the same H2 or H3. Preserve lists inside a single chunk if they are short enough. The goal is not evenly sized blocks. The goal is coherent units of meaning.
4. The Freshness Problem
Statyczna migawka wewnętrznej wiki to tryb prosty. Ciągłe pobieranie danych z żywego internetu jest trudne. Musisz wiedzieć, kiedy strona została ostatnio pobrana, czy od tego czasu uległa zmianie oraz jak długo informacje pozostają aktualne. Nieaktualne dane nie zawsze oznaczają widocznie starej daty. Czasami strona aktualizuje tekst, ale zachowuje ten sam adres URL, więc bez hashowania zawartości Twój system nigdy tego nie zauważy. Twórz jasne reguły odświeżania oparte na zmienności źródła. Strumień danych finansowych może wymagać sprawdzania co godzinę. Strona „O firmie” może wymagać kontroli raz na kwartał. Rejestruj znaczniki czasu i ustalaj granice czasu życia danych (time-to-live), zwłaszcza jeśli Twoja domena obejmuje regulowane lub krytyczne dla bezpieczeństwa wytyczne, gdzie nieaktualne fakty mogą wyrządzić realną szkodę.
5. Duplicate Pollution
Witryny internetowe są pełne powtórzeń. Ten sam opis produktu pojawia się na stronie kategorii, stronie produktu i na promocyjnej stronie docelowej. Ten sam komunikat prasowy znajduje się pod adresami /news/, /press/ i /blog/. Wyszukiwanie wektorowe nie usuwa duplikatów automatycznie. Jeśli w Twojej bazie danych znajduje się dziesięć niemal identycznych fragmentów (chunks), mogą one wyprzeć różnorodne, istotne wyniki w procesie top-k retrieval. Potrzebujesz śledzenia kanonicznego lub usuwania duplikatów treści przed procesem osadzania (embedding). Jeśli dwa fragmenty mówią to samo, zachowaj wiarygodne źródło i odrzuć kopie. Twój retriever ma ograniczone zasoby. Nie marnuj ich.
6. Missing Metadata
Baza danych wektorowych bez metadanych to po prostu silnik wyszukiwania gęstego tekstu, który nie ma pamięci kontekstu. Inteligentne wyszukiwanie zależy od sygnałów filtrowania i rankingowania, których surowe osadzenia (embeddings) nie mogą zapewnić. Przechowuj adres URL źródła, datę przechwycenia, kategorię dokumentu i numer wersji. Jeśli pobierasz dokumentację API, wersjonowanie jest niezbędne. Bez tego zapytanie może wymieszać specyfikacje v1 i v2 w jednej odpowiedzi. Jeśli pobierasz polityki HR, tagowanie według regionu lub działu pozwala filtrować wyniki, zanim trafią one do modelu. Metadane zmieniają zrzut tekstu w uporządkowany system wiedzy.
7. JavaScript Gaps
Nowoczesne strony nie przesyłają swojej zawartości w pierwszym pakiecie HTML. Przesyłają szkielet i „nawadniają” go (hydrate) za pomocą wywołań JavaScript. Podstawowe żądanie HTTP może nie zobaczyć nic poza kręcącym się spinnerem ładowania i szkieletem układu. Jeśli Twój potok (pipeline) nie potrafi wykonywać JavaScriptu, będziesz pobierać puste strony lub niepełne fragmenty, nawet nie zdając sobie sprawy z problemu. Użycie przeglądarki typu headless rozwiązuje problem renderowania, ale wprowadza nowe: większe zużycie pamięci, mniejszą przepustowość i bariery wykrywania botów. Świadomie wybieraj kompromisy, ale nie udawaj, że odpowiednik prostego polecenia curl wystarczy dla każdego źródła.
A Practical Ingestion Checklist
Jeśli budujesz lub przeglądasz strumień danych dla RAG, zacznij tutaj:
- Waliduj pokrycie źródeł i paginację. Mapa witryny może wymieniać tylko dziesięć pierwszych artykułów w kategorii. Przeszukuj głęboko i weryfikuj, czy paginowana lub dynamicznie ładowana zawartość jest faktycznie przechwytywana.
- Usuń tekst powtarzalny (boilerplate) przed dzieleniem na fragmenty. Usuń nawigację, reklamy, stopki i powtarzające się zastrzeżenia prawne. Jeśli fraza pojawia się na każdej stronie, jest szumem.
- Stosuj dzielenie na fragmenty uwzględniające strukturę. Respektuj nagłówki, listy punktowane i tabele. Dziel tekst na granicach semantycznych, a nie na podstawie liczby znaków.
- Dołączaj bogate metadane. Uwzględnij URL, datę przechwycenia, kategorię treści i wersję. Spraw, aby te pola były możliwe do filtrowania w zapytaniach wyszukiwania.
- Ustalaj częstotliwość odświeżania na podstawie zmienności danych. Źródła o dużej zmienności wymagają częstego ponownego przeszukiwania. Statyczne archiwa nie.
- Monitoruj korpus, a nie tylko status zadania. Potok może zakończyć działanie z kodem zero, produkując jednocześnie śmieci. Regularnie audytuj próbki zapisanych fragmentów pod kątem dryfu i jakości.
- Zdefiniuj reguły wersjonowania i usuwania. Gdy strona źródłowa zostanie usunięta, usuń jej fragmenty. Gdy zostanie zaktualizowana, nadpisz je lub stwórz nową wersję. Osierocone dane to cichy zabójca.
The Hard Truth About Embeddings
Żaden model osadzania (embedding), bez względu na to, jak zaawansowany, nie naprawi brakującego dokumentu. Nie zgadnie, że strona została zaktualizowana w zeszłym tygodniu, jeśli Twój strumień danych wciąż zawiera kopię z zeszłego roku. Nie wywnioskuje kontekstu wiersza tabeli, który został oddzielony od nagłówka przez błędną granicę fragmentu. Osadzenia kompresują znaczenie, ale nie tworzą go tam, gdzie warstwa pobierania danych nie zdołała go zachować.
Jakość wyszukiwania zaczyna się na warstwie pobierania danych. To ta warstwa decyduje, czy Twój system RAG jest użytecznym narzędziem, czy tylko pewnym siebie kłamcą z bazą danych wektorowych na zapleczu.
The Real Takeaway
Przestań mierzyć stan ingestii wyłącznie za pomocą dashboardów potoków danych. Zielone zadania i czyste logi nie gwarantują czystego korpusu. Otwórz bazę danych i przeczytaj rzeczywiste fragmenty, które będą pobierane przez użytkowników. Jeśli tekst jest pełen zastrzeżeń prawnych, rozbitych tabel i nieaktualnych stron z politykami, Twoim problemem nie jest LLM. Najpierw napraw feed. Wszystko inne to jedynie dostrajanie czegoś na bazie śmieci.