Большую часть своей 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 задач в реальных устройствах.

Моя любимая художественная книга - "Криптономикон" Нила Стивенсона, ставший уже классическим исторический боевик про вторую мировую, криптографию и бум доткомов одновременно. Кстати, именно Стивенсон придумал metaverse в своем раннем посткиберпанк-романе "Лавина", таким образом внеся значительный вклад в нынешнее безумие Цукерберга.

Стивенсон популярен среди нердов за проработанность деталей, в т.ч. исторических: например, вымышленные персонажи участвуют в "Барочном цикле" наравне с Ньютоном, Лейбницем и Вильгельмом Оранским, а в "Криптономиконе" - с Аланом Тьюрингом и генералом Макартуром. Таким образом фикшен переплетается с нон-фикшеном: "Барочный цикл" до сих пор остается моим основным источником знаний о 17-18 веках в Европе.

И вот недавно я нашел книгу, которая во многом похожа на "Криптономикон" по духу, будучи при этом полностью нон-фикшеном. Это "Отряд отморозков" (в оригинале The Bastard Brigade) - популярно рассказанная история о том, какие открытия привели к возможности создания атомной бомбы и как правительственные агентства пытались помешать немецкому Урановому Клубу ее все-таки создать.

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

Пилю один прототип, нужно гонять инференс относительно тяжелых моделей, но мало и нечасто. Так я добрался потрогать кое-что из современного GPU serverless - Replicate и Runpod.

Replicate - относительно модный стартап, из W20 батча YCombinator, они фокусируются на чистом serverless. Довольно богатый набор популярных опенсорс моделей, собственно, ради одной из них я и пришел - разворачивать инференс своими руками было немного лень. Для выкатывания своих моделей предлагают использовать Cog, я с этим фреймворком не сталкивался, но выглядит перспективно. В целом продукт выглядит причесанным, но недешевым: там есть всего два вида GPU, T4 GPU за $0.00055 per second и A100 (40GB) за $0.0023 per second.

Потому я глянул и на Runpod. Они более известны не serverless платформой, а обычными GPU нодами, которые у них тоже есть, причем куда дешевле больших популярных облаков типа AWS. Но serverless тоже есть, и тоже довольно простой в освоении: нужно написать хендлер для их библиотеки, похожий на обычную лямбду, запаковать в докер и готово. Доступно несколько разных GPU, и даже самая мощная A100 (80Gb) всего $0.001 per second. Но надо понимать, что прайсинг хитрый: дополнительно оплачивается диск, дополнительно оплачивается idle (если не хотите, чтобы воркер сразу вырубался после одного запроса). Хвастаются, что колдстарт оптимизирован, сам я всерьез не бенчмаркал. Еще понравилась возможность настраивать параметры скейлинга вручную, в обычных лямбдах иногда не хватало такой гибкости.

В комментарии отдельно приглашаются эксперты, которые очень хотят рассказать, что serverless - говно, а деды завещали использовать bare metal.

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

Типичная работа с промптами - это не инжиниринг, а скорее алхимия. Алхимия - это уже не шаманские ритуалы (не способные повторяемо вызвать дождь вопреки мнению камлающего), а протонаука, которая, хоть и содержала в себе много странного по современным меркам, иногда приводила к неплохим результатам (см. например историю открытия фарфора в Европе). Да, есть набор полезных эвристик типа chain of thought, который помогает выжать больше пользы из вашей любимой LLM, и вообще сколько-то воспроизводимы между разными задачами/моделями. Но воспроизводимость оставляет желать лучшего, и если что-то не работает, то для подавляющего большинства адептов промпт-инжиниринга остается только перебор этих самых эвристик из твиттера и awesome-prompt-engineering списков.

Или вот еще видел формулировку "Need to setup ChatGPT prompts that guarantee...". Ага, конечно, промпты к внешнему черному ящику с гарантией, и немного философского камня заодно.

Важное примечание, чтобы не считаться совсем луддитом: штуки типа P-tuning - это уже не алхимия, и в работе со своими - не 3rd party API - LLM можно добывать какие-то гарантии (см, например, guidance).

Кто-то возразит, что вообще-то весь ML такой, но я так не думаю. Да, есть какие-то вещи, в которых результат малопредсказуем без экспериментов, но для значительного количества ML проблем у профессионалов есть интуиция, как к этому осмысленно подойти, как найти боттлнек и точку для улучшения. А вот текущие практики промпт-инжиниринга скорее похожи на "в любой сложной ситуации давайте перебирать гиперпараметры", что попахивает магическим мышлением.

Наверное, я уже похож на тех дедов, которые восемь лет назад бубнили "да что этот ваш ML, сейчас я напишу ифов с регулярками, и норм" и "к черту ваш диплернинг, сейчас SVM поверх HOG обучим и хватит".

