2023 Revisión de artículos antiguos: guía del proceso de construcción y evaluación del sistema GAR

La Generación Aumentada de Recuperación (RAG) se está convirtiendo en una de las aplicaciones más populares de los Grandes Modelos Lingüísticos (LLM) y las bases de datos vectoriales. WeaviateLas aplicaciones RAG se utilizan habitualmente en chatbots y sistemas de preguntas y respuestas.

Como en cualquier sistema de ingeniería, la evaluación del rendimiento es importante para RAG El gasoducto RAG se divide en tres componentes:

1. indexación
2. recuperar (datos)
3. generando

La evaluación del GAR es un reto debido a la complejidad de las interacciones entre estos componentes y a la dificultad de recopilar datos de prueba. Esta ponencia mostrará un interesante avance en el uso del LLM para la evaluación y el estado actual de los componentes del GAR.

en pocas palabras: Nos inspira una asociación con Ragas El diálogo entre Jithin James y Shauhul Es, los creadores de Estos diálogos, escritos por Ragas y los nuevos avances en la evaluación LLM de los sistemas GAR promovidos por ARES nos impulsaron a reflexionar sobre las métricas existentes y a hacer balance de los parámetros GAR ajustables. En el curso de nuestra investigación, seguimos reflexionando sobre las posibles formas de software de seguimiento experimental de GAR y aclaramos aún más en qué se diferencian los sistemas GAR de los sistemas Agente y cómo se evalúan.

Las entradas de nuestro blog contienen las cinco secciones principales siguientes:

• Evaluación LLMTendencias emergentes en la puntuación del rendimiento RAG utilizando LLM, incluyendo cero muestras, pocas muestras y afinando el tamaño del evaluador LLM.
• Indicadores RAG: Métricas comunes utilizadas para evaluar la generación, búsqueda e indexación y cómo interactúan.
• Parámetros reglamentarios de la GAR: ¿Cuáles son las decisiones que afectan de forma significativamente diferente al rendimiento de los sistemas GAR?
• programación¿Cómo gestiono el seguimiento de la configuración del experimento para el sistema RAG?
• De la evaluación RAG a la evaluación de agentesDefinimos una GAR como un proceso de tres pasos: indexación, recuperación y generación. Esta sección describe cuándo un sistema GAR se transforma en un sistema Agente y cómo evaluar sus diferencias.

Evaluación LLM

Empecemos por la parte más nueva y emocionante: ¡la evaluación del aprendizaje automático! La historia del aprendizaje automático se ha basado en gran medida en el trabajo de anotar datos manualmente, como determinar si una reseña de Yelp es positiva o negativa, o si un artículo es relevante para la consulta "¿Quién es el entrenador jefe de los Boston Celtics?". LLM se está volviendo gradualmente más eficiente en la anotación de datos con menos esfuerzo manual. Se trata de una **"nueva tendencia "** clave que está acelerando el crecimiento de las aplicaciones GAR.

dejar (a algn.) Ragas La técnica más común de la que son pioneros marcos como la evaluación LLM de muestra cero es la evaluación LLM de muestra cero. La evaluación LLM de muestra cero implica preguntar al modelo de lenguaje grande con plantillas del tipo: "Por favor, valore la relevancia de estos resultados de búsqueda en una escala de 1 a 10. La consulta es {query} y los resultados de búsqueda son {search_results}. La consulta es {query} y los resultados de la búsqueda son {search_results}". La siguiente figura muestra cómo puede utilizarse LLM para evaluar el rendimiento de un sistema GAR.

Hay tres grandes oportunidades de ajuste en la evaluación del LLM de muestra cero: 1. las métricas de diseño, como precisión, recall o nDCG, 2. el lenguaje específico de estas claves, y 3. el modelo de lenguaje utilizado para la evaluación, por ejemplo, GPT-4, Coral, Llama-2, Mistral, etcétera. Una preocupación importante en este momento es el coste de utilizar el LLM para la evaluación. Por ejemplo, evaluar 10 resultados de búsqueda utilizando GPT-4 (suponiendo 500 tokens por resultado, más 100 tokens para la consulta y el comando, lo que da un total de unos 6.000 tokens) costaría unos 1.000 dólares por Ficha 0,005, o 3 $ para evaluar 100 consultas.

A medida que marcos como Ragas promueven la evaluación LLM de muestra cero, la gente empieza a cuestionarse la necesidad de una evaluación LLM de muestra menor. Dado que la evaluación LLM de muestra cero es "suficientemente buena", puede ser suficiente para servir de Estrella Polar para el ajuste del sistema RAG. Como se muestra en la siguiente figura, la puntuación RAGAS consta de cuatro indicaciones LLM de muestra cero para cada una de las dos métricas generadas:Fidelidad responder cantando Relevancia de la respuesta (Answer Relevancy)así como dos indicadores de recuperación:Precisión contextual (Context Precision) responder cantando Context Recall (Recuperación del contexto).

 fuente (de información, etc.)

