Что такое 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 ресурс, в котором можно посмотреть сколько токенов нужно для обработки вопроса (контекст мы также учитываем). Для апишки получается дешевле доставать релевантные данные с помощью ретривера и пулять дальше запрос.

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.

Далее релевантно описать про дробление документа на чанки, все зависит от того, насколько вам заходит такие посты, ставьте реакции.

🤖 — Да, интересно читать про LLM, давай дальше!
🦜 — Давай лучше про A/B тесты (это бежит попугайчик LangChain)

🚨 SRM в A/B тестах: когда не совпадают доли, и что с этим делать

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

Sample Ratio Mismatch (SRM) — несоответствие фактических долей заданным.

😢 Пример:

Ожидание:

control — 50%
test — 50%

Реальность:

control — 62%
test — 38%

🧐 Почему так могло произойти?

1. Что-то не то со сплитованием в A/B-шнице (последнее на что можно подумать, если платформа не только что разработана). Могут быть проблемы со сплитовалкой на уровне разработки, но также маловероятный сценарий.
2. Логи определения групп пользователей настроены некорректно. Вероятный сценарий. Могли определить неправильно веса групп, выкатить только на определенные девайсы, неправильно настроено определение групп (в тест / контроль попадают пользователи с разным распределением метрики при верной H0).

😎 Как это можно быстро проверить?

Предположим, что у нас есть таблица, куда складываются логи пользователей с группами, можно посмотреть на количество пользователей в каждой группе. Тут можно просто глазами просмотреть (что ожидали на дизайне vs то, что получили по факту, какое соотношение).

SQL

SELECT
    variant,
    COUNT(DISTINCT user_id) AS users
FROM
    experiment_assignments
WHERE
    experiment_name = 'new_checkout_flow'
    AND assignment_time BETWEEN '2025-04-01' AND '2025-04-10'
GROUP BY
    variant;

🐍 А с помощью Python можно воспользоваться критерием хи-квадрат. Он показывает расхождение между наблюдаемым распределением в выборке и ожидаемым распределением, которое предполагалось в эксперименте. На основе статистики мы понимаем является ли расхождение критичным или нет.

Возьмем пример из начала на 10 000 наблюдений с фактическим разбросом.

from scipy.stats import chisquare

observed = [6200, 3800]  
total = sum(observed)
expected = [total / 2, total / 2]  

_, p_value = chisquare(f_obs=observed, f_exp=expected)

if p_value < 0.05:
    print("SRM")
else:
    print("NO SRM")

Вообще на каждом эксперименте можно поставить автоматическую проверку (на предмет валидности расчетов). Ожидаемое vs Фактическое.

Немного про проверку гипотез при Chi-Square

H0: Распределение пользователей между вариантами эксперимента соответствует ожидаемым долям (например, 50 / 50).
H1: Распределение пользователей отличается от ожидаемого.

Если p-value < 0.05, мы отвергаем H0 => SRM есть.
Если p-value >= 0.05, оснований отвергать H0 нет => распределилось все как и ожидалось.

😘 Всегда проверяйте SRM до метрик. Это простая проверка, которая спасёт ваш эксперимент.

Ставьте реакции если:

🐳 — пост понравился!

🤡 — пойдет)

Отладка SQL-запросов

⌛️ Большую часть времени аналитики пишут скрипты в определённой СУБД: достают оттуда данные для моделей, отчётности, выгрузок, продуктовых исследований и прочих задач. Предположим, ты начал строить большую витрину, которая должна покрывать бизнес-потребности.

Всё идёт нормально, но вдруг:

1. Нет записей, хотя должны быть / записей стало меньше

2. Данные задвоились

3. Результаты не сходятся с дашбордом / другой внутренней системой (например, в 1С / сервисе заказов и тд)

____

Этот пост - про быструю и понятную отладку SQL-запросов, особенно если он уже раздулся на тысячи строк.

1️⃣ Начало с верхнеуровневой структуры

Если в коде есть подзапросы, лучше переписать их на CTE / временные таблицы. Так код легче читать и отлаживать по шагам.

Простой подзапрос:

select ...
from (
   select ...
   from orders
   where ...
) t
join ...

CTE:

with filtered_orders AS (
    select ...
    from orders
    where ...
)
select ...
from filtered_orders
join ...

