Итак, я обещал написать какие-то соображения, как выбирать стартап ранней стадии, к которому можно и нужно присоединяться. Дисклеймер: это личный опыт + наблюдения некоторых корешей, так что объективность не гарантируется. Кроме того, высказываюсь с позиции individual contributor, а не карьериста, который стремится к C-level.

Перефразируя Толстого, “все плохие стартапы плохи по-своему“. Нельзя найти критерии обязательного успеха, проще найти "красные флаги" 🚩- критерии, которые заметно снижают вероятность успеха в будущем.

🤔 фаундеры и команда сами не знают, что делают (или не могут толком объяснить).

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

🚜 инвестиции от непрофильных инвесторов;

Скорее всего, “хорошие” инвесторы денег не дали. Возможно, они что-то знают. Необязательно поднимать деньги от a16z или sequoia capital, но хотя бы от каких-то профессиональных VC. Фартовые пацаны с сетью шиномонтажей, вложившие деньги в стартап, с высокой вероятностью придут и попытаются рулить компанией по знакомым им понятиям. Кроме того, “плохие” инвесторы отпугнут потенциальных “хороших”. Сюда же - страновая принадлежность инвесторов: деньги от какого-нибудь чисто российского фонда сейчас обрекают компанию на жизнь внутри российской экосистемы без шанса влиться в мировую тусовку.

0️⃣ попытка на всем экономить;

Понятно, что денег у стартапа обычно немного, но если фаундер ML-focused стартапа говорит, что на видеокарты и разметку денег нет, крутись как хочешь, разговор можно заканчивать. «Пироги крошатся, если резать их слишком тонко», как говорил персонаж моей любимой книги.

💸 зарплата не по рынку.

С нищенскими зарплатами стартап не наймет достаточно сильных людей. С неадекватно высокими - быстро потратит инвестиции и не доживет до следующего раунда. Например, когда я пошел работать в Wanna, моя зарплата снизилась примерно на 40%.

👶 компания активно нанимает джуниоров на ключевые роли.

Слабая команда не сделает ничего хорошего. Нанимать джуниоров можно только тогда, когда сеньорам есть, что им делегировать (обычно это уже хотя бы series A или B, точно не seed/preseed)

📆 мутный вестинг;

Не могу представить ни одной уважительной причины хитрить с вестингом. Зато это полезно для фаундеров, чтобы потом кинуть гребцов 🚣‍♂️. Четыре года с клиффом - отлично, минимальные отклонения (например, неравномерный или ускоренный вестинг) тоже ок, а “посмотрим по результатам” - нет.

☁️ непрозрачность в целом;

Mushroom management 🍄 - известный антипаттерн, а для стартапов особенно опасный.

🎲 компания не может стать очень успешной даже в идеальном мире.

Простая эвристика: предположим, все планы фаундеров сбываются, все идет хорошо. Сколько в таком случае может стоить компания? Если продукт нацелен на рынок из трех с половиной калек (realtime MLOps для компаний в сфере рекламы азиатской косметики!), стать единорогом ему не светит даже при идеальном стечении обстоятельств, а на практике все будет только хуже.

В следующей серии: какие критерии все-таки могут засчитываться в плюс при выборе стартапа.

Today I learned, что такое residential proxy.

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

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

Так вот, очевидно, что не все прокси равны: сложно прикидываться обычным пользователем, когда IP явно указывает, что это AWS сервер. Логично, что нужны айпишники простых пользователей. Так вот, всякие сервисы, продающие прокси пачками, предлагают как "обычные" прокси, так и residentual - т.е. те, которые используются людьми, а не датацентрами. Разница в цене между ними у разных вендоров составляет примерно один порядок: $1 за гигабайт трафика через residentual прокси против $0.1 за обычный.

Вендоры утверждают, что у них десятки миллионов таких проксей. Возникает вопрос: а откуда они берутся?

Я нашел два сценария:
- можно самому осознанно сдавать свой канал в аренду за малую мзду. Например, Packetstream платит $0.1 (т.е. 10% от цены для покупателя) за гигабайт прокачанного трафика. Можно поставить приложение или запустить докер контейнер и сказочно обогатиться, я для эксперимента даже прокачал через виртуалку целых 7 мегабайт.
- паблишеры приложений могут выжимать со своих юзеров дополнительные пять центов в месяц, неявно внедряя такой SDK с прокси в свой продукт. Так что не удивляйтесь, когда очередная free-to-play игра вдруг сожрет у вас пару гигабайт мобильного трафика.