Минутка рекламы: у издательства, в котором выпускается наша Machine Learning System Design книга (кстати, в early access уже семь глав), сейчас идет большая распродажа - 50% скидки на электронные и 40% на печатные версии всех книг.

Так что даже если ML дизайн вас не интересует (например, вы услышали от модного спикера, что он сломан, и совершенно разочаровались), можете поискать в каталоге что-то менее сломанное.

Есть классическая картинка для иллюстрации жизненного цикла технологических инноваций - Gartner Hype Cycle. Он, конечно, скорее про adoption компаниями, но почему бы не натянуть эту фигуру и на отдельного индивида? Кажется, что прошло уже достаточно времени, чтобы ChatGPT прошел через этот hype cycle персонально для меня и достиг плато продуктивности: равномерное использование, выжившие юзкейсы, отсутствие восторгов и разочарований.

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

1) Бюрократ-копирайтер

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

2) Поверхностный эрудит

"Опиши состояние дел в какой-то области / объясни с учетом моего уровня (не)знания в соседних областях". Примеры вопросов: какой софт используют 3д художники для работы с текстурами? чем replacement map отличается от height map? какие острова на Азорах выбрать для недельного отпуска, если меня интересуют хайки и природные достопримечательности? какие прикладные применения сверхпроводимости? Дьявол обычно в деталях, и слишком глубоко закапываться с LLM не стоит, но можно быстро получить поверхностное понимание.

3) Junior software engineer

"Напиши прототип такой штуки, используя этот незнакомый мне, но популярный в целом API". Из последнего: делал так ORM на SQLAlchemy и blender-скрипты для headless рендеринга. В обоих случаях хочется, чтобы оно хоть как-то работало, а разбираться в апи не хочется - не предполагаю, что этот код нужно будет долго поддерживать или развивать.

4) Въедливый критик

"Найди недостатки и корнеркейсы в следующей идее/коде/тексте: {{INSERT YOUR STUFF}}". Люди неплохо справляются с поиском подтверждений своей идеи или дизайна (confirmation bias и его друзья), а по-хорошему надо искать опровержения и логические нестыковки. Кстати, отлично сочетается с предыдущим режимом использования: напиши-покритикуй-исправь-вываливай в продакшен.

Это именно персональные примеры использования, а не приложения вокруг API. Хотя я как раз использую не веб-интерфейс, а консольный heygpt: он быстрее, удобнее и даже дешевле, чем обычная подписка на GPT-4.

Расскажите в комментариях про сложившиеся у вас паттерны!

Очередная (см. ранее) история ускорения, в которой не понадобились никакие знания алгоритмов.

Пилю на досуге одну задачку, которая в некотором смысле сводится к семантической сегментации. Правда, у этой сегментации есть несколько нюансов: несколько подзадач, у каждого семпла может быть подмножество масок, разного размера, но все довольно жирные (по ~30 мегабайт в PNG). Таким образом, первая версия пайплайна, которую я написал в лоб, не могла загрузить даже слабенькую GPU, подготовка батчей занимала слишком много времени, около секунды на семпл. Учитывая, что это все крутится на арендном железе, оставалась опция купить тачку с кучей CPU ядер, но я слишком жадный.

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

Не будь у меня ограничений по диску, единожды перепаковать все каким-нибудь np.savez было бы эффективно: размен разового препроцессинага на быстрый IO. Но это бы раздуло датасет в несколько раз, тоже не очень. Есть np.savez_compressed, который еще и зипует, но он убивает все преимущества в скорости. Так я пришел к тому, что мне нужен аналог np.savez_compressed на стероидах.

Помимо древнего zip, есть и более современные алгоритмы быстрой компрессии, например, LZ4 или Zstandard. Я выбрал zstd (поверхностный гуглинг подсказал, что он более гибкий на спектре от быстрого до компактного сжатия) и написал сгенерил примерно пятнадцать строк простой обертки и еще чуть больше для скрипта препроцессинга.

Степень сжатия пока даже не тюнил, а выбрал наугад. В результате загрузка данных ускорилась примерно в четыре раза, а размер датасета вырос на 10% по сравнению с PNG.

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

Во-первых, получил письмо с многообещающим топиком "MANNING PUBLICATIONS CO. LLC has sent you money" 💰. $443.37 USD до налогов. Если хотите стать писателем ради наживы, подумайте дважды трижды.

Во-вторых, в early access вышла 9 глава про error analysis, на мой вкус, одна из самых ценных. Если бы меня спросили, какие три главы нужно осилить, чтобы условно из миддла стать могучим сеньором, я бы посоветовал 2, 9, 16 - Is there a problem?, Error analysis, Ownership and maintenance. Две из трех уже доступны, так что несите ваши денежки издательству! В эту главу в т.ч. много контрибьютил Богдан, за что ему спасибо.

