partially unsupervised

Почти в каждом deep learning-based продукте, над которым я работал, на каком-то этапе где-то сбоку появляется небольшая линейная модель, обучаемая отдельно, иногда даже на классических фичах. Она, конечно, не может решать основную сложную задачу, но внезапно сильно помогает с каким-нибудь корнеркейсом. Например:
- определять резкую смену контекста (и необходимость сбросить стейт),
- детектить потенциальные ошибки или аномалии,
- слегка уточнять результаты сложного пайплайна,
- роутить инпут между компонентами,
- заполнять недостающий параметр, если в API вдруг не приходит какое-то поле, а менять что-то на клиенте слишком дорого,
- подсвечивать потенциальные проблемы человекам in the loop.

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

Вот сейчас у меня есть матрица расстояний в чем-то вроде матчинга, и нужно оценивать уверенность матча, потому что иногда лучше ответить ничего, чем неправильно. Сначала берешь собственно дистанцию, потом хочется добавить еще пару эвристик типа расстояния до second best кандидата, их нужно как-то взвешивать... Так что не надо брезговать классикой, и умение выжать лишний процент из линейной модели все еще полезно.

Реальность:
- надоело ждать полного прогона тестов на CI, между делом спрятал некоторые долгие джобы под if, чтобы они триггерились только для релевантных изменений.

Потенциальный пост в Linkedin:
- Pioneered a transformative project as part of a company-wide infrastructure efficiency and cost optimization strategy, establishing a scalable model that achieved a sustainable 40% reduction in CI operational costs across the AI organization.

Еще одно философское соображение, на этот раз по мотивам Нобелевки: некоторые мамкины комментаторы видят в наградах Хинтону и Хассабису сигнал, что нобелевский комитет вложился в nvidia разделяет неудержимый технооптимизм, e/acc и вот это все.

Но есть ироничный факт, что Дарон Аджемоглу, лауреат премии по экономике этого года, оценил рост мирового продуктивности за счет AI в 0.66% на горизонте 10 лет (т.е. примерно на порядок меньше оценок того же Goldman Sachs с их $7 триллионами за 10 лет).

Если кому-то вдруг интересно лично мое мнение: считаю, что предложенный фреймворк слишком линейный, и при некотором скепсисе на тему genAI верю в сдвиги в некоторых областях за пределами генерации контента в блогах b2b SaaS-компаний.

Иногда люди не видят лес за деревьями, и частный случай этого - не видеть здравый смысл за чеклистами.

Например, пишет мужик из издательства и намекает, что в книжке неоригинальный контент! Мол, переработайте перед печатью кое-какие куски, "so we can't be accused of any sort of plagiarism", и любезно присылает список этих кусков.

Открываем список и видим грозные коментарии "Needs rework; extremely close to the article text" и ссылки на какой-то notion, в котором человек составляет для себя конспект книги. Рекурсия!

Самая технически сложная задача, которой я занимался в последний месяц - заставить домашний wifi нормально работать.

Вроде бы я не совсем кретин в вопросах сетей: в далекие школьные годы админил домашнюю сеть и еще помню романтику одного ADSL-подключения на четыре подъезда и обжима витой пары отверткой. Казалось бы, с тех пор прогресс огого, не надо ползать по чердаку и прописывать роуты вручную, так что организовать wifi на три комнаты должно быть несложно. Но нет, разобраться, почему прекрасно работавшая сеть внезапно начала терять 30% пакетов между роутером и экстендером, совсем не тривиально. Воспроизводимость экспериментов оказалась хуже, чем в машинлернинге, и даже random seed не зафиксировать.

Все починилось совершенно само по себе на следующий день. И как в таких условиях не верить в соседей с облучателем, который вызывает интерференцию?

Среди статей на ICML нашел интересный топик - knowledge transfer from foundation models. Такая смесь дистилляции (которая фокусируется на переносе знаний между архитектурами) и трансфер лернинга (перенос знаний между задачами). Возьмем для примера две статьи, одна от Apple, другая от Amazon (неудивительно, что этим больше интересуются компании, чем университеты).

В Knowledge Transfer from Vision Foundation Models for Efficient Training of Small Task-specific Models авторы предложили т.н. task-oriented knowledge transfer - по сути нехитрая трехшаговая схема, что в каком порядке учить, что замораживать, как выбирать неразмеченный датасет. Ничего сверхординарного, зато много результатов экспериментов, подтверждающих полезность этой схемы.