Ну и наверняка есть еще какое-то количество residential proxy, которые по сути своей ботнеты. Но, конечно, вендоры об этом не пишут - у них всегда ethical proxies, конечно.

P.S. Если кто-то знает секреты, как эффективно парсить Google на масштабе 3-5k RPS, напишите в комментариях или мне в личку (@arsenyinfo).

Делал несложный NLP классификатор-бейзлайн. Взял популярный фреймворк от huggingface 🤗 и начал адаптировать их пример.
На простой строчке accuracy = load_metric("accuracy") решил заглянуть в исходники, чтобы понять сигнатуру, а там внезапно такое.

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

Моя первая работа "весь день писать код за деньги" была в Яндексе. Там я не трогал рантайм, а в основном занимался тем, что сейчас называют дата инженерией, т.е. нагружал кластер имени некоего польского математика. Как следствие, неоптимальный код ничего слишком страшного не делал, просто выполнялся часами или даже днями. Однажды я наспех написал джобу и пошел домой, утром увидел, что и близко не выполнена, и обнаружил там классическую ошибку новичка: проверка условия типа if user in some_users, выполняемая миллионы раз, проходила по some_users, который был многомиллионным списком. Одна строка вида some_users = set(some_users) ускорила тогда джобу в 250 тысяч раз. Это мой личный рекорд ускорения (и личный рекорд неэффективности, конечно, тоже).

Потом работал в компаниях, где оптимизировать надо было только рантайм/инференс, и редко делал это сам - вокруг было слишком много ICPC-олимпиадников, и я со свиным рылом в калашный ряд без особой нужды не совался. А если и совался, то обычно оптимизация лежала в DL плоскости и была довольно прямолинейной: попробовать порубить или факторизовать свертки тут и там, посмотреть на метрики, где это приносит меньше вреда, готово, вы великолепны. Было и такое: все датасеты были настолько маленькими, что можно было все алгоритмы делать брутфорсом, и никто бы не заметил; даже счета от AWS редко стимулировали что-то оптимизировать.

А сейчас я с интересом столкнулся с данными того интересного масштаба, что переходить на распределенные вычисления пока рано, а на одной машине, даже жирной, все работает слишком медленно. Например, в прошлом посте я писал, что пилю NLP классификатор. Все шустро работало, пока я не перешел с игрушечного датасета (десятки тысяч строк) к настоящему (десятки миллионов). Т.е. какая-нибудь функция даже с линейной сложностью и скоростью выполнения 1ms внезапно превратилась в недопустимо тормознутую, а подход "просто закинуть все в память" перестал масштабироваться.

Пока что я успел возненавидеть pandas (в одном пайплайне сделал +30% к скорости, заменив все на простые дикты), полюбить polars, написать суперспецифическую обертку к LMDB в стиле RocksDict и просто начать иногда думать в процессе написания кода, а не просто кататься ебалом по клавиатуре принимать подсказки Copilot. Единственное, что меня беспокоило — это Rust. В мире нет никого более безответственного и безнравственного, чем 🦀 программисты, которые стремятся сделать все вокруг blazing fast 🚀. И я знал, что довольно скоро в это окунусь.

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

Очевидно, что в птицеводстве важно уметь отличать петуха от курицы: петухи не только не несут яйца, но и набирают массу медленнее куриц, т.е. невыгодны для разведения на мясо. Так вот, я случайно узнал, что ключевая технология распознавания пола цыплят (называется vent chick sexing) была опубликована только в 1933 году и вовсю используется до сих пор. Технология довольно неприятная, впрочем, по сравнению с тем, что ждет юных петухов - совершенно ничего страшного.

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

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

Один из проектов, получивший под эту проблему грант от Евросоюза, утверждает, что этот рынок creates a €300 billion opportunity - любой мамкин стартапер согласится, что это неплохой total addressable market.

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

Кажется, big data хайп окончательно сдулся, даже в не самой технически продвинутой Варшаве.

А вот другая история об умеренно больших данных. Есть у меня некий пайплайн, который делал неоптимальные запросы в некое облачное хранилище. Я знал об их неоптимальности, но осознанно забил - эта неоптимальность обходилась примерно в $7 в день, и я откладывал разбирательство, как это исправить. И вот внезапно на вход начало приходить в 20 раз больше данных, и неоптимальность стала обходиться в $140 в день. Ущерб от моей лени оказался заметным, а фикс занял меньше двух часов, включая деплоймент.