El paso de la evaluación LLM de muestra cero a la de muestra menor es sencillo. Incluimos algunos ejemplos anotados de la relevancia de los resultados de búsqueda para la consulta en las plantillas de instrucciones, lo que también se conoce como aprendizaje contextual. El descubrimiento de esta técnica fue uno de los principales avances de GPT-3.

Por ejemplo, añadir 5 puntuaciones de relevancia manuales al ejemplo añadiría 30.000 tokens a la consulta. Asumiendo los mismos costes que arriba, evaluamos un incremento de 3 a 15 dólares por 100 consultas. Tenga en cuenta que se trata de un ejemplo de estimación simple y no se basa en un modelo de precios real para LLM. Una consideración clave es que añadir menos ejemplos de muestra puede requerir modelos contextuales más largos que suelen tener un precio superior al LLM para entradas más pequeñas.

Este tipo de evaluación LLM basada en cero o pocas inferencias de muestra ya es muy atractiva, pero investigaciones posteriores han demostrado que el coste de la evaluación LLM puede reducirse aún más mediante algoritmos de entrenamiento a través de la destilación del conocimiento. Esto se refiere al uso del LLM para generar datos de entrenamiento para una tarea de evaluación y afinarlos en un modelo más pequeño.

existe ARESARES: En un marco automatizado para evaluar sistemas generativos de recuperación mejorada, Saad-Falcon et al. descubrieron que el entrenamiento de un evaluador propio de LLM puede superar las pistas de muestra cero. Inicialmente, ARES requiere tres datos de entrada: una colección de párrafos del corpus objetivo, 150 o más puntos de datos de validación de preferencias humanas y 5 ejemplos de consultas del dominio que no han sido objeto de muestreo. ARES utiliza estos ejemplos para generar una gran cantidad de datos de consulta sintéticos, filtrados por el principio de consistencia de bucle: es decir, cuando se busca con una consulta sintética, ¿puede recuperar el documento que generó la consulta sintética? . A continuación, ARES genera los datos para la relevancia contextualyAutenticidad de las respuestas responder cantando Pertinencia de las respuestas Ajuste de clasificadores ligeros.

Ajuste experimental del autor DeBERTa-v3-grandeEl modelo contiene 437 millones de parámetros más económicos, y cada cabeza clasificadora comparte el modelo lingüístico base, lo que suma un total de tres cabezas clasificadoras. Al dividir los datos sintéticos en conjuntos de entrenamiento y de prueba, la evaluación del sistema ARES reveló que el modelo ajustado superaba significativamente al GPT-3.5-turbo-16k de cero y pocas muestras. Para más detalles (por ejemplo, el uso innovador de intervalos de confianza en la inferencia basada en predicciones (PPI) y los pormenores de los experimentos), véase Saad-Falcon et al.Tesis.

Para comprender mejor el impacto potencial del LLM en la evaluación, seguiremos describiendo la metodología de evaluación comparativa sistemática RAG existente y sus variaciones particulares en la evaluación del LLM.

Indicadores RAG

Presentamos las métricas RAG desde la perspectiva superior de la generación, recuperación e indexación. A continuación, presentamos los parámetros de ajuste de la RAG desde la perspectiva inferior de la creación de índices, el ajuste de los métodos de recuperación y las opciones de generación.

Otra razón para presentar las métricas RAG desde una perspectiva de nivel superior es que los errores en la indexación se transmiten a la búsqueda y la generación, pero los errores en la generación (como los niveles que definimos) no afectan a los errores en la indexación. En el estado actual de la evaluación de la GAR, rara vez se realiza una evaluación de extremo a extremo de la pila de la GAR, y a menudo se asume que la contexto de oráculo tal vez término de interferencia controlada (CIT)(por ejemplo, el experimento Lost in the Middle) para determinar la veracidad generada y la relevancia de la respuesta. Del mismo modo, las incrustaciones suelen evaluarse con un índice violento que no tiene en cuenta el error del vecino más próximo aproximado. El error del vecino más próximo aproximado suele medirse encontrando el punto óptimo de precisión para compensar la consulta por segundo y la recuperación, siendo la recuperación del RNA los verdaderos vecinos más próximos de la consulta, en lugar de los documentos marcados como "relevantes" para la consulta.

Generación de indicadores

El objetivo general de la aplicación GAR es generar una salida útil, apoyada en el uso del contexto recuperado. La evaluación debe tener en cuenta que la salida utiliza el contexto y no se extrae directamente de la fuente, lo que evita la información redundante y previene las respuestas incompletas. Para puntuar el resultado, es necesario desarrollar métricas que cubran cada criterio.

