Рубрика "мои кенты - мое богатство". 👬

Я обещал написать про быстрый инференс, и вот подвернулся случай. У меня есть два предпочтения, которым я предпочитаю следовать в дизайне инференс-сервисов:
- никаких динамических графов, все должно быть сконвертировано в ONNX, даже легкие scikit-learn модели, и потом гоняться в ONNXRuntime. Это и минимизирует ошибки с одной стороны, и позволяет дешево сменить core model, да и запускать можно одинаково хоть локально, хоть на сервере, только бэкенд подмени;
- если можно что-то вынести на serverless (например, в AWS Lambda), надо выносить - это простой способ сглаживать нагрузку.

У лямбд есть несколько проблем:
- неидеальное масштабирование (с нуля до многих тысяч параллельных запусков мгновенно не вырастешь, что бы там ни говорили маркетинговые описания);
- медленный cold start (в эту сторону есть подвижки);
- нет GPU, и потому инференс жирных моделей скорее затруднителен, да и экономически не очень выгоден.

Так вот, мои старые кореша Андрей и Игорь решили починить одну из этих проблем и пилят платформу everinfer.ai, которая прям соответствует моим представлениям о прекрасном:

from everinfer import Client

client = Client('my_secret_key') 
pipeline = client.register_pipeline('my_model_name', ['onnx/model.onnx'])
runner = client.create_engine(pipeline['uuid'])
preds = runner.predict([inputs]) 

Внутри ONNXRuntime, Rust 🦀, ScyllaDB и прочие модные технологии, благодаря чему инференс получается довольно быстрым. Слегка потестировал, получилось чуть быстрее локального запуска ONNXRuntime на CPU, даже с учетом сетевых издержек.

Платформа только-только открывается для внешних пользователей и предлагает первым тестерам бесплатное железо для инференса и помощь в запуске (хотя API простой как табуретка, вряд ли понадобится много помощи). Можете писать сразу @andrey_kiselev и просить доступ.

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

Рабочие на заводах Форда были гораздо более продуктивны, зарабатывали сильно больше, чем на других производствах (The gains in productivity allowed Ford to increase worker pay from $1.50 per day to $5.00 per day once employees reached three years of service on the assembly line), но монотонность и темп работы делал ее значительно более тяжелой. Использование кардинально новых инструментов (copilot, explainpaper, chat GPT) может в разы увеличить эффективность любого белого воротничка, но требует определенной адаптации. Я знаю несколько крутых программистов, которые утверждают, что в их задачах copilot не поможет, хотя они и не пробовали; это нормальная инерция. Начать использовать больше инструментов - это большая ментальная нагрузка, и больше непривычных переключений контекста. Там где раньше человек решал одну задачу за единицу времени (будь то написание софта, маркетингового текста или презентации для клиента), с мощными инструментами он сделает две или три, но вникать в контекст каждой задачи все еще придется, и это зачастую сложнее, чем собственно написать сто строк говнокода. Вдобавок инстрмуенты пока сыроваты, за ними нужно приглядывать. В общем, повышение эффективности будет неизбежно, но небесплатно.

А в более долгосрочной перспективе этими инструментами начнут пользоваться все, кто не готов жить под мостом или идти работать баристой, и окно возможностей, открытое сейчас у early adopters, закроется.

Досталась мне на работе система, за которую до недавних пор отвечал умный, но неопытный PhD. Задача по сути сводится к text classification, внутри некий трансформер и все по классике: много кастомного, вычурный оптимайзер, дубликаты в данных и так далее. И, конечно, все надо улучшать - от точности до скорости.

В комплекте с системой полагался въедливый коллега, который с радостью согласился пойти разгребать авгиевы конюшни датасетов. А я взялся за инженерную часть. Кое-какая инфраструктура уже была: тесты, CI, обучение в докере - до этого мы с другим коллегой занимались переносом этого хозяйства из jupyter ноутбуков во что-то воспроизводимое. Так что надо можно было более или менее смело лезть в сам training pipeline.

