Kernel learning

[v1docq]

Коммит развивает трек Kernel Learning / Kernel Ensemble и переводит текущий модуль от MVP-каркаса к более строгой архитектуре:

1. typed domain contracts
2. pure-core правила для матриц и выбора весов
3. новые генераторы признаков
4. forecasting estimator
5. cache/report слой
6. расширенная интеграция с FEDOT warm-start.

PR-001: Harden Kernel Contracts And Matrix Semantics

Изменены:

• fedot_ind/core/kernel_learning/contracts.py
• fedot_ind/core/kernel_learning/kernels/builder.py
• fedot_ind/core/kernel_learning/init.py

Что сделано:

• В contracts.py добавлены KernelTaskType, KernelNormalization, PSDCorrectionPolicy и KernelMatrixPolicy.
• Для FeatureBundle, KernelBundle и KernelSelectionReport добавлены to_dict(), чтобы diagnostics и reports можно было стабильно сохранять в JSON artifacts.
• KernelMatrixBuilder теперь явно валидирует train/test feature matrix, train kernel и cross-kernel shapes.
• Добавлен guard против ситуации, когда distance matrix ошибочно используется как kernel matrix.
• Diagnostics builder теперь содержат JSON-friendly policy payload.

Содержательное влияние:

• Kernel Learning получает явный train/test kernel contract.
• Ошибка “расстояние вместо ядра” теперь ловится на уровне builder.
• Kernel diagnostics можно безопасно писать в benchmark artifacts.

PR-002: Replace Heuristic Selector With Sparse Adaptive MKL Objective

Изменены:

• fedot_ind/core/kernel_learning/selection/sparse_mkl.py
• fedot_ind/core/kernel_learning/selection/init.py

Что сделано:

• Добавлены MKLObjectiveConfig и MKLOptimizationResult.
• SparseMKLSelector расширен projected-gradient оптимизацией весов на simplex.
• Старый score-based режим сохранён как fallback через optimizer="score".
• В KernelSelectionReport.diagnostics теперь сохраняются optimizer, iterations, converged, objective_history и zeroed_generators.

Содержательное влияние:

• Выбор kernel weights стал не просто нормировкой эвристических score, а настоящей оптимизацией sparse MKL objective.
• Можно сравнивать heuristic baseline и adaptive MKL в benchmark.

PR-003: Stabilize Classifier/Regressor And FEDOT Warm Start

Изменены:

• fedot_ind/core/kernel_learning/estimators/base.py
• fedot_ind/core/kernel_learning/estimators/classifier.py
• fedot_ind/core/kernel_learning/estimators/regressor.py
• fedot_ind/api/utils/industrial_strategy.py

Что сделано:

• KernelEnsembleBase принимает selector_optimizer, selector_max_iter, selector_tol, selector_step_size.
• Classifier/regressor получили совместимые параметры kernel_approximation и nystrom_components.
• После fit сохраняется fit_diagnostics_ с kernel bundle summaries, selected generators и selector diagnostics.
• IndustrialStrategy теперь выбирает estimator по task type через estimator_by_problem.

Содержательное влияние:

• Classifier/regressor не сломаны, но теперь могут использовать новый MKL optimizer и Nystrom approximation.
• FEDOT warm-start получает больше диагностической информации для аудита выбранных генераторов.

PR-004: Topological Kernel Generator Under Budget Control

Изменены:

• fedot_ind/core/kernel_learning/generators/adapters.py
• fedot_ind/core/kernel_learning/generators/init.py

Что сделано:

• Добавлен GeneratorBudgetPolicy.
• Добавлен BudgetedRepositoryFeatureGeneratorAdapter.
• topological_extractor зарегистрирован как budgeted generator с fallback_generator="identity".
• Diagnostics фиксируют budget, skip_reason и fallback path.

Содержательное влияние:

• Topology можно подключать без риска уронить запуск из-за тяжёлой операции или недоступной зависимости.
• Если topology недоступен или превышает budget, pipeline продолжает работать и сообщает причину.

PR-005: Shapelet And Local Pattern Kernel Generators

Изменены:

• fedot_ind/core/kernel_learning/generators/adapters.py
• fedot_ind/core/kernel_learning/generators/init.py

Что сделано:

• Добавлен ShapeletFeatureGenerator.
• Зарегистрированы shapelet_extractor и local_pattern_extractor.
• Shapelet distances возвращаются как feature representation, а не как kernel matrix.

Содержательное влияние:

• Соблюдается архитектурное правило: distance features сначала превращаются в признаки, затем KernelMatrixBuilder строит валидное ядро.
• Kernel ensemble теперь может выбирать motif/local-pattern similarity как один из источников.

PR-006: Embedding And Foundation Feature Kernel Adapters

Изменены:

• fedot_ind/core/kernel_learning/generators/adapters.py
• fedot_ind/core/kernel_learning/generators/init.py

Что сделано:

• Добавлен RandomProjectionEmbeddingFeatureGenerator.
• Зарегистрированы embedding_extractor и foundation_embedding.
• Реализация deterministic, CPU-safe и без внешних model downloads.

