bogdanpavl/fuze_task
1
0
Fork 0
forked from Pikaliov/fuze_task
Code Pull Requests Activity

fuse_proj: Initial operational package for 3 researchers (Pavlenko/Blizno/Moroz)

Browse Source 
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>
This commit is contained in:
Pikaliov
2026-06-11 17:16:57 +03:00
commit 2c6a00a4ca
155 changed files with 39765 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

332
docs/01_tasks/00_MASTER_ASSIGNMENT.md Normal file
View File

@@ -0,0 +1,332 @@
# Общее задание команде
## 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 сильнее всего угрожает вашей же гипотезе и почему?