Стало чуточку проще читать + можно проверить, что в filtered_orders, следующий шаг про это

2️⃣ Проверка CTE или временных таблиц

Здесь мы проверяем количество строк / уникальных сущностей по типу order_id / user_id, проверяем на пустые значения

select count(*) as total_rows,
       count(distinct user_id) as unique_users
from filtered_orders;

3️⃣ Спускаемся глубже, смотрим с какого момента началась проблема (идем внутрь запроса)

Что нас ждет внутри? Джойны / оконные функции / группировки.

Хорошая практика - это посмотреть, задублировались ли ключи, по которым будет в дальнейшем JOIN

select o.order_id, count(*) as cnt
from orders o
join transactions t on o.order_id = t.order_id
group by o.order_id
having count(*) > 1;

Если дублируется, то надо ответить на вопрос: ожидаемое это поведение или нет? Если проблема, то следующий шаг.

4️⃣ Контроль за дублями

Базовая проблема: в одной таблице ключ уникален, в другом нет (можно, например, предагрегировать, используя row_number() / distinct / group by

with transaction_agg as (
  select order_id, sum(amount) as total_amount
  from transactions
  group by order_id
)
select o.order_id, t.total_amount
from orders o
left join transaction_agg as t ON o.order_id = t.order_id;

А если так нельзя схлопнуть, можно атрибуцировать за какой-то промежуток времени и связывать по дню, например

5️⃣Хорошая и простая практика: посмотреть глазами

Берем значение ключа, по которому связываем и смотрим, как дублируется, из-за чего. Возможно, на транзакции приходится несколько записей с типом оплаты (и это надо предусмотреть)

select *
from orders o
join transactions t on o.order_id = t.order_id
where o.order_id = 'abc123';

6️⃣Последнее

Действительно я понимаю данные, которые используются при сборе витрины?

Бывают разные сущности, но хочется понимать как мы закрываем бизнес-задачу, используя именно ЭТИ данные (тут про смысл аналитического мышления / бизнес-смысла и смысла данных

Понравился формат поста? Ставьте 🔥, пишите комментарии, какие пункты еще стоит добавить

Продуктовому аналитику важно уметь решать продуктовые кейсы. Это навык, который проверяют на собеседованиях, обсуждают на встречах с продактами и тренируют в работе каждый день.

Недавно наткнулся на воркшоп с разбором реальных продуктовых кейсов — практичная штука (там есть ответы + годные мысли).

Структурность ответа — показатель успеха. Весь кейс должен быть структурным, все должно быть связано (на это я сам натыкался, когда получал фидбеки по продуктовым секциям). Может быть очень сильный поток мысли, а структуры, которая может помочь в решении — нет.

1️⃣ Кейс

Вы продакт, который отвечает за корзину и метрики корзины.

Одна из ваших метрик — это доля выкупа заказанных вещей, т.е. те вещи, которые выкупил пользователь, которые заказал.

🍪🍪 Например, человек может заказать 10 вещей, но выкупить 4 штуки, а 6 уедет обратно.

Представим, что показатель процента невыкупленных товаров находится на уровне 10% — это означает, что 10 процентов пользователей не выкупают товар который заказал.

⬆️ Наступил май, и данный показатель стал аккуратно расти 12-15-20-25 процентов.

😨 В течение 2 недель дорос до 30 процентов.

И нужно разобраться куда копать и что смотреть, чтобы понять?

Какие гипотезы могут быть и повлияли на текущую ситуацию?

Если скажешь про A/B-тест. Не уверен в гипотезе, но готов тратить деньги. Важно проерить гипотезу без разработки, а на что можно посмотреть уже сейчас

Давайте проведем исследования, опрос, A/B тестирование выглядит странно, нужно обращаться к прокси-метрикам

2️⃣ Кейс

Вы продакт одного из классифайдов, отвечаете за звонки/контакты.

🤪 Основная задача: сделать так, чтобы эти метрики росли и не падали.

Другая команда решила добавить в выдаче на карточку оффера — отзывы о продавце, т.е. начала показывать рейтинг того или иного продавца (раньше, он был спрятан в карточке).

🆎 Другая команда по честному провела A/B тест, и получилось так, что A/B Тест уменьшил количество контактов на 30%.

🔽Ваша целевая метрика (контакты) упала.

Что делать с A/B-Тестом и на основе чего принять решение?

3️⃣ Кейс

Вы продакт какого-то классифайда (например, Недвижимость) и так получилось, что вы отвечаете за всю выручку данного классифайда.

У вас есть несколько сильных конкурентов, и вы не один на рынке, ваши услуги стоят достаточно дорого, дороже чем у других = вы самые дорогие.

📰 Основной способ заработка, это публикация объявления и дополнительное продвижение.

Публикация объявления, составляет около 80% всей прибыли сервиса.

Значительная часть ежегодного прироста выручки обеспечивается за счет повышения цен 2 раза в год.

😏 Придумать стратегию, которая позволит направлению вырасти на 20-30 по выручке в ближайший год, не потеряв долю относительно конкурентов.

Подумайте, как бы вы ответили на каждый из кейсов. Что проверили бы? Какие данные подняли бы в первую очередь?
Такие вопросы часто встречаются на собеседованиях — полезно поразмышлять и прокачать продуктовое мышление.

Если пост соберёт 100 🔥, расскажу, как я сам проходил собеседования с продуктовыми кейсами — какие были вопросы, как готовился и что помогло.

Ищу потенциальные точки роста в продукте — и как раз попалась статья про полезный список подходов, которые можно адаптировать под свой продукт.

📈 Что относится к продуктовому росту

Входит:

— Задачи, которые напрямую влияют на метрики продукта: CR, Retention, активацию, LTV
— Оптимизация UX, фичи с прикладной пользой (да, те самые “циничные”)
— CRM и триггерные коммуникации
— Работа с офферами, подписками, монетизацией
— A/B тесты и проверка гипотез

Не входит:

— Фичи для имиджа и роста NPS без понятного влияния на поведение
— Внешний маркетинг и рекламные кампании (включая перфоманс)

Три направления продуктового роста + ключевые механики

1️⃣ Привлечение и активация
🤩 Задача: помочь новичку быстро получить первую ценность

🟣Персонализированный онбординг

первые шаги адаптируются под пользователя: интересы, цели, поведение. Такой подход снижает “барьер входа”, увеличивает вовлечённость и показывает, что продукт понимает нужды пользователя.

🟣Aha-момент за 30 секунд

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

🟣Прогресс-бар

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

🟣Онбординг-напоминалки

помогает вернуть человека и мягко сконвертировать в активацию. Тут нужна добавленная ценность

Цель: удержать пользователя, чтобы он понял ценность.

2️⃣ Удержание и возвращение
🐸 Задача: сделать так, чтобы пользователь возвращался и не отваливался

🔵Daily rewards и челленджи — причины зайти каждый день (Например, это реализовано у Duolingo или Yazio).

🔵Персональные рекомендации — показываем релевантный контент или товары (Сейчас в это идут все сервисы, больше персонализации)

🔵Семейные подписки — люди остаются ради общего опыта и экономии (Кинопоиск с возможонстью просмотра для всей семьи)

🔵Winback-офферы — пуш/письмо с персональным предложением тем, кто ушёл (Коммуникация на отточников).

🔵Заморозка подписки — альтернатива отмене, снижает отток (Например, Duolingo или приложения с игровой механикой).

Цель: дать ощущение пользы и повода вернуться

3️⃣ Монетизация и LTV
🤑 Задача: зарабатывать больше с каждого пользователя

🟡Freemium + пробный доступ — вовлечь сначала, продать потом

обычно пользователям предоставляют 7-30 дней для пользования плюшками продукта

🟡Апгрейд через ценность — дать попробовать premium, чтобы захотелось остаться

работает как часть freemium или отдельно: пользователю предлагают временный апгрейд до премиум-версии без ограничений)

🟡Кросс-продажи — показать сопутствующие товары/фичи

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

🟡Лёгкие подписки / микроплатежи — сниженный порог входа

механика снижения болевого порога: вместо годовой подписки за X можно предложить месячную за X / k

😍 Цель: увеличить выручку не только количеством, но и качеством

Yango Play:
Первый год — привлечение
Второй год — активация
Третий год — удержание и выручка

Примеры продуктового роста других компаний

🔵Dropbox — рост через рефералку
🟣Проблема: дорогая реклама
🟡Решение: двухсторонняя реферальная система (бонус за приглашение)
🟢Результат: +60% регистраций, кратное снижение CAC

🔵Superhuman — элитность через waitlist
🟣Проблема: конкуренция с Gmail
🟡Решение: доступ только по инвайту, индивидуальный онбординг
🟢Результат: высокий LTV, искусственный дефицит → рост

🔵ConvertKit — рост через авторов
🟣Проблема: конкуренция с Mailchimp
🟡Решение: ниша блогеров + «значок» в email-подписи
🟢Результат: органический рост, лояльная аудитория

🔵Calendly — вирусность через встречи
🟣Проблема: как вовлечь новых пользователей
🟡Решение: бесплатные встречи + брендинг в ссылке
🟢Результат: каждая встреча — новая точка роста

А какие подходы применяете вы в продукте? Ставьте 🔥 и буду дальше писать про продуктовые штуки!

Поиск роста для аналитика в компании через освоение нового

Сидишь на одном месте, думаешь, что развитие вышло на плато и не знаешь, что делать.

🔽 Тебе может казаться, что ты начинаешь деградировать, а спрос на тебя как специалиста понемногу угасает.

Это может касаться разных сторон того, что хочется прокачать.

👍 Сюда можно отнести:

🟢Работу с новыми инструментами. Например, хочешь освоить Kafka, Hadoop, Airflow.
🟡Новые подходы. Например, применение A/B тестов, ML, Deep Learning, GPT в бизнес-процессах.
🟣Бизнес аспекты. Хочешь развиваться в e-com, e-grocery дальше, но не понимаешь почему вообще возникают те или иные задачи, общий контекст не складывается в голове
...
список можно дополнять в зависимости от своих интересов.

Когда задумываешься о своих точках роста, приходит понимание:

💲 Важно уметь показывать свою ценность — не только на этапе найма, но и в ежедневной работе.

Итак, мы выделили зону, где хочется развиваться, например, использование новых подходов.

Тут есть 2 варианта:

1️⃣ В компании есть наработки, а в команде нет. Нужно изучить существующие наработки в компании, понять, как их можно адаптировать под задачи своей команды, и предложить первый тестовый кейс на знакомой бизнес-проблеме. Возможно, применение ML поможет быстрее находить инсайты, а A/B тесты — честно замерять эффекты.

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

Бывало ли у вас ощущение, что развитие застопорилось?

Поставьте 🔥, если тема откликается! Делитесь в комментариях своими кейсами поиска роста 🙏

💡 Хочу собрать продуктовые кейсы и в дальнейшем разобрать тут

Очень часто аналитиков учат SQL, Python, визуализации. Но почти не учат думать о продукте и бизнесе: зачем метрика выросла, как устроен флоу решений, почему фича провалилась.

📊 Поэтому я собираю продуктовые кейсы — из разных компаний, команд и контекстов. Чтобы потом разобрать их и сделать нормальную базу практики.

Примеры задач, которые подходят:

1. продуктовая задача с собеседований
2. запуск фичи или её провал
3. борьба с оттоком, рост CR / LTV / GMV
4. нестандартный A/B
5. онбординг, ретеншен
6. или просто интересная продуктовая задача, с которой вы бились

👉 Форма на 3 минуты

Если получится классная история — сделаю по ней разбор.
Подключайтесь, будет интересно.

Про базовые метрики в задачах классификации в машинном обучении

Классификация — это про то, как определяется класс объекта. Например: фродер или нет, показать товар или не показать, дать кредит или отказать.

Классы могут быть бинарными, мультиклассовыми, со смещением и без. Используется в антифроде, поиске, скоринге, рекомендациях, модерации и почти в любом ML-продукте.

Когда обучается модель, необходимо понять, насколько хорошо она работает.

Обычно начинают с accuracy — самой простой и часто вводящей в заблуждение метрики.

1️⃣ Accuracy (доля верных предсказаний)

Представим задачу разметки клиентов как фродеров или нет.

В выборке всего 5% настоящих фродеров.

Если модель просто будет отвечать, что все не фродеры, она окажется права в 95% случаев. Accuracy = 95%.

На первый взгляд — отличный результат.

🚫 Но такой результат можно получить, не делая ничего. В задачах с перекосом классов accuracy — почти бесполезна.

Accuracy = (TP + TN) / (TP + FP + FN + TN)

2️⃣ Precision (точность)

Отражает долю корректных среди всех предсказанных как положительные.

В нашем случае отражает долю реальных фродеров среди всех, кого модель определила как фродеров

Если модель указывает на пользователей как фродеров, а по факту из 10 таких пользователей 6 действительно фродеры, а 4 — нет, то:

Precision = 6 / (6 + 4) = 0.6

👍 Иначе говоря — насколько обоснованно модель выдала положительный класс.

При низком precision модель тревожит нормальных пользователей — что критично для антифрода, медицины, рекомендаций.

Precision = TP / (TP + FP)

3️⃣ Recall (полнота)

Показывает, какую долю реальных фродеров удалось обнаружить.

Если в выборке 20 настоящих фродеров, и модель нашла 6 из них, то:

Recall = 6 / (6 + 14) = 0.3

😱 Это означает, что 70% фродеров модель пропустила.

Проще говоря — если модель кого-то не заметила, это может дорого обойтись.

Recall = TP / (TP + FN)

🤔 Про TP, FP, FN, TN в этой задаче классификации

TP — модель предсказала фрод и это правда
FP — модель предсказала фрод, но это ошибка
FN — модель сказала не фрод, но на самом деле это фрод
TN — не фрод и модель это правильно предсказала

4️⃣ Трейд-офф между Precision и Recall

🙂 При высоком пороге модель выдает положительный класс только при большой уверенности. Precision возрастает, но recall снижается — модель пропускает многих.

🪫 При низком пороге модель ловит почти всех фродеров — recall высокий, но увеличивается число ошибок (FP), и precision падает. Поэтому часто используют F1-score — гармоническое среднее между precision и recall.

F1 = 2 * (Precision * Recall) / (Precision + Recall)

Статьи:

[ссылка_1], [ссылка_2], [ссылка_3], [ссылка_4]

Ставьте 🔥, если пост был полезным, делитесь в комментариях своими мыслями, а я выложу следующий пост про другие метрики

Дашборд — это не конечный продукт аналитика, а основа для новых гипотез

❌ Особенно актуально это на тех местах работы, где проводится мало исследований или A/B-тестов, и аналитик постепенно превращается в сборщика витрин — на входе требования, на выходе дашборд.

🟢 Не спорю, это основа аналитики. Но сводить работу аналитика только к построению витрин и дашбордов — слишком узко. Гораздо ценнее периодически пересматривать отчётность хотя бы в рамках своего направления. Это помогает формулировать новые гипотезы и вместе с продуктом находить точки роста на основе реальных данных. В идеале — стремиться к тому, чтобы все ключевые процессы были покрыты прозрачной и удобной отчётностью.

🤓 По сути, это то место, где цифры можно представить в удобном формате для бизнеса для генерации новых задач,
формировании доработок в тех местах, где это нужно.

Помню первую работу: самая сложная часть — не графики, а ETL, который заключался в переливке данных для построения дашборда

-> дальше идет поддержание функционала, алерты. ТОЛЬКО продакты / проджекты генерировали новые задачи (аналитика не двигала бизнес).

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

Например.

1. На срезе X видно падение конверсии в поиск -> рождается гипотеза.
2. Общее падение заказов -> копаем в способы оплаты -> видно падение СБП.
3. Новички хуже проходят онбординг -> видно в глубине событий за первую сессию.

😎 Дашборд — инструмент для дальнейшей работы вместе с бизнесом. Хоть это и очевидно, не стоит забывать регулярно отслеживать метрики (необязательно каждый день)

15 минут в день и спина болеть не будет

🐶 Чтобы не просто отвечать на запрос, а самому формулировать следующий.
Чем чаще ты его открываешь — тем чаще у тебя будут идеи для роста бизнеса, а это ценный навык аналитика

🔥 Ставьте реакции, если пост был полезным, и делитесь своими кейсами в работе с дашбордами

Внезапные влеты

Привет, мир! Я вернулся после сдачи экзаменов. Тема поста - влеты.

Что такое влет? Сидишь такой, решаешь свои задачки и тут бац, срочная задача, которая должна быть сделана еще вчера

Например

📊 Просела метрика, давайте поймем, почему так.

🧑‍💻 CEO нужно показать отчет, для этого нужно предоставить те данные, которая не покрывает отчетность (через час, разумеется).

🆎 Нужно помочь завести эксперимент, определить гипотезу, метрику, аудиторию.

Есть плюсы и минусы, конечно же, давайте рассмотрим.

🟢 Плюсы

Во-первых, появляется возможность дополнить отчётность в том виде, который реально нужен бизнесу.
Ты видишь, какие цифры действительно важны на уровне решений.

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

Ну и ещё - это шанс выделиться. Быстро собрать информацию, выдать решение, спасти день и стать тем аналитиком, которому доверяют.

Если влеты регулярны (это уже не плюс, а тревожный звоночек) - значит, нужно автоматизировать.
Алерты, шаблоны - всё это спасает и время, и нервы.

🔴 Минусы

1. Внезапный стресс. Сложно может быть понимать контекст, резко смещать фокус в рамках спринта.
2. Местами может обесценивать твою работу (твои ресурсы, планирование и др.)
3. Нарушение границ. Если отвечать постоянно ДА, то высока вероятность, что следующий влет упадет в тебя, ну а затем выгорание)

