Реально на мои апельсинки 🍊 кто-то позарился? Или кто-то пытается их мне втюхать?
Как относитесь к таким пушам? Заставляют ли они вас более активно реагировать на них или вообще все равно?
Как относитесь к таким пушам? Заставляют ли они вас более активно реагировать на них или вообще все равно?
Please open Telegram to view this post
VIEW IN TELEGRAM
Пользуемся продуктом (или собираем фидбек) для генерации новых гипотез
Если ты сам не пользуешься продуктом, многое ускользает. По факту на основе данных мы отвечаем на вопрос: «Что случилось?»
Ты не замечаешь очевидных неудобств, которые мешают пользователям. Ты видишь, что на этапе оплаты большой отток. Анализируешь данные, проверяешь A/B-тесты, но не находишь явной причины. А если бы ты попробовал оплатить заказ сам, то заметил бы, что в мобильной версии кнопка “Оплатить” уходит за границы экрана.
Данные могут показывать проблему, но не её причину. Например, ты понимаешь, что время нахождения на странице сильно меньше, чем ожидается (мы считаем, что просмотр контента этой страницы улучшает бизнес-показатели). Проблема могла быть с тем, что очень много текста, непонятное содержание страницы, техническая ошибка и т.д. Хорошее правило с ошибками: «Если воспроизводится у двух и более людей, значит проблема глобальная».
Гипотезы строятся в вакууме, а не на основе реального опыта. Можно бесконечно анализировать данные, но хорошие гипотезы могут рождаются, когда ты сталкиваешься с неудобствами. Видишь, что процесс сложный, что логика неочевидная — проверяешь на адекватность, тестируешь.
В продукте для себя я вижу возможность для генерации новых гипотез, которые основаны на пользовательском пути (точечно) или для группы лиц (по результатам исследований).
[Я понимаю, что для разных аналитиков в разных продуктах по-разному. Мы можем по факту и не трогать продукт, а получать фидбек по нему на основе обращений в саппорт или качественных исследований по интересующему направлению]
Ставьте реакции❤️ , если пост понравился, пишите комментарии.
А вы тестируете продукт, который анализируете? Как часто замечаете проблемы, которые не видно в метриках?
Если ты сам не пользуешься продуктом, многое ускользает. По факту на основе данных мы отвечаем на вопрос: «Что случилось?»
Ты не замечаешь очевидных неудобств, которые мешают пользователям. Ты видишь, что на этапе оплаты большой отток. Анализируешь данные, проверяешь A/B-тесты, но не находишь явной причины. А если бы ты попробовал оплатить заказ сам, то заметил бы, что в мобильной версии кнопка “Оплатить” уходит за границы экрана.
Данные могут показывать проблему, но не её причину. Например, ты понимаешь, что время нахождения на странице сильно меньше, чем ожидается (мы считаем, что просмотр контента этой страницы улучшает бизнес-показатели). Проблема могла быть с тем, что очень много текста, непонятное содержание страницы, техническая ошибка и т.д. Хорошее правило с ошибками: «Если воспроизводится у двух и более людей, значит проблема глобальная».
Гипотезы строятся в вакууме, а не на основе реального опыта. Можно бесконечно анализировать данные, но хорошие гипотезы могут рождаются, когда ты сталкиваешься с неудобствами. Видишь, что процесс сложный, что логика неочевидная — проверяешь на адекватность, тестируешь.
В продукте для себя я вижу возможность для генерации новых гипотез, которые основаны на пользовательском пути (точечно) или для группы лиц (по результатам исследований).
[Я понимаю, что для разных аналитиков в разных продуктах по-разному. Мы можем по факту и не трогать продукт, а получать фидбек по нему на основе обращений в саппорт или качественных исследований по интересующему направлению]
Ставьте реакции
А вы тестируете продукт, который анализируете? Как часто замечаете проблемы, которые не видно в метриках?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤25🔥4🐳2
Материалы для прокачки навыков в pandas для начинающих 🐼 [ч. 1]
Хотите прокачаться в pandas, но не знаете, с чего начать? Собрал полезные инструменты, шпаргалки и ресурсы, которые помогут вам разобраться во всем шаг за шагом!
Можно основные операции потыкать на этом сайте (сводные таблицы, join'ы, сортировки и др.)
Есть официальная документация с быстрым стартом (как устроены данные, как создавать чарты, сводники)
В интернете присутствует очень много шпаргалок для различных инструментов (в т. ч. по pandas), одна из которых включает в себя практически всю документацию (очень много инфы тут) - ссылочка.
У Яндекс Образования в курсе по Python: блок по pandas
Шпаргалки по pandas (если нужно освежить быстро в памяти):
1. link1
2. link2
3. в одном PDF, во втором PDF, в третьем PDF
Была ли вам интересна подборка? Какие материалы помогли вам лучше всего разобраться в pandas? Делитесь в комментариях! А если пост соберёт 100 реакций, выложу следующую подборку с практическими задачами😏
#дляначинающих@zasql_python
UPD:
https://dfedorov.spb.ru/pandas/
Хотите прокачаться в pandas, но не знаете, с чего начать? Собрал полезные инструменты, шпаргалки и ресурсы, которые помогут вам разобраться во всем шаг за шагом!
Можно основные операции потыкать на этом сайте (сводные таблицы, join'ы, сортировки и др.)
Есть официальная документация с быстрым стартом (как устроены данные, как создавать чарты, сводники)
В интернете присутствует очень много шпаргалок для различных инструментов (в т. ч. по pandas), одна из которых включает в себя практически всю документацию (очень много инфы тут) - ссылочка.
У Яндекс Образования в курсе по Python: блок по pandas
Шпаргалки по pandas (если нужно освежить быстро в памяти):
1. link1
2. link2
3. в одном PDF, во втором PDF, в третьем PDF
Была ли вам интересна подборка? Какие материалы помогли вам лучше всего разобраться в pandas? Делитесь в комментариях! А если пост соберёт 100 реакций, выложу следующую подборку с практическими задачами
#дляначинающих@zasql_python
UPD:
https://dfedorov.spb.ru/pandas/
Please open Telegram to view this post
VIEW IN TELEGRAM
Формирование пользовательской привычки: почему одни продукты входят в повседневность, а другие нет?
Недавно наткнулся на интересную концепцию из книги Hooked от Нира Эяля.
Суть в том, что привычные продукты формируются на пересечении двух факторов:
1. Частоты использования – чем чаще мы совершаем действие, тем быстрее оно закрепляется
2. Воспринимаемой ценности – насколько полезным это кажется пользователю
🔍 Google – высокая частота использования, люди ищут информацию каждый день, поэтому привычка сформирована
🚔 Amazon – покупки совершаются реже, но воспринимаемая ценность высокая, поэтому пользователи возвращаются
Что здесь важно понимать?
Некоторые действия не становятся привычными, даже если они полезны, потому что происходят слишком редко. Например, покупка страховки – это важно, но никто не делает это регулярно, поэтому нет "привычки" взаимодействовать с сервисом.
Если продукт используется нечасто, но его воспринимаемая ценность огромна (например, Airbnb), пользователи всё равно возвращаются
Не всегда можно просто "увеличить частоту" – если пользователю не нужна ежедневная покупка товаров, пытаться формировать привычку через увеличение касаний может быть бесполезно
Как это применимо к продуктам и аналитике?
Если стоит задача увеличить вовлечённость, важно понимать, в какой зоне на графике находится продукт.
🍪 Высокая частота, но низкая ценность? Сделайте так, чтобы взаимодействие приносило больше пользы
🍪 Высокая ценность, но низкая частота? Напомните пользователю о возможностях продукта через персонализацию, дополнительной коммуникации.
Нет универсального рецепта, каждая компания решает эту задачу по-своему, опираясь на специфику продукта, аудитории и данных.
😏 Понравился пост? Наберется 100 рекций, продолжу дальше обозревать концепции из книг. А какие книги по продукту или аналитике читали вы? Какие концепции показались вам полезными?
Недавно наткнулся на интересную концепцию из книги Hooked от Нира Эяля.
Суть в том, что привычные продукты формируются на пересечении двух факторов:
1. Частоты использования – чем чаще мы совершаем действие, тем быстрее оно закрепляется
2. Воспринимаемой ценности – насколько полезным это кажется пользователю
Что здесь важно понимать?
Некоторые действия не становятся привычными, даже если они полезны, потому что происходят слишком редко. Например, покупка страховки – это важно, но никто не делает это регулярно, поэтому нет "привычки" взаимодействовать с сервисом.
Если продукт используется нечасто, но его воспринимаемая ценность огромна (например, Airbnb), пользователи всё равно возвращаются
Не всегда можно просто "увеличить частоту" – если пользователю не нужна ежедневная покупка товаров, пытаться формировать привычку через увеличение касаний может быть бесполезно
Как это применимо к продуктам и аналитике?
Если стоит задача увеличить вовлечённость, важно понимать, в какой зоне на графике находится продукт.
Нет универсального рецепта, каждая компания решает эту задачу по-своему, опираясь на специфику продукта, аудитории и данных.
Please open Telegram to view this post
VIEW IN TELEGRAM
2🐳27 16👍8 8
Пока Duolingo убивают сову, они выложили свою стратегию и принципы, которые позволяет им быть лучшим образовательным продуктом в мире
1️⃣ Работа в долгосрок
Работа в долгую лучше краткосрочных побед. Они не гонятся за хайпом и трендами, а создают вечнозеленый продукт, которым люди будут пользоваться через 10-20 лет.
2️⃣ Культура экспериментов: быстрые A/B тесты вместо долгих споров
> Ключевой принцип: тестирование в реальном мире всегда лучше, чем бесконечные внутренние обсуждения.
> В любой момент запущены сотни экспериментов, потому что неудачный эксперимент тоже полезен — он проверяет гипотезы.
3️⃣ Минимизация промежутков между действиями (Clock Speed)
Чем меньше времени между принятием решения и его реализацией, тем быстрее развивается продукт.
Duolingo сокращает все простои
> Быстро тестируют и вносят изменения.
> Важнее не избегать ошибок, а сохранять темп и минимизировать паузы между итерациями.
> Сразу получают обратную связь.
> Запускают гипотезу в бой, а не держат ее годами.
Это позволяет компании двигаться быстрее конкурентов.
4️⃣ Простота в продукте и фокус на миссии
В Duolingo нет перегруженных фич. Продукт интуитивно понятен, без сложного онбординга и обучающих экранов. Сотрудники делают только то, что укрепляет основную цель: помочь людям учить язык. Любая новая фича проходит фильтр: улучшает ли она долгосрочный пользовательский опыт?
5️⃣ Радикальные идеи приветствуются — «99 Bad Ideas»
В компании есть практика «99 плохих идей» — руководители и сотрудники предлагают самые безумные концепции. Многие идеи кажутся странными на старте, но потом становятся прорывом в области.
6️⃣ Меньше говорить, больше делать
> TL;DR-культура — вместо долгих обсуждений краткое выжимка из сути проблемы и решения.
> Говорить меньше — показывать больше (на примере прототипов).
> Когда в компании нет лишнего шума, решения принимаются быстрее.
7️⃣ Высокие планка: от команды до продукта
Duolingo строит культуру превосходства. Здесь ожидают, что сотрудники будут делать лучшую работу в своей карьере. Они не боятся ошибок, но главное правило — не обвинять, а разбираться в причинах:
Жесткие стандарты качества в продукте: Всё должно быть полезным, интуитивным, восхитительным и продуманным. Если фича требует пояснений — она сделана неправильно. Никаких избыточных функций и сложностей.
Темп + ориентация на долгосрок + простой UI = <3
🐳 🐳 🐳 А вы что думаете? Пишите в комментариях, ставьте реакции!
Работа в долгую лучше краткосрочных побед. Они не гонятся за хайпом и трендами, а создают вечнозеленый продукт, которым люди будут пользоваться через 10-20 лет.
If it helps in the short-term, but hurts Duolingo in the long-term, it’s not right
> Ключевой принцип: тестирование в реальном мире всегда лучше, чем бесконечные внутренние обсуждения.
> В любой момент запущены сотни экспериментов, потому что неудачный эксперимент тоже полезен — он проверяет гипотезы.
When we disagree, we test ideas and let the metrics decide.
Чем меньше времени между принятием решения и его реализацией, тем быстрее развивается продукт.
Duolingo сокращает все простои
> Быстро тестируют и вносят изменения.
> Важнее не избегать ошибок, а сохранять темп и минимизировать паузы между итерациями.
> Сразу получают обратную связь.
> Запускают гипотезу в бой, а не держат ее годами.
Это позволяет компании двигаться быстрее конкурентов.
В Duolingo нет перегруженных фич. Продукт интуитивно понятен, без сложного онбординга и обучающих экранов. Сотрудники делают только то, что укрепляет основную цель: помочь людям учить язык. Любая новая фича проходит фильтр: улучшает ли она долгосрочный пользовательский опыт?
Learners need to get utility out of whatever we’ve built. Otherwise, we’ve made something that adds more complexity to the app and distracts learners from what they’re here to do.
Every feature we ship must be intuitive, delightful, useful, and polished.
If a feature or screen requires explanation or additional context, it’s not right.
В компании есть практика «99 плохих идей» — руководители и сотрудники предлагают самые безумные концепции. Многие идеи кажутся странными на старте, но потом становятся прорывом в области.
Some of our best features and campaigns have come from asking ridiculous, unlikely questions
> TL;DR-культура — вместо долгих обсуждений краткое выжимка из сути проблемы и решения.
> Говорить меньше — показывать больше (на примере прототипов).
> Когда в компании нет лишнего шума, решения принимаются быстрее.
Talking about ideas is rarely as effective as building them
Duolingo строит культуру превосходства. Здесь ожидают, что сотрудники будут делать лучшую работу в своей карьере. Они не боятся ошибок, но главное правило — не обвинять, а разбираться в причинах:
We don’t chase blame. We dig in and figure out what happened. This is how we continuously raise the bar—not by being perfect, but by being a little bit better each day.
Жесткие стандарты качества в продукте: Всё должно быть полезным, интуитивным, восхитительным и продуманным. Если фича требует пояснений — она сделана неправильно. Никаких избыточных функций и сложностей.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤26🐳12 3🥴2 2
Please open Telegram to view this post
VIEW IN TELEGRAM
3😍29🥰10😁8❤7🔥1😱1
Что влияет на метрику X
В нашей работе может достаточно часто возникать задача в следующей формулировке: "А что влияет на метрику X?". Метрика X может быть произвольна. В дальнейшем бизнес может сделать упор над тем, а что можно улучшить, на что стоит обратить внимание. Для решения этой задачи можно подступиться следующим способом:
🆎 Проверить это на интересующей поверхности через A/B тест. Например, мы проводим ухудшающий эксперимент на главной и хотим понять какие метрики шатаются вместе с целевой (какие в общем бывают прокси). Эксперимент может показать насколько сонаправлены различные метрики + возможно его придется долго держать, чтобы проверить необходимые гипотезы.
💻 Собрать таблицу с фичами, которые экспертно могут быть выбраны для обучения модели машинного обучения.
Что здесь можно придумать?
📊 Линейная регрессия. Все мы любим линейную регрессию за ее простую интерпретируемость, но есть существенный минус: между фичой и таргетом должна быть линейная зависимость. Коэффициенты, которые мы получаем при обучении (coef_), по сути коэффициенты при которых минимизируется функция потерь. Кроме того, важно следить за мультиколлинеарностью, чтобы важность фичей не перераспределялась между различными признаками (для этого нужно определить насколько сильно они коррелируют друг с другом). doc
🌲 Деревья решений и градиентный бустинг. Когда мы работаем с нелинейными зависимостями, линейная регрессия уже не даёт нам полной картины. В таких случаях можно использовать деревья решений и градиентный бустинг. Эти модели оценивают важность признаков по тому, насколько они помогают уменьшать неопределённость (снижать критерий ошибки, например, Gini или MSE) при разбиениях. catboost doc
Здесь можно получить встроенную важность фичей. Это показатель, сколько раз признак использовался для разбиения и насколько он помог улучшить модель. Если признаки сильно коррелируют, модель может выбрать один из них, а другой посчитать неважным.
🤨 Permutation Importance. Метод, который отвечает на вопрос: "Что будет, если убрать этот признак?". doc
Шаги:
а) Перемешиваем значения одного признака случайным образом.
б) Смотрим, как падает качество модели.
в) Если качество сильно ухудшается, то признак важен.
Может долго считаться, если данных много + если есть коррелирующие признаки, можем не учесть важность одной из фич
🙄 SHAP. Когда важно не просто узнать, какие признаки важны, но и как именно они влияют. doc
🤔 Наберется 100 реакций, напишу более подробно про SHAP. А вы применяете эти методы или какие-то другие?
В нашей работе может достаточно часто возникать задача в следующей формулировке: "А что влияет на метрику X?". Метрика X может быть произвольна. В дальнейшем бизнес может сделать упор над тем, а что можно улучшить, на что стоит обратить внимание. Для решения этой задачи можно подступиться следующим способом:
🆎 Проверить это на интересующей поверхности через A/B тест. Например, мы проводим ухудшающий эксперимент на главной и хотим понять какие метрики шатаются вместе с целевой (какие в общем бывают прокси). Эксперимент может показать насколько сонаправлены различные метрики + возможно его придется долго держать, чтобы проверить необходимые гипотезы.
Что здесь можно придумать?
from sklearn.linear_model import LinearRegression
from sklearn.datasets import make_regression
import pandas as pd
X, y = make_regression(n_samples=1000, n_features=10, noise=10, random_state=42)
feature_names = [f"feature_{i}" for i in range(X.shape[1])]
model = LinearRegression()
model.fit(X, y)
importance = pd.Series(model.coef_, index=feature_names).sort_values(ascending=False)
Здесь можно получить встроенную важность фичей. Это показатель, сколько раз признак использовался для разбиения и насколько он помог улучшить модель. Если признаки сильно коррелируют, модель может выбрать один из них, а другой посчитать неважным.
from catboost import CatBoostRegressor
model = CatBoostRegressor(iterations=200, verbose=False)
model.fit(X, y)
feature_importance = pd.Series(model.get_feature_importance(), index=feature_names)
Шаги:
а) Перемешиваем значения одного признака случайным образом.
б) Смотрим, как падает качество модели.
в) Если качество сильно ухудшается, то признак важен.
from sklearn.ensemble import RandomForestRegressor
from sklearn.inspection import permutation_importance
from sklearn.model_selection import train_test_split
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)
model = RandomForestRegressor(n_estimators=100)
model.fit(X_train, y_train)
perm_importance = permutation_importance(model, X_test, y_test, scoring="r2")
importance = pd.Series(perm_importance.importances_mean, index=feature_names)
Может долго считаться, если данных много + если есть коррелирующие признаки, можем не учесть важность одной из фич
import shap
explainer = shap.TreeExplainer(model)
shap_values = explainer.shap_values(X_test)
shap.summary_plot(shap_values, X_test, feature_names=feature_names)
Линейная регрессия подходит для простых зависимостей, деревья и бустинг – для сложных, Permutation Importance – когда нужна честная оценка вклада признаков, а SHAP – для объяснения модели
Please open Telegram to view this post
VIEW IN TELEGRAM
3 49🐳19 12👍8❤4🦄3
о чем пишем на следующей неделе? пишите в комментариях
можно подумать над тем, чтобы ввести какую-то еженедельную рубрику (новости недели, задачи с собеседований и тд). Если вам такой формат зайдет, отреагируйте реакциями.
а так, любые предложения приветствуются
Please open Telegram to view this post
VIEW IN TELEGRAM
1 32❤12 7👍3😁1🥴1👀1🤝1
Типы задач продуктового аналитика
за время работы, общения с коллегами, друзьями выявил для себя основные таски, которые приходится выполнять продуктовому аналитику каждую неделю
1. создание дашбордов. Как ты видишь срез продукта, как донесешь другим людям полную картину, что происходит в бизнесе. Сделать так, чтобы это очень легко считывалось - искусство.
2. доработка / фикс / поддержка дашбордов. Если аналитик это заметил (с помощью алертинга, например, - класс), если бизнес - не особо. Возникают вопросы к доверию данных, актуализации отчетности, люди могут меньше обращаться к ней из-за наличия таких косяков.
3. работа с архитектурой данных. Здесь речь и про разработку витрин (не только для отчетности), но и для решения других задач. Сюда можно включить и разметку для пользовательского приложения (в зависимости от внердяемой фичи) и занесения метрик в абшницу и feature store для ML расчетов (вариаций куча).
4. оценка и приоритизация. Планы, приоритизация задач (в рамках скоринга задач, в каком порядке должны подступаться продуктово к решению задач), трекшн (как должен двигаться бизнес в определенном срезе), что может быть в будущем. К этому также может относиться расчет юнит-экономики, когда мы ищем определенные точки роста в бизнесе (новые идеи).
5*. прогнозирование. Тут речь про построение планов на основе различных методов прогнозирования (временные ряды), не грубая прикидка, а хороший прогноз (etna, arima, sarimax, prophet etc)
6. выгрузки / адхоки. Включает в себя разные вопросы, которые могут решаться за 1 этап (просто выгрузка из БД без каких-то фокусов). Сегменты пользователей для рассылки / коммуникации, ответ на вопрос, одна чиселка в ответе, передать инфу другим аналитикам / командам и др.
7. исследования. Здесь обычно нет какой-то структуры, может быть по-разному. Исследования, когда можно взять готовые данные и ответить на вопрос - одно. А когда нужно их комбинировать между собой, ставить перед собой задачу декомпозиции и потихоньку приходить к ответу - другое. Пример: понять, почему в бизнес-юните такая маленькая конверсия на данном этапе?
8. эксперименты. Дизайн, запуск, валидация, мониторинг, завершение. Здесь можно посчитать еще и долгосрочный эффект*, либо, если эксперимент неудачный - сделать перезапуск
9. моделирование / оптимизация. Машинное обучение, оптимизация бизнес-процессов, автоматизация (в том числе и для настройки ETL, отдельным пунктом в дашборд не выводил, так как само собой разумеющееся). Может быть и аплифт-моделирование (ближе к маркетинговой аналитике) и различные приколы с эмбеддингами (в аналитике поиска).
Что-то забыл? Делитесь в комментариях! Какую задачу вам приходится решать чаще всего?
за время работы, общения с коллегами, друзьями выявил для себя основные таски, которые приходится выполнять продуктовому аналитику каждую неделю
1. создание дашбордов. Как ты видишь срез продукта, как донесешь другим людям полную картину, что происходит в бизнесе. Сделать так, чтобы это очень легко считывалось - искусство.
2. доработка / фикс / поддержка дашбордов. Если аналитик это заметил (с помощью алертинга, например, - класс), если бизнес - не особо. Возникают вопросы к доверию данных, актуализации отчетности, люди могут меньше обращаться к ней из-за наличия таких косяков.
3. работа с архитектурой данных. Здесь речь и про разработку витрин (не только для отчетности), но и для решения других задач. Сюда можно включить и разметку для пользовательского приложения (в зависимости от внердяемой фичи) и занесения метрик в абшницу и feature store для ML расчетов (вариаций куча).
4. оценка и приоритизация. Планы, приоритизация задач (в рамках скоринга задач, в каком порядке должны подступаться продуктово к решению задач), трекшн (как должен двигаться бизнес в определенном срезе), что может быть в будущем. К этому также может относиться расчет юнит-экономики, когда мы ищем определенные точки роста в бизнесе (новые идеи).
5*. прогнозирование. Тут речь про построение планов на основе различных методов прогнозирования (временные ряды), не грубая прикидка, а хороший прогноз (etna, arima, sarimax, prophet etc)
6. выгрузки / адхоки. Включает в себя разные вопросы, которые могут решаться за 1 этап (просто выгрузка из БД без каких-то фокусов). Сегменты пользователей для рассылки / коммуникации, ответ на вопрос, одна чиселка в ответе, передать инфу другим аналитикам / командам и др.
7. исследования. Здесь обычно нет какой-то структуры, может быть по-разному. Исследования, когда можно взять готовые данные и ответить на вопрос - одно. А когда нужно их комбинировать между собой, ставить перед собой задачу декомпозиции и потихоньку приходить к ответу - другое. Пример: понять, почему в бизнес-юните такая маленькая конверсия на данном этапе?
8. эксперименты. Дизайн, запуск, валидация, мониторинг, завершение. Здесь можно посчитать еще и долгосрочный эффект*, либо, если эксперимент неудачный - сделать перезапуск
9. моделирование / оптимизация. Машинное обучение, оптимизация бизнес-процессов, автоматизация (в том числе и для настройки ETL, отдельным пунктом в дашборд не выводил, так как само собой разумеющееся). Может быть и аплифт-моделирование (ближе к маркетинговой аналитике) и различные приколы с эмбеддингами (в аналитике поиска).
Что-то забыл? Делитесь в комментариях! Какую задачу вам приходится решать чаще всего?
3❤26 8👍7 1
Bayessian vs Frequient A/B testing [презентация]
Видео на Youtube: Александр Сахнов — Почему вам не стоит использовать байесовское A/B-тестирование
Нашел вначале шикарную презентацию от X5 по сравнению байесовского и частотного подхода к применению A/B тестов, потом нашел само видео)
Есть код на Python, можно сравнить методы на данных и посмотреть, как использовать.
Опровергаются различные мифы по поводу байесовского тестирования (про Peeking Problem, большую чувствительность, множественное тестирование)
В начале идет описание частотного A/B тестирования и пайплайн проведения:
1. Фиксирование допустимых вероятностей ошибок первого и второго рода
2. Фиксирование ожидаемого результата
3. Оцениваем по истории дисперсии
4. Оцениваем необходимый размер групп
5. Проводим эксперимент
6. Собираем данные и вычисляем p-value
7. Оцениваем результат
Говорится о сложности интерпретации p-value. Вводится статистика, у которого какое-то предельное распределение. По реализации выборки мы считаем реализацию статистики и смотрим куда попала. Про это я писал у себя в посте. Бизнесу нужно принять бинарное решение (внедряем / не внедряем).
Затем описывается пайплайн байесовского A/B тестирования:
1. Определение априорных распределений (для неизвестных для нас параметров). Далее мы переходим к апостериорному распределению с помощью правдоподобий и теоремы Байеса
2. Определение размера групп. Размер групп можем взять из частотного метода
3. Проведение эксперимента
4. Собираем данные и что-то вычисляем
5. Оцениваем результат
Частотный подход: Какая вероятность получить такое или более экстремальное значение статистики при верности H0?
Байесовский подход: Какая вероятность, что среднее уменьшилось / увеличилось по совместному апостериорному распределению?
Далее оцениваются ошибки первого и второго рода в частотном и байесовском методе. Мы можем задавать априорное распределение через uninformative prior, тогда оба метода показывают одинаковые результаты в симуляциях. Использование дополнительных знаний через prior не позволило на симуляциях контролировать ошибки первого и второго рода.
В частотном A/B-тесте у всех одни и те же результаты, но в Байесе все зависит от априорных знаний. Если два аналитика зададут разные априоры, они могут получить разные выводы по одному и тому же тесту! Представьте, что в A/B платформе такое внедряется — один продакт видит значимый эффект, а другой — нет. Как принимать решения?
Байесовские методы позволяют решать различные задачи. Например, многорорукие бандиты, EM-алгоритмы и многое другое.
🐳 Наберется 100 реакций, в следующем посте буду писать про байесовское тестирование более подробно
А вы используете байесовские методы? Если да, то какие? Пишите в комментариях.
Видео на Youtube: Александр Сахнов — Почему вам не стоит использовать байесовское A/B-тестирование
Нашел вначале шикарную презентацию от X5 по сравнению байесовского и частотного подхода к применению A/B тестов, потом нашел само видео)
Есть код на Python, можно сравнить методы на данных и посмотреть, как использовать.
Опровергаются различные мифы по поводу байесовского тестирования (про Peeking Problem, большую чувствительность, множественное тестирование)
В начале идет описание частотного A/B тестирования и пайплайн проведения:
1. Фиксирование допустимых вероятностей ошибок первого и второго рода
2. Фиксирование ожидаемого результата
3. Оцениваем по истории дисперсии
4. Оцениваем необходимый размер групп
5. Проводим эксперимент
6. Собираем данные и вычисляем p-value
7. Оцениваем результат
Говорится о сложности интерпретации p-value. Вводится статистика, у которого какое-то предельное распределение. По реализации выборки мы считаем реализацию статистики и смотрим куда попала. Про это я писал у себя в посте. Бизнесу нужно принять бинарное решение (внедряем / не внедряем).
Затем описывается пайплайн байесовского A/B тестирования:
1. Определение априорных распределений (для неизвестных для нас параметров). Далее мы переходим к апостериорному распределению с помощью правдоподобий и теоремы Байеса
2. Определение размера групп. Размер групп можем взять из частотного метода
3. Проведение эксперимента
4. Собираем данные и что-то вычисляем
5. Оцениваем результат
Частотный подход: Какая вероятность получить такое или более экстремальное значение статистики при верности H0?
Байесовский подход: Какая вероятность, что среднее уменьшилось / увеличилось по совместному апостериорному распределению?
Далее оцениваются ошибки первого и второго рода в частотном и байесовском методе. Мы можем задавать априорное распределение через uninformative prior, тогда оба метода показывают одинаковые результаты в симуляциях. Использование дополнительных знаний через prior не позволило на симуляциях контролировать ошибки первого и второго рода.
В частотном A/B-тесте у всех одни и те же результаты, но в Байесе все зависит от априорных знаний. Если два аналитика зададут разные априоры, они могут получить разные выводы по одному и тому же тесту! Представьте, что в A/B платформе такое внедряется — один продакт видит значимый эффект, а другой — нет. Как принимать решения?
Байесовские методы позволяют решать различные задачи. Например, многорорукие бандиты, EM-алгоритмы и многое другое.
🐳 Наберется 100 реакций, в следующем посте буду писать про байесовское тестирование более подробно
А вы используете байесовские методы? Если да, то какие? Пишите в комментариях.
1🐳69❤25 9
Каннибализация продуктов: когда новый продукт убивает старый, а бизнес теряет деньги
💰 Запускаем новый продукт — кажется, что все идет отлично. Начинаются покупки, растет выручка. Но спустя время бизнес замечает странную вещь: общая выручка не изменилась, а иногда даже начала падать 😢
🤔 Что случилось?
Пользователи просто переключились со старого продукта на новый, но новых клиентов не пришло. Это и есть каннибализация — когда новый продукт съедает аудиторию старого, а не привлекает новую.
🤔 Почему это проблема?
1. Думаем, что новый продукт взлетает, но на самом деле он просто перетягивает пользователей🍪
2. Если пользователи переходят на более дешевый тариф или менее маржинальный продукт, бизнес теряет прибыль🥗
3. Если новый продукт не оправдал ожидания, пользователь может уйти вообще из обоих продуктов🌟
Пример:
У вас был премиум-тариф, который приносил высокий доход, а вы запустили дешевый вариант (дискаунтер). Клиенты ушли в новый продукт, выручка просела.
Как найти каннибализацию?🍪 🍪
Смотрим, как изменилось поведение пользователей после запуска нового продукта.
👩💻 SQL-запрос ниже
❓ Что значит результат?
1. Перешли, но платят меньше → Упали чеки, возможно, продукт слишком дешевый или не дает ценности. Нужно тестировать upsell, дополнительные возможности для продажи товаров / услуг, рост GMV, маржинальности😵
2. Остались на старом → Им новый продукт не нужен? Разбираемся, что именно их удерживает. Возможно, просто пользователи привыкли к другому продукту, а пересаживаться не видят смысла🪑
3. Мало новых клиентов → Новый продукт не привлекает новую аудиторию. Возможно, нужно менять маркетинг, коммуникацию с пользователями. Доносить понятные смыслы🖼
📈 Далее из этого можно составить различные чарты и другие инструменты, которые позволяют отслеживать перетоки между бизнес-юнитами, продуктами.
Бизнес думает, что новый продукт приносит деньги, но на самом деле пользователи просто перераспределяются.
😊 Наберется 100 реакций, сделаю еще пост с практическим применением SQL на реальных задачах
UPD: для оценки каннибализации честнее всего запустить 🆎
Пользователи просто переключились со старого продукта на новый, но новых клиентов не пришло. Это и есть каннибализация — когда новый продукт съедает аудиторию старого, а не привлекает новую.
1. Думаем, что новый продукт взлетает, но на самом деле он просто перетягивает пользователей
2. Если пользователи переходят на более дешевый тариф или менее маржинальный продукт, бизнес теряет прибыль
3. Если новый продукт не оправдал ожидания, пользователь может уйти вообще из обоих продуктов
Пример:
У вас был премиум-тариф, который приносил высокий доход, а вы запустили дешевый вариант (дискаунтер). Клиенты ушли в новый продукт, выручка просела.
Как найти каннибализацию?
Смотрим, как изменилось поведение пользователей после запуска нового продукта.
WITH old_product AS (
SELECT
user_id,
COUNT(order_id) AS old_orders,
SUM(revenue) AS old_revenue
FROM orders
WHERE product_id = 'old_product'
AND order_date < '2024-01-01'
GROUP BY user_id
),
new_product AS (
SELECT
user_id,
COUNT(order_id) AS new_orders,
SUM(revenue) AS new_revenue
FROM orders
WHERE product_id = 'new_product'
AND order_date >= '2024-01-01'
GROUP BY user_id
)
SELECT
o.user_id,
o.old_orders,
n.new_orders,
o.old_revenue,
n.new_revenue,
CASE
WHEN o.old_orders > 0 AND n.new_orders > 0 AND n.new_revenue < o.old_revenue
THEN 'Перешли, но платят меньше'
WHEN o.old_orders > 0 AND n.new_orders > 0 AND n.new_revenue >= o.old_revenue
THEN 'Перешли, но выручка сохранилась'
WHEN o.old_orders > 0 AND n.new_orders = 0
THEN 'Остались на старом'
WHEN o.old_orders = 0 AND n.new_orders > 0
THEN 'Новый клиент'
ELSE 'Нет активности'
END AS user_behavior
FROM old_product o
LEFT JOIN new_product n ON o.user_id = n.user_id;
1. Перешли, но платят меньше → Упали чеки, возможно, продукт слишком дешевый или не дает ценности. Нужно тестировать upsell, дополнительные возможности для продажи товаров / услуг, рост GMV, маржинальности
2. Остались на старом → Им новый продукт не нужен? Разбираемся, что именно их удерживает. Возможно, просто пользователи привыкли к другому продукту, а пересаживаться не видят смысла
3. Мало новых клиентов → Новый продукт не привлекает новую аудиторию. Возможно, нужно менять маркетинг, коммуникацию с пользователями. Доносить понятные смыслы
Бизнес думает, что новый продукт приносит деньги, но на самом деле пользователи просто перераспределяются.
UPD: для оценки каннибализации честнее всего запустить 🆎
Please open Telegram to view this post
VIEW IN TELEGRAM
[пост с линкедин]
Нашел на линкедине пост, посвященный уничтожению чемпиона в своей команде. Сталкивались ли с этим в команде? Что думаете? Пишите в комментариях
Нашел на линкедине пост, посвященный уничтожению чемпиона в своей команде. Сталкивались ли с этим в команде? Что думаете? Пишите в комментариях
Заскуль питона (Data Science)
Материалы для прокачки навыков в pandas для начинающих 🐼 [ч. 1] Хотите прокачаться в pandas, но не знаете, с чего начать? Собрал полезные инструменты, шпаргалки и ресурсы, которые помогут вам разобраться во всем шаг за шагом! Можно основные операции потыкать…
Материалы для прокачки навыков в Polars для начинающих
Написал я пост про Pandas, теперь напишу про Polars, чтобы было логическое продолжение
🐼 Если вы работаете с большими данными и устали ждать, пока Pandas обработает ваш запрос, стоит попробовать Polars.
Это быстрый, многопоточный, ленивый (в хорошем смысле) и оптимизированный инструмент для работы с таблицами. Используется дата-инженерами и аналитики.
❓ С чего начать?
1. Официальная документация – базовые концепции и API docs.pola.rs
2. Подробный гайд по Polars с примерами – разбор синтаксиса и возможностей Polars Book (GitHub)
3. Работа со строками в Polars – как делать обработку текстов, разбирать email-адреса, чистить данные и т.д. Статья на Towards Data Science
4. Шпаргалка в Jupyter Notebook – можно сразу потыкать основные команды Cheat Sheet
5. Шпаргалка в PDF (с визуализацией для лучшего усвоения) - PDF Cheat Sheet
Но стоит отметить, что в индустрии чаще всего используют для работы с большими даннными PySpark. Настройка приложений, различные запросы, ML-методы с PySpark и т. д.
❤️🔥 Наберем 100 реакций, выложу такую же подборку по PySpark
Используете ли вы Polars? Пишите в комментариях
#дляначинающих@zasql_python
Написал я пост про Pandas, теперь напишу про Polars, чтобы было логическое продолжение
Это быстрый, многопоточный, ленивый (в хорошем смысле) и оптимизированный инструмент для работы с таблицами. Используется дата-инженерами и аналитики.
1. Официальная документация – базовые концепции и API docs.pola.rs
2. Подробный гайд по Polars с примерами – разбор синтаксиса и возможностей Polars Book (GitHub)
3. Работа со строками в Polars – как делать обработку текстов, разбирать email-адреса, чистить данные и т.д. Статья на Towards Data Science
4. Шпаргалка в Jupyter Notebook – можно сразу потыкать основные команды Cheat Sheet
5. Шпаргалка в PDF (с визуализацией для лучшего усвоения) - PDF Cheat Sheet
Но стоит отметить, что в индустрии чаще всего используют для работы с большими даннными PySpark. Настройка приложений, различные запросы, ML-методы с PySpark и т. д.
Используете ли вы Polars? Пишите в комментариях
#дляначинающих@zasql_python
Please open Telegram to view this post
VIEW IN TELEGRAM
❤98 16🐳13❤🔥7 6
Что такое RFM-анализ и как он помогает сегментировать пользователей
У нас есть продукт, в котором мы хотим более точно сегментировать пользователей по их активности в приложении.
Есть различные методы сегментации, например, на уровне городов, приложения, какого-то другого признака.
В данном посте мы рассмотрим RFM-анализ.
Если вкратце мы разбиваем пользователей на сегменты на основе:
⌛️ R (Recency) - давности последней покупки (например, в днях)
🥳 F (Frequency) - общее количество покупок покупок.
🤑 M (Monetary) - сумма денег, потраченная пользователей.
Про присваиваемость сегментов:
1. Выбираем период анализа, например, последние 90 дней.
2. Определяется количество сегментов (обычно от 3 до 5 по одному из пунктов). Максимум X³ комбинаций, если делим каждую метрику на X частей.
Пояснение к п.2: Если у нас Monetary от 0 до 3000, а сегментов планируется 3, то трешхолды для определения сегментов: 1 - (0, 1000], 2 - (1000, 2000], 3 - (2000, 3000]. Аналогично и для других.
Пример сегмента на выходе: 111 - спящий, мало покупающий. 333 - частотник, много покупает и на большую сумму
3. По трешхолдам равномерно разбитым определяем сегменты
4. В дальнейшем можно понять кто чаще отваливается, как ведут себя в приложении топ-платящие и где есть узкие места в воронке.
Подойдет не каждому бизнесу, так как важно количество пользователей, а их может быть недостаточно
😊 Дополнительные материалы:
1. link1
2. link2
3. link3
А вы применяете RFM-анализ? Как относитесь к данному методу сегментации?
У нас есть продукт, в котором мы хотим более точно сегментировать пользователей по их активности в приложении.
Есть различные методы сегментации, например, на уровне городов, приложения, какого-то другого признака.
В данном посте мы рассмотрим RFM-анализ.
Если вкратце мы разбиваем пользователей на сегменты на основе:
Про присваиваемость сегментов:
1. Выбираем период анализа, например, последние 90 дней.
2. Определяется количество сегментов (обычно от 3 до 5 по одному из пунктов). Максимум X³ комбинаций, если делим каждую метрику на X частей.
Пример сегмента на выходе: 111 - спящий, мало покупающий. 333 - частотник, много покупает и на большую сумму
3. По трешхолдам равномерно разбитым определяем сегменты
4. В дальнейшем можно понять кто чаще отваливается, как ведут себя в приложении топ-платящие и где есть узкие места в воронке.
Подойдет не каждому бизнесу, так как важно количество пользователей, а их может быть недостаточно
1. link1
2. link2
3. link3
А вы применяете RFM-анализ? Как относитесь к данному методу сегментации?
Please open Telegram to view this post
VIEW IN TELEGRAM
🐳22 7 7❤4👍1
Используете ли вы LLM в аналитике? (или просто для продакшн-решений)
🗯 Многие уже применяют их в повседневной работе: ускоряют написание кода, SQL, помогают с формулировками гипотез, объясняют пайплайны, адаптируют текст под бизнес — это, кажется, уже стало базовым инструментом. Иногда, сталкиваемся с такими крайностями, как vibe code, когда просто копируются и вставляются ошибки с готово решения под разные модели GPT.
💭 Интересен другой кейс, как по мне. Задачи, где модель помогала не только вам, но и влиянию на сам процесс? Например, сбор ассистента, который отвечает за какой-то контекст бизнеса на основе скормленной документации / правил, или автоматизация аналитических выводов из отзывов пользователей / на основе имеющихся данных. Это может быть не просто базовый чат-бот, но и инструмент с возможностью разметки, решения задач на основе различных агентов (DeepSeek, OpenAI и др.).
Первый вариант понятен, этим пользуются почти все (поправить что-то, сделать под себя). Но во втором случае интересно: доводили ли вы такие проекты до MVP или продакшена? Или, может, делали ресёрч, который показал потенциал, но не стал продуктом?
🐳 Если тема зайдёт, хочу собрать отдельный пост с кейсами: где и как можно использовать LLM в аналитике, какие проекты реально работают. Возможно, даже попробую собрать простой продакшн-пример — и описать, где он может быть уместен.
Первый вариант понятен, этим пользуются почти все (поправить что-то, сделать под себя). Но во втором случае интересно: доводили ли вы такие проекты до MVP или продакшена? Или, может, делали ресёрч, который показал потенциал, но не стал продуктом?
Please open Telegram to view this post
VIEW IN TELEGRAM
🐳51 8 6👍2
LLM-агенты [https://huggingface.co/blog/open-source-llms-as-agents#what-are-agents] [ч.1]
LLM-агенты — это все системы, которые используют LLM в качестве своего механизма и могут выполнять действия в окружающей среде на основе наблюдений. Они могут использовать несколько итераций цикла «Восприятие ⇒ Рефлексия ⇒ Действие» для выполнения своей задачи и часто дополняются системами планирования или управления знаниями для повышения своей эффективности.
На картинке изображен ReAct (рассуждать и действовать) предлагается рассмотреть архитектуру с сохранением памяти на основе запроса и промпт складывать из имеющегося контекста. По сути как в ChatGPT, но тут еще дополнительно возникает проверка при решении задачи. То есть по сути до тех пор, пока задача не будет решена, мы будем добавлять дополнительного контекста
1. input
2. LLM размышляет
3. LLM вызывает инструмент
4. Инструмент возвращает результат
Решение базовых проблем
> кормить качественным контекстом
> хорошо описывать имеющиеся инструменты (например, таблицы, запросы и др.)
> использовать определенные сценарии
> рабочая память, валидация результатов агентом
> использовать память
Вместо угадываний LLM будет учиться выполнять задачи пошагово и подход в дальнейшем можно масштабировать). В этой статье представлен еще код того, как можно интегрировать библиотеки Hugging Face для создания агентов через LangChain.
Понравился такой формат поста? Ставьте реакции! Продолжу дальше писать про LLM и агентов, сейчас небольшое погружение
LLM-агенты — это все системы, которые используют LLM в качестве своего механизма и могут выполнять действия в окружающей среде на основе наблюдений. Они могут использовать несколько итераций цикла «Восприятие ⇒ Рефлексия ⇒ Действие» для выполнения своей задачи и часто дополняются системами планирования или управления знаниями для повышения своей эффективности.
На картинке изображен ReAct (рассуждать и действовать) предлагается рассмотреть архитектуру с сохранением памяти на основе запроса и промпт складывать из имеющегося контекста. По сути как в ChatGPT, но тут еще дополнительно возникает проверка при решении задачи. То есть по сути до тех пор, пока задача не будет решена, мы будем добавлять дополнительного контекста
1. input
Here is a question: "How many seconds are in 1:23:45?"
You have access to these tools:
- convert_time: converts a time given in hours:minutes:seconds into seconds.
You should first reflect with ‘Thought: {your_thoughts}’, then you either:
- call a tool with the proper JSON formatting,
- or your print your final answer starting with the prefix ‘Final Answer:’
2. LLM размышляет
Thought: I need to convert the time string into seconds.
3. LLM вызывает инструмент
Action:
{
"action": "convert_time",
"action_input": {
"time": "1:23:45"
}
}
4. Инструмент возвращает результат
Thought: I now have the information needed to answer the question.
Final Answer: There are 5025 seconds in 1:23:45.
Решение базовых проблем
> кормить качественным контекстом
> хорошо описывать имеющиеся инструменты (например, таблицы, запросы и др.)
> использовать определенные сценарии
> рабочая память, валидация результатов агентом
> использовать память
Вместо угадываний LLM будет учиться выполнять задачи пошагово и подход в дальнейшем можно масштабировать). В этой статье представлен еще код того, как можно интегрировать библиотеки Hugging Face для создания агентов через LangChain.
Понравился такой формат поста? Ставьте реакции! Продолжу дальше писать про LLM и агентов, сейчас небольшое погружение
🐳17 5❤4👍4🔥2 2
Предположим, у нас есть таблица с заказами и пользовательскими событиями (по последнему мы получаем данные по DAU / WAU / MAU, например).
1) orders:
user_id | order_id | gmv | date
user_id - id пользователя
order_id - id заказа
gmv - стоимость заказа (для пользователя)
date - дата оплаты заказа
2) actions:
user_id | action_name | date
user_id - id пользователя
action_name - обычно таблица с событиями (сюда льются любые заходы пользователя в приложении)
date - дата экшна
-- Считаем ARPU и ARPPU за март 2025 года
WITH
-- Количество уникальных активных пользователей (по действиям)
active_users AS (
SELECT COUNT(DISTINCT user_id) AS active_user_count
FROM actions
WHERE date BETWEEN '2025-03-01' AND '2025-03-31'
),
-- Количество уникальных платящих пользователей (по заказам)
paying_users AS (
SELECT COUNT(DISTINCT user_id) AS paying_user_count
FROM orders
WHERE date BETWEEN '2025-03-01' AND '2025-03-31'
),
-- Общая выручка за период
total_revenue AS (
SELECT SUM(gmv) AS gmv_total
FROM orders
WHERE date BETWEEN '2025-03-01' AND '2025-03-31'
)
-- Финальный расчёт метрик ARPU и ARPPU
SELECT
ROUND(gmv_total * 1.0 / active_user_count, 2) AS arpu, -- Средняя выручка на активного пользователя
ROUND(gmv_total * 1.0 / paying_user_count, 2) AS arppu -- Средняя выручка на платящего пользователя
FROM total_revenue
CROSS JOIN active_users
CROSS JOIN paying_users;
Например, ARPU = 100 ₽, ARPPU = 500 ₽ => платит только каждый 5-й.
Если рассматривать их в связке, можно понять за счёт чего растёт выручка: за счёт увеличения числа платящих (растёт ARPU, ARPPU на месте) или за счёт того, что каждый платящий стал платить больше (растут оба).
Обычно, при проведении экспериментов смотрят за ARPU (так как принимается решения по внедрению фичи не на срезе платящих, а не срезе всего приложения).
ARPU чувствительнее к изменениям в конверсии в оплату, а ARPPU — к изменениям в поведении уже платящих.
#дляначинающих@zasql_python
Please open Telegram to view this post
VIEW IN TELEGRAM
Глобальный контроль — кто это вообще и зачем он нужен?
😍 В практически любом приложении на вашем телефоне проводятся тысячи экспериментов за год на различных поверхностях / в различных направлениях. Как для пользователя изменения могут быть заметными, а могут вообще ни на что не влиять. Представьте, что вы попали в группу, в которой вообще ничего не происходит длительное время (то есть каких-то новых фичей не выкатывается). Если это так, знайте, что вы попали в глобальный контроль.
🥳 Раз в определенное время на различных срезах бизнеса (или вообще во всем бизнесе) отбирается небольшой процент пользователей, у которых вообще ничего не происходит. Например, в глобальном контроле представлены пользователи, которым не будет отправляться коммуникация (это может быть нам нужно для оценки тех коммуникаций, которые будут спустя время). Список пользователей может быть статичным и обновляться раз в какое-то время.
❗️ Тут важно, чтобы глобальный контроль оставался репрезентативным и отражал поведение всей аудитории. Но со временем поведение пользователей может меняться: кто-то уходит, кто-то становится менее активным, и группа теряет однородность. Поэтому её периодически пересобирают: делают новую случайную выборку.
🙅♂️ Зачем это нужно?
Когда мы проводим A/B эксперимент, мы смотрим на фактическую дельту между контролем и тестом. То, насколько изменилась метрика при внедрении какой-то фичи на целевом срезе (на чекауте / корзине / главной / в поиске и так далее). Получили значимый эффект, раскатили, зафиксировали эффект. По факту комбинация раскатанных вариантов не равняется простой фиксации эффекта в эксперименте. Глобальный контроль позволяет оценить долгосрочный эффект от выкаченных изменений + мы можем замерить реальный глобальный аплифт. Короткие интервалы помогают заметить локальные проблемы, а длинные — увидеть общую картину и оценить полный эффект. Также глобальный контроль позволяет поймать перекрестные эффекты, которые вместе дают негативный эффект (это как раз про оценку суммарного эффекта).
А у вас в компании есть глобальный контроль? Анализировали долгосрочный эффект от внедрения фичей в нашем направлении? Делитесь в комментариях кейсами)
❗️ Тут важно, чтобы глобальный контроль оставался репрезентативным и отражал поведение всей аудитории. Но со временем поведение пользователей может меняться: кто-то уходит, кто-то становится менее активным, и группа теряет однородность. Поэтому её периодически пересобирают: делают новую случайную выборку.
Когда мы проводим A/B эксперимент, мы смотрим на фактическую дельту между контролем и тестом. То, насколько изменилась метрика при внедрении какой-то фичи на целевом срезе (на чекауте / корзине / главной / в поиске и так далее). Получили значимый эффект, раскатили, зафиксировали эффект. По факту комбинация раскатанных вариантов не равняется простой фиксации эффекта в эксперименте. Глобальный контроль позволяет оценить долгосрочный эффект от выкаченных изменений + мы можем замерить реальный глобальный аплифт. Короткие интервалы помогают заметить локальные проблемы, а длинные — увидеть общую картину и оценить полный эффект. Также глобальный контроль позволяет поймать перекрестные эффекты, которые вместе дают негативный эффект (это как раз про оценку суммарного эффекта).
А у вас в компании есть глобальный контроль? Анализировали долгосрочный эффект от внедрения фичей в нашем направлении? Делитесь в комментариях кейсами)
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9 9 5
Что такое Retriever и зачем он нужен?
На схеме изображен классический вариант RAG (Retrieval Augmented Generation). Retrieved contexts получен с помощью Retriever поверх Vector Store.
Предобученная LLM (например, ChatGPT) знает уже много — она обучалась на огромном корпусе данных: сайты, книги, коды, форумы, всё подряд. Но у такой модели есть одна большая проблема: Она не знает ничего про внутренний контекст компании: как у тебя считаются метрики, какие A/B тесты были, как устроены ключевые таблицы. Чтобы LLM могла использовать знания из своей компании — ей нужно их передавать.
Retriever — это компонент, который вытаскивает только релевантную информацию, может быть интегрирован с собственной базой знаний (PDF, CSV, SQL, Confluence и др.), и может работать с LLM на основе релевантного контекста. На сайте LangChain можно посмотреть более подробно про основные концепции Retrievers + вот тут посмотреть какие вообще реализованы у LangChain
Пайплайн работы с Retriever
1. Загрузка документов (файлы, базы, статьи). Все, что мы считаем нужным для решения задачи. От черновиков дло
2. Разбиваем их на части (чанки) для индексации
3. Преобразуем текст в векторное представление (через эмбеддинги)
4. Сохраняем в векторную базу (Vector Store) — например, в FAISS или Chroma
5. По запросу — находим ближайшие куски текста, которые помогут модели ответить
Retriever делает семантический поиск по смыслу, а не просто по словам.
На LangChain можно реализовать достаточно быстро + покрутить эмбеддинги. Также советую от OpenAI ресурс, в котором можно посмотреть сколько токенов нужно для обработки вопроса (контекст мы также учитываем). Для апишки получается дешевле доставать релевантные данные с помощью ретривера и пулять дальше запрос.
Выше реализован single-shot RAG (одна проходка и ответ из базы). В дальнейшем напишу про виды RAG и чем они отличаются)
Какие бывают типы Retrieval? [статья с хабра]
1. Sparse Retrieval — классический полнотекстовый поиск
Примеры: TF‑IDF, BM25
Базы: PostgreSQL (GIN), Apache Solr, Whoosh
2. Dense Retrieval — семантический поиск через нейросети
Примеры: BERT, word2vec, e5-multilingual, OpenAI
Базы: ChromaDB, FAISS, Pinecone, Qdrant, Milvus
3. Hybrid Retrieval — комбинация sparse + dense
Примеры: ElasticSearch с плагином, Qdrant, PostgreSQL с pgvector
4. Graph Retrieval — поиск по графам знаний (use case: связи между объектами)
Примеры: Neo4j, Weaviate, ArangoDB, TigerGraph.
Далее релевантно описать про дробление документа на чанки, все зависит от того, насколько вам заходит такие посты, ставьте реакции.
🤖 — Да, интересно читать про LLM, давай дальше!
🦜 — Давай лучше про A/B тесты (это бежит попугайчик LangChain)
На схеме изображен классический вариант RAG (Retrieval Augmented Generation). Retrieved contexts получен с помощью Retriever поверх Vector Store.
Предобученная LLM (например, ChatGPT) знает уже много — она обучалась на огромном корпусе данных: сайты, книги, коды, форумы, всё подряд. Но у такой модели есть одна большая проблема: Она не знает ничего про внутренний контекст компании: как у тебя считаются метрики, какие A/B тесты были, как устроены ключевые таблицы. Чтобы LLM могла использовать знания из своей компании — ей нужно их передавать.
Retriever — это компонент, который вытаскивает только релевантную информацию, может быть интегрирован с собственной базой знаний (PDF, CSV, SQL, Confluence и др.), и может работать с LLM на основе релевантного контекста. На сайте LangChain можно посмотреть более подробно про основные концепции Retrievers + вот тут посмотреть какие вообще реализованы у LangChain
Пайплайн работы с Retriever
1. Загрузка документов (файлы, базы, статьи). Все, что мы считаем нужным для решения задачи. От черновиков дло
2. Разбиваем их на части (чанки) для индексации
3. Преобразуем текст в векторное представление (через эмбеддинги)
4. Сохраняем в векторную базу (Vector Store) — например, в FAISS или Chroma
5. По запросу — находим ближайшие куски текста, которые помогут модели ответить
Retriever делает семантический поиск по смыслу, а не просто по словам.
На LangChain можно реализовать достаточно быстро + покрутить эмбеддинги. Также советую от OpenAI ресурс, в котором можно посмотреть сколько токенов нужно для обработки вопроса (контекст мы также учитываем). Для апишки получается дешевле доставать релевантные данные с помощью ретривера и пулять дальше запрос.
from langchain_community.document_loaders import TextLoader
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings
from langchain_text_splitters import CharacterTextSplitter
from langchain.chains import RetrievalQA, ConversationalRetrievalChain
loader = TextLoader("text_for_gpt.txt")
documents = loader.load()
text_splitter = CharacterTextSplitter(chunk_size=1000, chunk_overlap=0)
texts = text_splitter.split_documents(documents)
embeddings = OpenAIEmbeddings()
vectorstore = FAISS.from_documents(texts, embeddings)
retriever = vectorstore.as_retriever()
llm = ChatOpenAI(model="gpt-3.5-turbo")
qa_chain = RetrievalQA.from_chain_type(llm=llm, retriever=retriever)
response = qa_chain.invoke({"query": 'О чем статья? Расскажи вкратце'})
print(response["result"])
Выше реализован single-shot RAG (одна проходка и ответ из базы). В дальнейшем напишу про виды RAG и чем они отличаются)
Какие бывают типы Retrieval? [статья с хабра]
1. Sparse Retrieval — классический полнотекстовый поиск
Примеры: TF‑IDF, BM25
Базы: PostgreSQL (GIN), Apache Solr, Whoosh
2. Dense Retrieval — семантический поиск через нейросети
Примеры: BERT, word2vec, e5-multilingual, OpenAI
Базы: ChromaDB, FAISS, Pinecone, Qdrant, Milvus
3. Hybrid Retrieval — комбинация sparse + dense
Примеры: ElasticSearch с плагином, Qdrant, PostgreSQL с pgvector
4. Graph Retrieval — поиск по графам знаний (use case: связи между объектами)
Примеры: Neo4j, Weaviate, ArangoDB, TigerGraph.
Далее релевантно описать про дробление документа на чанки, все зависит от того, насколько вам заходит такие посты, ставьте реакции.
Please open Telegram to view this post
VIEW IN TELEGRAM