2023 Old article review : a guide to the RAG system building process and assessment (Revue des anciens articles : un guide pour le processus de construction et l'évaluation du système RAG)

Retrieval Augmented Generation (RAG) est en train de devenir l'une des applications les plus populaires des grands modèles de langage (LLM) et des bases de données vectorielles. WeaviateLes applications RAG sont couramment utilisées dans les chatbots et les systèmes de questions-réponses.

Comme pour tout système technique, l'évaluation des performances est importante pour RAG La filière RAG est divisée en trois composantes :

1. indexation
2. récupérer (données)
3. générant

L'évaluation des RAG est un défi en raison de la complexité des interactions entre ces composants et de la difficulté de collecter des données d'essai. Cet article présentera un développement passionnant dans l'utilisation du LLM pour l'évaluation et l'état actuel des composants RAG.

en brefNous sommes inspirés par un partenariat avec Ragas Le dialogue entre Jithin James et Shauhul Es, les créateurs de l'émission de télévision de l'Union européenne. Ces dialogues, écrits par Ragas et les nouveaux développements dans l'évaluation LLM des systèmes RAG dont l'ARES a été le pionnier nous ont incités à réfléchir aux mesures existantes et à faire le point sur les paramètres ajustables des RAG. Au cours de nos recherches, nous avons poursuivi notre réflexion sur les formes possibles de logiciels de suivi expérimental des systèmes RAG et nous avons précisé en quoi les systèmes RAG diffèrent des systèmes d'agents et comment ils sont évalués.

Nos articles de blog contiennent les cinq sections principales suivantes :

• Évaluation du LLMLes tendances émergentes en matière de notation des performances RAG à l'aide de LLM, y compris les échantillons nuls, les échantillons peu nombreux et le réglage fin de la taille de l'évaluateur LLM.
• Indicateurs RAGLes indicateurs de performance : Les indicateurs communs utilisés pour évaluer la génération, la recherche et l'indexation, ainsi que leur interaction.
• Paramètres réglementaires du RAGLes décisions qui influencent de manière très différente la performance des systèmes RAG : Quelles sont les décisions qui influencent de manière très différente la performance des systèmes RAG ?
• programmationComment gérer le suivi de la configuration de l'expérience pour le système RAG ?
• Du RAG à l'évaluation des agentsNous définissons un RAG comme un processus en trois étapes d'indexation, de recherche et de génération. Cette section décrit quand un système RAG est transformé en un système Agent et comment évaluer leurs différences.

Évaluation du LLM

Commençons par la partie la plus récente et la plus passionnante : l'évaluation du LLM ! L'histoire de l'apprentissage automatique s'est fortement appuyée sur le travail d'annotation manuelle des données, par exemple pour déterminer si un avis Yelp est positif ou négatif, ou si un article est pertinent par rapport à la question "Qui est l'entraîneur en chef des Boston Celtics ?" LLM devient progressivement plus efficace pour annoter les données avec moins d'efforts manuels. C'est la clé de l'accélération de la croissance des applications RAG** "Quoi de neuf "**.

laisser (à qqn) Ragas La technique la plus courante mise au point par des cadres tels que l'évaluation LLM à échantillon zéro est l'évaluation LLM à échantillon zéro. L'évaluation LLM à échantillon zéro consiste à demander au grand modèle de langage des modèles tels que "Veuillez évaluer la pertinence de ces résultats de recherche sur une échelle de 1 à 10. La requête est {requête} et les résultats de la recherche sont {résultats_recherche}." La figure suivante montre comment le LLM peut être utilisé pour évaluer les performances d'un système RAG.

Il existe trois possibilités principales de réglage dans l'évaluation du MLI à zéro échantillon : 1. les mesures de conception, telles que la précision, le rappel ou le nDCG, 2. la langue spécifique de ces indices, et 3. le modèle de langue utilisé pour l'évaluation, par exemple, GPT-4, Coral, Llama-2, Mistral, et ainsi de suite. À l'heure actuelle, le coût de l'utilisation du LLM pour l'évaluation constitue une préoccupation majeure. Par exemple, l'évaluation de 10 résultats de recherche à l'aide de GPT-4 (en supposant 500 tokens par résultat, plus 100 tokens pour la requête et la commande, pour un total d'environ 6 000 tokens) coûterait environ 1 000 $ par Jeton 0,005, soit 3 dollars pour évaluer 100 requêtes.