🤷‍♂️ Что можно с этим сделать?

1. Управлять ожиданиями. Например, мы не можем сделать это сейчас, давайте запланируемся и разберем. Дополнительно определим ответственных, сроки, выделим на это ресурсы человека. Важно предлагать реалистичное решение

2. Если можно решить задачу на коленке грубо, можно предоставить вариант / MVP решения того, как можно закрыть проблему.

3. Делать выводы по влетам. А почему вообще возник? С чем связан? Является ли он критичным для бизнеса?

😖 Влеты раздражают, напрягают и сбивают с ритма.
Но и это точка, где аналитик становится не просто исполнителем, а партнёром: где ты думаешь не только про задачи, но и про приоритеты, коммуникацию, стабильность.
Главное - не брать всё на себя, фильтровать, проговаривать ожидания, и не бояться говорить с заказчиками.

Ставьте 🔥, если пост понравился! Делитесь с миром.
Как часто у вас бывают влеты на работе? Что с ними делаете? Пишите в комментариях

Визибилити в организации

Всем привет! Сегодня поговорим о такой штуке, как визибилити — или проще, видимость тебя и твоих наработок в организации. Характеристика, которая показывает, что ТЫ есть и ТЫ выполняешь конкретную функцию.

Сравним двух сотрудников

🎁 Первый: работает за нескольких человек, берет больше ответственности, иногда реально оверперформит, но рассказывает об этом только паре человек.