На каком-то этапе то, чем я зачастую занимаюсь, окружающие начали называть MLOps. Мне никогда не нравился этот термин, от него попахивало какой-то погоней за хайпом: в моем понимании возня с ML инфраструктурой - часть обязанностей обычного ML инженера, зачем придумывать еще какой-то термин и популяризировать его? Впрочем, игнорировать термин полностью я уже не могу: например, издатель нашей будущей книги очень въедливо спрашивал, чем ML system design, про который мы пишем, отличается от MLOps.

И вот недавно наткнулся на статью, в которой немецкие исследователи из Karlsruhe Institute of Technology и IBM попытались формализовать, что это вообще за зверь. В статье производит впечатление навороченными схемами, которые должны описывать, где чья зона ответственности и как они друг с другом пересекаются. Например, для "типичного" ML проекта предлагается аж шесть технических ролей.

Если почитать методологию, становится понятно, откуда растут ноги: авторы провели интервью с 8 представителями индустрии из разных компаний. Компании не называются, но несложно догадаться, что, например, music streaming service с 6500 сотрудников - это Spotify. Кстати, именно Spotify - самая маленькая из представленных компаний, в остальных десятки и сотни тысяч сотрудников. Еще в одной компании я подозреваю Oracle, в другой - индийского аутсорс гиганта TCS.

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

Горячо любимый мной Copilot иногда откалывает смешные штуки. Например, только что я делал микрофичу для slack-бота - выбирать рандомного инженера из команды. И стоит только добавить в список инженеров поляка по имени Мартин, Copilot настаивает, что пора нанять некоего Кшиштофа.

Недавно разговаривал с менеджером за жизнь на 1:1, речь зашла про образование, и он спросил "BTW, what's your degree? 🧑‍🎓". Как человек, 15 лет назад бросивший нетехнический факультет, я не мог удержаться от встречного вопроса - а ну-ка попробуй угадай. Его decision tree оказалось интересным:
- "не вставляешь свои пять копеек, когда кто-то вокруг начинает выебываться на тему математики и не стремишься решать задачи при помощи вычурных loss-функций - значит, не физика и не математика";
- "пишешь читаемый структурированный код и при этом интересуешься чем-то за пределами своей IDE - значит, не computer science";
- "напрашиваются нетехнические дисциплины, применяющие технические методы. Экономика?"

Ну да, я бы сильно удивился, если бы он прямо угадал мою церковно-приходскую школу родную кафедру технологий коммуникации журфака БГУ.

Кстати, в предыдущий раз про образование меня спрашивали два с половиной года назад - в тот раз это были визовые юристы.

Предположим такую ML ситуацию: например, мы учим классификацию, и на каком-то этапе train accuracy резко выросла (например, 80% => 90%), а на валидации - слегка просела (например, 75% => 74.5%). Как это прокомментировать?

👨‍🎓Ответ уровня junior: классический оверфит по учебнику, обязательно нужно делать early stopping или вводить другие способы регуляризации!
🤔 Ответ уровня middle: дорогой джун, а вот и необязательно оверфит, вдруг наша задача предполает, что качество трейна важно. Например, если у нас API, которое по адресу сайта предсказывает его тематику, и трейн содержит top-100000 сайтов по запрашиваемости, качество трейна важнее качества на валидации!
👴 Ответ уровня senior: дорогой middle, если у нас большая часть запросов касается трейнсета, давайте не будем там делать никакой ML, а просто запомним популярные значения и будем отдавать их из кэша. И тогда качество модели на трейне снова не важно!
🚁 Ответ уровня staff и выше: молчание - он верит, что коллеги разберутся с этой задачей, а у него есть дела поважнее.

Судя по тому, что я вчера прикрутил подобный lookup table (-17% к среднему времени инференса и +ε к точности), не быть мне пока стаффом!

Я в последнее время часто играю в GeoGuessr - это игра, в которой по картинкам из Google Street View за ограниченное время нужно угадывать локацию. Естественно, к этой игре уже сделали 100500 deep learning читов, которые угадывают сильно лучше среднего игрока. Но я хотел поделиться другим наблюдением: успех в GeoGuessr похож на успех в классических ML проектах. Т.е. для победы нужно придумать фичи и собрать датасет.

Примеры фичей: с какой стороны дороги едут машины, на каком языке написаны вывески и знаки (наконец-то мне пригодилось умение отличать польский от чешского, а вот сербский с болгарским пока иногда путаю), что растет на полях (конечно, с ребятами из OneSoil в этом соревноваться нельзя), видны ли в окрестностях море или горы, насколько разбита дорога, насколько просматривается солнце через облака, какое распределение машин/мопедов...

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

Читаю "Бобо в раю. Откуда берется новая элита" - про социальный класс bourgeois-bohemian, "буржуазной богемы" (в наших широтах похожих людей обычно называют не совсем точно хипстерами), и хочу выдернуть оттуда цитату:

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