Comme des cadres tels que Ragas promeuvent l'évaluation LLM à zéro échantillon, les gens commencent à s'interroger sur la nécessité d'une évaluation LLM à moins d'échantillons. Puisque l'évaluation LLM à zéro échantillon est "suffisamment bonne", elle peut être suffisante pour servir d'étoile polaire pour le réglage du système RAG. Comme le montre la figure ci-dessous, le score RAGAS se compose de quatre invites LLM à zéro échantillon pour chacune des deux mesures générées :Fidélité répondre en chantant Pertinence des réponses (Pertinence des réponses)ainsi que deux indicateurs pour la recherche :Précision du contexte (Précision du contexte) répondre en chantant Rappel de contexte (Rappel de contexte).

 source (d'information, etc.)

Le passage d'une évaluation LLM à zéro échantillon à une évaluation LLM à moindre échantillon est simple. Nous avons inclus des exemples annotés de la pertinence des résultats de la recherche par rapport à la requête dans les modèles d'instruction, également connus sous le nom d'apprentissage contextuel. La découverte de cette technique a été l'une des principales avancées du GPT-3.

Par exemple, l'ajout de 5 scores de pertinence manuels à l'exemple ajouterait 30 000 tokens à l'offre. En supposant les mêmes coûts que ci-dessus, nous évaluons une augmentation de 3 à 15 dollars pour 100 requêtes. Notez qu'il s'agit d'un simple exemple d'estimation et qu'il n'est pas basé sur un modèle de tarification réel pour LLM. Une considération clé est que l'ajout d'exemples moins nombreux peut nécessiter des modèles contextuels plus longs dont le prix est généralement supérieur au LLM pour des entrées plus petites.

Ce type d'évaluation LLM basée sur des inférences à zéro ou quelques échantillons est déjà très attrayant, mais des recherches supplémentaires ont montré que le coût de l'évaluation LLM peut être encore réduit en formant des algorithmes par distillation de connaissances. Il s'agit de l'utilisation du LLM pour générer des données d'entraînement pour une tâche d'évaluation et de les affiner dans un modèle plus petit.

existent ARESDans un cadre automatisé d'évaluation des systèmes génératifs améliorés par la recherche, Saad-Falcon et al. ont constaté que l'entraînement de son propre évaluateur LLM peut être plus performant que les indices de l'échantillon zéro. ARES utilise ces exemples sous-échantillonnés pour générer une grande quantité de données de requêtes synthétiques, filtrées par le principe de cohérence des boucles : c'est-à-dire, lors d'une recherche avec une requête synthétique, peut-il retrouver le document qui a généré la requête synthétique ? . ARES génère ensuite les données pour le pertinence contextuelle,Authenticité des réponses répondre en chantant Pertinence des réponses Affiner les classificateurs légers.

Mise au point expérimentale de l'auteur DeBERTa-v3-largeLe modèle contient 437 millions de paramètres plus économiques, chaque tête de classification partageant le modèle linguistique de base, soit un total de trois têtes de classification. En divisant les données synthétiques en ensembles de formation et de test, l'évaluation du système ARES a révélé que le modèle affiné surpassait de manière significative le modèle GPT-3.5-turbo-16k à zéro et à quelques échantillons. Pour plus de détails (par exemple, l'utilisation innovante des intervalles de confiance dans l'inférence pilotée par la prédiction (PPI) et les détails des expériences), voir Saad-Falcon et al.Thèse.

Afin de mieux comprendre l'impact potentiel de l'apprentissage tout au long de la vie dans l'évaluation, nous continuerons à décrire la méthodologie de benchmarking systématique existante de RAG et ses variations particulières dans l'évaluation de l'apprentissage tout au long de la vie.

Indicateurs RAG

Nous présentons les métriques RAG du point de vue de la génération, de la recherche et de l'indexation. Nous présentons ensuite les paramètres de réglage de RAG du point de vue de la construction des index, du réglage des méthodes de recherche et de la génération d'options.

Une autre raison de présenter les mesures des RAG dans une perspective de haut niveau est que les erreurs d'indexation sont transmises à la recherche et à la génération, mais que les erreurs de génération (telles que les niveaux que nous définissons) n'ont pas d'incidence sur les erreurs d'indexation. Dans l'état actuel de l'évaluation des RAG, il y a rarement une évaluation de bout en bout de la pile de RAG, et il est souvent supposé que la pile de RAG est la plus efficace. contexte de l'oracle peut-être terme d'interférence contrôlée (CIT)(par exemple, l'expérience Lost in the Middle) pour déterminer la véracité générée et la pertinence de la réponse. De même, les encastrements sont généralement évalués à l'aide d'un indice violent qui ne tient pas compte de l'erreur approximative du plus proche voisin. L'erreur de voisinage approximatif est généralement mesurée en trouvant le point optimal de précision pour échanger la requête par seconde et le rappel, le rappel ANN étant les vrais voisins les plus proches de la requête, plutôt que les documents marqués comme "pertinents" pour la requête.

Génération d'indicateurs

L'objectif global de l'application RAG est de générer des résultats utiles, étayés par l'utilisation du contexte récupéré. L'évaluation doit tenir compte du fait que le résultat utilise le contexte et n'est pas directement tiré de la source, ce qui permet d'éviter les informations redondantes et les réponses incomplètes. Afin d'évaluer les résultats, des mesures couvrant chaque critère doivent être développées.

Ragas Deux scores sont introduits pour mesurer la performance du résultat de la modélisation du langage large (LLM) : la plausibilité et la pertinence de la réponse.degré de crédibilité Évaluer l'exactitude factuelle des réponses sur la base du contexte retrouvé.Pertinence des réponses Déterminer la pertinence de la réponse par rapport à la question. Les réponses peuvent avoir des scores de crédibilité élevés mais des scores de pertinence de réponse faibles. Par exemple, une réponse plausible peut reproduire directement le contexte, mais cela se traduit par une faible pertinence de la réponse. Les scores de pertinence des réponses sont pénalisés lorsque les réponses manquent d'exhaustivité ou contiennent des informations en double.

En 2020, Google a publié MeenaL'objectif de Meena est de démontrer qu'elle est capable d'effectuer les tâches suivantes Raisonnable et spécifique du dialogue. Pour mesurer les performances des chatbots dans un domaine ouvert, ils ont introduit la mesure d'évaluation Sensibleness and Specificity Average (SSA) (moyenne de sensibilité et de spécificité). La réponse du robot doit être raisonnable dans son contexte et spécifique (moyenne de spécificité). Cela garantit que le résultat est complet et sans ambiguïté.2020 Cela nécessite qu'un humain parle au chatbot et le note manuellement.

S'il est bon d'éviter les réponses vagues, il est tout aussi important d'empêcher les grands modèles linguistiques d'apparaître le fruit de l'imagination . L'illusion fait référence au fait que les réponses générées par le Big Language Model ne sont pas basées sur des faits réels ou sur le contexte fourni.LlamaIndex utiliser FaithfulnessEvaluator pour mesurer cela. Les scores sont basés sur la cohérence de la réponse avec le contexte retrouvé.

L'évaluation de la qualité des réponses générées dépend d'un certain nombre d'indicateurs. Les réponses peuvent être factuelles mais sans rapport avec la question posée. En outre, la réponse peut être vague et manquer d'informations contextuelles essentielles pour étayer la réponse. Nous reviendrons ensuite sur la couche précédente du pipeline et discuterons des métriques de recherche.

Récupération des indicateurs

La couche suivante de la pile d'évaluation est la recherche d'informations. L'évaluation de l'historique de recherche nécessite que les humains annotent les documents pertinents pour la requête. Ainsi, pour créer une annotation de requête, il peut être nécessaire d'annoter la pertinence de 100 documents. Il s'agit déjà d'une tâche extrêmement difficile pour les requêtes de recherche générales, et le défi est encore plus grand lorsqu'il s'agit de construire des moteurs de recherche spécifiques à un domaine (par exemple, les contrats juridiques, les antécédents des patients médicaux, etc.

Pour réduire les coûts d'annotation, des heuristiques sont souvent utilisées pour déterminer la pertinence de la recherche. La plus courante est l'enregistrement des clics, c'est-à-dire qu'à partir d'une requête, les titres cliqués peuvent être pertinents, alors que les titres non cliqués ne le sont pas. Cette méthode est également connue sous le nom de supervision faible dans le domaine de l'apprentissage automatique.

Une fois que l'ensemble des données est prêt, trois indicateurs sont couramment utilisés dans l'évaluation : nDCG ,Rappel répondre en chantant Précision Le NDCG (Normalised Discount Cumulative Gain) mesure les classements en fonction de plusieurs critères de pertinence. Par exemple, un document sur la vitamine B12 peut ne pas être le résultat le plus pertinent pour une requête sur la vitamine D, mais il est plus pertinent qu'un document sur les Boston Celtics. En raison de la complexité supplémentaire du classement relatif, des étiquettes de pertinence binaires (1 pour pertinent et 0 pour non pertinent) sont souvent utilisées. Le rappel mesure le nombre d'échantillons positifs capturés dans les résultats de recherche, et la précision mesure la proportion de résultats de recherche qui sont étiquetés comme pertinents.

Ainsi, le Big Language Model peut calculer la précision à l'aide de l'invite suivante : "Combien de résultats de recherche parmi les suivants sont liés à la requête {requête} ? {search_results}". Une approximation du rappel peut également être obtenue à partir de l'invite du Big Language Model : "Ces résultats de recherche contiennent-ils toutes les informations nécessaires pour répondre à la requête {requête} ? {search_results}". Nous encourageons également le lecteur à consulter certains des conseils de Ragas ici (littéraire).

Une autre mesure qui mérite d'être explorée est LLM Wins, où l'invite de Big Language Modelling est la suivante : "Sur la base de la requête {query}, quel ensemble de résultats de recherche est le plus pertinent ? L'ensemble A {Set_A} ou l'ensemble B {Set_B}. Très important ! Veuillez limiter le résultat à 'Ensemble A' ou 'Ensemble B'".

Nous allons maintenant aller plus loin et comprendre comment comparer les index vectoriels.

Indicateurs indexés

Les utilisateurs expérimentés qui connaissent bien Weaviate savent que Benchmarks ANNLe test d'évaluation des performances a inspiré Développement de l'API gRPC dans Weaviate version 1.19Le benchmark ANN mesure les requêtes par seconde (QPS) par rapport au rappel et prend en compte des détails tels que les limites d'un seul thread. Alors que les bases de données sont généralement évaluées sur la base des coûts de latence et de stockage, les index de vecteurs aléatoires sont davantage axés sur les mesures de précision. Cela contraste avec Calculs approximatifs dans les instructions SQL select C'est un peu la même chose, mais nous prévoyons que les erreurs causées par les approximations feront l'objet d'une plus grande attention à mesure que l'indexation des vecteurs deviendra plus populaire.

La précision est mesurée par le rappel. Dans l'indexation vectorielle, le rappel est le rapport entre le nombre de voisins les plus proches de la réalité renvoyés par l'algorithme d'indexation approximative et le nombre de voisins les plus proches déterminés par la recherche brute. Ceci est similaire à la recherche d'informations (Information Récupération) diffère de l'usage habituel du "rappel", qui se réfère à la proportion de documents pertinents récupérés parmi tous les documents pertinents. Les deux sont généralement mesurés à l'aide d'un paramètre @K associé.

Dans le contexte de la pile RAG complète, une question intéressante se pose :Quand les erreurs de précision du RNA conduisent-elles à des erreurs dans la recherche d'informations (RI) ? Par exemple, nous pouvons atteindre 1 000 QPS avec un rappel de 80% ou 500 QPS avec un rappel de 95%. Quel est l'impact sur les mesures de recherche mentionnées ci-dessus (par exemple, la recherche des scores de rappel du nDCG ou du Large Language Modelling (LLM)) ?

Résumé des indicateurs RAG

En résumé, nous présentons des mesures permettant d'évaluer l'indexation, la recherche et la génération :

• générantL'évolution des mesures telles que la détection à grande échelle des hallucinations (par exemple, la moyenne de rationalité et de spécificité, la moyenne de sensibilité et de spécificité, SSA).
• récupérer (données)Les nouvelles opportunités pour la précision contextuelle contre le rappel contextuel dans la notation LLM, et une vue d'ensemble de l'annotation humaine pour mesurer le rappel, la précision, et le nDCG.
• indexationLe rappel est mesuré par le nombre de voisins les plus proches de la vérité de base renvoyés par l'algorithme de recherche vectorielle. Nous pensons que la question clé ici est la suivante :Quand les erreurs ANN se transforment-elles en erreurs IR ?

Tous les composants peuvent généralement faire l'objet d'un compromis entre les performances et la latence ou le coût. En utilisant un modèle linguistique plus coûteux, nous pouvons obtenir une génération de meilleure qualité ; en filtrant les résultats avec un réordonnateur, nous pouvons obtenir une extraction de meilleure qualité ; en utilisant plus de mémoire, nous pouvons obtenir une indexation de rappel plus élevée. La façon de gérer ces compromis pour améliorer les performances deviendra plus claire à mesure que nous continuerons à étudier les "boutons de RAG". Enfin, nous avons choisi de présenter les mesures dans une perspective descendante, de la génération à la recherche et à l'indexation, car le temps d'évaluation est plus proche de l'expérience de l'utilisateur. Nous présenterons également les boutons de réglage d'un point de vue ascendant, de l'indexation à la recherche et à la génération, car cela est plus proche de l'expérience d'un développeur d'application RAG.

Paramètres d'ajustement du RAG

Maintenant que nous avons examiné les paramètres permettant de comparer les systèmes RAG, nous allons nous pencher sur les décisions clés qui peuvent avoir un impact significatif sur les performances.

Paramètres de réglage de l'indice

Le paramètre de réglage de l'indexation le plus important lors de la conception d'un système RAG est le paramètre de compression vectorielle, introduit dans Weaviate 1.18 en mars 2023 sous le nom de quantification de produit (PQ), un algorithme de compression vectorielle qui regroupe des fragments consécutifs de vecteurs, regroupe les valeurs dans l'ensemble et réduit la précision par le centre de masse. Par exemple, un fragment contigu de quatre nombres à virgule flottante de 32 bits nécessite 16 octets pour être représenté, alors qu'un fragment de longueur 4 avec huit centres de masse ne nécessite qu'un octet, ce qui permet d'obtenir un taux de compression de la mémoire de 16:1. Les progrès récents en matière de réorganisation de la PQ ont considérablement réduit la perte de rappel due à la compression, mais il convient toujours de l'envisager avec prudence à des niveaux de compression très élevés.

Vient ensuite l'index de routage utilisé. Pour les ensembles de données comportant moins de 10 000 vecteurs, les applications RAG peuvent se contenter d'une indexation par force brute. Cependant, lorsque le nombre de vecteurs augmente, la latence de l'indexation par force brute est beaucoup plus élevée que celle de l'indexation basée sur des algorithmes de graphe de proximité tels que HNSW. Comme décrit dans les métriques RAG, les performances de HNSW sont généralement mesurées par le point optimal de Pareto, qui met en balance les requêtes par seconde et le rappel. Ce résultat est obtenu en ajustant la taille de la file d'attente de recherche utilisée pour l'inférence. ef pour y parvenir. Plus grand ef effectuera plus de comparaisons de distance au cours du processus de recherche, ce qui le ralentit considérablement, mais produit des résultats plus précis. Les paramètres suivants comprennent ceux utilisés dans la construction de l'index, tels que efConstruction (la taille de la file d'attente lors de l'insertion de données dans le graphique) et maxConnections (nombre d'arêtes par nœud, à stocker avec chaque vecteur).

Nous explorons également l'effet du biais de distribution sur le centre de masse des PQ et la relation avec les algorithmes hybrides de clustering et d'indexation des graphes tels que DiskANN peut-être IVFOADC+G+P). L'utilisation des mesures de rappel peut être suffisante pour déterminer si nous devons réajuster le centre de masse, mais la question reste de savoir quel sous-ensemble de vecteurs utiliser pour le réajustement. Si nous utilisons les 100 000 vecteurs les plus récents qui font chuter le rappel, nous risquons de surajuster une nouvelle distribution, de sorte qu'il peut être nécessaire d'échantillonner un mélange de calendriers de distribution de données. Ce sujet est étroitement lié à notre point sur l'optimisation continue des modèles d'apprentissage profond, et peut être discuté plus en détail dans la section "Optimisation de la réglementation".