🎁 Второй: работает обычно, но не упускает ни одной возможности выступить — на конференциях, внутренних встречах, митапах, презентует результаты, заводит новые знакомства. В общем, светит лицом по максимуму.

🤴 Как думаете, кому из них отдадут предпочтение, когда дело дойдет до повышения или интересных проектов?

На самом деле, это не всегда вопрос справедливости. Можно быть серым кардиналом, но если про твою работу никто не знает и никто не понимает ценности твоей работы — шансы на быстрый рост гораздо ниже.

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

🤔 Почему так?

Бизнесу важно видеть не только результат, но и того, кто его создает.
Руководителям важно опираться на людей, у которых есть и экспертность и желание влиять на процессы.

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

Твой вклад может утонуть, если о нем не знают ключевые люди.

Порой кажется, что достаточно просто хорошо работать. Но если не напоминать о своих результатах — кто-то другой легко заберет твою славу, а твой проект будет восприниматься как чья-то инициатива.

Важно, чтобы результаты твоей работы приносили ценность не только тебе, но и всей команде.

Что делать, чтобы тебя замечали

1. Не бояться рассказывать о успехах на командных встречах.
2. Помогать коллегам и не забывать фиксировать совместные результаты.
3. Предлагать инициативы — даже если не все из них реализуются.
4. Писать апдейты о ключевых изменениях, которые улучшили работу или продукт.
5. Стараться делиться не только победами, но и ошибками/инсайтами — это вызывает доверие.

