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

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>
2026-06-11 17:16:57 +03:00
commit 2c6a00a4ca
155 changed files with 39765 additions and 0 deletions
--- a/docs/01_tasks/00_MASTER_ASSIGNMENT.md
+++ b/docs/01_tasks/00_MASTER_ASSIGNMENT.md
@@ -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 сильнее всего угрожает вашей же гипотезе и почему?