Несколько месяцев назад я попытался бросить себе вызов и отправиться в путешествие по переходу от бэкграунда в аналитике данных к Data Engineering. До сих пор я построил в общей сложности два значимых реальных проекта, которые действительно научили меня чему-то полезному. Я построил пайплайн Git Hub ET L, который извлекает репозитории Git Hub и загружает их в базу данных SQLite — он работал по расписанию с использованием Git Hub Actions. Я также построил RSS-пайплайн, который извлекает статьи из RSS-каналов и сохраняет их в базу данных Kestra — оркестрируемый Kestra для запуска по почасовому расписанию. Теперь, когда я в определенной степени понял ET L, я хотел попробовать что-то новое. Я хотел продолжать практиковать всё, чему научился в прошлом, создавая что-то новое. Меня всегда увлекала область машинного обучения, но у меня никогда не было смелости в неё войти, потому что я думал, что там сложная математика. Больше нет. Недавно я построил модель прогнозирования оттока для вымышленной телекоммуникационной компании, которую я называю Northline Mobile (P.S. Я использую вымышленную компанию, потому что лучше всего понимаю вещи на реальных сценариях). Я предоставил ей данные 7043 клиентов, указав, подписались ли они на годовой контракт или ежемесячные планы, длительность клиента, ежемесячные платежи, дополнения и т.д. Кроме того, я указал, кто в итоге покинул Northline Mobile. Я перекрестно проверил модель на клиентах, которых она еще не видела. Она достигла точности 81%. Это научило меня всему, что входит в построение модели. Очевидно, я не понимал весь сложный код, потому что предпочитаю интуитивно понятные интерфейсы перетаскивания, а не сложный код. Но я понял основные строительные блоки создания модели; я объясню подробнее ниже с упрощенной архитектурой. Так что создание этой модели казалось победой с точки зрения машинного обучения; моя модель работала. Но все еще оставалась одна проблема: она все еще не была по-настоящему полезной. Предположим, сотрудник Northline, которому нужен прогноз, приходит ко мне, мне придется открыть Jupyter, загрузить нужный блокнот, запустить ячейки в правильном порядке и сделать ручной вызов predict_churn(). Да, модель существует, но я единственный, кто знает, как ею пользоваться. Больше никто в Northline не мог просто отправить информацию о клиенте в модель и получить прогноз, и она не могла взаимодействовать ни с каким другим приложением. Эта статья расскажет об этом. Недавно я узнал, что есть разница между наличием модели и наличием сервиса. Если модель просто находится в блокноте, только человек, который её создал, может ею пользоваться. Но превращение её в сервис позволяет всем использовать её — другие команды, приложения, дашборды и системы, которым не нужно знать или заботиться о том, как делается прогноз. Оказывается, построение модели машинного обучения было самой простой частью, но сделать её полезной — это еще один важный элемент, заслуживающий изучения. Что означало 'Готово' до APIВот примерно как выглядело построение модели: Это в значительной степени всё. Ничего слишком сложного. К концу этого у меня была обученная модель классификации оттока, пайплайн предварительной обработки, который очищал и кодировал необработанные данные, и показатели оценки, с которыми я был комфортен (подробнее об этих цифрах чуть позже, они не идеальны, и я не буду делать вид, что они идеальны). Но, как я уже сказал. Предположим, команда удержания Northline создает дашборд, и они хотят, чтобы он автоматически помечал клиентов из группы риска. Их дашборд не может обоснованно открыть мой блокнот Jupyter и запустить мои ячейки. Ему нужно что-то совершенно другое. Что-то вроде этого: Именно этот переход и описывается в данной статье. Одно быстрое предупреждение: это не туториал по Fast API. Fast API — это просто инструмент, который я использовал, чтобы предоставить модель как...