проанализируй весь файл и объясни более понятным я...

Question

проанализируй весь файл и объясни более понятным языком, что нужно сделать, что нужно использовать, как должна работать нейронка, какие есть ограничения, какие критерии оценки. представь что объясняешь 15 летнему мальчику

Answer 1

Я разобрал всё ТЗ целиком — 9 страниц. Если объяснить максимально простыми словами, задача такая:

Нужно сделать “Shazam для автомобилей”.

Показываем системе фотографию машины. Номер использовать нельзя. Система должна посмотреть на внешний вид автомобиля и найти эту же машину среди фотографий с других камер. Если такой машины там, скорее всего, нет — система должна честно сказать «не знаю / совпадения нет», а не выбирать случайную похожую машину.

И это именно ReID автомобиля — Vehicle Re-Identification, а не распознавание номера. (7. Фалькон Тех.pdf)

1. Что от вас вообще хотят

Есть две группы фотографий:

Галерея — условная база машин.

Запрос — фотография машины, которую нужно найти в галерее.

Например:

text
Запрос:
[серый BMW, вид спереди]

Галерея:
1. белая Lada
2. серый BMW сзади
3. черный Mercedes
4. серый BMW сбоку
...

Нейросеть должна понять, что фотографии №2 и №4 — вероятно, та же самая машина, несмотря на другой ракурс, камеру, свет и качество изображения.

По ТЗ от решения требуются три основные вещи:

превратить изображение автомобиля в цифровой вектор — embedding;
найти в галерее самые похожие векторы;
либо вернуть кандидатов, либо отказаться от ответа, если уверенности недостаточно. (7. Фалькон Тех.pdf)

2. Самая важная идея: нейросеть не должна запоминать конкретные машины

Вот это очень важно.

В обучающей выборке будут, допустим:

text
car_001
car_002
car_003
...

А на тесте дадут:

text
car_1001
car_1002
car_1003
...

То есть ни одной тестовой машины нейросеть раньше не видела. ID машин из train и test специально не пересекаются. (7. Фалькон Тех.pdf)

Поэтому нельзя обучить обычный классификатор:

«Эта фотография = машина №381».

Вместо этого нейросеть должна научиться более общей вещи:

«Вот эти две машины визуально очень похожи и, вероятно, являются одним автомобилем».

Это и называется Open-set Retrieval. (7. Фалькон Тех.pdf)

3. Как должна работать нейронка

Упрощённая схема всей системы:

text
Фотография
    ↓
BBox автомобиля
    ↓
Вырезаем машину из кадра
    ↓
Нейросеть
    ↓
Embedding
например:
[0.13, -0.51, 0.82, 0.07, ...]
    ↓
Сравниваем с embedding'ами машин в базе
    ↓
Получаем похожесть
    ↓
Сортируем
    ↓
Top-10 кандидатов
    ↓
Проверяем confidence
    ↓
либо кандидаты
либо "совпадения нет"

Именно такая логика описана в ТЗ: получение изображения и BBox → извлечение признаков → векторный поиск → сортировка → Top-N или отказ. (7. Фалькон Тех.pdf)

4. Что такое embedding на человеческом языке

Представим, что нейросеть смотрит на машину и мысленно описывает её:

text
цвет = темно-серый
кузов = SUV
форма фар = такая
форма задних фонарей = такая
диски = такие
крыша = такая
наклейка = здесь
царапина = здесь
геометрия кузова = такая
...

Но вместо текста она записывает всё это числами:

text
[0.126,
 -0.883,
  0.431,
  ...
]

Например, может получиться вектор из 512 чисел.

Это и есть embedding.

Две фотографии одной машины должны давать близкие векторы:

text
Машина A, камера 1:
[0.2, 0.7, 0.1, ...]

Машина A, камера 7:
[0.21, 0.68, 0.13, ...]

А другая машина:

text
Машина B:
[-0.5, 0.1, 0.8, ...]

должна оказаться дальше.

В ТЗ прямо сказано, что векторы одного автомобиля с разных камер должны быть математически ближе друг к другу, чем векторы разных автомобилей. (7. Фалькон Тех.pdf)

5. Что такое BBox и почему вам облегчили задачу

