Consideraciones prácticas en el diseño de aplicaciones RAG

Consideraciones prácticas para el diseño de aplicaciones RAG

Esta es la segunda parte del análisis RAG:

• parte 1: Desventajas de RAG
• parte 2: Consideraciones Prácticas en el Diseño de Aplicaciones RAG

La arquitectura RAG (Retrieval Augmented Generation) ha demostrado ser eficiente para superar el límite de longitud de entrada LLM y el problema de corte de conocimiento. En la pila técnica LLM actual, RAG es uno de los pilares fundamentales para fundamentar la aplicación en conocimiento local, mitigar las alucinaciones y hacer que las aplicaciones LLM sean auditables. Hay muchos ejemplos de cómo construir una aplicación RAG. Y también existen varios tipos de bases de datos vectoriales.

Muchas personas han notado que, a pesar de que las aplicaciones RAG son fáciles de demostrar, son difíciles de poner en producción. En este artículo, analizaremos algunos detalles prácticos del desarrollo de aplicaciones RAG.

Agenda

• Aprovechando los superpoderes de NLP Un tutorial paso a paso para ajustar finamente Hugging Face
• Oracle presenta su visión para el futuro impulsado por la IA y la nube
• Desbloqueando la transparencia de la IA Cómo el agrupamiento de características de Anthropic mejora la interpretabilidad de las redes neuronales

· La Línea de Base Perfecta de LLM· Expectativa de Rendimiento de RAG· Preservación de Información· Fortalezas y Debilidades de RAG· A Hacia una Mejor Aplicación RAG ∘ Tratamiento a tu LLM ∘ Manteniendo el Modelo de Incrustación en la Misma Página ∘ La Estrategia de Fragmentación Importa ∘ Reducción de la Pérdida de Información ∘ Empatía LLM· Palabras Finales· Referencias

La Línea de Base Perfecta de LLM

Suponiendo que tenemos un LLM generativo con una longitud de entrada ilimitada, la longitud de la cadena de entrada no tiene ninguna influencia en la precisión del LLM generativo. Aparte de eso, se comporta exactamente igual que otros LLM populares. Llamaremos a este modelo el LLM perfecto. Lo consideramos perfecto, no porque tenga un rendimiento excelente, sino porque tiene la deseada longitud de entrada ilimitada, que es imposible en la actualidad. La longitud de entrada ilimitada es realmente una característica atractiva de tener. De hecho, ya hay algunos proyectos ambiciosos trabajando en LLMs con entrada extremadamente larga. ¡Uno de ellos está investigando la posibilidad de un LLM con 1 millón de tokens de longitud de entrada! Sin embargo, temo que incluso el límite de 1 millón de tokens aún podría no ser suficiente en la aplicación porque solo equivale a 4-5 MB. Aún es menor que un gran número de documentos en negocios reales.

Ahora la pregunta es: cuando tienes un LLM perfecto de ese tipo, ¿aún considerarías la arquitectura RAG? El LLM perfecto con longitud de entrada ilimitada reduce la necesidad de construir un RAG complicado. Sin embargo, probablemente sí, todavía necesitarías considerar la arquitectura RAG. La arquitectura RAG ayuda no solo a superar el límite de longitud de entrada LLM, sino también a reducir los costos de invocación de LLM y mejorar la velocidad de procesamiento. Los LLM generativos tienen que procesar el contenido en secuencia. Cuanto más larga sea la entrada, más lento será.

Cuando diseñamos una aplicación RAG, necesitamos utilizar el LLM perfecto supuesto como referencia para examinar la aplicación RAG, de modo que podamos tener una visión clara de los aspectos positivos y negativos de RAG y encontrar formas de mejorar nuestras aplicaciones RAG.

Expectativa de Rendimiento de RAG

Con el modelo de referencia, la entrada de la aplicación de IA generativa se alimentaba directamente al LLM de una sola vez. De esta manera, el LLM tenía la oportunidad de digerir toda la información en el texto de entrada. La precisión del resultado final depende solo de qué tan bien funcione el LLM generativo.