Ragas Se introducen dos puntuaciones para medir el rendimiento de la salida de Large Language Modelling (LLM): verosimilitud y relevancia de la respuesta.grado de credibilidad Evaluar la exactitud factual de las respuestas basándose en el contexto recuperado.Pertinencia de las respuestas Determine la relevancia de la respuesta dada la pregunta. Las respuestas pueden tener una puntuación alta en credibilidad pero baja en relevancia. Por ejemplo, una respuesta plausible puede reproducir directamente el contexto, pero esto da como resultado una baja relevancia de la respuesta. Las puntuaciones de relevancia de la respuesta se penalizan cuando las respuestas no son completas o contienen información duplicada.

En 2020, Google lanzó MeenaEl objetivo de Meena es demostrar que puede llevar a cabo Razonable y específico del diálogo. Para medir el rendimiento de los chatbots de dominio abierto, introdujeron la métrica de evaluación Sensibleness and Specificity Average (SSA). La razonabilidad de la respuesta del bot debe tener sentido en el contexto y ser específica (Specificity Average). Esto garantiza que la respuesta sea completa y sin ambigüedades.2020 Para ello es necesario que un humano hable con el chatbot y lo puntúe manualmente.

Aunque es bueno evitar respuestas vagas, es igualmente importante evitar que aparezcan grandes modelos lingüísticos producto de la imaginación . La ilusión se refiere al hecho de que las respuestas generadas por el Big Language Model no se basan en hechos reales o en el contexto proporcionado.LlamaIndex utilizar FaithfulnessEvaluator para medirlo. Las puntuaciones se basan en si la respuesta es coherente con el contexto recuperado.

La evaluación de la calidad de las respuestas generadas depende de una serie de indicadores. Las respuestas pueden ser objetivas pero no pertinentes para la consulta. Además, la respuesta puede ser vaga y carecer de información contextual crítica que la respalde. A continuación, volveremos a la capa anterior del proceso y hablaremos de las métricas de recuperación.

Recuperación de indicadores

La siguiente capa de la pila de evaluación es la recuperación de información. La evaluación del historial de recuperación requiere que los humanos anoten qué documentos son relevantes para la consulta. Así, para crear una anotación de consulta, puede que tengamos que anotar la relevancia de 100 documentos. Esto ya es una tarea extremadamente difícil para las consultas de búsqueda generales, y el reto se agrava aún más cuando se construyen motores de búsqueda de dominios específicos (por ejemplo, contratos legales, historiales de pacientes médicos, etc.).

Para aliviar los costes de anotación, a menudo se recurre a la heurística para determinar la relevancia de la búsqueda. La más común de ellas es el registro de clics, es decir, dada una consulta, los títulos en los que se ha hecho clic pueden ser relevantes, mientras que los títulos en los que no se ha hecho clic no lo son. Esto también se conoce como supervisión débil en el aprendizaje automático.

Una vez que el conjunto de datos está listo, las tres métricas utilizadas habitualmente en la evaluación son: nDCG yRecall responder cantando Precisión NDCG (Normalised Discount Cumulative Gain) mide las clasificaciones por múltiples etiquetas de relevancia. Por ejemplo, un documento sobre la vitamina B12 puede no ser el resultado más relevante para una consulta sobre la vitamina D, pero es más relevante que un documento sobre los Boston Celtics. Debido a la complejidad adicional de la clasificación relativa, a menudo se utilizan etiquetas de relevancia binarias (1 para relevante y 0 para irrelevante). Recall mide cuántas muestras positivas se recogen en los resultados de búsqueda, y Precision mide la proporción de resultados de búsqueda que se etiquetan como relevantes.

Así, el Big Language Model puede calcular la precisión con la siguiente pregunta: "¿Cuántos de los siguientes resultados de búsqueda están relacionados con la consulta {query}? {resultados_búsqueda}". También se puede obtener un valor aproximado de Recall a partir de la pregunta del Big Language Model: "¿Contienen estos resultados de búsqueda toda la información necesaria para responder a la consulta {query}? {resultados_de_búsqueda}". También animamos al lector a consultar algunas de las sugerencias de Ragas aquí (literario).

Otra métrica que merece la pena explorar es LLM Wins, donde la pregunta de Big Language Modelling es: "Basándose en la consulta {query}, ¿qué conjunto de resultados de búsqueda es más relevante? Conjunto A {Conjunto_A} o Conjunto B {Conjunto_B}. ¡Muy importante! Por favor, limite el resultado a 'Conjunto A' o 'Conjunto B'".

Profundicemos un poco más y veamos cómo comparar índices vectoriales.

Indicadores indexados

Los usuarios experimentados familiarizados con Weaviate sabrán que Puntos de referencia de la RNALa prueba comparativa inspiró Desarrollo de la API gRPC en Weaviate versión 1.19La evaluación comparativa de RNA mide las consultas por segundo (QPS) frente a la recuperación e incluye la consideración de detalles como las limitaciones de un único subproceso. Mientras que las bases de datos suelen evaluarse en función de la latencia y los costes de almacenamiento, los índices vectoriales aleatorios se centran más en las medidas de precisión. Esto contrasta con Cálculos aproximados en sentencias select de SQL Algo similar, pero prevemos que los errores causados por aproximaciones recibirán más atención a medida que se popularice la indexación vectorial.

