Cuando leí el artículo reciente en VentureBeat sobre cómo Glean acaba de obtener más de 260 millones de dólares en su última ronda de financiaciónTuve dos intuiciones inmediatas. En primer lugar, fue satisfactorio ver este ejemplo tan público de Graph RAG aprovechando su potencial como una tecnología poderosa y valiosa que conecta a las personas con el conocimiento de manera más eficiente que nunca. En segundo lugar, fue sorprendente pero valido leer:
Una de las empresas de viajes compartidos más grandes del mundo experimentó sus beneficios de primera mano. Después de dedicar un equipo completo de ingenieros a desarrollar una solución interna similar, finalmente decidieron hacer la transición a la plataforma de Glean.
“En un mes, vieron el doble de uso en la plataforma Glean porque los resultados estaban ahí”, dice Matt Kixmoeller, CMO de Glean.
Aunque me sorprendió leer sobre la falla en un artículo de noticias, lo que esperaría es tener dificultades para poner Graph RAG en producción, según mi experiencia, así como la de mis compañeros de trabajo y clientes. No estoy diciendo que espere que las grandes empresas de tecnología fracasen en la construcción de su propio sistema gráfico RAG. Simplemente espero que la mayoría de la gente tenga dificultades para construir y producir el gráfico RAG, incluso si ya tienen una prueba de concepto muy exitosa.
escribí un reacción de alto nivel al artículo de VentureBeat en The New Stacky en este artículo, me gustaría profundizar en por qué el gráfico RAG puede ser tan difícil de hacer bien. Primero, señalaré lo fácil que se ha vuelto, utilizando las últimas herramientas, comenzar con Graph RAG. Luego, profundizaré en algunos de los desafíos específicos de Graph RAG que pueden hacer que sea tan difícil pasar de I+D a producción. Finalmente, compartiré algunos consejos sobre cómo maximizar sus posibilidades de éxito con Graph RAG.
Entonces, si una gran empresa de viajes compartidos no pudo construir su propia plataforma de manera efectiva, ¿por qué diría que es fácil implementar Graph RAG usted mismo?
Bueno, en primer lugar, las tecnologías que admiten RAG y Graph RAG han avanzado mucho durante el año pasado. Hace doce meses, la mayoría de las empresas ni siquiera habían oído hablar de la generación aumentada por recuperación. Ahora, no sólo es soporte RAG una característica clave de las mejores herramientas de creación de inteligencia artificial como LangChainpero casi todos los actores importantes en el espacio de la IA tienen un tutorial de RAG, y incluso hay un curso de Coursera. No faltan puntos de entrada rápida para probar RAG.
Puede que Microsoft no haya sido el primero en crear Graph RAG, pero le dieron un gran impulso al concepto con un publicación de blog de investigación a principios de este añoy continúan trabajando en tecnología relacionada.
Aquí en Medium también hay una buena introducción conceptual, con algunos detalles técnicos. de un ingeniero de inteligencia artificial de Google. Y, en Towards Data Science, hay un reciente y muy completo artículo instructivo sobre cómo construir un sistema RAG gráfico y pruebas en un conjunto de datos de publicaciones científicas.
Neo4j, un nombre establecido en análisis y bases de datos de gráficos tradicionales, agregó capacidades vectoriales a su producto insignia de base de datos de gráficos en respuesta a la reciente revolución de la IA de generación, y tiene una excelente plataforma de herramientas para proyectos que requieren análisis de gráficos sofisticados y algoritmos de gráficos profundos en Además de las capacidades de RAG de gráficos estándar. También tienen un Primeros pasos con Graph RAG guía.
Por otro lado, ni siquiera necesitas una base de datos gráfica para hacer RAG gráfico. Muchas personas que son nuevas en Graph RAG creen que necesitan implementar una base de datos de gráficos especializada, pero esto no es necesario y, de hecho, puede simplemente complicar su pila tecnológica.
Mi empleador, DataStax, también tiene una Guía para graficar RAG.
Y, por supuesto, los dos marcos de composición de aplicaciones de IA de generación más populares, LangChain y LlamaIndexcada uno tiene sus propias presentaciones de RAG de gráficos. Y hay un artículo de DataCamp que usa ambos.
Con todas las herramientas y tutoriales disponibles, comenzar con Graph RAG es la parte fácil…
Esta es una historia muy antigua en la ciencia de datos: una nueva metodología, tecnología o herramienta de software resuelve algún problema imponente en un contexto de investigación, pero la industria lucha por convertirlo en productos que entreguen valor a diario. No es sólo una cuestión de esfuerzo y competencia en el desarrollo de software: incluso los equipos más grandes, mejores y más brillantes podrían no ser capaces de superar la incertidumbre, la imprevisibilidad y la incontrolabilidad de los datos del mundo real involucrados en la resolución de problemas del mundo real.
La incertidumbre es una parte inherente de la construcción y el uso de sistemas centrados en datos, que casi siempre tienen algunos elementos de estocasticidad, probabilidad o entradas ilimitadas. Y la incertidumbre puede ser aún mayor cuando las entradas y salidas no están estructuradas, como es el caso de las entradas y salidas del lenguaje natural de los LLM y otras aplicaciones GenAI.
Las personas que quieren probar Graph RAG generalmente ya tienen una aplicación RAG existente que funciona bien para casos de uso simples, pero falla en algunos de los casos de uso más complejos y solicitudes que requieren múltiples datos en una base de conocimientos, potencialmente en diferentes documentos y contextos. , formatos o incluso almacenes de datos. Cuando toda la información necesaria para responder una pregunta está en la base de conocimientos, pero el sistema RAG no la encuentra, parece un fracaso. Y desde la perspectiva de la experiencia del usuario (UX), lo es: no se dio la respuesta correcta.
Pero eso no significa necesariamente que haya un “problema” con el sistema RAG, que podría estar funcionando exactamente como fue diseñado. Si no hay ningún problema o error, pero todavía no obtenemos las respuestas que queremos, eso debe significar que esperamos que el sistema RAG tenga una capacidad que simplemente no tiene.
Antes de ver por qué es difícil poner en producción el gráfico RAG, echemos un vistazo al problema que estamos tratando de resolver.
Debido a que los sistemas RAG simples (sin gráficos de conocimiento) recuperan documentos basándose únicamente en la búsqueda de vectores, solo se pueden recuperar los documentos que sean más semánticamente similares a la consulta. Los documentos que no son semánticamente similares en absoluto, o que no son lo suficientemente similares, se omiten y generalmente no se ponen a disposición del LLM, generando una respuesta al mensaje en el momento de la consulta.
Cuando los documentos que necesitamos para responder a una pregunta en un mensaje no son todos semánticamente similares al mensaje, un sistema RAG a menudo pasa por alto uno o más de ellos. Esto puede suceder cuando responder la pregunta requiere una combinación de documentos o términos generalizados y especializados, y cuando los documentos son densos en detalles en el sentido de que algunos detalles muy importantes para esta pregunta específica están enterrados en medio de detalles relacionados que no son tan relevante para este mensaje. Ver este artículo para ver un ejemplo de documentos faltantes de RAG porque dos conceptos relacionados (“Space Needle” y “barrio Lower Queen Anne” en este caso) no son semánticamente similares, y Consulte este artículo para ver un ejemplo de detalles importantes que se entierran. en documentos con muchos detalles porque las incrustaciones de vectores tienen “pérdidas”.
Cuando vemos que la recuperación “no logra” encontrar los documentos correctos, puede resultar tentador intentar mejorar la búsqueda vectorial o adaptarla más a nuestro caso de uso. Pero esto requeriría jugar con las incorporaciones, y las incorporaciones son complicadas, confusas, costosas de calcular y aún más costosas de ajustar. Además, esa ni siquiera sería la mejor manera de resolver el problema.
Por ejemplo, si observamos el ejemplo vinculado anteriormente, ¿realmente querríamos utilizar un algoritmo de incrustación que coloque el texto “Space Needle” y “Lower Queen Anne Neighborhood” juntos en el espacio vectorial semántico? No, ajustar o encontrar un algoritmo de incrustación que coloque esos dos términos muy juntos en el espacio semántico probablemente tendría algunos efectos secundarios inesperados y no deseados.
Es mejor no intentar forzar a un modelo semántico a realizar un trabajo para el que la información geográfica o turística sería mucho más adecuada. Si yo fuera una empresa de viajes o turismo que dependiera de saber en qué vecindario se encuentran dichos puntos de referencia, preferiría crear una base de datos que sepa estas cosas con certeza, una tarea que es mucho más fácil que hacer que la búsqueda de vectores semánticos haga la misma tarea… sin completar certeza.
Entonces, el problema principal aquí es que tenemos conceptos e información que sabemos que están relacionados de alguna manera, pero no en el espacio vectorial semántico. Alguna otra fuente de información (no vectorial) nos dice que existen conexiones entre la amplia variedad de conceptos con los que estamos trabajando. La tarea de crear una aplicación RAG de gráficos es capturar de manera efectiva estas conexiones entre conceptos en un gráfico de conocimiento y utilizar las conexiones del gráfico para recuperar documentos más relevantes para responder a un mensaje.
Para resumir el problema que estamos tratando de abordar con el gráfico RAG: existe información semiestructurada y no semántica que conecta muchos de los conceptos que aparecen en mis documentos no estructurados, y me gustaría usar esta información de conexión para complementar el vector semántico. buscar para recuperar los documentos que mejor se adapten a responder solicitudes y preguntas dentro de mis casos de uso. Simplemente queremos mejorar la recuperación y queremos usar información externa o lógica externa para lograrlo, en lugar de depender únicamente de la búsqueda de vectores semánticos para conectar indicaciones con documentos.
Teniendo en cuenta la motivación anterior (utilizar información “externa” para establecer conexiones de documentos que la búsqueda semántica pasa por alto), existen algunos principios rectores que podemos tener en cuenta al crear y probar una aplicación RAG de gráficos:
- El gráfico debe contener conceptos y conexiones significativos y de alta calidad.
- Los conceptos y conexiones deben ser relevantes para las indicaciones dentro del conjunto de casos de uso.
- Las conexiones de gráficos deben complementar, no reemplazar, la búsqueda de vectores
- Se debe priorizar la utilidad de las conexiones de gráficos de uno y dos pasos; confiar en más de tres pasos para realizar conexiones debe reservarse solo para casos de uso especializados.
Quizás en un artículo futuro, profundicemos en los matices y los impactos potenciales de seguir estos principios, pero por ahora, solo señalaré que esta lista tiene como objetivo aumentar conjuntamente la explicabilidad, evitar la complejidad excesiva y maximizar la eficiencia de ambos. y utilizando un sistema gráfico RAG.
Seguir estos principios junto con otros principios básicos de la ingeniería de software y la ciencia de datos puede aumentar sus posibilidades de crear con éxito una aplicación RAG de gráficos útil y potente, pero ciertamente existen obstáculos en el camino, que describimos en la siguiente sección.