Por qué RAG falla con documentos reales: fragmentación, búsqueda híbrida, reclasificación y evaluaciones.

Por qué las demostraciones fallan con datos reales

Los tutoriales de RAG suelen ejecutarse con un PDF ordenado o con datos extraídos de Wikipedia, lo cual no representa un escenario realista. Al aplicar el mismo proceso a material corporativo real, con formato irregular, tickets de soporte y wikis internos extensos, las respuestas comienzan a ser incompletas, inventadas o claramente erróneas. Dos factores explican casi todos los fallos en entornos de producción.

1. RAG es primero un sistema de recuperación de información y solo en segundo lugar un sistema generador de texto. Cuando la recuperación muestra el contexto incorrecto, el modelo prácticamente no tiene posibilidades de dar una respuesta correcta, por más capaz que sea.
2. La calidad general está limitada por la etapa más débil, no por la media. Un modelo de embedding potente no puede salvar a un procesador de texto que divida una oración en dos partes.

Dos fases

Cada sistema RAG se divide en una fase de indexación offline y una fase de consulta online:

Indexing (offline):   documents → chunks → embeddings → vector store
Query (online):       question → embedding → retrieval → context assembly → LLM

Las configuraciones de producción añaden caché, reclasificación, medidas de seguridad, monitoreo y lógica de respaldo alrededor de este núcleo, pero este sigue siendo la base de todo lo demás, y ninguna herramienta posterior puede reparar una base débil.

El particionamiento en fragmentos da los mejores resultados

La mayoría de los sistemas fallan al dividir el texto en fragmentos, y ese fallo permanece invisible hasta que se está depurando una respuesta incorrecta tres etapas después. Es importante porque los modelos incrustados funcionan mejor con segmentos coherentes, las ventanas de contexto son finitas, los fragmentos demasiado grandes generan ruido, y los demasiado pequeños dejan de lado los datos necesarios para una respuesta.

El particionamiento en fragmentos de tamaño fijo corta cada N tokens con un solapamiento del 10 al 20 por ciento. Es simple y predecible, pero no tiene en cuenta los límites de las oraciones y párrafos, por lo que puede dividir una definición sin darse cuenta. Es un punto de partida común, pero rara vez es el mejor.

El particionamiento recursivo o jerárquico prueba primero las interrupciones naturales, luego dobles saltos de línea, después simples saltos de línea, seguidos de oraciones y palabras, y solo recurre a otros métodos cuando una sección sigue siendo demasiado grande. La mayoría de los frameworks actuales usan este enfoque por defecto, y representa una mejora clara en comparación con el tamaño fijo puro.

El particionamiento consciente de la estructura sigue el propio diseño del documento: encabezados, secciones, bloques de código y tablas. En documentos técnicos y Markdown, a menudo es la opción más adecuada. Mantén enlaces padre-hijo para poder seleccionar un fragmento pequeño y preciso y luego expandirlo a toda la sección padre cuando se necesite más contexto.

El particionamiento semántico utiliza un modelo de embedding o un LLM para identificar dónde realmente cambia el tema y dividir allí el contenido. Ofrece los fragmentos más coherentes, pero a un costo adicional real, ya que cada decisión de límite requiere una llamada al modelo; por eso suele reservarse para corpus donde la calidad de la recuperación justifica el gasto.

Valores predeterminados sensatos:

• Comience con un proceso de división recursivo o que tenga en cuenta la estructura, y evite el método de tamaño fijo.
• Busque fragmentos de aproximadamente 300 a 800 tokens; luego ajuste los parámetros según su propio conjunto de evaluación y no según un número de un blog.
• Almacene metadatos en cada fragmento, como el documento de origen, el título de la sección y el número de página o párrafo. Se necesitarán para filtrar y hacer citaciones más adelante.
• Reúna un pequeño conjunto de preguntas reales e inspeccione qué se obtiene antes de utilizar el modelo de embedding. Una mala división en fragmentos arruina silenciosamente los resultados, así que corríjala antes de ajustar cualquier otro parámetro.

