Resolve double counting across original and multilingual evals
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- javascript
- Área
- analytics
Línea de trabajo
Start by reading the existing canonical eval/scoring-group and aggregation logic, plus the warnings/inspection views and configuration documentation; no file paths are named in the issue. First agree on the grouping and overlap policy, then trace how it affects standard and English-balanced scores and effective eval weights. Done means implementing and documenting the policy, exposing protocol/task identity and unused data, and passing the listed representative A/B, coverage, reconciliation, and aggregation checks.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Resolve how original and multilingual eval variants contribute to the same comparison, including repeated English measurements. Follow-up to #1; this work is deferred from that PR and does not block its merge.
Status: open follow-up. Ownership: Quickdash maintainer (unassigned). Next action: agree on scoring groups and language exclusions, then implement and test the policy. No implementation dependency on an external service.
Current behavior and evidence:
- MGSM combines
global_mgsmandmgsm_native_cot. Both can contribute English; the inspected export also has German, Spanish, and French in both protocols. The English entries use different few-shot settings (0 versus 5). - PIQA combines
piqaandglobal_piqa_completions. Both can contribute English, with different few-shot settings (10 versus 0) and sample counts. - ARC Challenge combines
arc_challengeandarc_challenge_mt. The inspected export has English only in the original task, so there is no repeated English measurement there. Other exports still need a defined policy. - MMLU and Global MMLU are intentionally separate evals and both include English. Review overlap without silently undoing that decision.
These observations establish repeated language measurements, not identical underlying question sets. Investigate task implementations/data before claiming item-level duplication. No private scores or model identities are needed in this issue.
Sampo proposed keeping translated variants separately named and dropping English from multilingual results where the original supplies English. Decide whether this is the desired policy and how to handle overlapping non-English MGSM variants and missing original-language coverage.
The dashboard already has two naming levels: a canonical eval/scoring group, and exact source task names visible in expanded views. There is no intermediate protocol subgroup. Splitting canonical evals changes their equal shares within a category; it is not merely a label change. English-balanced modes retain the configured English share but average multiple English measurements within it.
Acceptance checks:
- Document the chosen grouping and overlap policy, including original/multilingual naming, English exclusion, non-English overlap, and MMLU/Global MMLU treatment.
- Keep global interpretation rules distinct from comparison membership; express exclusions explicitly and make unused data visible through the existing warnings/inspection views.
- Verify the policy against representative A/B inputs, including multilingual-only data and asymmetric coverage. Missing measurements must not silently enter one side's score.
- Test standard, English-per-eval, and English-per-category aggregation, contribution reconciliation, and any intended change to effective eval weights.
- Ensure breakdowns expose protocol/task identity, and update configuration documentation with a concrete example.
- Explain remaining differences from Sampo's aggregation once his grouping policy is established; matching metric/baseline tables alone is insufficient.
- Lenguaje dominante
- Python
- Estrellas
- 0
- Forks
- 1
- Merge medio
- 2 h
- PR fusionados (30 d)
- 14
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Issues similares
-
Uninstall guide omits the CloudWatch log groups AWS CodeBuild creates for useCodeBuild pipelinesAbiertobug documentation
Dificultad 1/5 1-3 horas Aptitud para principiantes 88/100
awslabs/visual-asset-management-system#552 ·
Los mantenedores suelen responder en 1 día
-
netbox status: needs triage type: documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 76/100
netbox-community/netbox#23460 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
awslabs/threat-composer#362 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
ansys/pyansys-common-mcp#213 ·
Los mantenedores suelen responder en 3 días