Содержательное влияние:

• Появился lightweight stand-in для deep/foundation embeddings.
• Benchmark может сравнивать classical generators против embedding-like representation без тяжёлой зависимости.

PR-007: Forecasting Target Kernels And OKHS Adapter

Изменены:

• fedot_ind/core/kernel_learning/selection/targets.py
• fedot_ind/core/kernel_learning/selection/init.py
• fedot_ind/core/kernel_learning/estimators/forecasting.py

Что сделано:

• Добавлен ForecastTargetSpec.
• TargetKernelBuilder теперь поддерживает forecasting и ts_forecasting.
• Добавлены horizon-aware target kernels и forecastability_prior.
• Добавлен OKHSForecastHeadAdapter как OKHS-compatible precomputed-kernel head.

Содержательное влияние:

• Forecasting больше не маскируется под обычную regression target kernel.
• Можно строить alignment относительно multi-horizon target structure.

PR-008: KernelEnsembleForecaster Public Estimator

Изменены:

• fedot_ind/core/kernel_learning/estimators/forecasting.py
• fedot_ind/core/kernel_learning/estimators/init.py
• fedot_ind/core/kernel_learning/init.py
• fedot_ind/api/utils/industrial_strategy.py
• fedot_ind/core/kernel_learning/integration/initial_population_builder.py

Что сделано:

• Добавлен публичный KernelEnsembleForecaster.
• Поддержаны single-horizon и multi-horizon targets.
• Добавлена поддержка head_type="kernel_ridge" и OKHS-compatible head modes.
• KernelInitialPopulationBuilder теперь принимает forecasting и ts_forecasting.
• Для forecasting warm-start default head теперь ridge, а не treg.
• IndustrialStrategy route расширен на forecasting.

Содержательное влияние:

• Kernel Learning теперь покрывает три task-семейства: classification, regression, forecasting.
• FEDOT warm-start может строить initial assumptions для forecasting отдельно от regression.

PR-009: Cache, Approximation, Reports, Benchmarks, Legacy Cleanup

Добавлены:

• fedot_ind/core/kernel_learning/cache.py
• fedot_ind/core/kernel_learning/kernels/approximation.py
• fedot_ind/core/kernel_learning/reports.py

Изменены:

• fedot_ind/core/kernel_learning/kernels/builder.py
• fedot_ind/core/kernel_learning/kernels/init.py
• fedot_ind/core/kernel_learning/init.py

Что сделано:

• Добавлены KernelCachePolicy, KernelCacheKey, InMemoryKernelCache.
• Добавлены fingerprint_array и fingerprint_mapping.
• Добавлены NystromApproximationPolicy и NystromKernelApproximator.
• KernelMatrixBuilder получил optional approximation="nystrom".
• Добавлены KernelLearningReport, build_kernel_learning_report и TEXT2IMAGE_PROMPTS.

Содержательное влияние:

• Kernel Learning получил основу для cache/budget/approximation experiments.
• Nystrom можно включать как controlled approximation policy.
• Reports теперь могут включать selection, importance, kernel bundles и prompts для визуализации математической идеи PR.

Tests

Добавлены:

• tests/unit/core/kernel_learning/test_cache.py
• tests/unit/core/kernel_learning/test_contracts_reports.py

Изменены:

• tests/unit/core/kernel_learning/test_kernel_matrix_builder.py
• tests/unit/core/kernel_learning/test_selection.py
• tests/unit/core/kernel_learning/test_generators.py
• tests/unit/core/kernel_learning/test_estimators.py
• tests/unit/core/kernel_learning/test_initial_population_builder.py

Проверено:

• tests/unit/core/kernel_learning -q: 46 passed
• tests/unit/api/utils/test_kernel_warm_start_strategy.py -q: 3 passed

Тесты запускались через локальное окружение venv_3.9_new с PYTEST_DISABLE_PLUGIN_AUTOLOAD=1,

[v1docq]

Обзор KL-изменений перед вливанием в main

