Alpacaeval 2.0 con tasas de victorias (papel) controladas por longitud tiene una correlación de Spearman de 0.98 con Chatbot Arena, al tiempo que cuesta menos de $ 10 de créditos de Operai que se ejecutan y se ejecutan en menos de 3 minutos. Nuestro objetivo es tener un punto de referencia para los LLM de chat que es: rápido (<5 minutos), barato (<$ 10) y altamente correlacionado con los humanos (0.98). Aquí hay una comparación con otros puntos de referencia:

Actualizaciones:
? ¡Las tasas de ganancia controladas por longitud están fuera y se usan por defecto! Esto aumenta la correlación con ChatBot Arena de 0.93 a 0.98, mientras que disminuye significativamente la gameabilidad de longitud. Las tasas de ganancia en bruto todavía se muestran en el sitio web y la CLI. Más detalles aquí.
? ¡Alpacaeval 2.0 está fuera y se usa de forma predeterminada! Mejoramos el anotador automático (mejor y más barato) y usamos la vista previa de GPT-4 como línea de base. Más detalles aquí. Para la versión anterior, establezca su variable de entorno IS_ALPACA_EVAL_2=False .
La evaluación de los modelos de seguimiento de instrucciones (por ejemplo, CHATGPT) generalmente requiere interacciones humanas. Esto lleva mucho tiempo, costoso y difícil de replicar. Alpacaeval en una evaluación automática basada en LLM que es rápida, barata, replicable y validada contra 20K anotaciones humanas. Es particularmente útil para el desarrollo del modelo. Aunque mejoramos sobre las tuberías de evaluación automática previa, todavía existen limitaciones fundamentales como la preferencia por resultados más largos. Alpacaeval proporciona lo siguiente:
¿Cuándo usar Alpacaeval? Nuestro evaluador automático es un proxy rápido y barato para la evaluación humana de tareas simples de seguimiento de instrucciones. Es útil si tiene que ejecutar muchas evaluaciones rápidamente, por ejemplo, durante el desarrollo del modelo.
¿Cuándo no usar Alpacaeval? Como cualquier otro evaluador automático, Alpacaeval no debe reemplazar la evaluación humana en la toma de decisiones de alto riesgo , por ejemplo, para decidir sobre la liberación del modelo. En particular, Alpacaeval está limitado por el hecho de que (1) las instrucciones en el conjunto de evaluación podrían no ser representativas del uso avanzado de LLM; (2) los evaluadores automáticos pueden tener sesgos como favorecer el estilo sobre la facturidad de la respuesta; y (3) Alpacaeval no mide los riesgos que un modelo podría causar. Detalles en limitaciones.
Para instalar la versión estable, ejecute
pip install alpaca-evalPara instalar la versión nocturna, ejecute
pip install git+https://github.com/tatsu-lab/alpaca_evalEntonces puedes usarlo de la siguiente manera:
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 ' Esto imprimirá la tabla de clasificación en la consola y guardará tanto la tabla de clasificación como las anotaciones en el mismo directorio que el archivo model_outputs . Los parámetros importantes son los siguientes:
instruction y output de las teclas.weighted_alpaca_eval_gpt4_turbo (predeterminado para Alpacaeval 2.0), que tiene una alta tasa de acuerdo con nuestros datos de anotación humana, tamaño de contexto grande y es bastante barato. Para una comparación de todos los anotadores, ver aquí.model_outputs . Por defecto, esto es gpt4_turbo para Alpacaeval 2.0. Si no tiene las salidas del modelo, puede usar evaluate_from_model y pasar una ruta local o un nombre de un modelo de cara de abrazo, o un modelo de una API estándar (OpenAI, Anthricic, Cohere, Google, ...). Otros 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 obtener más información sobre cada función, use alpaca_eval <command> -- --help .
Nuestras tablas de clasificación se calculan en el conjunto de datos Alpacaeval. Precomputamos la tabla de clasificación para modelos importantes que utilizan diferentes modelos de referencia y autoannotadores. Nuestras dos tablas de clasificación principales ("Alpacaeval 2.0" y "Alpacaeval") se pueden encontrar en esta página. "Alpacaeval 2.0" usa weighted_alpaca_eval_gpt4_turbo para el anotador y gpt4_turbo para la línea de base. "Alpacaeval" usa alpaca_eval_gpt4 para el anotador y text_davinci_003 para la línea de base. Para todas las tablas de clasificación precomputadas, ver aquí. Más tarde, también mostramos cómo agregar su modelo a la tabla de clasificación y cómo hacer una nueva tabla de clasificación para su evaluador/conjunto de datos. Consulte aquí para ver las configuraciones de todos los modelos que están disponibles fuera de la caja.
Alpacaeval mínima tabla de clasificación :
| Tasa de ganancia | Error de ETS | |
|---|---|---|
| GPT4 | 95.3 | 0.7 |
| tirar | 88.4 | 1.1 |
| chatgpt | 86.1 | 1.2 |
| guanaco-65b | 71.8 | 1.6 |
| vicuna-13b | 70.4 | 1.6 |
| text_davinci_003 | 50.0 | 0.0 |
| Alpaca-Farm-Papo-Human | 41.2 | 1.7 |
| Alpaca-7b | 26.5 | 1.5 |
| text_davinci_001 | 15.2 | 1.2 |
Tasa de ganancia : la tasa de ganancia mide la fracción de tiempo que se prefiere la producción del modelo sobre las salidas de la referencia ( test-davinci-003 para Alpacaeval y gpt4_turbo para Alpacaeval 2.0). Más específicamente, para calcular la tasa de victorias, recolectamos pares de salidas del modelo deseado en cada instrucción del conjunto de datos Apacaval. Luego emparejamos cada salida con la salida de nuestro modelo de referencia (por ejemplo, text-davinci-003 ) en la misma instrucción. Luego le preguntamos a nuestro evaluador automático qué salida prefieren. Consulte las indicaciones y configuraciones de Alpacaeval y Alpacaeval 2.0, en particular, aleatorizamos el orden de los resultados para evitar el sesgo de posición. Luego promediamos las preferencias sobre todas las instrucciones en el conjunto de datos para obtener la tasa de ganancia del modelo sobre la línea de base. Si ambas salidas son exactamente las mismas, usamos una preferencia media para ambos modelos.
Error estándar : este es el error estándar (normalizado por N-1) de la tasa de victorias, es decir, las preferencias promediadas sobre las diferentes instrucciones.
alpaca_eval_gpt4 Nuestro anotador alpaca_eval_gpt4 (ver configs) promedia las preferencias, donde las preferencias se obtienen de la siguiente manera:
temperature=0El anotador es una mezcla entre (y fue altamente influenciado por) evaluadores de alpacafarm y aviarios. En particular, usamos el mismo código que para alpacafafarm (almacenamiento en caché/aleatorización/hiperparametros) pero usamos un indicador de clasificación similar al de Aviary. Hacemos cambios en la solicitud de Aviary para disminuir el sesgo para salidas más largas. Detalles en el trabajo relacionado.
Para Alpacaeval 2.0 usamos weighted_alpaca_eval_gpt4_turbo , que usa logProbs para calcular la preferencia continua y usa GPT4_Turbo como modelo (ver configuraciones).
Evaluamos diferentes anotadores automáticos en el conjunto de alpacaeval en comparación con 2.5k anotaciones humanas que recolectamos (~ 650 instrucciones cada una con 4 anotaciones humanas). A continuación mostramos métricas para nuestros evaluadores sugeridos ( weighted_alpaca_eval_gpt4_turbo , alpaca_eval_gpt4 ), para evaluadores automáticos anteriores ( alpaca_farm_greedy_gpt4 , aviary_gpt4 , lmsys_gpt4 ), para humanos ( humans ), y para modelos base diferentes con el mismo indicador ( gpt4 , claude , CLAUDE) text_davinci_003 , chatgpt_fn , guanaco_33b , chatgpt ). Consulte aquí para ver las configuraciones de todos los evaluadores que están disponibles fuera de la caja y sus métricas asociadas.
| Acuerdo humano | Precio [$/1000 ejemplos] | Tiempo [segundos/1000 ejemplos] | Spearman Corr. | Pearson Corr. | Inclinación | Diferencia | Proba. prefiere más tiempo | |
|---|---|---|---|---|---|---|---|---|
| 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 |
| tirar | 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 |
| el más largo | 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 |
Ahora explicamos en palabras cómo calculamos las métricas en la tabla de arriba. El código está aquí.
Acuerdo humano : esto mide el acuerdo entre el anotador actual y las preferencias mayoritarias de los humanos en nuestras ~ 650 anotaciones de nuestro conjunto de anotación cruzada, que contiene 4 anotaciones humanas por ejemplo. Para estimar el acuerdo entre un solo humano (la fila humans en la tabla anterior) y la mayoría de los humanos, tomamos una de las 4 anotaciones y calculamos la precisión que tiene al predecir el modo de las otras 3 anotaciones. Luego promediamos esta precisión en las 4 anotaciones y sobre las 650 instrucciones para obtener el acuerdo humano, es decir, calculamos el acuerdo esperado (sobre humanos y muestras) de baja a uno. Si el modo no es único, tomamos uno de los modos al azar. Realizamos exactamente el mismo cálculo para los anotadores automáticos, de modo que los números finales sean comparables.
Precio [$/1000 ejemplos] : Este es el precio promedio de cada 1000 anotaciones. Para los humanos, es el precio que pagamos a Turkers mecánicos para recolectar esas anotaciones ($ 21/hora). Si el precio depende de la máquina utilizada para calcular las anotaciones (por ejemplo, guanaco), la dejamos vacía.
Tiempo [segundos/1000 ejemplos] : Este es el tiempo promedio que lleva calcular 1000 anotaciones. Para los humanos, es el tiempo mediano estimado que cada turker mecánico tomó para anotar 1000 ejemplos. Para los anotadores automáticos, es el tiempo promedio que nos llevó al ejecutar las anotaciones. Tenga en cuenta que esto puede depender de los límites de API que sean diferentes para diferentes usuarios y la cantidad de solicitudes que los grupos están procesando.
Spearman Corr. : Esto mide la correlación de Spearman entre una tabla de clasificación calculada con la preferencia del anotador automático y la tabla de clasificación calculada con preferencias humanas. Al igual que con Human agreement , utilizamos las anotaciones humanas de Alpacafarm, pero ahora consideramos el acuerdo a nivel de método en lugar de solo el acuerdo de muestra con humanos. Tenga en cuenta que solo usamos tener 9 modelos y, por lo tanto, la correlación no es muy confiable.
Pearson Corr. : Igual que con Spearman corr. Pero con la correlación de Pearson.
Sesgo : acuerdo entre la etiqueta humana más probable y la automática más probable. Para los anotadores automáticos lo estimamos muestreando 4 anotaciones diferentes para cada ejemplo. La aleatoriedad aquí proviene del orden de las salidas en el aviso, muestreando desde el LLM, y si corresponde el orden de la instrucción en el lote y la elección del anotador en el grupo. Luego tomamos el modo de las 4 anotaciones y calculamos la precisión del modo al predecir el modo de las 4 anotaciones humanas. Tenga en cuenta que esto es probablemente una sobreestimación sobre el sesgo real que obtendríamos si tuviéramos un número "infinito" de anotaciones cruzadas. Un sesgo bajo significa que el anotador tiene en expectación las mismas preferencias que los humanos. Para el caso de los humanos, el sesgo es cero por definición. Tenga en cuenta que esto está relacionado, pero no con el sesgo estadístico estándar, porque tomamos el modo en lugar del promedio sobre anotaciones y consideramos la pérdida de 0-1 en lugar de la pérdida al cuadrado.
Varianza : Acuerdo esperado Una sola preferencia automática y la más probable. Lo estimamos de la misma manera que estimamos el "acuerdo humano" para los humanos, es decir, tomamos el error esperado de dejar un error al predecir el modo de las 3 anotaciones utilizando la cuarta anotación. Una baja varianza significa que el anotador es consistente con su preferencia, es decir, si la muestra con diferentes semillas, dará el mismo resultado. Al igual que con el sesgo, esta no es exactamente la varianza estadística estándar, porque tomamos el modo en lugar de las anotaciones promedio y consideramos la pérdida 0-1 en lugar de la pérdida al cuadrado.
Tenga en cuenta que el "acuerdo humano" está estrechamente relacionado con el sesgo y la varianza. En particular, la varianza mide el error debido al hecho de que solo usamos una anotación única, mientras que el sesgo tiene como objetivo medir el error irreductible para el anotador actual.
Proba. Prefiero más tiempo : esta es la probabilidad de que el anotador prefiera la salida más larga cuando una de las dos salidas es significativamente más larga que la otra (diferencia de más de 30 caracteres).
En la tabla completa también proporcionamos las siguientes métricas:
Proba. Prefiere listas : esta es la probabilidad de que el anotador prefiera la salida que contiene una lista/puntos de bala cuando una salida lo hace pero no la otra.
Proba. Prefiero 1 : Esta es la probabilidad de que el anotador prefiera el primero del par de salidas. Todos nuestros anotadores propuestos aleatorizan sobre las salidas en el aviso, por lo que esto debería ser 0.5. Anotadores anteriores, como lmsys y aviary , no lo hacen.
# Parsed : Este es el número de ejemplos que el anotador pudo analizar.
Tenga en cuenta que si la varianza y el sesgo están vacíos, significa que solo realizamos una anotación única para cada ejemplo de 648 debido a las restricciones de recursos (tiempo y precio). Esto explica por qué el #parsed es 648, de lo contrario debería ser 2592.
En general, recomendamos usar annotators_config=weighted_alpaca_eval_gpt4_turbo si desea el alto acuerdo con humanos y annotators_config=chatgpt_fn si tiene un presupuesto ajustado.
Al elegir un anotador, le recomendamos que considere lo siguiente (los tres primeros son obvios):
"Human agreement [%]""Price [$/1000 examples]""Time [seconds/1000 examples]""* corr." aprox. > 0.7. Es importante que la correlación no sea demasiado baja, pero no recomendamos usarla como la métrica principal, ya que la correlación se calcula en solo 9 modelos."Proba. prefer longer" aprox. <0.7. De hecho, encontramos que la mayoría de la preferencia de los anotadores humanos tienen un sesgo fuerte para respuestas más largas (como lo demuestra el alto rendimiento = 62.2 del evaluador "longest" que siempre prefiere la salida más larga). Esto sugiere que podría más un sesgo con los anotadores humanos. Para evitar tener tablas de clasificación con sesgos fuertes para la longitud, sugerimos usar anotadores automáticos con menos de 0.7 "Proba. Prefiere más tiempo"."Variance" aprox. <0.2. Creemos que un buen evaluador debe tener la menor variación posible para que los resultados sean en su mayoría reproducibles. Tenga en cuenta que la varianza puede ser deseable en el caso en que estamos simulando a los humanos como se muestra en Alpacafarm. Filtramos los anotadores que no satisfacen esos requisitos en la tabla anterior (además de humanos / chatgpt / 003 / lmsys para fines de referencia). Para todos los resultados, ver aquí. En general, descubrimos que weighted_alpaca_eval_gpt4_turbo es una buena compensación entre la calidad / precio / tiempo / varianza / sesgo de longitud.
Las métricas anteriores se calculan con respecto a las anotaciones de los trabajadores de la multitud. Aunque son útiles, esas anotaciones no son perfectas, por ejemplo, los trabajadores de la multitud a menudo favorecen el estilo sobre la fáctica. Por lo tanto, recomendamos a los usuarios que validen evaluadores automáticos en sus propias instrucciones y anotaciones humanas. Detalles en limitaciones.
>>> 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 evaluar un modelo que necesita:
model_outputs . Por defecto, usamos los 805 ejemplos de Alpacaeval. Para calcular las salidas en el uso de Alpacaeval: 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 su modelo es un modelo de cara de abrazos o de un proveedor de API estándar (OpenAI, Anthrope, Cohere). Luego, puede usar directamente alpaca_eval evaluate_from_model para que también se encargue de generar resultados.
reference_outputs . Por defecto, utilizamos salidas precomputadas de gpt4_turbo en Alpacaeval. Si desea usar un modelo diferente o un conjunto de datos diferente, siga los mismos pasos que (1.).annotators_config . Recomendamos usar alpaca_eval_gpt4_turbo_fn . Para otras opciones y comparaciones, consulte esta tabla. Dependiendo del evaluador, es posible que necesite establecer el API_KEY apropiado en su entorno o en los intencion_configs.Corriendo todos juntos:
alpaca_eval --model_outputs ' example/outputs.json '
--annotators_config ' alpaca_eval_gpt4_turbo_fn ' Si no tiene salidas decodificadas, puede usar evaluate_from_model que se encarga de la decodificación (modelo y referencia) para usted. Aquí hay un ejemplo:
# need a GPU for local models
alpaca_eval evaluate_from_model
--model_configs ' oasst_pythia_12b '
--annotators_config ' alpaca_eval_gpt4_turbo_fn ' Aquí los model_configs y reference_model_configs (opcional) son rutas a un directorio que especifica el indicador, el proveedor de modelos (aquí Huggingface) y los parámetros de decodificación. Vea este directorio para ver ejemplos. Para todos los proveedores de modelos que están disponibles fuera de la caja, ver aquí.
caching_path . Por lo tanto, las anotaciones nunca se recomputan, lo que hace que las anotaciones sean más rápidas, más baratas y permiten la reproducibilidad. Esto ayuda incluso al evaluar diferentes modelos, ya que muchos modelos tienen las mismas salidas.>>> 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 desea hacer una nueva tabla de clasificación utilizando un solo comando (en lugar de múltiples llamadas alpaca_eval ), para su conjunto de evaluación y evaluadores deseados, puede usar lo siguiente:
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 >dónde:
leaderboard_path : camino para guardar la tabla de clasificación para. La tabla de clasificación se guardará como un archivo CSV, si ya existe, agregará.all_model_outputs : la ruta JSON a las salidas de todos los modelos para agregar a la tabla de clasificación (como un solo archivo o al globalizar múltiples archivos). Cada diccionario debe contener las teclas ( instruction y output ) que están formateadas en las indicaciones y un generator de columna con el nombre del modelo actual. Como ejemplo, vea este archivo.reference_outputs La ruta a las salidas del modelo de referencia. Cada diccionario debe contener las claves ( instruction y output ) que están formateadas en las indicaciones. De manera predeterminada, las salidas de referencia son las salidas 003 en el conjunto Alpacaeval.annotators_config : la ruta al archivo de configuración del anotador. El valor predeterminado a 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 proporciona una forma simple de hacer nuevos evaluadores. Todo lo que necesita es hacer un nuevo archivo de configuración de configs.yaml , que luego pasará como --annotators_config <path_to_config.yaml> a alpaca_eval . Aquí hay algunas formas en que puede hacer un nuevo evaluador:
prompt_template del archivo de configuración. Las rutas son relativas al archivo de configuración.completions_kwargs en el archivo de configuración. Para ver todos los parámetros disponibles, consulte las documentos de la función correspondiente en este archivo especificado por fn_completions en el archivo de configuración.model_name y el indicador correspondiente en prompt_template . Si el modelo proviene de otro proveedor, tendrá que cambiar fn_completions que se asigna a la función correspondiente en este archivo. Proporcionamos funciones fn_completions para usar modelos de Operai, Anthrope, Cohere o Huggingface. Para instalar paquetes necesarios para todos los proveedores, use pip install alpaca_eval[all] . Lo más fácil es verificar las documentos de SinglePairwiseAnnotator . Aquí hay algunos 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.
Una vez que haya realizado el evaluador, también puede analizarlo y agregarlo a la tabla de clasificación del evaluador utilizando el siguiente comando:
alpaca_eval analyze_evaluators --annotators_config ' <path_to_config.yaml> ' Para estimar el sesgo y la varianza, esto evalúa cada ejemplo con 4 semillas, es decir, evaluación de 2.5k. Si desea una evaluación más barata, puede usar una sola semilla utilizando --is_single_annotator True que omitirá la estimación de sesgo y varianza.
Estamos aceptando PRS para nuevos modelos, evaluadores y conjuntos de evaluación, además de las correcciones de errores. Actualizaremos el sitio web de la tabla de clasificación regularmente con nuevas contribuciones de la comunidad. También hemos creado una discordia de soporte para Alpacaeval en caso de que se encuentre con algún problema y desee pedir ayuda a la comunidad.
Para comenzar, primero desembolse el repositorio e instale el paquete desde pip install -e .
Primero, deberá agregar una definición de configuración del modelo en la carpeta Models_Configs. Como ejemplo, puede mirar el YAML de inscripción Falcon-7B. Asegúrese de que el nombre de la carpeta y el nombre de la tecla en la coincidencia de YAML exactamente.
Luego, siga los pasos para evaluar un modelo para ejecutar la inferencia en el modelo para producir salidas en el conjunto EVS y calificar el modelo de acuerdo con uno de los evaluadores. Un comando de ejemplo puede parecer:
alpaca_eval evaluate_from_model
--model_configs ' falcon-7b-instruct 'Después de ejecutar este comando, debería haber generado un JSON de salida y una nueva entrada en el archivo de tablero de clasificación correspondiente. Haga un PR con el archivo de configuración, salidas y placas de clasificación actualizada.
Concretamente deberías hacer algo como:
git clone <URL>src/alpaca_eval/models_configs/<model_name> y evalúe It 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: Si está generando salidas fuera de Alpacaeval, aún debe agregar una configuración del modelo pero con fn_completions: null . Vea esta configuración para un ejemplo.