Para una aplicación RAG básica, hay dos componentes más que afectan el rendimiento final: el método de búsqueda semántica y la implementación de RAG. La arquitectura de RAG utiliza un modelo de incrustación para generar vectores de conocimiento de verdad y la consulta. Luego se utiliza la función de similitud de vectores para recuperar el contenido más relevante. La capacidad del modelo de incrustación para extraer significado del texto es muy crítica. Además del modelo de incrustación, hay muchos detalles de implementación en el desarrollo de RAG, que también afectan en gran medida el resultado final. Por lo tanto, la precisión de la salida de RAG sería igual al producto de la precisión del LLM generativo, la precisión de la búsqueda semántica y la tasa de preservación de información de RAG. Explicaré el concepto de la tasa de preservación de información de RAG más adelante.

Dado que los tres factores son inferiores al 100%, la precisión esperada de una aplicación RAG es menor que la de una aplicación basada en el mismo modelo LLM perfecto. Si RAG no está diseñado correctamente, su rendimiento cae significativamente. Ese es el primer concepto a tener en cuenta cuando comenzamos a pensar en el diseño de nuestra aplicación RAG. De lo contrario, el rendimiento inesperado nos sorprenderá.

Dado que el rendimiento final está impulsado por estos tres factores, el diseño de la aplicación RAG también debe centrarse en los tres componentes para lograr un resultado satisfactorio.

Preservación de información

Es fácil entender que tanto el modelo LLM como la búsqueda semántica no pueden lograr una precisión del 100%. Permítanme explicar qué es la tasa de preservación de información de RAG.

El corpus de texto que alimentamos a la aplicación puede tener información muy rica. Observemos qué hay en el corpus y cómo se alimenta la información en el LLM:

El gráfico muestra las relaciones de entidad en el corpus de texto. Las entidades están dispersas por todo el corpus y las relaciones de referencia también están en todas partes. Después del fragmentado, las entidades quedan limitadas en cada grupo y las relaciones entre grupos se cortan. En la fase de recuperación, solo los grupos principales tienen la oportunidad de enviarse a través del LLM. Eso significa que solo una parte de las entidades y relaciones pueden enviarse al LLM. El LLM tendrá problemas si requiere un amplio conocimiento de relaciones para responder a la consulta.

Además de las relaciones de entidad, la operación de fragmentado también tendrá un impacto en una variedad de otros tipos de información en la entrada:

1. Información contextual:

En la mayoría de los casos, el texto tiene múltiples capas de información contextual. Por ejemplo, el libro “The Elements of Statistical Learning” tiene 18 capítulos, cada uno de los cuales se centra en un tema único. Tiene subtemas y subtemas de segundo nivel en cada capítulo, etc. Las personas están acostumbradas a comprender el texto en contexto. La estrategia de fragmentado hace que el contenido se desconecte de su contexto.

2. Información posicional:

Los textos tienen diferentes pesos dependiendo de su posición en el documento. Los textos al principio y al final de un documento son más importantes que los que están en el medio. Son más importantes cuando están al principio o al final de un capítulo que cuando están en medio de un capítulo.

3. Información secuencial:

El texto natural utiliza con frecuencia enlaces lingüísticos explícitos e implícitos para conectar temas. Por ejemplo, una historia puede comenzar con “al principio”, luego continuar con “entonces”, “por lo tanto”, “después de eso”, hasta que termine con “eventualmente”, “finalmente”, etc. Con la estrategia de fragmentado, este tipo de conexión ya no está completa. No solo faltan las piezas de rompecabezas, sino que también se altera el orden de secuencia.

4. Información descriptiva:

Esto se refiere a la información que describe un solo sujeto. Con el fragmentado, no se garantiza que la información descriptiva esté junta. Imagina que estás en medio de una llamada telefónica y de repente se corta la línea. Depende de lo importante que sea tu llamada y cuándo haya ocurrido, el impacto puede ser desde trivial hasta muy frustrante.

