Как я вообще туда попал

Я крайне редко на фрилансе получал заказы связанные с DS/ML, специалистов для таких задач обычно ищут не там. Причины разные: они требуют долгой интеграции, заказчик сам не понимает задачу, DS более конфиденциален, DS часто возникают внутри продукта, да и в последнее время этот сегмент на фрилансе съедается при помощи LLM: AI integration, RAG боты например. По отдельности эти факторы не страшны, но их совокупность уменьшает количество таких проектов на российском фрилансе почти до 0.

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

Я откликнулся, задал кучу уточняющих вопросов - есть ли датасет, кто размечает, какая модель, где крутится. Заказчик ответил подробно, видно было что человек понимает задачу изнутри. Он написал:

Датасет надо делать, в этом и смысл задачи
Целевые проценты даны для ориентира, никто не знает что на самом деле достижимо. Готов принять и худшие результаты, если они объективно обоснованы

Вот это порадовало! Человек хочет не красивых цифр, а честный результат.
Предложил 140к, три этапа, поэтапная оплата - сделали этап, сдали, оплатили. Если что-то не устроит - можно уйти к другому разрабу с результатами. Так риски меньше для обеих сторон. Он принял:

Ваше предложение выглядит лучшим, как по адекватности понимания задачи, так и по репутации на площадке. Не вижу смысла дальше мучить себя и других...

Ну и поехали.

Требования, от которых голова кругом

На бумаге всё выглядело чётко:

Минимум 200 тегов
99%+ фото должны получить хотя бы один тег
Не более 3% фото с одинаковым набором тегов
Precision и recall — ориентир 90%
Работает локально, на CPU
Теги должны быть понятны обычному человеку без инструкции

И вот тут - штука, которая определила половину инженерных решений. Заказчик сразу обозначил:

Продукт включает только dlib для распознавания лиц. Он добавляет всего 5-10 МБ. Все модели из OpenCLIP потребуют torch, а он сам что-то вроде 300+ МБ

То есть нельзя просто взять SOTA-модель и сказать «вот, короче, работает». Она может не влезть в продукт. Это не академическая задача, а продуктовая. Ну и разница между ними - как между «решить уравнение на доске» и «построить мост, который не упадет».

Почему это не «ещё одна классификация картинок»

Я поначалу думал - ну, классификации, embedding, cosine similarity, дело техники)
Но..! ошибался.

Пользовательские архивы - это хаос. Типичный набор фотографий с телефона - это фото детей вперемешку со скриншотами переписок, мемами из чатов, фотографиями доков, случайными картинками и десятками дублей. Примерно треть архива - это даже не фотографии в привычном смысле. Но именно этот хаос и нужен)

Люди ищут не объекты, а воспоминания. Когда человеку нужно найти фото, он не думает «покажи объекты класса nature». Он думает: «где фото с той прогулки» или «найди фотки с моря», «убери все скрины». Это совершенно другая задача.

Теги должны работать как фильтры. Не «вот 50 тегов на фото, разбирайся сам» - а «вот 2-3 точных тега, которые позволяют сузить архив из 100 000 фото до 20». Заказчик сам привёл пример:

Желание найти фото "женщина в красном платье на фоне моря" может быть описано тремя тегами "портрет женщины", "море", "яркая одежда". Этого достаточно чтобы сузить архив из 100 000 фотографий до двух десятков и выбрать нужную глазами.

Красивая постановка. Осталось реализовать)

Как выяснилось, что в интернете нет ответа на главный вопрос

Вот здесь начались отхождения от начального ТЗ.

Заказчик был убежден, что можно пойти в интернет и найти то, как люди ищут свои фотографии. Что где-то на Reddit, в Google Photos, в обзорах - люди обсуждают, какие теги они ставят, как классифицируют свой архив. Он даже скинул мне свой диалог с DeepSeek на эту тему.

Я сел изучать. И выяснил, что этого не существует.