BBox — это прямоугольник вокруг машины:

text
+----------------------------+
|                            |
|       +-------------+      |
|       |    CAR      |      |
|       |             |      |
|       +-------------+      |
|                            |
+----------------------------+

В CSV вам уже дадут:

text
x, y, w, h

То есть координаты этого прямоугольника.

Поэтому искать автомобиль на фотографии вам не нужно.

Вы просто берёте исходный кадр:

python
car = image[y:y+h, x:x+w]

и дальше работаете с автомобилем.

В задачу специально не входят:

детекция автомобилей;
распознавание госномеров;
трекинг автомобилей между кадрами.

BBox будут даны и для train, и для test. (7. Фалькон Тех.pdf)

6. На что нейросеть должна смотреть

Номер использовать нельзя.

Она должна искать признаки вроде:

цвет;
тип кузова;
форма кузова;
форма фар;
форма задних фонарей;
решётка радиатора;
колёсные диски;
рейлинги;
наклейки;
повреждения;
необычные элементы;
общие пропорции автомобиля.

Именно визуальные характеристики вроде цвета, кузова, геометрии, наклеек и повреждений указаны как основа решения. (7. Фалькон Тех.pdf)

7. Номер использовать вообще нельзя

Это одно из самых жёстких правил.

В датасете номера специально размыты. Лица людей тоже размыты.

Более того:

использование даже каких-либо остаточных признаков номерного знака запрещено.

(7. Фалькон Тех.pdf)

А дальше ТЗ прямо предупреждает:

если решение использует признаки государственного номера — дисквалификация.

(7. Фалькон Тех.pdf)

Поэтому OCR номера, восстановление размытого номера и любые подобные хитрости — плохая идея.

8. Камеру, время и GPS вам тоже не дадут

Нельзя решить задачу хитростью вроде:

«Эта машина была на камере №2 в 13:05, а потом на камере №5 в 13:08, значит это она».

Потому что вам не передают:

ID камеры;
время;
геолокацию.

Решение должно основываться именно на внешнем виде машины. (7. Фалькон Тех.pdf)

9. Почему задача сложнее, чем кажется

Один автомобиль может выглядеть очень по-разному.

Например:

text
Фото 1:
день
вид спереди
солнечно
HD

Фото 2:
ночь
вид сзади
дождь
низкое качество
часть машины закрыта человеком

Но система всё равно должна понять:

это один и тот же автомобиль.

Датасет специально содержит разные:

времена суток;
погодные условия;
ракурсы;
фронтальные виды;
боковые виды;
задние виды;
перекрытия;
фотографии низкого качества.

(7. Фалькон Тех.pdf)

То есть главное испытание нейронки — научиться игнорировать:

text
ракурс
освещение
фон
камера
качество картинки

и сохранять признаки именно личности автомобиля.

10. Вторая половина задачи — поиск

Допустим, нейросеть превратила фотографию в embedding:

text
Query → vector Q

В базе уже лежат:

text
Car1 → vector A
Car2 → vector B
Car3 → vector C
...

Теперь сравниваем:

text
similarity(Q, A)
similarity(Q, B)
similarity(Q, C)
...

В ТЗ предлагаются, например:

cosine similarity;
L2 distance для нормализованных векторов.

(7. Фалькон Тех.pdf)

Допустим:

text
Car 872 → 0.94
Car 412 → 0.89
Car 933 → 0.81
Car 731 → 0.43
...

Тогда выдаём:

text
1. Car 872
2. Car 412
3. Car 933
...

11. Но нельзя всегда выдавать первую машину

Это ещё одна ключевая часть задания.

Представим:

text
Запрос:
красный Porsche

Галерея:
BMW
Lada
Toyota
Kia

Этого Porsche там вообще нет.

Плохая система скажет:

text
Toyota — самое похожее.

Хотя это неправда.

Хорошая система должна сказать:

text
Совпадение не найдено.

В ТЗ это называется режимом отказа / Refusal. (7. Фалькон Тех.pdf)

12. Для этого вам нужен threshold

Допустим, similarity находится от 0 до 1.

Можно установить:

text
threshold = 0.75

Тогда:

text
лучший кандидат = 0.93
→ вернуть машину

лучший кандидат = 0.82
→ вернуть машину

лучший кандидат = 0.61
→ отказ

Порог команда определяет сама.

Но на защите вы должны объяснить:

почему поставили именно такой порог?

(7. Фалькон Тех.pdf)

Это значит, что выбирать его наугад нельзя.

Правильнее будет экспериментировать на validation:

text
threshold 0.50 → слишком много ложных совпадений
threshold 0.65 → лучше
threshold 0.72 → лучший F1
threshold 0.80 → слишком много отказов

И затем аргументировать выбранное значение.

13. Какая именно нейросеть нужна?

Здесь важный момент:

ТЗ НЕ требует конкретную модель.

То есть в документе нет требования:

используйте ResNet50

или:

используйте ViT.

На защите, наоборот, нужно объяснить, какую архитектуру выбрали вы и почему, включая backbone и работу с изменением ракурса и освещения. (7. Фалькон Тех.pdf)

Поэтому дальше уже моя практическая рекомендация, а не обязательное требование ТЗ.

Для первой рабочей версии логика может быть такой:

text
Crop автомобиля
       ↓
Backbone
например ResNet / ConvNeXt / EfficientNet / ViT
       ↓
Feature vector
       ↓
Embedding layer
например 512 dimensions
       ↓
L2 normalization
       ↓
Cosine similarity

А обучение можно строить как metric learning:

text
одинаковые машины → притянуть друг к другу
разные машины → оттолкнуть

Иными словами, вам важнее не обычная классификация, а качество пространства embedding'ов.

14. Что значит «притянуть» машины

Представь большую карту:

Все фотографии автомобиля A должны оказаться рядом.

Все фотографии B — рядом между собой.

Но группы A и B должны находиться далеко друг от друга.

Вот практически вся математическая идея ReID.

15. Какие данные вы получите

Организаторы дают полные JPEG/PNG изображения.

Структура примерно такая:

text
images/
    ah73hd82.jpg
    j22kf91d.jpg
    ...

train.csv
test.csv

Для объекта будут координаты:

text
image_id
x
y
w
h
vehicle_id

Но vehicle_id доступен только для train.

Один кадр может содержать несколько автомобилей. (7. Фалькон Тех.pdf)

16. Train и test устроены специально сложно

Главный принцип:

text
vehicle_id(train) ∩ vehicle_id(test) = ∅

То есть пересечения нет вообще. (7. Фалькон Тех.pdf)

Поэтому если ваша модель просто запоминает обучающие автомобили — на закрытом тесте она развалится.

Нужно добиться generalization, то есть умения работать с абсолютно новыми машинами.

17. Какую систему нужно собрать целиком

Это не конкурс формата:

вот вам Jupyter Notebook, покажите accuracy.

Организаторы хотят практически готовый сервис.

Упрощённо архитектура может выглядеть так:

text
             Browser
                ↓
             Frontend
                ↓
             REST API
                ↓
        Inference backend
         ↓              ↓
      Neural Net     Vector Search
                         ↓
                 Vector Database

В ТЗ требуется разделение компонентов: backend инференса, база данных и клиентская часть. (7. Фалькон Тех.pdf)

18. Backend

Разрешён:

Python;
C++;
Rust.

Предпочтительны open-source решения, работающие под Linux. (7. Фалькон Тех.pdf)

Для хакатона самым очевидным вариантом будет Python.

19. Где хранить embeddings

В документе приведены варианты:

PostgreSQL + pgvector;
FAISS;
Milvus;
либо подходящая реляционная / документная / векторная БД.

(7. Фалькон Тех.pdf)

Для простой схемы:

text
vehicle/image ID → embedding

Для небольшого набора можно даже искать напрямую по матрице векторов.

Для миллионов объектов уже потребуется ANN-поиск.

20. FAISS — зачем он вообще нужен

Представим 1 миллион машин.

Сравнивать запрос с миллионом embedding'ов напрямую каждый раз может быть дорого.

FAISS позволяет примерно сказать:

«Не проверяй весь миллион подробно. Быстро найди область, где находятся самые похожие векторы».