Fortalezas y Debilidades de RAG

Si llamamos RAGs a aquellos que solo utilizan el fragmentado y la búsqueda de similitud de vectores llamado “vanilla RAGs”, podemos ver que solo pueden manejar algunos tipos de consultas porque pierden parte de la información de entrada que mencionamos anteriormente:1. Bueno para responder preguntas descriptivas de alcance estrecho. Por ejemplo, ¿qué materia posee ciertas características?

2. No es bueno para el razonamiento de relaciones, es decir, encontrar un camino desde la entidad A hasta la entidad B o identificar conjuntos de entidades.

3. No es bueno para la síntesis a largo plazo. Por ejemplo, “Enumera todas las peleas de Harry Potter” o “¿Cuántas peleas tiene Harry Potter?”.

Las aplicaciones RAG tienen un rendimiento deficiente en este tipo de tareas porque solo se pueden alimentar unos pocos fragmentos en el LLM, y estos fragmentos están dispersos. Sería imposible para el LLM recopilar la información necesaria para comenzar.

Las aplicaciones RAG están en su mayoría equipadas con un LLM generativo, lo que da la impresión a los usuarios de que la aplicación RAG debe tener una capacidad de razonamiento de alto nivel similar a la de un LLM perfecto. Sin embargo, debido a que el LLM tiene una entrada insuficiente en comparación con el modelo perfecto, las aplicaciones RAG no tienen el mismo nivel de capacidad de razonamiento. Ser consciente de la limitación de información de entrada puede ayudarnos a comprender qué puede y qué no puede hacer RAG. Deberíamos buscar el campo más adecuado para RAG y evitar forzarlo en el lugar equivocado.

Hacia una Mejor Aplicación de RAG

Habiendo discutido las limitaciones de la aplicación RAG, veamos cómo podemos mejorar su rendimiento.

Trata a tu LLM

Muy a menudo, al tratar la consulta de entrada, simplemente aceptamos lo que el usuario envía. Esto no es ideal, no solo por los riesgos de seguridad como la filtración y la inyección de datos, sino también porque el rendimiento puede ser decepcionante.

Según los investigadores, los LLM son sensibles a los errores de escritura y a las diferencias de palabras en el inicio [1]. Para asegurarse de que los LLM funcionen con su máximo rendimiento, considere corregir todos los errores de escritura y parafrasear la entrada en una forma que sea más fácil de seguir para los LLM.

Manteniendo el Modelo de Incrustación en la Misma Página

En la mayoría de los casos, el usuario envía consultas cortas, como ‘Cuéntame más sobre Tony Abbott’. Luego, la consulta se convierte en un vector de incrustación, que captura la esencia de esa consulta específica. Hacer una búsqueda semántica con una consulta directa puede ser desafiante debido a lo siguiente:

1. Las consultas de usuario son cortas y están en forma de preguntas. Contienen características semánticas limitadas. Mientras que las incrustaciones de documentos son largas, están en forma de varias formas de declaraciones, las incrustaciones de documentos tienen información mucho más rica en sus vectores.
2. Debido a las características semánticas limitadas en la consulta del usuario, la función de búsqueda semántica tenderá a interpretar en exceso detalles triviales en la consulta. La incrustación del documento puede tener un alto nivel de ruido. El fragmentado empeora las cosas porque muchas relaciones, contextos y enlaces secuenciales están vacíos.
3. Los modelos de incrustación y los LLM generativos pertenecen a familias diferentes. Se entrenan de manera diferente y tienen comportamientos diferentes. Los modelos de incrustación no tienen el mismo nivel de capacidad de razonamiento que los LLM generativos. Incluso no respetan tanto los detalles lingüísticos como los LLM generativos. Consultar directamente con la entrada del usuario, en el peor de los casos, hará que la función de búsqueda semántica se degrade a una búsqueda de palabras clave.
4. Dado que las incrustaciones y los LLM generativos son dos modelos diferentes que cumplen funciones diferentes en todo el proceso, no están en la misma página. Los dos modelos hacen su parte del trabajo de acuerdo a su propia comprensión de lo que se requiere, pero no se comunican entre sí. La información recuperada puede no ser algo que el LLM necesite para producir el mejor resultado. Estos dos modelos no tienen manera de alinearse entre sí.