La precisión se mide por la recuperación. En la indexación vectorial, la recuperación es el cociente entre el número de vecinos más próximos a la realidad devuelto por el algoritmo de indexación aproximada y el número de vecinos más próximos determinado por la búsqueda de fuerza bruta. Esto es similar a la recuperación de información (Information Recuperación) difiere del uso típico de "recall", que se refiere a la proporción de documentos relevantes recuperados de entre todos los documentos relevantes. Ambos suelen medirse con un parámetro @K asociado.

En el contexto de la pila completa de GAR, se plantea una cuestión interesante:¿Cuándo los errores de precisión de las RNA conducen a errores en la recuperación de información (RI)? Por ejemplo, podemos conseguir 1.000 QPS con un recall de 80% o 500 QPS con un recall de 95%, ¿cuál es el impacto en las métricas de búsqueda mencionadas anteriormente (por ejemplo, la búsqueda de nDCG o las puntuaciones de recall de Large Language Modelling (LLM))?

Resumen de los indicadores RAG

En resumen, mostramos métricas para evaluar la indexación, la recuperación y la generación:

• generando: fidelidad y relevancia de la respuesta, y la evolución desde métricas como la detección a gran escala de alucinaciones (por ejemplo, Racionalidad y Especificidad Media, Sensibilidad y Especificidad Media, SSA).
• recuperar (datos)Nuevas oportunidades para la precisión contextual frente a la recuperación contextual en la puntuación LLM, y una visión general de la anotación humana para medir la recuperación, la precisión y la nDCG.
• indexaciónRecuperación: la recuperación se mide por el número de vecinos más próximos a la verdad que devuelve el algoritmo de búsqueda vectorial. Creemos que la cuestión clave aquí es:¿Cuándo se convierten los errores de RNA en errores de RI?

Por lo general, todos los componentes pueden compensarse entre rendimiento y latencia o coste. Si utilizamos un modelo lingüístico más caro, podemos obtener una generación de mayor calidad; si filtramos los resultados con un reordenador, podemos obtener una recuperación de mayor calidad; si utilizamos más memoria, podemos obtener una indexación de mayor recuperación. El modo de gestionar estas compensaciones para mejorar el rendimiento se irá aclarando a medida que sigamos investigando los "botones de la GAR". Como nota final, hemos optado por presentar las métricas desde una perspectiva descendente, desde la generación hasta la búsqueda y la indexación, porque el tiempo de evaluación se acerca más a la experiencia del usuario. También presentaremos los mandos de ajuste desde una perspectiva ascendente desde la indexación hasta la búsqueda y la generación, ya que esto se asemeja más a la experiencia de un desarrollador de aplicaciones RAG.

Parámetros de ajuste RAG

Ahora que ya hemos hablado de las métricas para comparar los sistemas GAR, vamos a profundizar en las decisiones clave que pueden influir significativamente en el rendimiento.

Parámetros de ajuste del índice

El parámetro de ajuste de indexación más importante a la hora de diseñar un sistema RAG es el ajuste de compresión vectorial, introducido en Weaviate 1.18 en marzo de 2023 como Cuantización de Producto (PQ), un algoritmo de compresión vectorial que agrupa fragmentos consecutivos de vectores, agrupa los valores en el conjunto y reduce la precisión por el centro de masa. Por ejemplo, un fragmento contiguo de cuatro números en coma flotante de 32 bits tarda 16 bytes en representarse, mientras que un fragmento de longitud 4 con ocho centros de masa tarda sólo 1 byte, logrando una relación de compresión de memoria de 16:1. Los avances recientes en la reordenación PQ han reducido significativamente la pérdida de memoria debida a la compresión, pero aún debe considerarse con precaución en niveles muy altos de compresión.

Lo siguiente es el índice de enrutamiento utilizado. Para conjuntos de datos con menos de 10.000 vectores, las aplicaciones RAG pueden satisfacerse con la indexación por fuerza bruta. Sin embargo, a medida que aumenta el número de vectores, la latencia de la indexación por fuerza bruta es mucho mayor que la de la indexación basada en algoritmos de grafos de proximidad como HNSW. Como se describe en las métricas RAG, el rendimiento de HNSW suele medirse por el punto óptimo de Pareto, que pondera la consulta por segundo frente a la recuperación. Esto se consigue ajustando el tamaño de la cola de búsqueda utilizada para la inferencia. ef para hacerlo realidad. Más grande ef realizará más comparaciones de distancias durante el proceso de búsqueda, lo que lo ralentiza considerablemente, pero produce resultados más precisos. Los siguientes parámetros incluyen los utilizados en la construcción del índice, tales como efConstruction (el tamaño de la cola al insertar datos en el gráfico) y maxConnections (número de aristas por nodo, que se almacenará con cada vector).