Le découpage des données est une étape importante avant l'insertion des données dans Weaviate. Le découpage convertit les longs documents en parties plus petites. Cela permet d'améliorer la recherche car chaque morceau contient des informations importantes et permet de rester dans les limites de tokens du modèle du grand langage (LLM). Il existe de nombreuses stratégies pour analyser les documents. La figure ci-dessus montre un exemple de découpage d'un document de recherche en fonction de son titre. Par exemple, le morceau 1 correspond au résumé, le morceau 2 à l'introduction, et ainsi de suite. Il existe également des moyens de combiner les morceaux et de créer des chevauchements. Il s'agit notamment d'une fenêtre coulissante qui prend un jeton du bloc précédent et l'utilise comme point de départ du bloc suivant. Un léger chevauchement des blocs améliore la recherche, car l'extracteur est en mesure de comprendre le contexte/bloc précédent. L'image suivante montre un schéma de haut niveau du texte fragmenté.

récupérer (données)

Quatre paramètres principaux sont ajustables dans la recherche : le modèle d'intégration, les poids de la recherche hybride, l'utilisation ou non de l'AutoCut et le modèle de réorganisation.

La plupart des développeurs de RAG sont susceptibles de rapprocher immédiatement le modèle d'intégration utilisé, par exemple OpenAI, Cohere, Voyager, Jina AI, Sentence Transformers, et bien d'autres options ! Les développeurs devront également tenir compte de la dimensionnalité du modèle et de son effet sur la compression PQ.

