Я верно понимаю, что вы просто использовали евклидовый matching по признакам (с учетом того, что это приближенный поиск, коль речь про FAISS) ? Или есть какие-то особенности решения?
Это качественное исследование? Клево было бы на метрики еще глянуть (но нужна разметка, это да).
И с промптами похимичить бы (возможно, получится исправить часть проблем).
И еще немаловажный момент: какие из моделей умеют в структурированный вывод (и насколько хорошо следуют условной инструкции "ответь в формате json с такими-то полями"). В больших модельках не сомневаюсь, а вот к моделям поменьше могут быть вопросики.
Да, именно так. Своего рода дистилляция получается. В основном, мы обучаем более легкую и простую модельку, которая будет работать быстрее и использовать меньше ресурсов, чтобы сэкономить.
Впрочем, для некоторых специфичных кейсов (медицина, юриспруденция и т.п.) может еще быть так, что LLM будет хуже справляться, чем отдельная моделька с отдельно собранной специфичной разметкой. Но в таком случае и разметка от LLM будет только заготовкой. Так что все равно придется прилично потрудиться над разметкой (но небольшое ускорение возможно, полагаю). Но это скорее специфичный случай, основной вариант я описал выше.
Это те же рекомендации, но с учетом особенностей ритейла (что люди закупаются "корзинами" с некоторой периодичностью и наполнением). То есть, мы рекомендуем не единичные товары, а сразу некоторое множество (которое в себе предполагает какую-то логичную компоновку, например, учитывает, что для салата нужны не только огурцы, но еще хорошо бы взять и другие овощи).
Получается, что это все та же задача рекомендаций, но более общей сущности (целой корзины вместо товара).
А использовать это можно для того, чтобы посоветовать что-то, что вполне могло быть в корзине пользователя, но этого почему-то нет (например, пользователь постоянно покупает йогурты, а сегодня как назло забыл про это).
Но, конечно, это будет тащить за собой некоторые предположения (например, что у нас пользователь может набирать разные корзины в разные моменты времени). И, полагаю, еще будет иметь не только плюсы, но и минусы (ошиблись с предполагаемой корзиной - ухудшили рекомендации по сравнению с рекомендацией отдельных единичных товаров).
А как обновляются пороги? Если мы жестко "прибили гвоздями" константы, то со временем они могут устареть. И качество модели упадет.
Сюда же чуть более сложный вопрос. Предположим, что наши подсказки в моменте улучшили метрики. Но что, если мы просто временно сдвинули равновесие условного "рынка"? Что, если более успешные исполнители решат добавить еще что-то, что будет улучшать их метрики. Получим частичный возврат к исходному состоянию. Какие-то решения для этой проблемы продумывали?
Я выше писал, что у нас используются разные решения (как Open Source, так и проприетарные). Соответственно, для работы с чувствительными данными есть два варианта - работа с локальной моделью внутри инфраструктуры компании и подписание дополнительного соглашения с внешним сервисом (если компания в юрисдикции РФ).
В основном, мы используем первый вариант. То есть, для чувствительных данных используются модели внутри контура. А для менее чувствительных можно использовать и внешние модели.
Все как в жизни. Если модель русскоязычная, то она лучше понимает русский. Если же русский для нее не первый язык, то лучше все же общаться на английском. Например, есть исследования, которые говорят о том, что некоторые классы моделей "думают" на английском.
У нас в работе используется множество разных моделей (как Open Source, так и проприетарных).
Не сказал бы, что есть единый источник. Что-то мы поддерживаем сами, для каких-то моделей взаимодействуем с партнерами (например, YandexGPT, Гигачат). Для финального пользователя мы, конечно, все собираем в единое место, но это внутренний продукт с перманентным процессом обновления, т.к. постоянно выходит нечто новое.
Сервисы-прослойки мы не используем. Во многом, из-за корпоративных политик безопасности.
Но весьма вероятно, что в признаки для бустинга прокидывают исторические значения с некоторыми лагами (и это может быть как прошлый день, так и неделя, месяц, год).
Либо используют такие же классические статистические подходы (как и детекция тренда) на этапе коррекции предсказаний в отдельном модуле.
Изображение "Устройство KNN-классификатора" стоит поправить. На скриншот попало всплывающее сообщение, которое закрывает часть информации на этом изображении
Кажется, что совсем простую модель построили. Полагаю, туда еще можно было бы добавить много чего, к примеру: время на смене (сколько прошло с начала смены), насколько доставщик опаздывает, количество заказов клиента (про важность этого проговорили сами ранее), насколько близок адрес к основным магистралям (а то может это частный сектор какой, куда подъехать сложнее) и т.п. Ну и еще можно предложить использовать средства гео-визуализации для анализа и отладки (чтобы смотреть на что-то кроме shapely). Как пример - Kepler.gl от Uber.
"Раскатить" от слова "катить". Например: "мы выкатили новые улучшения нашего сайта для всех пользователей". Получается, что мы выпустили некие обновления, которые теперь видны всем пользователям.
Насколько я вижу, именно в таком значении и используется данный оборот в тексте. Применить изменение ко всем нашим пользователям.
По открытиям для сравнения посчитал.
Просто кажется, что для вас это может и быть полезнее (отправок больше — оплата больше). Но для заказчика — не факт. Тут хорошо бы про их мотивацию рассказать (если это возможно). Нужно ли больше денег суммарно от кампании, или нужен выше доход на отправку?
Может одно письмо стоит 15 рублей (я условно, это преувеличение, конечно же). Тогда для заказчика рассылка по большей аудитории окажется убытком.
P.S. В целом, молодцы, конечно. Но LSTM вроде бы не такая нестандартная модель для такого рода задач.
P.P.S. Кажется, что вашу задачу можно дальше попробовать сформулировать в терминах uplift'а.
Значимость A/B теста на чем считали? Клики, открытия, покупки?
Кажется, что доход на отправку упал: 12000 / 470 = 25.5, а 102000 / 10600 = 9.6. Или 12000 / (470 * 0.2) = 127.67, 102000 / (10600 * 0.15) = 64.15, если считать не по отправкам, а по открытиям.
Спасибо за статью!
Я верно понимаю, что вы просто использовали евклидовый matching по признакам (с учетом того, что это приближенный поиск, коль речь про FAISS) ? Или есть какие-то особенности решения?
Спасибо за статью!
Это качественное исследование? Клево было бы на метрики еще глянуть (но нужна разметка, это да).
И с промптами похимичить бы (возможно, получится исправить часть проблем).
И еще немаловажный момент: какие из моделей умеют в структурированный вывод (и насколько хорошо следуют условной инструкции "ответь в формате json с такими-то полями"). В больших модельках не сомневаюсь, а вот к моделям поменьше могут быть вопросики.
Спасибо за вопрос!
Да, именно так. Своего рода дистилляция получается. В основном, мы обучаем более легкую и простую модельку, которая будет работать быстрее и использовать меньше ресурсов, чтобы сэкономить.
Впрочем, для некоторых специфичных кейсов (медицина, юриспруденция и т.п.) может еще быть так, что LLM будет хуже справляться, чем отдельная моделька с отдельно собранной специфичной разметкой. Но в таком случае и разметка от LLM будет только заготовкой. Так что все равно придется прилично потрудиться над разметкой (но небольшое ускорение возможно, полагаю). Но это скорее специфичный случай, основной вариант я описал выше.
Это те же рекомендации, но с учетом особенностей ритейла (что люди закупаются "корзинами" с некоторой периодичностью и наполнением). То есть, мы рекомендуем не единичные товары, а сразу некоторое множество (которое в себе предполагает какую-то логичную компоновку, например, учитывает, что для салата нужны не только огурцы, но еще хорошо бы взять и другие овощи).
Получается, что это все та же задача рекомендаций, но более общей сущности (целой корзины вместо товара).
А использовать это можно для того, чтобы посоветовать что-то, что вполне могло быть в корзине пользователя, но этого почему-то нет (например, пользователь постоянно покупает йогурты, а сегодня как назло забыл про это).
Но, конечно, это будет тащить за собой некоторые предположения (например, что у нас пользователь может набирать разные корзины в разные моменты времени). И, полагаю, еще будет иметь не только плюсы, но и минусы (ошиблись с предполагаемой корзиной - ухудшили рекомендации по сравнению с рекомендацией отдельных единичных товаров).
А как обновляются пороги? Если мы жестко "прибили гвоздями" константы, то со временем они могут устареть. И качество модели упадет.
Сюда же чуть более сложный вопрос. Предположим, что наши подсказки в моменте улучшили метрики. Но что, если мы просто временно сдвинули равновесие условного "рынка"? Что, если более успешные исполнители решат добавить еще что-то, что будет улучшать их метрики. Получим частичный возврат к исходному состоянию. Какие-то решения для этой проблемы продумывали?
Спасибо, что поделились вашим опытом!
Интересное наблюдение.
Спасибо за интерес к статье!
Вопрос отличный.
Я выше писал, что у нас используются разные решения (как Open Source, так и проприетарные). Соответственно, для работы с чувствительными данными есть два варианта - работа с локальной моделью внутри инфраструктуры компании и подписание дополнительного соглашения с внешним сервисом (если компания в юрисдикции РФ).
В основном, мы используем первый вариант. То есть, для чувствительных данных используются модели внутри контура. А для менее чувствительных можно использовать и внешние модели.
Спасибо за интерес к статье!
Все как в жизни. Если модель русскоязычная, то она лучше понимает русский. Если же русский для нее не первый язык, то лучше все же общаться на английском. Например, есть исследования, которые говорят о том, что некоторые классы моделей "думают" на английском.
Спасибо за интерес к статье!
У нас в работе используется множество разных моделей (как Open Source, так и проприетарных).
Не сказал бы, что есть единый источник. Что-то мы поддерживаем сами, для каких-то моделей взаимодействуем с партнерами (например, YandexGPT, Гигачат). Для финального пользователя мы, конечно, все собираем в единое место, но это внутренний продукт с перманентным процессом обновления, т.к. постоянно выходит нечто новое.
Сервисы-прослойки мы не используем. Во многом, из-за корпоративных политик безопасности.
В топ-18 два пункта совпадают (7 и 13). Либо это должен быть топ-17, либо что-то забыли и заменили уже внесенным пунктом
Это своеобразный жаргон специалистов по работе с данными. Наверное, на русский было бы наиболее правильно перевести словом "оценки".
А свойства как получали из фильмов? Автоматизированно, или они сразу идут в описании контента?
Не скажу наверняка, как реализовано у автора.
Но весьма вероятно, что в признаки для бустинга прокидывают исторические значения с некоторыми лагами (и это может быть как прошлый день, так и неделя, месяц, год).
Либо используют такие же классические статистические подходы (как и детекция тренда) на этапе коррекции предсказаний в отдельном модуле.
На слайде с детекцией тренда написано "детекция труда". Кажется, что это описка, стоит поправить.
Изображение "Устройство KNN-классификатора" стоит поправить. На скриншот попало всплывающее сообщение, которое закрывает часть информации на этом изображении
Кажется, что совсем простую модель построили.
Полагаю, туда еще можно было бы добавить много чего, к примеру: время на смене (сколько прошло с начала смены), насколько доставщик опаздывает, количество заказов клиента (про важность этого проговорили сами ранее), насколько близок адрес к основным магистралям (а то может это частный сектор какой, куда подъехать сложнее) и т.п.
Ну и еще можно предложить использовать средства гео-визуализации для анализа и отладки (чтобы смотреть на что-то кроме shapely). Как пример - Kepler.gl от Uber.
Из двух альтернатив (тест и контроль) выбрали тестовый вариант для того, чтобы его применить ко всем пользователям сервиса. То есть "раскатили тест".
"Раскатить" от слова "катить". Например: "мы выкатили новые улучшения нашего сайта для всех пользователей". Получается, что мы выпустили некие обновления, которые теперь видны всем пользователям.
Насколько я вижу, именно в таком значении и используется данный оборот в тексте. Применить изменение ко всем нашим пользователям.
Просто кажется, что для вас это может и быть полезнее (отправок больше — оплата больше). Но для заказчика — не факт. Тут хорошо бы про их мотивацию рассказать (если это возможно). Нужно ли больше денег суммарно от кампании, или нужен выше доход на отправку?
Может одно письмо стоит 15 рублей (я условно, это преувеличение, конечно же). Тогда для заказчика рассылка по большей аудитории окажется убытком.
P.S. В целом, молодцы, конечно. Но LSTM вроде бы не такая нестандартная модель для такого рода задач.
P.P.S. Кажется, что вашу задачу можно дальше попробовать сформулировать в терминах uplift'а.
Кажется, что доход на отправку упал: 12000 / 470 = 25.5, а 102000 / 10600 = 9.6. Или 12000 / (470 * 0.2) = 127.67, 102000 / (10600 * 0.15) = 64.15, если считать не по отправкам, а по открытиям.