Problem
Сейчас агрегация результатов benchmark-экспериментов не выделена в единый модуль с понятным контрактом. Наиболее актуальные результаты лежат kernel_learning_ucr_suite_c44f2a9f6c можно использовать как референсную структуру: там уже есть runs, records, aggregate, metrics.csv, leaderboard.csv, predictions.csv, runs.csv, summary.md, errors.jsonl и другие артефакты.
Основная проблема в том, что правила агрегации зависят от типа задачи. Для классификации, регрессии и прогнозирования отличаются метрики, правила выбора лучшего результата, формат predictions, дополнительные визуализации и итоговые таблицы. Сейчас это не выражено как отдельная архитектурная сущность, поэтому разные benchmark-запуски могут агрегироваться по-разному и становиться несопоставимыми.
Why
Без единого aggregation-модуля результаты экспериментов сложно проверять, обновлять и использовать как основу для benchmark-витрины. Каждый runner может неявно реализовывать собственную логику агрегации, что увеличивает риск дублирования, ошибок в выборе best-result и расхождений между classification/regression/forecasting benchmark-ами.
Для Kernel Learning это особенно важно, потому что результаты должны стать воспроизводимой базой для сравнения моделей Industrial между собой, с предыдущими версиями и с SoTA baseline-ами.
Scope
1.Выделить единый модуль агрегации результатов экспериментов внутри актуального benchmark-пакета.
2.Использовать benchmark/results/v2_kernel_learning/ucr_suite_020626/kernel_learning_ucr_suite_c44f2a9f6c как reference-пример ожидаемой структуры входных и выходных артефактов.
3.Описать общий контракт входных данных для агрегации: runs, records, metrics, predictions, errors, metadata и task-specific diagnostics.
4.Описать общий контракт выходных данных: leaderboard.csv, metrics.csv, predictions.csv, runs.csv, run_metadata.json, summary.md и дополнительные task-specific артефакты.
5.Разделить общую aggregation-логику и task-specific правила для:
5.1. classification;
5.2. regression;
5.3. forecasting.
6. Для каждого типа задачи определить правила выбора лучшего результата: основная метрика, направление оптимизации, группировка по dataset/model/run, обработка failed-runs.
7. Сохранить поддержку Kernel Learning-specific артефактов, например kernel_diagnostics.jsonl и kernel_selection.jsonl, если они есть в запуске.
8. Сделать UCR classification benchmark первым поддержанным reference-сценарием.
9. После этого расширить тот же aggregation-подход на TSER и forecasting результаты из benchmark/results/v2_kernel_learning.
10. Добавить минимальные проверки, что агрегация воспроизводимо строит итоговые таблицы из reference-run.
Problem
Сейчас агрегация результатов benchmark-экспериментов не выделена в единый модуль с понятным контрактом. Наиболее актуальные результаты лежат kernel_learning_ucr_suite_c44f2a9f6c можно использовать как референсную структуру: там уже есть runs, records, aggregate, metrics.csv, leaderboard.csv, predictions.csv, runs.csv, summary.md, errors.jsonl и другие артефакты.
Основная проблема в том, что правила агрегации зависят от типа задачи. Для классификации, регрессии и прогнозирования отличаются метрики, правила выбора лучшего результата, формат predictions, дополнительные визуализации и итоговые таблицы. Сейчас это не выражено как отдельная архитектурная сущность, поэтому разные benchmark-запуски могут агрегироваться по-разному и становиться несопоставимыми.
Why
Без единого aggregation-модуля результаты экспериментов сложно проверять, обновлять и использовать как основу для benchmark-витрины. Каждый runner может неявно реализовывать собственную логику агрегации, что увеличивает риск дублирования, ошибок в выборе best-result и расхождений между classification/regression/forecasting benchmark-ами.
Для Kernel Learning это особенно важно, потому что результаты должны стать воспроизводимой базой для сравнения моделей Industrial между собой, с предыдущими версиями и с SoTA baseline-ами.
Scope
1.Выделить единый модуль агрегации результатов экспериментов внутри актуального benchmark-пакета.
2.Использовать benchmark/results/v2_kernel_learning/ucr_suite_020626/kernel_learning_ucr_suite_c44f2a9f6c как reference-пример ожидаемой структуры входных и выходных артефактов.
3.Описать общий контракт входных данных для агрегации: runs, records, metrics, predictions, errors, metadata и task-specific diagnostics.
4.Описать общий контракт выходных данных: leaderboard.csv, metrics.csv, predictions.csv, runs.csv, run_metadata.json, summary.md и дополнительные task-specific артефакты.
5.Разделить общую aggregation-логику и task-specific правила для:
5.1. classification;
5.2. regression;
5.3. forecasting.
6. Для каждого типа задачи определить правила выбора лучшего результата: основная метрика, направление оптимизации, группировка по dataset/model/run, обработка failed-runs.
7. Сохранить поддержку Kernel Learning-specific артефактов, например kernel_diagnostics.jsonl и kernel_selection.jsonl, если они есть в запуске.
8. Сделать UCR classification benchmark первым поддержанным reference-сценарием.
9. После этого расширить тот же aggregation-подход на TSER и forecasting результаты из benchmark/results/v2_kernel_learning.
10. Добавить минимальные проверки, что агрегация воспроизводимо строит итоговые таблицы из reference-run.