Forwarded from дAI потестить!
Делаем липсинк через Multitalk на видео.
Эксклюзивно для @VladPedro
Жду вопросы в комментах👇👇👇
#lipsync
Эксклюзивно для @VladPedro
Жду вопросы в комментах👇👇👇
#lipsync
Forwarded from Сарамуд NeuroДвиж 🤖
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Сарамуд NeuroДвиж 🤖
Пошаговый набор сервисов + альтернатива из скрина
1) Сгенерировать PRD (Product Requirements Document)
• ChatPRD — ИИ делает полноценный PRD из вашей идеи:
https://chatprd.ai/
• Feedough PRD Generator — готовит PRD по шаблону:
https://www.feedough.com/ai-product-requirements-document-prd-generator/
2) Сгенерировать мобильное приложение и протестировать в Expo Go
• Create (create.xyz) — text-to-app билдер, собирает React Native/Expo-проект из описания или PRD.
• Rork AI — генерация приложения по тексту/промпту:
https://rork.app/
Как использовать (коротко):
Идея → генерируете PRD → вставляете текст/PRD в билдер → через 10–15 минут получаете проект → открываете на телефоне в Expo Go (iOS/Android).
Replit, Rocket, Loveable, Youware, Bolt, Firebase Studio, Cursor, Trae AI IDE, Gemini CLI, Warp Terminal, Rork Ai, Orchids, Deepsite.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Заскуль питона (Data Science)
Буквально 2 дня назад вышла статья Avito 🌍 по 🆎. Разбираем по шагам механику A/B-тестирования: математика, интуиция и код
Почитал, в целом могу сказать, что хорошее чтиво для разбора A/B тестов.
Обычно, я смотрю графически на то, как изменяется MDE (тут это написано в зависимости от длительности эксперимента), также смотрю и по количеству пользователей в эксперименте (10/10, 20/20 и тд), только равные группы пользователей.
🧑🎓 Теоретическое
💻 Практическое
Из формулы MDE зачастую мы работаем с равными дисперсиями в выборкам, поэтому можно вынести из под корня константу в виде дисперсии и размера выборки, это вот тут.
Прикольно, что на практических сгенерированных примерах видно, что эти расчеты реально работают и можно использовать для реализации внутри компании, при дизайне / расчета A/B тестов.
Написано еще тут и про прокси-метрики, что их нужно выбирать в зависимости от каждого кейса, про оценку эффекта при переходе от обычной метрики к прокси-метрике, интерпретацию прокси-метрик
+ итоги правильной подготовки сетапа теста, где выбрали
а) сплит 50/50, а не 10/10
б) выбрали прокси-метрику, а не основную (которая обладает меньшей чувствительностью)
в) держать тест не 1, а 7 недель.
🔽 как результат, получили сокращение MDE в 9.2 раза!
Ну и дополнительно рассказали про контр-метрики, в очередной раз упомянули линеаризацию + доверительный интервал для оценки эффекта Ratio-метрик.
В целом, хорошая и ненапряжная статья, которую я вам советую прочитать, если хотите начать разбираться в A/B тестах + подметить для себя что-то новое)
Ставьте🐳 , если понравился пост, делитесь своими мыслями в комментариях.
Почитал, в целом могу сказать, что хорошее чтиво для разбора A/B тестов.
Обычно, я смотрю графически на то, как изменяется MDE (тут это написано в зависимости от длительности эксперимента), также смотрю и по количеству пользователей в эксперименте (10/10, 20/20 и тд), только равные группы пользователей.
def compare_mde(current_a, current_b, new_a, new_b):
return np.sqrt(1/current_a + 1/current_b) / np.sqrt(1/new_a + 1/new_b)
# здесь смотрят на то, а как изменится mde, если мы перейдем от 10/10 к 50/50 разбиению
compare_mde(0.1, 0.1, 0.5, 0.5) # ~2.236
def check_mde_reduce_from_size(grouped_dataset, current_t, current_c, new_t, new_c):
"""
Функция для сравнения MDE в текущем варианте сплитования и в новом.
Параметры:
- grouped_dataset: сгруппированный поюзерный датасет, на осоновании которого будут сравниваться MDE
- current_t: доля пользователей в тесте в текущем сетапе
- current_c: доля пользователей в контроле в текущем сетапе
- new_t: доля пользователей в тесте в новом сетапе
- new_c: доля пользователей в контроле в новом сетапе
Возвращает:
- отношение MDE_current / MDE_new
"""
grouped_dataset['group_current'] = np.random.choice(['test', 'control', '-'],
p=[current_t, current_c, 1 - current_c - current_t],
size=len(grouped_dataset))
grouped_dataset['group_new'] = np.random.choice(['test', 'control', '-'],
p=[new_t, new_c, 1 - new_t - new_c],
size=len(grouped_dataset))
metric = 'promotion_revenue'
test_curr = np.array(grouped_dataset[(grouped_dataset['group_current'] == 'test')][metric])
control_curr = np.array(grouped_dataset[(grouped_dataset['group_current'] == 'control')][metric])
test_new = np.array(grouped_dataset[(grouped_dataset['group_new'] == 'test')][metric])
control_new = np.array(grouped_dataset[(grouped_dataset['group_new'] == 'control')][metric])
MDE_current = get_relative_MDE(test_curr, control_curr, alpha=0.05, beta=0.2)
MDE_new = get_relative_MDE(test_new, control_new, alpha=0.05, beta=0.2)
return MDE_current / MDE_new
Из формулы MDE зачастую мы работаем с равными дисперсиями в выборкам, поэтому можно вынести из под корня константу в виде дисперсии и размера выборки, это вот тут.
Прикольно, что на практических сгенерированных примерах видно, что эти расчеты реально работают и можно использовать для реализации внутри компании, при дизайне / расчета A/B тестов.
Написано еще тут и про прокси-метрики, что их нужно выбирать в зависимости от каждого кейса, про оценку эффекта при переходе от обычной метрики к прокси-метрике, интерпретацию прокси-метрик
+ итоги правильной подготовки сетапа теста, где выбрали
а) сплит 50/50, а не 10/10
б) выбрали прокси-метрику, а не основную (которая обладает меньшей чувствительностью)
в) держать тест не 1, а 7 недель.
Ну и дополнительно рассказали про контр-метрики, в очередной раз упомянули линеаризацию + доверительный интервал для оценки эффекта Ratio-метрик.
В целом, хорошая и ненапряжная статья, которую я вам советую прочитать, если хотите начать разбираться в A/B тестах + подметить для себя что-то новое)
Ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Refat Talks: Tech & AI
This media is not supported in your browser
VIEW IN TELEGRAM
🤩 Как новенький LangExtract от Google может помочь в AI работе с доками, RAG и не только
Неделю назад Google тихо выпустил библиотеку, которая решает боль production LLM систем: как гарантировать, что извлеченные данные действительно есть в источнике, а не выдуманы моделью. Ты задаешь примеры что хочешь извлечь из текста (например, даты и суммы из контракта), LangExtract находит все такие элементы и показывает где именно каждый находится в документе, гарантируя что ничего не выдумано. Мне как раз надо было что-то подобное, я полез изучать, потом залез в исходники и залип.
Ключевая инновация - Source Grounding
Каждое извлечение привязано к точным координатам в тексте. Парсите контракт на 50 страниц? Система не просто скажет "срок оплаты 30 дней", но и покажет exact char positions где это написано. Под капотом - умный fuzzy matching алгоритм, который находит источник даже если LLM слегка перефразировал. То есть да, это как NER только без обучения, и как structured outputs, но с точным и надежным определением координат цитаты.
А еще на основе моих тестов эта штука поразительно хорошо и быстро работает с длинными документами.
Ботанский кусок (разверните кому интересно):
Use кейсы для вдохновления:
- Контракты на 100+ страниц - находит все суммы и сроки с точной ссылкой на цитату, можно легко интегрировать в UI "подсветку" фактов
- Медкарты с записями - извлекаем дозировки лекарств с гарантией и визуальным указанием источника
- Data Science стал еще доступнее: на вход тысячи не структурированный документов, на выход - CSV с нужными колонками и точными координатами откуда взял
- Извлекаете из корпоративной wiki, email, Slack: люди, проекты, технологии, их связи. Строим графы знаний - Profit!
Главное: LangExtract не просто надежно извлекает, но еще и доказывает откуда взял каждый факт.
Двигаемся еще ближе от "LLM как магический черный ящик" к "LLM как надежный production инструмент".
Блогпост | Репа
🔥➕🔁
Неделю назад Google тихо выпустил библиотеку, которая решает боль production LLM систем: как гарантировать, что извлеченные данные действительно есть в источнике, а не выдуманы моделью. Ты задаешь примеры что хочешь извлечь из текста (например, даты и суммы из контракта), LangExtract находит все такие элементы и показывает где именно каждый находится в документе, гарантируя что ничего не выдумано. Мне как раз надо было что-то подобное, я полез изучать, потом залез в исходники и залип.
Ключевая инновация - Source Grounding
Каждое извлечение привязано к точным координатам в тексте. Парсите контракт на 50 страниц? Система не просто скажет "срок оплаты 30 дней", но и покажет exact char positions где это написано. Под капотом - умный fuzzy matching алгоритм, который находит источник даже если LLM слегка перефразировал. То есть да, это как NER только без обучения, и как structured outputs, но с точным и надежным определением координат цитаты.
А еще на основе моих тестов эта штука поразительно хорошо и быстро работает с длинными документами.
Ботанский кусок (разверните кому интересно):
Покопался в исходниках, рассказываю суть.
По сути LangExtract = Few-shot Information Extraction + Structured Outputs + Automatic Source Grounding.
В отличие от простого использования structured outputs, автоматически находит точное местоположение типа {"startpos": 41, "endpos": 57}.
Общий принцип:
Документ → [Chunking] → [LLM + Schema] → [alignment phase] → Результат с позициями
Трехуровневый alignment (exact → case-insensitive → fuzzy) покрывает все основные кейсы, результаты потом валидируются.
Поддерживает extraction_passes - это механизм множественных независимых проходов извлечения по документу для повышения recall (полноты). LLM могут "пропускать" некоторые сущности при первом проходе, особенно в длинных текстах, поэтому повторные проходы помогают найти больше информации.
На входе использует example-driven подход - вместо написания промптов вы предоставляете несколько примеров того, что хотите извлечь. Из этих примеров автоматически генерируется JSON schema для structured output и создается few-shot промпт. Поддержка разных LLM провайдеров (Gemini, OpenAI, Ollama) с оптимизациями под каждый.
А с длинными доками хорошо работает за счет трех элегантных решений:
- Intelligent chunking с сохранением границ предложений (не тупое разбиение по токенам)
- Multi-pass extraction - несколько независимых проходов, каждый может найти что-то новое, результаты консолидируются
- Массивная параллелизация - десятки чанков обрабатываются одновременно
Есть встроенная HTML-визуализация с подсветкой найденных элементов прямо в исходном тексте (показана на видео).
Некоторые альтернативы: Instructor/Marvin/Outlines.
Use кейсы для вдохновления:
- Контракты на 100+ страниц - находит все суммы и сроки с точной ссылкой на цитату, можно легко интегрировать в UI "подсветку" фактов
- Медкарты с записями - извлекаем дозировки лекарств с гарантией и визуальным указанием источника
- Data Science стал еще доступнее: на вход тысячи не структурированный документов, на выход - CSV с нужными колонками и точными координатами откуда взял
- Извлекаете из корпоративной wiki, email, Slack: люди, проекты, технологии, их связи. Строим графы знаний - Profit!
Главное: LangExtract не просто надежно извлекает, но еще и доказывает откуда взял каждый факт.
Двигаемся еще ближе от "LLM как магический черный ящик" к "LLM как надежный production инструмент".
Блогпост | Репа
🔥➕🔁
Forwarded from Refat Talks: Tech & AI
This media is not supported in your browser
VIEW IN TELEGRAM
ElevenLabs опять радуют - запустили AI Student Pack - более $1500 бесплатных крЕдитов на 16 AI-инструментов для студентов (владельцев edu почты).
Заходишь на aistudentpack.com, логинишься студенческой почтой и забираешь что тебе нужно.
Что там есть:
- 3 месяца Creator Plan в ElevenLabs (стоит $55)
- Granola Business на 3 месяца (тут писал зачем вам она нужна)
- HeyGen для AI-видео
- 50% скидка на Superhuman (AI-почта)
- Месяц Headspace бесплатно
- Pika для AI-видео со скидкой 50%
- и еще 10 инструментов (см их блогпост)
Но нужна именно студенческая почта (.edu). Если у вас ее нет - Тимур расписал пошагово как ее добыть бесплатно.
UPD: второй вариант для .edu почты https://etempmail.com
Кстати, у ElevenLabs есть еще AI Engineer Pack и AI Creator Pack с похожими предложениями для разных аудиторий - текущие 'volumes' уже все, но обещают новые, stay tuned.
Другие тоже такое проводят. Видимо, формат с коллаборациями зашел.
🔥 ➕ 🔁
Заходишь на aistudentpack.com, логинишься студенческой почтой и забираешь что тебе нужно.
Что там есть:
- 3 месяца Creator Plan в ElevenLabs (стоит $55)
- Granola Business на 3 месяца (тут писал зачем вам она нужна)
- HeyGen для AI-видео
- 50% скидка на Superhuman (AI-почта)
- Месяц Headspace бесплатно
- Pika для AI-видео со скидкой 50%
- и еще 10 инструментов (см их блогпост)
Но нужна именно студенческая почта (.edu). Если у вас ее нет - Тимур расписал пошагово как ее добыть бесплатно.
UPD: второй вариант для .edu почты https://etempmail.com
Кстати, у ElevenLabs есть еще AI Engineer Pack и AI Creator Pack с похожими предложениями для разных аудиторий - текущие 'volumes' уже все, но обещают новые, stay tuned.
Другие тоже такое проводят. Видимо, формат с коллаборациями зашел.
🔥 ➕ 🔁
Forwarded from ML Baldini • Nikita Boyandin (Nikita Boyandin)
База собесов про LLM - промптинг💃
Предыдущий пост этой рубрики был встречен очень хорошо по реакциям и репостам, поэтому вторая часть посвященная промптингу к вашему вниманию.
1️⃣ Базовая структура промптов
По сути, есть две основные методологии составления промптов: AUTOMAT и CO-STAR. Давайте начнем с первого:
(А) Act as a … ― вы определяете роль LLM. Имеет смысл сказать модели, чтобы она действовала как профессионал в предметной области.
(U) User Persona & Audience ― с кем взаимодействует модель, аудитория, уровень ее подготовки.
(T) Targeted Action ― что необходимо сделать.
(O) Output Definition ― определяем выходной формат.
(M) Mode/Tonality/Style ― настроение, стиль. Объясните модели, как читатель должен воспринимать текст.
(A) Atypical Cases ― обработка исключений. Этот раздел для промптов, работающих с разным набором данных. Например, в приложениях, где один и тот же промпт вызывается с разными пользовательскими запросами. Объясните модели, как реагировать, когда пользователь спросил что-то не то.
(T) Topic Whitelisting ― контекст, допустимые обсуждаемые темы. Это раздел также для промптов, работающих с разным набором данных. Думаю, создатели фреймворка разделили последние два пункта в таком порядке в основном ради того, чтобы получился красивый акроним. Указываем модели, о чем мы собираемся говорить.
Теперь CO-STAR. По сути, тот же фреймворк, только в профиль:
Context: Объясните модели, о чем речь, предоставьте подробности и контекст.
Objective: Какая цель? Чего вы хотите добиться? Четко опишите задачу.
Style & Tone: Аналогично AUTOMAT ― укажите эмоциональный тон ответа.
Audience: Ваша аудитория, кто будет это читать, на кого вы ориентируетесь, готовя ответ.
Response: Определите формат вывода
Есть еще множество различных техник промптинга и вряд ли вы когда-нибудь их будете учить наизусть, но главное для меня - это обьяснять задачу LLM, как ребенку: сказать, чем он занимается, почему это важно, дать инструкции и примеры.
2️⃣ Что такое in-context learning?
Его еще называют обучение "на лету", то есть когда мы пытаемся улучшить качество ответа через промпт, без изменений весов LLM.
3️⃣ Типы промптов
Если вы начнете гуглить, то вам выдаст кучу непонятных типов, например сравнительных или ролевых промптов. Но в целом их можно обьединить в три вида: zero-shot, few-shot и chain-of-thought. Разберем каждый из них:
Zero-shot: предполагают отсутствие примеров в запросе. Модель должна самостоятельно понять задачу и сгенерировать соответствующий ответ. Этот подход хорошо подходит для получения общего ответа или выполнения простой команды, где не требуется контекст.
Few-shot: промпт включает несколько примеров решения задачи, что помогает модели лучше понять контекст и требования. Подходит для сложных задач, где важен контекст или требуется специфический стиль ответа.
Сhain-of-thought: модель обрабатывает задачу пошагово, следуя логической цепочке рассуждений. Идеален для ответов, требующих последовательного анализа или расчета.
4️⃣ Как повысить точность и надёжность ответов, а также сделать их проверяемыми в LLM?
Как мы все знаем, что LLM очень любит галюцинировать и выдавать несуществующие факты за реальные. Для нас это может стать большой проблемой, потому что это достаточно сложно отличить. Поэтому есть несколько вариантов, как это можно избежать:
1. RAG
Базовый поиск по векторам по базе документов, при котором LLM не ищет или придумывает данные, а сразу принимает реальные данные из нашей базы данных
2. Делать еще один запрос в LLM для проверки фактов
Базовая идея проверить один ответ другим запросом в LLM, но если вы делаете продукт для клиента, то это станет огромной проблемой, так как один запрос в LLM +3 секунды.
3. Делать структурированные выводы информации
Одной из лучших вещей, что есть в langchain считается structered_output, который дает возможность писать ответы в LLM в нужном формате.
Промпты, наверное, самая простая тема в собесах, так что если на этом посте будет больше 30 репостов, то сразу выпущу вопросы с собеса про RAG. Обязательно ставьте реакции, автору будет приятно💗
Предыдущий пост этой рубрики был встречен очень хорошо по реакциям и репостам, поэтому вторая часть посвященная промптингу к вашему вниманию.
По сути, есть две основные методологии составления промптов: AUTOMAT и CO-STAR. Давайте начнем с первого:
(А) Act as a … ― вы определяете роль LLM. Имеет смысл сказать модели, чтобы она действовала как профессионал в предметной области.
(U) User Persona & Audience ― с кем взаимодействует модель, аудитория, уровень ее подготовки.
(T) Targeted Action ― что необходимо сделать.
(O) Output Definition ― определяем выходной формат.
(M) Mode/Tonality/Style ― настроение, стиль. Объясните модели, как читатель должен воспринимать текст.
(A) Atypical Cases ― обработка исключений. Этот раздел для промптов, работающих с разным набором данных. Например, в приложениях, где один и тот же промпт вызывается с разными пользовательскими запросами. Объясните модели, как реагировать, когда пользователь спросил что-то не то.
(T) Topic Whitelisting ― контекст, допустимые обсуждаемые темы. Это раздел также для промптов, работающих с разным набором данных. Думаю, создатели фреймворка разделили последние два пункта в таком порядке в основном ради того, чтобы получился красивый акроним. Указываем модели, о чем мы собираемся говорить.
Теперь CO-STAR. По сути, тот же фреймворк, только в профиль:
Context: Объясните модели, о чем речь, предоставьте подробности и контекст.
Objective: Какая цель? Чего вы хотите добиться? Четко опишите задачу.
Style & Tone: Аналогично AUTOMAT ― укажите эмоциональный тон ответа.
Audience: Ваша аудитория, кто будет это читать, на кого вы ориентируетесь, готовя ответ.
Response: Определите формат вывода
Есть еще множество различных техник промптинга и вряд ли вы когда-нибудь их будете учить наизусть, но главное для меня - это обьяснять задачу LLM, как ребенку: сказать, чем он занимается, почему это важно, дать инструкции и примеры.
Его еще называют обучение "на лету", то есть когда мы пытаемся улучшить качество ответа через промпт, без изменений весов LLM.
Если вы начнете гуглить, то вам выдаст кучу непонятных типов, например сравнительных или ролевых промптов. Но в целом их можно обьединить в три вида: zero-shot, few-shot и chain-of-thought. Разберем каждый из них:
Zero-shot: предполагают отсутствие примеров в запросе. Модель должна самостоятельно понять задачу и сгенерировать соответствующий ответ. Этот подход хорошо подходит для получения общего ответа или выполнения простой команды, где не требуется контекст.
Few-shot: промпт включает несколько примеров решения задачи, что помогает модели лучше понять контекст и требования. Подходит для сложных задач, где важен контекст или требуется специфический стиль ответа.
Сhain-of-thought: модель обрабатывает задачу пошагово, следуя логической цепочке рассуждений. Идеален для ответов, требующих последовательного анализа или расчета.
Как мы все знаем, что LLM очень любит галюцинировать и выдавать несуществующие факты за реальные. Для нас это может стать большой проблемой, потому что это достаточно сложно отличить. Поэтому есть несколько вариантов, как это можно избежать:
1. RAG
Базовый поиск по векторам по базе документов, при котором LLM не ищет или придумывает данные, а сразу принимает реальные данные из нашей базы данных
2. Делать еще один запрос в LLM для проверки фактов
Базовая идея проверить один ответ другим запросом в LLM, но если вы делаете продукт для клиента, то это станет огромной проблемой, так как один запрос в LLM +3 секунды.
3. Делать структурированные выводы информации
Одной из лучших вещей, что есть в langchain считается structered_output, который дает возможность писать ответы в LLM в нужном формате.
Промпты, наверное, самая простая тема в собесах, так что если на этом посте будет больше 30 репостов, то сразу выпущу вопросы с собеса про RAG. Обязательно ставьте реакции, автору будет приятно
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Поступашки - ШАД, Стажировки и Магистратура
Пет-проекты для продолжающих аналитиков
Финальные 3 часа скидки на наши продвинутые курсы подходят к концу. Аналитика хард стартует уже завтра!
1. Прогнозирование временных рядов
На более старших позициях аналитикам часто нужно лезть в ML/Эконометрику, особенно риск аналитикам, поэтому нужно будет заботать оба этих навыка. В этом проекте будем прогнозировать спрос на следующий месяц и выявлять факторы воздействия на точность прогноза. Возьмём датасет продаж/курс валют/трафик веб-сайта и т. п. Работать будем в jupyter или коллабе, если датасет большой, то советую подключить cuda. Очистим данные от выбросов проанализируем ряд на тренд, остаток и сезонность. Многие модели требуют стационарность, поэтому в том числе нужно протестировать их. Если ряд не стационарный, то продифференцируем/логарифмируем. Из моделей выберем базовую arima и prophet. Далее оценим качество модели (например через WAPE) и напишем выводы.
2. Проектирование базы данных SQL
SQL довольно простой язык и с помощью одного пет-проекта можно легко заботать этот язык за неделю. В начале выберете тематику бд (например бд для интернет магазина). Первый этап в написании бд - это проектирование, в начале придумываете концептуальную модель, в ней должны быть описаны лишь названия сущностей и взаимосвязи между другими. Затем проектируем физическую и логическую модели, в первой описываем поля у каждых сущностей, их ограничения и типы, во второй (логической) - описываем рисуем схему с взаимосвязями (по каким ключам связь, какой тип ключа и связи) и можно также описать тип версионирования. Проект можете реализовывать в vscode (но его предварительно придется настроить), либо в dbeaver (открываете pgadmin, создаёте бд, идёте в dbeaver и подключаете к бд). Далее пишем ddl скрипты, которые реализуем полностью по логической и физической моделям БД (в процессе создания таблиц также можете изучить как расставлять индексы и добавить их). Затем реализуем dml - с генерацией данных и запросами (постараемся задействовать как можно больше различных продвинутых функционалов, например можно реализовать заполнение случайными данными и обернуть их в процедуры или представления, а также можно реализовать несколько запросов, которые актуальны для данных в них используем оконки, cte и рекурсивные).
3. Когортный анализ удержания клиентов
В данном проекте наша цель показать именно продуктовое понимание, накидать как можно больше выводов и гипотез, а не показать харды. Выгружаем данные транзакций какого-нибудь ретейлера. Когорты просто выбираем по месяцу первой покупки. Рассчитаем процент клиентов, совершающих повторные покупки на 7-й, 30-й, 90-й дни. Постройте хитмапу когорт по процентам удержания. При анализе такой карты хорошо заметны сезонные закономерности - например, когорты декабря часто показывают низкое удержание из-за новогоднего ажиотажа, когда люди совершают разовые покупки подарков. Также могут выявляться выбросы, связанные с маркетинговыми акциями или другими событиями. Далее можно сегментировать когорты по каналу привлечения (контекстная реклама/соцсети) и поискать зависимости по сегментам. В выводах анализируем тренд удержания, факторы влияющие на этот тренд и эффективность каналов привлечения.
4. Кореляционный анализ
Сначала выбираем тему и данные: находим две или больше числовых характеристик, где предполагается связь, например "Влияет ли размер скидки на объем продаж" или "Связь времени учебы и оценки". Опять же, можно взять готовый датасет с Kaggle, либо сгенерить/спарсить свои данные. Дальше проводим EDA и визуализируем связи. Считаем коэффициенты. Пирсон для линейных связей и нормальных данных, Спирмен для любых монотонных связей через ранги, Кендалл как альтернативу Спирмену для маленьких выборок. Для пирсона предварительно проведем проверку на нормальность (Шапиро Уилка или q-q plot). И оцениваем значимость связи через pvalue. В выводах объясняем тип связи, и стат значимость, но главное не путать корреляцию с причинностью. Можно провести регрессионный анализ и отобразить на графикe.
@postypashki_old
Финальные 3 часа скидки на наши продвинутые курсы подходят к концу. Аналитика хард стартует уже завтра!
1. Прогнозирование временных рядов
На более старших позициях аналитикам часто нужно лезть в ML/Эконометрику, особенно риск аналитикам, поэтому нужно будет заботать оба этих навыка. В этом проекте будем прогнозировать спрос на следующий месяц и выявлять факторы воздействия на точность прогноза. Возьмём датасет продаж/курс валют/трафик веб-сайта и т. п. Работать будем в jupyter или коллабе, если датасет большой, то советую подключить cuda. Очистим данные от выбросов проанализируем ряд на тренд, остаток и сезонность. Многие модели требуют стационарность, поэтому в том числе нужно протестировать их. Если ряд не стационарный, то продифференцируем/логарифмируем. Из моделей выберем базовую arima и prophet. Далее оценим качество модели (например через WAPE) и напишем выводы.
2. Проектирование базы данных SQL
SQL довольно простой язык и с помощью одного пет-проекта можно легко заботать этот язык за неделю. В начале выберете тематику бд (например бд для интернет магазина). Первый этап в написании бд - это проектирование, в начале придумываете концептуальную модель, в ней должны быть описаны лишь названия сущностей и взаимосвязи между другими. Затем проектируем физическую и логическую модели, в первой описываем поля у каждых сущностей, их ограничения и типы, во второй (логической) - описываем рисуем схему с взаимосвязями (по каким ключам связь, какой тип ключа и связи) и можно также описать тип версионирования. Проект можете реализовывать в vscode (но его предварительно придется настроить), либо в dbeaver (открываете pgadmin, создаёте бд, идёте в dbeaver и подключаете к бд). Далее пишем ddl скрипты, которые реализуем полностью по логической и физической моделям БД (в процессе создания таблиц также можете изучить как расставлять индексы и добавить их). Затем реализуем dml - с генерацией данных и запросами (постараемся задействовать как можно больше различных продвинутых функционалов, например можно реализовать заполнение случайными данными и обернуть их в процедуры или представления, а также можно реализовать несколько запросов, которые актуальны для данных в них используем оконки, cte и рекурсивные).
3. Когортный анализ удержания клиентов
В данном проекте наша цель показать именно продуктовое понимание, накидать как можно больше выводов и гипотез, а не показать харды. Выгружаем данные транзакций какого-нибудь ретейлера. Когорты просто выбираем по месяцу первой покупки. Рассчитаем процент клиентов, совершающих повторные покупки на 7-й, 30-й, 90-й дни. Постройте хитмапу когорт по процентам удержания. При анализе такой карты хорошо заметны сезонные закономерности - например, когорты декабря часто показывают низкое удержание из-за новогоднего ажиотажа, когда люди совершают разовые покупки подарков. Также могут выявляться выбросы, связанные с маркетинговыми акциями или другими событиями. Далее можно сегментировать когорты по каналу привлечения (контекстная реклама/соцсети) и поискать зависимости по сегментам. В выводах анализируем тренд удержания, факторы влияющие на этот тренд и эффективность каналов привлечения.
4. Кореляционный анализ
Сначала выбираем тему и данные: находим две или больше числовых характеристик, где предполагается связь, например "Влияет ли размер скидки на объем продаж" или "Связь времени учебы и оценки". Опять же, можно взять готовый датасет с Kaggle, либо сгенерить/спарсить свои данные. Дальше проводим EDA и визуализируем связи. Считаем коэффициенты. Пирсон для линейных связей и нормальных данных, Спирмен для любых монотонных связей через ранги, Кендалл как альтернативу Спирмену для маленьких выборок. Для пирсона предварительно проведем проверку на нормальность (Шапиро Уилка или q-q plot). И оцениваем значимость связи через pvalue. В выводах объясняем тип связи, и стат значимость, но главное не путать корреляцию с причинностью. Можно провести регрессионный анализ и отобразить на графикe.
@postypashki_old
Forwarded from Coder Doesn’t Know
Как и договаривались!
История собеседования на Software Engineer в Meta.😃
Там пошаговый процесс, подготовка и полезные лайфхаки - всё в Notion, если интересно 👀
Короткая ссылка: https://tinyurl.com/meta-swe-interview-2025
Оригинальная ссылка: https://diligent-path-faf.notion.site/Meta-SWE-2025-251511342c8680b38d99de8cc35655b2
P.S. Важно: эта история вымышлена. Все совпадения с реальными людьми, компаниями и процессами случайны.
#experience #faang #maang #bigtech #swe #meta #interview
История собеседования на Software Engineer в Meta.
Там пошаговый процесс, подготовка и полезные лайфхаки - всё в Notion, если интересно 👀
Короткая ссылка: https://tinyurl.com/meta-swe-interview-2025
Оригинальная ссылка: https://diligent-path-faf.notion.site/Meta-SWE-2025-251511342c8680b38d99de8cc35655b2
P.S. Важно: эта история вымышлена. Все совпадения с реальными людьми, компаниями и процессами случайны.
#experience #faang #maang #bigtech #swe #meta #interview
Please open Telegram to view this post
VIEW IN TELEGRAM
diligent-path-faf on Notion
Meta (SWE, 2025) | Notion
Application