Именно масштабирование ANN-поиска примерно до 10^6 объектов упоминается в дополнительных критериях. (7. Фалькон Тех.pdf)

Но это дополнительная возможность, а не основная часть 100 баллов.

21. API обязателен

API должно быть описано через:

OpenAPI / Swagger.

Пользователь должен работать через обычный веб-браузер. (7. Фалькон Тех.pdf)

Например:

http
POST /embedding
POST /search
POST /gallery/add
GET /health

Конкретные endpoint'ы ТЗ не диктует — это уже ваш дизайн.

22. Docker обязателен

Проект должен содержать:

text
Dockerfile
docker-compose.yml

и запускаться практически одной командой:

bash
docker compose up

без:

text
"сначала скачайте вручную веса"
"потом поменяйте конфиг"
"потом установите CUDA-пакет"
"потом запустите ещё этот скрипт"

Требование — воспроизводимый запуск без дополнительных ручных действий. (7. Фалькон Тех.pdf)

23. Интернет при финальном запуске использовать нельзя

Во время inference решение должно работать offline.

Все необходимые веса должны находиться внутри вашего решения. (7. Фалькон Тех.pdf)

То есть такой код на финальном сервере — риск:

python
model = download_from_internet(...)

Все модели лучше заранее положить в образ / репозиторий / поставляемые артефакты согласно правилам организаторов.

24. Предобученные модели использовать можно

И это хорошие новости.

Разрешены и даже приветствуются:

публичные pretrained weights;
открытые сторонние datasets.

Но нужно написать в README:

text
какая модель
откуда
какой датасет
какая версия

При этом закрытые, проприетарные или невоспроизводимые данные использовать нельзя — такие решения не допускаются к оценке. (7. Фалькон Тех.pdf)

25. Ограничение веса нейронки

Все файлы весов модели вместе:

не больше 2 ГБ.

Также inference не должен падать с:

text
CUDA out of memory
RAM out of memory

на тестовой выборке. (7. Фалькон Тех.pdf)

То есть собрать ансамбль из 15 огромных моделей по 1 ГБ каждая не получится.

26. Скорость тоже будет проверяться

Измеряют две вещи.

1. Скорость одной машины

Batch size = 1.

Например:

text
35 ms / image

2. Общий FPS при batch processing

Например:

text
120 images/sec

Причём система должна работать стабильно:

без бесконечного роста очереди;
без деградации памяти.

(7. Фалькон Тех.pdf)

27. Вашим цифрам скорости жюри просто не поверит на слово

Вы можете написать:

text
Наш сервис: 999 FPS

Но баллы дадут не за это.

Организаторы сами запустят решение на одинаковом оборудовании и измерят его своим скриптом. (7. Фалькон Тех.pdf)

То есть оптимизация действительно должна работать.

28. Что именно нужно сдать

Обязательных результатов несколько.

`submission.csv`

Для каждого query:

text
Top-10 наиболее похожих объектов галереи

причём в правильном порядке.

`embeddings.npy`

Embedding каждого тестового объекта.

Порядок обязан точно совпадать с соответствующим CSV.

`candidates.csv`

Для режима отказа:

text
query_001 → car_882, confidence=0.92
query_002 → пусто
query_003 → car_332, confidence=0.86

Код + окружение

Нужны:

text
training code
inference code
Dockerfile
docker-compose.yml
dependencies

(7. Фалькон Тех.pdf)

29. Самая важная метрика — mAP

За качество поиска в первую очередь смотрят mAP — mean Average Precision. (7. Фалькон Тех.pdf)

Объясню совсем просто.

Представим, что правильная машина есть на позициях:

text
1. ❌
2. ✅
3. ❌
4. ✅
5. ❌

Лучше, когда правильные фотографии находятся как можно выше.

То есть:

text
✅
✅
❌
❌
❌

намного лучше, чем:

text
❌
❌
❌
✅
✅

mAP оценивает качество всего такого ранжирования по всем запросам.

30. Что такое Rank-1

Очень просто:

Правильная машина стоит первой или нет?

Например:

text
1. нужная BMW       ← ✅
2. другая BMW
3. Mercedes

Это успех Rank-1.

Если:

text
1. другая BMW
2. нужная BMW