Para evitar este problema, probablemente quieras utilizar un LLM generativo para ampliar las consultas de los usuarios primero. Considera el siguiente ejemplo:

Consulta original del usuario: Cuéntame sobre Tony Abbott.

Y las consultas ampliadas que se reformularon en base a la consulta original usando Bard:- ¿Cuál es el trasfondo político de Tony Abbott?

– ¿Cuáles son los logros más destacados de Tony Abbott?

– ¿Cuáles son las opiniones políticas de Tony Abbott?

– ¿Cuáles son los intereses personales de Tony Abbott?

– ¿En qué controversias ha estado involucrado Tony Abbott?

¿Puedes ver la mejora en la riqueza de la información? Las consultas aumentadas proporcionan más características, produciendo así un mejor resultado de búsqueda. Además, al enviar las consultas aumentadas, el LLM tiene la oportunidad de decirle al modelo de incrustación lo que necesita, y el modelo de incrustación puede hacer un mejor trabajo al proporcionar trozos de alta calidad al LLM. Así es como los dos modelos pueden trabajar juntos.

La estrategia de segmentación importa

El tamaño de los fragmentos es uno de los pocos superparámetros que podemos ajustar para una aplicación RAG. Para obtener un mejor resultado, se recomienda usar tamaños de fragmentos más pequeños. Un análisis realizado por Microsoft [2] mostró lo siguiente:

Cuando dividimos el texto, también podemos elegir diferentes estrategias de división. La forma más simple es cortar en el límite de una palabra. También podemos probar diferentes estrategias, como cortar en el límite de una oración o párrafo. Y para obtener un resultado aún mejor, podemos superponer los fragmentos adyacentes. La comparación de estrategias de segmentación del análisis de Microsoft [2] es la siguiente:

Los modelos de incrustación tienen un poder limitado de extracción semántica. Son menos efectivos para presentar corpora de múltiples temas y diálogos que los modelos simples. Por eso, la RAG prefiere fragmentos más cortos. ¿Cuál es el tamaño de fragmento ideal? En el análisis de Microsoft, el tamaño de fragmento más pequeño fue de 512 tokens. Seguramente se inspiró en la idea de que los fragmentos más pequeños funcionan mejor; el tamaño de fragmento en algunas aplicaciones comerciales de RAG era de solo ~100 tokens. ¿El tamaño de fragmento más pequeño siempre produce un mejor resultado?

Como se discutió anteriormente, la estrategia de segmentación divide los corpora de texto en pequeñas partes, lo que resulta en pérdida de información. Cuanto más pequeño sea el tamaño de fragmento, más información se perderá. Por lo tanto, existe un tamaño óptimo de fragmento. Los fragmentos demasiado pequeños pueden no ser ideales. Sin embargo, buscar el tamaño de fragmento óptimo es como ajustar superparámetros. Debes experimentar con tus datos.

Reduciendo la pérdida de información

El análisis de Microsoft encontró que la fragmentación con una cantidad significativa de superposición mejora la precisión. ¿Por qué ayuda y podemos encontrar una mejor manera de mejorar el rendimiento de RAG?

La superposición ayudaba a vincular fragmentos adyacentes y proporcionar mejor información contextual para el fragmento. Sin embargo, incluso con una superposición muy agresiva del 25%, solo se mejoró la precisión en un 1.5%, del 42.4% al 43.9%. Esto significa que no es la forma más eficiente de optimizar el rendimiento de RAG. No podemos seguir mejorando el rendimiento de RAG superponiendo más fragmentos. Recuerda que la fragmentación superpuesta ni siquiera es una opción para fragmentos pequeños.

