Пользователь
Недавно ко мне обратились знакомые, которые активно впиливали LLM в своей продукт, однако их смущала стоимость такого решения - они платили около 8$/час за Huggingface inference Endpoint 24/7, на что уходили просто невиданные ~100 тысяч долларов в год. Мне нужно было заресерчить какие есть способы развертывания больших текстовых моделей, понять какие где есть проблемы и выбрать оптимальных из них. Результатами этого ресерча и делюсь в этой статье)
Инференсом ML-модели называют процесс её работы на конечном устройстве. Соответственно, чем больше мы разгоняем инференс, тем быстрее работает модель. Скорость может зависеть от разных условий, например, от архитектуры, которую вы выбрали для модели, или от железа, на котором работает устройство. Кроме того, проблема тяжёлого инференса остро ощущается на больших языковых моделях (LLM) так остро, как ни на каких других моделях.
Меня зовут Роман Горб, я старший ML-разработчик в команде YandexGPT. Тема инференса LLM заинтересовала меня, потому что я занимался R&D в квантовании сеток для CV-задач. Сегодня я расскажу, как безболезненно увеличить скорость инференса. Сперва разберёмся, зачем это нужно, а потом рассмотрим разные методы ускорения и фреймворки, которые могут в этом помочь.
В последнее время большие языковые модели (Large Language Models, LLM) стали невероятно популярными — кажется, их обсуждают везде, от школьных коридоров до Сената США. Сфера LLM растёт бурными темпами, привлекая внимание не только специалистов в области машинного обучения, но и обычных пользователей. Кто-то высказывает массу опасений насчет их дальнейшего развития, а кто-то и вовсе предлагает бомбить дата-центры — и даже в Белом Доме обсуждают будущее моделей. Но неужели текстом можно кому-то навредить? А что если такая модель приобрела бы агентность, смогла создать себе физическую оболочку и полностью ей управлять? Ну, это какая-то фантастика из (не)далёкого будущего, а про агентов нашего времени я расскажу в этой статье. И не переживайте — знание машинного обучения вам не понадобится!
Заглянуть в будущее
Когда мы хотим рассчитать количество звонков в колл-центр через час, поставить в пятничную смену достаточно курьеров или предсказать потребление электроэнергии небольшим городком через 5 лет, мы обращаемся к теме обработки временных рядов. На тему обработки timeseries (временной ряд, англ.) написано множество статей и создано несчетное количество часов видео. Но попробуйте задать поисковой системе вопрос: как работать с временными рядами. Уверен, вы закопаетесь в многообразии ссылок, похожих по смыслу и содержанию. Однако, ни одна из них не ответит на вопрос полностью. Авторы выдают два или три метода обработки как панацею от всех проблем в работе со временем.
Мы попробуем собрать в одной статье все классические и современные методы обработки даты и времени.
Разберем случай, когда в нашем распоряжении имеются только даты с количеством завершенных событий. В ежедневных задачах прогнозирования мы можем подгрузить дополнительные данные или иметь в своем распоряжении сразу несколько показателей для временного периода. Мы же будем извлекать максимум данных из даты и единичного значения целевого события.
TL:DR
Основная цель статьи – создание новых признаков из временных периодов для решения бизнес-задач. Информация будет полезна новичкам и специалистам, которые редко работают со временными рядами. К тексту прилагается заметка на kaggle. Вы можете изучать статью и одновременно выполнять код. Мы не будем строить графики и рассматривать особенности временных рядов.
Ничего личного – просто бизнес
Прогнозирование временных рядов — это достаточно популярная аналитическая задача. Прогнозы используются, например, для понимания, сколько серверов понадобится online-сервису через год, каков будет спрос на каждый товар в гипермаркете, или для постановки целей и оценки работы команды (для этого можно построить baseline прогноз и сравнить фактическое значение с прогнозируемым).
Существует большое количество различных подходов для прогнозирования временных рядов, такие как ARIMA, ARCH, регрессионные модели, нейронные сети и т.д.
Сегодня же мы познакомимся с библиотекой для прогнозирования временных рядов Facebook Prophet (в переводе с английского, "пророк", выпущена в open-source 23-го февраля 2017 года), а также попробуем в жизненной задаче – прогнозировании числа постов на Хабрехабре.
Привет, Хабр! Поговорим о RecSys?
Что нужно для построения рекомендательной системы, которая будет полезна бизнесу? Топовые метрики, максимум предсказательной силы, machine learning на полную? Проверим. Сегодня покажу:
• Как (и почему) мы дропнули в 3 раза ранжирующие метрики в пет-проекте по рекомендациям фильмов
• Как искали свой идеальный алгоритм
• Как подобрали релевантные рекомендации на самые разные запросы
Будем говорить обо всех аспектах экспериментов в RecSys: метрики, визуальный анализ, workflow. А результат проверим в онлайн-приложении.
Привет, я Галина Вакулина, лидер аналитиков в Точке.
В новой компании аналитик тратит много времени на изучение данных, с которыми ему предстоит работать. В этой статье я рассказываю, как мы построили процесс онбординга, чтобы погружение новичка проходило эффективно и безболезненно.
Однажды мне понадобилось внедрить метрики в сервисы своей команды. С самого начала я не понимал, что именно хочу получить: одно дело — прикрутить библиотеку и нарисовать графики, другое дело — показывать осмысленные данные.
Мне нужен был гайд, который сочетает эти две вещи: сначала «почему так принято», а затем — «как правильно делать». В результате такой гайд мне пришлось написать самому. Его цель — объяснить разработчикам с любым бэкграундом, что такое метрики, как правильно о них думать и осмысленно использовать. Сначала гайд жил во внутренней документации Точки, но я решил сделать его публичным — возможно, кому-то этот опыт будет полезен. Разбираться будем с Prometheus и Grafana. Если у вас другой стек — не страшно. Мы затронем и фундаментальные темы: например, перцентили, производные и кардинальность.
Гайд будет выходить как цикл статей. Сначала посмотрим на архитектуру: как собираются метрики и где хранятся. Дальше разберемся с типами метрик — они не так просты, как кажется. Потом придется немного отвлечься на математику (но только с инженерной точки зрения!). И, наконец, научимся писать запросы, но не просто так: сразу посмотрим на разные грабли и неочевидные моменты.
Это вторая статья из цикла. В первой, вводной, я рассказывал, как устроены метрики для сервисов, чем отличаются от логов, и какую задачу вообще решают. Теперь подробнее про то, как их готовить.
Под катом: формат данных, способы отправки, типы метрик и их применение, кардинальность.
Привет, Точка на связи! Аналитик Никитин Александр и Head of ML Андрей Румянцев разобрались как с помощью машинного обучения смерджить несколько наборов данных из открытых источников и не сойти с ума. Open data, TF-IDF, faiss, pgvector, трансформеры и удивительное завершение нашего приключения — всё это под катом.
Привет, с вами Данил Губанов — backend-разработчик в Точке. Сегодня я расскажу о сервисах, которые позволяют разработать целое приложение, при этом не требуя кода. В этой статье я буду говорить о Glide и Lucidchart, а во второй части материала расскажу про Google Sheets и Notion. Почему я буду рассказывать о них? Потому что они простые и доступные. С их помощью я за несколько часов смог создать телеграм-бота и небольшое приложение с админкой без единой строчки кода.
Прежде всего этот пост для джунов и тех, кто хочет быстро создавать и тестировать MVP без привлечения разработчиков. Если вы опытный айтишник со стажем, то вряд ли узнаете что-то новое для себя.
Привет, я Михаил Ковалев, Python-разработчик в Точке.
Именно в Точке я впервые столкнулся с микросервисами и конкурентной средой. Разумеется, у меня не получилось сразу усвоить все боевые нюансы работы в новых условиях. С тех пор я прошёл непростой путь.
У меня возникла идея написать свой цикл статей. Мы разберемся, как у наших сервисов получается не запутаться в непрерывном потоке информации — как получаемой от клиентов, так и передаваемой между собой.
В этой статье я широкими мазками опишу, как рядовой разработчик видит инфраструктуру Точки, с какими проблемами мы регулярно сталкиваемся и почему нам так важна консистентность данных
Всем привет, и с вами снова Данил Губанов — backend-разработчик в Точке. В этом материале я расскажу об инструментах, с которыми можно быстро сделать лендинг с формами, создать таблицу и даже разработать приложение для психологической помощи (и всё это без кода). Речь пойдет про Notion и Google Sheets. Поехали!
В прошлой статье я рассказал о конкурентной среде в Точке и типовых проблемах, с которыми сталкиваются разработчики. В этот раз речь пойдёт о том, как же можно эту консистентность реализовать и какие злые силы нам могут помешать это сделать. Решил больше не делить статьи на части, поэтому продолжение вот в этой большой статье, всё в одном месте.
Напомню, что текст рассчитан в первую очередь на разработчиков, которые имеют мало практического опыта работы в конкурентной и/или микросервисной среде, поэтому многие вещи я объясню на пальцах. Для тех, кто захочет ознакомиться с более строгими формулировками, сразу скажу, что здесь будут затронуты упрощённые идеи паттернов Transactional Outbox и Saga.
Каждый, кто занимался сбором данных во «внешнем мире» знает, что этот мир жесток. И парсер сторонних сайтов всегда может наткнуться на какие-то блокировки, задержки и множество других проблем, которые либо замедляют работу, либо вообще делают парсинг невозможным. Лимиты по IP и капча — нам не друзья. Поэтому было решено сделать инструмент, позволяющий с ними бороться.
Всем привет. Меня зовут Артур. Готовясь к выступлению на внутреннем митапе по теме особенности алгоритмов у CatBoost и LightGBM, я понял, что не смог найти единого места, где были бы понятным языком рассказаны основные особенности того, что алгоритмически работает под капотом у CatBoost и LightGBM. Причём не формальные записи алгоритмов на псевдокоде, а понятные пошаговые инструкции. Так появилась эта статья.
Сейчас в Альфа-Банке при построении моделей используется множество различных источников данных. Мы в Лаборатории машинного обучения уже несколько лет применяем нейронные сети на последовательностях для решения задачи кредитного скоринга и построили модели на данных карточных транзакций, транзакций расчетного счета и кредитных историй. Повышение качества в задаче кредитного скоринга позволяет банку выдавать большее количество кредитов при неизменном уровне риска, что напрямую влияет на его прибыль.
Моделей становится все больше, и возникает вопрос: почему бы нам не смешивать модели не на уровне их предсказаний, а на некотором более низком уровне? Эта идея приводит нас к новому способу смешивания - построению единой нейросетевой модели, работающей со всеми источниками последовательных данных и учитывающей их взаимное влияние друг на друга. В этой статье мы расскажем, как нам удалось разработать такую модель и каких результатов она позволяет добиться в задаче кредитного скоринга.
