В Netflix было сделано много нового со времён выхода предыдущих материалов, посвящённых роли тех, кто отвечает за направление Content Engineering, в реализации поиска по нашему федеративному графу (federated graph). А именно, в первой статье мы идентифицировали проблему и рассказали об использовании инфраструктуры индексирования данных, а во второй мы углубились в вопрос о том, как мы пользуемся очередями. Мы дали доступ к Studio Search для всех инженеров компании, а не только для тех, кто занимается направлением Content Engineering, и переименовали этот проект в Graph Search. С Graph Search интегрировано более 100 приложений. В рамках этой системы поддерживается примерно 50 индексов. Мы продолжаем расширять её функционал. Как было обещано в предыдущем материале, здесь мы расскажем о том, как мы, объединив усилия с одной из команд, отвечающих за Studio Engineering, создавали обратный поиск (reverse search). Обратный поиск переворачивает с ног на голову стандартный подход к выполнению запросов: вместо того, чтобы искать документы, которые соответствуют запросу, он направлен на поиск запросов, соответствующих документу.

Если вы посещали занятия по статистике — вы, возможно, проходили тему «общая теория меры». Там могла идти речь о мере и об интеграле Лебега, а так же — об их связи с другими способами интегрирования. Если на ваших занятиях много внимания уделялось математике (так было у меня), то на них вы вполне могли познакомиться с теоремой Каратеодори о продолжении меры и даже с основами теории операторов на гильбертовых пространствах, а так же — с преобразованиями Фурье и много с чем ещё. Большинство этих математических конструкций нацелено на доказательство одной из самых важных теорем, на которой основана огромная часть статистики. Речь идёт о центральной предельной теореме (ЦПТ).

ЦПТ утверждает, что для широкого класса того, что мы называем в математике «случайными величинами» (которые представляют собой результаты проведения некоего эксперимента, включающего в себя элемент случайности), до тех пор, пока они удовлетворяют определённым условиям (как может показаться — простым), их среднее значение сходится к случайной величине определённого типа, который называют «нормальным» или «Гауссовым».

Написание запросов для решения аналитических задач — это основное занятие тех, кто работает с данными Pinterest. Но подбор подходящих данных и преобразование описания проблемы в корректный и эффективный SQL‑код могут оказаться непростыми делами. Ведь речь идёт о среде, которая быстро меняется, и о значительных объёмах данных, разбросанных по разным местам.

За последние три года размер данных Notion увеличился в 10 раз из‑за роста количества пользователей и объёмов контента, с которым они работают. Удвоение этого показателя происходило каждые 6–12 месяцев. Нам нужно было справиться со стремительным ростом размеров данных, соответствуя при этом постоянно растущим требованиям, которые выдвигали критически важные сценарии использования наших продуктов и аналитических систем. Особенно это справедливо в применении к новым функциям Notion AI. Для того чтобы решить эти задачи нам нужно было создать озеро данных Notion и обеспечить его масштабирование. Вот как мы это сделали.

Можно ли реализовать механизм внутреннего внимания, потребляющий гораздо меньше ресурсов, чем обычно?

Говорят, что механизм внимания плохо переносит работу с последовательностями большой длины. Это — идея, которая встречалась любому, кто потратил достаточно много времени, занимаясь трансформерами и механизмом внутреннего внимания. Это, одновременно, и так, и не так. С одной стороны — с этим сталкивался каждый, кто пытался увеличить размеры контекста своей модели, натыкаясь при этом на то, что модель начинала работать с сильным скрипом. С другой стороны — возникает такое ощущение, что практически каждую неделю выходит новая эталонная модель, которая характеризуется новыми размерами контекста, бьющими все рекорды. (Контекстное окно Gemini составляет 2 миллиона токенов!)

Есть много хитроумных методов, вроде RingAttention, которые позволяют обучать модели с очень большими размерами контекста на мощных распределённых системах. Но сегодня меня интересует всего один простой вопрос: «Как далеко можно зайти, применяя лишь механизм линейного внимания?».

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

Мой отец эмигрировал из Колумбии в Северную Америку, когда ему было 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‑моделями и человеческой психологией важны, так как они помогают нам понять то, как мы можем улучшить результаты работы таких моделей. Аналогии указывают нам на возможности, которых может не хватать моделям.