alpaca_eval
v0.6.5
Alpacaeval 2.0 avec des taux de victoires contrôlés par la longueur (papier) a une corrélation Spearman de 0,98 avec Chatbot Arena tout en coûtant moins de 10 $ de crédits Openai et en cours d'exécution en moins de 3 minutes. Notre objectif est d'avoir une référence pour le CHAT LLMS, c'est-à-dire: rapide (<5min), bon marché (<10 $) et fortement corrélé avec les humains (0,98). Voici une comparaison avec d'autres repères:
Mises à jour:
? Les taux de victoire contrôlés par la longueur sont sortis et utilisés par défaut! Cela augmente la corrélation avec l'aréna de chatbot de 0,93 à 0,98, tout en diminuant considérablement le jeu de longueur. Les taux de victoire bruts sont toujours affichés sur le site Web et la CLI. Plus de détails ici.
? Alpacaeval 2.0 est sorti et utilisé par défaut! Nous avons amélioré l'auto-annotateur (meilleur et moins cher) et utilisons l'aperçu GPT-4 comme base. Plus de détails ici. Pour l'ancienne version, définissez votre variable d'environnement IS_ALPACA_EVAL_2=False .
L'évaluation des modèles de suivi des instructions (par exemple, Chatgpt) nécessite généralement des interactions humaines. Cela prend du temps, cher et difficile à reproduire. Alpacaval dans une évaluation automatique basée sur LLM qui est rapide, bon marché, reproductible et validée contre 20 000 annotations humaines. Il est particulièrement utile pour le développement du modèle. Bien que nous nous soyons améliorés par rapport aux pipelines d'évaluation automatiques antérieures, il existe toujours des limitations fondamentales comme la préférence pour les sorties plus longues. Alpacaeval fournit les éléments suivants:
Quand utiliser alpacaeval? Notre évaluateur automatique est un proxy rapide et bon marché pour l'évaluation humaine des tâches simples de suivi des instructions. Il est utile si vous devez exécuter de nombreuses évaluations rapidement, par exemple, pendant le développement du modèle.
Quand ne pas utiliser d'alpacaval? Comme tout autre évaluateur automatique, Alpacaeval ne devrait pas remplacer l'évaluation humaine dans la prise de décision à haut débit , par exemple, pour décider de la libération du modèle. En particulier, l'alpacaval est limité par le fait que (1) les instructions de l'ensemble d'évaluation pourraient ne pas être représentatives de l'utilisation avancée de LLMS; (2) les évaluateurs automatiques peuvent avoir des biais tels que la faveur du style à la factualité de la réponse; et (3) l'alpacaval ne mesure pas les risques qu'un modèle pourrait provoquer. Détails dans les limitations.
Pour installer la version stable, exécutez
pip install alpaca-evalPour installer la version nocturne, exécutez
pip install git+https://github.com/tatsu-lab/alpaca_evalEnsuite, vous pouvez l'utiliser comme suit:
export OPENAI_API_KEY= < your_api_key > # for more complex configs, e.g. using Azure or switching clients see client_configs/README.md
alpaca_eval --model_outputs ' example/outputs.json ' Cela imprimera le classement à la console et enregistrera à la fois le classement et les annotations au même répertoire que le fichier model_outputs . Les paramètres importants sont les suivants:
instruction et output des touches.weighted_alpaca_eval_gpt4_turbo (par défaut pour Alpacaeval 2.0), qui a un taux d'accord élevé avec nos données d'annotation humaine, une grande taille de contexte et est assez bon marché. Pour une comparaison de tous les annotateurs, voir ici.model_outputs . Par défaut, il s'agit gpt4_turbo pour Alpacaeval 2.0. Si vous n'avez pas les sorties du modèle, vous pouvez utiliser evaluate_from_model et passer un chemin local ou un nom de modèle de câlins ou un modèle à partir d'une API standard (Openai, anthropic, cohere, google, ...). Autres commandes:
>>> alpaca_eval -- --help SYNOPSIS
alpaca_eval COMMAND
COMMANDS
COMMAND is one of the following:
evaluate
Evaluate a model based on its outputs. This is the default entrypoint if no command is specified.
evaluate_from_model
Evaluate a model from HuggingFace or an API provider. This is a wrapper around `evaluate` which includes generating from a desired model.
make_leaderboard
Precompute and save an entire leaderboard for a given dataset / evaluator / set of models generations.
analyze_evaluators
Analyze an evaluator and populates the evaluators leaderboard (agreement with human, speed, price,...).
Pour plus d'informations sur chaque fonction, utilisez alpaca_eval <command> -- --help .
Nos classements sont calculés sur l'ensemble de données alpacaval. Nous avons précomposé le classement pour des modèles importants en utilisant différents modèles de base et autoannotateurs. Nos deux classements principaux ("Alpacaeval 2.0" et "Alpacaeval") se trouvent sur cette page. "Alpacaeval 2.0" utilise weighted_alpaca_eval_gpt4_turbo pour l'annotateur et gpt4_turbo pour la ligne de base. "Alpacaeval" utilise alpaca_eval_gpt4 pour l'annotateur et text_davinci_003 pour la ligne de base. Pour tous les classements pré-calmés, voyez ici. Plus tard, nous montrons également comment ajouter votre modèle au classement et comment créer un nouveau classement pour votre évaluateur / ensemble de données. Voir ici pour les configurations de tous les modèles disponibles hors de la boîte.
Alpacaeval Minimal Cleader :
| Taux de victoire | Erreur des std | |
|---|---|---|
| gpt4 | 95.3 | 0.7 |
| claude | 88.4 | 1.1 |
| chatte | 86.1 | 1.2 |
| guanaco-65b | 71.8 | 1.6 |
| vicuna-13b | 70.4 | 1.6 |
| text_davinci_003 | 50.0 | 0.0 |
| alpaga-farm-appo-humain | 41.2 | 1.7 |
| alpaca-7b | 26.5 | 1.5 |
| text_davinci_001 | 15.2 | 1.2 |
Taux de victoire : le taux de victoire mesure la fraction du temps que la sortie du modèle est préférée aux sorties de la référence ( test-davinci-003 pour Alpacaeval et gpt4_turbo pour Alpacaeval 2.0). Plus précisément, pour calculer le taux de victoire, nous collectons des paires de sorties du modèle souhaité sur chaque instruction de l'ensemble de données Apacaeval. Nous assocons ensuite chaque sortie avec la sortie de notre modèle de référence (par exemple, text-davinci-003 ) sur la même instruction. Nous demandons ensuite à notre évaluateur automatique quelle sortie ils préfèrent. Voir les invites et les configurations d'Alpacaeval et Alpacaeval 2.0, en particulier, nous randomions l'ordre des sorties pour éviter le biais de position. Nous en moyenne les préférences sur toutes les instructions de l'ensemble de données pour obtenir le taux de victoire du modèle par rapport à la ligne de base. Si les deux sorties sont exactement les mêmes, nous utilisons une demi-préférence pour les deux modèles.
Erreur standard : il s'agit de l'erreur standard (normalisée par N-1) du taux de victoire, c'est-à-dire les préférences en moyenne sur les différentes instructions.
alpaca_eval_gpt4 Notre annotateur alpaca_eval_gpt4 (voir configs) fait des moyennes sur les préférences, où les préférences sont obtenues comme suit:
temperature=0L'annotateur est un mélange entre (et a été fortement influencé par) les évaluateurs de l'alpacafarm et de la volière. En particulier, nous utilisons le même code que pour l'alpacafarm (mise en cache / randomisation / hyperparamètres) mais utilisons une invite de classement similaire à celle de la volière. Nous apportons les modifications de l'invite de la volière pour diminuer le biais des sorties plus longues. Détails dans les travaux connexes.
Pour Alpacaeval 2.0, nous utilisons weighted_alpaca_eval_gpt4_turbo , qui utilise des logprobs pour calculer la préférence continue et utilise gpt4_turbo comme modèle (voir configs).
Nous évaluons différents annotateurs automatiques sur l'ensemble alpacaval en comparant à 2,5k d'annotations humaines que nous avons collectées (~ 650 instructions chacune avec 4 annotations humaines). Below we show metrics for our suggested evaluators ( weighted_alpaca_eval_gpt4_turbo , alpaca_eval_gpt4 ), for prior automatic evaluators ( alpaca_farm_greedy_gpt4 , aviary_gpt4 , lmsys_gpt4 ), for humans ( humans ), and for different base models with essentially the same prompt ( gpt4 , claude , text_davinci_003 , chatgpt_fn , guanaco_33b , chatgpt ). Voir ici pour les configurations de tous les évaluateurs qui sont disponibles hors de la boîte et leurs mesures associées.
| Accord humain | Prix [$ / 1000 exemples] | Temps [secondes / 1000 exemples] | Spearman Corr. | Pearson Corr. | Biais | Variance | Proba. préférer plus longtemps | |
|---|---|---|---|---|---|---|---|---|
| alpaca_eval_gpt4 | 69.2 | 13.6 | 1455 | 0,97 | 0,93 | 28.4 | 14.6 | 0,68 |
| alpaca_eval_cot_gpt4_turbo_fn | 68.6 | 6.3 | 1989 | 0,97 | 0,90 | 29.3 | 18.4 | 0,67 |
| alpaca_eval_gpt4_turbo_fn | 68.1 | 5.5 | 864 | 0,93 | 0,82 | 30.2 | 15.6 | 0,65 |
| alpaca_eval_llama3_70b_fn | 67.5 | 0.4 | 209 | 0,90 | 0,86 | 32.3 | 8.2 | 0,79 |
| gpt4 | 66.9 | 12.5 | 1037 | 0,88 | 0,87 | 31.5 | 14.6 | 0,65 |
| alpaca_farm_greedy_gpt4 | 66.4 | 15.3 | 878 | 0,85 | 0,75 | 30.2 | 19.3 | 0,60 |
| alpaca_eval_cot_gpt4_turbo_fn | 65.7 | 4.3 | 228 | 0,78 | 0,77 | 33.9 | 23.7 | 0,61 |
| humains | 65.7 | 300.0 | 36800 | 1,00 | 1,00 | 0.0 | 34.3 | 0,64 |
| claude | 65.3 | 3.3 | 173 | 0,93 | 0,90 | 32.4 | 18.5 | 0,66 |
| LMSYS_GPT4 | 65.3 | 13.9 | 17982 | 0,98 | 0,97 | 31.6 | 15.9 | 0,74 |
| text_davinci_003 | 64.1 | 8.7 | 121 | 0,85 | 0,83 | 33.8 | 22.7 | 0,70 |
| le plus long | 62.2 | 0.0 | 0 | 0,27 | 0,56 | 37.8 | 0.0 | 1,00 |
| chatte | 57.3 | 0.8 | 285 | 0,72 | 0,71 | 39.4 | 34.1 | 0,59 |
Nous expliquons maintenant en mots comment nous calculons les mesures du tableau ci-dessus. Le code est ici.
Accord humain : Cela mesure l'accord entre l'annotateur actuel et les préférences majoritaires des humains sur nos ~ 650 annotations de notre ensemble de l'annotation croisée, qui contient 4 annotations humaines par exemple. Pour estimer l'accord entre un seul humain ( humans Row dans le tableau ci-dessus) et la majorité des humains, nous prenons l'une des 4 annotations et calculons la précision qu'elle a lors de la prévision du mode des 3 autres annotations. Nous en moyenne cette précision sur les 4 annotations et sur les 650 instructions pour obtenir l'accord humain, c'est-à-dire que nous calculons l'accord attendu (sur les humains et les échantillons). Si le mode n'est pas unique, nous prenons l'un des modes au hasard. Nous effectuons exactement le même calcul pour les annotateurs automatiques, afin que les nombres finaux soient comparables.
Prix [$ / 1000 Exemples] : Il s'agit du prix moyen de chaque 1000 annotations. Pour les humains, c'est le prix que nous avons payé les turcs mécaniques pour collecter ces annotations (21 $ / heure). Si le prix dépend de la machine utilisée pour calculer les annotations (par exemple Guanaco), nous la laissons vide.
Temps [secondes / 1000 exemples] : C'est le temps moyen nécessaire pour calculer 1000 annotations. Pour l'homme, c'est le temps médian estimé que chaque turker mécanique a pris pour annoter 1000 exemples. Pour les annotateurs automatiques, c'est le temps moyen qu'il nous a fallu lors de l'exécution des annotations. Notez que cela peut dépendre des limites d'API différentes pour différents utilisateurs et du nombre de demandes que les clusters traitent.
Spearman Corr. : Cela mesure la corrélation de Spearman entre un classement calculé avec la préférence de l'auto-annotateur et le classement calculé avec les préférences humaines. Comme pour Human agreement , nous utilisons les annotations humaines de l'alpacafarm, mais nous considérons maintenant l'accord au niveau de la méthode plutôt que uniquement l'accord par échantillon avec les humains. Notez que nous n'utilisons que des modèles 9 et que la corrélation n'est donc pas très fiable.
Pearson Corr. : Identique à Spearman corr. mais avec la corrélation de Pearson.
Biais : accord entre l'étiquette humaine la plus probable et la plus probable automatique. Pour les annotateurs automatiques, nous l'estimons en échantillonnant 4 annotations différentes pour chaque exemple. L'aléatoire ici vient de l'ordre des sorties dans l'invite, échantillonnant de la LLM, et le cas échéant, l'ordre de l'instruction dans le lot et le choix de l'annotateur dans la piscine. Nous prenons ensuite le mode des 4 annotations et calculons la précision du mode lors de la prévision du mode des 4 annotations humaines. Notez que cela est probablement une surestimation sur le vrai biais que nous obtiendrions si nous avions un nombre "infini" d'anannations croisées. Un faible biais signifie que l'annotateur a en attente les mêmes préférences que les humains. Pour le cas des humains, le biais est zéro par définition. Notez que cela est lié, mais pas le biais statistique standard, car nous prenons le mode au lieu des annotations moyennes et nous considérons une perte de 0-1 au lieu d'une perte au carré.
Variance : accord attendu une seule préférence automatique et la plus probable. Nous l'estimons de la même manière que nous avons estimé «l'accord humain» pour les humains, c'est-à-dire que nous prenons l'erreur de congé attendu lors de la prévision du mode des 3 annotations en utilisant la 4e annotation. Une faible variance signifie que l'annotateur est cohérent avec sa préférence, c'est-à-dire que si vous en échantillons avec des graines différentes, elle donnera le même résultat. Comme pour le biais, ce n'est pas exactement la variance statistique standard, car nous prenons le mode au lieu de la moyenne sur les annotations et nous considérons une perte de 0-1 au lieu d'une perte au carré.
Notez que «l'accord humain» est étroitement lié au biais et à la variance. En particulier, la variance mesure l'erreur due au fait que nous n'utilisons qu'une seule annotation tandis que le biais vise à mesurer l'erreur irréductible pour l'annotateur actuel.
Proba. Préférer plus longtemps : c'est la probabilité que l'annotateur préfère la sortie plus longue lorsque l'une des deux sorties est significativement plus longue que l'autre (différence de plus de 30 caractères).
Dans le tableau complet, nous fournissons également les mesures suivantes:
Proba. Préférer les listes : c'est la probabilité que l'annotateur préfère la sortie qui contient une liste / des puces lorsqu'une sortie le fait mais pas l'autre.
Proba. Préférer 1 : c'est la probabilité que l'annotateur préfère la première de la paire de sorties. Tous nos annotateurs proposés randomisent sur les sorties dans l'invite, donc cela devrait être de 0,5. Les annotateurs antérieurs, tels que lmsys et aviary , ne le font pas.
# Annué : Ceci est le nombre d'exemples que l'annotateur a pu analyser.
Notez que si la variance et le biais sont vides, cela signifie que nous avons effectué une seule annotation pour chaque exemple de 648 en raison des contraintes de ressources (temps et prix). Cela explique pourquoi le #Parsed est 648, sinon il devrait être 2592.
Dans l'ensemble, nous vous recommandons d'utiliser annotators_config=weighted_alpaca_eval_gpt4_turbo si vous voulez un accord élevé avec les humains, et annotators_config=chatgpt_fn si vous êtes sur un budget serré.
Lors du choix d'un annotateur, nous vous recommandons de considérer les éléments suivants (les trois premiers sont évidents):
"Human agreement [%]""Price [$/1000 examples]""Time [seconds/1000 examples]""* corr." Env. > 0,7. Il est important que la corrélation ne soit pas trop faible, mais nous ne recommandons pas de l'utiliser comme métrique principale car la corrélation est calculée sur seulement 9 modèles."Proba. prefer longer" environ. <0,7. En effet, nous avons constaté que la majorité de la préférence des annotateurs humains a un biais fort pour des réponses plus longues (comme le montrent la performance élevée = 62,2 de l'évaluateur "longest" qui préfère toujours la sortie la plus longue). Cela suggère que cela pourrait plus un biais avec les annotateurs humains. Afin d'éviter d'avoir des classements avec de forts biais pour la longueur, nous suggérons d'utiliser des annotateurs automatiques avec moins de 0,7 "Proba. Préférer plus longtemps"."Variance" environ. <0,2. Nous pensons qu'un bon évaluateur devrait avoir le moins de variance possible afin que les résultats soient principalement reproductibles. Notez que la variance peut être souhaitable dans le cas où nous simulons les humains comme indiqué dans l'alpacafarm. Nous avons filtré les annotateurs qui ne satisfont pas à ces exigences dans le tableau ci-dessus (en plus des humains / chatgpt / 003 / lmsys à des fins de référence). Pour tous les résultats, voir ici. En général, nous avons trouvé weighted_alpaca_eval_gpt4_turbo comme un bon compromis entre le biais de qualité / prix / temps / variance / longueur.
Les métriques ci-dessus sont calculées en ce qui concerne les annotations de la foule. Bien que utiles, ces annotations ne sont pas parfaites, par exemple, les fouleurs favorisent souvent le style à la factualité. Nous recommandons donc aux utilisateurs de valider les évaluateurs automatiques sur leurs propres instructions et annotations humaines. Détails dans les limitations.
>>> alpaca_eval evaluate -- --help NAME
alpaca_eval evaluate - Evaluate a model based on its outputs. This is the default entrypoint if no command is specified.
SYNOPSIS
alpaca_eval evaluate <flags>
DESCRIPTION
Evaluate a model based on its outputs. This is the default entrypoint if no command is specified.
FLAGS
--model_outputs=MODEL_OUTPUTS
Type: Optional[Union]
Default: None
The outputs of the model to add to the leaderboard. Accepts data (list of dictionary, pd.dataframe, datasets.Dataset) or a path to read those (json, csv, tsv) or a function to generate those. Each dictionary (or row of dataframe) should contain the keys that are formatted in the prompts. E.g. by default `instruction` and `output` with optional `input`. If None, we just print the leaderboard.
-r, --reference_outputs=REFERENCE_OUTPUTS
Type: Union
Default: <func...
The outputs of the reference model. Same format as `model_outputs`. If None, the reference outputs are a specific set of Davinci 003 outputs on the AlpacaEval set:
--annotators_config=ANNOTATORS_CONFIG
Type: Union
Default: 'alpaca_eval_gpt4_turbo_fn'
The path the (or list of dict of) the annotator's config file. For details see the docstring of `PairwiseAnnotator`.
-n, --name=NAME
Type: Optional[Optional]
Default: None
The name of the model to add to the leaderboard. If None we check if `generator is in model_outputs` if not we use "Current model".
-o, --output_path=OUTPUT_PATH
Type: Union
Default: 'auto'
Path to the directory where the new leaderboard and the annotations should be stored. If None we don't save. If `auto` we use `model_outputs` if it is a path, and otherwise use the directory from which we call the script.
-p, --precomputed_leaderboard=PRECOMPUTED_LEADERBOARD
Type: Union
Default: 'auto'
The precomputed leaderboard or a path to it (json, csv, or tsv). The leaderboard should contain at least the column `win_rate`. If `auto` we will try to use the corresponding leaderboard for the reference outputs (only if in CORRESPONDING_OUTPUTS_LEADERBOARDS). If `None` we won't add other models from the leaderboard.
--is_overwrite_leaderboard=IS_OVERWRITE_LEADERBOARD
Type: bool
Default: False
Whether to overwrite the leaderboard if the model is already in it.
-l, --leaderboard_mode_to_print=LEADERBOARD_MODE_TO_PRINT
Type: Optional
Default: 'minimal'
The mode of the leaderboard to use. Only used if the precomputed leaderboard has a column `mode`, in which case it will filter the leaderboard by this mode. If None keeps all.
-c, --current_leaderboard_mode=CURRENT_LEADERBOARD_MODE
Type: str
Default: 'community'
The mode of the leaderboard for the current method.
--is_return_instead_of_print=IS_RETURN_INSTEAD_OF_PRINT
Type: bool
Default: False
Whether to return the metrics instead of printing the results.
-f, --fn_metric=FN_METRIC
Type: Union
Default: 'pairwise_to_winrate'
The function or function name in `metrics.py` that will be used to convert preference to metrics. The function should take a sequence of preferences (0 for draw, 1 for base win, 2 when the model to compare wins) and return a dictionary of metrics and the key by which to sort the leaderboard.
-s, --sort_by=SORT_BY
Type: str
Default: 'win_rate'
The key by which to sort the leaderboard.
--is_cache_leaderboard=IS_CACHE_LEADERBOARD
Type: Optional[Optional]
Default: None
Whether to save the result leaderboard to `precomputed_leaderboard`. If None we save only if max_instances not None. A preferred way of adding models to the leaderboard is to set `precomputed_leaderboard` to the previously saved leaderboard at `<output_path>/leaderboard.csv`.
--max_instances=MAX_INSTANCES
Type: Optional[Optional]
Default: None
The maximum number of instances to annotate. Useful for testing.
--annotation_kwargs=ANNOTATION_KWARGS
Type: Optional[Optional]
Default: None
Additional arguments to pass to `PairwiseAnnotator.annotate_head2head`.
-A, --Annotator=ANNOTATOR
Default: <class 'alpaca_eval.annotators.pairwise_evaluator.PairwiseAn...
The annotator class to use.
Additional flags are accepted.
Additional arguments to pass to `PairwiseAnnotator`.
>>> alpaca_eval evaluate_from_model -- --help NAME
alpaca_eval evaluate_from_model - Evaluate a model from HuggingFace or an API provider. This is a wrapper around `evaluate` which includes generating from a desired model.
SYNOPSIS
alpaca_eval evaluate_from_model MODEL_CONFIGS <flags>
DESCRIPTION
Evaluate a model from HuggingFace or an API provider. This is a wrapper around `evaluate` which includes generating from a desired model.
POSITIONAL ARGUMENTS
MODEL_CONFIGS
Type: Union
A dictionary or path (relative to `models_configs`) to a yaml file containing the configuration of the model to decode from. If a directory,we search for 'configs.yaml' in it. The keys in the first dictionary should be the generator's name, and the value should be a dictionary of the generator's configuration which should have the
FLAGS
-r, --reference_model_configs=REFERENCE_MODEL_CONFIGS
Type: Optional[Union]
Default: None
Same as in `model_configs` but for the reference model. If None, we use the default Davinci003 outputs.
-e, --evaluation_dataset=EVALUATION_DATASET
Type: Union
Default: <func...
Path to the evaluation dataset or a function that returns a dataframe. If None, we use the default evaluation
-a, --annotators_config=ANNOTATORS_CONFIG
Type: Union
Default: 'alpaca_eval_gpt4_turbo_fn'
Path to the annotators configuration or a dictionary. If None, we use the default annotators configuration.
-o, --output_path=OUTPUT_PATH
Type: Union
Default: 'auto'
Path to save the generations, annotations and leaderboard. If auto saves at `results/<model_name>`
-m, --max_instances=MAX_INSTANCES
Type: Optional[int]
Default: None
Maximum number of instances to generate and evaluate. If None, we evaluate all instances.
--is_strip_output=IS_STRIP_OUTPUT
Type: bool
Default: True
Whether to strip trailing and leading whitespaces from the outputs.
--is_load_outputs=IS_LOAD_OUTPUTS
Type: bool
Default: True
Whether to try to load outputs from the output path. If True and outputs exist we only generate outputs for instructions that don't have outputs yet.
-c, --chunksize=CHUNKSIZE
Type: int
Default: 64
Number of instances to generate before saving. If None, we save after all generations.
Additional flags are accepted.
Other kwargs to `evaluate`
NOTES
You can also use flags syntax for POSITIONAL ARGUMENTS
Pour évaluer un modèle dont vous avez besoin:
model_outputs . Par défaut, nous utilisons les exemples 805 d'Alpacaeval. Pour calculer les sorties sur une utilisation alpacée: import datasets
eval_set = datasets . load_dataset ( "tatsu-lab/alpaca_eval" , "alpaca_eval" )[ "eval" ]
for example in eval_set :
# generate here is a placeholder for your models generations
example [ "output" ] = generate ( example [ "instruction" ])
example [ "generator" ] = "my_model" # name of your model Si votre modèle est un modèle HuggingFace ou à partir d'un fournisseur API standard (Openai, anthropic, cohere). Ensuite, vous pouvez utiliser directement alpaca_eval evaluate_from_model pour s'occuper également de générer des sorties.
reference_outputs . Par défaut, nous utilisons des sorties précomputées de gpt4_turbo sur Alpacaeval. Si vous souhaitez utiliser un modèle différent ou un ensemble de données différent, suivez les mêmes étapes que (1.).annotators_config . Nous vous recommandons d'utiliser alpaca_eval_gpt4_turbo_fn . Pour d'autres options et comparaisons, consultez ce tableau. Selon l'évaluateur, vous devrez peut-être définir l'API_KEY approprié dans votre environnement ou int le client_configs.Courir tous ensemble:
alpaca_eval --model_outputs ' example/outputs.json '
--annotators_config ' alpaca_eval_gpt4_turbo_fn ' Si vous n'avez pas de sorties décodées, vous pouvez utiliser evaluate_from_model qui prend en charge le décodage (modèle et référence) pour vous. Voici un exemple:
# need a GPU for local models
alpaca_eval evaluate_from_model
--model_configs ' oasst_pythia_12b '
--annotators_config ' alpaca_eval_gpt4_turbo_fn ' Ici, les model_configs et reference_model_configs (facultatif) sont des chemins vers un répertoire qui spécifie l'invite, le fournisseur de modèle (ici HuggingFace) et les paramètres de décodage. Voir ce répertoire pour des exemples. Pour tous les fournisseurs de modèles disponibles prêts à l'emploi ici.
caching_path . Les annotations ne sont donc jamais recalculées, ce qui rend les annotations plus rapides, moins chères et permettent de reproductibilité. Cela aide même lors de l'évaluation de différents modèles car de nombreux modèles ont les mêmes sorties.>>> alpaca_eval make_leaderboard -- --help NAME
alpaca_eval make_leaderboard - Precompute and save an entire leaderboard for a given dataset / evaluator / set of models generations.
SYNOPSIS
alpaca_eval make_leaderboard <flags>
DESCRIPTION
Precompute and save an entire leaderboard for a given dataset / evaluator / set of models generations.
FLAGS
--leaderboard_path=LEADERBOARD_PATH
Type: Optional[Union]
Default: None
The path to save the leaderboard to. The leaderboard will be saved as a csv file, if it already exists it will
--annotators_config=ANNOTATORS_CONFIG
Type: Union
Default: 'alpaca_eval_gpt4_turbo_fn'
The path the (or list of dict of) the annotator's config file.
--all_model_outputs=ALL_MODEL_OUTPUTS
Type: Union
Default: <fu...
The outputs of all models to add to the leaderboard. Accepts data (list of dictionary, pd.dataframe, datasets.Dataset) or a path to read those (json, csv, tsv potentially with globbing) or a function to generate those. If the path contains a globbing pattern, we will read all files matching the pattern and concatenate them. Each dictionary (or row of dataframe) should contain the keys that are formatted in the prompts. E.g. by default `instruction` and `output` with optional `input`. It should also contain a column `generator` with the name of the current model.
-r, --reference_outputs=REFERENCE_OUTPUTS
Type: Union
Default: <func...
The outputs of the reference model. Same format as `all_model_outputs` but without needing `generator`. By default, the reference outputs are the 003 outputs on AlpacaEval set.
-f, --fn_add_to_leaderboard=FN_ADD_TO_LEADERBOARD
Type: Callable
Default: 'evaluate'
The function to use to add a model to the leaderboard. If a string, it should be the name of a function in `main.py`. The function should take the arguments: `model_outputs`, `annotators_config`, `name`, `precomputed_leaderboard`, `is_return_instead_of_print`, `reference_outputs`.
--leaderboard_mode=LEADERBOARD_MODE
Type: str
Default: 'verified'
The mode of the leaderboard to save all new entries with.
-i, --is_return_instead_of_print=IS_RETURN_INSTEAD_OF_PRINT
Type: bool
Default: False
Whether to return the metrics instead of printing the results.
Additional flags are accepted.
Additional arguments to pass to `fn_add_to_leaderboard`.
Si vous souhaitez faire un nouveau classement en utilisant une seule commande (plutôt que plusieurs appels alpaca_eval ), pour votre ensemble d'évaluation et les évaluateurs souhaités, vous pouvez utiliser ce qui suit:
alpaca_eval make_leaderboard
--leaderboard_path < path_to_save_leaderboard >
--all_model_outputs < model_outputs_path >
--reference_outputs < reference_outputs_path >
--annotators_config < path_to_config.yaml >où:
leaderboard_path : Chemin pour sauver le classement. Le classement sera enregistré en tant que fichier CSV, s'il existe déjà, il ajoutera.all_model_outputs : le chemin JSON vers les sorties de tous les modèles à ajouter au classement (en tant que fichier unique ou par plusieurs fichiers globbing). Chaque dictionnaire doit contenir les touches ( instruction et output ) qui sont formatées dans les invites et un generator de colonnes avec le nom du modèle actuel. À titre d'exemple, voir ce fichier.reference_outputs le chemin vers les sorties du modèle de référence. Chaque dictionnaire doit contenir les touches ( instruction et output ) qui sont formatées dans les invites. Par défaut, les sorties de référence sont les sorties 003 sur le jeu alpacaval.annotators_config : le chemin d'accès au fichier de configuration de l'annotateur. Par défaut est alpaca_eval_gpt4 . >>> alpaca_eval analyze_evaluators -- --help NAME
alpaca_eval analyze_evaluators - Analyze an evaluator and populates the evaluators leaderboard (agreement with human, speed, price,...).
SYNOPSIS
alpaca_eval analyze_evaluators <flags>
DESCRIPTION
Analyze an evaluator and populates the evaluators leaderboard (agreement with human, speed, price,...).
FLAGS
--annotators_config=ANNOTATORS_CONFIG
Type: Union
Default: 'alpaca_eval_gpt4_turbo_fn'
The path the (or list of dict of) the annotator's config file.
-A, --Annotator=ANNOTATOR
Default: <class 'alpaca_eval.annotators.pairwise_evaluator.PairwiseAn...
The annotator class to use.
--analyzer_kwargs=ANALYZER_KWARGS
Type: Optional[Optional]
Default: None
Additional arguments to pass to the analyzer.
-p, --precomputed_leaderboard=PRECOMPUTED_LEADERBOARD
Type: Union
Default: PosixPath('/Users/yanndubois/Desktop/GitHub/alpaca_eval/src/...
The precomputed (meta)leaderboard of annotators or a path to it (json, csv, or tsv).
--is_save_leaderboard=IS_SAVE_LEADERBOARD
Type: bool
Default: False
Whether to save the leaderboard (ie analyzed results).
--is_return_instead_of_print=IS_RETURN_INSTEAD_OF_PRINT
Type: bool
Default: False
Whether to return the leaderboard (ie analyzed results). If True, it will not print the results.
--is_overwrite_leaderboard=IS_OVERWRITE_LEADERBOARD
Type: bool
Default: False
Whether to overwrite the leaderboard if it already exists.
-m, --max_instances=MAX_INSTANCES
Type: Optional[Optional]
Default: None
The maximum number of instances to analyze.
--is_single_annotator=IS_SINGLE_ANNOTATOR
Type: bool
Default: False
Whether to analyze a single annotator. If True, will not be able to estimate the annotator's bias.
-l, --leaderboard_mode_to_print=LEADERBOARD_MODE_TO_PRINT
Type: str
Default: 'minimal'
The mode of the leaderboard to print.
-c, --current_leaderboard_mode=CURRENT_LEADERBOARD_MODE
Type: str
Default: 'minimal'
The mode of the leaderboard to save all new entries with.
-o, --output_path=OUTPUT_PATH
Type: Union
Default: 'auto'
Path to save the leaderboard and annotataions. If None, we don't save.
Additional flags are accepted.
Additional arguments to pass to `Annotator`.
Alpacaeval fournit un moyen simple de faire de nouveaux évaluateurs. Tout ce dont vous avez besoin est de créer un nouveau fichier de configuration configs.yaml , que vous passerez ensuite en --annotators_config <path_to_config.yaml> à alpaca_eval . Voici quelques façons de créer un nouvel évaluateur:
prompt_template du fichier de configuration. Les chemins sont relatifs au fichier de configuration.completions_kwargs dans le fichier de configuration. Pour voir tous les paramètres disponibles, reportez-vous aux docstrings de la fonction correspondante dans ce fichier spécifié par fn_completions dans le fichier de configuration.model_name et l'invite correspondante dans prompt_template . Si le modèle provient d'un autre fournisseur, vous devrez modifier fn_completions qui mappe à la fonction correspondante dans ce fichier. Nous fournissons des fonctions fn_completions pour utiliser des modèles d'Openai, Anthropic, Cohere ou HuggingFace. Pour installer les packages nécessaires pour tous les fournisseurs, utilisez pip install alpaca_eval[all] . Le plus simple est de vérifier les docstrings de SinglePairwiseAnnotator . Voici quelques importants:
Parameters
----------
prompt_template : path
A prompt that will be given to `fn_prompter` or path to the prompts. Path is relative to
`evaluators_configs/`
fn_completion_parser : callable or str
Function in `completion_parsers.py` to use for parsing the completions into preferences. For each completion,
the number of preferences should be equal to the batch_size if not we set all the preferences in that batch to
NaN.
completion_parser_kwargs : dict
Kwargs for fn_completion_parser.
fn_completions : callable or str
Function in `decoders.py` to use for decoding the output.
completions_kwargs : dict
kwargs for fn_completions. E.g. model_name, max_tokens, temperature, top_p, top_k, stop_seq.
is_randomize_output_order : bool
Whether to randomize output_1, output_2 when formatting.
batch_size : int
Number of examples that will be added in a single prompt.
Une fois que vous avez fait l'évaluateur, vous pouvez également l'analyser et l'ajouter au classement de l'évaluateur à l'aide de la commande suivante:
alpaca_eval analyze_evaluators --annotators_config ' <path_to_config.yaml> ' Pour estimer le biais et la variance, cela évalue chaque exemple avec 4 graines, c'est-à-dire une évaluation 2,5k. Si vous voulez une évaluation moins chère, vous pouvez utiliser une seule graine en utilisant --is_single_annotator True qui sautera l'estimation du biais et de la variance.
Nous acceptons les PR pour les nouveaux modèles, évaluateurs et ensembles d'évaluation, en plus des corrections de bogues. Nous mettrons à jour le site Web de classement régulièrement avec de nouvelles contributions communautaires. Nous avons également créé une discorde de support pour Alpacaeval au cas où vous rencontreriez des problèmes et que vous souhaitiez demander de l'aide de la communauté.
Pour commencer, veuillez d'abord fourchez le dépôt et installez le package à partir de Source pip install -e .
Tout d'abord, vous devrez ajouter une définition de configuration de modèle dans le dossier Models_configs. À titre d'exemple, vous pouvez regarder le YAML Falcon-7B-Istruct. Veuillez vous assurer que le nom du dossier et le nom de la clé du YAML correspondent exactement.
Ensuite, veuillez suivre les étapes de l'évaluation d'un modèle pour exécuter l'inférence sur le modèle pour produire des sorties sur l'ensemble d'évaluation et marquer le modèle en fonction de l'un des évaluateurs. Un exemple de commande peut ressembler:
alpaca_eval evaluate_from_model
--model_configs ' falcon-7b-instruct 'Après avoir exécuté cette commande, vous devriez avoir généré un JSON de sortie et une nouvelle entrée dans le fichier de classement correspondant. Veuillez créer un PR avec la configuration, les sorties du fichier et le classement mis à jour.
Concrètement vous devriez faire quelque chose comme:
git clone <URL>src/alpaca_eval/models_configs/<model_name> et évaluez- evaluate_from_model --model_configs '<model_name>'git add src/alpaca_eval/models_configs/ < model_name > # add the model config
git add src/alpaca_eval/leaderboards/ # add the actual leaderboard entry
git add src/alpaca_eval/metrics/weights # add the weights for LC
git add -f results/ < model_name > /model_outputs.json # force add the outputs on the dataset
git add -f results/ < model_name > / * /annotations.json # force add the evaluations from the annotators
git commit -m " Add <model_name> to AlpacaEval "
git push Remarque: Si vous générez des sorties en dehors de l'alpacaeval, vous devez toujours ajouter une configuration de modèle mais avec fn_completions: null . Voir cette configuration pour un exemple.
Un résultat vérifié dans l'alpacaval indique qu'un mainteneur de base a décodé les sorties du modèle et effectué l'évaluation. Malheureusement, nous, les maintenneurs alpacaeval, n'avons pas les ressources pour vérifier tous les modèles et nous ne le ferons donc que pour les modèles qui figurent dans le top 5 du classement. Nous nous excusons pour tout inconvénient que cela peut provoquer et apprécier votre compréhension. Pour que votre modèle vérifie, veuillez suivre les étapes ci-dessous:
@yann sur Discord ou envoyez-nous un e-mail si vous avez notre e-mail, en fournissant une brève justification pour expliquer pourquoi votre modèle doit être vérifié.alpaca_eval evaluate_from_model --model_configs '<your_model_name>' sans nécessiter de GPU local.alpaca_eval evaluate_from_model --model_configs '<your_model_name>' , mettez à jour les résultats et vous informez afin que vous puissiez révoquer les touches temporaires.Notez que nous ne réévaluons pas le même modèle. En raison de la variance d'échantillonnage, les résultats peuvent être légèrement différés de vos premiers. Nous remplacerons vos résultats de la communauté précédents par ceux vérifiés.
Veuillez d'abord suivre les instructions pour créer un nouvel évaluateur. Une fois que vous avez créé la configuration de l'annotateur, nous vous demandons de créer un nouveau classement pour l'annotateur en évaluant l'ensemble minimal de modèles. Les sorties de ces modèles peuvent être trouvées en téléchargeant alpaca_eval_all_outputs.json.
alpaca_eval make_leaderboard
--leaderboard_path src/alpaca_eval/leaderboards/data_AlpacaEval/ < evaluator > _leaderboard.csv
--all_model_outputs alpaca_eval_all_outputs.json
--annotators_config < evaluator_config >Ensuite, veuillez créer un PR avec la configuration de l'annotateur et le CSV de classement.
Pour contribuer un nouvel ensemble d'évaluation, vous devrez d'abord spécifier un ensemble d'instructions textuelles. Ensuite, vous devrez spécifier un ensemble de sorties de référence (les taux gagnants du modèle sont calculés par rapport à cette référence). Pour plus de facilité d'utilisation, vous pouvez utiliser la configuration de référence par défaut Text-Davinci-003.
Placez-les ensemble dans un JSON, où chaque entrée spécifie l' instruction , output et generator des champs. Vous pouvez se tourner vers alpaca_eval.json comme guide (le champ dataset n'est pas nécessaire).
Enfin, nous vous demandons de créer un classement minimal sur ce nouvel ensemble d'évaluation. Vous pouvez le faire avec les éléments suivants:
alpaca_eval make_leaderboard
--leaderboard_path < src/alpaca_eval/leaderboards/data_AlpacaEval/your_leaderboard_name.csv >
--all_model_outputs alpaca_eval_all_outputs.json
--reference_outputs < path_to_json_file >Veuillez soumettre un PR avec l'évaluation JSON et CSV de classement correspondant.
Actuellement, nous permettons différentes fonctions d'achèvement, par exemple, openai , anthropic , huggingface_local , huggingface_hub_api ... Si vous souhaitez contribuer une nouvelle fonction d'achèvement / API avec laquelle effectuer l'inférence, suivez ces étapes:
<name>_completions(prompts : Sequence[str], model_name :str, ... ) dans le dossier du décodeur. Cette fonction doit prendre comme argument les invites + kwargs et renvoyer les compléments. Veuillez consulter d'autres fonctions d'achèvement dans le répertoire des modèles. EG HUGGINGFACE_LOCAL_COMPLETIONS ou anthropic.<name>_completions et dépendances dans init . Encore une fois, vous pouvez suivre l'exemple de HuggingFace_Local_Completionsalpaca_eval evaluate_from_model --model_configs '<model_configs>'N'hésitez pas à démarrer un RP tôt, nous serons en mesure de fournir une aide dans le processus!
Le pipeline d'évaluation alpacaval, comme les autres évaluateurs actuels, a des limites importantes et ne devrait donc pas être utilisé comme remplacement de l'évaluation humaine dans des contextes importants, par exemple pour décider si un modèle est prêt à être déployé. Ceux-ci peuvent largement être regroupés en 3 catégories:
Les instructions pourraient ne pas être représentatives de l'utilisation réel : l'ensemble alpacaval contient des exemples d'une variété de jeux de données (auto-instruments, à l'Open-Assistant, vicuna, koala, hh-rlhf) qui pourraient ne pas être représentatifs des applications réelles et avancées de meilleurs modèles comme GPT4. Cela rend probablement les meilleurs modèles fermés (GPT4 / Claude / Chatgpt / ...) semble plus similaire aux modèles ouverts que ce qu'ils sont. En effet, ces modèles fermés semblent être prédéfinie / finetunés sur des données beaucoup plus diverses. Voir par exemple ce blog pour les résultats préliminaires sur des instructions plus complexes. Notez cependant que dans l'alpacafarm, nous avons montré que les taux de victoires sur notre ensemble d'évaluation sont fortement corrélés (0,97 R2) avec des taux de victoires sur les instructions des interactions utilisateur avec la démo alpaca. De plus, le classement alpacaval montre un écart plus important entre les modèles ouverts et les modèles OpenAI que les autres classements (par exemple LMSYS).
Biais d'annotateurs automatiques : les annotateurs automatiques bruts semblent avoir des biais implicites. En particulier, nous avons constaté qu'ils ont tendance à préférer les sorties et les sorties plus longues qui contiennent des listes (par exemple 0,68 / 0,69 pour alpaca_eval_gpt4 et 0,62 / 0,58 pour claude ). Bien que nous ayons constaté que les humains ont des biais similaires (0,64 / 0,61), nous pensons que cela pourrait être plus une limitation du pipeline d'annotation humaine que nous avons utilisé plutôt qu'un véritable biais humain. Plus généralement, grâce à une analyse qualitative, nous avons constaté que les annotateurs automatiques accordent plus d'importance au style de la sortie que son contenu (par exemple, factualité). Enfin, nous avons constaté que les évaluateurs automatiques ont tendance à préférer les sorties de modèles similaires (probablement formés sur les mêmes données) que ceux suggérés par la grande différence entre ChatGpt / GPT4 sur claude 's et alpaca_eval_gpt4 . Notez que le biais de longueur est partiellement atténué dans nos taux de victoires contrôlés par la longueur.
Manque d'évaluation de la sécurité : surtout, l'alpacaval évalue uniquement les capacités de suivi des instructions des modèles plutôt que le préjudice qu'ils pourraient causer (par exemple, comportement ou biais toxique). En conséquence, le petit écart entre le chatppt actuel et les meilleurs modèles open source ne doit pas être interprété comme si ces derniers sont prêts à être déployés.
Au-delà de ces limites concernant les pipelines d'évaluation, il existe également des limites concernant notre validation des évaluateurs et notre approche proposée pour sélectionner des ensembles d'évaluation.
Premièrement, notre validation des évaluateurs basée sur des annotations croisées humaines souffre des limites suivantes: (1) Nous avons constaté qualitativement que nos travailleurs de la foule ont tendance à favoriser également le style tel que la longueur et la présence de listes sur la factualité; (2) Cela ne valide pas si les taux de victoire contre un modèle de référence sont une bonne stratégie d'évaluation en premier lieu; (3) Les préférences de 16 travailleurs de la foule ne sont pas représentatives des préférences de tous les humains.
Deuxièmement, notre approche suggérée pour sélectionner des ensembles d'évaluation basée sur la puissance statistique souffre des limites suivantes: (1) La puissance statistique ne garantit pas la bonne direction, par exemple, vous pouvez avoir un ensemble d'instructions non naturel où l'alpaga "fonctionne" mieux que de meilleur modèle; et (2) cela peut pousser les utilisateurs pour sélectionner des données pour soutenir l'hypothèse qu'ils souhaitent valider.
Visualisations alpacavals contrôlées par longueur:
Développement alpacaval à longueur contrôlée:
Le cahier affiche différentes options que nous avons considérées pour atténuer le biais de longueur des annotateurs automatiques.
Ici, nous résumons brièvement les principaux résultats. À savoir:
win_rate(m,b) = 1 - win_rate(b,m) in [0,1] and win_rate(m,m) = 0.5 . This is shown in the plot below. 
Finally, note that we are only controlling for length bias. There are other known biases that we are not controlling for, such as the fact that auto-annotators prefer outputs similar to their model. Although we could control for that, in practice we have found that to be less of an issue than length bias. For two reasons (1) this mostly a single model in the leaderboard because fine-tuning on outputs from the auto-annotator doesn't seem to have doesn't seem to impact the win-rate as much, and (2) the bias is actually less strong that what one could think. For example we show below a subset of the leaderboards auto-annotated by three different models, and we see that the ranking of models is exactly the same. In particular, claude-3-opus prefers gpt4_preview , and mistral-large prefers the former two.
Caution : all the following results are about AlpacaEval 1.0 and have not been updated since
Analyzing evaluators:
As we saw in the evaluator's leaderboard, there are many metrics to consider when selecting an evaluator, eg the quality, price, and speed. To assist with selection of the evaluator we provide a few functions to plot those metrics. The following shows for example the price/time/agreement of the different evaluators.
Here we see that alpaca_eval_gpt4 performs very well and is better than humans on all the considered metrics.
Previously we only considered the agreement with human annotators overall. An additional validation that one could do is checking whether making a leaderboard using our automatic annotator gives similar results as a leaderboard from humans. To enable such analysis, we release human annotations of outputs from 22 methods from AlpacaFarm => 22*805 = ~18K annotations. As a result we can test the correlation between the win-rates of the 22 models as evaluated by the humans and our automatic annotator. Note that this is arguably a better way of selecting an automatic evaluator than using "human agreement [%]" but is expensive given that it requires 18K annotations. The plot below shows such correlation for the alpaca_eval_gpt4 evaluator.
We see that the alpaca_eval_gpt4 leaderboard is highly correlated (0.94 Pearson correlation) to the leaderboard from humans, which further suggests that automatic evaluation is a good proxy for human evaluation. For the code and more analysis, see this notebook, or the colab notebook above.
Caution : all the following results are about AlpacaEval 1.0 and have not been updated since.
Making evaluation sets:
When creating an evaluation set there are two main factors to consider: how much data to use? and what data?
One way of answering those question is by considering a leaderboard of models that you believe are of different quality and checking what and how much data is needed to distinguish between them in a statistically significant way. We will do so below using a paired t-test to test if the difference in win-rates between every pair of models is statistically significant.
First, let us consider the question of how much data to use. Below we show the number of random samples needed from AlpacaEval for the paired t-test to give a p-value < 0.05 for each pair of models in the minimal alpaca_eval_gpt4 leaderboard. Grey cells correspond to pairs that are not significantly different on the 805 samples. y- and x-axis are ordered by the win-rate of the first and second model respectively.
We see that most models can already be distinguished with 50 samples, and that 150 samples allows distinguishing the majority of pairs (74 out of 78). This suggests that we can decrease the evaluation set size by a factor of 4 when testing two models that have similar performance gaps as those on the minimal alpaca_eval_gpt4 leaderboard.
The second question is what data to use. Again we can try to answer this question from a statistical power perspective: what data allows to best distinguish between models. Let's consider this for all the datasets that are part of AlpacaEval, but let us control for the size of the evaluation sets as we only care about the quality of the data. The following plot shows the p-values from the paired t-test of each pairs of models on 80 examples of each subset of AlpacaEval.
We see for example that the self-instruct dataset yields the least statistical power, which suggests that one could remove this dataset from the evaluation set. The exact reason should be analyzed in future work. For the code and more analysis see this notebook, or the colab notebook above.
Please consider citing the following depending on what you are using and referring to:
alpaca_eval (this repo). Specify whether you are using AlpacaEval or AlpacaEval 2.0. For length-controlled win-rates see below.alpaca_eval_length .dubois2023alpacafarm (AlpacaFarm)alpaca_eval and self-instruct, open-assistant, vicuna, koala, hh-rlhf.Here are the bibtex entries:
@misc{alpaca_eval,
author = {Xuechen Li and Tianyi Zhang and Yann Dubois and Rohan Taori and Ishaan Gulrajani and Carlos Guestrin and Percy Liang and Tatsunori B. Hashimoto },
title = {AlpacaEval: An Automatic Evaluator of Instruction-following Models},
year = {2023},
month = {5},
publisher = {GitHub},
journal = {GitHub repository},
howpublished = {url{https://github.com/tatsu-lab/alpaca_eval}}
}
@article{dubois2024length,
title={Length-Controlled AlpacaEval: A Simple Way to Debias Automatic Evaluators},
author={Dubois, Yann and Galambosi, Bal{'a}zs and Liang, Percy and Hashimoto, Tatsunori B},
journal={arXiv preprint arXiv:2404.04475},
year={2024}
}
@misc{dubois2023alpacafarm,
title={AlpacaFarm: A Simulation Framework for Methods that Learn from Human Feedback},
author={Yann Dubois and Xuechen Li and Rohan Taori and Tianyi Zhang and Ishaan Gulrajani and Jimmy Ba and Carlos Guestrin and Percy Liang and Tatsunori B. Hashimoto},
year={2023},
eprint={2305.14387},
archivePrefix={arXiv},
primaryClass={cs.LG}
}
Length controlled (LC) win-rates are a debiased version of the win-rates that control for the length of the outputs.
The main idea is that for each model we will fit a logistic regression to predict the preference of the autoannotator given: (1) the instruction, (2) the model, and (3) the difference of length between the baseline and model output. Given such a logistic regression we can then try to predict the counterfactual "what would the preference be if the model's output had the same length as the baseline" by setting the length difference to 0. By averaging over this length-controlled preference, we then obtain the length-controlled win-rate. The exact form of the logistic regression is taken such that the interpretation of LC win rates is similar to the raw win rates, for example for any model m1 and m2 we have win_rate(m1, m2) = 1 - win_rate(m2, m1) in [0,100] and win_rate(m1, m1) = 0.5 . Length controlled win-rates increase the correlation between AlpacaEval's leaderboard and Chat Arena from 0.93 to 0.98 Spearman correlation, while significantly decreasing the length gameability of the annotator . For more information and results about length controlled win-rates see this notebook.
This idea of estimating the controlled direct effect, by predicting the outcome while conditioning on the mediator (the length difference), is common in statistical inference.
To get LC win rates on previously annotated models, you can use the following command:
pip install -U alpaca_eval
alpaca_eval --model_outputs … --is_recompute_metrics_only TrueAlpacaEval 2.0 is a new version of AlpacaEval. Here are the differences:
gpt4_turbo : we upgraded the baseline from text-davinci-003 to gpt4_turbo to make the benchmark more challenging and have a metric that better reflects the current state of the art.weighted_alpaca_eval_gpt4_turbo : we improved the annotator in quality and price. First, we use the gpt4_turbo model for annotating, which is approximately 2x cheaper than gpt4 . Second, we changed the prompt such that the model outputs a single token, which further reduced cost and speed. Finally, instead of using a binary preference, we used the logprobs to compute a continuous preference, which gives the final weighted win-rate. Note that the latter two changes had the surprising effect of decreasing the annotators' length biased. By default, AlpacaEval 2.0 will be used from pip install alpaca_eval==0.5 . If you wish to use the old configs by default, you can set IS_ALPACA_EVAL_2=False in your environment.
As part of AlpacaEval, we release the following data:
text-davinci-003 reference on the AlpacaFarm evaluation set. Annotations are from a pool of 16 crowd workers on Amazon Mechanical Turk. The different models are: 6 from OpenAI, 2 SFT models from AlpacaFarm, 13 RLHF methods from AlpacaFarm, and LLaMA 7B.For more details about the human annotations refer to the AlpacaFarm paper.
AlpacaEval is an improvement and simplification of the automatic pairwise preference simulator from AlpacaFarm. Outside AlpacaFarm, you should be using AlpacaEval. Here are the main differences:
{instruction}nn{input} . This affects 1/4 of the examples in the AlpacaFarm evaluation set (the self-instruct subset). This simplification provides a more fair comparison for models that were not trained by distinguishing between the two fields.text-davinci-003 ), so the results on AlpacaEval are not comparable to those on AlpacaFarm even for examples that had no input field.--anotators_config 'alpaca_farm' and --p_label_flip 0.25 when creating an evaluator. There have been several work that propose new automatic annotators for instruction-following models. Here we list the ones that we are aware of and discuss how they differ from ours. We evaluated all of those in our evaluator's leaderboard.
lmsys_gpt4 ) evaluates the pair by asking the annotator a score from 1-10 for each output, and then selecting the output with the highest score as preferred. They do not randomize over output order and they ask an explanation after the score. Overall, we found that this annotator has strong bias towards longer outputs (0.74) and relatively low correlation with human annotations (63.2).alpaca_farm_greedy_gpt4 ) evaluates the pair by directly asking the annotator which output it prefers. Furthermore, it batches 5 examples together to amortize the length of the prompt and randomizes the order of outputs. Overall, we found that this annotator has much less bias towards longer outputs (0.60) and is faster (878 seconds/1000 examples) than others. It has a slightly higher correlation with the majority of human annotations (66.4) than humans themselves (65.7). However, it is more expensive ($15.3/1000 examples) and doesn't work with very long outputs given the batching.aviary_gpt4 ) asks the annotator to order the output by its preference, rather than simply selecting the preferred output. It does not randomize the order of outputs and uses high temperature for decoding (0.9). Overall, we found that this annotator has relatively strong bias towards longer outputs (0.70) and very high correlation with human annotations (69.1). By decreasing the temperature and randomizing the order of outputs, we further improved the correlation to 69.8 ( improved_aviary_gpt4 ) but this further increased the length bias to 0.73. Our alpaca_eval_gpt4 is a mix between the AlpacaFarm and Aviary annotators. It asks the annotator to order the outputs by preference, but it uses temperature 0, randomizes over outputs, and made some modifications to the prompt to decrease length bias to 0.68.
Other related work include recent papers which analyze automatic evaluators. Par exemple:
For all models you can find the auto-annotations under results/<model_name>/*/annotations.json . The annotations have the following columns:
instruction : the promptgenerator_1 : the baseline modeloutput_1 : the output of the baseline modelgenerator_2 : the model being evaluatedoutput_2 : the output of the model being evaluatedannotator : the auto-annotatorpreference : the result of the auto-annotator. This is a float between 1 and 2. Closer to 1 means that the auto-annotator prefers output_1 , closer to 2 means that it prefers output_2 . For AlpacaEval 2.0, preference-1 corresponds to the probability of output_1 being preferred. For AlpacaEval 1.0, preference is 1 if output_1 is preferred, 2 if output_2 is preferred, and 1.5 if they are the same. The win rate is always (preference -1).mean() .raw_completion : the raw output of the auto-annotator. This is field contains the completions before de-randomization of the order between output_1 and output_2 ! It is thus much harder to interpret, see below for more information.Chain of thought
For some annotators, eg alpaca_eval_cot_gpt4_turbo_fn we use chain of thought reasoning to make the models preferences more interpretable. Those can then be found under concise_explanation . To interpret them, you should also look at referenced_models which translates the temporary model name (in the prompt) to the actual output. Below, we provide more explanation as to what is happening behind the scenes.
You can check the raw_annotations["concise_explanation] column in annotations.json (eg here) which contains the chain of thought reasoning of the auto annotator. Note that the raw_annotations is not modified by the randomization of the order of the outputs. In particular, "m" and "M" can sometime refer to the first model (the reference) and sometime to the second model (the model being evaluated). To understand which model is being referred to, you should use the column preference and ordered_models . To make it easier we add a column "referenced_models" mapping the model names to the corresponding outputs. For example in the following annotation we see that the preference is 1.0 (ie output_1 ) and corresponds to model M in concise_explanation (see ordered_models ).
{
"instruction" : " How did US states get their names? " ,
"output_1" : " The names of U.S. states are derived from a variety of languages and sources, including indigenous American languages, European languages (primarily English, Spanish, and French), as well as other historical influences. Here is a brief overview of how some states got their names: nn 1. **Indigenous American Languages**: Many state names come from Native American words or names of tribes, often from the languages of the indigenous peoples who lived in or near those areas. n - **Alabama**: Possibly derived from the Choctaw language, meaning " thicket clearers. "n - **Connecticut**: From a Mohegan-Pequot word meaning " long tidal river. "n - **Massachusetts**: [...] " ,
"generator_1" : " gpt4_1106_preview " ,
"dataset" : " helpful_base " ,
"output_2" : " The names of the 50 U.S. states come from a variety of sources, including Native American languages, European languages, and historical figures. Here's a brief overview of how some states got their names: nn 1. Native American origins: Many states have names derived from Native American languages. For example, Alabama comes from the Choctaw word " Albah amo, " meaning " plant gatherers " or " herb gatherers. " Similarly, the name Mississippi comes from the Ojibwe word " Misi-ziibi, " meaning " great river. "nn 2. European languages: [...]. " ,
"generator_2" : " gpt4 " ,
"annotator" : " alpaca_eval_cot_gpt4_turbo_fn " ,
"preference" : 1.0 ,
"raw_completion" : {
"concise_explanation" : " Model M provided a more detailed and structured response, including bold headings for each category and a wider range of examples. It also included additional categories such as 'Other European Languages' and 'Combination of Languages and Influences', which added depth to the explanation. Model m's response was accurate but less comprehensive and lacked the clear structure found in Model M's output. " ,
"ordered_models" : [
{
"model" : " M " ,
"rank" : 1
},
{
"model" : " m " ,
"rank" : 2
}
]
},
"referenced_models" : {
"M" : " output_1 " ,
"m" : " output_2 "
}
}chatgpt_fn that anyone can use (no waiting lists).chatgpt_fn or alpaca_eval_gpt4_fn .
