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

Мой отец эмигрировал из Колумбии в Северную Америку, когда ему было 18. Сделал он это в поисках лучшей жизни. Для меня и моего брата это значило — проводить много времени на уличном холоде. Отец выбрал путь улучшения своей судьбы через улучшение того, что его окружает. Меня и брата «добровольно» завербовали в помощники по работам над принадлежащими нам постройками.

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

В подвижном мире развивающихся нейросетевых архитектур главную роль играет эффективность работы моделей. Тонкая настройка сетей под конкретные задачи предусматривает интеграцию в них априорных знаний. Делается это посредством стратегических корректировок архитектур сетей. Это — процедура, выходящая за рамки подстройки параметров. Речь идёт о внедрении в нейросеть информации, которая позволит сети понять то, что нужно её создателю. Один из способов это сделать заключается в использовании априорных знаний геометрического характера. Именно этому и посвящена данная статья.

Приходилось вам копипастить фрагменты вспомогательного кода между проектами, попадая в ситуацию, когда несколько версий одного и того же набора команд оказывались в разных репозиториях? Или, может, вам надо было делать pull‑запросы к десяткам проектов после того, как было изменено имя GCP‑корзины, где вы храните данные?

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

Предлагаю погрузиться в тему монорепозиториев. Это — архитектура, широко применяемая в ведущих технологических компаниях наподобие Google. Поговорим о том, как монорепозитории способны улучшить ваши рабочие процессы, связанные с машинным обучением. Монорепозитории дают тем, кто их выбирает, много полезного. Это, несмотря на то, что есть у них и недостатки, делает их привлекательным выбором для управления сложными ML‑экосистемами.

Сначала мы кратко обсудим сильные и слабые стороны монорепозиториев, поговорим о том, почему они — это отличное архитектурное решение для ML‑команд, коснёмся того, как их используют в крупных технологических компаниях. В итоге у нас появится представление о том, как воспользоваться возможностями системы сборки кода Pants для организации ML‑репозиториев при построении надёжной CI/CD‑системы для сборки проектов.

А теперь — в путь — к оптимизации управления проектами в сфере машинного обучения.

Консоль бодро оповестила меня о завершении работы скрипта. Его задача заключалась в поиске учётных данных для доступа к Firebase, которые лежали в открытом доступе и принадлежали одному из сотен недавно появившихся ИИ‑стартапов.

Скрипт шёл по общедоступному списку сайтов с использованием домена верхнего уровня .ai. Программа парсила данные сайтов (и любые.js‑бандлы, на которые находила ссылки) в поиске переменных, которые обычно используются для настройки подключения к Firebase.

Когда я пытаюсь обойтись без *args и **kwargs в сигнатурах функций, это не всегда можно сделать, не вредя удобству использования API. Особенно — когда надо писать функции, которые обращаются к вспомогательным функциям с одинаковыми сигнатурами.

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

def foo(*args: int, **kwargs: bool) -> None:
    ...

Применение такой конструкции указывает на то, что args — это кортеж, все элементы которого являются целыми числами, а kwargs — это словарь, ключи которого являются строками, а значения имеют логический тип.

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

Этот материал посвящён тому, как добавлять собственные данные в предварительно обученные LLM (Large Language Model, большая языковая модель) с применением подхода, основанного на промптах, который называется RAG (Retrieval‑Augmented Generation, генерация ответа с использованием результатов поиска).

Большие языковые модели знают о мире многое, но не всё. Так как обучение таких моделей занимает много времени, данные, использованные в последнем сеансе их обучения, могут оказаться достаточно старыми. И хотя LLM знакомы с общеизвестными фактами, сведения о которых имеются в интернете, они ничего не знают о ваших собственных данных. А это — часто именно те данные, которые нужны в вашем приложении, основанном на технологиях искусственного интеллекта. Поэтому неудивительно то, что уже довольно давно и учёные, и разработчики ИИ‑систем уделяют серьёзное внимание вопросу расширения LLM новыми данными.