Otra nueva dirección que estamos explorando es el efecto del sesgo distributivo en el centro de masa de los PQ, y la relación con algoritmos híbridos de agrupación e indexación de grafos como DiskANN tal vez IVFOADC+G+P). El uso de la métrica de recuperación puede ser suficiente para determinar si es necesario volver a ajustar el centro de masa, pero la cuestión sigue siendo qué subconjunto de vectores utilizar para el reajuste. Si utilizamos los 100.000 vectores más recientes que provocan una caída del recall, puede que estemos sobreajustando a una nueva distribución, por lo que puede que necesitemos muestrear una mezcla de líneas temporales de distribución de datos. Este tema está estrechamente relacionado con nuestro punto sobre la optimización continua de los modelos de aprendizaje profundo, y puede tratarse con más detalle en la sección "Optimización normativa".

La fragmentación de datos es un paso importante antes de insertar datos en Weaviate. La fragmentación convierte los documentos largos en partes más pequeñas. Esto mejora la recuperación porque cada trozo contiene información importante y ayuda a mantenerse dentro de los límites de tokens del Modelo de Lenguaje Grande (LLM). Existen múltiples estrategias para analizar documentos. La figura anterior muestra un ejemplo de fragmentación de un artículo de investigación basado en su título. Por ejemplo, el trozo 1 es el resumen, el trozo 2 es la introducción, y así sucesivamente. También hay formas de combinar trozos y crear solapamientos. Esto incluye una ventana deslizante que toma un Token del bloque anterior y lo utiliza como inicio del siguiente bloque. Un ligero solapamiento de bloques mejora la búsqueda, ya que el recuperador es capaz de entender el contexto/bloque anterior. La siguiente imagen muestra un esquema de alto nivel del texto fragmentado.

recuperar (datos)

Hay cuatro parámetros principales ajustables en la búsqueda: el modelo de incrustación, los pesos de búsqueda híbrida, si se utiliza AutoCut y el modelo de reordenación.

Es probable que la mayoría de los desarrolladores de GAR reconcilien inmediatamente el modelo de incrustación utilizado, por ejemplo, OpenAI, Cohere, Voyager, Jina AI, Sentence Transformers, ¡y muchas otras opciones! Los desarrolladores también tendrán que considerar la dimensionalidad del modelo y su efecto en la compresión PQ.

La siguiente decisión clave es cómo ajustar los pesos de agregación para los métodos de recuperación dispersa y densa en la búsqueda híbrida. Las ponderaciones se basan en el parámetro alpha.alpha 0 es puro bm25 Busca.alpha a 1 es una búsqueda vectorial pura. Por lo tanto, establecer alpha Depende de los datos y la aplicación.

Otro avance emergente es la eficacia de los modelos de reordenación de muestra cero.Weaviate ofrece actualmente 2 Modelo de reordenación de Cohere::rerank-english-v2.0 responder cantando rerank-multilingual-v2.0. Como su nombre indica, estos modelos difieren principalmente por los datos de entrenamiento utilizados y las capacidades multilingües resultantes. En el futuro, esperamos ofrecer más opciones en cuanto a las capacidades de los modelos, lo que implica un compromiso inherente entre rendimiento y latencia que puede tener sentido para algunas aplicaciones, pero no para otras. En el proceso de ajuste de los parámetros de la recuperación, fue un reto descubrir qué tipo de reordenador capaz se necesitaba y cuántos resultados de la recuperación había que reordenar. Este es también uno de los puntos de entrada más sencillos para afinar los modelos personalizados en la pila RAG, de lo que hablamos más adelante en "Optimización normativa".

Otro parámetro de ajuste interesante es la búsqueda multiíndice. Al igual que en el caso del chunking, esto implica cambios estructurales en la base de datos. La cuestión general es:¿Cuándo debo utilizar una recogida selectiva en lugar de un filtro? debe transferir blogs responder cantando documentation en dos conjuntos, o almacenarlos conjuntamente en una colección con un source atributo Document ¿En la categoría?

El uso de filtros nos ofrece una forma rápida de probar la utilidad de estas etiquetas, ya que podemos añadir varias etiquetas a cada bloque y luego ablarlas para analizar cómo las utiliza el clasificador. Hay una serie de ideas interesantes, como etiquetar explícitamente la fuente del contexto en la entrada de contexto al LLM, por ejemplo: "Los siguientes son resultados de búsqueda de blogs {search_results}. Aquí están los resultados de la búsqueda en documentos {documentación}". A medida que el LLM sea capaz de manejar entradas más largas, esperamos que la fusión de contextos entre múltiples fuentes de datos sea cada vez más común, por lo que surge otro hiperparámetro relevante: cuántos documentos se recuperan de cada índice o filtro.

generando

