Feature Programming

Эссе по итогам нырка в Deep Learning, но не о DL и даже не совсем о Machine Learning, а о новой парадигме программирования, которая рождается из него.

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

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

Оговорка раз: я определённо не эксперт в машинном обучении. Эссе в большей степени отражает мой опыт и картину мира, нежели знания и понимание ML и DL.

Оговорка два: термины «признак», «feature» будут использоваться достаточно вольно.

Feature Programming

Функциональное программирование — когда программу выражают через абстракцию математических функций: операции ими и над ними.

Объектно-ориентированное программирование — когда на программу смотрят через абстракцию объектов и коммуникаций между ними.

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

Существует множество прочих мемплексов с подходами к описанию программ.

Возможно, я увидел новую парадигму: Feature Programming — представление программы через манипуляцию признаками данных. Чтобы не путать с функциональным программированием, сокращать Feature Programming будем как FeP.

В интернетах есть близкий термин — Feature Oriented Programming, который выглядит более естественно, но уже занят другой штукой. Не будем их путать.

Каждая из больших парадигм (FP, OOP, LP, etc) не далась нам изначально, не появилась вместе с первыми ЭВМ, но рождалась путём многочисленных проб и ошибок в исследовательских и промышленных лабораториях. Так и FeP рождается прямо сейчас и пока не обзавелась собственным уголком в отрасли.

Насколько большим будет этот уголок зависит, как и в случае с другими парадигмами, не только от наших усилий и хайпа, но и от физических ограничений, экономической целесообразности. Об этом ещё поговорим.

О признаках

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

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

Утрируя, признак — харатеристика данных, которая позволяет разделить их на непересекающиеся множества по признаку её наличия.

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

Отмечу, что признак может определяться не только явно, но и статистически. Например, как тип распределения значения, его мат. ожидание и дисперсия.

Признаками можно управлять:

• определять: посмотреть какого цвета забор;
• заменять: перекрасить забор в другой цвет;
• добавлять: покрасить забор в шахматную клетку;
• удалять: закрасить шахматную клетку.

Можно создавать штуки с заданными признаками: зелёные заборы, водонепроницаемые телефоны, etc.

Эти рассуждения справедливы не только для физического мира, но и для виртуального. Замените в примерах забор на «цифровое изображение забора» и ничего не изменится.

Недавно мы имели единственный подход к работе с признаками. Чтобы изменить признак штуки, требовалось разобраться как он появляется и повторить этот процесс с необходимыми изменениями.

Чтобы сделать забор зелёным, требовалось сделать зелёную краску и покрасить его.

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

С развитием машинного обучения на горизонте появился альтернативный путь. Теперь не нужно досконально разбираться с причинами появления признака, воспроизводить их цепочку или изменять её. Достаточно просто выделить признак и преобразовать: удалить, заменить, изменить.

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

Машинное обучение и управление признаками

Большая часть машинного обучения посвящена операциям над признаками:

• классификация — определение известных признаков (классов);
• кластеризация — выделение неизвестных признаков и разделение данных на их основе;
• сегментация — выделение данных на основе признаков;
• обнаружение аномалий — выделение данных на основе признаков;
• генерация данных — создание данных с заданными признаками;
• перенос стилей изображения — перенос признаков;
• etc.

Однако неправильно ставить знак равенства между машинным обучением и FeP.

Во-первых, признаками можно манипулировать и без ML — классическими алгоритмами. Утрируя, не надо создавать нейронную сеть для определения признака делимости на 2. Да и та же аугментация данных для ML изменяет признаки, но сама не работает, обычно, на технологиях ML.

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

Однако, прямо здесь и сейчас лучше всего FeP заметно в глубоком обучении, поэтому для удобства можно далее без потери смысла все упоминания FeP заменять на DL.

Программирование признаками

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

Стиль художника, наличие опухолей на МРТ, форма лица, сворачиваемость белков, особенности голоса до недавнего времени поддавались программной обработке с большим трудом. Команды программистов и учёных тратили годы, чтобы получить заметный результат.

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

Мало кто, а может и никто — я не встречал упоминаний, предполагал, что элементарным шагом алгоритма станет операция «выделить признак как у этих данных». Не говоря уже об операциях вроде «перенести общий признак данных X на данные Y».

Deep Learning буквально переворачивает индустрию, о чём, как мне кажется, большинство до сих пор не подозревает. С другой стороны, это не удивительно: FeP и DL сейчас находятся где-то на уровне разработки машинными кодами / ассемблером на заре вычислительных технологий.

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

Для примера актуализирую описание уже древнего алгоритма генерации анимешных аватарок:

1. Собрать изображения персонажей из интернета.
2. Выделить части изображения с признаком «лицо».
3. Определить на лицах признаки «цвет волос», «цвет глаз», «форма лица», etc.
4. По изображениям лиц и признакам создать генератор новых данных с признаками лиц.
5. Profit.

Получить схожий результат в традиционном программировании невозможно крайне дорого.

Более интересные примеры и размышления найдутся в моих комментариях к новостям о GPT-3 для изображений и улучшению графики в GTA 5.