До наступления эры LLM модели часто дополняли новыми данными, просто проводя их дообучение. Но теперь, когда используемые модели стали гораздо масштабнее, когда обучать их стали на гораздо больших объёмах данных, дообучение моделей подходит лишь для совсем немногих сценариев их использования. Дообучение особенно хорошо подходит для тех случаев, когда нужно сделать так, чтобы модель взаимодействовала бы с пользователем, используя стиль и тональность высказываний, отличающиеся от изначальных. Один из отличных примеров успешного применения дообучения — это когда компания OpenAI доработала свои старые модели GPT-3.5, превратив их в модели GPT-3.5-turbo (ChatGPT). Первая группа моделей была нацелена на завершение предложений, а вторая — на общение с пользователем в чате. Если модели, завершающей предложения, передавали промпт наподобие «Можешь рассказать мне о палатках для холодной погоды», она могла выдать ответ, расширяющий этот промпт: «и о любом другом походном снаряжении для холодной погоды?». А модель, ориентированная на общение в чате, отреагировала бы на подобный промпт чем‑то вроде такого ответа: «Конечно! Они придуманы так, чтобы выдерживать низкие температуры, сильный ветер и снег благодаря…». В данном случае цель компании OpenAI была не в том, чтобы расширить информацию, доступную модели, а в том, чтобы изменить способ её общения с пользователями. В таких случаях дообучение способно буквально творить чудеса!

Уже лет 50, со времён выхода первого издания «Языка программирования Си» Кернигана и Ритчи, известно, что «числа с плавающей запятой» одинарной точности имеют размер 32 бита, а числа двойной точности — 64 бита. Существуют ещё и 80-битные числа расширенной точности типа «long double». Эти типы данных покрывали почти все нужды обработки вещественных чисел. Но в последние несколько лет, с наступлением эпохи больших нейросетевых моделей, у разработчиков появилась потребность в типах данных, которые не «больше», а «меньше» существующих, потребность в том, чтобы как можно сильнее «сжать» типы данных, представляющие числа с плавающей запятой.

Я, честно говоря, был удивлён, когда узнал о существовании 4-битного формата для представления чисел с плавающей запятой. Да как такое вообще возможно? Лучший способ узнать об этом — самостоятельно поработать с такими числами. Сейчас мы исследуем самые популярные форматы чисел с плавающей запятой, создадим с использованием некоторых из них простую нейронную сеть и понаблюдаем за тем, как она работает.

Я решил назвать эту статью так же как называется книга Макса Тегмарка, потому что речь в статье пойдёт о том же, о чем и в книге. Но дело в том, что я не читал эту книгу. Я, думаю, как и многие тут, смотрел научно-популярные видео, интересовался устройством вселенной, копил знания, замечал закономерности и в какой-то момент у меня сложилась картина. Я держал эту картину при себе т.к. уж очень простой и понятной она была, я был уверен, что я не первый и не десятый человек, увидевший эту картину.

Нарушение лицензии и отказ технической поддержки предоставить исходники — одни из множества неприятностей. Особенно если речь идёт о довольно крупных компаниях, в моём случае — Digma. В этой статье рассказываю, как я пытался получить исходный код ядра Linux, который используется в планшете Digma Plane 4G 1538E.

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

Однако же, жизни многих людей работают на сбойных операционных системах. Они называются «списками дел». Встречался вам кто‑нибудь, кто управляет временем, используя списки дел, и реально завершает все запланированные на день задачи? Я таких людей не видел.

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

В таких сферах, как исследование операций (Operations Research) и наука о данных (Data Science) чрезвычайно актуально сближение теории и её практического применения в виде программных проектов. Теоретические выкладки формируют базу программ для оптимизации чего‑либо, так как теория даёт средства для решения разнообразных задач. Но очень важно помнить и о том, что подобные программы должны быть доступны конечному пользователю, что с ними должно быть удобно работать.

Задача коммивояжёра (Traveling Salesman Problem, TSP) — это, без сомнения, та самая задача комбинаторной оптимизации, которая изучена лучше всего (Rego, C., Gamboa, D., Glover, F., & Osterman, C., 2011. Traveling salesman problem heuristics: Leading methods, implementations and latest advances. European Journal of Operational Research, 211(3), 427–441). Её легко описать (по крайней мере — на словах), её можно использовать для того чтобы продемонстрировать некоторые из возможных компонентов API современной программы по построению маршрутов. В результате я просто не мог подобрать ничего лучше этой задачи в качестве основы для примера, который разобран в этой статье.

Здесь вы узнаете о том, как использовать Python‑библиотеку Streamlit для создания веб‑приложения, которое позволяет решать задачу коммивояжёра с использованием входных данных, предоставленных пользователем. Так как нас интересует создание приложения, пригодного для решения реальных задач, мы, анализируя пути перемещения между некими географическими точками, будем интересоваться не только евклидовым расстоянием между ними, но и другими характеристиками путей. В частности, наша программа, используя координаты точек, должна уметь получать данные о том, какое расстояние по автомобильным дорогам нужно преодолеть для перемещения между ними. Эти данные должны учитываться при выполнении оптимизации. Для этого мы воспользуемся API OpenStreetMap.