Lo primero en lo que hay que centrarse con respecto a la generación es qué Modelo de Lenguaje Grande (LLM) elegir. Por ejemplo, puede elegir modelos de OpenAI, Cohere, Facebook y muchas opciones de código abierto. Muchos marcos LLM (p. ej. Cadena LangChainyLlamaIndex responder cantando Módulo de generación de Weaviate) ofrece una fácil integración con diversos modelos, lo cual es una gran ventaja. La elección del modelo puede depender de factores como si quieres que tus datos sigan siendo privados, el coste, los recursos, etc.

Un parámetro de regulación común y específico del LLM es la temperatura. El ajuste de temperatura controla la aleatoriedad de la salida. Una temperatura de 0 significa que la respuesta es más predecible y menos variable; una temperatura de 1 permite al modelo introducir aleatoriedad y creatividad en la respuesta. Por lo tanto, si ejecuta el modelo generativo varias veces con la temperatura ajustada a 1, la respuesta puede ser diferente cada vez que lo vuelva a ejecutar.

Los Modelos de Contexto Largo (LCM) son una dirección emergente a la hora de elegir un LLM para su aplicación. ¿Mejora la calidad de las respuestas si se añaden más resultados de búsqueda? La investigación sobre el experimento Lost in the Middle (Perdido en el medio) plantea algunas dudas. En "Perdidos en el medio" En él, investigadores de Stanford, UC Berkeley y Samaya AI realizaron experimentos controlados que demostraban que si la información relevante se coloca en medio de un resultado de búsqueda, en lugar de al principio o al final, el modelo lingüístico puede no ser capaz de incorporarla al generar una respuesta. Otro trabajo realizado por investigadores de Google DeepMind, Toyota y la Universidad de Purdue señaló:"Los grandes modelos lingüísticos se distraen fácilmente con contextos irrelevantes".. A pesar del potencial de esta dirección, en el momento de escribir estas líneas, la RAG de contexto largo se encuentra aún en sus primeras fases. Afortunadamente, métricas como las puntuaciones Ragas pueden ayudarnos a probar rápidamente nuevos sistemas.

De forma similar a los recientes avances en la evaluación de LLM de los que hemos hablado antes, el aspecto generativo de la sintonización se divide en tres etapas: 1. Sintonización de instrucciones, 2. Ejemplos de pocos intentos y 3. Sintonización fina. La sintonización de instrucciones implica ajustar expresiones lingüísticas específicas como "Por favor, responda a la pregunta basándose en los resultados de búsqueda proporcionados". frente a "Por favor, responda a la pregunta. Importante: siga atentamente las siguientes instrucciones. Su respuesta a la pregunta debe basarse únicamente en los resultados de la búsqueda". La diferencia entre.

Como ya se ha mencionado, una muestra menos ejemplo se refiere a la recopilación de una serie de pares de pregunta, contexto y respuesta escritos manualmente para guiar la generación de un modelo lingüístico. Estudios recientes (por ejemplo "Vector de contexto") demuestra aún más la importancia de este tipo de bootstrapping del espacio potencial. En el proyecto Gorila Weaviate, utilizamos GPT-3.5-turbo para generar consultas Weaviate, y cuando añadimos lenguaje natural a la traducción de consultas de los ejemplos de muestra menores, el rendimiento mejoró significativamente.

Por último, cada vez se presta más atención al ajuste del LLM para aplicaciones GAR. He aquí algunos enfoques a tener en cuenta. Volviendo a nuestra discusión sobre la evaluación del LLM, es posible que queramos generar datos de entrenamiento utilizando un LLM más robusto para construir un modelo más pequeño y asequible de nuestra propiedad. Otra idea es proporcionar una anotación humana de la calidad de la respuesta para que el LLM pueda ser ajustado con el siguiente comando. si estás interesado en el ajuste fino del modelo, echa un vistazo a la contribución de Brev sobre cómo utilizar la biblioteca HuggingFace PEFT en tutoriales.

Resumen de las opciones de ajuste del GAR

En resumen, hemos descrito las principales opciones de ajuste disponibles en el sistema GAR:

• Indexación: al más alto nivel, tenemos que considerar cuándo utilizar sólo la búsqueda por fuerza bruta y cuándo introducir la indexación RNA. Esto es especialmente interesante cuando se afinan casos de uso multiusuario con usuarios nuevos frente a usuarios forzados. En la indexación ANN, tenemos hiperparámetros para PQ (fragmentación, centro de masa y límites de entrenamiento). hNSW incluye (ef, efConstruction y maxConnections).
• Recuperación: selección de un modelo de incrustación, ajuste de los pesos de búsqueda híbrida, selección de un reordenador y partición de una colección en varios índices.
• Generar: seleccionar un LLM y decidir cuándo pasar de la sintonización de pistas a ejemplos con menos muestras o a la sintonización fina.