Обучение занимало ~10-11 часов на одной A100, что в целом приемлемо, но, судя по низкой нагрузке и CPU, и GPU, можно было сделать лучше. Перенес часть препроцессинга из __getitem__ в __init__, избавился от pandas, выкинул лишние данные из памяти, что-то закэшировал, увеличил количество воркеров для датасетов, увеличил батчи - и GPU стала загружаться на ~95-98%, а обучение стало втрое быстрее. С такими скоростями уже можно быстро итерироваться.

Основная модель весила больше гигабайта. Я посмотрел на граф и обнаружил, что больше половины весов - это жирная мультиязычная embedding матрица инпута. Пошел в Athena и добыл неразмеченный датасет вида SELECT * FROM DATA WHERE THINGS ARE NOT LIKE FULL GARBAGE LIMIT OVERDOHOOYA, прогнал его через токенайзер, подтвердил гипотезу, что реально используется <50% токенов. Значит, можно переучить токенайзер и заменить эмбеддинг слой на значительно меньший, предварительно скопировав предобученные веса полезных токенов. Это уменьшает размер модели примерно до 60% от оригинального (правда, без заметного эффекта на скорости инференса). Потребление памяти важно для рантайма, ведь можно держать в памяти одного инстанса больше моделей, там как раз был боттлнек.

Кстати, раз у нас есть большой неразмеченный датасет, это звучит как повод устроить pretraining. Адаптировал masked language pretraining пайплайн с huggingface 🤗, и оставил новую, уже уменьшенную модель учиться на недельку. И, наконец, заменил дефолтные веса в основном пайплайне на результат претрейна на этом неразмеченном датасете. Это не только улучшило точность (на разных тестовых датасетах от 10% до 20%) и вторичные метрики вроде калибровки, но и ускорило сходимость, т.е. можно безболезненно уменьшить количество эпох еще на треть.

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

Я когда-то писал про residential proxies, и вот случайно наткнулся на еще один способ, как такие компании набирают себе пул прокси.

Захотел поставить на телевизор Apple TV, пошел в LG app store, глаз зацепился за приложение Xmas Tree в блоке рекомендаций. Как нетрудно догадаться, приложение показывает елку на фоне горящего камина, но в настройках есть чекбокс "Режим HD" с любопытной подписью мелким шрифтом типа "Разрешить bright data ltd использовать вашу сеть". Bright data - один из крупных поставщиков прокси, на одной из прошлых работ использовали их как раз для парсинга цен конкурентов.

Киберпанк, который мы заслужили: рождественская OLED елка, которая в фоне что-то скрапит.

P.S. Всех с рождеством! 🎄🎅

Для тех, кто предпочитает аудиовизуальный контент, а не эту всю писанину: поговорили с Антоном, одним из самых крутых инженеров и спикеров в русскоязычной computer vision тусовке. Обсудили Copilot, chat GPT и прочие LLM-based инструменты, и как они могут повлиять на околоDS карьеры.

Увидел очередную статью про определение людей и их поз по WiFi-сигналу, и нахлынули воспоминания.

Идея "видеть сквозь стены через wifi" не отпускает ресерчеров уже давно, не меньше 10 лет. На этот раз к ней подошли через любимый мной densepose (я пару раз пытался применять его в работе, но всегда выживал какой-нибудь другой подход), и вроде даже работает. Я склонен верить картинкам и метрикам, потому что Fernando De la Torre - чувак довольно авторитетный!

В умеренно далеком 2019, когда я рисовал AR-кроссовки, на CVPR меня познакомили с Фернандо, который на тот момент был менеджером AR-ресерча в Facebook. Прекрасный шанс запитчить наши наработки и попасть на радар к Facebook, который тогда еще активно покупал стартапы. И вот, после нескольких минут хвастовства, какое у нас технологически охуенное приложение, он задал мне простой вопрос: "окей, приложение хорошее, а в чем ваша команда по-настоящему, на мировом уровне, сильна?". Я растерялся, пробубнил что-то невнятное, и Фернандо мгновенно утратил к нам интерес. Так я просрал шанс, но и он упустил шанс получить промо, недорого прикупив клевых белорусских гребцов.

