Si ha estado experimentando con modelos de lenguaje grandes (LLM) para tareas de búsqueda y recuperación, probablemente se haya topado con la generación aumentada de recuperación (RAG) como una técnica para agregar información contextual relevante a las respuestas generadas por LLM. Al conectar un LLM a datos privados, RAG puede permitir una mejor respuesta al introducir datos relevantes en la ventana de contexto.
Se ha demostrado que RAG es muy eficaz para responder consultas complejas, tareas intensivas en conocimiento y mejorar la precisión y relevancia de las respuestas para modelos de IA, especialmente en situaciones en las que los datos de entrenamiento independientes pueden ser insuficientes.
Sin embargo, estos beneficios de RAG solo se pueden obtener si monitorea continuamente su sistema LLM en los puntos de falla comunes, especialmente con métricas de evaluación de respuesta y recuperación. En este artículo, analizaremos los mejores flujos de trabajo para solucionar problemas de métricas de respuesta y recuperación deficientes.
Vale la pena recordar que RAG funciona mejor cuando la información requerida está disponible. Si los documentos relevantes están disponibles centra las evaluaciones del sistema RAG en dos aspectos críticos:
- Evaluación de recuperación: Evaluar la exactitud y relevancia de los documentos que se recuperaron.
- Evaluación de respuesta: Medir la idoneidad de la respuesta generada por el sistema cuando se proporcionó el contexto.
Tabla 1: Métricas de evaluación de respuesta
Tabla 2: Métricas de evaluación de recuperación
Repasemos tres escenarios potenciales para solucionar problemas de rendimiento deficiente de LLM según el diagrama de flujo.
Escenario 1: buena respuesta, buena recuperación
En este escenario, todo en la aplicación LLM actúa como se esperaba y tenemos una buena respuesta con una buena recuperación. Descubrimos que nuestra evaluación de respuesta es “correcta” y nuestro “Acierto = Verdadero”. El acierto es una métrica binaria, donde “Verdadero” significa que se recuperó el documento relevante y “Falso” significaría que no se recuperó el documento relevante. Tenga en cuenta que la estadística agregada de aciertos es la tasa de aciertos (porcentaje de consultas que tienen contexto relevante).
Para nuestras evaluaciones de respuesta, la corrección es una métrica de evaluación que se puede realizar simplemente con una combinación de aporte (consulta), producción (respuesta), y contexto como se puede ver en tabla 1. Varios de estos criterios de evaluación no requieren etiquetas de verdad sobre el terreno etiquetadas por el usuario, ya que los LLM también se pueden utilizar para generar etiquetas, puntuaciones y explicaciones con herramientas como Llamada a función OpenAIa continuación se muestra una plantilla de mensaje de ejemplo.
Estos Evaluaciones de LLM se puede formatear como numérico, categórico (binario y multiclase) y de salida múltiple (múltiples puntuaciones o etiquetas); siendo el binario categórico el más utilizado y el numérico el menos utilizado.
Escenario 2: mala respuesta, mala recuperación
En este escenario encontramos que la respuesta es incorrecta y no se recibió el contenido relevante. Según la consulta vemos que el contenido no fue recibido porque no hay solución a la consulta. El LLM no puede predecir compras futuras, independientemente de los documentos que se proporcionen. Sin embargo, el LLM puede generar una mejor respuesta que alucinar una respuesta. Aquí sería experimentar con el mensaje que genera la respuesta simplemente agregando una línea a la plantilla de mensaje de LLM de “si no se proporciona contenido relevante y no se encuentra una solución concluyente, responda que se desconoce la respuesta”. En algunos casos la respuesta correcta es que la respuesta no existe.
Escenario 3: mala respuesta, métricas de recuperación mixtas
En este tercer escenario, vemos una respuesta incorrecta con métricas de recuperación mixtas (se recuperó el documento relevante, pero el LLM alucinó con una respuesta debido a que se le dio demasiada información).
Para evaluar un sistema LLM RAG, es necesario buscar el contexto correcto y luego generar una respuesta adecuada. Normalmente, los desarrolladores incorporarán una consulta de usuario y la utilizarán para buscar fragmentos relevantes en una base de datos vectorial (consulte la Figura 3). El rendimiento de la recuperación depende no sólo de que los fragmentos devueltos sean semánticamente similares a la consulta, sino también de si esos fragmentos proporcionan suficiente información relevante para generar la respuesta correcta a la consulta. Ahora, debe configurar los parámetros de su sistema RAG (tipo de recuperación, tamaño del fragmento y K).
De manera similar, con nuestro último escenario, podemos intentar editar la plantilla de solicitud o cambiar el LLM que se utiliza para generar respuestas. Dado que el contenido relevante se recupera durante el proceso de recuperación del documento pero el LLM no lo muestra, esta podría ser una solución rápida. A continuación se muestra un ejemplo de una respuesta correcta generada al ejecutar una plantilla de solicitud revisada (después de iterar sobre las variables de solicitud, los parámetros de LLM y la plantilla de solicitud en sí).
Al solucionar problemas de malas respuestas con métricas de rendimiento mixtas, primero debemos determinar qué métricas de recuperación tienen un rendimiento inferior. La forma más sencilla de hacerlo es implementar umbrales y monitores. Una vez que reciba una alerta sobre una métrica de bajo rendimiento en particular, puede resolverla con flujos de trabajo específicos. Tomemos como ejemplo nDCG. nDCG se utiliza para medir la efectividad de sus documentos mejor clasificados y tiene en cuenta la posición de los documentos relevantes, por lo que si recupera su documento relevante (Hit = ‘True’), deberá considerar implementar una técnica de reclasificación para obtener los documentos relevantes. documentos más cerca de los resultados de búsqueda mejor clasificados.
Para nuestro escenario actual, recuperamos un documento relevante (Hit = ‘True’), y ese documento está en la primera posición, así que intentemos mejorar la precisión (porcentaje de documentos relevantes) hasta ‘K’ documentos recuperados. Actualmente nuestra Precision@4 es del 25%, pero si utilizamos solo los dos primeros documentos relevantes, entonces Precision@2 = 50% ya que la mitad de los documentos son relevantes. Este cambio conlleva la respuesta correcta del LLM ya que se le da menos información, pero proporcionalmente más información relevante.
Básicamente, lo que estábamos viendo aquí es un problema común en RAG conocido como perdido en el medio, cuando su LLM está abrumado con demasiada información que no siempre es relevante y luego no puede dar la mejor respuesta posible. En nuestro diagrama, vemos que ajustar el tamaño de su fragmento es una de las primeras cosas que hacen muchos equipos para mejorar las aplicaciones RAG, pero no siempre es intuitivo. Con problemas de desbordamiento de contexto y pérdida en el medio, más documentos no siempre es mejor y la reclasificación no necesariamente mejorará el rendimiento. Para evaluar qué tamaño de fragmento funciona mejor, debe definir un punto de referencia de evaluación y realizar un barrido sobre los tamaños de fragmento y los valores top-k. Además de experimentar con estrategias de fragmentación, probar diferentes técnicas de extracción de texto y métodos de incrustación también mejorará el rendimiento general de RAG.
Las métricas y enfoques de evaluación de respuesta y recuperación en esta pieza Ofrece una forma integral de ver el rendimiento de un sistema LLM RAG, guiando a los desarrolladores y usuarios a comprender sus fortalezas y limitaciones. Al evaluar continuamente estos sistemas con respecto a estas métricas, se pueden realizar mejoras para mejorar la capacidad de RAG de proporcionar información precisa, relevante y oportuna.
Los métodos avanzados adicionales para mejorar RAG incluyen reclasificaciónarchivos adjuntos de metadatos, probar diferentes modelos de incrustación, probar diferentes métodos de indexación, implementar Hyde, implementar métodos de búsqueda de palabras clave o implementar el modo de documento Cohere (similar a HyDE). Tenga en cuenta que, si bien estos métodos más avanzados (como la fragmentación, la extracción de texto y la experimentación con modelos de incrustación) pueden producir fragmentos más coherentes contextualmente, estos métodos requieren más recursos. El uso de RAG junto con métodos avanzados puede mejorar el rendimiento de su sistema LLM y continuará haciéndolo siempre que sus métricas de recuperación y respuesta se supervisen y mantengan adecuadamente.
¿Preguntas? Por favor comuníquese conmigo aquí o en LinkedIn, Xo Flojo!