Глава 7. R-CNN → YOLO

Глава 7. Эволюция взгляда: От R-CNN до YOLO

В 2014 году инженеры уже умели довольно точно находить объекты.
Проблема была не в качестве. Проблема была в скорости.
Если решению нужен бюджет 20 мс, алгоритм за секунду бесполезен — какой бы ни был mAP.

Части I–II научили сеть видеть признаки.
Детекция требует большего: много объектов, классы, координаты — и всё это внутри latency-бюджета продукта.

Здесь впервые архитектура начинает подчиняться не только математике представления, а железу и времени.

7.1. Эпоха Region Proposals: сначала «где», потом «что»

Естественная инженерная мысль после победы классификаторов:

У нас есть отличная сеть «что на кропе».
Значит, нарежем подозрительные кропы и прогоним классификатор по каждому.

Так родилось семейство R-CNN.

Упрощённый пайплайн:

Пайплайн R-CNN

Логика честная. И убийственно дорогая.

1 кадр × 2000 кропов × прогон сети  ≈  работа «как будто 2000 картинок»

Даже когда появились Fast/Faster R-CNN и посчитали свёртки на всём кадре один раз, а proposals стали почти нейросетевыми, философия осталась двухстадийной:

  1. найти области;
  2. разобраться, что внутри.

Для офлайна и точности — нормально.
Для камеры на роботе / видеоаналитики / edge — часто мимо бюджета.

Двухстадийный обмен

Плюсы Минусы
Точнее можно выжать Latency и сложный пайплайн
Явный этап локализации Много лишних кандидатов
Удобно улучшать по частям Сложно уложиться в realtime

7.2. Думать сеткой: одна задача вместо конвейера

Теперь сменим вопрос.

Не: «Как аккуратнее предложить рамки?»
А: «Что можно выбросить, чтобы стало достаточно быстро?»

Гипотеза, которая звучит дерзко:

Разделим картинку на сетку.
Каждая ячейка отвечает за объекты, чей центр в неё попал.
За один проход сеть предсказывает классы и боксы для всей сетки.

YOLO: кадр в сетку

Схема:

YOLO: один проход по сетке

Именно эта ставка — one look / one stage — сделала семейство YOLO практическим стандартом там, где важны кадры в секунду.

Имя можно произнести после идеи, не до:

You Only Look Once — не маркетинг, а архитектурный тезис:
детекция как единая регрессия/классификация на сетке, а не конвейер из тысяч кропов.

7.3. Конфликт уверенности и цена простоты

Одностадийность не бесплатна.

Проблема 1. Несколько ячеек на один объект.
Крупный объект касается многих клеток. Кто имеет право ответить? Нужны правила ответственности (центр, якоря, позже — assigners вроде TAL) и подавление дублей (NMS и наследники).

Проблема 2. Классификация vs локализация.
«Это птица» и «край крыла вот здесь» — разные давления на признаки. Позже это приведёт к decoupled head (разнесённые головы). Пока достаточно зафиксировать конфликт.

Проблема 3. Мелкие объекты на грубой сетке.
Если выходная сетка редкая, спичка на горизонте может не получить достойного носителя. Отсюда будущая нужда в многомасштабных головах и шее FPN/PAN — следующая глава.

flowchart TD
    A[Нужна детекция] --> B{Как искать?}
    B --> C[Сначала proposals, потом класс]
    B --> D[Сразу сетка + один проход]
    C --> E[Точность / тяжёлый пайплайн]
    D --> F[Скорость / новые конфликты assign и масштаба]
    F --> G[Дальше: многомасштабная шея, лучшие loss, better head]

Историческая траектория внутри самого YOLO тоже была эволюцией компромиссов: якоря → отказ от якорей, связанные головы → раздельные, MSE по боксам → IoU-семейство.
Эти боли разобраны углубляюще в главах 7a (якоря) и 7b (голова и loss) — без changelog ради changelog.

7.4. Итог развилки

R-CNN против YOLO

Правильный инженерный вывод не «YOLO всегда лучше».
А такой:

Если ваш бюджет — realtime на конкретном железе,
вы почти обречены задавать вопрос Редмона:
что можно не делать, сохранив достаточную точность?

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

Если бы вы были автором статьи…

  1. Оцените порядок: 30 FPS на 640×640, backbone X GFLOPs.
    При каких условиях двухстадийный детектор всё ещё рационален?

  2. Сетка 7×7 против 80×80 — что ломается в каждом крайнем случае?
    Как бы вы совместили оба режима в одной модели?

  3. Придумайте правило ответственности ячейки за объект без чтения современных assigner-статей.
    Где ваше правило даст дубли? Где — пропуски?

Дальше — пирамиды признаков: как сеть одновременно держит в голове муравья и грузовик.