4️⃣5️⃣6️⃣

Главный bottleneck в рекомендациях — embedding-таблицы

Давно хотел рассказать про такую интересную штуку как unified embeddings, и кажется, что этот подход реально БАЗОЙ в генеративных рекомендациях.

Если по-человечески, то раньше каждая фича жила в своей отдельной табличке с эмбеддингами, и, мягко говоря, при миллионах товаров или пользователей это была катастрофа.

В отличие от LLM где вокабуляр составляет 40-50 тысяч токенов, мы оперируем миллионами товаров и пользователей. Поэтому мы ограничены как в расчете full CE, так и в том что-бы хранить все пространство.

И вы знаете, мы неплохо научись бороться с этим бутылочным горлышком. Если нам тяжело и дорого считать всё напрямую — давайте считать приближенно.

Один из таких подходов предложили исследователи Google под названием Feature Multiplexing: вместо независимых таблиц для каждого признака модель использует единое пространство эмбеддингов.

Причем размеры этой таблицы мы можем задавать сами — а лукапы реализовать через агрегацию по хешам. Таким образом, один унифицированный эмбеддинг товара несёт семантику сразу из разных источников.

По сути вы заставляете модель, в каком-то линейном слое, научить правильно декодировать эмбеддинг.

Безусловно за все хорошее надо платить — теперь у вас открывается пассивный навык в виде 1-5% коллизий.

Кроме Google unified матрицы используют Pinterest, Netflix, Yandex, WB, определенно стоит присмотреться!

➡️ Unified Embedding

❗В предыдущем посте кстати угадали альтернативную версию — semantic id. Одну из проблем мы решили, но вот вам следующий кейс: FullCE вы считать не можете у вас слишком много классов, а что тогда?

➡️Как сделать ИИ-чатбота менее болтливым. Совет от OpenAI

Ребята из OpenAI в мануале по ЖПТ-5.1 рекомендуют добавлять следующий текст к промпту:

Вы цените ясность, динамику и уважение, измеряемое полезностью, а не любезностями. Ваш инстинкт по умолчанию — поддерживать беседы четкими и целенаправленными, отсекая все, что не продвигает работу вперед. Вы не холодны — вы просто экономны в языке и достаточно доверяете пользователям, чтобы не оборачивать каждое сообщение в "набивку".
- Адаптивная вежливость:
- Когда пользователь тепло относится, детализирует, проявляет внимание или говорит «спасибо», вы предлагаете одно, краткое подтверждение — небольшой кивок в ответ на их тон с помощью токенов подтверждения или получения, таких как «Понял», «Я понимаю», «Пожалуйста» — затем немедленно переключаетесь обратно на продуктивное действие. При этом не будьте приторными или чрезмерно поддерживающими.
- Когда ставки высоки (сроки, вопросы соответствия, срочная логистика), вы отбрасываете даже этот небольшой кивок и сразу переходите к решению или сбору необходимой информации.
- Основная склонность:
- Вы говорите с обоснованной прямотой.
- Вы верите, что самое уважительное, что вы можете предложить, — это эффективность: чистое решение проблемы без лишней болтовни.
- Вежливость проявляется через структуру, точность и оперативность, а не через словесный «пух».
- Отношение к токенам подтверждения и получения:
- Вы относитесь к подтверждению и получению как к необязательной приправе, а не к самому блюду.
- Если пользователь быстр или лаконичен, вы соответствуете этому ритму с почти полным отсутствием подтверждений.
- Вы избегаете стандартных подтверждений, таких как «Понял» или «Спасибо, что обратились», если только тон или темп пользователя естественным образом не приглашают к краткому, пропорциональному ответу.
- Ритм разговора:
- Вы никогда не повторяете подтверждения. Как только вы сигнализировали о понимании, вы полностью переключаетесь на задачу.
- Вы внимательно прислушиваетесь к энергии пользователя и отвечаете в том же темпе: быстро, когда они быстры, более пространно, когда они многословны, всегда оставаясь сфокусированным на действии.
- Основной принцип:
- Ваша философия общения — «уважение через динамику». Вы теплы в намерении, но лаконичны в выражении, фокусируя каждое сообщение на том, чтобы помочь пользователю продвигаться вперед с минимальным трением.

Этож сколько сил требуется на убеждение модели, чтобы с нее как с рога изобилия всякая дичь не лилась??😄
Рекомендую запомнить эту мантру перед началом планерок😄

➡️Советы по вайбкодингу

Как и обещал на выступлении, прикладываю ссылку на презу. В pptx - есть видео с демонстранцией. В pdf - отсутствует

Нежданчик от Gamma

Презентацию делал в Гамме. Экспортировал в паверпоинт за день до выступления. Вылез баг - размеры шрифтов заголовков на каждом слайде с картинками очень различаются. Видимо, Гамма автоматически подстраивает размер под объем контента. На сайте этот как-то было не сильно заметно, а вот в паверпоинте заиграло новыми красками🤦‍♂️

Пришлось поздно вечером форматировать всю презу.

На будущее буду сохранять из гаммы часть слайдов и допиливать их уже в паверпоинте. Чтобы все картинки были на одном уровне и шрифты не плясали.

Как вытащить БОЛЬ из рекрутера и техлида прямо сейчас

Прямо сейчас на трансляции мы разбираем, как перестать быть «одним из 30» в очереди и начать диктовать свои условия. Но чтобы продать решение, нужно сначала понять, что у них болит 👀

Не надо гадать на кофейной гуще - тут нужно просто спросить. Ловите вопросы, которые превратят ваш монолог в допрос для компании, после которой вы будете знать её боли лучше, чем сама компания знает свои

1️⃣ HR-скрининг (Ищем Бизнес-боль)
Здесь мы узнаем контекст. HR - твой союзник, он сольет тебе инфу, если правильно спросить.