La décision clé suivante est de savoir comment ajuster les poids d'agrégation pour les méthodes de recherche dense et peu dense dans la recherche hybride. Les poids sont basés sur le paramètre alpha.alpha 0 est pur bm25 Recherche.alpha à 1 est une recherche vectorielle pure. Par conséquent, le fait de fixer alpha Cela dépend de vos données et de votre application.

Un autre développement émergent est l'efficacité des modèles de réorganisation à échantillonnage nul. Weaviate offre actuellement 2 Modèle de réorganisation de Cohere: :rerank-english-v2.0 répondre en chantant rerank-multilingual-v2.0. Comme leur nom l'indique, ces modèles diffèrent principalement par les données d'apprentissage utilisées et les capacités multilingues qui en résultent. À l'avenir, nous prévoyons d'offrir davantage d'options en termes de capacités des modèles, ce qui implique un compromis inhérent entre les performances et la latence qui peut être judicieux pour certaines applications, mais pas pour d'autres. Au cours du processus de réglage des paramètres de la recherche, il a été difficile de découvrir quel type de réorganisateur capable était nécessaire et combien de résultats de recherche devaient être réorganisés. Il s'agit également de l'un des points d'entrée les plus faciles pour affiner les modèles personnalisés dans la pile RAG, que nous examinons plus en détail dans la section "Optimisation de la réglementation".