Como ha demostrado la estrategia de fragmentación superpuesta, preservar la información puede ayudar al LLM a generar mejores respuestas. ¿Cómo podemos preservar la información de entrada tanto como sea posible?

La estrategia de fragmentación superpuesta solo esperaba que las últimas varias oraciones del fragmento anterior pudieran proporcionar más información contextual. Y como podemos entender, las últimas varias oraciones pueden no ser muy representativas. Probablemente podamos usar un resumen generado por LLM del fragmento anterior en lugar de la superposición.

Y recuerda que el texto de entrada tiene múltiples capas de información contextual. Si ese es el caso en tu aplicación, tal vez quieras agregar la información contextual en capas al fragmento también. O una forma más eficiente podría ser almacenar la información contextual como metadatos.

RAG con Knowledge Graph está de moda en este momento. Con la ayuda de los grafo de conocimiento, RAG puede almacenar las relaciones en la base de datos gráfica. La conexión entre los fragmentos puede ser completamente reservada. Es una solución muy considerable si el razonamiento de las relaciones es crítico para tu proyecto.

Sin embargo, RAG con Knowledge Graph no es libre de desafíos. Establecer un grafo de conocimiento a partir de texto no estructurado no es trivial. Hay una cantidad considerable de experimentos sobre la extracción de tripletas entidad-relación a partir de la entrada textual. Es una historia diferente cuando necesitas poner en producción la solución. Las entidades y relaciones extraídas automáticamente pueden contener mucho ruido y omitir información real. Debes inspeccionar cuidadosamente la calidad de la salida. Incluso después de la población del grafo de conocimiento, las consultas admitidas están estrechamente acopladas con el diseño de la base de datos gráfica.

No tan sofisticado como RAG con Knowledge Graph, la base de datos relacional habilitada para búsqueda vectorial también es un componente muy importante en el arsenal. Una base de datos como pgvector te permite almacenar información sofisticada como columnas mientras preserva las funciones de búsqueda semántica. Es mucho más fácil de integrar con otros sistemas empresariales y mucho más flexible que un grafo de conocimiento.

Estas son todas opciones válidas para considerar. La única advertencia es que muchas bases de datos gráficas, motores de búsqueda y bases de datos relacionales habilitadas para vectores no están completamente optimizadas como bases de datos vectores. Su velocidad al manejar índices de vectores masivamente escalados puede no ser ideal, especialmente cuando tienen que actualizar el índice con mucha frecuencia. Por favor, consulta [3] para obtener más detalles sobre la introducción a los diferentes tipos de almacenamiento vectorial.

Empatía LLM

A veces, encontramos que RAG no responde muy bien a nuestras preguntas. En lugar de girar todas las perillas para que tenga un mejor rendimiento, debemos considerar las siguientes preguntas:

• ¿El LLM tiene toda la información que necesita?
• ¿La información está organizada de manera amigable para el LLM?

Consideremos el siguiente ejemplo:

Estamos construyendo una aplicación RAG en un sitio web de SharePoint. Una de las páginas web trata sobre todos los proyectos y sus miembros del equipo, incluidos todos los perfiles de las personas. Debemos asegurarnos de que RAG responda con precisión a las preguntas sobre proyectos y miembros del equipo, sin embargo, el resultado inicial fue muy decepcionante.

La investigación inicial mostró que el sitio web de SharePoint no organiza los contenidos de manera estructurada, de modo que la afiliación de la información pueda entenderse fácilmente. Después de eliminar todas las etiquetas HTML, el contenido de la página web se ve así:

proyecto AContacto del cliente: SteveMiembros del equipo:persona Apersona Bcorreo electrónico de persona Acorreo electrónico de persona Brol de persona Arol de persona Bdescripción de persona Adescripción de persona Bproyecto B...