Если прочитал до конца — считай, ты уже на шаг ближе к визибилити.
Ставьте 🔥 и напишите, как вы делаете себя видимыми на работе! Интересно узнать)

UX пользователей: кейсы крупных компаний

В своем Линке я выкладывал пост про сайт, где можно посмотреть на различные кейсы крупных игроков с точки зрения UX в мультяшном формате.

🔗 Так вот, ссылочка тут

Работая продуктовым аналитиком, изучаешь пользовательские пути, то, как они взаимодействуют с приложением, что на каждом этапе может нравится / не нравится.

Интересные кейсы

🟣 Audible: Build seamless purchase experiences
Рассматривается, как Audible улучшает UX при оформлении подписки, минимизируя фрикции и повышая конверсию.

🍔 McDonald’s: The Psychology Behind McDonald’s $2 Billion Self-Serve Kiosks
Анализируется, как дизайн киосков влияет на поведение клиентов и способствует увеличению продаж.

🟢 Grammarly: How to Craft Onboarding Surveys Users Love: 5 Do’s and Don’ts
Показано, как правильно сформулированные вопросы при регистрации повышают вовлеченность пользователей.

🎵 Spotify Wrapped: Spotify Wrapped: 6 psychology principles that make it go viral every year.
Разбирается, какие психологические принципы делают ежегодный отчет Spotify таким популярным и ожидаемым.