Rank-1 уже не засчитан.

31. Что такое Rank-5

Тот же принцип, только:

попала ли правильная машина хотя бы в первые 5?

Rank-1 и Rank-5 в ТЗ являются дополнительными публикуемыми метриками, а основной является mAP. (7. Фалькон Тех.pdf)

32. Причём фотографии с той же камеры не считаются

Это важная деталь.

Если машина была снята одной камерой два раза, такое совпадение из расчёта исключается.

Жюри интересует именно:

text
камера A → камера B

то есть настоящее cross-camera ReID. (7. Фалькон Тех.pdf)

33. Как оценивается режим «не знаю»

Здесь появляются три понятия.

F1

Это баланс между:

text
не пропустить настоящий match

и

text
не принять неправильную машину за правильную

F1 при выбранном вашей командой пороге — основная метрика этой части. (7. Фалькон Тех.pdf)

34. TNR

True Negative Rate.

Он проверяет:

если нужной машины в базе действительно нет, насколько часто нейросеть правильно говорит «нет совпадения»?

Например:

text
100 запросов без настоящего совпадения.

Система правильно отказалась в 87 случаях.

TNR = 87%

Это нужно, чтобы нельзя было сделать:

text
всегда возвращай top-1

и получить хорошие показатели только за счёт этого. (7. Фалькон Тех.pdf)

35. mINP / Precision-Recall AUC

Это дополнительная проверка того, насколько хорошо система в целом разделяет:

text
это match

и

text
это НЕ match

независимо от одного конкретно выбранного threshold. (7. Фалькон Тех.pdf)

36. Самое важное: как распределяются 100 баллов

Вот ваша реальная таблица приоритетов.

Часть	Вес
mAP на закрытом тесте	45%
Скорость и применимость	20%
Инженерное качество	15%
Режим отказа	10%
Защита проекта	10%

Именно так распределяется итоговая оценка. (7. Фалькон Тех.pdf)

То есть почти половина конкурса — просто:

насколько хорошо нейросеть находит одну и ту же машину.

37. Что означает 45% за точность

Это главный кусок.

Жюри возьмёт закрытый test, которого вы не видели, и измерит mAP.

Здесь победит не модель, которая идеально выучила train, а модель, способная работать с новыми автомобилями. (7. Фалькон Тех.pdf)

Поэтому нужно очень внимательно строить validation.

38. Что означает 20% за производительность

Смотрят:

быстро ли работает inference;
сколько FPS;
влезают ли веса в лимит;
не падает ли память;
похож ли pipeline на реально применимый.

(7. Фалькон Тех.pdf)

То есть gigantic-model с +0.1% accuracy, но работающая 3 секунды на одну картинку, может оказаться неудачным компромиссом.

39. Что означает 15% инженерного качества

Будут смотреть:

запускается ли код;
можно ли повторить результат;
нормальная ли архитектура;
нормальный ли Docker;
соблюдены ли требования к стеку;
нормальная ли документация.

(7. Фалькон Тех.pdf)

Поэтому:

text
final_final_v7_REAL.ipynb

который работает только на ноутбуке одного участника — плохой вариант.

40. Ещё 10% — режим отказа

Нужно правильно определять:

text
машина существует в gallery

против

text
машины в gallery нет

Смотрят F1 и TNR.

И вы должны объяснить выбранный threshold. (7. Фалькон Тех.pdf)

41. Последние 10% — защита

На питче смотрят:

можете ли объяснить архитектуру;
почему выбрали такую модель;
почему выбрали такой threshold;
знаете ли слабые стороны своей модели;
анализировали ли ошибки.

(7. Фалькон Тех.pdf)

То есть сказать:

«мы взяли модель из GitHub, она дала хороший score»

недостаточно.

42. Что может привести к дисквалификации

Два особенно важных случая указаны явно:

1. Решение невозможно воспроизвести из вашего кода.

2. Вы используете признаки государственного номера.

В таком случае решение вообще не допускается к итоговой оценке. (7. Фалькон Тех.pdf)

Также закрытые/проприетарные/невоспроизводимые внешние данные не допускаются. (7. Фалькон Тех.pdf)

43. Есть ещё дополнительные «плюшки»