«В чем сейчас главная боль команды? Какую задачу нужно "тушить" в первую очередь?»

«А какие задачи будут приоритетными для нового человека, чтобы усилить то направление, которым занимался предыдущий сотрудник?»

«Позиция новая или это замена? Если замена — чего не хватило прошлому сотруднику?»

«Каких конкретных результатов вы ожидаете от специалиста через 3 месяца после начала работы? Что будет критерием успешного прохождения испытательного срока?»
2️⃣ Техническое собеседование (Ищем Техническую боль)
Здесь ты говоришь с носителем боли. Поговоришь с людьми, которые либо решают эту боль, или её испытывают.

«Расскажите, пожалуйста, как выглядит путь модели от идеи до продакшена? С какими основными сложностями (узкими местами) команда сталкивается при деплое сейчас?»

«Каково примерное соотношение времени, которое команда тратит на поддержку текущих решений и на разработку новых фичей/моделей?»

«Как у вас выстроен процесс работы с данными? Есть ли в команде выделенные дата-инженеры, или подготовка данных и построение пайплайнов полностью лежат на ML-разработчиках?»

«Много времени уходит на поддержку легаси-моделей?»

«Насколько чистые данные приходят? Сколько времени уходит на feature engineering, а сколько на обучение?»

3️⃣ Поведенческое / Финал (Ищем Культурный код)
Здесь смотрим, сработаемся ли мы по-человечески.

«На какие ключевые метрики бизнеса влияет работа вашей команды? Как именно эта роль помогает компании достигать глобальных целей?»

«Как у вас организован рабочий процесс? Как обычно ставятся задачи и как команда справляется с пиковыми нагрузками или срочными дедлайнами?»

«Опишите, пожалуйста, идеального кандидата для этой роли. Какими софтами должен обладать человек, чтобы максимально органично вписаться в вашу команду?»

«Основываясь на нашем разговоре, есть ли у вас какие-то сомнения относительно моего опыта или навыков, которые мы могли бы обсудить и прояснить прямо сейчас?»

Залетай на эфир, там сейчас самый сок - разбираем, как эти ответы превратить в оффер

Diff-in-Diff на самом деле

Вокруг методов квазиэкспериментов (diff-in-diff, regression discontinuity, Propensity Score Matching и тд), которые применяются в случае, когда A/B невозможен, есть некая атмосфера крутизны. Считается, что обычные A/B тесты это база, которую умеют делать все, а вот методы причинного вывода это реально сложно и интересно. Хотя все понимают (надеюсь), что с точки зрения валидности и надежности выводов правильно задизайненный и проведенный A/B тест опережает все вышеперечисленное. Все остальные квазиэксперименты это "A/B для бедных". Тем не менее, иногда действительно нет возможности провести A/B тест по разным причинам. Например, он технически невозможен или этически недопустим, однако эффект все равно оценить нужно, тогда без квазиэкспериментов никак.
У меня самой было в планах наконец-то разобраться с этими методами, так как это интересно, а еще про это любят спрашивать на собеседованиях 😏.

И вот оно: по работе возникла задача посчитать влияние уже внедренной фичи, которую запускали сразу на 100% без A/B (были на это причины). Это как раз типичный кейс применения diff-in-diff. Я обрадовалась возможности с этим разобраться на реальных данных (ооо наконец-то сложные методы), так что поставила задачку на себя и пошла читать статьи как это работает.

Оказалось, что аналитики в очередной раз назвали умными словами обычную линейную регрессию с двумя факторами и взаимодействием. Основная сложность метода не в формуле, а как обычно в наличии качественных данных и в умении правильно их приготовить. Например, нужно выбрать подходящую контрольную группу или построить синтетическую, проверить выполняются ли параллельные тренды до вмешательства, при необходимости добавить ковариаты, но это уже детали.
Общую идею метода неплохо объяснили в статье на хабре, но мне немного показалось, что в статье есть то самое "назвать простое сложным".

Сама формула:

y = β0 + β1*treat + β2*post + β3*(treat × post) + ε

Как видите, это обычная формула линейной регрессии с взаимодействием, где

β0 (Intercept) – значение интересующего показателя, например конверсии, в контрольной группе до воздействия.
β1 – значение показателя в тестовой группе до воздействия.
β2 – значение показателя в контрольной группе после воздействия.

β3 – тот самый эффект взаимодействия, Diff-in-Diff, дополнительное изменение конверсии в тестовой группе после воздействия по сравнению с контрольной группой.

Никакой сложной математики, старая добрая линейная регрессия в тренде 😎

Пример кода на 🖥

# предварительно уже создан df, в комментарии пришлю как сгенерировать
model <- lm(y ~ treat*post, data = data)
summary(model)

Пример кода на 🐍

# предварительно уже создан df, в комментарии пришлю как сгенерировать
import statsmodels.formula.api as smf # ключевой import для работы с Diff-in-Diff
df['did'] = df['treat'] * df['post'] # создание переменной взаимодействия
model = smf.ols("y ~ treat + post + did", data=df).fit()
print(model.summary())

Самое главное для применения метода подобрать подходящий контроль с соблюдением параллельности трендов до воздействия, а дальше сама формула занимает буквально две строчки. И необязательно делать вид, что это что-то супер сложное и крутое, потому что по сравнению с моделями, с которыми сталкиваются ученые, это совсем не рокет саенс 🤓

Вот еще несколько полезных ссылок:
1) Статья из книги Causal Inference for the Brave and True
2) Небольшая заметка на kaggle
3) Хорошая статья от X5 на хабре

👇В комментарии приложила пример кода для генерации подходящих под Diff-in-Diff данных на R и Python

#analytics #stats