Если вы хотите лучше разобраться в теоретических аспектах числовой оптимизации — вам, возможно, интересно будет почитать мои статьи о линейном программировании и о задаче маршрутизации транспорта (это — обобщение задачи коммивояжёра).

Готовы поработать? Взгляните на то, что у нас должно в итоге получиться…

В 2017 году я впервые почувствовал себя в роли CTO (Chief Technical Officer, технический директор). Я присоединился к маленькому стартапу в роли разработчика‑сеньора, и не успел опомниться, как оказалось, что я держу в руках бразды правления технической командой. Если сказать кому о том, что я занимаю пост технического директора, прозвучало бы это впечатляюще, но на самом деле моя должность больше соответствовала роли технического руководителя проекта. Я трудился в маленькой компании, в состав которой входило человек десять сотрудников, и плотно занимался разработкой продукта этой компании. Мои дни были наполнены программированием, отладкой и постоянной борьбой с новыми багами и проблемами клиентов. Я, кроме того, был ответственным за то, чтобы наша команда выполняла бы обязательства перед инвесторами и клиентами. Это было не только время непростых задач, но и время мощного обучения, и время профессионального роста.

И ещё — то было время постоянного стресса. Но это — уже совсем другая история.

Перенесёмся в наши дни. Сегодня я — сооснователь цифрового агентства, которое находится в Швейцарии. В нём я занимаю должность CTO. Мы одновременно работаем над несколькими проектами, задействуя в каждом из них универсальные команды. Наше агентство, со времён его создания, немного подросло. Теперь в нём работает почти 50 человек. Эволюционировала и та роль, которую я в нём играю. Я больше не занимаюсь только программированием и отладкой. Теперь я управляю ресурсами, занимаюсь планированием, принимаю стратегические решения. Сейчас передо мной стоят другие непростые задачи. Но я, как и раньше, прямо‑таки наслаждаюсь, решая разного рода проблемы, и понимая, что я — тот, кто формирует техническое видение компании.

Музыка — это универсальный язык, для которого нет границ. Стремительный прогресс больших языковых моделей (Large Language Model, LLM) привёл к тому, что нейроучёные продемонстрировали острый интерес к исследованию представления музыки в человеческом мозгу.

Команда учёных из Google, Осакского университета, NICT и Araya Inc., движимая этим интересом, провела исследование, результаты которого изложены в публикации «Brain2Music: Reconstructing Music from Human Brain Activity». В исследовании используется конвейер обработки данных, названный Brain2Music, в состав которого входит модель MusicLM, реконструирующая музыку, которую слышит человек, на основе его мозговой активности. Система генерирует композиции, которые напоминают исходные музыкальные раздражители. Этот новый метод даёт ценные сведения о взаимоотношениях мозговой активности с когнитивным и чувственным опытом людей.

Учёные сделали следующие основные выводы:

Генеративные текстовые модели, например — ChatGPT и GPT-4, кардинально изменили всё то, что происходит в области искусственного интеллекта (ИИ, AI, Artificial Intelligence).

GPT‑модели (Generative Pre‑trained Transformer, генеративный предобученный трансформер), похоже, донельзя снизили порог входа в сферу ИИ, сделав её доступной даже тем, кто весьма далёк от компьютерных технологий. Любой может просто начать спрашивать модель обо всём на свете и получать пугающе точные ответы.

По крайней мере — получать такие ответы почти всегда…

Когда модель не выдаёт правильный ответ — это не значит, что она не в состоянии это сделать. Часто нужно всего лишь изменить предлагаемое ей задание, или «промпт» (prompt, подсказка), таким образом, чтобы направить модель к верному ответу.

Это часто называют «промпт‑инжинирингом» (prompt engineering).

