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

Una captura estática de una wiki interna es el modo sencillo. La ingesta continua desde la web en vivo es difícil. Necesitas saber cuándo se recopiló una página por última vez, si ha cambiado desde entonces y cuánto tiempo sigue siendo válida la información. Los datos obsoletos no siempre significan una fecha visiblemente antigua. A veces, una página actualiza su texto pero mantiene la misma URL, por lo que tu sistema nunca lo nota sin un hash de contenido. Crea reglas de actualización claras basadas en la volatilidad de la fuente. Un feed de datos financieros podría necesitar comprobaciones cada hora. Una página de "acerca de" de una empresa podría necesitar comprobaciones trimestrales. Registra las marcas de tiempo y establece límites de tiempo de vida (TTL), especialmente si tu dominio involucra orientación regulada o crítica para la seguridad, donde los hechos antiguos pueden causar daños reales.

5. Contaminación por duplicados

Los sitios web están llenos de repeticiones. La misma descripción de producto aparece en la página de categoría, en la página del producto y en una página de aterrizaje promocional. El mismo comunicado de prensa vive bajo /news/, /press/ y /blog/. La búsqueda vectorial no elimina duplicados automáticamente. Si diez fragmentos casi idénticos se encuentran en tu base de datos, pueden desplazar resultados diversos y relevantes en tu recuperación top-k. Necesitas un seguimiento canónico o una deduplicación de contenido antes de la incrustación (embedding). Si dos fragmentos dicen lo mismo, conserva la fuente autorizada y descarta las copias. Tu recuperador tiene ranuras limitadas. No permitas que se desperdicien.

6. Metadatos faltantes

Una base de datos vectorial sin metadatos es solo un motor de búsqueda de texto denso sin memoria del contexto. La recuperación inteligente depende de señales de filtrado y clasificación que los embeddings puros no pueden proporcionar. Almacena la URL de origen, la fecha de captura, la categoría del documento y el número de versión. Si ingieres documentación de una API, el control de versiones es esencial. Sin él, una consulta podría mezclar especificaciones de la v1 y la v2 en la misma respuesta. Si ingieres políticas de RR. HH., el etiquetado por región o departamento te permite filtrar los resultados antes de que lleguen al modelo. Los metadatos convierten un volcado de texto en un sistema de conocimiento curado.

7. Brechas de JavaScript

Los sitios modernos no envían su contenido en la primera carga de HTML. Envían un esqueleto y lo hidratan con llamadas de JavaScript. Una solicitud HTTP básica podría no ver nada más que un indicador de carga y un esquema de diseño. Si tu pipeline no puede ejecutar JavaScript, ingerirás páginas en blanco o fragmentos parciales y nunca te darás cuenta de que algo anda mal. El uso de un navegador headless resuelve el problema de renderizado pero introduce otros nuevos: mayor uso de memoria, menor rendimiento y muros de detección de bots. Elige tus compensaciones deliberadamente, pero no pretendas que un equivalente simple a curl sea suficiente para cada fuente.

Una lista de verificación práctica de ingesta

Si estás construyendo o revisando un feed de RAG, comienza aquí:

  • Valida la cobertura de la fuente y la paginación. Un sitemap podría listar solo los primeros diez artículos de una categoría. Rastrea a fondo y verifica que el contenido paginado o cargado dinámicamente se capture realmente.
  • Elimina el texto repetitivo (boilerplate) antes de la fragmentación (chunking). Elimina la navegación, los anuncios, los pies de página y los avisos legales repetidos. Si una frase aparece en todas las páginas, es ruido.
  • Utiliza una fragmentación consciente de la estructura. Respeta los encabezados, las listas con viñetas y las tablas. Divide en límites semánticos, no por recuento de caracteres.
  • Adjunta metadatos enriquecidos. Incluye la URL, la fecha de captura, la categoría de contenido y la versión. Haz que estos campos sean filtrables en tus consultas de recuperación.
  • Establece frecuencias de actualización basadas en la volatilidad de los datos. Las fuentes con cambios frecuentes necesitan re-rastreos constantes. Los archivos estáticos no.
  • Monitorea el corpus, no solo el estado del trabajo. Un pipeline puede finalizar con código cero mientras produce basura. Audita muestras de los fragmentos almacenados regularmente para detectar deriva y calidad.
  • Define reglas para el versionado y las eliminaciones. Cuando se elimine una página de origen, elimina sus fragmentos. Cuando se actualice, sobrescríbelos o crea versiones. Los datos huérfanos son un asesino silencioso.

La dura verdad sobre los embeddings

Ningún modelo de embedding, por muy avanzado que sea, puede reparar un documento faltante. No puede adivinar que una página se actualizó la semana pasada si tu feed todavía tiene la copia del año pasado. No puede inferir el contexto de una fila de una tabla que quedó separada de su encabezado por un mal límite de fragmentación. Los embeddings comprimen el significado, pero no crean significado donde la capa de ingesta no logró preservarlo.

La calidad de la recuperación comienza en la capa de ingesta. Esa capa decide si tu sistema RAG es una herramienta útil o simplemente un mentiroso confiado con una base de datos vectorial detrás.

La conclusión principal

Deja de medir la salud de la ingesta únicamente con dashboards de pipelines. Los procesos exitosos y los logs limpios no garantizan un corpus limpio. Abre la base de datos y lee los fragmentos reales que tus usuarios recuperarán. Si el texto está lleno de avisos de derechos de autor, tablas divididas y páginas de políticas desactualizadas, tu problema no es el LLM. Primero arregla el feed. Todo lo demás es intentar ajustar sobre basura.