🟡 Temu: The psychology of Temu’s casino-like shopping UX
Исследуется, как элементы геймификации и случайных вознаграждений стимулируют покупки.

Всего представлено 64 кейса, которые можно посмотреть и рассмотреть с уклоном в психологию пользователей

Также выделены 106 психологических приемов, которыми пользуются топовые компании

Годный ресурс, советую каждому ознакомиться с ним.

Если пост понравился, поставьте 🔥, пишите комментарии, нужно ли делать подборку по таким ресурсам!

📺 [YouTube] Деплой ML моделей: от кода до продакшена

Админ сдал диплом, скоро пойдет на вручение и будет писать вступительные экзамены

💻 Классное видео, в котором разобрано на простеньком примере, как можно задеплоить модельку с нуля от её написания до разворачивания на сервере. Автор еще Streamlit не подкручивал, результат был бы просто обернут в UI. Прям топ видео, начинающим зайдет. Всем, кто хочет быстро погрузиться в деплой ML, очень советую!

Код из видео

🧠 Что в видео:

👩‍💻 Создается публичный репозиторий в GitHub и далее клонируется в VSCode. После чего все изменения вносятся через VSCode.

👩‍💻 Сначала автор делает базовый ресерч в ipynb, обучает простенькую модель (деревья решений) на всем известном Titanic Dataset.

