Криптопротокол для ИИ

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

Отсюда закономерный вопрос: как что-то спросить у ИИ и не раскрыть чувствительную инфу? Напрашивается очевидное решение — использовать локальный ИИ на своём железе и со своей моделью. Но железо дорогое, а качественную модель бесплатно не предоставят, такая корова и самому нужна. И настраивать, обучать это всё тоже дорогое дело и не для каждой компании. Облака и ИИ как сервис пока что (и вероятно надолго) это единственное доступное многим решение.

Другое решение: размыть чувствительные данные среди подобных других. К примеру Алиса предоставляет Бобу в облако 1000 вариантов контекста, из которых один настоящий, а другие сгенерированные мусорные. Алиса знает какой именно запрос настоящий, но Бобу придётся просчитать все и возможно ещё и доучиться на мусорных вариантах (привет GIGO). Также Боб может найти закономерность в мусорных вариантах, распознать их, выбросить мусорные вариант и может даже найти истинный вариант. Или как минимум сильно сузить множество.

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

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

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

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

ChatGPT product strategy

Крайне интересный документ появился в сети в конце 2024 года. Это выдержки из продуктовой стратегии ChatGPT. Скачать можно в первоисточнике или посмотреть здесь если первоисточник исчезнет.

Вкратце суть документа такая.

  • Мы хотим превратить GPT в универсальный костыль супер-ассистент человека. Такой ассистент, который заменит если не всё, то почти всё: учителей, экспертов-советников, соавторов, развлекателей, компаньов, аналитиков.
  • Прибыль не будет расти вечно. Мы создадим такого супер-ассистента, который сгенерирует монетизируемый спрос.
  • Сейчас наши конкуренты чат-гопоты это поисковики, браузеры и даже взаимодействие с реальными людьми. Но мы будем искать способы втянуть людей в пользование чат-гопотой. И сделать свой продукт универсальным окном в интернет и в реальный мир. Делать это собираемся с помощью агрессивной дистрибуции.

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

Логичный вопрос — где для обучения всего этого брать контент? Напрашивается очевидный ответ: любой девайс пользователя будет его читать и слушать и на всём переданном GPT контенте обучаться без согласия пользователя.

Вы всё ещё не общаетесь с чат-гопотой? Тогда она идёт к Вам!

Под капотом чужого продукта

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

Суть в следующем. Компания использует некоторое покупное или открытое ИТ-решение и всё в нём устраивает, кроме некоторого недостающего функционала. И этот функционал не обеспечивается штатными возможностями продукта, конфигурацией или расширениями к нему. Возникает естественная мысль: а давайте найдём спеца/компанию или своими силами "доработаем напильником" решение как нам надо. Часто это можно сделать за вменяемые деньги и время, компания модифицирует решение и включает в свой ключевой бизнес-процесс. И всё работает, какое-то время.

Сложности начинаются по прошествии времени. Продукт у поставщика обновляется, а наш нет. Или обновляется, но работает не как ожидалось. Или работает, но через какое-то время появляются неожиданные ошибки. Или продукт поменялся так, что модификация с сохранением функционала теперь невозможна. Фактически компания теперь имеет кастомный продукт без возможности внятной поддержки. Таким образом получаются различные необновляемые CRM/ERP/фреймоворки и сторонние библиотеки, а 1С-ники отлично знают "счастье" работы с правленной конфигурацией.

Хороший вариант решения: написать свой модуль или расширение к используемому решению. К сожалению, такое возможно не всегда, да и в этом случае расширение зависимо от основного продукта и может потерять поддержку.

В более широком смысле это вопрос управляемости ИТ-решений. Внедрённое локально решение кажется "своим" и управляемым, однако это иллюзия. Любой продукт имеет множество внешних зависимостей, повлиять на которые не в наших силах. Это важное отличие от материального мира, где купленная вещь действительно "своя".

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

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

Разработка ПО полвека назад

Так Фредерик Брукс описывает разработку и тестирование софта примерно полвека назад:

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

(…)

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

Люди работали круглосуточно, чтобы машины не простаивали. Еще 20-30 лет назад крупное ПО полностью компилировалось раз в сутки и код выкладывался на тестирование. Там же:

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

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

(…)

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

Сейчас по ночам обычно спят, а инструменты всего цикла разработки ПО поменялись. У почти каждого разработчика в арсенале виртуальные машины, контейнеры и прочие докеры для экспериментов и не только. Тестировать и выкладывать даже большой код можно настолько часто, насколько это позволяет местный DevOps.

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

Взлет и падение проекта FreeBSD

В далёких нулевых годах, когда я только начинал работать с серверными системами, мейнстримом было использование FreeBSD. Более половины серверов под *nix в то время было FreeBSD и другмими BSD. Линукс в качестве серверной системы тогда встречался редко и на него смотрели с опаской. Даже на десктопах линукс считался выбором гиков. Адепты BSD считали только её варианты настощим unix и достойной серверной системой и на "пингвинятников" часто смотрели с большим презрением.

Всё изменилось в последующие годы — доля BSD на серверах уже в 2010-е неуклонно падала и сейчас её почти и не осталось, а если встретишь, то под разные специфичные/legacy задачи. Молодое поколение не всегда и знает об это операционке, для них это архаика сродни MS DOS или OS/2.

Почему так получилось, что хорошая ОС уступила лидерство?

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

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

Отдельной историей был buildworld и buildkernel, т.е. обновление самого самого "мира" и ядра. "Пересборка мира" занимала огромное количество времени и в результате можно было получить нерабочую систему. Или рабочую систему, в которой что-то не работает из прикладного софта и требует "доработки напильником", причём это не всегда можно было определить сразу после пересборки, иногда проблема всплывала потом. Поскольку результат такого обновления в общем случаем не предсказуем, было разумно из RAID-зеркала (если такая возможность была) вынуть один из дисков в качестве бэкапа, обновиться и вернуть в случае успеха.

И так на каждом сервере! Если в небольших проектах такое можно было делать относительно безболезненно, то на больших проектах или high-availability процесс обновления представлял собой уже нетривиальную задачу. А если серверов не несколько штук, а хотя бы десятки — поддержка превращалалась в проблему.

Линуксы с их пакетными менеджерами и уже скомпилированными и протестированными(!) ядром, библиотеками и софтом имели огромное преимущество, их обновление происходило предсказуемо, а саму систему со всем софтом и окружением можно было несложно воспроизвести из пакетов.

Только по этой причине многие компании отказались от freebsd в пользу систем с более предсказуемой поддержкой. Та же участь постигла и линуксы без пакетных менеджеров, вроде того же gentoo.

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

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

Неподдерживаемый код

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

В продакшене могила компилировалась из исходников на тех же CentOS серверах примерно в те же годы, т.е. начало 2010-х. На тех же серверах работает код самого проекта на php 5.4 с остальным уже сильно не новым окружением. А код заказчика развивается и хотелось бы уже мигрировать новую спецификацию языка и использовать возможности новых библиотек. Но сделать это сложно.

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

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

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

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

Выводы:

  1. Избегать использования библиотек, поддержка которых вероятно скоро прекратится. Заранее это не всегда можно определить, но есть косвенные признаки.
  2. Писать код с продуманной архитектурой и интерфейсами, которые позволяют легко поменять хранилище (и не только его).
  3. Разделять задачу на разные уровни. Конкретно здесь хранение можно почти полностью реализовать на более низком уровне без существенного потери функционала.
  4. Использовать как можно более прозрачные и унифицированные инструменты.