Un resultado verificado en Alpacaeval indica que un mantenedor de núcleo ha decodificado las salidas del modelo y ha realizado la evaluación. Desafortunadamente, nosotros, los mantenedores Alpacaeval, carecen de los recursos para verificar todos los modelos y, por lo tanto, solo lo haremos para los modelos que se encuentran en los 5 mejores de la clasificación. Pedimos disculpas por cualquier inconveniente que esto pueda causar y apreciar su comprensión. Para verificar su modelo, siga los pasos a continuación:
@yann en Discord, o envíenos un correo electrónico si tiene nuestro correo electrónico, proporcionando una breve justificación de por qué su modelo debe ser verificado.alpaca_eval evaluate_from_model --model_configs '<your_model_name>' sin requerir una GPU local.alpaca_eval evaluate_from_model --model_configs '<your_model_name>' , actualizar los resultados e informarle para que pueda revocar las claves temporales.Tenga en cuenta que no reevaluaremos el mismo modelo. Debido a la varianza de muestreo, los resultados pueden diferir ligeramente de los iniciales. Reemplazaremos los resultados de su comunidad anteriores por los verificados.
Primero siga las instrucciones para hacer un nuevo evaluador. Una vez que haya creado la configuración del anotador, le pedimos que cree una nueva tabla de clasificación para el anotador evaluando el conjunto mínimo de modelos. Las salidas para estos modelos se pueden encontrar descargando 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 >Luego, cree un PR con la configuración del anotador y la tabla de clasificación CSV.
Para contribuir con un nuevo conjunto de evaluación, primero deberá especificar un conjunto de instrucciones textuales. Luego, deberá especificar un conjunto de salidas de referencia (las tasas de victorias del modelo se calculan con esta referencia). Para facilitar el uso, puede usar la configuración de referencia de texto de texto predeterminada predeterminada.
Coloque estos en un JSON, donde cada entrada especifica la instruction de campos, output y generator . Puede buscar en alpaca_eval.json como una guía (el campo dataset no es necesario).
Finalmente, le pedimos que cree una tabla de clasificación mínima en este nuevo conjunto de evaluación. Puedes hacer esto con lo siguiente:
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 >Envíe un PR con el set de evaluación JSON y el CSV de tabla de clasificación correspondiente.
Actualmente, permitimos diferentes funciones de finalización, por ejemplo, openai , anthropic , huggingface_local , huggingface_hub_api ... Si desea contribuir con una nueva función / API de finalización con la que realizar una inferencia, siga esos pasos:
<name>_completions(prompts : Sequence[str], model_name :str, ... ) en la carpeta decodificadora. Esta función debe tomar como argumento las indicaciones + KWARGS y devolver las finalizaciones. Mire otras funciones de finalización en el directorio para plantillas. Por ejemplo, huggingface_local_completions o antrópico.<name>_completions y dependencias en INIT . Nuevamente puede seguir el ejemplo de Huggingface_local_completionsalpaca_eval evaluate_from_model --model_configs '<model_configs>'Siéntase libre de comenzar un relaciones públicas temprano, ¡podremos proporcionar ayuda en el proceso!
La tubería de evaluación Alpacaeval, al igual que otros evaluadores actuales, tienen limitaciones importantes y, por lo tanto, no deben usarse como reemplazo para la evaluación humana en entornos importantes, como decidir si un modelo está listo para implementarse. Esos pueden agruparse ampliamente en 3 categorías:
Las instrucciones pueden no ser representativas del uso real : el conjunto Alpacaeval contiene ejemplos de una variedad de conjuntos de datos (autoinstructo, asistente abierto, vicuna, koala, HH-RLHF) que podrían no ser representativos de aplicaciones de uso real y avanzados de mejores modelos como GPT4. Esto probablemente hace que los mejores modelos cerrados (GPT4 / CLAUDE / CHATGPT / ...) parezcan más similares a los modelos abiertos que los que son. De hecho, esos modelos cerrados parecen estar provocados/finetos con datos mucho más diversos. Vea, por ejemplo, este blog para obtener resultados preliminares sobre instrucciones más complejas. Sin embargo, tenga en cuenta que en Alpacafarm demostramos que las tasas de victorias en nuestro conjunto de evaluación están altamente correlacionadas (0.97 R2) con tasas de victorias en las instrucciones de las interacciones del usuario con la demostración de Alpaca. Además, la tabla de clasificación Alpacaeval muestra una mayor brecha entre los modelos abiertos y los modelos OpenAI que otras tablas de clasificación (por ejemplo, LMSYS).
Sesgos de anotadores automáticos : los anotadores automáticos en bruto parecen tener sesgos implícitos. En particular, encontramos que tienden a preferir salidas y salidas más largas que contienen listas (por ejemplo, 0.68 / 0.69 para alpaca_eval_gpt4 y 0.62 / 0.58 para claude ). Aunque encontramos que los humanos tienen sesgos similares (0.64 / 0.61), creemos que esto podría ser más una limitación de la tubería de anotación humana que utilizamos en lugar de un verdadero sesgo humano. En términos más generales, a través del análisis cualitativo, encontramos que los anotadores automáticos dan más importancia al estilo de la producción que su contenido (por ejemplo, hecho de hecho). Finalmente, encontramos que los evaluadores automáticos tienden a preferir los resultados de los modelos que son similares (probablemente entrenados en los mismos datos) según lo sugerido por la gran diferencia entre ChatGPT/GPT4 en la tabla de clasificación de claude y alpaca_eval_gpt4 . Tenga en cuenta que el sesgo de longitud se mitiga parcialmente en nuestras tasas de victorias controladas por longitud.
Falta de evaluación de seguridad : lo más importante, Alpacaeval solo evalúa las capacidades de seguimiento de la instrucción de los modelos en lugar del daño que podrían causar (por ejemplo, comportamiento tóxico o sesgo). Como resultado, la pequeña brecha entre el CHATGPT actual y los mejores modelos de código abierto no debe interpretarse como si estos últimos estén listos para implementarse.
Más allá de esas limitaciones sobre las tuberías de evaluación, también existen limitaciones sobre nuestra validación de los evaluadores y nuestro enfoque propuesto para seleccionar conjuntos de evaluación.
Primero, nuestra validación de los evaluadores basados en anotaciones cruzadas humanas sufre de las siguientes limitaciones: (1) descubrimos cualitativamente que nuestros trabajadores de la multitud también tienden a favorecer el estilo como la longitud y la presencia de listas sobre la fáctica; (2) Esto no valida si las tasas de victorias contra un modelo de referencia es una buena estrategia de evaluación en primer lugar; (3) Las preferencias de 16 trabajadores de la multitud no son representativas de las preferencias de todos los humanos.
En segundo lugar, nuestro enfoque sugerido para seleccionar conjuntos de evaluación basados en el poder estadístico sufre de las siguientes limitaciones: (1) El poder estadístico no garantiza la dirección correcta, por ejemplo, puede tener un conjunto no natural de instrucciones donde Alpaca "funciona" mejor que un mejor modelo; y (2) esto puede impulsar a los usuarios a seleccionar datos para respaldar la hipótesis que desean validar.
Visualizaciones alpacaevales controladas por longitud:
Desarrollo Alpacaeval controlado por la longitud:
El cuaderno muestra diferentes opciones que consideramos para mitigar el sesgo de longitud de los anotadores automáticos.
Aquí resumimos brevemente los principales resultados. A saber:


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 ejemplo:
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 .