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

Статический снимок внутренней вики — это простой режим. Непрерывный сбор данных из «живого» интернета — задача сложная. Вам нужно знать, когда страница была собрана в последний раз, изменилась ли она с тех пор и как долго информация остается актуальной. Устаревшие данные — это не всегда наличие явно старой даты. Иногда страница обновляет текст, но сохраняет тот же URL, поэтому ваша система никогда не заметит изменений без хеширования контента. Формируйте четкие правила обновления, исходя из изменчивости источника. Финансовой ленте данных может требоваться проверка каждый час. Странице «О компании» может быть достаточно ежеквартальной проверки. Фиксируйте временные метки и устанавливайте границы времени жизни (TTL), особенно если ваша область деятельности связана с регулируемыми отраслями или вопросами безопасности, где устаревшие факты могут нанести реальный вред.

5. Засорение дубликатами

Веб-сайты переполнены повторами. Одно и то же описание продукта встречается на странице категории, на странице товара и на рекламном лендинге. Один и тот же пресс-релиз может находиться в разделах /news/, /press/ и /blog/. Векторный поиск не выполняет дедупликацию автоматически. Если в вашей базе данных окажется десять почти идентичных чанков, они могут вытеснить разнообразные и релевантные результаты из вашей выборки top-k. Вам необходимо каноническое отслеживание или дедупликация контента перед созданием эмбеддингов. Если два чанка говорят об одном и том же, оставьте авторитетный источник и удалите копии. У вашего ретривера ограниченное количество слотов. Не позволяйте тратить их впустую.

6. Отсутствие метаданных

Векторная база данных без метаданных — это всего лишь движок плотного текстового поиска, лишенный контекста. Умный поиск зависит от сигналов фильтрации и ранжирования, которые не могут обеспечить «сырые» эмбеддинги. Сохраняйте URL источника, дату захвата, категорию документа и номер версии. Если вы загружаете документацию API, версионирование становится критически важным. Без него запрос может смешать спецификации v1 и v2 в одном ответе. Если вы загружаете кадровые политики, тегирование по регионам или отделам позволит фильтровать результаты еще до того, как они попадут в модель. Метаданные превращают свалку текста в курируемую систему знаний.

7. Пробелы из-за JavaScript

Современные сайты не отдают контент в первом же HTML-пакете. Они присылают «скелет» и наполняют его данными с помощью JavaScript-вызовов. Обычный HTTP-запрос может увидеть лишь индикатор загрузки и пустой макет. Если ваш конвейер не умеет исполнять JavaScript, вы будете загружать пустые страницы или фрагментарные обрывки, даже не осознавая, что что-то идет не так. Использование headless-браузера решает проблему рендеринга, но порождает новые: повышенное потребление памяти, снижение пропускной способности и риск блокировки системами защиты от ботов. Выбирайте компромиссы осознанно, но не делайте вид, что простого аналога curl достаточно для любого источника.

Практический чек-лист по инжестированию

Если вы строите или проверяете RAG-конвейер, начните здесь:

  • Проверяйте полноту охвата источников и пагинацию. Карта сайта (sitemap) может содержать только первые десять статей в категории. Проводите глубокий краулинг и проверяйте, что пагинированный или динамически загружаемый контент действительно захватывается.
  • Удаляйте шаблонный контент перед разбиением на чанки. Вырезайте навигацию, рекламу, футеры и повторяющиеся юридические дисклеймеры. Если фраза встречается на каждой странице, это шум.
  • Используйте разбиение на чанки с учетом структуры. Соблюдайте иерархию заголовков, списков и таблиц. Делите текст по семантическим границам, а не по количеству символов.
  • Добавляйте подробные метаданные. Включайте URL, дату захвата, категорию контента и версию. Сделайте эти поля доступными для фильтрации в ваших поисковых запросах.
  • Устанавливайте частоту обновления в зависимости от изменчивости данных. Источники с частыми изменениями требуют частого переобхода. Статические архивы — нет.
  • Мониторьте корпус данных, а не только статус выполнения задачи. Конвейер может завершиться с кодом 0, выдавая при этом мусор. Регулярно проводите аудит выборок сохраненных чанков на предмет дрейфа данных и качества.
  • Определите правила версионирования и удаления. Когда страница источника удаляется, удаляйте и её чанки. Когда она обновляется, перезаписывайте их или создавайте новые версии. «Осиротевшие» данные — это скрытая угроза.

Горькая правда об эмбеддингах

Ни одна модель эмбеддингов, какой бы продвинутой она ни была, не сможет восстановить отсутствующий документ. Она не сможет угадать, что страница была обновлена на прошлой неделе, если в вашем фиде все еще хранится копия прошлого года. Она не сможет восстановить контекст строки таблицы, которая была отделена от своего заголовка из-за неудачного разбиения на чанки. Эмбеддинги сжимают смысл, но они не создают смысл там, где слой инжестирования не смог его сохранить.

Качество поиска начинается на уровне сбора данных. Именно этот уровень определяет, будет ли ваша RAG-система полезным инструментом или просто самоуверенным лжецом с векторной базой данных за спиной.

Главный вывод

Перестаньте измерять качество загрузки данных только по дашбордам пайплайнов. Зеленые статусы задач и чистые логи не гарантируют чистоту корпуса. Откройте базу данных и прочитайте те самые чанки, которые будут получать ваши пользователи. Если текст переполнен уведомлениями об авторских правах, разбитыми таблицами и устаревшими страницами политик, то ваша проблема не в LLM. Сначала исправьте источник данных. Все остальное — это лишь попытки настройки поверх мусора.