Они не входят напрямую в 100 баллов.

Они используются, если основные результаты нескольких команд совпадут. (7. Фалькон Тех.pdf)

Это:

Красивый web UI

Пользователь:

text
загружает фото
↓
видит найденные машины
↓
видит confidence
↓
может экспортировать результат

(7. Фалькон Тех.pdf)

Интерпретируемость

Например Grad-CAM / Attention Map:

text
нейросеть решила, что машины одинаковые,
потому что смотрела на:
- левую фару
- решётку
- колесо

(7. Фалькон Тех.pdf)

Масштабируемость

Показать, что поиск сможет работать примерно на:

text
1 000 000 объектов

с помощью FAISS/HNSW/ANN. (7. Фалькон Тех.pdf)

Анализ ошибок

Например:

text
Модель ошибается:
- на одинаковых белых седанах;
- на ночных кадрах;
- когда видна только задняя часть;
- когда автомобиль сильно перекрыт.

Такой анализ отдельно ценится. (7. Фалькон Тех.pdf)

44. Что обязательно рассказать в презентации

Презентация должна быть понятна и технарям, и бизнес-жюри.

Нужно показать:

вашу методологию;
архитектуру нейронки;
почему выбрали backbone;
как боролись с разными ракурсами;
как боролись с разным освещением;
пользовательский путь;
план масштабирования;
реальные ошибки модели.

(7. Фалькон Тех.pdf)

45. Что должно быть в README

README здесь не формальность.

Там должны быть:

архитектура всей системы;
используемые алгоритмы;
обработка данных;
инструкция по запуску;
метрики на validation;
обоснование threshold;
все библиотеки;
версии;
внешние datasets;
внешние models/weights.

Цель — чтобы другой человек получил репозиторий и смог полностью повторить ваш результат. (7. Фалькон Тех.pdf)

46. Что надо отдать в самом конце

На платформе понадобятся четыре ссылки:

Git-репозиторий;
презентация;
работающий прототип;
отдельная документация, если она не полностью находится в README.

(7. Фалькон Тех.pdf)

47. Если свести проект к 7 блокам

Вся задача выглядит вот так:

text
1. DATA
   изображения + BBox + vehicle_id(train)

                 ↓

2. PREPROCESSING
   вырезать машину
   resize
   augmentation

                 ↓

3. NEURAL NETWORK
   изображение → embedding

                 ↓

4. VECTOR SEARCH
   embedding → cosine similarity → ranking

                 ↓

5. REFUSAL
   similarity < threshold → "не найдено"

                 ↓

6. SERVICE
   API + DB/vector search + web interface

                 ↓

7. DELIVERY
   Docker + CSV + embeddings + README + презентация

48. Если бы я объяснял, что вам делать завтра утром

Я бы разбил работу примерно так.

Сначала вообще забудьте про интерфейс и микросервисы. Получите working ML baseline:

text
image
→ crop по BBox
→ model
→ embedding
→ cosine similarity
→ top-10
→ mAP

Когда этот pipeline реально считает метрику, только потом имеет смысл превращать его в сервис.

49. Этап 1 — правильно подготовить данные

Из:

text
full image + x,y,w,h

получить:

text
cropped car

И построить dataset:

text
image → vehicle_id

для train.

Важно, чтобы validation тоже имитировал ReID, а не обычную классификацию.

50. Этап 2 — сделать baseline

Самый простой вариант:

text
pretrained backbone
↓
embedding
↓
L2 normalize
↓
cosine similarity

Сначала не надо строить космическую архитектуру.

Главный вопрос:

работает ли весь pipeline от начала до конца?

51. Этап 3 — считать правильную validation-метрику

Не просто:

text
accuracy = 95%

а именно retrieval:

text
Query
↓
Gallery
↓
Ranking
↓
mAP
Rank-1
Rank-5

Потому что именно это в итоге проверит жюри.

52. Этап 4 — улучшать embedding

Вот здесь уже можно экспериментировать.

Это уже мои технические рекомендации, а не обязательные пункты ТЗ:

text
augmentations
metric-learning losses
лучший backbone
hard-negative mining
reranking
multi-view robustness
color augmentation
random erasing
better crop strategy