Если отстраниться от текущих «скромных» возможностей DL, можно представить более сложные системы:

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

Отличие от классического программирования

Программирование признаками стоит ещё ближе к исследовательской работе, чем обычное программирование.

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

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

Как следствие, программирование признаками может сдвинуть суть исследовательской работы, инженерии и науки в целом. Об этом будет отдельный пост.

Текущее состояние

Как я уже говорил, на текущий момент FeP лучше всего просматривается в области Deep Learning и пока не ясно, возникнут ли альтернативы. Поэтому в этой части я буду говорить о текущем состоянии DL, а в следующей — о его перспективах.

Работа с DL, по моим ощущениям, сейчас находится примерно на уровне программирования ассемблером/машинными кодами на больших ламповых машинах.

Как при разработке на ассемблере, приходится думать о регистрах, архитектуре процессора, адресации памяти и прочей жути, так и при разработке Deep Learning модели необходимо точно указывать слои нейронов, их типы и свойства — гиперпараметры нейронной сети. Не говоря уже о подготовке данных.

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

Кроме того, state of the art результаты доступны только в виде научных статей, что требует от инженеров дополнительных усилий по их отслеживанию и внедрению в свою работу. Среднестатический разработчик в наше время с таким вообще не сталкивается, даже если работает над сложными системами.

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

И, само собой, чем меньше у вас денег, тем больше вы страдаете и полагаетесь на чуйку. Чем больше — тем проще и быстрее вам готовить модели.

Поэтому главный вызов для DL, на текущий момент, — разработка методов и/или инструментов абстрагирования от работы с гиперпараметрами.

Необходима быстрая обратная связь для разработчиков моделей.

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

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

Некоторые движения в эту сторону уже происходят, но довольно медленно, на мой взгляд.

Направления развития

Аналогично истории с классическим программированием, для появления специализированного высокоуровневого инструмента FeP есть несколько препятствий:

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

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

Варианты обхода первого препятствия:

• Жёсткая формализация моделей — тут пока не видно результатов.
• Построение метамоделей, которые будут самостоятельно крутить гиперпараметры. Такие оптимизаторы уже развиваются и даже включены в топовые библиотеки.
• Разработка стандартов, которые зафиксируют статистически оптимальные наборы гиперпараметров для базовых задач. Попытки стандартизации начались, но издалека, пример — ONNX.

Варианты обхода второго препятствия:

• Улучшение текущей архитектуры железа. Ещё возможно, но на сколько порядков ускорения вычислений его хватит? А сколько порядков надо?
• Развитие облачной инфраструктуры. Сделает DL доступнее, но не дешевле.
• Кардинальное изменение архитектуры железа и моделей, например на:
  • massively parallel processor + PLD (а-ля FPGA) для разработки;
  • massively parallel processor + ASIC для реализации.

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

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

Репозитории готовых моделей

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

В общем-то, такие репозитории будут развиваться в любом случае — по аналогии с репозиториями библиотек классических ЯП. Первые реализации уже появились. Вопрос скорее в их роли, будут ли они использоваться как:

• классические программные пакеты;
• базовые строительные блоки FeP программ;
• заготовки для доучивания под нужды разработчика.

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

Альтернативы DL

Может появиться альтернатива DL или их вариация, которая будет менее требовательна к вычислительным ресурсам.

Вариант чрезмерно оптимистичный, но я допускаю его возможность.

Направления исследований я вижу следующие:

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

Мне, конечно, близок последний вариант. В частности, я бы поставил на открытие/формализацию законов эволюции и систем.

Стоит ли переключаться на FeP сейчас?

ML и DL — довольно далёкие от классического программирования дисциплины. Идеальный вход в их глубины сейчас происходит со стороны статистики, требует сильной математической интуиции.

В них ещё много классического программирования, но это программирование для обеспечения инфраструктуры, а не для занятия FeP. Программист может, например, строить кластер для ML или управлять потоками данных, но это слабо приблизит его к ML.

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

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

Соответственно, для физических лиц:

• ML & DL идеальны как хобби. Полученные знания и опыт обязательно окупятся.
• Если у вас есть сильные математические навыки — это отличный вариант построения карьеры. Рекомендую.
• Если ваши навыки не очень сильные, но компенсируются общей соображалкой и упорством — тоже хороший вариант.
• Если вы боитесь обычного программирования, то ML & DL ввергнут вас в  хтонический ужас :-) Особенно то ML, которое не о нейронных сетях.

Главное не попадите в фирму, у которой на ML денег не хватает.

Юридическим же лицам главное помнить две вещи:

• Информация правит миром.
• ML & DL — очень дорогие удовольствия.

Чем больше у вас данных и денег, тем больше пользы вы можете извлечь из анализа признаков своих данных.

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

Если у вас мало денег и мало информации, ML & DL навредит вам с большей вероятностью, чем поможет. Скорее всего вы не найдёте специалистов, которые смогут сделать с данными что-то полезное.

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

Делайте лопаты

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

Так вот, самое время делать лопаты для FeP.

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

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

Материалы по теме

• Добавлено 9 октября 2023: How I think about LLM prompt engineering