К Google Photos чужим - нет доступа. Нельзя посмотреть, как другие люди организуют свои фотки, какие альбомы создают, по каким словам ищут. Это все закрыто. Да и в России не много кто намеренно разбирает фотки в Google Photos. Скорее они по дефолту иногда туда загружаются. Reddit - просто никто об этом не говорит. Гипотеза о том, что люди в интернете обсуждают, как они классифицируют свои фотки, - оказалась неверна. Может, лет двадцать назад это было актуально. Сейчас - УВЫ! Люди не думают про организацию архива, пока у них не накопится 50 000 фото и они не захотят найти конкретное.

На стоках типа Shutterstock, Unsplash, Pexels - теги есть, но они коммерческие. Они нужны для SEO, чтобы фото находили в интернете. «Happy», «business», «success» - это маркетинг, а не память. Огромная разница между тем, как интернет по алгоритму классифицирует фотографии, и тем, как человек для себя их обозначает. И вот тут мы с заказчиком пришли к выводу, что нельзя найти в интернете готовый ответ на вопрос «как люди для себя классифицируют фотки». Либо данных нет, либо их дистилляция заняла бы столько времени, что это был бы отдельный проект.

Недолго думая, я решил: сам придумаю. Я же человек. Пообщался с окружающими, с женой, сам с собой подумал - на какие сцены можно разделить фотографии. Не абстрактно, а конкретно: вот я открываю галерею, мне нужно найти фото - о чём я думаю в этот момент? И понял одну важную вещь. Люди мыслят не объектами. Не «красивый лес» и не «два человека». Люди определяют фотографии по месту, по ощущениям, по времени и настроению. «Это было летом на даче». «Это когда мы тусовались в парке». «Это тот вечер в центре, когда шел дождь». Память работает через контекст, а не через перечисление объектов.

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

Оси памяти

Получилось шесть основных координат:

Тип контента - фото, скриншот, мем, документ, коллаж
Место / сцена - дом, улица, парк, пляж, кафе, горы
Активность - прогулка, спорт, еда, шоппинг, путешествие
Событие - день рождения, свадьба, Новый год
Люди —- мужчина, женщина, ребенок (не конкретные лица — это уже было в продукте)
Качество и условия - темное, размытое, засвеченное, дождь, снег

Каждая ось - координата, по которой человек может сузить поиск. Комбинация 2-3 осей даёт достаточно узкую выборку, чтобы найти нужное фото глазами.

Как я собирал 122 000 фотографий

Заказчик сразу сказал: нужно минимум 100 000 фото для тестирования. Свои он давать не готов - они пойдут на валидацию результатов. Предложил: "Возьмите свои фотки и фотки знакомых/родных. Плюс можно поскачивать из интернета"

Я начал с идеи собрать по знакомым. Быстро понял - никто не хочет делиться своими фотками. Это личный архив, там все - от нелепых селфи до документов. Люди не готовы это отдавать. И даже если бы согласились - это не набрало бы 100 000. То есть суммарно мне скинули около 400 фоток.

Тогда я пошел в Telegram. Написал парсер на Telethon (userbot на Python), который проходил по каналам, проверял последние 20 000 сообщений и выгружал фотографии. Только открытые каналы, только публичный контент.

Но не случайные каналы. Я уже имел черновое древо тегов и для каждого тега искал тематический канал. Собаки - каналы про собак. Дети — родительские чаты. Тусовки, концерты, еда, путешествия, горы, дача - на каждый тег свой источник. Плюс обязательно - каналы, где люди просто делятся своими фото, без тематики. Потому что типичный архив - это не тематическая подборка, а хаос. Много рандомных фото нашел в источниках типа "фото для фейка", "фото на аву". Были классные каналы фотографов - прям удовольствие местами получил

Потребовалось около 70 каналов. На выходе - 122 000 изображений: фотографии разного качества, скриншоты, мемы, документы, дубли, случайный мусор.
К концу, правда, понял, что для некоторых тегов эталонных фото не хватало - не все можно найти в открытых каналах. Но для MVP хватило.

Этап 1 — "Мы не оптимизируем. Мы выясняем, где сигнал"

Принцип первого этапа я зафиксировал жестко: никакой оптимизации. Только проверка - есть ли вообще сигнал?.. Потому что соблазн "а давайте ещё вот это попробуем" — он на каждом шагу. И если не ставить четких границ - будет страшно.