Embeddings y almacenes vectoriales

Los modelos de incrustación colocan el texto en un espacio de alta dimensión donde la cercanía semántica se convierte en cercanía geométrica, lo que generalmente se mide mediante la similitud de coseno o el producto escalar. El modelo es importante, pero la calidad de los datos y la división en fragmentos suelen ser más decisivos que el modelo específico utilizado en el proceso. Las categorías principales son los modelos abiertos de uso general, los modelos de incrustación especializados para textos legales, médicos o de código, y las APIs propietarias. Elija según el vocabulario de su área de aplicación, y no únicamente según el ranking en las listas de mejores modelos.

La verdadera función de un almacén de vectores es realizar búsquedas rápidas de vecinos más cercanos aproximados, ya que la comparación exacta por fuerza bruta no es escalable más allá de colecciones pequeñas. La mayoría de los almacenes utilizan índices basados en grafos como HNSW o índices basados en clústeres como IVF, de modo que una consulta no necesita compararse con cada vector. El compromiso es una pequeña probabilidad, ajustable, de no encontrar al verdadero vecino más cercano a cambio de un tiempo de consulta sublineal. Rara vez se ajusta esto al principio, pero saber que existe ayuda cuando se pregunta por qué no se recuperó el fragmento que aparentemente era el correcto.

Al elegir un almacén, pregúntese si filtra por metadatos, si admite nativamente búsquedas híbridas de vectores más palabras clave (BM25), cuán fácil es ejecutarlo localmente frente a una versión gestionada, y cuál es el comportamiento en cuanto a persistencia, replicación y escalabilidad para su volumen de datos. Entre las opciones comunes se encuentran Qdrant, Weaviate, Pinecone, Chroma, pgvector y OpenSearch k-NN.

Al principio, la marca de la tienda tiene menos importancia que otras cuatro cosas: datos organizados, segmentación sólida, metadatos adecuados y una forma de combinar la búsqueda vectorial con la basada en palabras clave. La búsqueda híbrida se utiliza prácticamente en todas las implementaciones serias, ya que la búsqueda puramente vectorial sigue omitiendo tokens literales como códigos de error, códigos SKU y IDs de productos, que la búsqueda por palabras clave maneja con facilidad. La fusión de puntuaciones densas y dispersas suele estar controlada por un único peso, de modo que una consulta puede inclinarse hacia el significado o hacia términos exactos según el caso de uso. Una llamada híbrida conceptual se ve así, aunque la API exacta varía según la tienda:

# Conceptual shape of a hybrid query — exact API varies by vector store
results = vector_store.hybrid_search(
    query=user_question,
    alpha=0.5,          # weight between dense (1.0) and keyword (0.0) search
    filters={"doc_type": "runbook", "product": "checkout-service"},
    top_k=25,
)

Más allá de la similitud top-k

Obtener los fragmentos más cercanos top-k es donde comienza la recuperación, pero no donde termina. El tráfico real sigue revelando los mismos problemas: el fragmento más cercano no es el más útil, los hechos de una respuesta están distribuidos en varios fragmentos, los modelos prestan poca atención al material en medio de un contexto largo, incluso cuando está presente (el efecto de lo perdido en medio), y el modelo de embeddings podría no comprender el vocabulario de su dominio.

Técnicas que vale la pena incorporar, aproximadamente según el retorno de la inversión de esfuerzo:

• Reclasificación. Se obtiene un conjunto amplio de candidatos, digamos los 20 a 50 mejores y a veces hasta 100, mediante búsquedas vectoriales económicas, y luego se vuelven a calificar con un cross-encoder o un pequeño LLM antes de seleccionar aquellos que se incluirán en la solicitud. Este método se considera consistentemente una de las mejores adiciones a un proceso de procesamiento. Un cross-encoder califica tanto la consulta como el documento juntos, lo cual es mucho más preciso que comparar dos vectores calculados por separado, pero debe ejecutarse una vez por cada candidato y no puede abarcar toda la colección. La búsqueda con bi-encoder es económica y aproximada, y sirve para reducir el campo de búsqueda, mientras que el cross-encoder es costoso y preciso, pero solo examina lo que queda.
• Búsqueda híbrida, que combina vectores densos con búsquedas por palabras clave dispersas para que los tokens exactos no queden al azar.

