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

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

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

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

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

Сегодня я расскажу о том, как был подготовлен материал об одиночестве, «24 hours in an invisible epidemic», опубликованный на платформе Pudding.

Всё началось с моей одержимости материалами Американского обследования использования времени (American Time Use Survey, ATUS). Каждый год в ходе соответствующего мероприятия проводится опрос десятков тысяч американцев. Им предлагают проследить за одним днём своей жизни. Полученные данные позволяют получить некие общие показатели и, при желании, добраться до каждого респондента и узнать о том, чем занимался именно он.

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

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

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

Двадцать лет назад Джоэл Спольски написал: «Не существует такой штуки, как «обычный текст». Если имеется строка, но неизвестно, какую кодировку символов она использует — смысла в этой строке нет. Больше нельзя спрятать голову в песок и притвориться, что «обычный» текст имеет кодировку ASCII.»

Многое изменилось за 20 лет. В 2003 году главный вопрос звучал так: «Что это за кодировка?». В 2023 году такой вопрос больше не стоит: с вероятностью в 98% это — UTF-8. Наконец то! Можно снова спрятать голову в песок!

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

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

Улучшите качество кода, украсив его оператором match и срезами объектов.

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

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

В этом материале мы рассмотрим две таких возможности: оператор match и создание срезов строк и списков. Мы подробно разберёмся с тем, как работают эти механизмы, а так же изучим несколько примеров, которые позволят вам познакомиться с синтаксисом и семантикой соответствующих конструкций.

Появление в библиотеке pandas режима Copy‑on‑Write (CoW, копирование при записи) — это изменение, нарушающее обратную совместимость, которое окажет некоторое воздействие на существующий код, использующий pandas. Мы разберёмся с тем, как адаптировать код к новым реалиям, сделать так, чтобы он работал бы без ошибок тогда, когда режим CoW будет включён по умолчанию. Сейчас сделать это планируется в версии pandas 3.0, выход которой ожидается в апреле 2024 года. В первом материале из этой серии мы разбирались с особенностями поведения CoW, во втором — говорили об оптимизации производительности, имеющей отношение к новому режиму работы pandas.

Мы планируем добавить в систему «тревожный режим», в котором она будет выдавать предупреждения при выполнении любой операции, поведение которой меняется при включении CoW. Эти предупреждения будут привлекать к себе очень много внимания пользователей, поэтому к возможности их появления стоит относиться с осторожностью. В этом материале рассматриваются некоторые типичные проблемы кода и то, как его можно адаптировать для того чтобы его поведение не изменилось бы после включения CoW.

В первом материале из этой серии была объяснена работа механизма Copy‑on‑Write (CoW, копирование при записи). Там были упомянуты некоторые ситуации, в которых при выполнении кода осуществляется копирование данных. В этой статье речь пойдёт об оптимизации, направленной на то, чтобы копирование не ухудшило бы средних показателей скорости работы кода.

Мы используем подход, применяемый внутри pandas для того, чтобы избежать копирования всего объекта DataFrame в тех случаях, когда это не нужно. Этот подход позволяет повысить производительность системы.

Библиотека pandas 2.0 вышла в начале апреля, в ней появилось много улучшений нового режима Copy‑on‑Write (CoW, копирование при записи). Ожидается, что в pandas 3.0 режим CoW будет использоваться по умолчанию. Сейчас полный переход на копирование при записи запланирован на апрель 2024 года. У разработчиков библиотеки нет планов поддержки некоего «режима совместимости» или режима, в котором CoW не применяется.

Эта серия публикаций посвящена рассказу о том, как работают внутренние механизмы CoW в pandas. Она призвана помочь пользователям библиотеки понять, что происходит при выполнении кода, узнать о том, как эффективно пользоваться копированием при записи, и о том, как адаптировать свой код под новые возможности pandas. Здесь будут приведены примеры того, как использовать данный механизм для того чтобы добиться от системы самого высокого уровня производительности. Здесь же будет рассмотрено и несколько антипаттернов, использование которых в программах ведёт к появлению в них ненужных «узких мест». Пару месяцев назад я написал небольшой вводный материал по Copy‑on‑Write в pandas.

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

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

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

