В таких сферах, как исследование операций (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 и разберём практические примеры работы с ними.

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

Исследовательская команда Microsoft, вдохновлённая этими идеями, провела эксперимент, отчёт о котором — Textbooks Are All You Need — можно найти на arXiv.org. В рамках эксперимента была создана большая языковая модель для генерирования кода, названная phi-1. Обучение этой модели проводилось с использованием специально подготовленного набора данных, качество которого сопоставимо с учебниками по программированию. В результате модель phi-1, при том, что в ней используется всего 1,3 миллиарда параметров, показала результаты, превосходящие то, на что способны самые совершенные большие языковые модели.

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

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

Если N — величина небольшая — взаимоотношения между точками будут именно такими, какими их можно представить на интуитивном уровне. Но иногда N достигает огромных значений. Это может произойти, например, когда множество признаков создают посредством прямого кодирования или чего‑то подобного. Для очень больших значений N наблюдения ведут себя так, как если бы они были бы представлены разреженными данными, или так, как если бы расстояния между ними были бы несколько больше, чем можно было бы ожидать.

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

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

Генеративные текстовые модели, например — 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. Читайте также первую часть.

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

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

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

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

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

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

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

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

Почему вы выбрали фреймворк Scrum, а не метод управления проектами Kanban? Не можете ответить? Значит — лично вы Scrum и не выбирали. Кто-то сделал это за вас.

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