Основная цель каждого эксперимента одна:

поднять cross-camera mAP на validation.

Не «сделать нейронку красивее», а увеличить реальную метрику.

53. Этап 5 — отдельно решить Refusal

После хорошего retrieval нужно исследовать распределение:

text
same-car similarity
versus
different-car similarity

Условно может получиться:

text
same:
0.73 0.81 0.91 0.88 ...

different:
0.21 0.43 0.52 0.38 ...

И дальше подобрать порог.

Например:

text
threshold = 0.68

Но победное значение заранее неизвестно — оно зависит от вашей модели.

54. Этап 6 — оптимизировать скорость

Только после хорошего качества.

Можно смотреть:

text
размер input image
размер backbone
FP16
batching
ONNX/TensorRT — если подходит вашему окружению
эффективный vector search

Но помните:

скорость = 20%, качество = 45%.

То есть бессмысленно ради ещё 50 FPS разрушить mAP.

55. Этап 7 — завернуть всё в продукт

После этого:

text
Backend
+ API
+ Vector DB
+ Docker
+ Swagger
+ Web UI

И сделать сценарий примерно таким:

text
Пользователь загружает фотографию
             ↓
выбирается BBox / передаётся BBox
             ↓
сервис строит embedding
             ↓
ищет по галерее
             ↓
показывает:

#1  92%
#2  84%
#3  78%

или

"Уверенное совпадение не найдено"

56. Что обязательно, а что можно оставить на потом

Я бы разделил требования так:

Приоритет	Что
🔴 Критично	хороший embedding
🔴 Критично	mAP
🔴 Критично	Top-10 retrieval
🔴 Критично	не использовать номер
🔴 Критично	воспроизводимый код
🔴 Критично	Docker
🔴 Критично	веса ≤ 2 ГБ
🔴 Критично	offline inference
🟠 Очень важно	скорость
🟠 Очень важно	refusal threshold
🟠 Очень важно	README
🟠 Очень важно	правильные submission-файлы
🟡 Нужно для продукта	API/Swagger
🟡 Нужно для продукта	web frontend
🟢 Бонус при равенстве	Grad-CAM
🟢 Бонус при равенстве	поиск на ~1 млн машин
🟢 Бонус при равенстве	особенно хороший UI

Основание для такого разделения — веса критериев и дополнительные tie-breaker требования в ТЗ. (7. Фалькон Тех.pdf)

57. На что я бы особенно обратил внимание

Самая опасная ошибка — подумать:

«Нам надо определить марку, модель и цвет машины».

Нет.

Допустим, рядом стоят две совершенно одинаковые:

text
Toyota Camry 2024
белая
одинаковая комплектация

Система должна попытаться определить:

это именно та конкретная Camry, а не просто автомобиль той же модели.

Поэтому марка + модель + цвет могут помогать, но этого недостаточно.

58. Вторая опасная ошибка

Сделать обычную классификацию:

text
vehicle_id → class

и ждать, что этого хватит.

На тесте совершенно новые vehicle_id.

Поэтому конечная цель — именно embedding, хорошо работающий для неизвестных автомобилей. (7. Фалькон Тех.pdf)

59. Третья опасная ошибка

Сконцентрироваться на красивом сайте.

Можно сделать потрясающий:

text
React
анимации
графики
карточки

а нейронка будет плохо искать автомобили.

Тогда вы проиграете большую часть оценки, потому что только закрытый mAP составляет 45%, тогда как demo-интерфейс вообще относится к дополнительным критериям при равенстве основных результатов. (7. Фалькон Тех.pdf) (7. Фалькон Тех.pdf)

60. Как выглядит «хорошее» готовое решение

В идеальном варианте у вас будет:

text
                  USER
                    ↓
              Web interface
                    ↓
                  API
                    ↓
              Crop by BBox
                    ↓
                ReID model
                    ↓
                embedding
                    ↓
             L2 normalize
                    ↓
        FAISS / pgvector / Milvus
                    ↓
             Top candidates
                    ↓
             confidence logic
                ↙       ↘
          similarity     similarity
          high           low
             ↓             ↓
         results       REFUSAL