🔵 Затем сохраняет полученную модель (в т.ч. веса в pickle, отсюда очень удобно предсказывать значения).

🔘 Далее создается py-файл с FastAPI (с реализацией API и методов POST/GET). С помощью POST мы хотим понимать, выживет ли человек с заданными параметрами или нет, а с GET - получить метаданные. в POST забирается модель из pickle файла и дальше делается предсказание.

👩‍💻 Затем все оборачивается в Docker, создается образ и контейнеры (с соответствующими requirements.txt - это обычно нужно для сохранения версий библиотек на момент запуска приложений, чтобы не было конфликтов).

🟣.dockerignore - чтобы лишние файлы с собой не затаскивать (например, .ipynb, который нужен был для рисерча + сохранения файла модели или же .csv, откуда брали данные для обучения модели).

👩‍💻 Заносятся изменения с помощью git add ., commit, merge.

💵 После чего автор заходит на сайт, где можно арендовать дешево сервер и поднимает докер-контейнер с запуском приложения, предварительно клонируя из GitHub (открытого репозитория) все файлы, необходимые для запуска.

👍 Готово! Теперь у вас есть поднятый сервис, который может обрабатывать запросы пользователей в интернете.

Такой пайплайн — основа для любого продакшен ML-сервиса, и даже на простых примерах становится понятно, как устроен реальный цикл доставки модели до пользователя.

Понравился пост? Ставьте реакции, пишите комментарии о чем писать в дальнейшем! Очень интересно!

Применяешь t-test на целевую метрику у пользователей в эксперименте, видишь pvalue 0.051... (разумеется, на уровне значимости 0.05)

😏 А потом CUPED и стратификацию применим для прокраса эксперимента, да?

🥴 Без учета дизайна эксперимента.

Только в случае ожидаемого зеленого прокраса 😍

#memes