Si los humanos encuentran confuso saber quién es quién, RAG también tiene dificultades. Para organizar mejor la información, usamos código Python para agregar la información juntos según las propiedades HTML, separamos cada proyecto y los nombres de los miembros del equipo en un solo archivo de texto, y colocamos la información de cada persona en su propio archivo:

archivo project_A.txt:nombre del proyecto: project_AContacto del cliente: SteveMiembros del equipo:Adam SmithJobs Muskarchivo person_A.txt:nombre: Adam Smithcorreo electrónico: [email protected]: ingenierodescripción: Pasatiempos/pasión: escalada en roca...

Los archivos de texto generados son pequeños, lo cual parece no estar alineado con la práctica de fragmentación de RAG. La razón es que los archivos muy concentrados evitan el problema de la división y reducen completamente el ruido. Con los archivos recién generados, RAG no tiene problemas para responder preguntas como “¿quién está trabajando en el proyecto x?” y “¿cuál es el pasatiempo de Adam Smith?”.

Sin embargo, RAG tuvo dificultades cuando invertimos la pregunta: “¿En qué proyecto trabaja Adam Smith?”. Vimos que Adam Smith aparecía entre los miembros del proyecto. No estamos muy seguros de por qué el modelo de incorporación no pudo captarlo. Para ayudar al LLM a hacer el trabajo, podemos hacer que la información destaque. Agregamos una línea en el archivo de la persona que indica explícitamente el compromiso con el proyecto:

archivo person_A.txt:nombre: Adam Smithcorreo electrónico: [email protected]: ingenierodescripción: Pasatiempos/pasión: escalada en rocaproyecto: project_A

Y esta línea adicional hace que la aplicación RAG pueda responder con precisión al las preguntas anteriores al 100%.

Palabras de cierre

RAG, como una tecnología emergente, está evolucionando rápidamente. Encontré que me ayudó mucho cuando investigué sus componentes de construcción pieza por pieza. Al examinar los detalles, puedo obtener una comprensión más profunda de los pros y los contras de la tecnología y desarrollar una idea de qué tan importante puede ser una nueva propuesta. Hay algunos marcos de trabajo muy populares que ayudan a las personas a desarrollar aplicaciones RAG. Encontré algunas ideas de implementación inspiradoras; sin embargo, no recomiendo comenzar a aprender o desarrollar tu RAG solo porque es fácil comenzar.

Si has seguido este artículo hasta aquí, seguramente estarás de acuerdo en que RAG es una arquitectura complicada. Los marcos populares envuelven todos los detalles, lo que hace que la gente piense que esos detalles no son importantes. Mi sugerencia es aprender RAG con una implementación básica y considerar características adicionales posteriormente. De esta manera, conocerás los elementos esenciales y el impacto de cada parte móvil. No es tan difícil comenzar con un RAG mínimo y analizar cómo funciona. Por favor, revisa mi publicación, Desventajas de RAG.

Referencias

Robustez de la pregunta: Cómo medir y cómo mejorar

Discusión sobre la robustez de la pregunta LLM, medición, mejora y el uso de PromptBench.

pub.towardsai.net

Azure Cognitive Search: Superando la búsqueda vectorial con capacidades híbridas de recuperación y clasificación

¿Cómo encuentras el mejor contenido para alimentar tus modelos de IA generativos? En esta publicación de blog, te mostramos cómo usar Azure…

techcommunity.microsoft.com

Lo que necesitamos saber antes de adoptar una base de datos vectorial

Para continuar con nuestro camino hacia la IA generativa aplicable, me gustaría discutir algunos de los desafíos…

VoAGI.com

Desventajas de RAG

Recientemente, el surgimiento de modelos de lenguaje grandes (LLMs) ha despertado mucho interés en los sistemas RAG. Muchos profesionales…

VoAGI.com

We will continue to update Zepes; if you have any questions or suggestions, please contact us!