Область	Оценка	Почему
Постановка задачи, цели и ограничения	8/10	У серии KL понятные цели - убрать старую структуру бенчмарков, ввести типизированный запуск, открыть модели Kernel Learning и сделать примеры воспроизводимыми.
Риски	6/10	Риски бенчмарков и артефактов частично закрыты статусами запусков, журналами ошибок и политикой архивов.
Предыдущие решения и сравнения	9/10	В витрине сравниваются текущий Industrial, старый Industrial, SoTA-результаты, простые базовые модели и варианты Kernel Learning. Для прогнозирования пока нет полноценного SoTA-источника в основной витрине.
Метрики и измерение качества	8/10	Метрики задач и направление оптимизации явно заданы в типизированных конфигурациях и манифестах результатов. Доверительные интервалы, разброс и пороги приемки пока не стали частью контракта.
Данные, разметка и признаки	7/10	Корни данных, манифесты, наборы генераторов и каталоги артефактов видимы. Ссылки на внешнее хранилище пока частично заглушены, а часть локальных сценариев не имеет опубликованного пути получения данных.
Проверка качества и утечки данных	6.5/10	Публичные разбиения бенчмарков и типизированные адаптеры данных снижают риск ошибок. Для пользовательских и локальных наборов данных нужен явный чек-лист против утечек между обучением и проверкой.
Разбор ошибок	B	В пакетах результатов появились покрытие, приросты/просадки, средние ранги, лучших k, диагностика, частоты генераторов, изменение параметров и история эволюции. Разбор доменных ошибок пока неоднороден.
Обучение и воспроизводимость	B+	Типизированные конфигурации, JSON-настройки, возобновляемые артефакты, зарегистрированные запуски и точечные тесты сильно лучше разрозненных скриптов. Полный перезапуск ноутбуков все еще зависит от локальных данных и окружения.
Интеграция и выпуск	5.5/10	Публичные адаптеры бенчмарков, теплый старт для FedotIndustrial и слой инструментов для внешних агентов уже есть. Промышленный выпуск, требования к задержкам и план раскатки не входят в этот PR.
Сопровождение и владение	6/10	Инструкции по запуску и команды проверки есть, но нет легкой таблицы владельцев, правила обновления результатов и цикла контроля свежести бенчмарков и примеров.

Главное исправление перед вливанием - сделать отдельный проход по документации. Надо перенаправить или архивировать материалы про benchmark.v2, обновить старые быстрые инструкции и заполнить реальные ссылки на внешние данные или DVC-хранилище. Рефакторинг бенчмарков вызывает доверие тогда, когда код,
метрики, результаты запусков и примеры смотрят в один и тот же типизированный контракт. После KL-серии этот контракт появился, но его нужно поддерживать в документации и данных.

Резюме

Серия KL переводит IndustrialTS из состояния «много полезных, но разрозненных
скриптов и локальных артефактов» в более явную ML-систему:

• benchmark.industrial стал основным исполняемым слоем для бенчмарков.
• fedot_ind.core.kernel_learning стал публичной подсистемой Kernel Learning:
  в нем есть модули оценки, ядра, генераторы признаков, sparse MKL, кеш,
  отчеты и интеграция с теплым стартом.
• Эксперименты по бенчмаркам теперь задаются через типизированные сущности:
  BenchmarkSuiteConfig, DatasetSpec, ModelSpec, RunSpec, ArtifactSpec.
• Анализ результатов вынесен из ноутбуков и ручной обработки CSV в общие
  модули агрегации и визуализации.
• В папке examples появились понятные роли: утилиты текущего API,
  прикладные сценарии, инструменты для внешних агентов и единая папка для
  артефактов.
• Исторические результаты больше не выглядят как исполняемый код. Они
  индексируются как справочные данные через манифесты и витрины результатов.

Это крупное архитектурное улучшение. Что надо доделать - навигацию для нового разработчика: в репозитории все еще есть старые материалы про benchmark.v2, ссылки на внешние данные частично остаются
заглушками, а новая поверхность API достаточно широка, чтобы устаревшая
документация могла сбить с толку.

Что было проверено

Код и документация:

• docs/dev_guide/benchmark_infrastructure.md:9 задает benchmark.industrial
  как основной исполняемый пакет бенчмарков.
• docs/dev_guide/benchmark_infrastructure.md:44 описывает контракт
  типизированных конфигураций.
• docs/dev_guide/benchmark_infrastructure.md:124 описывает ответственность
  за хранение результатов.
• docs/dev_guide/benchmark_infrastructure.md:201 описывает правила агрегации
  и визуализации.
• docs/dev_guide/benchmark_infrastructure.md:315 перечисляет, чего не стоит
  делать в новых изменениях.
• docs/dev_guide/kernel_learning_benchmark_runbook.md:31 задает правила
  конфигурации запусков Kernel Learning.
• docs/dev_guide/kernel_learning_benchmark_runbook.md:63 и
  docs/dev_guide/kernel_learning_benchmark_runbook.md:108 описывают первый и
  второй этап Kernel Learning.
• examples/README.md:7 описывает текущее назначение подпапок в examples.
• examples/tools_example/README.md:15 описывает каталог инструментов для MCP
  и внешних агентов.
• examples/artifacts/README.md:8 описывает общий центр артефактов.
• benchmark/results/showcase/README.md:14 описывает публичные направления
  бенчмарков.

Сводка изменений относительно origin/main:

• изменено 789 файлов;
• добавлено 104 638 строк;
• удалено 198 171 строка;
• большой объем удалений связан в основном с очисткой старых примеров,
  локальных фикстур данных, benchmarking_utils, benchmark/v2 и устаревших
  ноутбуков.

Цепочка связанных issues:

• начальные коммиты с реализацией Kernel Learning;
• KL-101: реорганизация модуля бенчмарков;
• KL-102: единые типизированные конфигурации запусков;
• KL-103: переработка примеров, прикладных сценариев и центра артефактов;
• KL-104: витрина результатов бенчмарков;
• KL-105: инфраструктурные контракты бенчмарков;
• KL-106: единый слой агрегации результатов;
• KL-201: упрощение и типизация контрактов Kernel Learning;
• KL-202: контракт генераторов признаков и крайние случаи;
• KL-301: кеш, диагностика и обработка ошибок второго этапа;
• KL-302: настройки запусков по умолчанию и удобство пользовательских данных;
• KL-401: разделение адаптеров генераторов по тематическим модулям.

