grant_kachalka_Egor/SmartRep/0_prompts/Промпт для task-utility статей.md

---

# 📝 ВАРИАНТ 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.
- Перед финальным артефактом — короткий блок структурных решений.
- После артефакта — мета-комментарий о работе шаблона на этой статье.
````

---