В таких сферах, как исследование операций (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 человек. Эволюционировала и та роль, которую я в нём играю. Я больше не занимаюсь только программированием и отладкой. Теперь я управляю ресурсами, занимаюсь планированием, принимаю стратегические решения. Сейчас передо мной стоят другие непростые задачи. Но я, как и раньше, прямо‑таки наслаждаюсь, решая разного рода проблемы, и понимая, что я — тот, кто формирует техническое видение компании.

В последние несколько месяцев наблюдаются значительные успехи в разработке языковых моделей, особенно — в сфере частного бизнеса. В прошлом году вышло несколько подобных проектов, основанных на Minecraft. В частности — речь идёт о фреймворке MineDojo, который представляет собой огромный симулятор, а так же — о системах, позволяющих ИИ‑агентам обучаться игре в Minecraft с помощью VPT (Video PreTraining). Похожие проекты появились и в этом году. Среди них — системы, в которых используется SOTA LLM, модель STEVE-1, Minecraft‑агент Voyager, фреймворк GITM.

Базой всех этих разработок является игра Minecraft. В них, кроме того, обычно используется окружение MineRL. Мы, для удовлетворения наших исследовательских потребностей, занимаемся работой над другим стеком инструментов, который основан на воксельном движке Minetest.

В новой публикации «Large Language Models as Optimizers» (Большие языковые модели в роли оптимизаторов) команда исследователей Google DeepMind представила инновационный метод оптимизации, названный «оптимизация через промпты» (Optimization by PROmpting, OPRO). При применении этого метода в роли оптимизаторов используются большие языковые модели (Large Language Model, LLM). С его помощью можно генерировать решения, зависящие от описаний задач оптимизации, выполненных на естественном языке.

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

Этот материал посвящён взлому промптов Notion AI, семи методикам реверс‑инжиниринга промптов и рассказу о том, почему все ошибаются в своих мнениях о промпт‑инъекциях (prompt injection).

Вчера я получил доступ к публичной альфа‑версии Notion AI. У меня ушло 2 часа на то, чтобы, пользуясь промпт‑инъекциями, раздобыть полные тексты внутренних промптов, применяемых для реализации каждой из возможностей Notion AI.

Сегодня я публикую тексты этих промптов, но делаю это не потому, что я — человек безответственный; я отстаиваю точку зрения, в соответствии с которой в этом нет ничего страшного. И я воздаю должное команде Notion, которая так хорошо интегрировала возможности искусственного интеллекта в свой продукт.

Мне, кроме того, пришлось разработать и использовать кое‑какие новые техники приблизительного определения исходных текстов промптов. Я подумал, что было бы интересно представить их вам — моим замечательным читателям.

Привет Хабр! Сегодня публикуем вторую часть материала об архетипах программных архитекторов. Если пропустили, то вот первая часть.

Что такое архетип? Это — образец набора вариантов поведения или поведенческих сценариев, типичных для определённой роли. Уилл Ларсон, который сейчас занимает должность главного технического директора в Carta, определил четыре архетипа для должности «ведущий инженер‑программист» (Staff Engineer). Это — «техлид» (Tech Lead), «архитектор» (Architect), «решатель задач» (Solver) и «незаменимый помощник» (Right Hand).

Я работаю над новой книгой, которую планируется опубликовать этой осенью. Она называется «The Software Engineerʼs Guidebook». Когда я писал в ней об архитектуре ПО, меня зацепила идея существования «архетипов» программных архитекторов, которые могут сочетаться друг с другом либо хорошо, либо плохо. Речь идёт о людях, работающих бок о бок друг с другом, вклад каждого из которых в общее дело отличается чем-то особенным. Разбираться с тем, какие архетипы лучше всего описывают коллег — это интересное занятие, которое может привести к ценным открытиям. И вполне возможно, что вы, задумываясь об этом, поймёте, какой из архетипов лучше всего описывает вас самих.

Развитие больших языковых моделей (Large Language Model, LLM) привело к смене парадигмы в сфере обработки естественного языка (Natural Language Processing, NLP). LLM, обученные на огромных объёмах текста, взятого из интернета, могут осваивать выполнение новых задач, задействуя механизмы контекстного обучения. Это означает, что NLP‑специалисты, «натаскивая» такие модели на решение определённых задач, не занимаются обновлением их параметров. Вместо этого специалисты пишут для LLM промпты, демонстрирующие желаемое поведение моделей и содержащие инструкции или некоторое количество готовых примеров. Эти промпты передают моделям в виде входного контекста (потому это и называют «контекстным обучением»), а модели используют информацию из промптов для формирования ответов на похожие вопросы.

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

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

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

В Python 3.8. появилась новая примечательная возможность — протоколы (protocols). Протоколы — это альтернатива абстрактным базовым классам (abstract base classes, ABC). Они позволяют пользоваться структурной подтипизацией (structural subtyping), то есть — осуществлять проверку совместимости классов исключительно на основе анализа их атрибутов и методов. В этом материале мы поговорим о протоколах в Python и разберём практические примеры работы с ними.