Transferring Knowledge from Large Foundation Models to Small Downstream Models понравилась больше. В этой статье авторы предлагают своего рода выучиваемый feature selection поверх фичей из foundation моделей. Идея такая: надо заставить модель-студента выучивать только нужные фичи от учителя, а остальные можно игнорить (в отличие от обычной дистилляции, где студент должен выучить все, и обычно в пространстве предсказаний, а не фичей).

The core intuition behind AFT is that we want the downstream model to prefer making predictions based on information already present in the pre-trained features, as they are highly likely to contain useful knowledge for the downstream task, but without necessarily using all pretrained features, since not all of them will be relevant to the downstream task.

In contrast to KD, AFT does not penalize the downstream model (student) from forgetting some of the pretrained (teacher) features, and only penalizes learning extra features not extracted from pre-training.

Техническая реализация представляет собой дополнительную компоненту лосса, который регуляризует обучение основной модели, используя фичи от pretrained foundation модели. При этом можно использовать фичи сразу от нескольких моделей, и успешно дистиллировать их все. Кстати, оказалось, что для компьютерного зрения фичи из нескольких моделей более полезны, чем в NLP - авторы предполагают, что причина в большем разнообразии vision моделей по сравнению с однотипными языковыми трансформерами, обученными на одних и тех же датасетах.

Повторюсь: умение делать небольшие модели - важно и нужно.

Сел в поезд, еду в Вену жрать шницели со штруделем на ICML - пожалуй, это вторая по значимости академическая ML конференция после NeurIPS.

В первый и пока единственный раз я ездил на ICML восемь лет назад. Тогда конференция проходила в большом отеле в Нью-Йорке, и это привело к курьезу - я вышел из лифта не на том этаже, и оказался на встрече тогда еще кандидата в президенты Трампа с лидерами христианских общин. Пока что эвристика "поехал на ICML - Трамп стал президентом" работает со стопроцентной точностью, учитывайте в своих политических прогнозах!

Кажется, с разных сторон назревает некоторый антихайп про generative AI:

Например:
- Партнер в Sequoia насчитал, что с текущими инвестициями в железо genAI должен принести $600B, чтобы окупиться, и этого, конечно, не видно.
- Goldman Sachs оценивает будущие инвестиции в железо в триллион баксов (правда, без уточнения, за какой период) и тоже сомневаются в окупаемости
- Видеокарты не становятся фундаментально эффективнее, а в основном просто больше (правда, этот тейк относится к продвижению альтернативного железа, так что take it with a grain of salt).
- Economist утверждает про незначительный экономический эффект, несмотря на сотни миллиардов capex.
- Anecdotal data: лично разговаривал с парой человек, которые после тщательного анализа передумали лезть в некоторые на первый взгляд привлекательные ниши, где genAI вроде должен быть полезен: оказалось, что соотношение цена/качество (и полезность как следствие качества) не сходятся буквально на порядок.

Но подождите, рано ползти на кладбище. Вместо этого приведу цитату из requests for startups от YC:

Small fine-tuned models as an alternative to giant generic ones'

Giant generic models with a lot of parameters are very impressive. But they are also very costly and often come with latency and privacy challenges.
...
We are eager to support companies engaged in developing or fine-tuning such specialized models or creating tools to facilitate their construction.

Запрос на это не может не развиться: на foundation моделях хорошо строить прототипы, а вот скейлить и улучшать - гораздо сложнее. Например, мои бывшие коллеги делали решение для крупного банка, и их специализованный API получился примерно в 500 раз дешевле:

Enriching these transactions directly with GPT4-0314 , would cost $4.5M per day. With Ntropy, this costs $9k per day, a 500x reduction, while maintaining the same accuracy.

Окей, GPT4-0314 - это уже плохой выбор, GPT-4o обошлась бы в разы дешевле, но разбежка примерно на два порядка все еще сохраняется.

Как человек, который любит делать мелкие негигантские специализированные модели и не любит обещать API-based foundation моделям $100 чаевыми, я не могу не радоваться.

Это было предсказуемо: в 2024 легкая небрежность в тексте/коде окончательно стала премиальной и крафтовой. Пресный вежливый текст - значит, написано при помощи LLM (и даже без упражнений с промптами). Шероховатости придают эффект теплоты: человек не поленился и написал сам.

