Los problemas de RAG persisten: he aquí cinco formas de solucionarlos

Es hora de enfrentarse a la verdad sobre la generación aumentada por recuperación, o RAG: es una solución que necesita su propia solución.

El objetivo de la RAG era mejorar el rendimiento de modelos de lenguaje de gran tamaño (LLM) y reducir las alucinaciones, permitiendo que los LLMs fueran más allá de sus datos de entrenamiento con acceso a bases de conocimiento externas. Sin embargo, los límites reales de los sistemas de RAG tradicionales han quedado muy claros.

“En gran medida, la RAG es defectuosa”, afirmó Dinesh Nirmal, vicepresidente sénior de IBM® Software. “La RAG pura realmente no está dando los resultados óptimos que se esperaban”.

Los retos de la RAG que suelen enfrentar los usuarios incluyen limitaciones en ventanas de contexto y operaciones de agregación, incapacidad para comprender relaciones complejas y resultados de baja calidad asociados a una fragmentación subóptima. Es decir, la implementación de RAG también puede presentar problemas de seguridad, como la fuga de datos.

La buena noticia es que los avances en herramientas y estrategias de inteligencia artificial están ayudando a compensar los defectos de la RAG tradicional, lo que se traduce en respuestas generadas más precisas a las consultas de los usuarios. Echemos un vistazo más de cerca a cómo mejorar el rendimiento de la RAG.

Pedir a una aplicación de LLM basada en RAG tradicional que realice operaciones de agregación (como calcular una suma) para un conjunto de datos enorme no suele ser difícil, sino literalmente imposible. Una cosa que dificulta el rendimiento del sistema sería el tamaño de la ventana de contexto: las ventanas contextuales de los LLM no suelen ser lo suficientemente escalables para procesar, por ejemplo, una colección de 100 000 facturas. Además, el pipeline de RAG tradicional se basa en bases de datos vectoriales, que están diseñadas para búsquedas por similitud, no para operaciones de agregación.

“Básicamente, significa que una base de datos vectorial no es suficiente para gestionar estos casos”, explicó Sudheesh Kairali, ingeniero distinguido de IBM. “La ventana de contexto es un problema. El otro es la incapacidad para gestionar operaciones matemáticas”.

Entra en escena SQL RAG.  

Cuando los usuarios de LLM buscan respuestas en grandes conjuntos de datos, combinar una generación aumentada por recuperación con SQL puede proporcionar resultados precisos, explicó Kairali.

SQL incluye funciones de agregación integradas, y las bases de datos SQL tienen mayor capacidad que las ventanas de contexto de LLM. Si una empresa consume sus datos de facturas en una base de datos SQL, puede utilizar un LLM para convertir consultas, como “¿Cuál es la suma de todas las facturas del año pasado?”, en SQL, consultar la base de datos SQL a través de RAG y obtener la respuesta.

“Se pueden hacer muchas agregaciones si se es capaz de crearlas”, dijo Kairali. Después de que la base de datos SQL realice una agregación, “en ese momento solo se convierte en un ejercicio de procesamiento del lenguaje natural (PLN) para el LLM”.

Discernir cómo se relacionan entre sí los diferentes fragmentos de información o entidades recuperados es otra de las debilidades de la RAG tradicional. Por ejemplo, consideremos el caso de uso de un paciente con un historial médico complejo. Mediante el proceso de recuperación de la RAG tradicional, un LLM podría proporcionar información relevante. Estos datos podrían incluir detalles como el número de médicos que ha visitado el paciente en un año, pero podría resultar difícil especificar qué tratamientos le ha prescrito cada médico.

GraphRAG, presentado en 2024 por Microsoft Research, aborda este reto procesando e identificando relaciones a través de grafos de conocimiento. GraphRAG organiza la información como una red de nodos y aristas que representan entidades y sus relaciones entre sí.

“Si un paciente ha acudido a un hospital y la pregunta es 'Muéstreme todas las visitas anteriores que ha realizad', eso se puede mostrar no solo como un texto, sino como una representación del conocimiento a través de un grafo”, explicó Nirmal. “Puede ver diferentes puntos múltiples y ver los diferentes médicos que ha visitado, los diferentes medicamentos que ha tomado, los tratamientos a los que se ha sometido, todo en una única representación gráfica”.

