Я верно понимаю, что вы просто использовали евклидовый matching по признакам (с учетом того, что это приближенный поиск, коль речь про FAISS) ? Или есть какие-то особенности решения?
Это качественное исследование? Клево было бы на метрики еще глянуть (но нужна разметка, это да).
И с промптами похимичить бы (возможно, получится исправить часть проблем).
И еще немаловажный момент: какие из моделей умеют в структурированный вывод (и насколько хорошо следуют условной инструкции "ответь в формате json с такими-то полями"). В больших модельках не сомневаюсь, а вот к моделям поменьше могут быть вопросики.
Да, именно так. Своего рода дистилляция получается. В основном, мы обучаем более легкую и простую модельку, которая будет работать быстрее и использовать меньше ресурсов, чтобы сэкономить.
Впрочем, для некоторых специфичных кейсов (медицина, юриспруденция и т.п.) может еще быть так, что LLM будет хуже справляться, чем отдельная моделька с отдельно собранной специфичной разметкой. Но в таком случае и разметка от LLM будет только заготовкой. Так что все равно придется прилично потрудиться над разметкой (но небольшое ускорение возможно, полагаю). Но это скорее специфичный случай, основной вариант я описал выше.
Это те же рекомендации, но с учетом особенностей ритейла (что люди закупаются "корзинами" с некоторой периодичностью и наполнением). То есть, мы рекомендуем не единичные товары, а сразу некоторое множество (которое в себе предполагает какую-то логичную компоновку, например, учитывает, что для салата нужны не только огурцы, но еще хорошо бы взять и другие овощи).
Получается, что это все та же задача рекомендаций, но более общей сущности (целой корзины вместо товара).
А использовать это можно для того, чтобы посоветовать что-то, что вполне могло быть в корзине пользователя, но этого почему-то нет (например, пользователь постоянно покупает йогурты, а сегодня как назло забыл про это).
Но, конечно, это будет тащить за собой некоторые предположения (например, что у нас пользователь может набирать разные корзины в разные моменты времени). И, полагаю, еще будет иметь не только плюсы, но и минусы (ошиблись с предполагаемой корзиной - ухудшили рекомендации по сравнению с рекомендацией отдельных единичных товаров).
А как обновляются пороги? Если мы жестко "прибили гвоздями" константы, то со временем они могут устареть. И качество модели упадет.
Сюда же чуть более сложный вопрос. Предположим, что наши подсказки в моменте улучшили метрики. Но что, если мы просто временно сдвинули равновесие условного "рынка"? Что, если более успешные исполнители решат добавить еще что-то, что будет улучшать их метрики. Получим частичный возврат к исходному состоянию. Какие-то решения для этой проблемы продумывали?
Я выше писал, что у нас используются разные решения (как Open Source, так и проприетарные). Соответственно, для работы с чувствительными данными есть два варианта - работа с локальной моделью внутри инфраструктуры компании и подписание дополнительного соглашения с внешним сервисом (если компания в юрисдикции РФ).
В основном, мы используем первый вариант. То есть, для чувствительных данных используются модели внутри контура. А для менее чувствительных можно использовать и внешние модели.
Все как в жизни. Если модель русскоязычная, то она лучше понимает русский. Если же русский для нее не первый язык, то лучше все же общаться на английском. Например, есть исследования, которые говорят о том, что некоторые классы моделей "думают" на английском.
У нас в работе используется множество разных моделей (как Open Source, так и проприетарных).
Не сказал бы, что есть единый источник. Что-то мы поддерживаем сами, для каких-то моделей взаимодействуем с партнерами (например, YandexGPT, Гигачат). Для финального пользователя мы, конечно, все собираем в единое место, но это внутренний продукт с перманентным процессом обновления, т.к. постоянно выходит нечто новое.
Сервисы-прослойки мы не используем. Во многом, из-за корпоративных политик безопасности.
Но весьма вероятно, что в признаки для бустинга прокидывают исторические значения с некоторыми лагами (и это может быть как прошлый день, так и неделя, месяц, год).
Либо используют такие же классические статистические подходы (как и детекция тренда) на этапе коррекции предсказаний в отдельном модуле.
Изображение "Устройство KNN-классификатора" стоит поправить. На скриншот попало всплывающее сообщение, которое закрывает часть информации на этом изображении
Кажется, что совсем простую модель построили. Полагаю, туда еще можно было бы добавить много чего, к примеру: время на смене (сколько прошло с начала смены), насколько доставщик опаздывает, количество заказов клиента (про важность этого проговорили сами ранее), насколько близок адрес к основным магистралям (а то может это частный сектор какой, куда подъехать сложнее) и т.п. Ну и еще можно предложить использовать средства гео-визуализации для анализа и отладки (чтобы смотреть на что-то кроме shapely). Как пример - Kepler.gl от Uber.
"Раскатить" от слова "катить". Например: "мы выкатили новые улучшения нашего сайта для всех пользователей". Получается, что мы выпустили некие обновления, которые теперь видны всем пользователям.
Насколько я вижу, именно в таком значении и используется данный оборот в тексте. Применить изменение ко всем нашим пользователям.
Статья интересная, но еще бы добавить графиков и бенчмарков для сравнений (так воспринимать проще материал), чтобы было совсем круто.
И еще клево было бы увидеть, что делать с такой проблемой, коль она уж проявилась. И как ее мониторить на основе полученных выводов на практике.
Заглавная картинка в уменьшенном виде в ленте выглядит нечитаемо. Стоит поправить
Спасибо за статью!
Я верно понимаю, что вы просто использовали евклидовый matching по признакам (с учетом того, что это приближенный поиск, коль речь про FAISS) ? Или есть какие-то особенности решения?
Спасибо за статью!
Это качественное исследование? Клево было бы на метрики еще глянуть (но нужна разметка, это да).
И с промптами похимичить бы (возможно, получится исправить часть проблем).
И еще немаловажный момент: какие из моделей умеют в структурированный вывод (и насколько хорошо следуют условной инструкции "ответь в формате json с такими-то полями"). В больших модельках не сомневаюсь, а вот к моделям поменьше могут быть вопросики.
Спасибо за вопрос!
Да, именно так. Своего рода дистилляция получается. В основном, мы обучаем более легкую и простую модельку, которая будет работать быстрее и использовать меньше ресурсов, чтобы сэкономить.
Впрочем, для некоторых специфичных кейсов (медицина, юриспруденция и т.п.) может еще быть так, что LLM будет хуже справляться, чем отдельная моделька с отдельно собранной специфичной разметкой. Но в таком случае и разметка от LLM будет только заготовкой. Так что все равно придется прилично потрудиться над разметкой (но небольшое ускорение возможно, полагаю). Но это скорее специфичный случай, основной вариант я описал выше.
Это те же рекомендации, но с учетом особенностей ритейла (что люди закупаются "корзинами" с некоторой периодичностью и наполнением). То есть, мы рекомендуем не единичные товары, а сразу некоторое множество (которое в себе предполагает какую-то логичную компоновку, например, учитывает, что для салата нужны не только огурцы, но еще хорошо бы взять и другие овощи).
Получается, что это все та же задача рекомендаций, но более общей сущности (целой корзины вместо товара).
А использовать это можно для того, чтобы посоветовать что-то, что вполне могло быть в корзине пользователя, но этого почему-то нет (например, пользователь постоянно покупает йогурты, а сегодня как назло забыл про это).
Но, конечно, это будет тащить за собой некоторые предположения (например, что у нас пользователь может набирать разные корзины в разные моменты времени). И, полагаю, еще будет иметь не только плюсы, но и минусы (ошиблись с предполагаемой корзиной - ухудшили рекомендации по сравнению с рекомендацией отдельных единичных товаров).
А как обновляются пороги? Если мы жестко "прибили гвоздями" константы, то со временем они могут устареть. И качество модели упадет.
Сюда же чуть более сложный вопрос. Предположим, что наши подсказки в моменте улучшили метрики. Но что, если мы просто временно сдвинули равновесие условного "рынка"? Что, если более успешные исполнители решат добавить еще что-то, что будет улучшать их метрики. Получим частичный возврат к исходному состоянию. Какие-то решения для этой проблемы продумывали?
Спасибо, что поделились вашим опытом!
Интересное наблюдение.
Спасибо за интерес к статье!
Вопрос отличный.
Я выше писал, что у нас используются разные решения (как Open Source, так и проприетарные). Соответственно, для работы с чувствительными данными есть два варианта - работа с локальной моделью внутри инфраструктуры компании и подписание дополнительного соглашения с внешним сервисом (если компания в юрисдикции РФ).
В основном, мы используем первый вариант. То есть, для чувствительных данных используются модели внутри контура. А для менее чувствительных можно использовать и внешние модели.
Спасибо за интерес к статье!
Все как в жизни. Если модель русскоязычная, то она лучше понимает русский. Если же русский для нее не первый язык, то лучше все же общаться на английском. Например, есть исследования, которые говорят о том, что некоторые классы моделей "думают" на английском.
Спасибо за интерес к статье!
У нас в работе используется множество разных моделей (как Open Source, так и проприетарных).
Не сказал бы, что есть единый источник. Что-то мы поддерживаем сами, для каких-то моделей взаимодействуем с партнерами (например, YandexGPT, Гигачат). Для финального пользователя мы, конечно, все собираем в единое место, но это внутренний продукт с перманентным процессом обновления, т.к. постоянно выходит нечто новое.
Сервисы-прослойки мы не используем. Во многом, из-за корпоративных политик безопасности.
В топ-18 два пункта совпадают (7 и 13). Либо это должен быть топ-17, либо что-то забыли и заменили уже внесенным пунктом
Это своеобразный жаргон специалистов по работе с данными. Наверное, на русский было бы наиболее правильно перевести словом "оценки".
А свойства как получали из фильмов? Автоматизированно, или они сразу идут в описании контента?
Не скажу наверняка, как реализовано у автора.
Но весьма вероятно, что в признаки для бустинга прокидывают исторические значения с некоторыми лагами (и это может быть как прошлый день, так и неделя, месяц, год).
Либо используют такие же классические статистические подходы (как и детекция тренда) на этапе коррекции предсказаний в отдельном модуле.
На слайде с детекцией тренда написано "детекция труда". Кажется, что это описка, стоит поправить.
Изображение "Устройство KNN-классификатора" стоит поправить. На скриншот попало всплывающее сообщение, которое закрывает часть информации на этом изображении
Кажется, что совсем простую модель построили.
Полагаю, туда еще можно было бы добавить много чего, к примеру: время на смене (сколько прошло с начала смены), насколько доставщик опаздывает, количество заказов клиента (про важность этого проговорили сами ранее), насколько близок адрес к основным магистралям (а то может это частный сектор какой, куда подъехать сложнее) и т.п.
Ну и еще можно предложить использовать средства гео-визуализации для анализа и отладки (чтобы смотреть на что-то кроме shapely). Как пример - Kepler.gl от Uber.
Из двух альтернатив (тест и контроль) выбрали тестовый вариант для того, чтобы его применить ко всем пользователям сервиса. То есть "раскатили тест".
"Раскатить" от слова "катить". Например: "мы выкатили новые улучшения нашего сайта для всех пользователей". Получается, что мы выпустили некие обновления, которые теперь видны всем пользователям.
Насколько я вижу, именно в таком значении и используется данный оборот в тексте. Применить изменение ко всем нашим пользователям.