Exemples de probabilités de journaux Azure OpenAI (LogProbs)
Application .NET Console qui montre quatre exemples de la façon dont Azure OpenAI LogProbs peut être utile pour la récupération d'informations de qualité :
- Probabilité du premier jeton : calcule la probabilité vraie ou fausse, renvoie la probabilité la plus élevée si le modèle (LLM) dispose de suffisamment d'informations pour répondre à la question de l'invite.
- Probabilité du premier jeton [Avec les scores Brier] - Probabilité vraie ou fausse, renvoie la probabilité la plus élevée si le modèle (LLM) dispose de suffisamment d'informations pour répondre à la question de l'invite. Calcule les scores Brier à la fois individuels et totaux pour mesurer la précision des prévisions probabilistes du modèle (LLM).
- Probabilité pondérée du score de confiance - Renvoie un score de confiance en soi compris entre 1 et 10 qui est pondéré à partir d'une distribution de probabilité (les 5 principales probabilités logarithmiques) pour donner une estimation améliorée (pondérée) du score de confiance pour répondre à une question.
- Intervalle de confiance : calculé à partir de la simulation bootstrap de plusieurs appels au modèle. Cela fournit un intervalle de confiance (plage) de 95 % des scores de confiance plausibles. C’est idéal lorsque vous avez besoin de comprendre une gamme plausible de possibilités interprétées par le modèle plutôt qu’une estimation ponctuelle.
Commencer
Exigences
- SDK .NET 8.x installé
- Accès API Azure OpenAI : (OpenAI Access fonctionnera également) soit GPT3.5, GPT-4T, GPT-4o, GPT-4o-mini déployés et clé API
- Visual Studio 2022(+) si vous déboguez la solution avec un IDE
Cloner le dépôt
git clone https://github.com/bartczernicki/AzureOpenAILogProbs.git
Ajoutez-le au Secrets.json (clic droit sur VS Project -> Gérer les secrets utilisateur) et exécutez l'application console
{
"AzureOpenAI" : {
"ModelDeploymentName" : "gpt-4-2024-04-09" , // Any Azure OpenAI GPT-4o-mini, GPT-4o or GPT3.5 model should perform well
"APIKey" : "YOURAZUREOPENAIKEY" ,
"Endpoint" : "https://YOURAZUREOPENAIENDPOINT.openai.azure.com/"
}
}
Créer et exécuter des commandes (vous pouvez également créer ou déboguer à partir de Visual Studio 2022+)
Informations clés sur la configuration de la solution
Dans cette configuration, le LLM recevra des paragraphes sélectionnés d'un article Wikipédia sur l'histoire de l'équipe de baseball des Mets de New York. L'article complet peut être consulté ici : https://en.wikipedia.org/wiki/New_York_Mets. Il s'agit du contexte (informations de base) qui sera toujours fourni dans chaque invite.
De plus, 20 paires de questions et réponses sont fournies. Chaque élément de la liste comporte une question sur l'article Wikipédia des Mets associée à une évaluation humaine Vrai/Faux, s'il y a suffisamment d'informations dans l'article Wikipédia fourni pour répondre à la question. Chaque question sera envoyée au LLM et celui-ci évaluera ensuite s'il dispose de suffisamment d'informations pour répondre à la question. Cette réponse sera comparée à l’évaluation humaine (vérité logique). Deux exemples parmi la liste de 20 questions :
new Question { Number = 1 , EnoughInformationInProvidedContext = true , QuestionText = " When where the Mets founded? " } ,
new Question { Number = 2 , EnoughInformationInProvidedContext = true , QuestionText = " Are the Mets a baseball team or basketball team? " } ,
La possibilité d'inspecter les probabilités du journal des jetons est désactivée par défaut. Pour activer cette fonctionnalité, la propriété IncludeLogProbabilities doit être définie sur true. Cela ne coûte pas de jetons supplémentaires et ne rend pas les appels API plus coûteux. Cependant, cela augmente très légèrement la charge utile de l'objet JSON qui revient. Par exemple, en utilisant la nouvelle bibliothèque OpenAI .NET, il est exposé en tant que propriété sur la classe ChatCompletionOptions.
chatCompletionOptions . IncludeLogProbabilities = true ;
La bibliothèque .NET inclut la possibilité de contrôler le nombre de probabilités de journal renvoyées avec chaque appel d'API. Cela fournit un tableau/une liste de jetons avec chaque probabilité respective. En statistique, c'est ce qu'on appelle une fonction de masse de probabilité (PMF) car il s'agit d'une distribution discrète de probabilités. Remarque : Sur Azure OpenAI, ce nombre est actuellement limité à 5 et sur OpenAI 10 (pour la plupart des API). Par exemple, en utilisant la nouvelle bibliothèque OpenAI .NET, il est exposé en tant que propriété sur la classe ChatCompletionOptions.
chatCompletionOptions . TopLogProbabilityCount = 5 ;
La solution inclut également la possibilité de définir la température de chacune des sorties attendues du modèle (LLM). La valeur par défaut est 0,3f (nombre à virgule flottante), mais peut être augmentée à 2f pour plus de créativité et de variance.
internal static class GenAI
{
// To simulate more variance in selecting lower probability tokens, increase the temperature to between 1.4 - 2.0.
public const float OPENAITEMPATURE = 0.3f ;
.. .
C'est essentiellement la configuration de base de cette solution. Le reste du code est du code C# pour câbler les entrées/sorties des services et garantir que les calculs sont correctement effectués et visualisés dans l'application console.
Informations générales sur les probabilités de journalisation
Que sont les LogProbs (Log Probabilités) ? La plupart des LLM actuels traitent les instructions d'invite en prédisant le prochain jeton et parcourent chaque jeton jusqu'à ce qu'ils atteignent un point d'arrêt (c'est-à-dire la longueur maximale du jeton, en complétant les instructions de l'utilisateur). Pour chaque jeton pris en compte pour la sortie, il est traité via un pipeline LLM interne qui génère une distribution de probabilité statistique des jetons « meilleure correspondance » parmi lesquels sélectionner. En fonction des configurations (température, top_p, etc.), ces probabilités de jeton peuvent être calculées, puis le LLM sélectionne le prochain jeton « meilleure correspondance » en fonction des différentes configurations. Étant donné que ces LLM sont de nature probabiliste, c'est pourquoi vous pouvez voir différents jetons générés pour la même instruction d'invite envoyée au modèle (LLM).
Vous trouverez ci-dessous un exemple de scénario de questions-réponses et les probabilités associées pour les deux jetons (mots) sélectionnés pour répondre à la question : « Qui a été le premier président des États-Unis ? » . Dans l'exemple ci-dessous, le modèle a répondu avec deux jetons « George » « Washington », en utilisant les probabilités de jetons de 99,62 % et 99,99 % respectivement. Notez qu'il y avait d'autres jetons disponibles pour la sélection, mais les connaissances inhérentes et la capacité de raisonnement du LLM (du fait d'être formé sur une quantité volumineuse de données) ont augmenté avec confiance la probabilité de ces deux jetons : « George » et « Washington ».
Il existe des paramètres qui peuvent calibrer le degré de rigueur ou de créativité d'un LLM. Par exemple, vous avez peut-être entendu parler d'un paramètre de modèle (LLM) appelé Température qui augmente essentiellement les chances de sélection de jetons à faible probabilité.
Besoin de plus d'informations ? Lecture recommandée sur l’arrière-plan d’Azure OpenAI LogProbs :
- Livre de recettes OpenAI - LogProbs : https://cookbook.openai.com/examples/using_logprobs
- Que sont les LogProbs ? : https://www.ignorance.ai/p/what-are-logprobs
Utiliser LogProbs pour améliorer la qualité de GenAI
Il existe diverses techniques d'amélioration éprouvées et nouvelles qui utilisent plusieurs appels à un ou plusieurs modèles pour arriver à une réponse, une conclusion ou une décision de qualité. Actuellement, la plupart des façons dont les LLM sont utilisés dans les systèmes de production GenAI sont avec la mise à la terre (RAG) en fournissant des informations contextuelles supplémentaires. Le modèle (LLM) est chargé de répondre à une question, de raisonner sur ces informations, etc. Cependant, avec de mauvaises techniques de mise à la terre, cela peut entraîner des résultats de moindre qualité.
Azure OpenAI LogProbs est une technique avancée qui peut aider et être utilisée pour évaluer la confiance (probabilité) de la réponse du modèle. Cette formidable capacité peut permettre au système GenAI de s'auto-corriger ou de guider l'utilisateur/agent pour arriver à une réponse de meilleure qualité.
La puissance de LogProbs est illustrée ci-dessous avec le diagramme du flux de travail GenAI. Notez qu'il existe deux chemins (gauche et droite) :
- Le chemin de gauche est le chemin traditionnel suivi par la plupart des applications GenAI. Vous posez une question et recevez une réponse d'un LLM. Ce flux de travail typique sur la gauche est ce que l'on trouvera dans la plupart des applications GenAI Chat actuelles.
- La bonne voie est une « amélioration de la qualité » du flux de travail. En parallèle, on peut demander au LLM "LLM, avez-vous suffisamment d'informations pour répondre à cette question et êtes-vous sûr d'avoir suffisamment d'informations ?" ! Remarquez dans le diagramme ci-dessous que cette « amélioration de la qualité » inclut désormais :
- Réponse à la question
- Le modèle dispose-t-il de suffisamment d'informations pour répondre à la question - Estimation vraie ou fausse du modèle (LLM)
- Probabilité d'avoir suffisamment d'informations pour répondre à la question - Calculée à partir de LogProbs ; qui peut être utilisé pour une inférence statistique supplémentaire ou un seuil de décision
Options de traitement de la console
1) Probabilité du premier jeton - Dans quelle mesure le modèle d'IA (LLM) est-il confiant avec les informations nécessaires pour répondre à la question
- Le modèle (LLM) répondra uniquement par True ou False . Le modèle classera essentiellement (Vrai ou Faux) s'il pense qu'il y a suffisamment d'informations (Vrai) ou pas assez d'informations (Faux) dans la base Wikipédia fournie pour répondre à la question dans l'invite.
- Utilise Azure OpenAI LogProbs pour déterminer la probabilité du premier jeton dans la réponse. Le premier jeton sera toujours True ou False .
- Si la probabilité est élevée, le modèle (LLM) est très confiant dans sa propre réponse (Vrai ou Faux)
- Si la probabilité est faible, le modèle (LLM) n'est pas très sûr de sa propre réponse (Vrai ou Faux)
- La probabilité peut être utilisée comme seuil de décision de classification pour savoir si le modèle dispose de suffisamment d'informations (contexte RAG) pour répondre à la question. Par exemple, on peut fournir à une expérience utilisateur un signal vérifié indiquant que la réponse a passé par une seconde validation lorsque la probabilité émise par le modèle (LLM) est supérieure à 90 %.
Exemple de sortie :
Notez que l'image ci-dessus illustre la sortie Vrai et Faux du LLM ainsi que la probabilité de cette sortie Vrai ou Faux. Étant donné que « Vrai » ou « Faux » sont les premiers et seuls jetons de la réponse, la probabilité du premier jeton (LogProb) peut être utilisée. Il y a quelques problèmes avec cette approche :
- Seuls le premier jeton et la probabilité sont étudiés. En regardant l'exemple de George Washington ci-dessus, notez qu'il existe différents jetons qui peuvent être générés et qui peuvent être des composants ou être similaires à "George Washington". La même chose s'applique même lorsque l'on regarde uniquement les jetons « Vrai » ou « Faux ». Il pourrait y avoir des jetons comme "TRU", "true", "tr" et ils devraient tous être regroupés pour signifier une probabilité collective de "True". Les exemples ci-dessous illustrent cela.
- En exécutant les exemples plusieurs fois, il semblera parfois y avoir un écart entre le premier jeton et le LogProb supérieur. En effet, le service OpenAI peut sélectionner des jetons avec des probabilités plus faibles, en particulier avec des paramètres tels qu'une température plus élevée. Il s'agit d'une solution simple, essentiellement LogProbs permet au développeur de remplacer le premier jeton sélectionné et de sélectionner celui avec la probabilité la plus élevée.
2) Probabilité du premier jeton [avec les scores du Brier] - Calcul des scores du Brier de la probabilité du premier jeton
- Cet exemple montre comment mesurer la précision des prévisions et des prédictions du modèle.
- Identique à la probabilité du premier jeton, mais calcule également le score Brier pour chacune des réponses probabilistes.
- Les scores Brier (et des méthodes similaires dans Machine Learning & Statistics) sont utilisés pour mesurer la précision des prédictions probabilistes.
- Plus le score Brier est faible, plus le modèle est capable de prédire la probabilité de réponse. Par exemple, s'il existe deux modèles et qu'ils prédisent tous deux l'événement correct, mais que la probabilité du premier modèle était de 65 % et celle du deuxième modèle était de 95 %, le score Brier du deuxième modèle sera inférieur. En effet, si l'événement futur se produit, une probabilité de 100 % lui est automatiquement attribuée. 95 % est plus proche de 100 %. Plus d'informations sur les scores du Brier : https://en.wikipedia.org/wiki/Brier_score
- Les scores du Brier peuvent regrouper plusieurs pronostics individuels et être regroupés en un seul score. Cet exemple génère un tableau des scores Brier pour chacune des questions et du score Brier moyen pour toutes les questions.
- La moyenne des scores Brier peut nous en dire beaucoup sur la précision globale des performances du système probabiliste ou d'un modèle probabiliste. Les scores Brier moyens de 0,1 ou moins sont considérés comme excellents, 0,1 à 0,2 sont supérieurs, 0,2 à 0,3 sont adéquats et 0,3 à 0,35 sont acceptables, et enfin les scores moyens au Brier supérieurs à 0,35 indiquent de mauvaises performances de prédiction.
Les scores du Brier varient en fonction des capacités du modèle, de l'invite et du contexte de la question. En gardant l'invite et le contexte identiques, on peut comparer les performances globales de précision du modèle. Notez les scores Brier ci-dessous comparant les modèles GPT-4o et GPT-4o-mini. Le modèle GPT-4o-mini a un score Brier inférieur, ce qui signifie qu'il est plus précis dans la prédiction de la probabilité d'une réponse correcte. En fait, le GPT-4o-mini est arrivé correctement à la réponse finale à 18 des 20 questions, alors que le modèle GPT-4o correspondait à la réponse humaine attendue (s'il y a suffisamment d'informations dans le contexte pour répondre à la question) 17 sur 20 questions. Notez que le score Brier moyen du GPT-4o-mini est de 0,083 (inférieur à 0,1), ce qui indique d'excellentes performances prédictives. Par conséquent, le score Brier du modèle GPT-4o-mini est inférieur (meilleur). Cela montre empiriquement qu'il est plus précis dans la quantification de la probabilité qu'il dispose de suffisamment d'informations pour répondre à la question posée.
Exemple de sortie :
3) Probabilité pondérée du score de confiance - Le modèle fournit un score de confiance en soi, puis évalue la probabilité du score de confiance.
- Dans les exemples précédents, seule la première probabilité symbolique a été utilisée. Le jeton ayant la probabilité la plus élevée a été utilisé comme détermination Vrai ou Faux.
- Azure OpenAI LogProbs peut renvoyer une distribution de fonction de masse de probabilité (PMF) allant jusqu'aux 5 jetons suivants, y compris leurs probabilités.
- Ce calcul utilise plusieurs LogProbs pour déterminer la probabilité « pondérée » de la réponse.
- De plus, au lieu de demander au modèle de simplement fournir une détermination Vrai ou Faux, le modèle peut fournir un score de confiance (1 à 10) indiquant son degré de confiance dans la réponse à la question.
- La probabilité pondérée est calculée par multiplication : Score de confiance*Probabilité pour donner une meilleure estimation pondérée de la confiance pour répondre à la question.
- La probabilité pondérée peut être utilisée comme score de confiance mieux calibré pour la réponse du modèle.
Pour renvoyer plusieurs probabilités de journal, définissez LogProbabilitiesPerToken sur 5 (maximum actuel d'Azure OpenAI, au moment d'écrire ces lignes) :
chatCompletionOptions.Temperature = 0.3f; // Higher Temperature setting will use tokens with much lower probability
chatCompletionOptions.IncludeLogProbabilities = true;
// For the Confidence Score, we want to investigate 5 of the top log probabilities (PMF)
chatCompletionOptions.TopLogProbabilityCount = 5;
Exemple de sortie :
Vous trouverez ci-dessous un exemple de distribution de probabilité de jeton lorsque 5 jetons LogProbs sont renvoyés avec leurs probabilités respectives. Dans l'histogramme ci-dessous, « Score de confiance : 1 » a une probabilité de 42,3 % ; ce qui signifie que le modèle pense qu'il a un très faible score de confiance = 1 pour répondre à la question et que la faible chance est de 42,3 %. Si vous sélectionnez simplement le score de confiance le plus élevé renvoyé par le modèle, vous risquez de manquer de nombreuses autres informations avec les autres jetons (jeton numéro 2 à 5). Dans ce scénario, il existe environ 57 % d'informations supplémentaires selon lesquelles d'autres probabilités symboliques peuvent être utilisées pour calculer un score de confiance « pondéré », qui calibre le score de confiance de 1 à 2,3.
4) Intervalle de score de confiance à 95 % - Utilisez la distribution des probabilités pour calculer un intervalle de confiance (plage) de 95 % de réponses plausibles.
- Les exemples précédents montrent une estimation en un seul point du score de confiance. Cela peut être trompeur car le modèle peut avoir plusieurs interprétations de la réponse.
- Azure OpenAI LogProbs peut renvoyer une distribution de fonction de masse de probabilité (PMF) allant jusqu'aux 5 jetons suivants, y compris leurs probabilités.
- Ce calcul utilise plusieurs LogProbs pour déterminer « l'intervalle de confiance » de la réponse.
- L'intervalle de confiance est calculé en amorçant plusieurs appels (10) au modèle (en utilisant la même invite) et en calculant l'intervalle de confiance à 95 % des scores de confiance.
- L'intervalle de confiance peut être utilisé pour comprendre l'éventail des possibilités, où 95 % des résultats se situeront dans cet intervalle lorsque la même question est répétée.
- Pourquoi appelleriez-vous le modèle 10x, n'est-ce pas exagéré ? Pour les décisions et les raisonnements à enjeux élevés (acheter une maison/une voiture, décider d'un diplôme de 4 ans), ces quelques appels supplémentaires valent bien les quelques centimes et le temps supplémentaire nécessaires pour obtenir une plage d'erreur appropriée.
Exemple de sortie :
Autres considérations avancées (exécuter le projet de console SampleConfidenceIntervalSimulation)
Ce référentiel n'a pas abordé le calibrage du score de confiance du modèle ni le calibrage des LogProbs de probabilité du modèle. Les LLM étant essentiellement des réseaux de neurones, ils peuvent être non calibrés pour des tâches ou des domaines spécifiques. Fondamentalement, lorsque le LLM indique qu'il est confiant à 8/10 ou détermine une probabilité de 80 %, le modèle devrait être correct environ 80 % du temps (dans les limites du taux d'erreur).
- Un modèle qui répond à 100 questions avec un score de confiance de 80 % devrait être correct environ 80 fois. Ce serait un étalonnage idéal.
- Remarque : Il existe un taux d'erreur même si le modèle est parfaitement calibré autour de 80 %. Dans le cas de 100 questions, 95% du temps on s'attend à ce que la fourchette soit comprise entre 72 et 88 bonnes questions (+/- 8 questions autour de la moyenne attendue de 80). Pourquoi déclarer un niveau de confiance de 95 % et non de 100 % ? Indiquer un niveau de confiance de 100 % n'a aucun sens puisque la plage de confiance de 100 % va de 0 à 100 bonnes réponses. Même si l’ensemble des probabilités est infaisable, il reste une très infime chance de répondre à 0 ou 100 questions. Un niveau de confiance de 95 % fournit une plage réaliste de résultats plausibles et si vous voyez des résultats en dehors de cette plage, quelque chose « qui mérite d'être étudié » est potentiellement en train de se produire.
- Un modèle qui répondrait à 100 questions avec un score de confiance de 80 % et n’aurait raison que 50 fois serait extrêmement confiant. C’est bien en dehors de la plage d’erreur attendue.
- Remarque : Des statistiques ou une simulation peuvent démontrer que la probabilité d'obtenir seulement 50 bonnes réponses si le modèle prétend qu'il est sûr à 80 % est proche de 0,00 % ! Ce n’est pas impossible, mais si cela se produit dans un scénario de production, le modèle est clairement non calibré et très confiant.
- Un modèle qui répondrait à 100 questions avec un score de confiance de 80 % et qui aurait raison 90 fois serait peu confiant. Cela se situe en dehors de la plage d’erreur attendue.
- Remarque : Des statistiques ou une simulation peuvent démontrer qu'un modèle fiable à 80 %, mais en réalité correct plus de 90 fois, ne se produirait que 0,00233 (0,233 %) du temps.
Simulation statistique Affichage de 10 000 000 de simulations et des plages attendues pour 100 questions Calibrage à 80 % :
Ces techniques d'étalonnage s'appliquent à des scénarios du monde réel. Prenons l’exemple de Mainifold Markets (https://manifold.markets/), où les super prévisionnistes humains parient sur la probabilité d’événements. La sagesse collective de ces super prévisionnistes humains est hautement calibrée pour prédire les événements du monde réel !
Exemple d'étalonnage dans un environnement de prévision réel à partir de Manifold Markets de milliers de prévisions :
Le sujet de l’étalonnage n’est pas nouveau et a été étudié en théorie de la décision et en apprentissage automatique. Vous pouvez appliquer à la fois des techniques d’intelligence décisionnelle (sciences cognitives) et d’apprentissage automatique pour calibrer davantage les performances du modèle.
- Calibrer Chat GPT pour son excès de confiance : https://hubbardresearch.com/chat-gpt-ai-calibration/
- Exemple de calibrage des prévisionnistes Manifold Markets : https://manifold.markets/calibration
- Calibrer un évaluateur basé sur LLM : https://arxiv.org/pdf/2309.13308.pdf