Думаю, эта цитата хорошо описывает, почему X денег, заработанных в Сбере или, например, на перепродаже спизженного кирпича - не так круто, как такие же X денег от продажи стартапа, призовых на Kaggle или гонораров за лекции.

В любом ML проекте, в котором я оказываюсь, довольно быстро заводятся минимум две функции: get_relative_path и ensure_local.

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

fixture = get_relative_path("../fixtures/file.csv", __name__)

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

with ensure_local("s3://secret-bucket/kurwa_dzik.jpg") as fd:
    img = cv2.imread(fd)

С течением времени из ensure_local обычно вырастает отдельный модуль io; все это пишется абсолютно бессознательно. А поскольку осознанность - это важно, расскажите в комментариях, какой либой можно удержать меня copilot от написания этого в очередной раз и какие utils пишете вы, врываясь в новый проект?

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

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

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

В написании "обычных" текстов сейчас помогают Wordtune и Grammarly, и, конечно, до уровня Copilot им еще очень далеко - не в последнюю очередь из-за UX, это скорее постпроцессинг текста, а не подсказки в формате автодополнения. В Google Docs тоже есть автодополнение, но пока слабоватое, обычно подсказывает буквально пару слов для завершения идиомы.

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

Короче, I'm bullish on large language models для широкого применения.

Недавно нужно было наколхозить простую тулзу для поиска семплов в большом датасете. Условно есть 200М семплов, доступных через AWS Athena, и к ним делаются запросы в духе select * from big_table where blah like '%blah%' and foo like '%bar%' limit 10;.

Делать все через Athena очень просто, но медленно (запросы редко занимают меньше 10 секунд) и небесплатно (получалось что-то вроде $0.05 за запрос, некритично, но не приятно). Напрашивается решение с частичным кэшированием: возьмем сабсет на 5% данных, положим его локально и будем обращаться к нему, а если не нашли достаточно семплов в локальном сабсете, тогда уже пойдем в Athena с медленным запросом. На практике оказалось, что 95%+ запросов можно удовлетворить сабсетом, все довольно быстро (до полутора секунды на запрос) и бесплатно.

Так как я ленивый, сперва уложил локальный сабсет в SQLite, чтобы не возиться с поднятием более серьезной базы. В принципе, этого было достаточно, но в познавательных целях решил потрогать DuckDB - это embedded OLAP (т.е. колоночная) SQL база данных. DuckDB ставится через pip install (впрочем, есть поддержка и для других языков), плотно интегрирована с pandas и parquet. Замена SQLite на DuckDB потребовала всего нескольких строк и ускорила поиск почти в два с половиной раза до малозаметных 600 мс.

Жду комментариев, что Настоящий Мужик бы поднял кластер Clickhouse, а не это все.

Потестил howto - мелкую (120 строк на go) CLI утилиту, написанную @dlinnlp. howto подсказывает консольные же команды по запросу на естественном языке.

Под капотом OpenAI Codex, потому для работы нужен API ключ OpenAI. Впрочем, сложно представить, что кто-то надергает подсказок больше, чем на пару десятков центов.
Вот примеры работы:

➜  ~ howto push my git branch ignoring conflicts
git push -f origin my_branch

➜  ~ howto cache model from huggingface
python3 -m transformers.convert_graph_to_onnx --model_type bert --model_name bert-base-uncased --framework pytorch --output_dir /tmp/onnx/ --input_shape [1,512] --opset 11 --do_lower_case --save_mode model

➜  ~ howto add dependency with poetry
poetry add <package>

➜  ~ howto remove unused docker artifacts
docker system prune -a --volumes

➜  ~ howto pull logs from cloudwatch and filter by word
aws logs filter-log-events --log-group-name /aws/lambda/my-lambda-function --filter-pattern "ERROR" --start-time 1555555555555 --end-time 1555555555555 --output text --limit 100 --query events[*].message | tr -d '"' | grep -i "my-word"

➜  ~ howto install micro
curl https://getmic.ro | bash

➜  ~ howto install python 3.12 ubuntu 16.04
sudo apt-get install python3.12

➜  ~ howto install python 3.14 ubuntu 16.04
sudo apt-get install python3.4

