Наш специалист по данным, Давиде, и серверный разработчик, Пьетро, рассказывают, как они повышают эффективность предсказаний на основе машинного обучения crystal (спойлер: это круто)
Есть несколько жизненно важных ингредиентов, позволяющих сдвинуть с мертвой точки службу прогнозирования. Но прежде чем мы перейдем к нашему проекту, давайте начнем с основ:
Что такое «прогноз»?
Прогнозирование - это процесс прогнозирования или оценки будущей тенденции или события, основанный в основном на данных наряду с анализом тенденций.
Но ... как вы на самом деле прогнозируете?
Проще говоря: к набору данных применяется модель машинного обучения, которая затем дает результаты. Звучит довольно просто, правда?
Хорошо ... что вы подразумеваете под службой прогнозов?
Это микросервис, который после получения запроса на ввод (от пользователей или других служб) отвечает, применяя модель к последним доступным данным вместе с другими параметрами, которые могут быть установлены пользователем.
Хорошо ... но как вы можете использовать его для нескольких проектов?
Что ж, теперь вы об этом просили! Выпейте и устройтесь поудобнее. Это может быть технически, но также весело 😉.
Итак, в чем была специфика нашего проекта?
Что нам было нужно?
Решение, которое может быстро создавать прогнозы для самых разных проектов огромного масштаба. Обычно задачи, выполняемые специалистами по данным, в значительной степени зависят от спецификаций проекта и отнимают много времени. Нам нужно было это изменить.
Асинхронное обучение и динамические данные
Основная цель этого проекта - создать систему прогнозирования, которая после получения источника данных (пользователем, компанией или организацией) возвращает прогноз с некоторым подходящим числовым индикатором его вероятности.
Чтобы сделать это не только полезным, но и полезным, нам пришлось выполнять этап обучения асинхронно (чтобы любая операция, связанная с ним, не приостанавливала весь процесс).
Мы также должны были заставить его учиться постоянно, передавая ему данные в реальном времени. Это позволит с каждым днем становиться лучше и точнее.
Для этой задачи мы приняли принцип дизайна разделение задач (как объяснил Талин, здесь), разделив его на разные модули, чтобы сделать его тестируемым и масштабируемым. и поправляемый.
Король моделей
Секрет в том, чтобы автоматизировать этап выбора модели.
Что мы сочли очень полезным, так это создать конкуренцию между моделями. Каждая модель конкурирует друг с другом на основе общей оценочной метрики. Затем модель, получившая наибольшее количество баллов, отправляется в производство. Таким образом, мы могли сделать все автоматизированным и плавным.
Мы достигли этой цели, написав классы модели таким образом, чтобы они предоставляли один и тот же интерфейс. Каждой модели нужны данные в определенной форме, поэтому мы решили перенести этап обработки в саму модель.
В конце концов, каждая модель принимает один и тот же ввод и производит один и тот же вывод (по крайней мере, форма вывода остается той же). Это позволило нам ускорить и автоматизировать цикл оценки модели.
Ввод в реальном времени и время отклика
Входы - это серьезное дело: пользователь может в любой момент запросить прогноз!
Очевидно, что если вы хотите, чтобы люди использовали ваше приложение, вы должны дать им ответ быстро - например, в режиме реального времени. Мы достигли этого, загрузив экземпляр обученной модели в память, поэтому мы смогли резко сократить время отклика e. Кроме того, пользователь может запросить сложный прогноз. Приведем два примера с кристаллом (вы, кстати, уже встречали кристалл, первый продукт iGenius?):
Пользователя интересует общее количество посещений его веб-сайта. Вот еще один пример:
Здесь пользователь добавляет больше контекста к своему вопросу. Они добавили источник посещения в качестве измерения - просто еще один значок «x» во входном векторе.
Поэтому мы приняли это правило для применения во время обучающей фразы - мы должны искать разумные значения по умолчанию для каждого измерения, которое пользователь может или не может использовать.
Микросервисы и отсутствие простоев (кластер услуг)
Лучший способ масштабировать и поддерживать весь проект - это структурировать его в соответствии с архитектурой микросервисов. По сути, это позволило нам создать кластер, чтобы служба не простаивала и всегда была доступна вместе с большей гибкостью.
Поскольку служба имеет более одной реплики, все потенциальные проблемы, которые могут возникнуть в одном экземпляре службы, будут устранены, не затрагивая другие экземпляры.
Узнайте об архитектурах микросервисов в классной статье Hashmap.
Подводя итоги
Невозможно найти идеальное решение для каждого проекта, но некоторые ингредиенты должны присутствовать всегда. Точнее три:
❶ Асинхронные обучающие модели
❷ Стандартизированная модель интерфейса
❸ Кластер, обеспечивающий постоянную доступность сервиса
Вам нравится, как мы работаем? "Увлекаться".