Un autre paramètre de réglage intéressant est la recherche multi-index. Comme pour le découpage, cela implique des modifications structurelles de la base de données. La question générale est la suivante :Quand dois-je utiliser une collecte séparée au lieu d'un filtre ? devrait transférer blogs répondre en chantant documentation en deux ensembles, ou les stocker ensemble dans une collection avec une valeur de source attribut Document Dans la catégorie ?

L'utilisation de filtres nous donne un moyen rapide de tester l'utilité de ces étiquettes, car nous pouvons ajouter plusieurs étiquettes à chaque bloc et ensuite ablater pour analyser comment le classificateur les utilise. Il existe un certain nombre d'idées intéressantes, telles que l'étiquetage explicite de la source du contexte dans l'entrée contextuelle du LLM, par exemple "Les résultats suivants sont des résultats de recherche provenant de blogs {search_results}. Voici les résultats de recherche de documents {documentation}". Comme le LLM est capable de traiter des entrées plus longues, nous nous attendons à ce que la fusion de contexte entre des sources de données multiples devienne plus courante, donc un autre hyperparamètre pertinent émerge : combien de documents sont récupérés de chaque index ou filtre.

générant

La première chose sur laquelle il faut se concentrer en ce qui concerne la génération est le choix d'un grand modèle de langage (LLM). Par exemple, vous pouvez choisir les modèles d'OpenAI, Cohere, Facebook et de nombreuses options open source. De nombreux cadres LLM (par ex. LangChain,LlamaIndex répondre en chantant Module de génération de Weaviate) offre une intégration facile avec une variété de modèles, ce qui est un grand avantage. Le choix du modèle peut dépendre de facteurs tels que la confidentialité des données, le coût, les ressources, etc.

