Desafíos iniciales de RAG: la cuestión crítica de la «longitud del fragmento»
En el artículo ¿Qué es RAG?, explicamos que la característica definitoria de RAG es su capacidad para vectorizar y buscar pasajes completos (fragmentos), en lugar de palabras individuales. Sin embargo, en las primeras implementaciones de RAG, manejar estos “fragmentos” se convirtió en un obstáculo importante.
Más allá de la calidad de los datos y los problemas de formato, el mayor desafío para los ingenieros fue la longitud (tamaño) del fragmento. Esto creó un equilibrio difícil:
◼ Fragmentos largos: contexto rico, enfoque borroso
Contienen abundante contexto, pero se pueden mezclar varios temas. Como resultado, la representación vectorial pierde nitidez, lo que dificulta la recuperación precisa.
◼ Fragmentos cortos: búsqueda nítida, contexto faltante
La representación vectorial se vuelve más clara y la recuperación más precisa. Sin embargo, la información está fragmentada y puede perderse el contexto esencial para generar una respuesta sólida.
Debido a que el método comprime un pasaje largo en un solo vector numérico, los desarrolladores se vieron efectivamente empujados hacia fragmentos más cortos. El resultado fue a menudo una recuperación fragmentada y respuestas incompletas o insatisfactorias.
En los últimos años, se han adoptado enfoques más flexibles —como generar múltiples vectores a partir de un único documento largo— para abordar esta cuestión. Exploraremos estos métodos en una sección posterior.
Punto clave
Los primeros RAG no alcanzaron la “calidad de respuesta similar a LLM” que esperaban los usuarios, limitada por fragmentos cortos y recuperación gruesa.
A partir de 2023, RAG llamó la atención como una alternativa relativamente liviana al ajuste fino que requiere mucha mano de obra, prometiendo una manera fácil de extender los LLM a dominios especializados. En la práctica, sin embargo, los primeros RAG a menudo decepcionaban a los usuarios que esperaban una calidad de respuesta equivalente a las respuestas de conocimiento general de un LLM.
Si bien la arquitectura RAG en sí era técnicamente sencilla de implementar, las implementaciones en el mundo real expusieron rápidamente numerosos obstáculos. Inmediatamente surgieron problemas clásicos con los datos: documentos fuente internos
eran cuestiones escasas, no estructuradas o mal seleccionadas— familiares desde hace mucho tiempo en los proyectos de aprendizaje automático.
Además, incluso con datos adecuadamente preparados, los primeros sistemas RAG normalmente dependían de una incrustación uno a uno por fragmento. Este diseño extrajo significado sólo de unidades de texto relativamente cortas, rompiendo así la continuidad contextual. La evidencia recuperada resultante fue fragmentaria, lo que dio lugar a resultados de LLM que con frecuencia adolecían de una falta de coherencia.
Estos problemas se vieron agravados por otros factores: desajustes entre el espacio semántico del modelo de incrustación y las representaciones internas del LLM, y prácticas de clasificación burdas que dependían de un ordenamiento ingenuo de los puntajes más altos. En retrospectiva, estas limitaciones explican colectivamente por qué los primeros RAG a menudo no lograron ofrecer el sólido desempeño que muchos habían esperado inicialmente.
6.2De la decepción a la utilidad: dos primeros pasos esenciales
Debido a los desafíos que enfrentaron los primeros sistemas RAG, muchos profesionales se desilusionaron y concluyeron que “RAG no funciona” Pero darse por vencido en ese momento sería prematuro.
RAG es, por naturaleza, un enfoque tipo patchwork con muchos parámetros que ajustar. Entre ellos, el equilibrio entre el tamaño del fragmento y la precisión de la recuperación fue una de las cuestiones más difíciles. Hoy, sin embargo, existen soluciones claras y prácticas.
Para generar respuestas precisas, RAG debe preservar suficiente contexto y al mismo tiempo permitir una recuperación precisa. Para lograr este equilibrio se han convertido en estándar tres enfoques:
- Fragmentos más grandes para un mejor contexto
En lugar de dividir los documentos en fragmentos excesivamente pequeños, se utilizan fragmentos más largos para preservar un contexto y un significado coherentes. Al mantener una continuidad semántica más amplia dentro de cada fragmento, el modelo puede acceder a información más rica al generar respuestas. La clave no es simplemente alargar los fragmentos, sino garantizar que se conserve un contexto significativo sin difuminar demasiado la precisión de la recuperación. - Vectorización de uno a muchos (integración múltiple por fragmento)
En lugar de asignar un solo vector a un pasaje largo, se generan múltiples vectores (índices) a partir del mismo fragmento. Esto permite que el sistema capture diferentes facetas semánticas —como palabras clave, definiciones, contexto de fondo o relaciones causales— y recupere el contenido desde múltiples perspectivas. - Reclasificación avanzada para una selección precisa
Después de que una búsqueda vectorial inicial recupera pasajes candidatos, un modelo separado de alta precisión (por ejemplo, un modelo de reclasificación como Cohere Rerank) evalúa su relevancia para la consulta de manera más rigurosa y los reordena en consecuencia. Este paso adicional mejora significativamente la calidad de la selección final.
Si bien estas técnicas requieren un esfuerzo de implementación adicional, mejoran drásticamente el rendimiento de RAG una vez implementadas. En la práctica, ofrecen una forma muy rentable de mejorar la precisión de la recuperación y la calidad de las respuestas.
En particular, la combinación de fragmentos más grandes con vectorización de uno a muchos —a menudo implementada a través de fragmentos jerárquicos (por ejemplo, fragmentos principales e secundarios)— permite que los documentos largos sigan siendo ricos en contexto y al mismo tiempo se puedan buscar con precisión detallada. Examinaremos estas técnicas con más detalle en una sección posterior.
Fragmentación jerárquica: organización de documentos largos en capas
La fragmentación jerárquica es un método para dividir un documento largo en capas de diferentes tamaños —por ejemplo, fragmentos más grandes “principales” que preservan un contexto amplio y fragmentos más pequeños “secundarios” que capturan detalles específicos. Cada capa se vectoriza por separado.
Esta estructura en capas permite que el sistema mantenga intacto el significado general del documento y al mismo tiempo recupere información precisa y detallada cuando sea necesario. En términos simples, permite a RAG ver tanto el “panorama general” como los “detalles importantes” al mismo tiempo.
Punto clave
Las claves para mejorar la precisión de RAG: fragmentos más largos, vectorización de uno a muchos y reclasificación avanzada
Mejorar la precisión de RAG depende de tres dimensiones:
1. Qué unidad de significado se utiliza
2. ¿cuántas perspectivas semánticas se capturan
3. Con qué precisión se filtran los candidatos
Primero, con respecto a la unidad de significado: RAG divide los documentos fuente externos en fragmentos, los convierte en vectores y recupera los más relevantes. Si los fragmentos son demasiado pequeños, se pierde el contexto y se rompe la coherencia semántica. Por el contrario, el uso de fragmentos más largos ayuda a preservar un contexto más amplio, lo que permite una recuperación semánticamente más cohesiva y precisa.
A continuación, sobre cómo capturar el significado desde múltiples perspectivas: las primeras implementaciones de RAG generalmente producían una única incrustación por fragmento. Sin embargo, esto a menudo era insuficiente para captar los diversos aspectos de un texto. La vectorización de uno a muchos genera múltiples incrustaciones a partir de un solo fragmento, cada una de las cuales representa diferentes puntos de vista semánticos —como palabras clave, definiciones, conocimientos previos o relaciones causales. Esto da como resultado una recuperación más rica y multidimensional.
Finalmente, sobre cómo refinar la precisión de la selección: después de recuperar los fragmentos candidatos, un paso adicional determina cuáles se pasan al LLM. Confiar únicamente en la similitud de vectores es inadecuado. Para extraer la información contextualmente más apropiada, es esencial una reclasificación avanzada. Este proceso mejora significativamente las posibilidades de producir respuestas relevantes y significativas.
6.3Desafíos de RAG: los LLM tienen dificultades para leer tablas (Excel)
Otro obstáculo importante para la adopción práctica de RAG son los datos estructurados —como las hojas de cálculo creadas en Excel.
Esto puede parecer sorprendente, pero los LLM no son particularmente buenos leyendo tablas de Excel. Los LLM están entrenados principalmente para procesar texto secuencialmente, de izquierda a derecha. Por el contrario, el significado de una tabla (una estructura bidimensional) depende de relaciones tanto verticales como horizontales. Cuando se tratan como texto ordinario, las tablas suelen ser difíciles de interpretar correctamente para los LLM.
Sin embargo, en entornos empresariales reales, los datos están en todas partes en forma de hojas de cálculo. Sin abordar esta cuestión, es imposible construir sistemas RAG verdaderamente prácticos. Entonces, ¿cómo se puede solucionar? La respuesta es sencilla: convertir tablas a formatos que los LLM puedan leer eficazmente —es decir, en texto estructurado.
Un enfoque es describir manualmente la tabla en oraciones (por ejemplo, “La columna A representa X, la columna B representa Y”). Sin embargo, hoy en día es más común convertir tablas a formatos que sean más fáciles de procesar para los programas y de entender estructuralmente para los LLM—, como las tablas JSON o Markdown.
Formatos JSON y Markdown
¿Qué son exactamente estos formatos? Estos son los puntos clave:
¿qué es JSON?
• Un formato de texto que representa datos como pares “clave: valor”
• Fácil de procesar para los programas, con una estructura claramente definida
¿Qué es Markdown?
• Un formato de texto liviano que utiliza símbolos simples para representar tablas. •
Fácil de leer para los humanos y de reconocer estructuralmente para los LLM.
• Permite escribir encabezados, viñetas y tablas de una manera sencilla
6.4La dificultad de integración con el espacio semántico del LLM
Con estas medidas, RAG puede funcionar a nivel práctico. Sin embargo, sigue existiendo una brecha entre un sistema que simplemente “funciona” y uno que parece tan natural como si el conocimiento fuera nativo del LLM.
La cuestión central es la interpretación. Incluso si la recuperación es perfecta, es posible que los documentos llenos de términos médicos especializados, legales o específicos de la empresa no se comprendan completamente. Sin captar sus matices, el modelo puede citar la fuente correcta pero aun así malinterpretarla— produciendo respuestas que parecen ligeramente fuera de lugar.
Punto clave
La limitación fundamental de RAG radica en la “fragmentación de los mundos semánticos”
En un sistema RAG típico, el componente que recupera el conocimiento externo y el modelo de lenguaje grande (LLM) que interpreta la consulta y genera la respuesta final operan como entidades en gran medida independientes. Como resultado, el sistema en su conjunto lucha por mantener una “visión del mundo” o comprensión cohesiva y unificada del contexto.
Es algo así como tener dos traductores —uno responsable de responder y el otro de buscar—, cada uno hablando en un dialecto semántico ligeramente diferente. Durante el proceso de conversión de consultas y pasajes recuperados.
en “el lenguaje numérico de los vectores”, cada componente interpreta el significado dentro de su propio dominio semántico distinto. Esta sutil desalineación puede provocar inconsistencias y una pérdida de coherencia en la respuesta final.
Esta “división de mundos” es, en esencia, el factor central que socava la confiabilidad y consistencia de las respuestas generadas por RAG
6.5Por qué ChatGPT y Gemini funcionan como sistemas «RAG superiores»
Cuando ChatGPT se lanzó por primera vez en 2022, respondía rutinariamente a preguntas sobre eventos recientes con una exención de responsabilidad estándar:
“Me entrenaron con datos hasta septiembre de 2021”
Hoy en día, sin embargo, los últimos modelos GPT (comenzando con GPT-4o y posteriores) pueden realizar búsquedas web en tiempo real de forma predeterminada, incorporar información actualizada y responder de forma natural. Estos sistemas pueden considerarse implementaciones altamente sofisticadas de RAG.
En este capítulo, hemos examinado los desafíos clave en la construcción de sistemas RAG, incluida la fragmentación, la recuperación y el manejo de datos estructurados. A continuación se resumen las principales cuestiones y su dificultad relativa.
Resumen de los desafíos de RAG
| Desafío | Dificultad | Razón principal |
| Restricciones de longitud del fragmento | Bajo | Los métodos establecidos, como la vectorización de uno a muchos (incluida la fragmentación jerárquica), están disponibles y son relativamente fáciles de implementar. |
| Mejora de la precisión de la recuperación | Bajo–Medio | Se puede mejorar mediante la expansión y reclasificación de consultas, pero la eficacia depende de la estrategia de búsqueda y el diseño de metadatos. |
| Manejo de datos estructurados | Medio | Las tablas y formatos como XML deben convertirse a lenguaje natural o formatos de texto estructurado; es posible si se abordan de forma incremental. |
| Desajuste del espacio semántico | Alto | Los términos específicos del dominio fuera del espacio semántico del modelo requieren soluciones estructurales como una integración más profunda o un reentrenamiento. |
| Adaptación dinámica / en tiempo real | Alto | Técnicamente es posible, pero la actualización continua, el monitoreo y la gestión de la consistencia crean una complejidad operativa significativa. |
Cómo ChatGPT y Gemini abordan estos desafíos
¿Cómo responden los últimos modelos —como ChatGPT y Gemini— a estos desafíos relacionados con RAG? Sus enfoques pueden resumirse de la siguiente manera.
Cómo ChatGPT / Gemini manejan los desafíos de RAG
| Desafío | Enfoque en ChatGPT / Gemini |
| Restricciones de longitud del fragmento | Las ventanas de contexto muy grandes reducen la necesidad de realizar fragmentos finos; los pasajes largos se pueden procesar e integrar directamente. |
| Mejora de la precisión de la recuperación | El modelo infiere intenciones, reformula consultas y realiza de manera efectiva la expansión y reclasificación de consultas internas. |
| Manejo de datos estructurados | Entrenado en CSV, JSON y código; puede interpretar datos estructurados de forma lógica y ejecutar cálculos cuando sea necesario. |
| Desajuste del espacio semántico | Un amplio espacio semántico compartido reduce las brechas, pero los términos específicos del dominio no vistos aún requieren una inyección de contexto explícita (por ejemplo, RAG). |
| Adaptación dinámica / en tiempo real | Cuando el modelo determina que su conocimiento interno puede estar desactualizado, puede llamar de forma autónoma a herramientas como la búsqueda web para recuperar información actualizada antes de generar una respuesta. |
No más límites de fragmentos — y una comprensión más inteligente de los datos estructurados
Uno de los puntos más llamativos de la tabla anterior es la eliminación práctica de límites estrictos al tamaño de entrada (fragmentos). Esta es una fortaleza que los sistemas RAG tradicionales no pueden replicar fácilmente. Incluso cuando el contenido recuperado es relativamente largo, el modelo puede leerlo en su totalidad, integrar el contexto y comprenderlo como un todo.
Los primeros LLM tenían dificultades con datos estructurados, como hojas de cálculo de Excel. Hoy en día, sin embargo, los modelos se entrenan en una amplia gama de formatos estructurados —incluidas tablas CSV, JSON, HTML y tablas Markdown—, lo que mejora enormemente su capacidad para reconocer e interpretar dichos patrones. Además, cuando sea necesario, pueden procesar datos mediante programación utilizando código como Python.
Alineación semántica — Una fortaleza exclusiva de los desarrolladores de LLM
Dos desafíos importantes en los sistemas RAG convencionales —el desajuste del espacio semántico y la adaptación en tiempo real— se abordan de manera más fluida en los modelos avanzados.
La principal ventaja radica en la estrecha integración de la recuperación y la generación. En un RAG típico, el motor de búsqueda y el modelo generativo funcionan por separado. Por el contrario, modelos como ChatGPT determinan qué información se necesita, la recuperan y la interpretan dentro del mismo sistema. Esta integración profunda es posible porque el desarrollador del modelo controla ambos componentes.
Sin embargo, los términos específicos de la empresa o la jerga altamente especializada que faltan en los datos de capacitación aún requieren una inyección de contexto explícita —por ejemplo, proporcionando documentos relevantes en el mensaje.
Para la adaptación en tiempo real, los modelos modernos pueden reconocer cuándo su conocimiento puede estar desactualizado, llamar de forma autónoma a herramientas de búsqueda web e incorporar información actualizada antes de responder.