Кстати, вопрос "в чем ты крут на мировом уровне" мне задавали с тех пор еще один раз, и я снова ответил уклончиво. Хороший повод для карьерной рефлексии!

Применил на работе прием, который считал общеизвестным, но, судя по реакции коллег, это не совсем так. Потому расскажу и здесь!

Предположим, для какой-то ML задачи нужна ручная разметка данных, и расходы сколько-то заметны💰 (а значит, в 2023 их наверняка предложат урезать 🔪). В такой ситуации хочется хотя бы приблизительно понимать, как эти инвестиции в разметку окупаются.

Мое сколько-то наивное решение такое:
- делим тренировочный датасет на бакеты так, минимизируя разницу размеров бакетов и некоторое сходство между семплами разных бакетов (например, все семплы одного пользователя попадают в один бакет, который определяется на базе хэша его id);
- фиксируем вычислительный бюджет (вне зависимости от размера датасета учимся на N батчей);
- учим модель на сабсетах в диапазоне от малой части датасета до целого датасета, обеспечивая кумулятивного увеличение датасета (например, если некий семпл X был в обучении на 10% сабсете, то он обязательно будет и в обучении на 20% датасета);
- для каждой обученной модели смотрим ключевую метрику и рисуем график: по оси X - размер датасета, по оси Y - улучшение метрики;
- включаем воображение и оцениваем с точностью до порядка, сколько данных нужно досыпать, чтобы выжать следующий 1% метрики.

Точность такой экстраполяции оставляет желать лучшего (например, совершенно не учитывает штуки типа concept drift), но она значительно лучше, чем "хер его знает!", и сильно упрощает принятие решений типа "что выгоднее: отправить джуна подбирать гиперпараметры или нанять десять разметчиков и дальше заваливать модель данными".

Сделал вчера неочевидный баг в простом коде и какое-то время тупил, это ли не повод оставить задачку для уважаемых подписчиков?

Задача такая: из некоторого списка тегов отбираем наиболее важные по словарю рангов, формируем промпт и отправляем в модель. Что не так с этим кодом?

import typing as t


def predict_from_tags(model: BertModel, tags: t.Sequence[str]):
    prompt = prompt_from_tags(tags, model.tag_ranks)
    return model.predict(prompt)


def prompt_from_tags(tags: t.Sequence[str],
                     tag_ranks: t.Dict[str, float],
                     max_tags: int = 20,
                     allow_duplicates: bool = False,
                     ) -> str:

    if not allow_duplicates:
        tags = list(set(tags))

    sorted_tags = sorted(tags, key=lambda x: tag_ranks.get(x, float("inf")))
    return " ".join(sorted_tags[:max_tags])

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

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

Будучи еще достаточно молодым человеком, необремененным достаточным количеством тормозов, я отправил на всю соседнюю команду письмо, подписанное HR, с просьбой написать объяснительные по поводу "регулярного распития алкоголя в офисе и иных проявлений аморального образа жизни". После невнятного шума за стенкой, их директор выбежал из кабинета, со сложным лицом прибежал к HR-директору, через какое-то время они дошли до админов, наконец, к концу дня история дошла до моего босса.

Мой босс был отличным мужиком, который в т.ч. ценил шутки. И вместо того, чтобы выдать мне заслуженных пиздюлей, он отсмеялся и начал диктовать мне следующий пранк-емейл своему другу и коллеге: "Уважаемый Н.Г.! Просьба явиться завтра в 13:00 по адресу [главное управление КГБ Беларуси] для проведения оперативно-розыскных мероприятий…".

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

Грустная ирония всплыла в новостях спустя 12 лет. С подачи КГБ уважаемый Н.Г. внесен в список лиц, причастных к «финансировании террористической деятельности», что в переводе с белорусского мусорского новояза чаще всего значит что-то очень достойное.

Давно ничего не писал про прогресс с книгой, а ведь он есть!