Было и стало

Область	Было	Стало
Исполняемый слой бенчмарков	Одновременно существовали benchmark/v2, корневые скрипты бенчмарков и benchmarking_utils. Было трудно понять, какой путь считать основным.	benchmark.industrial стал основным пакетом. Старые обертки, где они еще нужны, живут в benchmark.industrial.legacy; исполняемый benchmark.v2 удален.
Точки запуска экспериментов	Скрипты были разбросаны и часто смешивали константы, описания моделей, сохранение результатов и сам запуск.	Эксперименты сгруппированы по типу задач в benchmark/experiments/kernel_learning/{classification,regression,forecasting,analysis} и используют типизированные конфигурации.
Настройки по умолчанию	Списки моделей, метрики, наборы данных и шаблоны выходных папок часто были зашиты в Python-файлы.	Настройки вынесены в JSON, например benchmark/experiments/kernel_learning/defaults.json и benchmark/industrial/experiments/preset_defaults.json.
Агрегация результатов	Ноутбуки и отдельная CSV-логика каждый раз заново собирали сравнения.	benchmark.industrial.evaluation.aggregation и result_analysis дают общий путь чтения, проверки покрытия, ранжирования, подсчета приростов, диагностики и сборки отчетов.
Витрина результатов	benchmark/results смешивал архивы, SoTA-таблицы, текущие результаты и локальные артефакты.	benchmark/results/showcase дает манифестную витрину текущего Industrial, старого Industrial и SoTA-таблиц.
Примеры	automl_example, benchmark_v2, data, outdated_examples, rkhs_okhs и real_world_examples пересекались по назначению.	examples/utils, examples/tools_example, examples/real_world_examples и examples/artifacts получили явные роли.
Kernel Learning	Направление уже развивалось, но уровень публичного API был менее явным.	fedot_ind.core.kernel_learning открывает оцениватели, контракты, ядра, генераторы, методы выбора, отчеты, кеш и интеграцию с теплым стартом.
Двухэтапная эволюция	Артефакты первого и второго этапа, а также состояния ошибок было трудно переиспользовать.	Первый и второй этап имеют API-классы экспериментов, загружаемые артефакты, диагностику, статусы пропуска/ошибок и ленивые предположения PipelineBuilder.
Инструменты для агентов	Примеры в основном были скриптами или ноутбуками.	examples/tools_example дает сервисный слой с JSON-запросами и ответами для загрузки данных, обучения, эволюции, PDL и детекции аномалий.
Правила разработки	Архитектурные правила жили в обсуждениях и ревью.	FEDOT-навыки и документация бенчмарков фиксируют локальность реализаций, типизированные конфигурации, вынесение констант в JSON, инвариантные тесты и короткие публичные индексы.

Что изменилось в работе фреймворка

1. Запуск бенчмарков стал типизированным и привязанным к реестру

Новые запуски должны сводиться к схеме:

typed_config.build_suite_config() -> run_registered_suite(...)

Это важно, потому что BenchmarkSuiteConfig теперь несет тип задачи, наборы
данных, модели, метрики, параметры запуска и правила сохранения артефактов как
один проверяемый объект. Разработчику больше не нужно искать константы по
нескольким скриптам, чтобы понять, что именно будет запущено.

Ключевые файлы:

• benchmark/industrial/core.py
• benchmark/industrial/experiments/registry.py
• benchmark/industrial/experiments/manifests.py
• benchmark/industrial/experiments/presets.py
• benchmark/experiments/kernel_learning/configs.py
• benchmark/experiments/kernel_learning/defaults.json

Практический эффект для разработчика:

• использовать ModelSpec и DatasetSpec вместо ручных словарей параметров;
• добавлять новые наборы настроек через JSON рядом с тематическим модулем;
• использовать манифесты для воспроизводимых запусков;
• запускать сохранение через run_registered_suite или
  run_registered_manifest_path.

2. Стало ясно, где живет код бенчмарков

benchmark.industrial теперь единственный правильный исполняемый пакет для
нового кода бенчмарков. Старый пакет benchmarking_utils удален, а benchmark/v2
перенесен и переработан в benchmark/industrial.

Публичный пакет использует ленивые экспорты: легкие импорты вроде ModelSpec
не должны сразу подтягивать необязательные зависимости для прогнозирования или
глубокого обучения.

Ключевые файлы:

