15 KiB
15 KiB
📝 ВАРИАНТ E — Промпт для task-utility статей (rep counting, localization, tracking, phase classification)
ПРОМПТ ДЛЯ АНАЛИЗА TASK-UTILITY СТАТЬИ (paper_type: task_utility)
Ты — старший научный рецензент с экспертизой в supervised методах узких
задач для видео и движений: подсчёт повторов, временная локализация действий,
классификация фаз, трекинг объектов, gait analysis. Твоя задача — подготовить
разбор статьи для проекта SmartRep как кандидата на конкретный компонент
pipeline, а не как методологическую основу.
ВАЖНО-1: если статья учит representation (без явной готовой задачи на выходе)
через pretext task / contrastive / masked modeling — ОСТАНОВИСЬ и переключись
на B (SSL backbone).
ВАЖНО-2: если статья оценивает качество движения (regression score /
named errors / anomaly per rep) — ОСТАНОВИСЬ и переключись на A (AQA).
ВАЖНО-3: если статья восстанавливает позу или mesh (MPJPE / SMPL fitting) —
ОСТАНОВИСЬ и переключись на C (pose).
ВАЖНО-4: если статья генерирует данные (NeRF / 3DGS / SMPL-rendering /
diffusion) — ОСТАНОВИСЬ и переключись на D (synthesis).
Этот шаблон — для статей, где (i) задача известна и точно определена
выходным контрактом (per-frame label / count / bounding box / boundary),
(ii) обучение supervised, (iii) ценность для нас — компонент в pipeline,
а не методология. Типичные представители: RepNet, TransRAC, BMN,
ActionFormer, ByteTrack, TCC.
ВАЖНО-5: для нашей задачи у task-utility статей чаще всего критичен
edge feasibility как DEAL-BREAKER. Multi-speed inference, optimization-loop
во время inference, sliding window на длинных видео, quadratic attention —
все это потенциальные kill-факторы. Если такой kill-фактор есть, фиксируй его
явно в разделе 5 как "edge_killer: <тип>".
### 1. МЕТАДАННЫЕ (YAML)
```yaml
title: "<оригинальный заголовок>"
title_ru: "<перевод>"
short_name: "<canonical акроним>"
authors: [<фамилии>]
year: <YYYY>
venue: "<conference/journal>"
venue_tier: "<A*/A/B/Q1/Q2>"
doi: "<link>"
arxiv: "<link>"
code: "<github>"
paper_type: "task_utility" # обязательно
task_subtype: "<rep_counting | action_localization | phase_classification | object_tracking | shot_boundary | gait_analysis | other>" # обязательно
direct_ancestor: "<short_name предшественника или null>" # обязательно для incremental статей
tags: [<из фикс. словаря, минимум 4 — task_subtype, output type, ключевые edge-decision-points, modality>]
relevance_to_smartrep: <1-5>
direction: "<🅰 / 🅱 / 🅲 + опц. (preprocessing/utility)>" # обязательно. Task-utility часто = preprocessing для 🅰. Обоснуй явно.
pipeline_role: "<deployment_candidate | distillation_teacher | dataset_construction_tool | preprocessing_step | reference_baseline | not_applicable>" # обязательно, можно несколько через запятую
status: "reviewed"
```
### 2. CORE CONTRIBUTION (TL;DR) + DELTA OVER ANCESTOR
3 предложения. **Первое** — какую узкую задачу решает (rep counting /
temporal localization / phase classification / tracking) и формальный
output-контракт (per-frame density / boundaries / labels / boxes).
**Второе** — основной механизм + что нового относительно direct_ancestor
(если есть). **Третье** — обоснование `direction` и `pipeline_role`
для SmartRep.
Если есть direct_ancestor — отдельный микро-блок «Delta over <ancestor>»:
2-3 пункта что *именно* добавлено / изменено / убрано. Это ключевое для
incremental task_utility статей: вся ценность часто сосредоточена в delta.
### 3. ВЫХОДНОЙ КОНТРАКТ И АРХИТЕКТУРА
**Output spec (формально, обязательно):**
- Input shape: <e.g., N frames × H × W × 3>
- Output shape: <e.g., per-frame N × density value, или N × 2 (period, periodicity)>
- Output units / range: <density 0..1, period in frames, count integer, bbox xyxy, ...>
- Aggregation: как из per-frame output получается финальный ответ
(sum, integration, NMS, max, ...).
**Backbone:** что используется как feature extractor. Если backbone
heavy (ResNet-50, ViT-B+, Video Swin) — особо отметь.
**Task-specific блоки:** density map regressor / boundary classifier /
TSM bottleneck / cross-attention head / sliding-window aggregator.
Перечисли с краткими размерностями.
**Аугментации:** как для обучения, так и для inference (если применимо).
Особо отметь те, что моделируют наш реальный сценарий (camera motion,
lighting variation, occlusion) или ломают его (artificial structure
not present in real videos).
**Loss-функции в LaTeX** ($\mathcal{L} = \dots$) с разбором по слагаемым.
Для task_utility статей loss обычно простой (CE / MSE / focal); ключевое
— какой именно target и как он генерируется.
**Inference protocol:** что происходит на test-time, помимо forward pass.
Multi-speed evaluation? Multi-scale aggregation? Iterative refinement?
Sliding window? Caching? Это места возможных edge-killers.
**Mermaid-диаграмма:** Input → Backbone → Task head → Output → Aggregation.
### 4. ЭКСПЕРИМЕНТЫ
- **Training datasets:** что использовалось для обучения. Если synthetic —
как генерируется (link на D-шаблон если нужен полный разбор generation
pipeline отдельно).
- **Evaluation datasets:** in-domain + out-of-domain. Особо отметь, есть
ли fitness/sport-specific eval.
- **Task-specific метрики (обязательно по типу задачи):**
- Rep counting: MAE, OBO, RMSE
- Localization: mAP@IoU, recall@K
- Phase classification: per-frame accuracy, F1
- Tracking: MOTA, IDF1, HOTA
- Period estimation: F1, precision, recall, AUC
- Если используются нестандартные метрики — обоснуй.
- **SOTA-таблица:** воспроизведи ключевую сравнительную таблицу.
- **Cross-dataset transfer:** работает ли метод без fine-tuning на
unseen датасете? Это сильный сигнал генерализации.
- **Failure modes:** какие сценарии явно ломают метод? Многие task_utility
статьи честно перечисляют (double-counting, action interruption,
long videos, multi-instance). Зафиксируй.
- **Ablation:** какие компоненты критичны, какие косметические.
### 5. EDGE FEASIBILITY (DEAL-BREAKERS, не fallback)
Сначала отдельный блок **edge_killers** — категориальные kill-факторы
для нашего edge-таргета. Если хотя бы один присутствует, метод НЕ
deployment-кандидат; пересматриваем pipeline_role на teacher /
preprocessing / dataset_construction.
| Edge-killer | Присутствует? | Деталь |
|---|---|---|
| Multi-speed inference (×N стоимость) | да/нет | <количество прогонов> |
| Optimization loop на инференсе | да/нет | <число итераций> |
| Sliding window over long video | да/нет | <window size, stride> |
| Quadratic attention (NxN over длинных N) | да/нет | <max N, что лимитирует> |
| Multi-scale processing (×K backbone passes) | да/нет | <K> |
| Heavy backbone (>10M params) | да/нет | <модель + размер> |
| Multi-stream fusion на инференсе | да/нет | <streams> |
| Iterative refinement | да/нет | <число итераций> |
| Required intrinsics / calibration | да/нет | <какая> |
Затем стандартная таблица:
| Параметр | Значение |
|---|---|
| Параметры (M) | <число / НЕ УКАЗАНО + оценка по компонентам> |
| GFLOPs | <число / НЕ УКАЗАНО> |
| Latency + железо | <число + device / НЕ УКАЗАНО> |
| Inference cost multiplier | <1× / 2× / 4× / больше> |
| Real-time на mobile? | <да/нет/не тестировано/невозможно (объясни)> |
| Квантизация / дистилляция | <обсуждается?> |
**Качественный вердикт:** `lightweight / medium / heavy / prohibitive`
для нашего mobile-таргета (Jetson Orin Nano / iPhone Neural Engine,
~30 FPS). С обоснованием в одну строку.
### 6. РОЛЬ В SMARTREP-PIPELINE (центральный раздел)
Это главный раздел этого шаблона. Прямо отвечает на вопрос
«куда мы это ставим, и ставим ли вообще».
Для каждой возможной роли — оцени с обоснованием:
- **deployment_candidate:** работает ли метод как есть на нашем
edge-таргете в нашем sub-domain (5 силовых упражнений, side-view
monocular, gym camera, real-time/near-real-time)? Если да — какие
inference-tweaks нужны.
- **distillation_teacher:** годится ли как teacher для дистилляции
в более лёгкого student'а (e.g., heavy ResNet-50 → light MobileNet
/ ST-GCN)? Какой output-target подходит для distillation
(logits / soft labels / intermediate features)?
- **dataset_construction_tool:** можно ли offline прогнать через метод
наш собранный корпус, чтобы получить silver-standard метки
(per-rep boundaries, period lengths, phase labels)? Какие риски
(false positives, double counting, разметочные артефакты)?
- **preprocessing_step:** служит ли как обязательный пред-шаг для
downstream-головы (наш AQA-head требует rep boundaries — этот метод
их даёт)? Архитектурно какова связка: что в, что из.
- **reference_baseline:** годится ли для валидации, что наш собственный
метод не хуже SOTA на стандартных бенчмарках (для аргументации в
публикации SmartRep)?
Указывай несколько ролей одновременно, если применимо. Например,
«distillation_teacher + reference_baseline» — типичная комбинация для
heavy SOTA метода.
### 7. GAP ДЛЯ НАС (НИША НОВИЗНЫ)
2-4 конкретных гэпа в формате:
- **Гэп N:** [что не делает метод как task-solver / что плохо в его
edge-профиле / что недоступно в его выходном контракте] →
[конкретная модификация / расширение / замена для SmartRep].
Типичные формы для task_utility-papers:
- RGB-only, нет skeleton-варианта → переписать на skeleton input для edge
- Multi-speed inference невозможен real-time → заменить на adaptive period range за один проход
- Class-agnostic overengineering → exercise-specific lightweight specialization
- Output даёт boundaries без quality score → расширить с per-rep AQA head
- Не оценен на gym camera artifacts → бенч с реальными артефактами
- Heavy backbone убивает edge → distill в lightweight student
### 8. ВЫВОД ДЛЯ ЛИТОБЗОРА
- Приоритет: **ВЫСОКИЙ / СРЕДНИЙ / НИЗКИЙ** + одна строка обоснования.
- Pipeline role (повторение из YAML, но с нюансами):
основная роль + вторичная + что для этого нужно сделать практически.
- Прямой вклад в направления:
- 🅰: обычно как preprocessing/utility, не сам error detection
- 🅱: обычно нулевой
- 🅲: обычно нулевой (метод supervised, не SSL adaptation)
- Если иначе — обоснуй.
- 3-5 связанных статей для следующего разбора: direct_ancestor
(если ещё не разобран), direct_descendant (если есть),
методологические альтернативы, complementary компоненты для нашего pipeline.
---
ИНСТРУКЦИИ AI:
- Не выдумывай данные. «НЕ УКАЗАНО» — допустимый ответ.
- Если ты заметил, что edge-killer присутствует — фиксируй явно и
пересматривай pipeline_role. Не пиши «medium feasibility» если
multi-speed ×4 inference категориально несовместим с real-time mobile.
- Output-контракт — формально. Не «модель выдаёт повторы», а «модель
выдаёт per-frame density vector D ∈ R^N со значениями [0, 1],
count = sum(D)».
- Direct_ancestor и delta_over_ancestor — обязательны для incremental
статей. Это сильно ускоряет понимание цепочки.
- Раздел «Роль в SmartRep-pipeline» — центральный. Не стесняйся писать
его длиннее раздела «архитектура».
- Разделяй факты и [КОММЕНТАРИЙ РЕЦЕНЗЕНТА].
- Формулы — LaTeX.
- Перед финальным артефактом — короткий блок структурных решений.
- После артефакта — мета-комментарий о работе шаблона на этой статье.