Позавчера созванивались с новым редактором книги по ML System Design - предыдущий уволился после пяти глав, интересно, насколько велик наш вклад в его решение. Новый редактор оказался приятным и толковым дядькой, хотя его linkedin сначала вызвал у меня скепсис: например, до работы в издательстве он долго работал в одной компании на позициях типа Senior XML Architect 🤯. Но большe меня удивило то, что он одновременно работает над 18 (!) книгами. Я бы свихнулся от такого переключения контекстов.

А вообще мы обсуждали early access: продажи книги Chip Huyen ярко подтвердили интерес к теме; и мы, и издательство хотим зарелизить первые главы до окончания всей книги. Сейчас в работе седьмая глава из семнадцати запланированных, в ранний доступ пока планируется выложить пять глав, и добавлять примерно по главе в месяц.

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

Самая неинтутивная вещь про работу программиста: на каком-то уровне сеньорности чем больше времени ты пишешь код, тем хуже. И дело не в том, что надо уметь писать быстрее, а в том, что написание кода становится прокрастинацией, а максимальную пользу для компании человек мог бы наносить другими, более "менеджерскими" способами: планирование, дизайн, уточнение требований, поиск корнер кейсов, ревью, фидбеки, приоритизация, обучение менее опытных коллег etc. Но такая работа часто сложнее и менее комфортна, и потому эскапизм в родную IDE - как глоток свежего воздуха.

Кстати, про IDE - утащу из одного чатика инсайд от сотрудника Jetbrains:
> В JB было сделано внутреннее исследование, сколько кодят разработчики - и выяснилось, что почти по всем языкам это порядка 10 строк кода в день в среднем; потом это исследование решили не публиковать.

(Не знаю, насколько этому исследованию можно доверять, но сойдет как иллюстрация того, что не кодом единым).

Когда именно с этим парадоксом сталкивается конкретный IC, зависит от окружения. Эвристика простая: чем более ты сеньорный относительно прочих в своей команде/организации, тем меньше кода нужно писать. И потому на каком-то этапе карьеры надо либо осознанно перековываться в человеки-которые-[почти]-не-пишут-код, либо целенаправленно идти в такой орг, где личная максимальная полезность оказывается именно в написании кода, обычно это какие-то сложные специфические системы, и такого в индустрии маловато.

Еще, конечно, всегда можно вырулить в соседнюю область, которая дисконтирует предыдущую сеньорность, но это только временное решение.

Большую часть своей ML карьеры я был участником сообщества Open Data Science aka ODS.ai: сначала скромным читателем, потом активным комментатором, примерно с 2017 - одним из админов. В 2017-2019 мы сделали три датафеста в Минске, собрали большую тусовку местных data-related людей, я лично познакомился с кучей отличных людей: с кем-то мы работали, с кем-то рубились в Kaggle, с кем-то вместе разбирались в сложных статьях или понемногу контрибьютили в опенсорс, с кем-то просто трепались и пили пиво.

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

Сообщество начало сколько-то увядать в ковидные времена: сложно поддерживать большое количество слабых социальных связей fully remote. Но по-настоящему все треснуло с началом войны: где-то проявились латентные "где вы были восемь лет" ватники, где-то, наоборот, люди начали уходить, возмущенные отсутствием яркого антивоенного консенсуса. Появились вопросы к основателю коммьюнити насчет его связей с государством, не получившие толком ответов. Наконец, недавно Slack пообещал окончательно закрыть все организации с российскими корнями. Это все привело к диссоциации: от ODS откололось не меньше пяти разных коммьюнити на разных платформах.

Вместе с группой друзей мы вспомнили принцип "If you can't beat them, lead them" и тоже сделали форк - singularis.ai. Это тоже Slack-чат, среди админов - исключительно достойные люди, которых я давно и хорошо знаю. Мы хотим сохранить тот дух научного и профессионального любопытства, который когда-то царил в ODS, но избавиться от токсичности и вотэбаутизма, и, конечно, никак не будем заигрывать ни с каким государством.

Нас уже больше двух тысяч, join us, we have no cookies.

Предсказание: в ближайшие пару лет Rust наконец-то пойдет в массы.