• benchmark/industrial/__init__.py
• benchmark/industrial/classification.py
• benchmark/industrial/regression.py
• benchmark/industrial/forecasting.py
• benchmark/industrial/datasets/local_io.py
• benchmark/industrial/legacy/*

Практический эффект для разработчика:

• новый исполняемый код должен жить в тематическом подпакете
  benchmark.industrial;
• __init__.py должен оставаться коротким публичным указателем;
• старые корневые классы бенчмарков допустимы только как совместимые обертки;
• исторические пути v2_kernel_learning являются источниками данных, а не
  импортируемыми модулями.

3. Результаты запусков стали полноценными входными данными анализа

Запуски теперь сохраняют достаточно информации, чтобы пересобрать таблицы без
повторного обучения:

records/
  runs.jsonl
  metrics.jsonl
  predictions.jsonl
  kernel_diagnostics.jsonl
  kernel_selection.jsonl
aggregate/
  runs.csv
  metrics.csv
  predictions.csv
  leaderboard.csv
  run_metadata.json
  summary.md
resolved_config.json
resolved_manifest.json
run_summary.json
artifact_manifest.json

Это важное изменение для всей системы: анализ результатов больше не привязан к
состоянию ноутбука или локальному Python-объекту.

Ключевые файлы:

• benchmark/industrial/experiments/artifacts.py
• benchmark/industrial/evaluation/aggregation.py
• benchmark/industrial/evaluation/result_analysis.py
• benchmark/industrial/visualization/benchmark_results.py
• benchmark/industrial/visualization/forecast_comparison.py

Практический эффект для разработчика:

• ошибки и пропущенные запуски остаются видимыми в записях;
• основные сравнительные таблицы используют успешные строки метрик, если отчет
  явно не посвящен ошибкам;
• покрытие, список отсутствующих наборов данных, метаданные источников,
  диагностику, изменение параметров, приросты и лучших k можно пересобрать единым
  способом.

4. Kernel Learning стал отдельной подсистемой фреймворка

fedot_ind.core.kernel_learning теперь выглядит не как набор экспериментальных
скриптов, а как публичная подсистема.

Основные части:

• contracts.py: тип задачи, нормализация, исправление PSD, аппроксимация,
  набор признаков, набор ядер, отчет о выборе.
• estimators/: KernelEnsembleClassifier, KernelEnsembleRegressor,
  KernelEnsembleForecaster.
• generators/: базовые контракты, адаптеры репозитория, легкие генераторы,
  спецификации операций, реестр.
• kernels/: сборка матриц ядер, оценка сложности, аппроксимация Нистрема.
• selection/: sparse MKL, целевые ядра, отчеты о важности.
• integration/: определение задачи теплого старта и сборка начальных популяций.
• experiments_api/: загружаемые артефакты первого и второго этапа, а также
  классы запуска.
• cache.py: детерминированный кеш ядер по отпечаткам массива и конфигурации.

Практический эффект для разработчика:

• прямые пользователи могут импортировать оцениватели из
  fedot_ind.core.kernel_learning;
• пользователи бенчмарков получают те же оцениватели через адаптеры моделей
  benchmark.industrial;
• расширение генераторов теперь идет через реестр и спецификации операций, а не
  через один большой файл adapters.py;
• второй этап эволюционной оптимизации может использовать генераторы,
  выбранные на первом этапе, как ленивые предположения теплого старта
  PipelineBuilder.

5. Генераторы признаков разложены по тематическим модулям

После KL-401 старый крупный файл адаптеров генераторов разделен:

fedot_ind/core/kernel_learning/generators/
  base.py        общие контракты, нормализация, преобразование входов FEDOT
  repository.py  адаптеры репозитория и политики вычислительного бюджета
  lightweight.py identity, shapelet, random projection embedding
  specs.py       спецификации операций и параметры по умолчанию
  registry.py    реестр генераторов и разрешение спецификаций операций
  adapters.py    фасад совместимости

Публичные импорты при этом сохранены, но будущие изменения генераторов стало
намного проще читать и проверять.

Практический эффект для разработчика:

• новая реализация генератора должна жить в тематическом модуле, который
  отвечает за ее поведение;
• adapters.py должен оставаться фасадом совместимости;
• registry.py отвечает за публичные имена вроде wavelet_extractor,
  embedding_extractor или tabular_extractor;
• политики бюджета и запасные варианты выполнения изолированы в
  repository.py.

6. Эксперименты Kernel Learning используют актуальные модели Industrial

Стандартный набор бенчмарков Kernel Learning теперь включает:

• классификация:
  • KernelEnsembleClassifier_score_baseline_summary;
  • KernelEnsembleClassifier_adaptive_all_non_topological;
  • KernelEnsembleClassifier_shapelet_motif_rbf;
  • KernelEnsembleClassifier_embedding_nystrom;
• регрессия:
  • KernelEnsembleRegressor_score_linear_summary;
  • KernelEnsembleRegressor_adaptive_rbf_summary;
  • KernelEnsembleRegressor_shapelet_rbf;
  • KernelEnsembleRegressor_embedding_nystrom;
• прогнозирование:
  • NaiveLastValue;
  • LaggedRidgeForecaster;
  • KernelEnsembleForecaster_identity_shapelet;
  • KernelEnsembleForecaster_embedding_nystrom_okhs.

Настройки по умолчанию также задают:

• наборы нетопологических генераторов;
• метрики для конкретных задач;
• шаблоны выходных папок;
• поведение возобновляемых запусков;
• поиск последнего первого этапа для двухэтапных запусков;
• custom_dataset_policy для поведения на UCR и пользовательских данных.

7. Первый и второй этап Kernel Learning стали восстанавливаемыми процессами

Первый этап теперь записывает диагностику ядер и артефакты выбранных
генераторов. Их можно загрузить позже. Второй этап может либо запустить первый
этап, либо взять уже существующий запуск. Если второй этап не может собрать
начальную популяцию, он записывает структурированный статус пропуска или ошибки,
а не теряет состояние.

Ключевые файлы:

• fedot_ind/core/kernel_learning/experiments_api/stage1.py
• fedot_ind/core/kernel_learning/experiments_api/stage2.py
• benchmark/experiments/kernel_learning/classification/run_ucr_two_stage.py
• benchmark/industrial/evaluation/kernel_learning.py

Практический эффект для разработчика:

• использовать KernelLearningStage1Runner для первого этапа на UCR;
• использовать KernelLearningStage2Runner для эволюции FEDOT с теплым стартом;
• не задавать stage1_run_id, если нужен автоматический поиск последнего
  первого этапа;
• использовать функции анализа, чтобы смотреть выбор генераторов до запуска
  второго этапа.

8. Витрина результатов стала публичным окном состояния моделей

benchmark/results/showcase теперь отвечает на вопрос: «Как сейчас выглядят
модели Industrial по сравнению с SoTA и предыдущими версиями Industrial?»

Витрина индексирует:

• UCR/UEA univariate classification;
• multivariate classification;
• TSER regression;
• M4 monthly forecasting.

Она также формирует:

• опись источников;
• обзор бенчмарков;
• лучшие результаты по наборам данных;
• кандидатов на архивирование;
• сводные пакеты по каждому направлению.

Практический эффект для разработчика:

• использовать python -m benchmark.results.showcase для пересборки основной
  витрины;
• добавлять новые публичные сравнения через showcase_manifest.json;
• не включать сырые исторические папки в публичные таблицы, если манифест явно
  не называет их источниками.

9. Примеры переорганизованы по роли в воспроизводимости

Структура examples теперь основана на назначении:

examples/
  utils/                  утилиты текущего API и маленькие фикстуры
  tools_example/          сервисный слой для MCP и внешних агентов
  real_world_examples/    бенчмарковые и прикладные сценарии
  artifacts/              каталог артефактов, облачный пакет, локальная витрина

Удалены или выведены из основной структуры:

• examples/benchmark_v2;
• examples/outdated_examples;
• старый сырой вид examples/data;
• отдельная верхнеуровневая папка examples/rkhs_okhs;
• старое название automl_example.

Практический эффект для разработчика:

• начинать с python -m examples.utils.current_api;
• использовать python -m examples.artifacts для пересборки описи артефактов и
  локальной витрины;
• использовать examples/tools_example для MCP или адаптеров внешних агентов;
• использовать examples/real_world_examples для прикладных ноутбуков и
  доменных сценариев.

10. Инструменты подготовлены для интеграции с внешними агентами

examples/tools_example больше не является набором тонких оберток над
примерами текущего API. Это сервисный слой Python со следующими частями:

• contracts.py: ToolRequest, ToolResponse, ToolArtifact, ToolError;
• registry.py: описания инструментов, JSON-схемы, маршрутизация вызовов;
• services/data.py: список, загрузка и просмотр наборов данных;
• services/training.py: конфигурации обучения и необязательное выполнение;
• services/evolution.py: конфигурация двухэтапной оптимизации Kernel Learning;
• services/pdl.py: конфигурация PDL-обучения;
• services/anomaly.py: контекст и процесс детекции аномалий.

Все тяжелые инструменты по умолчанию работают в режиме предварительной проверки
и требуют execute=true для запуска обучения или оптимизации.

Практический эффект для разработчика:

• внешний MCP-сервер может напрямую отразить описания из реестра в набор
  инструментов;
• каждый ответ имеет структуру и может включать сведения об артефактах;
• политика локальных данных описана в README и tool_defaults.json.

Как работать с обновленным репозиторием

Добавить новое направление бенчмарка

1. Добавить исполняемую логику в benchmark/industrial/<domain>.
2. Добавить или переиспользовать BenchmarkSuiteConfig.
3. Положить таблицы моделей и настройки по умолчанию в JSON рядом с тематическим
   пакетом.
4. Добавить тонкий запуск в benchmark/experiments/<family>/<task>.
5. Сохранять результаты через run_registered_suite или помощники реестра
   манифестов.
6. Подключить агрегацию и визуализацию через общие функции benchmark.industrial.
7. Добавить источник в benchmark/results/showcase/showcase_manifest.json, если
   результат должен стать публичным доказательством.
8. Добавить тесты на нормализацию конфигурации, проверку манифеста, агрегацию и
   короткий короткий проверочный запуск.

Добавить новый генератор Kernel Learning

1. Писать общий контракт в generators/base.py только если он действительно
   нужен нескольким генераторам.
2. Класть адаптеры репозитория или изменения политики бюджета в
   generators/repository.py.
3. Класть маленькие только на numpy генераторы в generators/lightweight.py.
4. Описывать спецификации операций и параметры по умолчанию в generators/specs.py.
5. Регистрировать публичное имя генератора в generators/registry.py.
6. Держать generators/adapters.py только как фасад совместимости.
7. Добавлять тесты в tests/unit/core/kernel_learning/test_generators.py.

Добавить новый пример

1. Сначала выбрать роль:
   • маленький воспроизводимый короткий проверочный пример: examples/utils/current_api;
   • инструмент для внешнего агента: examples/tools_example;
   • прикладной сценарий: examples/real_world_examples;
   • сгенерированные отчетные артефакты: examples/artifacts.
2. Использовать типизированные конфигурации бенчмарков или актуальные
   оцениватели Kernel Learning.
3. Держать каталогоподобные константы и настройки в JSON рядом с примером.
4. Не коммитить сырые локальные наборы данных и чекпойнты.
5. В README описывать локальные входы и ожидаемые выходы.
6. Если пример создает переиспользуемые графики или таблицы, регистрировать их
   в каталоге артефактов.

Обновить результаты бенчмарков

1. Запустить или возобновить бенчмарк в benchmark/results/kernel_learning/....
2. Убедиться, что папки records и aggregate созданы.
3. Обновить манифест витрины, если источник должен попасть в публичное сравнение.
4. Выполнить:

python -m benchmark.results.showcase
python -m examples.artifacts

5. Проверить опись источников, покрытие, лучшие результаты по наборам данных и
   кандидатов на архивирование.

[v1docq]

Закрыл финальный cleanup по замечаниям перед merge.

Что поправлено по инфраструктурным пунктам:

• Старые benchmark.v2-доки переведены в миграционные страницы на benchmark.industrial; активные копируемые примеры from benchmark.v2 / python -m benchmark.v2 убраны.
• kernel_learning_mvp_api.md больше не советует менять константы в начале скриптов: актуальный путь теперь через JSON defaults и типизированные конфигурации.
• Внешние данные переведены с placeholder-ссылок Google Drive на публичный архив Яндекс.Диска: https://disk.yandex.ru/d/Ch_7K26rukpAWw; в manifest добавлены public_archive_subdir, owner, last_verified.
• Для M4 forecasting в showcase явно указан режим industrial_internal_comparison до появления отдельного SoTA/Monash source.
• В showcase/artifact manifests добавлены owner, last_refreshed, refresh_command, post-merge checklist и политика размера артефактов.

Что поправлено по комментариям Lopa10ko:

• Удален старый файл плана из docs/kernel_clf_reg_docs: такие планы должны жить в issue/PR, а не в пользовательской документации.
• Старый examples/benchmark_v2 уже выведен из активного контура; текущие manifests в examples/showcase держатся в JSON и проверяются тестами.
• experiments_api перенесен из fedot_ind.core.kernel_learning в benchmark.industrial.experiments.kernel_learning; в fedot_ind.core.kernel_learning больше нет импортов benchmark.*.
• По замечанию про SparseMKLSelector: добавлен AdaptiveKernelWeightSelector, старое имя оставлено только как совместимый alias; diagnostics теперь содержит selector_family.
• InMemoryKernelCache используется в KernelEnsembleBase / KernelMatrixBuilder через KernelCacheKey и fingerprint данных.
• Для stage2 добавлены явные skipped / failed summaries, reason/traceback и strict=True.
• Тест experiments_api перенесен в benchmark test area, чтобы ownership соответствовал новому расположению пакета.

Что сознательно не стал превращать в большой refactor внутри этого cleanup:

• Полную замену estimator constructors на dataclass/config object: это затрагивает sklearn-compatible get_params / set_params и лучше делать отдельной задачей.
• Полную миграцию validation на marshmallow и backend-agnostic tensor typing для cupy/torch: это отдельный контракт ввода/валидации, не точечная правка перед merge.

Проверено локально:

• py_compile по перенесенному Kernel Learning experiments package и обновленным imports.
• PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 venv_3.9_new\Scripts\python.exe -m pytest -q tests\unit\benchmark\test_kernel_learning_experiments_api.py tests\unit\models\test_kernel_learning_experiment_scripts.py tests\unit\core\kernel_learning\test_selection.py tests\unit\examples\test_artifact_hub.py tests\unit\benchmark\test_results_showcase.py -> 35 passed.
• Поиск старых путей/placeholders: нет совпадений для from benchmark.v2, python -m benchmark.v2, gdrive://<, <folder-id>, public_google_drive_url, fedot_ind.core.kernel_learning.experiments_api.
• git diff --check без whitespace-ошибок; остались только стандартные предупреждения Git про LF -> CRLF в нескольких markdown/python-файлах.

[v1docq]

Что сделал в последних 2 коммитах

1. Обновил старую документацию про benchmark.v2 под benchmark.industrial.
2. Вставил ссылку на публичный архив Яндекс.Диска.
3. Явно пометил M4 forecasting как внутреннее сравнение Industrial до появления SoTA-источника.
4. Добавил ownership/freshness/refresh-команды и политику размера артефактов.
5. Удалил старый файл плана из docs/kernel_clf_reg_docs.
6. Перенёс experiments_api из fedot_ind.core.kernel_learning в benchmark.industrial.experiments.kernel_learning; в ядре больше нет импортов benchmark.*.
7. Добавил AdaptiveKernelWeightSelector, оставив SparseMKLSelector как совместимый alias.
8. Перенёс тесты experiments_api в benchmark-зону.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.27%. Comparing base (f726f97) to head (e6568aa).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #225      +/-   ##
==========================================
+ Coverage   65.08%   70.27%   +5.18%     
==========================================
  Files         145      250     +105     
  Lines       13945    24398   +10453     
==========================================
+ Hits         9076    17145    +8069     
- Misses       4869     7253    +2384     

Flag	Coverage Δ
unittests	70.27% <ø> (+5.18%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Lopa10ko]

nit-pick: здесь и везде в Fedot.Industrial - парсинг CLI вызовов через argparse обычно не очень хорошая идея в бенчмаркинге, достаточно устаревший подход, который хотелось бы в дальнейшем переписать на hydra yaml конфиги

при очередном запуске примера, бенча или просто тестирования хочется иметь какой-то артефакт этого запуска не только в логах, но и непосредственно рядом с файлом запуска

[Lopa10ko]

здесь и везде PROJECT_ROOT и другие пути до каких-либо директорий обычно должны прописываться единожды на уровне фреймворка (например, в fedot_ind/tools/serialisation/path_lib.py) и везде при необходимости можно прописывать from fedot_ind.tools.serialisation.path_lib import PROJECT_PATH или подобное, а не завязваться на конкретную файловую организацию в бенчмаркинг слое

если в дальнейшем бенчмаркинг будет изменяться, файлы будут переноситься и так далее, возможны проблемы с путями

[Lopa10ko]

здесь и везде вместо print в консоль лучше логировать и сохранять лог запуска

[Lopa10ko]

привязываться к конкретной дате бенчмаркинга ucr_two_stage_optim_140526 - code smell

[Lopa10ko]

зачем здесь используются nested imports внутри методов?

[Lopa10ko]

зачем каждый раз вводить either? можно пользоваться pymonad

[Lopa10ko]

везде встречаются похожие методы load_*_defaults, можно единожды реализовать в утилитах бенчмаринга или примеров и переиспользовать везде, они отличаются только названием метода в сигнатуре и в ошибке ValueError

применимо и к остальным методам, которые по какой-то причине не переиспользуются, а пишутся заново под конкретный скрипт

[Lopa10ko]

зачем?

[Lopa10ko]

проверить, используется ли это вообще? если нет, то удалить или все же применить

если я верно понимаю, cwrapped нужен для реализации метода tessellate, который используется в fedot_ind.tools.explain.pcd.numpy2stl, который используется в fedot_ind/core/operation/transformation/representation/topological/topological_extractor._generate_pcd, но закомментирован (вместо этого используется какая-то эвристика)

Fedot.Industrial/fedot_ind/core/operation/transformation/representation/topological/topological_extractor.py

Lines 80 to 100 in 0466e0f

	def _generate_pcd(self, ts_data, persistence_params):
	window_size_range = list(range(1, 35, 5))
	stride_range = list(range(1, 15, 3))
	list(product(window_size_range, stride_range))
	# for params in pcd_params:
	# data_transformer = TopologicalTransformation(stride=params[1], persistence_params=persistence_params,
	# window_length=round(ts_data.shape[0] * 0.01 * params[0]))
	# point_cloud = data_transformer.time_series_to_point_cloud(input_data=ts_data, use_gtda=True)
	# # VR_mesh = self._generate_vr_mesh(point_cloud)
	# for scale in range(1, 15, 3):
	# numpy2stl(point_cloud,
	# f"./stl_scale_{scale}_ws_{params[0]}_stride_{params[1]}.stl",
	# max_width=300.,
	# max_depth=200.,
	# max_height=300.,
	# scale=scale,
	# min_thickness_percent=0.5,
	# solid=False)
	# pcd = o3d.geometry.PointCloud()
	# pcd.points = o3d.utility.Vector3dVector(point_cloud)
	# o3d.io.write_point_cloud(f"./pcd_ws_{params[0]}_stride_{params[1]}.ply", pcd)

[Lopa10ko]

зачем добавлен lock?
убрать poetry.lock, добавить в .gitignore

[v1docq]

Что вошло в cleanup commit:

1. убрал из git examples/artifacts/cloud_bundle, examples/artifacts/showcase, poetry.lock,fedot_ind/tools/explain/cwrapped.c;
2. удалил benchmark.industrial.legacy и старые legacy-входы из public API;
3. перевел artifact hub на политику “генерируем локально, публикуем во внешнее хранилище, не коммитим”;
4. поправил benchmark paths через общий PROJECT_PATH, убрал date-specific stage2 default;
5. заменил print на логируемый run_info.log;
6. вынес общий JSON defaults loader в examples/utils/config_io.py;
7. заменил локальный Either на pymonad.either;
8. добавил явное назначение examples.tools_example.main.