Un paramètre de régulation commun, spécifique au LLM, est la température. Le réglage de la température contrôle le caractère aléatoire de la sortie. Une température de 0 signifie que la réponse est plus prévisible et moins variable ; une température de 1 permet au modèle d'introduire de l'aléatoire et de la créativité dans la réponse. Par conséquent, si vous exécutez le modèle génératif plusieurs fois avec une température de 1, la réponse peut être différente à chaque fois.

Les modèles à contexte long (LCM) constituent une nouvelle orientation dans le choix d'un LLM pour votre application. L'ajout de résultats de recherche en entrée améliore-t-il la qualité des réponses ? La recherche sur l'expérience "Lost in the Middle" (Perdus au milieu) soulève quelques points d'interrogation. En "Perdu au milieu" Dans ce document, des chercheurs de Stanford, UC Berkeley et Samaya AI ont mené des expériences contrôlées montrant que si des informations pertinentes sont placées au milieu d'un résultat de recherche, plutôt qu'au début ou à la fin, le modèle de langage peut ne pas être en mesure de les intégrer lors de la génération d'une réponse. Un autre article rédigé par des chercheurs de Google DeepMind, de Toyota et de l'université de Purdue indique que"Les grands modèles linguistiques sont facilement distraits par un contexte non pertinent.. Malgré le potentiel de cette orientation, au moment où nous écrivons ces lignes, le RAG à long contexte n'en est qu'à ses débuts. Heureusement, des mesures telles que les scores de Ragas peuvent nous aider à tester rapidement de nouveaux systèmes !

Tout comme les récentes percées dans l'évaluation LLM que nous avons discutées plus tôt, l'aspect génératif de l'ajustement est divisé en trois étapes : 1. l'ajustement de l'invite, 2. quelques exemples, et 3. l'ajustement fin. Le réglage des invites implique l'ajustement d'expressions linguistiques spécifiques telles que "Veuillez répondre à la question en vous basant sur les résultats de recherche fournis". au lieu de "Veuillez répondre à la question. Il est important de suivre scrupuleusement les instructions ci-dessous. Votre réponse à la question doit être basée sur les résultats de recherche fournis, uniquement !!!" La différence entre.

Comme nous l'avons mentionné précédemment, un échantillon moins exemple fait référence à la collecte d'un certain nombre de paires de questions, de contextes et de réponses écrites manuellement pour guider la génération d'un modèle linguistique. Des études récentes (par exemple "Vecteur de contexte) démontre une fois de plus l'importance d'amorcer l'espace potentiel de cette manière. Dans le projet Weaviate Gorilla, nous avons utilisé GPT-3.5-turbo pour générer des requêtes Weaviate, et lorsque nous avons ajouté le langage naturel à la traduction des requêtes des exemples les plus simples, les performances se sont améliorées de manière significative.

Enfin, le réglage fin du LLM pour les applications RAG fait l'objet d'une attention croissante. Voici quelques approches à considérer. Pour revenir à notre discussion sur l'évaluation du LLM, nous pourrions vouloir générer des données de formation en utilisant un LLM plus robuste pour construire un modèle plus petit et plus abordable qui nous appartiendrait. Une autre idée est de fournir une annotation humaine de la qualité des réponses afin que le LLM puisse être affiné avec la commande suivante. Si vous êtes intéressé par l'affinement du modèle, consultez la contribution de Brev sur la façon d'utiliser la bibliothèque HuggingFace PEFT à l'adresse suivante tutoriels.

Résumé des options de réglage du RAG

En résumé, nous avons décrit les principales options de réglage disponibles dans le système RAG :