Например, пишет мне рекрутер, и второй абзац его письма выглядит как LLM-summary моего линкедин-профиля. Дальше как-то автоматически сложно поверить его словам, что this is exactly the type of experience they are looking for.

Или с другой стороны: проверяю тестовые задания, и довольно быстро калибруюсь. Например, много тривиальных комментариев, начинающихся с заглавной буквы и заканчивающихся точкой - явное свидетельство сгенеренного кода. Да ладно комментарии, я уже и по названиям переменных узнаю код авторства GPT.

# Init model.
model = Autoencoder.to(DEVICE)
criterion = nn.MSELoss()

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

В итоге умение писать кое-как теперь вообще не имеет значения, а умение писать изящно (будь то текст или код) ценится как и раньше.

Наша книга по ML System Design прошла третье - и последнее - ревью внутри паблишера. Я уже писал про ревью раньше, но вкратце процесс такой: издатель раздает 10+ потенциальным читателям текущую версию книги и заставляет писать много комментариев и отвечать на десятки вопросов. Ревью проводится после каждой трети книги, и потом анонимизированные комментарии сваливаются обратно авторам: чините, что считаете важным.

По результатам ревью выглядит так, что мы наконец-то научились писать: оценки выросли 3.75 → 4.36 → 4.73. Во многом это вызвано тем, что книга "отлежалась" - много мелких улучшений по результатам первых ревью, отзывов читателей (большое вам спасибо!) и собственных переосмыслений/дополнений. Еще в комментариях написали, что книгу стоило бы назвать Principles of ML Design. Мы вообще-то так и хотели, но издательство вежливо проигнорировало наше мнение по этому вопросу.

В общем, с нашей стороны все в целом готово, осталось пройти через пару кругов формальностей, дождаться корректуры, и тогда книга уйдет в печать (и все предзаказавшие печатную версию ее наконец-то получат). Зная неповортливость издательства, рассчитываю увидеть печатную версию к концу года.

В раннем доступе было продано чуть больше тысячи экземпляров. До завтрашнего дня у издательства скидки 50% на все, но я ни на что не намекаю :)

Беда пришла откуда не ждали: сегодня tensorboard насрал мне в штаны.

Ковырял задачу, в которой без оценки глазами пока никак. Сгенерил все семплы, сложил в тензорборд, предусмотрительно запустил с -samples_per_plugin images=100000, начал анализировать. Размер датасета я знал, пролистал все картинки, нашел ошибки, и бодро подытожил в духе: "так, среди 200 семплов у нас 4 ошибки, error rate 2%, проблема незначительна". Подытожил настолько бодро, что даже CTO поверил.

Внес небольшие изменения, пошел смотреть на различия и вдруг что-то зачесалось - как будто слишком быстро все просмотрел. Ну и оказалось, что в UI отображалась только примерно половина семплов. Пришлось вручную распарсить tensorboard-файл и со стыдом признаться, что в своей оценке масштаба проблемы я ошибся примерно вдвое.

Дата-дривен карго культ учит, что если метрики растут, а результат на глаз выглядит не очень, то метрики первичны, ведь они как будто имеют больший охват (например, весь тестовый датасет), чем то, что может увидеть один человек невооруженным взглядом. Я и сам долгое время был адептом этого тезиса, пока не наступил на достаточное количество граблей.

Проблема в том, что сделать сбалансированную метрику или набор метрик всегда сложнее, чем кажется (завсегдатаи Kaggle не дадут соврать). Именно поэтому в реальности приходится не оптимизировать единственную метрику верхнего уровня, а делать набор метрик и следить за всеми, а потом принимать субъективное решение, когда одна метрика неизбежно вдруг пойдет вверх, а другая вниз.

Буквально вчера на работе смотрел на результаты ML экспериментов и недоумевал: вариант, который и визуально мне нравился больше, и в теории должен был быть лучше, по метрикам выглядел хуже. Заподозрил проблему в недавно задизайненной метрике, поленился доказывать теорией, сделал "модель", которая генерила рандом с определенными свойствами и тут же выбил искомые 100%. Будь это корпорация с бездумной ориентацией на KPI, можно было бы закоммитить и бездельничать до конца квартала!