Una vez comprendidas las métricas RAG y cómo mejorar su rendimiento mediante el ajuste, analicemos las posibles implementaciones del seguimiento experimental.

programación

Dados los recientes avances en el campo de la evaluación de Grandes Modelos Lingüísticos (LLM) y una visión general de algunos de los parámetros sintonizables, existe una interesante oportunidad para combinar todo esto con un marco de seguimiento de experimentos. Por ejemplo, se podría utilizar un orquestador sencillo con una API intuitiva para que el usuario realice lo siguiente: 1. solicitar una prueba completa de 5 LLM, 2 modelos incrustados y 5 configuraciones de indexación; 2. ejecutar los experimentos; y 3. devolver un informe de alta calidad al usuario.Weights & Biases ha labrado un camino de seguimiento experimental notable para el entrenamiento de modelos de aprendizaje profundo. Esperamos que crezca rápidamente el interés por el soporte experimental RAG con los parámetros y métricas sintonizables que se describen en este artículo.

Seguimos dos direcciones de desarrollo en este ámbito. Por un lado, los LLM de muestra cero existentes (por ejemplo, GPT-4, Command, Claude, así como las opciones de código abierto Llama-2 y Mistral) no son tan eficaces a la hora de tener un contexto de oráculo funcionó bastante bien en su momento. Así que hay una gran oportunidad de Concéntrese en la parte de búsqueda . Esto requiere encontrar formas de compensar los errores de la RNA, los modelos integrados, la ponderación de búsqueda híbrida y la reordenación de PQ o HNSW en múltiples configuraciones, como se ha descrito anteriormente en este documento.

Weaviate 1.22 introduce índices asíncronos y las correspondientes API de estado de nodo, que esperamos que, a través de asociaciones centradas en la evaluación RAG y la orquestación de ajuste, puedan aprovechar para determinar cuándo han terminado de construirse los índices y, a continuación, ejecutar las pruebas. Esto es especialmente interesante a la hora de considerar el ajuste de las interfaces de orquestación con cada inquilino en función de estos estados de nodo, donde algunos inquilinos pueden confiar en la búsqueda de fuerza bruta, mientras que otros necesitan encontrar el modelo de incrustación y la configuración HNSW adecuados para sus datos.

Además, es posible que queramos acelerar las pruebas paralelizando la asignación de recursos. Por ejemplo, evaluando 4 modelos de incrustación al mismo tiempo. Como ya se ha mencionado, otra parte interesante es el ajuste de chunks u otros metadatos simbólicos que pueden proceder del importador de datos. Como ejemplo, el conjunto de datos Weaviate Verba contiene 3 carpetas de Weaviate BlogsyDocumentation responder cantando Video Transcripción. Si deseamos comparar tamaños de trozos de 100 y 300, no es necesario volver a llamar al rastreador web. Es posible que necesitemos otro formato, ya sean datos almacenados en cubos de almacenamiento S3 o de otro tipo, con metadatos asociados, pero proporciona una forma más económica de experimentar.

Por otro lado, tenemos el ajuste fino de modelos y el aprendizaje continuo basado en gradientes, en lugar de la inserción o actualización de datos. Los modelos más utilizados en RAG son los modelos incrustados, los modelos reordenados y, por supuesto, los LLM. Mantener los modelos de aprendizaje automático actualizados con nuevos datos ha sido durante mucho tiempo el objetivo de los marcos de aprendizaje continuo y las orquestaciones MLops que gestionan el reentrenamiento, las pruebas y el despliegue de nuevos modelos. Empezando por el aprendizaje continuo LLM, uno de los mayores puntos de venta del sistema RAG es la capacidad de ampliar la fecha de "corte" de la base de conocimientos LLM para mantenerla sincronizada con sus datos. ¿puede LLM hacer esto directamente? No creemos que esté claro lo bien que interactúa la formación continua con el mero hecho de mantener la información actualizada a través del GAR. Algunos estudios (por ejemplo, MEMIT) han experimentado con análisis de mediación causal de la atribución de peso, actualizando hechos como "LeBron James juega al baloncesto" a "LeBron James juega al fútbol". ", etcétera. Se trata de una técnica bastante avanzada, y otra oportunidad podría ser simplemente etiquetar los trozos utilizados en el entrenamiento (por ejemplo, "LeBron James juega al baloncesto") y volver a entrenarlos utilizando datos de entrenamiento mejorados con recuperación que contengan la nueva información. Se trata de un campo importante que seguimos de cerca.

Como se ha mencionado anteriormente, también estamos considerando cómo integrar este tipo de ajuste continuo directamente en Weaviate utilizando centros primos PQ. El centroide PQ de los primeros K vectores que entran en Weaviate por primera vez puede verse afectado por cambios significativos en la distribución de los datos. El entrenamiento continuo de los modelos de aprendizaje automático sufre el infame problema del "olvido catastrófico", en el que el entrenamiento en el último lote de datos perjudica el rendimiento en lotes anteriores. Esta es una de las consideraciones que tuvimos en cuenta al diseñar el reajuste del centro de masa de PQ.