Transformación de la consulta: reescribir la pregunta, generar un documento de respuesta hipotético y buscar en él (estilo HyDE), o dividir una pregunta compleja en subpreguntas que se recuperan de forma independiente.

Filtrado de metadatos, que reduce las opciones según el tipo de documento, el rango de fechas o el producto antes de que se ejecute la búsqueda vectorial y no después.

Recuperación del documento padre, realizando la coincidencia en un fragmento pequeño y preciso pero devolviendo su sección padre más amplia para que el contexto esté completo.

Medición de la recuperación por sí sola

Un conjunto de evaluación es mejor que la intuición. Escriba de 20 a 50 preguntas realistas, anote qué fragmentos deben recuperarse para cada una y verifique directamente si el fragmento correcto se encuentra entre los 5 o 10 primeros (Recall@k). Agregue un evaluador basado en LLM solo para la relevancia, una vez que la inspección manual le haya generado confianza. Si la calidad de la recuperación nunca se mide aparte de la calidad de la respuesta, el tiempo se invierte en optimizar la etapa incorrecta. Herramientas como Ragas cubren métricas específicas de RAG, por lo que no es necesario crear todo el sistema manualmente.

LlamaIndex o LangChain, conceptualmente

LlamaIndex está centrado en los datos, con abstracciones bien definidas para los motores de indexación, recuperación y consultas, y resulta natural cuando el problema principal es un gran volumen de documentos que requieren una buena recuperación. LangChain es de uso general, surgido a partir de cadenas y agentes, y cuenta con un ecosistema de integración mucho más amplio. Es más flexible, pero también más pesado cuando lo único que se necesita es la recuperación de información. Ninguno de los dos es mágico, ya que ambos utilizan los mismos patrones subyacentes. Elige uno, aprende bien sus conceptos y no seas dogmático, porque los conocimientos arquitectónicos son aplicables independientemente de la sintaxis que uses.

Resumen

1. La indexación y las consultas son fases separadas, por lo que deben diseñarse de forma independiente.
2. El particionamiento en fragmentos es una elección de diseño importante y no algo que el framework asuma por defecto.
3. Los almacenes vectoriales son parte de la infraestructura, y los beneficios provienen del filtrado y la búsqueda híbrida, no de la marca en sí.
4. La calidad de la recuperación debe medirse por separado, independientemente de la calidad de la respuesta.
5. Los frameworks son herramientas y no la arquitectura, por lo que hay que aprender los patrones y tratar la herramienta como algo reemplazable.

Leer más

• RAG avanzado en producción: arquitecturas, herramientas y compromisos — Un recorrido por el RAG en producción: ingestión, análisis, fragmentación, embeddings, almacenes vectoriales, recuperación híbrida, reclasificación, evaluación y seguridad, junto con los compromisos de cada uno.
• Un mapa de RAG: desde los principios básicos hasta los fallos en producción — Dos pipelines, tres pasos y una lista de fallos específicos: cómo funciona la generación mejorada por recuperación de información, dónde falla y qué soluciones abordan cada problema.
• Mover RAG de Pinecone a Postgres pgvector: Seis meses después — Números de producción tras migrar 9 millones de vectores desde Pinecone: costo, latencia, precisión de recuperación, fiabilidad, qué empeoró y cuándo es la mejor opción pgvector.
• Un chatbot para reparación de flotas como ejemplo de RAG en lenguaje sencillo con Chroma y Ollama — Cómo la generación mejorada por recuperación puede manejar la primera fase de diagnóstico de informes de reparación de automóviles enviados por WhatsApp, utilizando Chroma, embeddings de MiniLM y Llama 3.2.