В основе многих приёмов промпт‑инжиниринга лежат попытки сымитировать то, как работает человеческое мышление. Отличные примеры имитации мышления людей — это когда моделям предлагают «подумать вслух» (think aloud ) или говорят: «давай продумаем этот вопрос пошагово» (let's think step by step).

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

Мой друг и коллега по цеху, блоггер Сэм, недавно опубликовал своё третье иллюстрированное руководство, темой которого стало хеширование. Нет острой необходимости читать его руководство перед прочтением моей статьи, но я очень рекомендую вам это сделать. Хотя бы ради того, чтобы посмотреть на восхитительные анимации, от которых невозможно оторваться. Честно — они просто потрясающие. Тут, к сожалению, анимаций вы не найдёте, поэтому насмотритесь на них в той статье, а потом возвращайтесь сюда. Здесь вы сможете немного позабавиться поиском коллизий алгоритма хеширования MurmurHash3.

Сразу хочу отметить, что этот материал я писал исключительно ради развлечения. Ничто из того, что я тут покажу, не предназначено для продакшн-кода. И вот, как всегда, ссылка на GitHub-репозиторий, в котором можно найти код к этой статье.

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

Shopify — это один из крупнейших конкурентов Amazon в сфере онлайн‑ритейла. В компании работает около 10 000 человек. Shopify, в отличие от Amazon — централизованной торговой площадки, предлагает коммерческим структурам платформу для создания их собственных онлайн‑магазинов и веб‑сайтов. Shopify — это одна из крупнейших технологических организаций, в которой применяется полностью удалённый режим работы. Она перешла к такой модели в начале 2020 года. Это — одна из последних компаний такого размера, которая не переводит сотрудников обратно в офисы. По крайней мере — пока не переводит.

Shopify находится в самом разгаре внесения серьёзных изменений в свои процессы разработки ПО и в свою систему распределения сотрудников по уровням. Новая система основана на концепции «мастерства». В её рамках существующие уровни делятся на более мелкие части. Компания планировала ввести в строй эти новые «уровни мастерства» в мае, но она немного отстаёт от графика. Правда, даже учитывая это, изменения в уровнях сотрудников уже начались.

Я поговорил с несколькими инженерами‑программистами и менеджерами, которые сейчас работают в Shopify. Мне было интересно узнать от них о том, как в компании работает система уровней сотрудников, что вкладывается в понятие «мастерство», почему компания решила сделать то, что сделала. В этом материале мы исследуем следующие вопросы:

Значения Шепли применяются в экономике, а точнее — в теории кооперативных игр. Такие значения назначаются игрокам сообразно их вкладу в игру. В сфере машинного обучения идея использования значений Шепли нашла отражение во фреймворке SHAP (SHapley Additive exPlanations). Он представляет собой эффективный инструмент для интерпретации механизмов функционирования моделей.

Если вам интересны подробности о значениях Шепли — очень рекомендую обратиться к моей предыдущей статье, посвящённой математическим и интуитивным представлениям, раскрывающим смысл этих значений. И хотя в машинном обучении эти значения применяются по‑особенному, понимание базовых принципов, на которых они основаны, может оказаться полезным.

Использование значений Шепли во фреймворке SHAP напоминает их классическое применение тем, что они отражают индивидуальное влияние признаков на «игру» (другими словами — на модель машинного обучения). Но модели машинного обучения — это «игры», где нет «кооперирования» игроков, то есть — признаки не обязательно взаимодействуют друг с другом, как это происходило бы, будь они игроками в кооперативной игре. Вместо этого каждый из признаков вносит независимый вклад в результаты работы модели. Хотя тут может быть использована формула для нахождения значений Шепли, соответствующие вычисления могут оказаться слишком «тяжёлыми» и неточными. Это так из‑за большого количества «игроков» и из‑за того, что они могут объединяться в «союзы». Для того чтобы решить эту проблему, исследователи разработали альтернативные подходы. Среди них — метод Монте‑Карло и ядерные методы. В этом материале мы будем заниматься методом Монте‑Карло.

Если вы работали над проектом по реферированию текстов, то вы могли заметить сложность получения тех результатов, которые ожидалось получить. Если у вас имелись представления относительно того, как должен работать некий алгоритм, какие предложения он должен выделять при формировании рефератов, то этот алгоритм, чаще всего, выдавал результаты, весьма далёкие от ваших представлений. А ещё интереснее — ситуация с извлечением из текстов ключевых слов. Дело в том, что существует множество самых разных алгоритмов — от тех, что используют тематическое моделирование, до тех, где применяется векторизация данных и эмбеддинги. Все они работают очень хорошо. Но если дать одному из них абзац текста, то выданный им результат, опять же, будет далеко не самым правильным. А дело тут в том, что слова, которые встречаются в тексте чаще всего — это не всегда самые важные слова.

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