В-третьих, пришли результаты внешнего ревью - издательство семплит сколько-то внешних экспертов из числа потенциальных читателей, дает им бесплатную копию и заставляет заполнить длинную анкету. Наблюдается явный прогресс: первое ревью - average star rating is 3.75, второе ревью - average star rating is 4.36. Причем некоторые ревьюверы участвовали дважды (почти год назад и сейчас), и явно отмечают улучшение в т.ч. по ранним главам ("It has improved and I congratulate the authors for it"). За это, кстати, отдельное спасибо читателям, которые присылают комментарии и дополнения.

Среди отзывов ревьюверов, конечно, попадается и странное - вот мой любимый: "When I read the title, I thought the book should explain how install a tool such as MLFlow or Kubeflow" 🤯

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

Понравился LiteLLM - LLM Ops здорового человека. TL;DR: тонкий враппер с общим поверх популярных провайдеров LLM, с кэшированием, обработкой ошибок и бюджетированием.

Вообще я не спец в LLM, но сделал сколько-то прототипов на коленке, и считаю, что правильный воркфлоу - делать proof of concept поверх самого дорогого и предсказуемого на текущий момент API (читай GPT-4), и держать в уме опцию миграции в будущем. Уже в паблике есть и жирная Falcon-180B 🐪, и крутой для своего размера Mistral 7B 🇫🇷, и разные затюненные Llama-2. Лень сетапить инференс - пожалуйста, есть Replicate или Deepinfra.com под ваш форк Лламы, и Antropic через AWS Bedrock; все они обойдутся дешевле, чем GPT.

Если совсем полетит, то на собранном датасете можно будет тюнить свою кастомную модель, если лицензия позволит 🏴‍☠️. Но скорее всего, YAGNI.

AI, который мы заслужили

Совсем недавно казалось, что эпоха локальных вычислений окончательно ушла, уступив облакам. В начале года я достал из компьютера старые видюхи, завернул в пузырчатую пленку и за малые гроши отправил в Лодзинское воеводство. Сентиментально вспоминал, как покупал первую в 2016, чтобы осваивать deep learning, потом майнил казавшуюся важной ачивку kaggle master, а в промежутках - Ethereum. Радиатор одной из карт был надпилен: слегка не влазила в канплюктер, пришлось избавиться от нескольких мм металла. Потом карточки пару лет пылились в Минске и ждали, пока подвернется оказия их передать. Впрочем, к этому времени они уже потеряли всякую актуальность: даже в бесплатном Google Colab GPU мощнее, а на паре старых консьмерских видюх ничего обучить нельзя - так, для дебага в лучшем случае.

А потом внезапно случился ренессанс: в паблик ушли веса Llama (а дальше и Llama 2) и сотни их файнтюнов, появился llama.cpp, агрессивная квантизация до пяти бит, на реддите /r/LocalLLaMA бешеные тыщи энтузиастов жонглируют свежими релизами и обсуждают, какую железку купить для домашнего инференса очередной опенсорсной LLM и почему это Mac Studio.

Я тоже под шумок решил обновить компьютер для зимнего обогрева. Воткнул в освободившийся слот видеокарту посвежее, SSD побыстрее и новый wifi-адаптер вместо потерянного при переездах. И словно провалился в прошлое: как в давние времена нужно читать мануалы, разбираться, какие комбинации слотов предпочтительнее ("When an M.2 device in PCIe mode is installed, PCIe x16_2 slot only runs at x1 mode"), подбирать wifi драйвера для богом забытого чипа и недоумевать, почему видеокарта при нагрузке делает hard reset.

Впрочем, в GPT-guided эпоху это все оказалось куда проще. Раньше возня с драйверами могла занять все выходные, а иногда даже ни к чему не привести; сейчас в интерактивном режиме ("у меня не работает X, вот аутпут dmesg, help me diagnose it step by step") с этим может справиться любой нормис вроде меня. Слава роботам! 🤖

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

Дочитываю "Создание атомной бомбы" Роудса и не устаю рекомендовать вообще всем знакомым. Она комплиментарна "Отряду отморозков", который я рекомендовал ранее, и фильму про Оппенгеймера, только на порядок шире и глубже. Начинается с историй о том, как в конце 19 века Резерфорд копал картошку в Новой Зеландии, а Бор играл в футбол и читал Кьеркегора, и дальше слой за слоем раскрывает, что привело к созданию бомбы. Роудс не физик, а историк, но достаточно глубоко погружается в физику, и даже нормис типа меня может в общих чертах понять, на каких умозаключениях основывались ключевые открытия, как дизайнили первые реакторы и чем U-235 отличается от U-238.

Книга огромная и плотная, почти тыща страниц, почти три тыщи сносок, Пулитцеровская премия 1988 года, вездесущие параллели про войны, вынужденные миграции и непубликацию свежего ресерча из-за беспокойства про superalignment.