De la evaluación RAG a la evaluación de agentes

A lo largo de este artículo, nos centraremos en la RAG En lugar de Agente Valoración. En nuestra opinión.RAG definida como el proceso de indexación, recuperación y generación, y la Agentes El alcance del sistema es más abierto. El diagrama siguiente ilustra cómo vemos los componentes principales, como la planificación, la memoria y las herramientas, que en conjunto proporcionan importantes capacidades a su sistema, pero también dificultan su evaluación.

Un paso común para las aplicaciones RAG es añadir un motor de consulta avanzado. Para los lectores que son nuevos en este concepto, echa un vistazo a nuestra serie LlamaIndex y Weaviate que proporciona ejemplos de código Python sobre cómo empezar. Existen muchos motores de consulta avanzados, como los motores de consulta de subpreguntas, los enrutadores SQL, los motores de consulta autocorrectivos y otros. También estamos considerando posibles formas de la API promptToQuery o del extractor de consultas de búsqueda en el módulo Weaviate. Cada motor de consulta tiene sus propias ventajas en el proceso de recuperación de información, así que vamos a profundizar en algunos de ellos y en cómo podemos evaluarlos.

El motor de consulta multisalto (también conocido comoMotor de consulta de subtemas) es perfecto para descomponer problemas complejos en subproblemas. En el diagrama anterior, tenemos la consulta "¿Qué es Ref2Vec en Weaviate?" Para responder a esta pregunta, necesita saber qué son Ref2Vec y Weaviate, respectivamente. Para responder a esta pregunta, es necesario saber qué son Ref2Vec y Weaviate, respectivamente. Por lo tanto, es necesario llamar a la base de datos dos veces para ambas preguntas a fin de recuperar el contexto pertinente. A continuación, las dos respuestas se combinan para producir un único resultado. La evaluación del rendimiento de un motor de consulta multisalto puede realizarse examinando las subpreguntas. Es importante que LLM cree subpreguntas relevantes, responda a cada pregunta con precisión y combine las dos respuestas para proporcionar resultados relevantes y precisos. Además, si se formulan preguntas complejas, es mejor utilizar un motor de consulta multisalto.

Los problemas multisalto dependen ante todo de la precisión de las subpreguntas. Aquí podríamos utilizar una evaluación LLM similar, con la siguiente pregunta: "Dada la pregunta: {query}. Un sistema decidió descomponerla en las subpreguntas {sub_pregunta_1} y {sub_pregunta_2}. ¿Tiene sentido esta descomposición de la pregunta?" A continuación, realizamos dos evaluaciones RAG separadas para cada subpregunta y evaluamos si LLM puede combinar las respuestas a cada pregunta para responder a la pregunta original.

Como otro ejemplo de la evolución de la complejidad de los GAR a los Agentes, consideremos los motores de consulta de enrutamiento. La siguiente figura ilustra cómo un Agente puede enrutar una consulta a una base de datos SQL o vectorial. Este escenario es muy similar a nuestra discusión del enrutamiento multiíndice, y podemos utilizar un enfoque similar para evaluar los resultados generados, insinuando la necesidad de indicar bases de datos SQL y vectoriales, y preguntando después al enrutador LLM si tomó la decisión correcta. También podríamos utilizar la puntuación de relevancia contextual de RAGAS para los resultados de consultas SQL.

Para resumir la discusión de "De la RAG a la evaluación de agentes", creemos que actualmente es imposible saber cuáles son los patrones comunes de uso de los agentes. Hemos mostrado intencionadamente motores de consulta multisalto y enrutadores de consulta porque son relativamente fáciles de entender. Una vez que añadamos evaluaciones más abiertas relacionadas con bucles de planificación, uso de herramientas y cómo evaluar la capacidad de un modelo para formatear solicitudes de API de herramientas, así como sugerencias de gestión de memoria meta-interna como las de MemGPT, será difícil proporcionar una abstracción común sobre cómo evaluar Agentes.

llegar a un veredicto

Muchas gracias por leer nuestro resumen de la evaluación GAR. A modo de resumen rápido, en primer lugar presentamos la nueva tendencia de utilizar LLM para la evaluación, lo que supone un importante ahorro de costes y tiempo para los sistemas de GAR iterativos. A continuación, presentamos más antecedentes sobre las métricas tradicionales utilizadas para evaluar las pilas de GAR, desde la generación hasta la búsqueda y la indexación. Para los constructores que deseen mejorar el rendimiento de estas métricas, mostramos a continuación algunos parámetros sintonizables para la indexación, la búsqueda y la generación. Presentamos los retos del seguimiento experimental de estos sistemas y describimos nuestros puntos de vista sobre las diferencias entre la evaluación de RAG y la evaluación de agentes. Esperamos que este artículo le resulte útil.