• Indexation : au niveau le plus élevé, nous devons déterminer quand utiliser uniquement la recherche par force brute et quand introduire l'indexation ANN. Cette question est particulièrement intéressante lorsqu'il s'agit de régler des cas d'utilisation multi-locataires avec de nouveaux utilisateurs ou des utilisateurs assidus. Dans l'indexation ANN, nous disposons d'hyperparamètres pour PQ (fragmentation, centre de masse et limites d'entraînement). hNSW comprend (ef, efConstruction et maxConnections).
• Récupération : sélection d'un modèle d'intégration, ajustement des poids de recherche hybrides, sélection d'un réorganisateur et partitionnement d'une collection en plusieurs index.
• Générer : sélectionner un LLM et décider quand passer de l'ajustement des repères à des exemples moins nombreux ou à l'ajustement fin.

Après avoir compris les paramètres RAG et la manière d'améliorer leurs performances par le biais de réglages, examinons les possibilités de mise en œuvre d'un suivi expérimental.

programmation

Compte tenu des avancées récentes dans le domaine de l'évaluation des grands modèles de langage (LLM) et d'un aperçu de certains des paramètres réglables, il existe une opportunité intéressante de combiner tout cela avec un cadre de suivi des expériences. Par exemple, un simple orchestrateur avec une API intuitive pourrait être utilisé pour que l'utilisateur effectue les opérations suivantes : 1. demander un test complet de 5 LLM, 2 modèles intégrés et 5 configurations d'indexation ; 2. exécuter les expériences ; et 3. renvoyer un rapport de haute qualité à l'utilisateur.Weights & Biases a tracé un chemin de suivi expérimental remarquable pour la formation de modèles d'apprentissage profond. Nous nous attendons à ce que l'intérêt se développe rapidement pour le soutien expérimental RAG avec les paramètres réglables et les métriques décrites dans ce document.

Nous suivons deux directions de développement dans ce domaine. D'une part, les LLM à zéro échantillon existants (par exemple, GPT-4, Command, Claude, ainsi que les options open-source Llama-2 et Mistral) ne sont pas aussi efficaces pour avoir une vision d'ensemble. contexte de l'oracle s'est assez bien comportée à l'époque. Il existe donc une énorme opportunité de Se concentrer sur la recherche . Il faut pour cela trouver des moyens de concilier les erreurs des ANN, les modèles intégrés, la pondération de la recherche hybride et la réorganisation du PQ ou du HNSW dans des configurations multiples, comme décrit précédemment dans le présent document.

Weaviate 1.22 introduit des index asynchrones et des API d'état de nœud correspondantes, dont nous espérons que, grâce à des partenariats axés sur l'évaluation RAG et l'orchestration des réglages, ils pourront tirer parti pour déterminer quand les index ont fini d'être construits et ensuite exécuter des tests. Ceci est particulièrement intéressant lorsqu'il s'agit de régler les interfaces d'orchestration avec chaque locataire sur la base de ces états de nœuds, où certains locataires peuvent s'appuyer sur la recherche par force brute tandis que d'autres ont besoin de trouver le bon modèle d'intégration et la bonne configuration HNSW pour leurs données.

En outre, nous pouvons souhaiter accélérer les tests en parallélisant l'allocation des ressources. Par exemple, évaluer 4 modèles d'intégration en même temps. Comme mentionné précédemment, une autre partie intéressante est l'ajustement des chunks ou d'autres métadonnées symboliques qui peuvent provenir de l'importateur de données. Par exemple, le jeu de données Weaviate Verba contient 3 dossiers de Weaviate's Blogs,Documentation répondre en chantant Video Transcription. Si nous souhaitons comparer des tailles de morceaux de 100 et 300, il n'est pas nécessaire de rappeler le robot d'exploration du web. Nous pourrions avoir besoin d'un autre format, soit des données stockées dans des buckets de stockage S3 ou autre, avec les métadonnées associées, mais c'est un moyen plus économique d'expérimenter.

D'autre part, nous avons le réglage fin du modèle et l'apprentissage continu basé sur le gradient plutôt que l'insertion ou la mise à jour des données. Les modèles les plus courants utilisés dans RAG sont les modèles intégrés, les modèles réordonnés et, bien sûr, les LLM. La mise à jour des modèles d'apprentissage automatique en fonction des nouvelles données est depuis longtemps un objectif des cadres d'apprentissage continu et des orchestrations MLops qui gèrent le recyclage, le test et le déploiement de nouveaux modèles. En ce qui concerne l'apprentissage continu LLM, l'un des principaux arguments de vente du système RAG est la possibilité de repousser la date limite de la base de connaissances LLM afin de la synchroniser avec vos données. Nous ne pensons pas que l'interaction entre la formation continue et la mise à jour des informations par le biais du système RAG soit claire. Certaines études (par exemple MEMIT) ont expérimenté des analyses de médiation causale de l'attribution de poids, en mettant à jour des faits tels que "LeBron James joue au basket-ball" en "LeBron James joue au football". "et ainsi de suite. Il s'agit d'une technique assez avancée, et une autre possibilité pourrait consister à simplement étiqueter les morceaux utilisés dans la formation (par exemple, "LeBron James joue au basket-ball") et à les entraîner à nouveau en utilisant des données de formation améliorées par la recherche contenant les nouvelles informations. Il s'agit d'un domaine important que nous suivons de près.

Comme nous l'avons déjà mentionné, nous réfléchissons également à la manière d'intégrer ce type de réglage continu directement dans Weaviate à l'aide des centroïdes PQ. Le centroïde PQ des K premiers vecteurs entrant dans Weaviate pour la première fois peut être affecté par des changements significatifs dans la distribution des données. La formation continue des modèles d'apprentissage automatique souffre du fameux problème de "l'oubli catastrophique", où la formation sur le dernier lot de données nuit aux performances sur les lots précédents. C'est l'une des considérations que nous avons prises en compte lors de la conception du réaménagement du centre de masse du PQ.

Du RAG à l'évaluation des agents

Tout au long de cet article, nous nous concentrons sur la RAG Au lieu de Agent Évaluation. À notre avis.RAG défini comme le processus d'indexation, d'extraction et de génération, et le processus d'analyse de l'information. Agents Le champ d'application du système est plus ouvert. Le diagramme ci-dessous illustre la façon dont nous voyons les principaux composants, tels que la planification, la mémoire et les outils, qui, ensemble, fournissent des capacités importantes pour votre système, mais le rendent également plus difficile à évaluer.

L'étape suivante pour les applications RAG consiste à ajouter un moteur de requête avancé. Pour les lecteurs qui ne connaissent pas ce concept, consultez nos séries LlamaIndex et Weaviate qui fournissent des exemples de code Python sur la façon de commencer. Il existe de nombreux moteurs d'interrogation avancés différents, tels que les moteurs d'interrogation de sous-questions, les routeurs SQL, les moteurs d'interrogation auto-correcteurs, et bien d'autres encore. Nous envisageons également des formes possibles de l'API promptToQuery ou de l'extracteur de requêtes de recherche dans le module Weaviate. Chaque moteur de requête a ses propres avantages dans le processus de recherche d'informations. Nous allons donc nous pencher sur quelques-uns d'entre eux et sur la manière dont nous pouvons les évaluer.

Le moteur de recherche multi-sauts (également connu sous le nom deMoteur de recherche de sous-questions) est parfait pour décomposer des problèmes complexes en sous-problèmes. Dans le diagramme ci-dessus, nous avons la question "Qu'est-ce que Ref2Vec dans Weaviate ?" Pour répondre à cette question, vous devez savoir ce que sont respectivement Ref2Vec et Weaviate. Pour répondre à cette question, vous devez savoir ce que sont respectivement Ref2Vec et Weaviate. Par conséquent, votre base de données doit être appelée deux fois pour les deux questions afin de récupérer le contexte pertinent. Les deux réponses sont ensuite combinées pour produire un seul résultat. L'évaluation des performances d'un moteur de requête multi-sauts peut être effectuée en examinant les sous-questions. Il est important que LLM crée des sous-questions pertinentes, réponde à chaque question avec précision et combine les deux réponses pour fournir un résultat factuel précis et pertinent. En outre, si vous posez des questions complexes, il est préférable d'utiliser un moteur de recherche multi-sauts.

Les problèmes à sauts multiples dépendent avant tout de la précision des sous-questions. Nous pourrions utiliser une évaluation LLM similaire ici, avec l'invite suivante : "Étant donné la question : {requête}. Un système a décidé de la décomposer en deux sous-questions {sous_question_1} et {sous_question_2}. Nous effectuons ensuite deux évaluations RAG séparées pour chaque sous-question et évaluons si LLM peut combiner les réponses à chaque question pour répondre à la question originale.

Pour illustrer l'évolution de la complexité des RAG vers les agents, prenons l'exemple des moteurs de requêtes de routage. La figure ci-dessous illustre comment un agent peut acheminer une requête vers une base de données SQL ou vectorielle. Ce scénario est très similaire à notre discussion sur le routage multi-index, et nous pouvons utiliser une approche similaire pour évaluer les résultats générés, en faisant allusion à la nécessité d'énoncer les bases de données SQL et vectorielles, puis en demandant au routeur LLM s'il a pris la bonne décision. Nous pourrions également utiliser le score de pertinence du contexte RAGAS pour les résultats des requêtes SQL.

Pour résumer la discussion de "Du RAG à l'évaluation des agents", nous pensons qu'il est actuellement impossible de dire quels sont les schémas courants d'utilisation des agents. Nous avons intentionnellement montré des moteurs de requête multi-sauts et des routeurs de requête parce qu'ils sont relativement faciles à comprendre. Une fois que nous aurons ajouté des évaluations plus ouvertes liées aux boucles de planification, à l'utilisation d'outils et à la manière d'évaluer la capacité d'un modèle à formuler des demandes d'API d'outils, ainsi que des indications sur la gestion de la mémoire méta-interne telles que celles de MemGPT, il sera difficile de fournir une abstraction commune sur la manière d'évaluer les agents.

rendre un verdict

Merci beaucoup d'avoir lu notre aperçu de l'évaluation des GCR ! Pour récapituler rapidement, nous avons d'abord présenté la nouvelle tendance consistant à utiliser les LLM pour l'évaluation, ce qui permet de réaliser d'importantes économies de temps et d'argent pour les systèmes RAG itératifs. Ensuite, nous avons présenté plus en détail les mesures traditionnelles utilisées pour évaluer les piles RAG, de la génération à la recherche et à l'indexation. Pour les constructeurs qui souhaitent améliorer la performance de ces mesures, nous montrons ensuite quelques paramètres réglables pour l'indexation, la recherche et la génération. Nous présentons les défis posés par le suivi expérimental de ces systèmes et décrivons notre point de vue sur les différences entre l'évaluation des RAG et l'évaluation des agents. Nous espérons que cet article vous sera utile !