GraphRAG, señaló Nirmal, tiene limitaciones porque la representación de un grafo se vuelve más difícil a medida que aumenta el volumen de datos. Mapear cientos de miles de nodos es más difícil que mapear solo unas docenas, por ejemplo. “Todo viene con limitaciones”, dijo Nirmal, “pero la razón por la que GraphRAG está despegando es por las limitaciones de la RAG pura en sí misma”.

Más información sobre GraphRAG.

La fragmentación es crítica para las aplicaciones de RAG. En los modelos tradicionales de fragmentación mediante embedding, los documentos pertinentes se desglosan en puntos fijos en partes más pequeñas, cada una representada en una base de datos vectorial. Sin embargo, este método puede hacer que una aplicación de LLM proporcione respuestas incompletas o inexactas incluso cuando utiliza un algoritmo de machine learning de búsqueda semántica en una base de conocimiento específica de un dominio.

“En este proceso, muchas veces se pierde precisión porque no se sabe dónde se están dividiendo los datos”, explicó Nirmal. “Supongamos que fragmenta o corta una tabla por la mitad, de modo que cuando la recupera, solo obtiene la mitad. En ese momento, ha perdido precisión”.

Afortunadamente, unas mejores estrategias de fragmentación mediante métodos agénticos pueden mejorar la recuperación de información. Esta fragmentación agéntica incluye estrategias como la creación de fragmentos superpuestos y la alteración dinámica del tamaño de los fragmentos en función del contexto de los documentos recuperados. Los marcos de orquestación de LLM pueden ser útiles para este propósito. Por ejemplo, las herramientas TextSplitters de LangChain pueden dividir el texto en pequeños fragmentos semánticamente significativos. Estas estrategias ayudan a evitar la pérdida de información relevante cuando se descompone un documento.

Más información sobre la fragmentación agéntica.

La IA agéntica es útil para la fragmentación y también puede mejorar la precisión de la recuperación de otras formas. Consideremos la RAG agéntica: se trata de un marco de IA avanzado que puede integrar pipelines de RAG para consultar tanto datos estructurados en bases de datos SQL como datos no estructurados en repositorios de documentos, aprovechando las bases de datos vectoriales para la búsqueda por similitud.

La RAG agéntica también enriquece cada fragmento con metadatos. Este proceso correlaciona los datos estructurados (los metadatos almacenados en una base de datos transaccional) con los datos no estructurados para optimizar la precisión de la recuperación.

“Si realmente podemos aprovechar el poder de una base de datos vectorial junto con su aspecto transaccional o SQL y unir ambos”, afirmó Nirmal, “podremos mejorar considerablemente la precisión y el rendimiento”.

Descubra lo que se necesita para superar los tres retos principales de los datos no estructurados.

La fuga de datos es un problema conocido de los sistemas de IA en general, y los LLM que utilizan RAG no son una excepción. Sin las medidas adecuadas, un LLM podría proporcionar a los usuarios de bajo nivel información a la que no están autorizados a acceder, desde información de identificación personal (PII) hasta datos financieros confidenciales.

“Esto es una realidad con la RAG”, dijo Kairali. “Cuando se empieza con la prueba de concepto, todo el mundo está contento. Pero luego, cuando se quiere llevar a producción y se quiere asegurarse de que es apto para el nivel de producción, se empieza a entender que hay un problema de protección de datos”.

Abordar el problema significa preservar las listas de control de acceso (ACL) y otras políticas de gobierno cuando se ingieren datos no estructurados en varias bases de datos. “Cuando llega la consulta y se recuperan los datos, es importante asegurarse de que se respetan las ACL y las políticas de gobierno”, dijo Kairali. “Es básicamente un problema de ingeniería”.

La resolución de este problema de ingeniería puede facilitarse con las plataformas de datos adecuadas, como los lakehouses de datos gobernados y habilitados para código abierto. Por ejemplo, watsonx.data de IBM, un lakehouse de datos híbrido y abierto, garantiza que los controles de acceso se hereden de los sistemas de origen de documentos cuando se recuperan los datos. También proporciona anotaciones de PII para evitar que se comparta información confidencial.

A medida que los LLM y otras IA generativas se arraigan más profundamente en los flujos de trabajo cotidianos, la mejora de RAG ayuda a las empresas a desbloquear un mayor valor de sus datos empresariales. Las herramientas y estrategias adecuadas a nivel empresarial “permiten un mayor rendimiento y precisión para que los datos se vuelvan manejables y valiosos”, afirmó Nirmal. “Eso es lo que buscan todos los clientes”.