Rust уже давно был в странной позиции самого любимого языка, на котором пишут в основном пет-проекты и редкие системы с повышенными требованиями к безопасности (читай веб3 и криптографию). Порог входа относительно высокий, разработчиков на рынке мало - нужно быть довольно рисковым, чтобы стартовать новый проект на нем. Но кажется, что для него есть еще две созревшие ниши:
1) очевидная - язык для dev-инструментов,
2) неочевидная - быть вторым языком в проекте.

Эти две ниши хорошо сочетаются.

Rust хорошо интегрируется с двумя самыми популярными языками современности: c Python через maturin, с JS через WebAssembly. Я не знаком с миром JS, видел краем глаза пару примеров дев-тулов на расте. В Python тусовке знаю больше: набирающий популярность линтер, два популярных токенайзера
(второй используют OpenAI!), новая версия валидатора pydantic. Уверен, что в течение пары лет появится популярный Python веб-фреймворк типа FastAPI/Starlite с ядром, написанным на расте.

И тут я наконец вверну кусок про LLM. У нас на работе Rust уже давно использовался именно как второй язык бэкенда, для ускорения узких мест, и за день перед отпуском (не начинать же Большую Задачу) в обучающих целях я решил слегка ускорить кусок препроцессинга. Нашел профайлером пару относительно медленных функций, скормил их в GPT-4, получил аналог на расте, поправил пару мест, повозился с интеграцией, получил комментарий на ревью от человека, который, в отличие от меня, на расте писать умеет, починил, смержил. Короче, оно уже в проде (люблю запах деплоя пятничными вечерами!), экономит 1 ms на запрос (в масштабах тысяч RPS имеет некоторый смысл), а ведь я даже учебник по расту не дочитал.

В мире JS уже есть даже специальные курсы типа Rust for JS devs. Думаю, автор учебника Rust for Python developers будет крайне успешен. Если кто-то из читателей хочет этим заняться, но не знает, как начать, пишите - поделюсь опытом работы с издательством.

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

С другой стороны, в 2023 good prompt is all you need (хотя некоторые ресерчеры не согласны). Значит, можно взять главу, разбить на части, и отправить их на GPT-корректуру. Понадобилось несколько уточнений в промпте, чтобы "корректор" не становился "редактором": был не слишком активным в изменениях, чистил фигню, но более или менее сохранял стиль.

Но ведь хороший редактор это тоже полезно! Только если правки корректора можно принимать практически не глядя, то замечания редактора - это как комментарии на code review, над ними нужно подумать, но далеко не на все нужно реагировать изменениями. Значит, надо усовершенствовать промпт: ...If there is a statement that seems to be wrong, suggest a detailed comment in a square brackets, e.g. [This might be wrong because ...], and keep the sentence as is.

Для теста добавил в часть про training pipeline такое:

...Using training pipeline is dangerous as it could be poisonous. There are 1 million people who died from poisonous training pipelines.

На выходе:

...[The statement "Using training pipeline is dangerous as it could be poisonous. There are 1 million people who died from poisonous training pipelines." seems to be incorrect and irrelevant to the topic. Please consider removing it.]

Теперь хочется прогнать через GPT-редактора и написанные ранее главы; вдруг найдется где-то полная дичь.

Два мелких наблюдения про GPT-driven написание кода:

1) за последний месяц написал больше регулярок, чем за всю предыдущую карьеру - нужно выковыривать результат из GPT и фиксить (например, добавлять пропущенные запятые в невалидный JSON). К счастью, писать их руками тоже необязательно, copilot справляется.
2) надо думать своей головой дважды (трижды для таких невнимательных людей, как я), принимая какие-то дизайн-решения на базе ответов ChatGPT. Недавно лопухнулся: спросил, как сделать некую интеграцию с гуглдоками, посмотрел код и подумал, что после мелких фиксов все заработает. После многих часов в попытках это завести обнаружил, что такого API не существует, есть вроде бы похожее, но совершенно не решающее мою задачу.

Наконец-то выкатили в early access первую версию книги! 📖

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

По промокоду mlkravchenko скидка 45% до 9 мая.