Максимально тупой pipeline

Для первого прохода - простой подход. Без обучения, без fine-tuning. Чистый zero-shot:

image → CLIP embedding (ViT-B-32)
tag → набор текстовых промптов
score = cosine_similarity(image, prompt)
if score >= threshold → assign tag

Каждый тег описывался несколькими текстовыми промптами. Один глобальный порог. 39 тегов. 122 000 фото. Один вопрос: работает или нет?

Результат удивил

Я взял top-30 фотографий по каждому тегу и глазами проверил.

21 тег - точность 90-100%. Пляж, парк, дом, селфи, еда, прогулка, пикник, транспорт. Без единого обучающего примера. Просто по текстовому описанию.

Ещt 9 тегов - 70-89%. И 9 провалились ниже 70%.

Думал будет больше шума, а оно работает)
На бытовых категориях zero-shot CLIP дает адекватный результат.

Но тут же вылезла системная проблема

Текстовые промпты оказались слабым звеном.

birthday, wedding, new_year — для CLIP это почти одно и то же. Люди, еда, украшения, помещение. Модель не виновата - она видит визуально похожие сцены, и никакая формулировка промпта не помогает их различить.

document путался с фотографиями книг. screenshot - с селфи в зеркало. meme - со скриншотами переписок.

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

Что сказал заказчик

Заказчик подтвердил приемку первого этапа и сразу обозначил направление:

Вижу, что вы строили работу вокруг текстовых промптов, для первой стадии это вполне естественно. Однако, если строить классификатор не по текстовым промптам, а по эмбеддингам картинок - мы вообще будем не привязаны к лексическому модулю, и сможем использовать не только CLIP, но и любую другую архитектуру.

Заказчик сам предложил ключевой поворот проекта. Не потому что ML-инженер - а потому что продуктовый разработчик, который думал на шаги вперед. Если мы завязаны на текстовый энкодер CLIP - мы завязаны на весь стек! А это, так то, 300+ МБ в дистрибутиве.

Вывод первого этапа уместился в одну фразу: сигнал есть, текст -узкое место.

Ключевой поворот: от слов к изображениям

Самый важный архитектурный момент проекта. Он изменил всё.

Было: класс = набор текстовых описаний.
Стало: класс = набор эталонных фотографий.

Вместо того чтобы объяснять модели текстом, что такое "пляж" - мы показываем ей 120 фотографий пляжей. Модель считает средний эмбеддинг - "центроид класса". Новое фото сравнивается не с текстом, а с этим вот центроидом.

Что это даёт:

Нет зависимости от текстового энкодера. Можно использовать любую модель, которая превращает картинку в вектор: CLIP, ResNet, MobileNet, dlib - да что угодно!
Нет лексической ловушки. "День рождения" и "свадьба" различаются не по словам, а по визуальным паттернам.
Объяснимость. Можно посмотреть, из каких фото состоит класс. Понять, почему модель ошиблась. Улучшить - добавив или убрав примеры, например.
Масштабируемость. Новый тег = новая папка с фотографиями. Никакого переобучения.

Провал с hard negatives

Помимо положительного центроида нужен был отрицательный — чтобы штрафовать за «похож на общий фон». Рабочая формула:

score(tag) = cos(image, centroid_positive) - cos(image, centroid_negative

Это сильно снизило false positives. Но дальше я попробовал hard negatives - вручную подобранные «похожие, но не то». Если beach путается с pool - добавим фото бассейнов как negative.

Результат жесть. Слишком узкие negatives сломали шкалу скоров - модель начала видеть "пляж" в совершенно случайных фото. Массовый over-tagging.
Ну надо запомнить: negative нужен, но нейтральный фон датасета работает лучше ручного подбора. А для конфликтующих классов - нужен отдельный фильтр постфактум.

Этап 2 — шесть моделей и момент, когда заказчик сказал "это отстой"

Зачем сравнивать, если CLIP работает

Потому что продуктовые ограничения. PyTorch - 300+ МБ. У заказчика уже есть dlib - 5-10 МБ. Если эмбеддинги можно считать через dlib или TFLite - продукт распухнет на 50-80 МБ вместо 700. Это не академический интерес - это натуральное бизнес-требование.

Шесть кандидатов

CLIP RN50 - основной кандидат
CLIP ViT-L/14 - потолок качества (для контекста, не для прода)
MobileNet v3 Small - компактный
ResNet50 (ImageNet), EfficientNet-B0
dlib модели - ResNet34, ResNet50, ViT-S-16

Первый прогон: красивые цифры, которые ничего не значили

Первую версию сравнения я построил на coverage - какой процент фото получает тег. MobileNet показал лучший coverage. Я был доволен.

Но не заказчик:

Мы померяли охваты моделей, но это не то же самое что recall. У нас нет числовых показателей precision/recall. Сложно так принимать решение о выборе.

И далее:

Честно говоря, цифры немного расстраивают... RN50 конечно лучше, но тоже отстой.

Ну тут важно сказать одну вещь: когда заказчик говорит "отстой" - я не воспринимаю это как претензию к своей работе, я ж не изобретаю нейросеть с нуля. Я делаю research - беру готовые предобученные модели, делаю эмбеддинги, показываю результат. Если результат слабый - это факт о модели, а не результат моей работы. Это отчётность о чем-то фактическом. Я выявил результат, и точка.

Но пинок был правильный. Потому что coverage - действительно не recall. И без честного P/R/F1 нельзя принимать решение.

Как пришлось перестроить всё

Собрал GT-датасет - 5500 фото, размеченных вручную по 15 тегам
Посчитал честный Precision / Recall / F1 для каждой модели
Добавил режимы сравнения: target P ≥ 0.9, target R ≥ 0.8
Добавил метаданные: размер, лицензии, runtime, CPU latency
Прогнал SOTA-ceiling - ViT-L/14

Заказчик еще отдельно ткнул в мою ошибку с dlib:

Почему вы из dlib взяли dlib_face? Это же для распознавания лиц, а не картинок. Там же есть resnet50_1000_imagenet_classifier, vit-s-16. Почему не попробовали их?

Действительно. Я взял face-модель как feature backend - проверить принцип работы dlib. Но нужно было брать classifier-модели. Протестировал дополнительно.

Результат

На GT (5500 фото, 15 тегов):

Модель	Precision	Recall	F1
RN50 (CLIP)	0.466	0.853	0.557
ViT-L/14 (ceiling)	0.644	0.565	0.538
MobileNet v3	0.457	0.712	0.514
dlib ResNet34	0.442	0.450	0.339
dlib ViT-S-16	0.432	0.200	0.203

Три наблюдения:

Первое. Разрыв между RN50 и потолком (ViT-L/14) - небольшой. При этом ViT-L/14 в три с лишним раза медленнее (153 vs 45 мс/фото). Потолок качества подтверждён - но он не настолько далеко, чтобы оправдывать тяжёлую модель.

Второе. dlib провалился. ImageNet-обученные модели дают эмбеддинги под 1000 фиксированных классов, а у нас - multilabel, пользовательские сцены, абстрактные теги типа walk и travel. Заказчик сам это резюмировал:

Они же на 1000 классах учили, а не на контрасте как CLIP

Другая постановка - другие требования к пространству эмбеддингов.

Третье. MobileNet был быстрее и компактнее, но ручная валидация показала: на сложных тегах больше borderline-случаев, однотипные результаты. Когда RN50 путает день рождения со свадьбой - это все таки визуально близко. Когда MobileNet путает день рождения с любым столом с едой - это уже раздражает.

Финальное решение: RN50 (CLIP) через ONNX Runtime. Без PyTorch в продакшене. ~45 мс на фото на CPU. ~77 МБ весов.

Этап 3 - "Меньше экспериментов, больше фиксации"

Третий этап - не про исследования, а про то, чтобы зафиксировать и упаковать все, что выжило после первых двух.

81 тег

Система выросла с 39 до 81 тега по всем шести осям. Места, активности, события, типы контента, люди, качество и условия - от beach до moon, от selfie до stairwell.

Индивидуальные пороги

На первом этапе - один глобальный порог. На третьем - каждый тег получил свой, подобранный по precision-recall кривой. Для beach - высокий (модель уверена). Для birthday - компромисс между "хоть что-то" и "не врать".

Conflict-фильтр

screenshot и meme - скриншот переписки часто содержит мем. birthday и wedding - модель может поставить оба. Если два конфликтующих тега прошли порог - остается тот, у которого score выше.

Fallback для покрытия

Без fallback - 52.73% фото с тегами. С fallback — 99.07%.

Если ни один тег не прошёл порог - берется лучший тег с минимальным порогом. Это не "точный тег", а "лучшее предположение". Но для навигации - лучше, чем ничего. В отчетах я всегда считал эти цифры отдельно. Потому что coverage с fallback - продуктовая метрика. Coverage без - качественная. То есть - не путать их!.

Дополнительный этап - уменьшение размерности

После того как RN50+CLIP через ONNX стал финальным выбором, заказчик вернулся к вопросу, который поднял ещё на этапе 2:

Снижение размерности. 1024-мерный вектор - избыточен для 81 тега. Можно ужать?

Вопрос не праздный: меньше размерность - быстрее retrieval, меньше памяти. Договорились начать с 512 и смотреть, что теряется.
Проверяли два метода: PCA 512d и Random Projection 512d.

Ловушка красивых чисел

Автоматические метрики выдали неожиданную картину

Режим	Precision	Recall	F1	overlap@10
Baseline 1024d	0.823	0.474	0.542	—
PCA 512d	0.344	0.998	0.484	0.810
RP 512d	0.828	0.440	0.514	0.735

PCA показывает recall 0.998 - почти идеальный. Выглядит как победа. Но precision 0.344 - печаль. Модель начала ставить теги буквально всему. Та же история с coverage: загрубил - получил красивую цифру. Только здесь не намеренно - пространство схлопнулось, все эмбеддинги стали ближе друг к другу, и старые пороги поехали.

RP ведёт себя честнее по агрегатным метрикам, но хуже держит retrieval: overlap@10 = 0.735 против 0.810 у PCA.

По числам непонятно, нужна ручная проверка.

Что показала ручная валидация

Подготовил артефакты для визуального сравнения: для 30+ query-изображений - top-10 соседей в каждом из трех режимов, для сложных тегов (birthday, wedding, screenshot, walk и других) - top-30 кандидатов по score. Около 2000 примеров прошли ручную оценку.

Результат по retrieval - доля визуально осмысленных соседей:

baseline: 0.940
pca_512: 0.947
rp_512: 0.927

PCA не только не деградировал - он чуть лучше держит retrieval, чем baseline. По classification на сложных тегах деградации, заметной для пользователя, не выявлено.

Вывод простой: агрегатные метрики врали. Precision 0.344 - артефакт порогов, которые нужно перекалибровать под новое пространство. Визуальное поведение системы осталось рабочим.

Финал: PCA 512d в продакшене. Вдвое меньше размерность, быстрее retrieval, меньше памяти - без практической потери качества.

Итоговые цифры

GT-оценка (7000 фото, 30 тегов)

Precision: 0.654
Recall: 0.634
F1: 0.566

Полный прогон (122 263 фото)

Coverage с fallback: 99.07%
Coverage без fallback: 52.73%
Среднее тегов на фото: 1.558
Уникальных наборов тегов: 2023

Финальная конфигурация

RN50 (CLIP) → ONNX Runtime → PCA 512d. Размер модели ~77 МБ, ~45 мс на фото на CPU, 512-мерный эмбеддинг вместо 1024.

Разбор

F1 = 0.566 - это не 90% из ориентира. Но давайте разберём.

Macro-усреднение считает каждый тег одинаково. Сильные теги (beach, selfie, park) дают 95-100%. Слабые (birthday, eating) тянут среднее вниз. Ищешь "фото с пляжа" - работает отлично. "Фото с дня рождения" - шумнее.
Потолок подтверждён. SOTA-модель (ViT-L/14) на том же GT — F1 = 0.538. Не лучше RN50. Ограничение не в модели, а в сложности самой задачи.
52.73% без fallback - не "модель работает наполовину", на половине фото модель уверена для жесткого порога. Остальные получают тег через fallback - менее уверенно, но полезно для навигации.

Про LLM в этом проекте

Весь код написан через LLM. Скрипты эмбеддинга, классификации, прогонов, валидации, экспорта в ONNX - все сгенерировано. Я работал в основном с Codex, там пока лимиты повышены на версию 5.3.

Конечно, были тупежи. Самый показательный - на третьем этапе мы с заказчиком четко зафиксировали: работаем с RN50. Все к этому подготовили и я смотрю - а Codex мне генерирует скрипт эмбеддинга на совершенно другую модель. ViT-S-16, вроде как - короче, не RN50. Я ему: "В спецификации конкретно написано, что мы работаем только с RN50". А он просто проигнорировал контекст и взял что ему показалось подходящим.

Галлюцинации немного удлиняли процесс. Но в целом - все равно это намного быстрее, чем писать все скрипты руками. А их было достаточно много: парсер для сбора фото, эмбеддинги, прогоны по моделям, валидация, визуальные сэмплы, GT-оценка, экспорт ONNX, conflict-фильтр, fallback-логика. Руками это было бы в разы дольше.

Но - и это важно - архитектура, таксономия тегов, выбор модели, интерпретация результатов - это инженерная работа. Нейросеть не скажет тебе, что coverage - не recall. Не скажет, что дни рождения путаются со свадьбами потому что это контекстно разные, но визуально похожие события. И уж точно не придумает за тебя оси памяти, основанные на том, как реальные люди вспоминают свои фотографии.

Это должен понять человек.

Пять вещей, которые я вынес

Сначала таксономия, потом модель. beach работает на 100% не из-за модели, а потому что пляж - визуально однозначная категория. birthday не работает не из-за модели, а потому что день рождения - контекст, а не визуальный паттерн. Если не зафиксирован язык тегов - сравнение моделей бессмысленно.

Zero-shot - лучший разведчик, худший продакшен. Для первого прохода - гениально. За день можно проверить 50 гипотез. Строить на нём продукт - ловушка.

Coverage - опасная метрика. Можно загрубить пороги и показать 95%. А потом пользователь увидит, что на его борще стоит тег beach - и удалит приложение.

Продуктовые ограничения формируют архитектуру. Размер дистрибутива, CPU latency, лицензии - это не "потом разберемся". Это часть архитектурного решения с первого дня.

Заказчик, который говорит "отстой" - хороший заказчик. Каждый его пинок заставлял меня перестроить что-то конкретное. Каждый раз результат становился лучше. Проект, где заказчик только говорит "ок, супер" — это проект, где никто не проверяет качество.

Что дальше

Проект завершён, развитие - отдельные треки:

Расширение до 200 тегов. Черновая иерархия на 190 готова. Нужен пересбор прототипов и калибровка.

Квантизация. FP16 работает без заметных потерь. INT8 — нужна отдельная валидация.

Снижение размерности. 1024-мерный вектор — избыточен для 81 тега. Заказчик сам предложил гипотезу — можно ужать до 10-20 параметров. Но это отдельный scope, потому что затрагивает ещё и поиск похожих фото.

Усиление сложных тегов. Событийные классы (birthday, travel, eating) требуют не смены модели, а расширения и доочистки прототипов.

Вместо заключения

Фотографии - это не изображения. Это фрагменты памяти. И когда строишь систему навигации по ним - самый важный вопрос не "какая модель лучше", а "как человек будет это искать".

Если ответ правильный - даже простой cosine similarity с прототипами дает результат, которым можно пользоваться. Если неправильный - никакой ViT-L/14 не поможет.

Инструмент - усилитель. Но усиливает он то, что ты в него вложил.

Проект выполнен как фриланс-заказ для десктопного приложения каталогизации фотоархивов. Все данные - из реальных отчетов и переписки. Немного пиара моего канала. Если есть вопросы по техничке - пишите в комментариях.

Как я учил компьютер понимать 122 000 фотографий — и почему сложностью оказались не нейронки, а слова