¿La generación aumentada por recuperación (RAG) será eliminada por los LLM de contexto largo?
La búsqueda de la innovación y la supremacía en IA no muestra señales de desaceleración. Recientemente, Google reveló Gemini 1.5, apenas dos meses después del debut de Gemini, su más reciente modelo de lenguaje grande (LLM) capaz de manejar contextos que abarcan hasta unos impresionantes 10 millones de tokens. Simultáneamente, OpenAI ha salido a escena con Sora, un robusto modelo de texto a video celebrado por sus cautivadores efectos visuales. El enfrentamiento de estas dos tecnologías de vanguardia ha desatado debates sobre el futuro de la IA, especialmente sobre el papel y la posible desaparición de Retrieval Augmented Generation (RAG).
En este blog, exploraremos las complejidades de las capacidades de contexto largo de Gemini, sus limitaciones y su impacto en la evolución de las técnicas de Retrieval Augmented Generation. Lo más importante es que analizaremos si RAG está al borde de la desaparición y cómo optimizar los sistemas RAG.
Comprender la capacidad de contexto largo de Gemini
Aunque el atractivo de los efectos visuales de Sora capta más atención, a mí me interesa más Gemini y su informe técnico adjunto, que abarca más de 50 páginas y explora las pruebas de las capacidades de contexto largo y multimodales de Gemini. Según este informe, Gemini 1.5 Pro admite contextos ultralargos de hasta 10 millones de tokens y procesamiento de datos multimodales, lo que permite a Gemini interactuar sin problemas con datos diversos, desde un libro completo y enormes colecciones de documentos hasta amplias bibliotecas de código y una película de una hora.
Gemini 1.5 Pro admite contextos ultralargos de hasta 10M tokens. Fuente de la imagen: https://blog.google/technology/ai/google-gemini-next-generation-model-february-2024/
Estabilidad y precisión de recuperación
Este informe introduce un método de evaluación de "aguja en un pajar" para probar y comparar la capacidad de recuperación de Gemini 1.5 Pro y GPT-4. En esta prueba, Google inserta segmentos de texto (las "agujas") en diferentes posiciones de un documento extenso (el "pajar"), y Gemini y GPT deben encontrar y nombrar documentos relevantes para recuperarlos.
Los resultados de las pruebas muestran que Gemini 1.5 Pro alcanza un 100% de recall con hasta 530.000 tokens y mantiene más del 99,7% de recall con hasta 1M tokens. Incluso con un documento superlargo de 10M tokens, el modelo conserva una impresionante tasa de recall del 99,2%. Mientras que GPT-4 maneja excelentemente menos de 128.000 tokens, Gemini es más competente en el manejo de contextos más extensos. Estos resultados subrayan la excelente recuperación de información, estabilidad y precisión de Gemini en contextos excepcionalmente extensos de hasta 10M tokens.
Fuente de la imagen: https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
Respuesta a preguntas
Además de probar la capacidad de recuperación de Gemini, Google evalúa su capacidad de respuesta a preguntas proporcionando contexto. En esta prueba, Google utiliza el libro Los miserables (710.000 tokens) como contexto y pide a Gemini 1.5 Pro, Gemini 1.0 Pro y Claude 2.1 de Anthropic que respondan preguntas sobre el libro.
Dado que Gemini 1.0 Pro y Claude 2.1 admiten una longitud de contexto menor que 710,000 tokens, deben aprovechar la técnica de generación aumentada por recuperación (RAG) para acceder a los pasajes más relevantes de Top-K (hasta 4,000 tokens) del libro como su contexto. Gemini tiene una ventana de contexto más grande, por lo que toma como contexto el libro completo. Esta prueba también compara el rendimiento de los tres modelos en la configuración 0-shot sin que se proporcione nada como contexto.
Los resultados de las pruebas muestran que Gemini 1.5 Pro supera a otros LLMs impulsados por RAG al responder preguntas, lo que demuestra su dominio en la comprensión y el procesamiento de enormes colecciones de texto. Esta prueba también revela que la técnica de generación aumentada por recuperación a menudo tiene dificultades para resolver expresiones de referencia y razonamiento entre fuentes de datos con dependencias de larga distancia.
Fuente de la imagen: https://storage.googleapis.com/deepmind-media/gemini/gemini_v1_5_report.pdf
¿Los LLMs de contexto largo acabarán con RAG?
El marco de generación aumentada por recuperación, que incorpora una base de datos vectorial, un LLM y prompt-as-code, es una tecnología de vanguardia que integra sin problemas fuentes de conocimiento externas para enriquecer la base de conocimiento de un LLM y obtener documentos y respuestas precisos y relevantes. Es una solución probada que aborda eficazmente desafíos fundamentales de los LLM, como las alucinaciones y la falta de conocimiento específico del dominio.
Al presenciar el impresionante rendimiento de Gemini al manejar contextos largos, algunas voces predicen rápidamente la desaparición de RAG. Por ejemplo, en una reseña de Gemini 1.5 Pro en Twitter, el Dr. Yao Fu afirmó audazmente: "El contexto de 10M acaba con RAG."
¿Es cierta esta afirmación? Desde mi perspectiva, la respuesta es “NO.” El desarrollo de la tecnología RAG apenas ha comenzado y seguirá evolucionando. Aunque Gemini sobresale en la gestión de contextos extendidos, lidia con desafíos persistentes resumidos en las 4V: Velocidad, Valor, Volumen y Variedad.
Los desafíos de las 4V de los LLMs
Velocidad: Gemini enfrenta obstáculos para lograr tiempos de respuesta inferiores a un segundo en contextos extensos, como evidencia una demora de 30 segundos al responder a 360,000 contextos. A pesar del optimismo sobre los avances computacionales de los LLMs, las respuestas rápidas a nivel inferior a un segundo al recuperar contextos largos siguen siendo un desafío para los grandes modelos basados en transformers.
Valor: La propuesta de valor de los LLMs se ve socavada por los considerables costos de inferencia asociados con la generación de respuestas de alta calidad en contextos largos. Por ejemplo, recuperar 1 millón de tokens de conjuntos de datos a una tarifa de 1.50 por una sola solicitud. Este factor de costo hace que tales gastos elevados sean poco prácticos para el uso cotidiano, lo que plantea una barrera significativa para la adopción generalizada.
Volumen: A pesar de su capacidad para manejar una gran ventana de contexto de hasta diez millones de tokens, la capacidad de volumen de Gemini queda eclipsada en comparación con la inmensidad de los datos no estructurados. Por ejemplo, ningún LLM, incluido Gemini, puede albergar adecuadamente la escala colosal de datos que se encuentra dentro del índice de búsqueda de Google. Además, los datos corporativos privados tendrán que permanecer dentro de los límites de sus propietarios, quienes pueden optar por usar RAG, entrenar sus propios modelos o usar un LLM privado.
Variedad: Los casos de uso del mundo real implican no solo datos no estructurados como textos extensos, imágenes y videos, sino también una diversa gama de datos estructurados que pueden no ser capturados fácilmente por un LLM con fines de entrenamiento, como datos de series temporales, datos de grafos y cambios en el código. Las estructuras de datos y los algoritmos de recuperación optimizados son esenciales para procesar datos tan variados de manera eficiente.Todos estos desafíos resaltan la importancia de un enfoque equilibrado en el desarrollo de aplicaciones de IA, lo que hace que RAG sea cada vez más crucial en el panorama en evolución de la inteligencia artificial.
Estrategias para optimizar la efectividad de RAG
Aunque la generación aumentada por recuperación ha demostrado ser beneficiosa para reducir las alucinaciones de los LLM, tiene limitaciones. En esta sección, exploraremos estrategias para optimizar la efectividad de la generación aumentada por recuperación con el fin de lograr un equilibrio entre precisión y rendimiento para hacer que los sistemas RAG sean más adaptables en una gama más amplia de aplicaciones.
Mejorar la comprensión de contextos largos
Las técnicas convencionales de generación aumentada por recuperación suelen depender de la fragmentación para vectorizar datos no estructurados, principalmente debido a las limitaciones de tamaño de los modelos de embeddings y sus ventanas de contexto. Sin embargo, este enfoque de fragmentación presenta dos desventajas notables.
- En primer lugar, divide la secuencia de entrada en fragmentos aislados, interrumpiendo la continuidad del contexto e impactando negativamente en la calidad de los embeddings.
- En segundo lugar, existe el riesgo de separar información consecutiva en fragmentos distintos, lo que podría dar lugar a una recuperación incompleta de información esencial.
En respuesta a estos desafíos, las estrategias emergentes de embeddings basadas en LLMs han ganado terreno como soluciones eficientes. Presumen de una mejor capacidad de embedding y admiten ventanas de contexto ampliadas. Por ejemplo, SRF-Embedding-Mistral y GritLM7B, dos de los modelos de lenguaje de embeddings con mejor rendimiento en el Huggingface MTEB LeaderBoard, admiten contextos de 32k tokens, lo que muestra una mejora sustancial en las capacidades de embedding. Esta mejora en el embedding de datos no estructurados también eleva la comprensión de RAG de los contextos largos.
Otro enfoque eficaz para abordar los desafíos anteriores es la estrategia BGE Landmark Embedding, lanzada recientemente. Este enfoque adopta una arquitectura sin fragmentación, donde los embeddings para las unidades de entrada de grano fino, por ejemplo, oraciones, pueden generarse en función de un contexto largo coherente. También aprovecha una función consciente de la posición para facilitar la recuperación completa de información útil que comprende múltiples oraciones consecutivas dentro del contexto largo. Por lo tanto, landmark embedding es beneficioso para mejorar la capacidad de los sistemas RAG de comprender y procesar contextos largos.
La arquitectura para landmark embedding. Los tokens Landmark (LMK) se agregan al final de cada oración. Se emplea una ventana deslizante para manejar los textos de entrada más largos que la ventana de contexto del LLM. Fuente de la imagen: https://arxiv.org/pdf/2402.11573.pdf
Este diagrama compara los métodos Sentence Embedding y Landmark Embedding para ayudar a las aplicaciones RAG a responder preguntas. El primero funciona con el contexto fragmentado, que tiende a seleccionar la oración destacada. El segundo mantiene un contexto coherente, lo que le permite seleccionar la oración correcta. Las oraciones resaltadas en azul y morado son respuestas recuperadas por los dos métodos de embedding, respectivamente. El sistema RAG que aprovechó Sentence embedding dio la respuesta incorrecta, mientras que el RAG basado en Landmark embedding dio la respuesta correcta. Esta imagen está adaptada de: https://arxiv.org/abs/2402.11573
Utilizar la búsqueda híbrida para mejorar la calidad de búsqueda
La calidad de las respuestas de generación aumentada por recuperación depende de su capacidad para recuperar información relevante de alta calidad. La limpieza de datos, la extracción de información estructurada y la búsqueda híbrida son formas eficaces de mejorar la calidad de la recuperación. Investigaciones recientes sugieren que los modelos de vectores dispersos como Splade superan a los modelos de vectores densos en la recuperación de conocimiento fuera del dominio, la percepción de palabras clave, la búsqueda semántica y muchas otras áreas.
El modelo de embedding BGE_M3, recientemente publicado como código abierto, puede generar vectores de tokens dispersos, densos y similares a Colbert dentro del mismo modelo. Esta innovación mejora significativamente la calidad de recuperación de la base de datos vectorial al realizar recuperaciones híbridas entre diferentes tipos de vectores. Cabe destacar que este enfoque se alinea con el concepto ampliamente aceptado de búsqueda híbrida entre proveedores de bases de datos vectoriales como Zilliz. Por ejemplo, el próximo lanzamiento de Milvus 2.4 promete una búsqueda híbrida más completa de vectores densos y dispersos.
Utilizar tecnologías avanzadas para mejorar el rendimiento de RAG
En este diagrama, Wenqi Glantz enumeró 12 puntos débiles en el desarrollo de un pipeline RAG y propuso 12 soluciones correspondientes para abordar estos desafíos. Fuente de la imagen:https://towardsdatascience.com/12-rag-pain-points-and-proposed-solutions-43709939a28c
Maximizar las capacidades de RAG implica abordar numerosos desafíos algorítmicos y aprovechar capacidades y tecnologías de ingeniería sofisticadas. Como destaca Wenqi Glantz en su blog, desarrollar un pipeline RAG presenta al menos 12 desafíos de ingeniería complejos. Abordar estos desafíos requiere una comprensión profunda de los algoritmos de ML y utilizar técnicas complicadas como la reescritura de consultas, los datos de entrenamiento para el reconocimiento de intención, y la detección de entidades.
Incluso modelos avanzados como Gemini 1.5 enfrentan obstáculos sustanciales. Requieren 32 llamadas para alcanzar una tasa de precisión del 90.0% en las pruebas de referencia MMLU de Google. Esto subraya la naturaleza de maximizar el rendimiento en los sistemas RAG.
Las bases de datos vectoriales, una de las tecnologías de IA más avanzadas, son un componente central en el pipeline de RAG. Optar por una base de datos vectorial más madura y avanzada, como Milvus, amplía las capacidades de tu pipeline de RAG desde la generación de respuestas hasta tareas como la clasificación, la extracción de datos estructurados y el manejo de documentos PDF complejos. Estas mejoras multifacéticas de las bases de datos vectoriales contribuyen a la adaptabilidad de los sistemas RAG en un espectro más amplio de casos de uso de aplicaciones.
Conclusión: RAG sigue siendo un eje central para el éxito sostenido de las aplicaciones de IA.
Los grandes modelos de lenguaje están remodelando el mundo, pero no pueden cambiar los principios fundamentales de nuestro mundo. La separación de computación, memoria y almacenamiento de datos externo existe desde la creación de la arquitectura de von Neumann en 1945. Sin embargo, incluso con la memoria de una sola máquina alcanzando hoy el nivel de terabytes, los discos SATA y flash siguen desempeñando funciones cruciales en diferentes casos de uso de aplicaciones. Esto demuestra la resiliencia de los paradigmas establecidos frente a la evolución tecnológica.
El framework RAG sigue siendo un eje central para el éxito sostenido de las aplicaciones de IA. Su provisión de memoria a largo plazo para los grandes modelos de lenguaje resulta indispensable para los desarrolladores que buscan un equilibrio óptimo entre la calidad de las consultas y la rentabilidad. Al implementar IA generativa en grandes empresas, RAG es una herramienta crítica para el control de costos sin comprometer la calidad de las respuestas.
Así como los avances en memoria de gran capacidad no pueden desplazar a los discos duros, el papel de RAG, junto con sus tecnologías de apoyo como la base de datos vectorial, sigue siendo integral y adaptativo. Está preparado para perdurar y coexistir dentro del nuevo panorama de datos en constante evolución de las aplicaciones de IA y la recuperación de información.
Sigue leyendo
Zilliz Cloud Enterprise Vector Search Powers High-Performance AI on AWS
Zilliz Cloud on AWS powers secure, scalable, ultra-fast vector search for enterprise AI apps, with BYOC, sub-10ms latency, and zero-DevOps simplicity.
AI Agents Are Quietly Transforming E-Commerce — Here’s How
Discover how AI agents transform e-commerce with autonomous decision-making, enhanced product discovery, and vector search capabilities for today's retailers.
How to Use Anthropic MCP Server with Milvus
MCP + Milvus: Streamline AI agent development with standardized data access, eliminating integration hassles while enhancing context and flexibility.