forked from Pikaliov/fuze_task
2c6a00a4ca
Multimodal fusion research on StripNet+GTA-UAV proxy: - 3 independent fusion tracks: condition-aware (A), token/bottleneck (B), role-aware (C) - Shared interfaces, protocol, dataset audit, baseline benchmarks - Canonical version-chain references to vault (SPEC, ANALYSIS, TRIAGE) - Personalized task plans and decision tables for each researcher - 3 generated DOCX task assignment files with milestones and DoD checklist - Full modality dropout diagnostics and missing-modality robustness requirements - Data contract, benchmark registry, experiment tracking infrastructure Operational documents: - docs/00_project/: MERIDIAN context, protocol, repository reuse guide, experiment specification - docs/01_tasks/: Master assignment + 3 individual researcher tracks + joint integration - docs/02_references/: Core literature, version-chain bases, code maps - docs/03_codebase_guides/: Existing code snapshots from vault - scripts/: gen_task_plans.js (DOCX generation), placeholder infrastructure - vendor_reference/: Snapshots of caption_test, depth_edges_annotate, existing SOFIA/SegModel code - reports/, results/, experiments/: Shared output structure for all 3 researchers 3 DOCX files generated from gen_task_plans.js (Times New Roman 14pt, GOST format): - План_заданий_Павленко_БВ.docx (Condition-Aware track, fusion API owner) - План_заданий_Близно_МВ.docx (Token/Bottleneck track, benchmark owner) - План_заданий_Мороз_ЕС.docx (Role-Aware track, data contract owner) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
333 lines
18 KiB
Markdown
333 lines
18 KiB
Markdown
# Общее задание команде
|
||
|
||
## 1. Исполнители
|
||
|
||
| Сотрудник | Архитектурный трек | Общая ответственность |
|
||
|---|---|---|
|
||
| Павленко Богдан Викторович | Condition-Aware RGB-Anchored Fusion | общий fusion API и architecture consistency |
|
||
| Близно Максим Витальевич | Token/Bottleneck Full-Modal Aggregation | benchmark, metrics, run registry и статистика |
|
||
| Мороз Егор Сергеевич | Role-Aware Hierarchical Fusion | dataset contract, preprocessing и quality validation |
|
||
|
||
Работа выполняется совместно. Каждый сотрудник обязан понимать входной contract, baseline, loss и evaluation всех трёх вариантов, а не только своего модуля.
|
||
|
||
## 2. Что требуется решить
|
||
|
||
Нужно разработать алгоритм объединения модальностей для cross-view geo-localization. Для каждой view-ветки доступен свой набор:
|
||
|
||
| View | RGB | Text | Geometry | Segmentation |
|
||
|---|---|---|---|---|
|
||
| Satellite | satellite image | satellite caption | CHM | satellite segmentation |
|
||
| UAV | UAV image | UAV caption | relative depth | UAV segmentation |
|
||
|
||
Один shared `StripNet-small` кодирует RGB. Fusion-модуль должен использовать дополнительные сигналы и сформировать descriptor, подходящий для retrieval между UAV query и satellite gallery.
|
||
|
||
### 2.1. Зачем это нужно (большая система)
|
||
|
||
Проект — архитектурный отбор fusion-механизма для Teacher системы MERIDIAN на быстром прокси (StripNet + GTA-UAV вместо DINOv3 + production-данных). Победившее семейство будет перенесено на DINOv3-Teacher и станет KD-таргетом для RGB-only edge-Student. Отсюда два следствия:
|
||
|
||
1. Нас интересует **класс механизма и причина его успеха**, а не выжатые гиперпараметрами проценты.
|
||
2. Вторичный критерий отбора — **корректное поведение при отсутствии модальности** (validity mask = 0): выход конечен, RGB-путь не искажён. Подробности и таблица безопасных/опасных классов операторов: `docs/00_project/06_MERIDIAN_CONTEXT.md` §5.
|
||
|
||
Modality dropout в training loop при этом в задание НЕ входит (это следующий этап MERIDIAN); требуется только архитектурная готовность к нему.
|
||
|
||
### 2.2. Факты о данных, которые надо знать заранее
|
||
|
||
| Факт | Значение | Следствие |
|
||
|---|---|---|
|
||
| Satellite RGB | 14,640 PNG 256×256, **RGBA** | alpha-канал проверить и отбросить осознанно |
|
||
| UAV RGB | 33,763 PNG 512×384, высоты 100–600 м | resize к 256×256 фиксируется единообразно |
|
||
| Captions UAV | 33,411 из 33,763 (~99%) | почти полное покрытие |
|
||
| Captions satellite | **6,546 из 14,640 (~44.7%)** | text_valid mask обязателен; пустой caption ≠ нулевой текст |
|
||
| Auxiliary maps | 48,403 изображений: segm/depth/edge/chm (+SafeTensors) | edges в primary input не входят |
|
||
| Segmentation | 17 unified classes | канон классов — `vendor_reference/depth_edges_annotate_worlduav/scripts/seg_classes.py` |
|
||
| Seg-filter | 37,498 из 48,403 прошли фильтр (≥90% background+water исключены) | фильтр применяется одинаково ко всем вариантам |
|
||
| Расположение данных | Linux-сервер: `/home/servml/Документы/datasets/GTA-UAV-LR{,-captions,-aug}/` | фактические пути фиксируются в gin и ENVIRONMENT_AUDIT |
|
||
|
||
## 3. Что подаётся на вход
|
||
|
||
### 3.1 Satellite branch
|
||
|
||
```text
|
||
RGB satellite [B, 3, 256, 256]
|
||
Caption satellite list[str] / tokenized text
|
||
CHM [B, 1, 256, 256]
|
||
Segmentation [B, 1, 256, 256] IDs или [B, 17, 256, 256]
|
||
Validity masks geometry + segmentation
|
||
```
|
||
|
||
### 3.2 UAV branch
|
||
|
||
```text
|
||
RGB UAV [B, 3, 256, 256]
|
||
Caption UAV list[str] / tokenized text
|
||
Relative depth [B, 1, 256, 256]
|
||
Segmentation [B, 1, 256, 256] IDs или [B, 17, 256, 256]
|
||
Validity masks geometry + segmentation
|
||
```
|
||
|
||
Полный contract описан в `docs/00_project/01_INPUT_OUTPUT_CONTRACT.md`.
|
||
|
||
## 4. Что должно получаться на выходе
|
||
|
||
Для каждой view независимо:
|
||
|
||
```text
|
||
descriptor [B, 1024], L2 normalized
|
||
rgb_descriptor [B, 1024]
|
||
modality_contributions
|
||
diagnostics
|
||
```
|
||
|
||
Далее вычисляется similarity matrix UAV-to-satellite. Fusion-модуль не получает features противоположной view.
|
||
|
||
## 5. Главная цель экспериментов
|
||
|
||
Проверить, может ли full-modal representation улучшить cross-area retrieval относительно StripNet RGB-only и какой класс fusion делает это наиболее надёжно.
|
||
|
||
Primary metric: cross-area UAV-to-satellite R@1.
|
||
|
||
Secondary:
|
||
|
||
- R@5, R@10, MRR, AP;
|
||
- satellite-to-UAV retrieval;
|
||
- mean и std по seed 42/123/456;
|
||
- peak VRAM, latency, trainable params;
|
||
- вклад text, segmentation и geometry;
|
||
- отсутствие modality collapse.
|
||
|
||
## 6. Общие архитектурные кандидаты
|
||
|
||
### Track A: Condition-aware
|
||
|
||
RGB остаётся anchor. Auxiliary encoders строят residual corrections, а controller определяет их вклад в зависимости от content и качества входов.
|
||
|
||
### Track B: Token/bottleneck
|
||
|
||
RGB stages, text, segmentation и geometry преобразуются в компактный token pool. Cross-modal reasoning выполняется через mutable queries, bottleneck tokens или soft experts.
|
||
|
||
### Track C: Role-aware
|
||
|
||
Segmentation используется как spatial semantics, geometry как dense structural signal, text как global semantic context. Операторы и порядок fusion соответствуют роли модальности.
|
||
|
||
## 7. Общие этапы работы
|
||
|
||
### Этап 0. Изучение материалов
|
||
|
||
- [ ] Прочитать `docs/00_project/06_MERIDIAN_CONTEXT.md` (контекст системы и терминология).
|
||
- [ ] Прочитать пять документов из `docs/02_references/01_required/`.
|
||
- [ ] Прочитать `TRIAGE_teacher_fusion_dropout_2026-06-11.md` (свежий аудит fusion-литературы; минимум §6a и сквозные выводы).
|
||
- [ ] Прочитать fusion core пакет; канонические документы читать **цепочкой**: полная база из `_version_chain/` + верхняя дельта (см. `00_READING_MAP.md` §0).
|
||
- [ ] Прочитать персональный paper package.
|
||
- [ ] Создать evidence matrix: механизм, исходная задача, переносимость, риск, ожидаемый эффект.
|
||
- [ ] Отделить факты статьи от проектных предположений.
|
||
|
||
### Этап 1. Environment audit
|
||
|
||
- [ ] Проверить `caption-test`.
|
||
- [ ] Проверить `depth_edges_annotate_worlduav`.
|
||
- [ ] Найти GTA-UAV RGB и captions.
|
||
- [ ] Найти/generated GTA-UAV auxiliary SafeTensors.
|
||
- [ ] Проверить StripNet checkpoint.
|
||
- [ ] Записать версии Python, PyTorch, CUDA, GPU.
|
||
- [ ] Создать `reports/joint/ENVIRONMENT_AUDIT.md`.
|
||
|
||
### Этап 2. Data audit
|
||
|
||
- [ ] Проверить 20 satellite и 20 UAV samples.
|
||
- [ ] Проверить shape, dtype, range и validity каждой модальности.
|
||
- [ ] Проверить совпадение spatial layout RGB и auxiliary maps.
|
||
- [ ] Проверить alpha channel satellite RGB.
|
||
- [ ] Проверить 17 segmentation classes.
|
||
- [ ] Проверить пустые captions (особенно satellite: покрытие ~44.7%).
|
||
- [ ] Проверить multi-match pair labels.
|
||
- [ ] **Верифицировать split**: установить, как `meta/train_80.json`/`test_20.json` соотносятся с официальными `cross-area-drone2sate-{train,test}.json`. Если 80/20 — случайный split по всем парам, он НЕ является cross-area; тогда финальная оценка дополнительно выполняется на официальном cross-area test, а решение фиксируется в `INTERFACE_DECISION.md`.
|
||
- [ ] Сформировать таблицу найденных аномалий.
|
||
|
||
### Этап 3. Interface freeze
|
||
|
||
- [ ] Утвердить representation segmentation.
|
||
- [ ] Утвердить normalization depth и CHM.
|
||
- [ ] Утвердить text encoder и caption levels.
|
||
- [ ] Утвердить fusion API.
|
||
- [ ] Утвердить common diagnostics.
|
||
- [ ] Утвердить experiment naming.
|
||
- [ ] Создать `reports/joint/INTERFACE_DECISION.md`.
|
||
|
||
### Этап 4. Baseline
|
||
|
||
- [ ] Перенести StripNet wrapper.
|
||
- [ ] Перенести GTA-UAV loader без изменения split semantics.
|
||
- [ ] Перенести multi-match evaluation.
|
||
- [ ] Настроить symmetric retrieval objective.
|
||
- [ ] Запустить B0 smoke.
|
||
- [ ] Запустить B0 seed 42.
|
||
- [ ] После проверки запустить B0 seeds 123 и 456.
|
||
- [ ] Создать `reports/joint/BASELINE_REPORT.md`.
|
||
|
||
### Этап 5. Архитектурное проектирование
|
||
|
||
Каждый сотрудник обязан до кода:
|
||
|
||
- [ ] предложить минимум три варианта внутри трека;
|
||
- [ ] сравнить их таблицей;
|
||
- [ ] выбрать primary и fallback;
|
||
- [ ] показать tensor flow для satellite и UAV;
|
||
- [ ] указать StripNet insertion stages;
|
||
- [ ] записать формулы;
|
||
- [ ] оценить params/FLOPs/VRAM;
|
||
- [ ] определить falsification criteria;
|
||
- [ ] пройти совместное design review.
|
||
|
||
### Этап 6. Реализация
|
||
|
||
- [ ] Реализовать variant за общим API.
|
||
- [ ] Добавить gin config.
|
||
- [ ] Добавить shape/unit tests.
|
||
- [ ] Добавить diagnostics.
|
||
- [ ] Добавить smoke config.
|
||
- [ ] Выполнить взаимное code review.
|
||
|
||
### Этап 7. Smoke benchmark
|
||
|
||
- [ ] B0, A-primary, B-primary, C-primary.
|
||
- [ ] Один subset, seed 42, одинаковое число steps.
|
||
- [ ] Сравнить loss, R@K sanity, VRAM, latency, NaN.
|
||
- [ ] Исправить integration defects.
|
||
|
||
### Этап 8. Primary comparison
|
||
|
||
- [ ] Полный seed 42 для трёх variants.
|
||
- [ ] Отсечь варианты, не прошедшие decision rules.
|
||
- [ ] Запустить финалистов на 123 и 456.
|
||
- [ ] Выполнить bootstrap CI и paired comparison.
|
||
|
||
### Этап 9. Ablation
|
||
|
||
- [ ] Leave-one-modality-out на evaluation.
|
||
- [ ] Single-modality auxiliary pairs.
|
||
- [ ] Late-only vs multi-stage.
|
||
- [ ] Frozen vs common Conv-MONA setting.
|
||
- [ ] Shared vs view-specific projectors.
|
||
- [ ] Персональные ablations каждого трека.
|
||
|
||
### Этап 10. Итог
|
||
|
||
- [ ] Свести общую таблицу.
|
||
- [ ] Выбрать primary, fallback, research-arm.
|
||
- [ ] Описать failure cases.
|
||
- [ ] Зафиксировать, какие hypotheses подтверждены или опровергнуты.
|
||
- [ ] Подготовить `reports/joint/FINAL_COMPARISON.md`.
|
||
- [ ] Подготовить `reports/joint/DECISION_RECORD.md`.
|
||
|
||
## 8. Обязательные baselines
|
||
|
||
| ID | Реализация |
|
||
|---|---|
|
||
| B0 | StripNet RGB-only |
|
||
| B1 | Late concat: pooled RGB + pooled text + pooled seg + pooled geometry |
|
||
| B2 | Static additive residual с фиксированными weights |
|
||
| B3 | Multi-FiLM + ADD |
|
||
|
||
Нельзя сравнивать сложные варианты только друг с другом без B0-B3.
|
||
|
||
## 9. Общая документация каждого варианта
|
||
|
||
В design report должны быть:
|
||
|
||
1. BLUF: primary/fallback и ожидаемая причина успеха.
|
||
2. Формализация входов и выхода.
|
||
3. Evidence matrix минимум по 8 источникам.
|
||
4. Сравнение трёх кандидатов.
|
||
5. Architecture diagram.
|
||
6. Tensor table для satellite и UAV.
|
||
7. Equations.
|
||
8. Pseudocode.
|
||
9. Params/FLOPs/VRAM estimate.
|
||
10. Diagnostics.
|
||
11. Experiment matrix.
|
||
12. Risks и falsification.
|
||
|
||
## 10. Результаты, которые считаются содержательными
|
||
|
||
Положительный результат:
|
||
|
||
- устойчивое улучшение retrieval;
|
||
- понятный вклад минимум одной auxiliary modality;
|
||
- приемлемая стоимость;
|
||
- повторяемость по seed.
|
||
|
||
Отрицательный результат также принимается, если:
|
||
|
||
- protocol корректен;
|
||
- baseline воспроизводим;
|
||
- причина провала диагностирована;
|
||
- показано, какой механизм не работает и при каких условиях.
|
||
|
||
## 11. Запрещено
|
||
|
||
- Использовать GPS/coordinates/location name.
|
||
- Передавать features второй view в текущий encoder.
|
||
- Менять split, loss или gallery только для одного варианта.
|
||
- Выбирать метрики после просмотра результатов.
|
||
- Сравнивать runs с разными data filters без явного отдельного эксперимента.
|
||
- Кодировать auxiliary maps как цветные RGB renderings для обучения.
|
||
- Скрывать failed runs из отчёта.
|
||
|
||
## 12. Файлы сдачи
|
||
|
||
| Сотрудник | Design report | Implementation report |
|
||
|---|---|---|
|
||
| Павленко | `reports/pavlenko/DESIGN.md` | `reports/pavlenko/IMPLEMENTATION_AND_RESULTS.md` |
|
||
| Близно | `reports/blizno/DESIGN.md` | `reports/blizno/IMPLEMENTATION_AND_RESULTS.md` |
|
||
| Мороз | `reports/moroz/DESIGN.md` | `reports/moroz/IMPLEMENTATION_AND_RESULTS.md` |
|
||
|
||
Общие:
|
||
|
||
- `reports/joint/ENVIRONMENT_AUDIT.md`
|
||
- `reports/joint/INTERFACE_DECISION.md`
|
||
- `reports/joint/BASELINE_REPORT.md`
|
||
- `reports/joint/FINAL_COMPARISON.md`
|
||
- `reports/joint/DECISION_RECORD.md`
|
||
|
||
## 13. Milestones
|
||
|
||
| Milestone | Проверяемый результат |
|
||
|---|---|
|
||
| M0 | окружение и данные доступны |
|
||
| M1 | interface frozen |
|
||
| M2 | RGB-only baseline воспроизведён |
|
||
| M3 | три design reports приняты |
|
||
| M4 | три implementations проходят tests |
|
||
| M5 | smoke benchmark завершён |
|
||
| M6 | primary comparison завершён |
|
||
| M7 | ablations и статистика завершены |
|
||
| M8 | финальное решение принято |
|
||
|
||
## 14. Ориентировочный календарь (8 недель)
|
||
|
||
Календарь — ориентир для самоконтроля, не замена milestones. Если этап задерживается больше чем на 3 рабочих дня, блокер фиксируется в `WORKLOG.md` и обсуждается с руководителем.
|
||
|
||
| Неделя | Этапы | Milestone |
|
||
|---|---|---|
|
||
| 1 | Этап 0 (чтение) + Этап 1 (environment audit) | M0 |
|
||
| 2 | Этап 2 (data audit) + Этап 3 (interface freeze) | M1 |
|
||
| 3 | Этап 4 (baseline B0–B3) | M2 |
|
||
| 4 | Этап 5 (design reports, перекрёстное ревью) | M3 |
|
||
| 5 | Этап 6 (реализация за общим API) | M4 |
|
||
| 6 | Этап 7 (smoke) + начало Этапа 8 | M5 |
|
||
| 7 | Этап 8 (primary comparison, 3 seeds для финалистов) | M6 |
|
||
| 8 | Этап 9 (ablations) + Этап 10 (итоговые отчёты, decision meeting) | M7, M8 |
|
||
|
||
Чтение литературы не заканчивается на неделе 1: evidence matrix дополняется по мере проектирования, но после M1 новые источники не могут менять общий interface без RFC.
|
||
|
||
## 15. Контрольные вопросы самопроверки (до design report)
|
||
|
||
Каждый сотрудник должен уметь ответить письменно:
|
||
|
||
1. Почему geometry-каналы satellite и UAV нельзя кодировать одним projector без view-specific нормализации?
|
||
2. Что произойдёт с вашим оператором, если segmentation полностью отсутствует у sample (validity = 0)? Покажите формулой.
|
||
3. Почему чисто multiplicative gating опасен для RGB-якоря?
|
||
4. Чем modality collapse отличается от modality shortcut и какой диагностикой ловится каждый?
|
||
5. Почему нельзя оценивать GTA-UAV по diagonal-only similarity matrix?
|
||
6. Какой ваш baseline сильнее всего угрожает вашей же гипотезе и почему?
|