alpaca_eval
v0.6.5
O Alpacaeeval 2.0 com taxas de vitória controladas por comprimento (Paper) tem uma correlação de Spearman de 0,98 com o Chatbot Arena, enquanto custa menos de US $ 10 dos créditos do OpenAI, executados em menos de 3 minutos. Nosso objetivo é ter uma referência para o Chat LLMs, ou seja: Fast (<5min), barato (<$ 10) e altamente correlacionado com os seres humanos (0,98). Aqui está uma comparação com outros benchmarks:
Atualizações:
? As taxas de vitória controladas por comprimento estão fora e usadas por padrão! Isso aumenta a correlação com a arena do chatbot de 0,93 para 0,98, enquanto diminui significativamente a gameavability. As taxas de vitória bruta ainda são mostradas no site e na CLI. Mais detalhes aqui.
? O Alpacaeeval 2.0 está fora e usado por padrão! Melhoramos o auto-anotador (melhor e mais barato) e usamos a visualização do GPT-4 como linha de base. Mais detalhes aqui. Para a versão antiga, defina sua variável de ambiente IS_ALPACA_EVAL_2=False .
A avaliação de modelos de seguidores de instruções (por exemplo, chatGPT) geralmente requer interações humanas. Isso é demorado, caro e difícil de replicar. Alpacaeval em uma avaliação automática baseada em LLM que é rápida, barata, replicável e validada contra 20k anotações humanas. É particularmente útil para o desenvolvimento do modelo. Embora tenhamos melhorado em relação aos pipelines anteriores de avaliação automática, ainda existem limitações fundamentais, como a preferência por saídas mais longas. Alpacaeeval fornece o seguinte:
Quando usar o Alpacaeeval? Nosso avaliador automático é um proxy rápido e barato para a avaliação humana de tarefas simples de seguidores de instruções. É útil se você precisar executar muitas avaliações rapidamente, por exemplo, durante o desenvolvimento do modelo.
Quando não usar o Alpacaeeval? Como qualquer outro avaliador automático, o Alpacaeeval não deve substituir a avaliação humana na tomada de decisões de alta participação , por exemplo, para decidir sobre a liberação do modelo. Em particular, o alpacaeval é limitado pelo fato de que (1) as instruções no conjunto de avaliação podem não ser representativas do uso avançado do LLMS; (2) avaliadores automáticos podem ter vieses como favorecer o estilo em detrimento da factualidade da resposta; e (3) o Alpacaeeval não mede os riscos que um modelo pode causar. Detalhes em limitações.
Para instalar a liberação estável, execute
pip install alpaca-evalPara instalar a versão noturna, execute
pip install git+https://github.com/tatsu-lab/alpaca_evalEntão você pode usá -lo da seguinte forma:
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 ' Isso imprimirá a tabela de classificação no console e salvará a tabela de classificação e as anotações no mesmo diretório que o arquivo model_outputs . Parâmetros importantes são os seguintes:
instruction e output das chaves.weighted_alpaca_eval_gpt4_turbo (padrão para o Alpacaeval 2.0), que tem uma alta taxa de concordância com nossos dados de anotação humana, tamanho de contexto grande e é bastante barato. Para uma comparação de todos os anotadores, consulte aqui.model_outputs . Por padrão, este é gpt4_turbo para o AlpacaEval 2.0. Se você não tiver as saídas do modelo, poderá usar evaluate_from_model e passar em um caminho local ou um nome de um modelo Huggingface, ou um modelo de uma API padrão (OpenAI, Anthropic, Cohere, Google, ...). Outros comandos:
>>> 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,...).
Para obter mais informações sobre cada função, use alpaca_eval <command> -- --help .
Nossas tabelas de classificação são calculadas no conjunto de dados Alpacaeeval. Precisamos a tabela de classificação para modelos importantes usando diferentes modelos de linha de base e autoanotadores. Nossas duas principais tabelas de classificação ("Alpacaeval 2.0" e "Alpacaeval") podem ser encontradas nesta página. "Alpacaeval 2.0" usa weighted_alpaca_eval_gpt4_turbo para o ANOTADOR e gpt4_turbo para a linha de base. "Alpacaeval" usa alpaca_eval_gpt4 para o ANOTATOR e text_davinci_003 para a linha de base. Para todas as tabelas de classificação pré -computadas, veja aqui. Mais tarde, também mostramos como adicionar seu modelo à tabela de classificação e como fazer uma nova tabela de classificação para o seu avaliador/conjunto de dados. Veja aqui as configurações de todos os modelos disponíveis fora da caixa.
Tabela de classificação mínima alpacaeeval :
| Taxa de vitória | Erro de DST | |
|---|---|---|
| GPT4 | 95.3 | 0,7 |
| Claude | 88.4 | 1.1 |
| chatgpt | 86.1 | 1.2 |
| Guanaco-65b | 71.8 | 1.6 |
| Vicuna-13b | 70.4 | 1.6 |
| text_davivinci_003 | 50.0 | 0,0 |
| ALPACA-FARM-PPO-HUMANO | 41.2 | 1.7 |
| ALPACA-7B | 26.5 | 1.5 |
| text_davinci_001 | 15.2 | 1.2 |
Taxa de vitória : a taxa de vitória mede a fração do tempo em que a saída do modelo é preferida sobre as saídas da referência ( test-davinci-003 para alpacaeval e gpt4_turbo para alpacaeeval 2.0). Mais especificamente, para calcular a taxa de vitória, coletamos pares de saídas do modelo desejado em todas as instruções do conjunto de dados APACAEVAL. Em seguida, emparelhamos cada saída com a saída do nosso modelo de referência (por exemplo text-davinci-003 ) na mesma instrução. Em seguida, perguntamos ao nosso avaliador automático qual saída eles preferem. Consulte os avisos e configurações da Alpacaeeval e Alpacaevel 2.0, em particular, randomizamos a ordem das saídas para evitar o viés de posição. Em seguida, calculamos as preferências sobre todas as instruções no conjunto de dados para obter a taxa de vitória do modelo na linha de base. Se ambas as saídas forem exatamente as mesmas, usamos meia preferência para ambos os modelos.
Erro padrão : este é o erro padrão (normalizado por N-1) da taxa de vitória, ou seja, as preferências calculadas em média sobre as diferentes instruções.
alpaca_eval_gpt4 Nosso alpaca_eval_gpt4 (consulte o ANOTATOR DE CONFIGS) Médias de preferências, onde as preferências são obtidas da seguinte forma:
temperature=0O anotador é uma mistura entre (e foi altamente influenciado por) alpacafarm e avaliadores aviários. Em particular, usamos o mesmo código que para alpacafarm (cache/randomização/hiperparâmetro), mas usamos um prompt de classificação semelhante ao do aviário. Fazemos alterações no aviso do Aviary para diminuir o viés para obter saídas mais longas. Detalhes em trabalho relacionado.
Para o alpacaeval 2.0, usamos weighted_alpaca_eval_gpt4_turbo , que usa logProbs para calcular a preferência contínua e usa GPT4_Turbo como modelo (consulte as configurações).
Avaliamos diferentes anotadores automáticos no conjunto Alpacaeeval, comparando -se a anotações humanas de 2,5k que coletamos (~ 650 instruções cada uma com 4 anotações humanas). 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 ). Veja aqui as configurações de todos os avaliadores que estão disponíveis fora da caixa e suas métricas associadas.
| Acordo humano | Preço [US $ 1000 Exemplos] | Tempo [segundos/1000 exemplos] | Spearman Corr. | Pearson Corr. | Viés | Variação | Proba. prefira mais tempo | |
|---|---|---|---|---|---|---|---|---|
| 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 |
| humanos | 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_davivinci_003 | 64.1 | 8.7 | 121 | 0,85 | 0,83 | 33.8 | 22.7 | 0,70 |
| mais longo | 62.2 | 0,0 | 0 | 0,27 | 0,56 | 37.8 | 0,0 | 1,00 |
| chatgpt | 57.3 | 0,8 | 285 | 0,72 | 0,71 | 39.4 | 34.1 | 0,59 |
Agora explicamos em palavras como calculamos as métricas na tabela acima. O código está aqui.
Acordo humano : isso mede o acordo entre o atual anotador e as preferências da maioria dos seres humanos em nossas ~ 650 anotações do nosso conjunto de anuções cruzadas, que contém 4 anotações humanas por exemplo. Para estimar o acordo entre uma única humana ( humans Row na tabela acima) e a maioria dos seres humanos, pegamos uma das 4 anotações e calculamos a precisão que ela tem ao prever o modo das outras 3 anotações. Em seguida, calculamos a média dessa precisão nas 4 anotações e nas 650 instruções para obter o acordo humano, ou seja, calculamos o acordo esperado (sobre seres humanos e amostras). Se o modo não for exclusivo, pegamos um dos modos aleatoriamente. Nós executamos exatamente o mesmo cálculo para os anotadores automáticos, para que os números finais sejam comparáveis.
Preço [US $ 1000 Exemplos] : Este é o preço médio de cada 1000 anotações. Para os seres humanos, é o preço que pagamos aos Turkers mecânicos para coletar essas anotações (US $ 21/hora). Se o preço depende da máquina usada para calcular as anotações (por exemplo, Guanaco), deixamos -a vazia.
Tempo [segundos/1000 exemplos] : Este é o tempo médio necessário para calcular 1000 anotações. Para os seres humanos, é o tempo médio estimado que cada turker mecânico levou para anotar 1000 exemplos. Para anotadores automáticos, é o tempo médio que levou ao executar as anotações. Observe que isso pode depender dos limites da API que são diferentes para diferentes usuários e o número de solicitações que os clusters estão processando.
Spearman Corr. : Isso mede a correlação Spearman entre uma tabela de classificação calculada com a preferência do auto-anotador e a tabela de classificação calculada com as preferências humanas. Como no Human agreement , usamos as anotações humanas da AlpacaFarm, mas agora consideramos o acordo no nível do método, e não apenas o acordo de amostra com os seres humanos. Observe que usamos apenas 9 modelos e, portanto, a correlação não é muito confiável.
Pearson Corr. : o mesmo que com Spearman corr. Mas com a correlação de Pearson.
Viés : concordância entre o rótulo humano mais provável e o mais provável automático. Para os anotadores automáticos, estimamos -o amostrando 4 anotações diferentes para cada exemplo. A aleatoriedade aqui vem da ordem das saídas no prompt, amostragem do LLM e, se aplicável, a ordem da instrução no lote e a escolha do Annotator no pool. Em seguida, tomamos o modo das 4 anotações e calculamos a precisão do modo ao prever o modo das 4 anotações humanas. Observe que isso provavelmente é uma superestimação sobre o verdadeiro viés que teríamos se tivéssemos um número "infinito" de anuções cruzadas. Um baixo viés significa que o anotador tem em expectativa as mesmas preferências que os seres humanos. Para o caso dos humanos, o viés é zero por definição. Observe que isso está relacionado, mas não ao viés estatístico padrão, porque pegamos o modo em vez de uma média nas anotações e consideramos a perda de 0-1 em vez de perda ao quadrado.
Variação : Contrato esperado Uma única preferência automática e a mais provável. Estimamos da mesma maneira que estimamos o "acordo humano" para os seres humanos, ou seja, pegamos o erro esperado para prever o modo das 3 anotações usando a 4ª anotação. Uma variação de baixa variação significa que o anotador é consistente com sua preferência, ou seja, se você amostrar com sementes diferentes, ele fornecerá o mesmo resultado. Assim como o viés, essa não é exatamente a variação estatística padrão, porque tomamos o modo em vez de uma média nas anotações e consideramos a perda de 0-1 em vez de perda ao quadrado.
Observe que o "acordo humano" está fortemente relacionado ao viés e variação. Em particular, a variação mede o erro devido ao fato de usarmos apenas uma única anotação, enquanto o viés visa medir o erro irredutível para o anotador atual.
Proba. Prefiro mais : essa é a probabilidade de o anotador preferir a saída mais longa quando uma das duas saídas é significativamente maior que a outra (mais de 30 caracteres diferença).
Na mesa completa, também fornecemos as seguintes métricas:
Proba. Listas de preferência : essa é a probabilidade de o anotador preferir a saída que contém uma lista/marcador quando uma saída faz, mas não a outra.
Proba. Prefira 1 : essa é a probabilidade de o Annotator preferir o primeiro dos pares de saídas. Todos os nossos anotadores propostos randomizam sobre as saídas no prompt, portanto, isso deve ser 0,5. Anotadores anteriores, como lmsys e aviary , não.
# analisado : este é o número de exemplos que o anotador conseguiu analisar.
Observe que, se a variação e o viés estiverem vazios, isso significa que executamos apenas uma única anotação para cada exemplo 648 devido a restrições de recursos (tempo e preço). Isso explica por que o #PARSED é 648, caso contrário, deve ser 2592.
No geral, recomendamos o uso annotators_config=weighted_alpaca_eval_gpt4_turbo Se você deseja o alto acordo com os seres humanos, e annotators_config=chatgpt_fn se você estiver com um orçamento apertado.
Ao escolher um anotador, recomendamos que você considere o seguinte (os três primeiros são óbvios):
"Human agreement [%]""Price [$/1000 examples]""Time [seconds/1000 examples]""* corr." aprox. > 0,7. É importante que a correlação não seja muito baixa, mas não recomendamos usá -la como a principal métrica, pois a correlação é calculada em apenas 9 modelos."Proba. prefer longer" aprox. <0,7. De fato, descobrimos que a maioria da preferência dos anotadores humanos tem um forte viés para respostas mais longas (como mostra o alto desempenho = 62,2 do avaliador "longest" que sempre prefere a saída mais longa). Isso sugere que pode ser mais um viés com os anotadores humanos. Para evitar tabelas de classificação com vieses fortes por comprimento, sugerimos o uso de anotadores automáticos com menos de 0,7 "proba. Prefira mais tempo"."Variance" aprox. <0,2. Acreditamos que um bom avaliador deve ter o mínimo de variação possível, para que os resultados sejam reproduzíveis principalmente. Observe que a variação pode ser desejável no caso em que estamos simulando os seres humanos, como mostrado no AlpacaFarm. Filizamos os anotadores que não atendem a esses requisitos na tabela acima (além de humanos / chatgpt / 003 / lmsys para fins de referência). Para todos os resultados, veja aqui. Em geral, encontramos weighted_alpaca_eval_gpt4_turbo ser uma boa troca entre a qualidade / preço / tempo / variação / comprimento.
As métricas acima são calculadas em relação às anotações de trabalhadores multidões. Embora úteis, essas anotações não são perfeitas, por exemplo, os trabalhadores de multidões geralmente favorecem o estilo em detrimento da factualidade. Assim, recomendamos os usuários para validar avaliadores automáticos por suas próprias instruções e anotações humanas. Detalhes em limitações.
>>> 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
Para avaliar um modelo que você precisa:
model_outputs . Por padrão, usamos os 805 exemplos da Alpacaeeval. Para calcular as saídas no uso de alpacaeeval: 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 Se o seu modelo for um modelo Huggingface ou de um provedor de API padrão (Openai, antropic, coere). Em seguida, você pode usar diretamente alpaca_eval evaluate_from_model para cuidar também de gerar saídas.
reference_outputs . Por padrão, usamos saídas pré -computadas de gpt4_turbo no Alpacaeval. Se você deseja usar um modelo diferente ou um conjunto de dados diferente, siga as mesmas etapas que (1.).annotators_config . Recomendamos o uso alpaca_eval_gpt4_turbo_fn . Para outras opções e comparações, consulte esta tabela. Dependendo do avaliador, talvez seja necessário definir a API_KEY apropriada em seu ambiente ou int os client_configs.Correndo juntos:
alpaca_eval --model_outputs ' example/outputs.json '
--annotators_config ' alpaca_eval_gpt4_turbo_fn ' Se você não tiver saídas decodificadas, poderá usar evaluate_from_model , que cuida da decodificação (modelo e referência) para você. Aqui está um exemplo:
# need a GPU for local models
alpaca_eval evaluate_from_model
--model_configs ' oasst_pythia_12b '
--annotators_config ' alpaca_eval_gpt4_turbo_fn ' Aqui, o model_configs e reference_model_configs (Opcional) são caminhos para um diretório que especifica o prompt, o provedor de modelos (aqui HuggingFace) e parâmetros de decodificação. Veja este diretório para exemplos. Para todos os provedores de modelos que estão disponíveis, consulte aqui.
caching_path . As anotações nunca são recomputadas, o que torna as anotações mais rápidas, mais baratas e permitem a reprodutibilidade. Isso ajuda mesmo ao avaliar modelos diferentes, pois muitos modelos têm as mesmas saídas.>>> 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`.
Se você deseja fazer uma nova tabela de classificação usando um único comando (em vez de várias chamadas alpaca_eval ), para o conjunto de avaliação e avaliadores desejados, você pode usar o seguinte:
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 >onde:
leaderboard_path : PATH para salvar a tabela de classificação. A tabela de classificação será salva como um arquivo CSV, se já existir, ele anexará.all_model_outputs : O caminho JSON para as saídas de todos os modelos para adicionar ao Diretor de Lizer (como um único arquivo ou globando vários arquivos). Cada dicionário deve conter as teclas ( instruction e output ) que são formatadas nos prompts e um generator de coluna com o nome do modelo atual. Como exemplo, consulte este arquivo.reference_outputs O caminho para as saídas do modelo de referência. Cada dicionário deve conter as teclas ( instruction e output ) que são formatadas nos prompts. Por padrão, as saídas de referência são as saídas 003 no conjunto de alpacaevel.annotators_config : o caminho para o arquivo de configuração do annotador. Padrão para 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`.
A Alpacaeeval fornece uma maneira simples de criar novos avaliadores. Tudo o que você precisa é criar um novo arquivo de configuração configs.yaml , que você passará como --annotators_config <path_to_config.yaml> para alpaca_eval . Aqui estão algumas maneiras de fazer um novo avaliador:
prompt_template do arquivo de configuração. Os caminhos são relativos ao arquivo de configuração.completions_kwargs no arquivo de configuração. Para ver todos os parâmetros disponíveis, consulte os documentos da função correspondente neste arquivo especificado por fn_completions no arquivo de configuração.model_name e o prompt correspondente no prompt_template . Se o modelo vier de outro provedor, você deverá alterar fn_completions que mapeiam a função correspondente neste arquivo. Fornecemos funções fn_completions para usar modelos do OpenAI, Antrópico, Coere ou Huggingface. Para instalar os pacotes necessários para todos os provedores, use pip install alpaca_eval[all] . O mais fácil é verificar os documentos do SinglePairwiseAnnotator . Aqui estão alguns importantes:
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.
Depois de fazer o avaliador, você também pode analisá -lo e adicioná -lo à tabela de classificação do avaliador usando o seguinte comando:
alpaca_eval analyze_evaluators --annotators_config ' <path_to_config.yaml> ' Para estimar o viés e a variação, isso avalia todos os exemplos com 4 sementes, ou seja, avaliação de 2,5k. Se você deseja uma avaliação mais barata, pode usar uma única semente usando --is_single_annotator True que ignorará a estimativa de viés e variação.
Estamos aceitando PRs para novos modelos, avaliadores e conjuntos de avaliação, além das correções de bugs. Atualizaremos o site da tabela de classificação regularmente com novas contribuições da comunidade. Também criamos uma discórdia de suporte para o Alpacaeeval, caso você encontre quaisquer problemas e deseje pedir ajuda à comunidade.
Para começar, primeiro bifore o repositório e instale o pacote da fonte pip install -e .
Primeiro, você precisará adicionar uma definição de configuração de modelo na pasta Models_Configs. Como exemplo, você pode olhar para o YAML da instrução Falcon-7B. Certifique -se de que o nome da pasta e o nome da chave no YAML correspondam exatamente.
Em seguida, siga as etapas na avaliação de um modelo para executar a inferência no modelo para produzir saídas no conjunto de avaliação e pontuar o modelo de acordo com um dos avaliadores. Um comando de exemplo pode parecer:
alpaca_eval evaluate_from_model
--model_configs ' falcon-7b-instruct 'Depois de executar este comando, você deve ter gerado um JSON de saídas e uma nova entrada no arquivo de tabela de classificação correspondente. Por favor, faça um PR com o arquivo de configuração, o arquivo de saída e a tabela de classificação atualizada.
Concretamente você deve fazer algo como:
git clone <URL>src/alpaca_eval/models_configs/<model_name> e avalie -o 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 Nota: Se você estiver gerando saídas fora do Alpacaeval, ainda deverá adicionar uma configuração de modelo, mas com fn_completions: null . Veja esta configuração para um exemplo.
Um resultado verificado em alpacaevel indica que um mantenedor de núcleo decodificou as saídas do modelo e realizou a avaliação. Infelizmente, nós, os mantenedores da Alpacaeeval, não temos recursos para verificar todos os modelos e, portanto, faremos isso apenas para modelos que estão entre os 5 primeiros da tabela de classificação. Pedimos desculpas por qualquer inconveniente que isso possa causar e apreciar sua compreensão. Para ver seu modelo verificado, siga as etapas abaixo:
@yann na discórdia ou envie um email se você tiver nosso email, fornecendo uma breve justificativa para o motivo pelo qual seu modelo deve ser verificado.alpaca_eval evaluate_from_model --model_configs '<your_model_name>' sem exigir uma GPU local.alpaca_eval evaluate_from_model --model_configs '<your_model_name>' , atualize os resultados e informará você para que você possa revogar as chaves temporárias.Observe que não reavaliaremos o mesmo modelo. Devido à variação de amostragem, os resultados podem diferir ligeiramente dos seus iniciais. Substituiremos os resultados anteriores da comunidade pelos verificados.
Primeiro, siga as instruções para fazer um novo avaliador. Depois de criar a configuração do Annotator, solicitamos que você crie uma nova tabela de classificação para o Annotator, avaliando o conjunto mínimo de modelos. As saídas para esses modelos podem ser encontradas baixando 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 >Em seguida, crie um PR com a configuração do ANOTATOR e CSV do tabela de classificação.
Para contribuir com um novo conjunto de avaliação, você precisará primeiro especificar um conjunto de instruções textuais. Em seguida, você precisará especificar um conjunto de saídas de referência (as taxas de vitória do modelo são calculadas em relação a essa referência). Para facilitar o uso, você pode usar a configuração de referência padrão-davinci-003.
Coloque -os juntos em um JSON, onde cada entrada especifica a instruction , output e generator dos campos. Você pode procurar alpaca_eval.json como um guia (o campo dataset não é necessário).
Por fim, pedimos que você crie uma tabela de classificação mínima neste novo conjunto de avaliação. Você pode fazer isso com o seguinte:
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 >Por favor, envie um PR com o conjunto de avaliação JSON e o CSV de tabela de classificação correspondente.
Atualmente, permitimos diferentes funções de conclusão, por exemplo, openai , anthropic , huggingface_local , huggingface_hub_api ... se você deseja contribuir com uma nova função de conclusão / API com a qual executar a inferência, siga as etapas:
<name>_completions(prompts : Sequence[str], model_name :str, ... ) na pasta decodificadora. Essa função deve ter como argumento os prompts + kwargs e retornar as conclusões. Veja outras funções de conclusão no diretório para modelos. Por exemplo, huggingface_local_completions ou antropic.<name>_completions and Dependências no init . Novamente você pode seguir o exemplo de huggingface_local_completionsalpaca_eval evaluate_from_model --model_configs '<model_configs>'Sinta -se à vontade para iniciar um PR mais cedo, poderemos fornecer alguma ajuda no processo!
O pipeline de avaliação do ALPACAEEV, como outros avaliadores atuais, tem limitações importantes e, portanto, não deve ser usado como substituição da avaliação humana em ambientes importantes, como decidir se um modelo está pronto para ser implantado. Eles podem ser amplamente agrupados em 3 categorias:
As instruções podem não ser representativas do uso real : o conjunto de alpacaevel contém exemplos de uma variedade de conjuntos de dados (auto-estrutura, assistente aberto, Vicuna, Koala, HH-RLHF) que podem não ser representativos de aplicações reais e avançadas de melhores modelos como o GPT4. Provavelmente, isso faz com que os melhores modelos fechados (GPT4 / Claude / ChatGPT / ...) pareçam mais parecidos com os modelos abertos do que o que são. De fato, esses modelos fechados parecem ter sido pré -criados/Finetuned em dados muito mais diversos. Veja, por exemplo, este blog para obter resultados preliminares sobre instruções mais complexas. Observe, no entanto, que no AlpacaFarm mostramos que as taxas de vitória em nosso conjunto de avaliação estão altamente correlacionadas (0,97 R2) com taxas de vitória nas instruções das interações do usuário com a demonstração da ALPACA. Além disso, a tabela de líderes da Alpacaeeeva mostra maior lacuna entre os modelos abertos e os modelos Openai do que outras tabelas de classificação (por exemplo, LMSYs).
Vieses dos anotadores automáticos : os anotadores automáticos brutos parecem ter vieses implícitos. Em particular, descobrimos que eles tendem a preferir saídas e saídas mais longas que contêm listas (por exemplo, 0,68 / 0,69 para alpaca_eval_gpt4 e 0,62 / 0,58 para claude ). Embora tenhamos descoberto que os seres humanos têm vieses semelhantes (0,64 / 0,61), acreditamos que isso pode ser mais uma limitação do pipeline de anotação humana que usamos do que um verdadeiro viés humano. De maneira mais geral, através da análise qualitativa, descobrimos que os anotadores automáticos dão mais importância ao estilo da saída do que seu conteúdo (por exemplo, factualidade). Finalmente, descobrimos que os avaliadores automáticos tendem a preferir saídas de modelos semelhantes (provavelmente treinados nos mesmos dados), conforme sugerido pela grande diferença entre ChatGPT/GPT4 na tabela de classificação de claude e alpaca_eval_gpt4 . Observe que o viés de comprimento é parcialmente mitigado em nossos taças de vitória controlados pelo comprimento.
Falta de avaliação de segurança : É importante ressaltar que o Alpacaeval avalia apenas as capacidades de seguidores de instruções dos modelos, em vez do dano que eles poderiam causar (por exemplo, comportamento tóxico ou viés). Como resultado, a pequena lacuna entre o ChatGPT atual e os melhores modelos de código aberto não deve ser interpretado como se estes estivessem prontos para serem implantados.
Além dessas limitações sobre os pipelines de avaliação, também existem limitações sobre nossa validação dos avaliadores e nossa abordagem proposta para selecionar conjuntos de avaliação.
Primeiro, nossa validação de avaliadores com base nas anuções cruzadas humanas sofre com as seguintes limitações: (1) descobrimos qualitativamente que nossos trabalhadores de multidões tendem a favorecer o estilo como comprimento e presença de listas sobre a factualidade; (2) isso não valida se as taxas de vitória contra um modelo de referência são uma boa estratégia de avaliação em primeiro lugar; (3) As preferências de 16 trabalhadores multidão não são representativos das preferências de todos os seres humanos.
Segundo, nossa abordagem sugerida para selecionar conjuntos de avaliação com base no poder estatístico sofre com as seguintes limitações: (1) o poder estatístico não garante a direção certa, por exemplo, você pode ter um conjunto não natural de instruções em que a ALPACA "executa" melhor do que o melhor modelo; e (2) isso pode levar os usuários a selecionar dados para suportar a hipótese que desejam validar.
Visualizações alpacaeevels controladas por comprimento:
Desenvolvimento alpacaeeval controlado por comprimento:
O notebook mostra diferentes opções que consideramos para mitigar o viés de comprimento dos anotadores automáticos.
Aqui resumimos brevemente os principais resultados. Nomeadamente:
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. Por exemplo:
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 .