61. А теперь всё ТЗ одним предложением

Сделайте быстрый и воспроизводимый сервис, который по фотографии автомобиля без номера создаёт устойчивый embedding, находит эту же машину среди фотографий с других камер, умеет отказаться от ответа при отсутствии уверенного совпадения, работает offline в Docker, укладывается в ограничение весов 2 ГБ и показывает высокий cross-camera mAP на новых автомобилях. (7. Фалькон Тех.pdf) (7. Фалькон Тех.pdf)

И главное — стратегия конкурса

Если представить, что у вас ограниченное время хакатона, то не надо пытаться делать всё одновременно.

Я бы выстроил работу в таком порядке:

датасет → baseline ReID → правильный validation/mAP → улучшение модели → refusal → speed → Docker/API → UI → презентация

Потому что основная ценность решения находится в хорошем embedding и retrieval: 45% оценки — точность, ещё 20% — производительность, и только после этого имеет смысл полировать продуктовую оболочку. (7. Фалькон Тех.pdf)

Если совсем по-простому, ваша нейронка должна научиться игре:

«Узнай ту же самую машину, даже если я покажу её с другой стороны, ночью, под дождём, с другой камеры — и не ври, если её среди вариантов вообще нет».

Вопрос

Мысль

Ответ

1. Что от вас вообще хотят

2. Самая важная идея: нейросеть не должна запоминать конкретные машины

3. Как должна работать нейронка

4. Что такое embedding на человеческом языке

5. Что такое BBox и почему вам облегчили задачу

6. На что нейросеть должна смотреть

7. Номер использовать вообще нельзя

8. Камеру, время и GPS вам тоже не дадут

9. Почему задача сложнее, чем кажется

10. Вторая половина задачи — поиск

11. Но нельзя всегда выдавать первую машину

12. Для этого вам нужен threshold

13. Какая именно нейросеть нужна?

ТЗ НЕ требует конкретную модель.

14. Что значит «притянуть» машины

15. Какие данные вы получите

16. Train и test устроены специально сложно

17. Какую систему нужно собрать целиком

18. Backend

19. Где хранить embeddings

20. FAISS — зачем он вообще нужен

21. API обязателен

22. Docker обязателен

23. Интернет при финальном запуске использовать нельзя

24. Предобученные модели использовать можно

25. Ограничение веса нейронки

26. Скорость тоже будет проверяться

1. Скорость одной машины

2. Общий FPS при batch processing

27. Вашим цифрам скорости жюри просто не поверит на слово

28. Что именно нужно сдать

submission.csv

embeddings.npy

candidates.csv

Код + окружение

29. Самая важная метрика — mAP

30. Что такое Rank-1

31. Что такое Rank-5

32. Причём фотографии с той же камеры не считаются

33. Как оценивается режим «не знаю»

F1

34. TNR

35. mINP / Precision-Recall AUC

36. Самое важное: как распределяются 100 баллов

37. Что означает 45% за точность

38. Что означает 20% за производительность

39. Что означает 15% инженерного качества

40. Ещё 10% — режим отказа

41. Последние 10% — защита

42. Что может привести к дисквалификации

43. Есть ещё дополнительные «плюшки»

Красивый web UI

Интерпретируемость

Масштабируемость

Анализ ошибок

44. Что обязательно рассказать в презентации

45. Что должно быть в README

46. Что надо отдать в самом конце

47. Если свести проект к 7 блокам

48. Если бы я объяснял, что вам делать завтра утром

49. Этап 1 — правильно подготовить данные

50. Этап 2 — сделать baseline

51. Этап 3 — считать правильную validation-метрику

52. Этап 4 — улучшать embedding

53. Этап 5 — отдельно решить Refusal

54. Этап 6 — оптимизировать скорость

55. Этап 7 — завернуть всё в продукт

56. Что обязательно, а что можно оставить на потом

57. На что я бы особенно обратил внимание

58. Вторая опасная ошибка

59. Третья опасная ошибка

60. Как выглядит «хорошее» готовое решение

61. А теперь всё ТЗ одним предложением

И главное — стратегия конкурса

Поделиться этим Q&A

`submission.csv`

`embeddings.npy`

`candidates.csv`