В реальной реализации ML само обучение занимает около четверти усилий.
Остальные три четверти включают подготовку данных с помощью усилий и бюрократии, сложное развертывание, часто в замкнутом цикле без доступа в Интернет, настройку инфраструктуры, тестирование и мониторинг.
Документы сотнями листов, ручной режим, конфликты версий моделей, открытый исходный код и суровый энтерпрайз — все это ждет дата-сайентиста.
Но его не интересуют такие «скучные» оперативные вопросы; он хочет разработать алгоритм, добиться высокого качества, отдать его и никогда больше не вспоминать.
Возможно, где-то ML реализуется проще, проще, быстрее и одной кнопкой, но таких примеров мы не видели.
Все вышеперечисленное — это опыт Front Tier в сфере финансовых технологий и телекоммуникаций.
О нем на Высокая нагрузка++ — сказал Сергей Виноградов, эксперт в области архитектуры высоконагруженных систем, больших хранилищ и анализа больших объемов данных.
Жизненный цикл модели
Обычно жизненный цикл в нашей области состоит из трех частей.Во-первых задача исходит из бизнеса .
В секунду инженер по данным и/или специалист по данным готовят данные , построить модель.
Третья часть начинается хаос .
В последних двух происходят разные интересные ситуации.
Разнорабочий
Первая распространенная ситуация: специалист по данным или инженер по обработке данных имеет доступ к продукту, поэтому ему говорят: «Ты все это сделал, можешь установить».Человек берет Блокнот Юпитера или пачку ноутбуков, рассматривает их исключительно как артефакт развертывания и начинает с радостью реплицировать их на некоторых серверах.
Вроде все хорошо, но не всегда.
Я скажу вам почему позже.
Безжалостная эксплуатация
Вторая история сложнее и обычно случается в компаниях, где эксплуатация достигла состояния легкого безумия.Специалист по обработке данных внедряет свое решение в производство.
Там они открывают этот черный ящик и видят нечто ужасное:
- блокноты;
- мариновать разные версии;
- куча скриптов: непонятно где и когда их запускать, куда сохранять генерируемые ими данные.
Например, датасайентист не указал конкретную версию библиотеки, и операция взяла самую последнюю.
Через некоторое время прибегает дата-сайентист: — Вы установили не ту версию scikit-learn, теперь все метрики работают! Вам необходимо откатиться на предыдущую версию.
Это полностью ломает изделие, и страдает работа.
Бюрократия
В компаниях с зелеными логотипами, когда дата-сайентист приходит на производство и приносит модель, он обычно получает в ответ документ на 800 листов: «Следуйте этим инструкциям, иначе ваш продукт никогда не увидит свет».Грустный дата-сайентист уходит, бросает все на полпути, а потом уходит — ему это неинтересно.
Развертывать
Предположим, что специалист по данным прошел все круги и наконец все развернул.Но он не сможет понять, что все работает как надо.
По моему опыту, те же благословенные банки не следят за продуктами data science. Хорошо, если специалист записывает результаты своей работы в базу данных.
Через некоторое время он их получит и увидит, что происходит внутри.
Но это не всегда происходит. Когда бизнес и специалист по данным просто верят, что все отлично и прекрасно работает, это приводит к неудачным случаям.
МФО
Однажды мы разработали скоринговую систему для крупной микрофинансовой организации.Нам их не дали продать, а просто взяли у нас каскад моделей, установили и запустили.
Они остались довольны результатами тестирования моделей.
Но через 6 месяцев они вернулись: - Все плохо.
Дела идут неважно, нам становится всё хуже и хуже.
Модели вроде бы отличные, но результаты падают, мошенничества и дефолта становится всё больше, а денег всё меньше.
За что мы вам заплатили? Давайте разберемся.
При этом они опять-таки не предоставляют доступа непосредственно к модели.
На загрузку логов ушёл месяц, а им было полгода.
Мы изучали выгрузку еще месяц и пришли к выводу, что в какой-то момент ИТ-отдел МФО изменил входные данные, и вместо документов в json стали отправлять документы в xml. Модель ожидала json, а получила xml, грустила и считала, что входных данных нет.
Если данных нет, то и оценка происходящего другая.Это невозможно обнаружить без мониторинга.
Новая версия, каскад и тесты
Часто мы сталкиваемся с тем, что модель работает хорошо, но по каким-то причинам она была разработана.новая версия .
Опять же нужно как-то довести модель и пройти все круги ада еще раз.
Хорошо, если версии библиотек будут такими же, как и в предыдущей модели, но если нет, то развертывание начинается заново.
Иногда, прежде чем запустить в бой новую версию, нам хочется Попробуй это — выставьте на продажу, посмотрите тот же трафик, убедитесь, что он хороший.
Это снова полная цепочка развертывания.
Дополнительно мы настроили системы так, что по этой модели не происходит никакого реального вывода, если мы говорим о скоринге, а только мониторинг и анализ результатов для дальнейшего анализа.
Бывают ситуации, когда его используют каскад моделей.
Когда результаты работы следующих моделей зависят от предыдущих, необходимо как-то наладить взаимодействие между ними и где-то опять же всё это сохранить.
Как решить такие проблемы?
Часто проблемы может решить один человек В ручной режим , особенно в небольших компаниях.Он знает, как все работает, держит в голове все версии моделей и библиотек, знает, где и какие скрипты работают, какие витрины строят. Это все здорово.
Истории, которые оставляет после себя ручной режим, особенно прекрасны.
История наследства .
Добрый человек работал в одном небольшом банке.
Однажды он уехал в южную страну и не вернулся.
После него нам досталось в наследство: куча кода, генерирующего витрины, на которых работают модели.
Код отличный, работает, но мы не знаем точную версию скрипта, генерирующего ту или иную витрину.
Все витрины присутствуют в бою, и все они запущены.
Мы потратили два месяца, пытаясь разобраться в этом запутанном клубке и как-то его структурировать.
В суровом предприятии, люди не хотят заморачиваться со всякими Питонами, Юпитерами и т. д. Они говорят: — Давайте купим IBM SPSS, установим и всё будет отлично.
Там как-то решались проблемы с версионированием, с источниками данных, с деплоем.
Такой подход имеет право на существование, но не каждый может себе это позволить.
В любом случае, это очень качественная игла с колючкой.
Сидят на нем, но слезть не могут – края неровные.
И это обычно очень дорого.
Открытый источник - противоположность предыдущему подходу.
Разработчики порылись в Интернете и нашли множество решений с открытым исходным кодом, в той или иной степени решающих их проблемы.
Это отличный способ, но для себя мы не нашли решения, которое удовлетворяло бы наши требования на 100%.
Поэтому мы выбрали классический вариант – ваше решение .
Свои костыли, велосипеды, все твое, дорогой.
Чего мы хотим от нашего решения?
Не пишите все сами .Мы хотим взять компоненты, особенно инфраструктурные, которые хорошо себя зарекомендовали и знакомы с применением в институтах, с которыми мы работаем.
Мы просто напишем среду, которая позволит легко изолировать работу специалиста по данным от работы DevOps. Обработка данных в двух режимах: пакетном и в режиме реального времени.
.
В наши задачи входят оба режима работы.
Простота развертывания и в закрытом периметре .
При работе с конфиденциальными личными данными доступ к сети Интернет отсутствует. В это время все должно быстро и точно дойти до производства.
Поэтому мы стали смотреть в сторону Gitlab, конвейера CI/CD внутри него и Docker.
Модель не является самоцелью.Внутри конвейера должны быть правила и конгломерат моделей с поддержкой.Мы не решаем задачу построения модели, мы решаем бизнес-задачу.
версионирование всех компоненты трубопровода.
Что подразумевается под трубопроводом? В России действует 115-й Федеральный закон о борьбе с отмыванием денег и финансированием терроризма.
Только содержание рекомендаций ЦБ занимает 16 экранов.
Это простые правила, которым банк может следовать, если у него есть такие данные, или не может, если их нет. Оценка заемщика, финансовой операции или другого бизнес-процесса — это поток данных, который мы обрабатываем.
Поток должен проходить через такие правила.
Эти правила в простой форме описывает аналитик.
Он не специалист по данным, но хорошо знает законы и другие инструкции.
Аналитик садится и понятным языком описывает тесты на данные.
Построение каскадов моделей .
Часто возникает ситуация, когда следующая модель использует для своей работы значения, полученные в предыдущих моделях.
Быстро проверяйте гипотезы.
Повторю предыдущий тезис: датасайент сделал какую-то модель, она крутится в бою и работает хорошо.
По какой-то причине специалист придумал лучшее решение, но не хочет рушить налаженный рабочий процесс.
Специалист по данным присоединяет новую модель к тому же боевому трафику в боевой системе.
Он не участвует непосредственно в принятии решений, а обслуживает тот же трафик, считает какие-то выводы, и эти выводы где-то хранятся.
Легкое повторное использование.
Многие задачи имеют схожие компоненты, особенно те, которые связаны с извлечением признаков или правилами.
Мы хотим перетащить эти компоненты в другие конвейеры.
Что ты решил сделать?
Сначала нам нужен мониторинг.И есть два типа этого.
Мониторинг
Технический мониторинг.Если развернуты какие-то компоненты конвейера, в работе они должны видеть, что происходит с компонентом: как он потребляет память, ЦП, диск.
Мониторинг бизнеса.
Это инструмент Data Scientist, который позволяет абстрагироваться от технических нюансов реализации.
На уровне проектирования и построения это помогает определить, какие метрики модели должны быть доступны для мониторинга, например, распределение признаков или результаты службы скоринга.
Специалист по данным определяет метрики и не должен беспокоиться о том, как они попадут в систему мониторинга.
Важно лишь то, что он определил эти метрики и внешний вид дашборда, на котором метрики будут отображаться.
Потом специалист запустил все в продакшн, развернул, и через некоторое время метрики потекли в мониторинг.
Таким образом, специалист по данным, не имеющий доступа к продукту, может видеть, что происходит внутри модели.
Тестирование
Тест конвейер для согласованности .Учитывая специфику конвейера, это своего рода вычислительный граф.
Мы хотим понять, что граф реализуем, мы можем обойти его и найти выход из него.
Граф имеет компоненты — модули.
Все модули должны пройти модульное и интеграционное тестирование.
Процесс должен быть прозрачным и простым для специалиста по данным.
Разработчик описывает модель и тестирует сам или с чьей-либо помощью.
Размещает все в Gitlab, пайплайне, настраивает Continuous Integration, поднимает, тестирует, видит результаты.
Если все хорошо, он идет дальше, если нет, то начинает заново.
Специалист по данным сосредоточен на модели и не знает, что находится под капотом.
Для этого ему дается несколько вещей.
- API для базовой интеграции сама система через шину данных – шину сообщений.
В этом случае специалисту необходимо описать, что входит на вход и что выходит из его модели, точку входа и точку соединения с разными компонентами внутри конвейера.
- После обучения модели появляется артефакт — файл XGBoost или соленый огурец .
У датасайентиста есть исполнитель для работы с артефактами — он должен интегрировать внутри себя компоненты конвейера.
- Простой и прозрачный API для специалистов по анализу данных, позволяющий контролировать работу компонентов конвейера — технический и бизнес-мониторинг.
- Простая и прозрачная инфраструктура для интеграции с источниками данных и сохранения результатов работы.
Аудит хочет проверить правильность работы и отсутствие мошенничества с нашей стороны.
Нужны простые инструменты, чтобы любой аудитор, знающий SQL, мог зайти в специальный репозиторий и посмотреть, как все работало, какие решения были приняты и почему.
Мы заложили основу для двух важных для нас историй.
Путешествие клиента.
Это возможность использовать механизмы сохранения всей истории клиента — того, что происходило с клиентом в рамках бизнес-процессов, которые реализованы в этой системе.
У нас могут быть внешние источники данных, такие как платформы DMP. От них мы получаем информацию о поведении людей в сети и на мобильных устройствах.
Это может повлиять на LTV моделей и модели оценки.
Если заемщик не выполняет платеж, мы можем предсказать, что здесь нет злого умысла, а есть только проблемы.
В этом случае мы используем мягкие методы воздействия на заемщика.
Когда проблемы будут решены, клиент закроет кредит. Когда он придет в следующий раз, мы узнаем всю его историю.
Специалист по данным извлечет из модели визуальную историю и проведет оценку в облегченном режиме.
Обнаружение аномалий .
Мы постоянно сталкиваемся с очень сложным миром.
Например, слабые места при ускоренной оценке МФО могут стать источником автоматического мошенничества.
Customer Journey — это концепция быстрого и легкого доступа к потоку данных, проходящих через модель.
Модель позволяет легко обнаружить аномалии, характерные для мошенничества в момент его массового возникновения.
Как все это работает?
Не долго думая, мы взяли Кафка как патч шины сообщений.Это хорошее решение, которым пользуются многие наши клиенты; оперативная группа знает, как с этим работать.
Некоторые компоненты системы могут уже использоваться внутри самой компании.Хранилище данных в данном случае это хранилище, которое обычно уже имеется у клиента.Мы не строим систему с нуля, а переиспользуем то, что уже есть.
Это может быть Hadoop, реляционные и нереляционные базы данных.
Мы можем сразу же работать с HDFS, Hive, Impala, Greenplum и PostgreSQL. Мы рассматриваем эти складские помещения как источник для витрин.
Данные поступают на склад и проходят через наш ETL или ETL клиента, если он у них есть.
Мы строим витрины, которые затем используются внутри моделей.
Мы используем хранилище данных в режиме только для чтения.
Наши разработки
Доска.Название взято из одной довольно странной практики математиков 30-40-х годов.
Это менеджер пайплайнов, которые живут в админке.
У Blackboard есть нечто под названием Meta Storage. В нем хранятся сами пайплайны и конфигурации, необходимые для инициализации всех компонентов.
Вся работа системы начинается с Blackboard. Каким-то чудом конвейер оказался в Meta Storage, через некоторое время Blackboard это понимает, вытаскивает текущую версию конвейера, инициализирует его и отправляет сигнал внутрь Kafka. Есть Среда выполнения .
Он построен на Docker и может быть реплицирован на серверах, в том числе в частном облаке клиента.
Основной выходит из коробки Актер::Init является инициализатором.
Это джинн, который может делать только две вещи: строить И уничтожить компоненты .
Он получает команду от Blackboard: «Вот конвейер, его нужно запустить на таких-то серверах с такими-то ресурсами в таком-то количестве — работайте!» Дальше все начинается с актера.
Математически актор — это функция, которая принимает на вход один или несколько объектов, внутренне изменяет состояние объектов по определенному алгоритму, а на выходе генерирует новый объект или изменяет состояние существующего.
Технически актор — это программа Python. Он работает в контейнере Docker со своей собственной средой.
Актер не знает о существовании других актеров.
Единственная сущность, которая знает, что кроме актора есть весь конвейер в целом, — это Blackboard. Он отслеживает статус исполнения всех участников системы и поддерживает актуальное состояние, которое выражается в мониторинге как картины всего бизнес-процесса в целом.
Actor::Init порождает множество контейнеров Docker. Кроме того, актеры могут работать с хранилищем данных.
Сама система имеет компонент Хранение событий .
Мы используем его как хранилище событий.
Кликхаус .
Его задача проста: вся информация, которой обмениваются актеры через Kafka, хранится в ClickHouse. Готово для дальнейшего аудита .
Это журнал работы трубопровода.
Актеры также могут быть спроектированы так, чтобы Путь клиента .
Они видят изменения в журнале конвейера и могут на лету перестроить витрины, необходимые моделям или компонентам для работы с правилами, уже внутри конвейера.
Это непрерывный процесс изменения данных.
Мониторинг довольно примитивно построен на Прометей .
Актеру предоставляется базовый API, и в приватном, но достаточно прозрачном для разработчика режиме он отправляет сообщения с метриками в Kafka. Prometheus считывает метрики из Kafka и сохраняет их в своем хранилище.
Для визуализации мы используем Графана .
Две точки интеграции
Первый — это точка интеграции с источниками данных, которые передаются через ETL в хранилище данных.Вторая точка интеграции — это когда сервис уже используется потребителем данных, например сервис скоринга.
Мы взяли Апач Сервисмикс.
По опыту эти точки интеграции однотипные с однотипными протоколами: SOAP, RESTful и реже очереди.
Мы не хотим каждый раз разрабатывать собственный конструктор или сервис для создания другого SOAP-сервиса.
Поэтому мы берем ServiceMix и описываем его на SDL, в котором построены модели данных этого сервиса и существующие в нем методы.
Затем мы помещаем маршрутизатор внутрь ServiceMix, и он сам генерирует сервис.
От себя мы добавили хитроумное синхронно-асинхронное преобразование.
Все запросы, находящиеся внутри системы, являются асинхронными и проходят через шину сообщений.
Большинство скоринговых сервисов являются синхронными.
Запросы ServiceMix поступают через REST или SOAP. В этот момент он проходит через наш шлюз, в котором хранятся сведения о HTTP-сессии.
Затем он отправляет сообщение Kafka, оно проходит через какой-то конвейер и генерируется решение.
В этом случае решения может еще не быть.
Например, что-то отвалилось, или существует жесткий SLA для принятия решения, и Gateway следит: «ОК, я получил запрос, он мне пришел в другой теме Kafka, или я ничего не получил, но мой таймаут триггер сработал».
Далее снова происходит преобразование из синхронного в асинхронное, и в рамках той же HTTP-сессии потребителю отправляется ответ с результатом работы.
Это может быть ошибка или обычный прогноз.
В этом месте мы, кстати, съели невкусную собаку благодаря великому и могучему Open Source. Мы использовали одну из последних версий ServiceMix и предыдущие версии Kafka, и все работало отлично.
Мы писали в этом шлюзе на основе кубов, которые уже были в ServiceMix. Когда вышла новая версия Kafka, мы ухватились за нее, но оказалось, что существовавшая ранее поддержка Kafka заголовков сообщений изменилась.
Шлюз внутри ServiceMix больше не может с ними работать.
Мы потратили много времени, чтобы понять это.
В результате мы создали собственный шлюз, который умеет работать с новыми версиями Kafka. Мы написали разработчикам ServiceMix о проблеме и получили ответ: «Спасибо, мы обязательно посочувствуем вам в следующих версиях!» Поэтому мы вынуждены следить за обновлениями и регулярно что-то менять.
Инфраструктура — Gitlab. Мы используем в нем практически все.
- Репозиторий кода.
- Продолжается интеграция/продолжается конвейер доставки.
- Реестр для ведения реестра Docker-контейнеров.
Компоненты
Мы разработали 5 компонентов:- доска — управление жизненным циклом трубопровода.
Где, что и с какими параметрами запускать из конвейера.
- Экстрактор функций Работает это просто — мы сообщаем Feature Extractor, что получаем на вход такую-то модель данных, выбираем из данных нужные поля и сопоставляем их с определенными значениями.
Например, мы получаем дату рождения клиента, преобразуем ее в возраст и используем в качестве признака в нашей модели.
Экстрактор функций отвечает за обогащение данных.
- Механизм, основанный на правилах — проверка данных по правилам.
Это простой язык описания, позволяющий человеку, знакомому с построением
если еще блоки для описания правил, которые необходимо проверить в системе. - Механизм машинного обучения — позволяет запустить исполнителя, инициализировать обученную модель и подать ее в качестве входных данных.
На выходе модель принимает данные.
- Механизм принятия решений — механизм принятия решений, выход из графика.
Имея каскад моделей, например, разных ветвей оценки заемщика, вы должны в какой-то момент принять решение о выдаче денег.
Набор правил решения должен быть простым.
Например, у нас есть анализ модели LTV — прогноз заработка определенной суммы денег, если прогнозируемая сумма меньше порога, то ответ отрицательный.
Пример работы
Рассмотрим пример скорингового сервиса с двумя наборами входных данных.Первый – это анкета заемщика, которую он заполняет сам.
Второе — кредитная история из кредитного бюро, которая говорит о его финансовой дисциплине.
Вот как выглядит конвейер в этом синтетическом примере.
- Разработчик описывает Экстрактор функций : какие особенности, какие данные мы извлекаем из анкеты и кредитной истории и в каком виде подаем их в модель.
- Список правил .
Например, проверка стоп-факторов: реальность паспорта, срок действия, действительная дата рождения и возраст старше 18 лет.
- Описано набор моделей.
В зависимости от типа заемщик оценивается по разным моделям.Если разработчик предлагает другую модель, использующую результаты предыдущей модели, он также описывает ее здесь и вставляет в конвейер.
- Сформированный Механизм принятия решений .
В нем описаны правила принятия решений на основе результатов моделей и правил.
- Генерируется решение .
Итак, мы сделали это, используя текстовый редактор и язык yaml. Разработчик пайплайна, описывая все компоненты, указывает их тип: экстрактор функций, правила, модели, механизм принятия решений, его название и версию.
Это важно - контейнер Docker генерируется на основе имени и версии .
Это ссылка на реестр, в котором находятся контейнеры Docker. Инициализирующий актер, который их вызывает, называется этим именем.
Поэтому, если вы допустите ошибку, то при сборке будет создан Docker-контейнер с таким именем, который останется на века.
Трубопровод
Нам хотелось сделать все быстрее, поэтому мы начали писать в Питон — мы его знаем и умеем на нём быстро писать.Экстрактор функций, правила, модели и механизм принятия решений были созданы на Python. Трубопровод натянут ямл.
Мы еще не завершили сохранение описания системного окружения в метахранилище — это делается Руки .
Если среда выполнения реплицируется на 10 серверах, Blackboard должна знать, что она должна запустить этот конвейер на 10 серверах.
Вы можете указать, где и какие именно компоненты запускать: серверы, правила, IP-адреса для точки входа Kafka, порты, топики.
На данный момент все это делается вручную.
Все артефакты сохраняются в GitLab. Развертывание и первоначальная подготовка выполняются Ansible. Оказалось, что это сложный процесс.
Условно большую инфраструктуру на пару десятков серверов можно развернуть за несколько часов, но наш инженер по эксплуатации написал для этого 50 000 строк Ansible-кода.
Как выглядит развертывание?
У GitLab есть конвейер.Разработчик привержен GitLab. CI увидел процесс, заметил новый артефакт, провел тесты, выдал результаты.
Далее идет GitLab Раннер В нем конструируются Docker-контейнеры для всех компонентов, которые описаны в пайплайне.
Если получится собрать, то все сохранится в Реестре.
Преимущество Docker в том, что мы избавляемся от проблем с версионированием.
Каждый Docker-контейнер имеет свою версию необходимых библиотек для каждого компонента.
В результате CI-конвейер сохраняет само описание конвейера в бизнес-процессах в Meta Storage, с которым работает Blackboard. Blackboard регулярно просматривает Meta Storage — видел новые изменения, получал их, проверял, отправлял сообщения инициализирующему субъекту.
Он вытащил Docker-контейнер и через несколько минут скопировал его, поднял и запустил.
Инициализирующий актор получает от Blackboard из Meta Storage все необходимые для запуска параметры конфигурации: подключения к базе данных, к Kafka, к системе мониторинга.
Любая информация, которая должна быть настраиваемой, о которой Docker-контейнер изначально ничего не знает, поступает в момент инициализации.
Загорелась лампочка, в мониторинге появились Docker-контейнеры, загорелись — конвейер готов! Изначально мы все разрабатывали в DigitalOcean. Потом мы научились деплоить на AWS и Scaleway, но последнее нам не очень нравится.
Для наших клиентов главное, чтобы все это могло вращаться в пределах своего периметра.
Весь трубопровод и вся его инфраструктура могут находиться под контролем заказчика.
Гарантия отсутствия протечек.
Это вообще быстро?
Трудно оценить – формальные критерии непросты.Например, самый сложный конвейер, который мы делали для запросов в реальном времени, был таким.
- 2 Экстрактор входных данных.
Размер данных чуть меньше 1 МБ, т.е.
json с огромным количеством данных.
- 8 моделей - 8 экземпляров двигателя ML. Все они были основаны на XGBoost.
- 18 блоков наборов правил в движке РБ (115 ФЗ).
Блоки содержат 1000 правил проверки на отмывание денег.
- 1 механизм принятия решений
Благодаря 2 экстракторам функций, 8 моделям, 18 блокам и 1 механизму принятия решений принятие решений занимает в среднем 1,2 секунды.
Планы
Ресурсы открытия.Автоматически отследить, что некоторые сервера отвалились, невозможно.
В процессе развертывания мы обнаруживаем, что сервер вышел из строя в момент развертывания.
В настоящее время мы работаем над решением.
Все ресурсы в Meta Storage мы описываем вручную.
Визуальное проектирование трубопровода .
Мы хотим реализовать какой-то движок, например БПМ .
С его помощью разработчик не будет писать на yaml с кучей синтаксических и орфографических ошибок, а будет визуально перемещать кубики, получать из репозитория уже готовые и рисовать.
Поддержка актеров на других языках.
Сейчас ради эксперимента пишем актор на Java, Scala, R. Само ядро на Python, но актор выполняется независимо от всей системы, а язык может быть любой.
Достаточно предоставить набор API на других языках, чтобы разработчик пайплайна мог писать актеров на знакомом языке.
Каков результат?
Разработка первой версии заняла месяц работы двух человек.До продуктового решения еще полгода работы.
Как результат получил конструктор , которым они сами научились пользоваться с трудом.
С трудом, потому что образ дизайнера требовал нескольких итераций и подходов.
Все описанное выше — это его состояние по состоянию на ноябрь 2018 года.
Пытаясь работать с конструктором, мы столкнулись с интересными проблемами, обошли их и научились с ними работать.
И не зря – жизнь становится проще и нам, и клиентам, пользующимся конструктором.
Процесс понятен как разработчикам, так и операторам.
.
Мы избежали многих проблем, связанных с тем, как запустить этот несчастный ноутбук в производство, как отслеживать и развертывать модель.
Например, это то, что я имел в виду, когда сказал что существует пропасть между идеальным алгоритмом в вакууме и его применением.Теги: #Машинное обучение #программирование #Высокая производительность #Анализ и проектирование систем #наука о данных #gitlab #pipeline #usedataconf #xgboostПриглашаю тех, кто уже научился это преодолевать, представить отчет на UseData Конф.
.
А для тех, кто хочет узнать больше о том, как машинное обучение используется в практических задачах, посетите конференцию 16 сентября.
-
Любопытство Сделало Автопортрет
19 Oct, 24 -
Новая Опера – Новый Пожиратель Памяти
19 Oct, 24 -
Вы Неправильно Пишете Животных
19 Oct, 24