➜  ~ howto compile python code with rust to make it fast
rustc -C opt-level=3 -C lto -C target-cpu=native -C target-feature=+avx2 -C target-feature=+fma -C target-feature=+sse4.2 -C target-feature=+ssse3 -C target-feature=+avx -C target-feature=+aes -C target-feature=+rdrnd -C target-feature=+rdseed -C target-feature=+pclmul -C target-feature=+lzcnt -C target-feature=+popcnt -C target-feature=+bmi2 -C target-feature=+avx512f -C target-feature=+avx512cd -C target-feature=+avx512er -C target-feature=+avx512pf -C target-feature=+avx512bw -C target-feature=+avx512dq -C target-feature=+avx512vl -C target-feature=+avx512ifma -C target-feature=+avx512vbmi -C target-feature=+avx512vb

Как видно, пока не все идеально, но в целом может быть полезно. К сожалению, пока частенько падает с signal SIGSEGV, но верю в скорый фикс.

UPD: кажется, уже починили, спасибо уважаемому подписчику.

Хороший пример intelligence amplification - еще один сыроватый, но полезный инструмент на базе large language models: explainpaper.com.

Суть такая: загружаешь статью (например, свежую state of the art), в процессе чтения выделяешь непонятные куски и получаешь объяснение, что это вообще такое. Если объяснения оказывается недостаточно, можно задавать наводящие вопросы.

Работает прям неплохо: может использоваться и просто как напоминалка базовых понятий ("черт, я забыл, что такое self-attention") и для объяснения концепций из статьи, т.е. в контексте.

С контекстными объяснениями пока не все идеально, с наводящими вопросами тоже. Например, частый failure mode - просто пересказать сказанное выше, не добавляя новой информации. Но в целом выглядит как хороший помощник для тех, кому иногда нужно читать статьи и не хочется закапываться в глубину, чтобы разобраться на достаточном уровне.

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

Потом был семестр экономики на первом курсе. О качестве преподавания там говорит тот факт, что школьных знаний хватило на сдачу экзамена на нетипичные для меня 9 баллов. На этом академический аспект закончился, а я просто периодически почитывал разные популярные книжки про экономику - от сверхпопсовой "Фрикономики" до относительно немодной "The Worldly Philosophers".

Это я все к чему? Хочу порекомендовать Economics: The User's Guide (на русском "Как устроена экономика") хотя бы за ее четвертую главу, в которой систематизированы десять экономических школ. Да и в остальных главах автор стремится показать многообразие, не пытаясь показать то или иное течение как единственно верное.

Как писали в одном из отзывов, [it guides] how to think (as opposed to what to think). Например, поможет разобраться, почему Хайек - напомню, прославившийся трудом с пафосным названием “Дорога к рабству” - в свое время одобрял диктатуру Пиночета в Чили. И, конечно, более явно замечать bias в той или иной околоэкономической точке зрения.

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

На Nim можно легко компилировать нативные модули для дальнейшего вызова из Python. Собственно, такое упражнение я для себя и выбрал: взял пять функций для работы со строками, которые относительно недавно использовал, и реализовал их в виде nim-библиотеки, которую можно импортировать в python-код. Выбрал строки, потому что в числодробилках тягаться с numpy-экосистемой было бы сложно.

Гипотеза такая: учитывая простоту языка сабсета языка, на него можно будет переписывать узкие места кода на питоне (например, какой-нибудь препроцессинг), не прибегая к тяжелым наркотикам вроде Rust 🦀

TL;DR:
- писать примитивные штуки действительно несложно, билдить под питон - тоже;
- слишком примитивные функции ускорить не получится;
- чуть более сложные куски приятно ускоряются;
- тягаться с оптимизированным C кодом, обернутым в питон, тоже нельзя.

В общем, в прод не потяну, а для какого-нибудь оффлайн процессинга вполне можно пробовать.
Чуть больше деталей и исходники на Github 👨‍💻

Про Galactica - "AI trained on humanity's scientific knowledge" - написали уже многие. Вкратце: это decoder-only (т.е. похожая на семейство GPT) языковая модель, обученная на корпусе научных текстов, как следствие, способная решать всякие околонаучные задачи - например, пересказывать научные статьи или упрощать математические выкладки. Больше примеров можно посмотреть на сайте.

Но больше, чем результат, меня впечатлила статья, а точнее, одна из идей - см. 3.1.1 Working Memory Token.

Our solution is a working memory token we call <work>. ... Where a computation is performed that a human could not do internally,
we offload by writing and executing a Python script.

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

Importantly, we do not have to turn this on, and the model can also predict the output from running a program. For our experiments, we did not find the need to turn Python offloading on, and leave this aspect to future work.

Эффективное объединение ML и какие-то внешних систеи (например, баз данных) - нерешенная в общем виде проблема, и такие идеи мне кажутся полезными и важными в долгосрочной перспективе.