Я уже недавно писал, что в эпоху LLM регулярки снова стали актуальным инструментом так называемого AI. Regex-in-the-loop как промежуточный вариант между "слепо доверимся черному ящику" и относительно дорогим human-in-the-loop.

И вот для тех, кто уже перешел с ChatGPT на что-то опенсорсное из зоопарка парнокопытных, уже появился враппер, который заставляет LLM-ку отвечать в заданном формате. Идея очень простая:

ReLLM filters non-matching tokens pre-generation. For each token, ReLLM tests every possible completion against a partial regex. For the potential completions that do not match the pattern, ReLLM masks the logits so that the language model does not generate them.

У меня нет бенчмарков, потому голословно выскажу предположение, что для ряда нехитрых продакшен задач такой нехитрый костыль сильно сократит отставание опенсорсных LLM от великого и могучего OpenAI.

Получил доступ к превью Copilot for Docs.

В отличие от обычного Github Copilot, это набор chat LLM, зафайнтюненных на определенные сабсеты данных: например, документация Azure, Github, TypeScript, React... Всего доступно 12 топиков, ни один из них лично мне не слишком близок (наверное, из всего доступного у меня за последний год были только вопросы по Github Actions).

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

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

Пока во всех ML-related каналах пишут о том, что OpenAI массово раздает доступ к плагинам для GPT, я спрятался от хайпа, добрался до watch later и посмотрел два старых видео про профайлинг: Performance matters и Python performance matters.

Оба видео - доклады Emery Berger, автора известных инструментов профайлинга, на конференции Strange Loop. Просмотр обоих толсто намекнул, что некоторые мои потуги в вопросах оптимизации были довольно наивны, а кроличья нора профайлинга - куда глубже, чем может показаться ("ну а че там, запускаешь функцию, меряешь время, все просто"). Если тема интересна, но жалко времени, то посмотрите хотя бы первое видео, чтобы узнать о роли memory layout в бенчмарках и о том, почему не все ускорения одинаково полезны.

Emery Berger - вообще очень интересный чувак. Например, еще в 2014 он работал над идеей автоматического поиска ошибок в Excel таблицах (и развил метод в работе 2019 года). В Scalene - Python-профайлере из второго видео - давно прикручен OpenAI для подсказок оптимизация. Еще одна похожая утилита про dev tools meeting generative AI - ChatDBG, дебаггер с интегрированным ChatGPT.

С интересом прочитал короткую статью Bytes Are All You Need: Transformers Operating Directly On File Bytes.

TL;DR: авторы попробовали учить трансформеры на недекодированных файлах (картинки и звуки), модель очень простая: сырые байты => token embedding => conv1d для уменьшения размерности => transformer go brrr. Работает на JPEG, TIFF, PNG, WAV, MP3; ожидаемо, форматы с компрессией работают хуже. Метрики не самые клевые для 2023, но авторы явно и не пытались побить state of the art.

Интересно другое:

1) Всеми любимый Andrej Karpathy давно восхищается тем, насколько трансформер сближает домены: раньше ML-задачи на картинках, текстах и аудиоданных решались совсем по-разному, а сейчас полковник Кольт уравнял их шансы решения разных задач все больше похожи друг на друга. Эта статья - еще один шаг в том же направлении: домен не важен, засунул байтики и норм.

Наверное, похожие чувства были у людей, когда AlexNet вдруг всех победил: "это что, не надо пилить дескрипторы, просто пихаешь RGB-датку в свертки, добился сходимости (без батчнормов и residual connections, хехе) и все??".

2) В статье рассказывается, что такой подход может привнести новые элементы в построение безопасных систем. Например, можно представить камеру, которая в принципе не формирует полное RGB изображение, а только рандомные пиксели, и на этом можно успешно учиться (метрики прилагаются). Или, например, можно консистентно обфусцировать инпуты, и это тоже потенциально полезно для приватности. Учитывая, что авторы статьи из Apple, подозреваю, что они вполне могут использовать идеи byteformer для privacy-preserving задач в реальных устройствах.