Как я сходил вчера на конференцию для аналитиков от Яндекса

(это не реклама, я сходил в оффлайне)

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

Я периодически посматривал на бейджи, которые нам выдавали при регистрации. Было прям очень много компаний (в том числе WB, Яндекс, Авито, Т-Банк, VK, Сбер, Ozon и др.).

👀 Что касается докладов (я ходил по треку Data to insights)

💜 Про замеры качества Алисы доклад, в котором говорится, про то, что они перешли от разметки при помощи обученных асессоров к гибридной разметке (LLM + асессор, что обеспечивает стабильное качество разметки) + научились оценивать диалог с точки зрения пользовательской задачи.

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

❤️ Про аналитику международного поиска. Рассказали, про проблему качества поиска, интерпретацию волатильных метрик. Решение: еженедельный синк по ключевым метрикам с заинтересованными лицами и анализ прогноза.
Кроме того, поговорили про формирование команды и об отношении к людям.

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

👍 На воркшоп я не успел сходить, но попросил скинуть мне ноутбучек (там про создание агента с RAG и MCP.

🍴 Затем было афтерпати, где я пообщался с интересными ребятами, поел, да и поехал я домой.

Ну и выдали мерч, куда же без него

Трансляции сохранились, кому интересно, можете глянуть

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

Понравился пост? Ставь 🐳, пиши комментарии, а я выложу, что за мерч подарили 🥳

Перфекционизм убивает скорость

🥰 В аналитике (да и не только в ней на самом деле) легко попасть в ловушку: хочется, чтобы запрос выглядел идеально, дашборд был вылизанным, а исследование должно быть нереально красивым. Но проблема в том, что бизнесу чаще всего нужно не идеально, а своевременно. Заказчики могут приходить с конкретной болью, которую хочется решить прямо сейчас. Хороший сторителлинг может быть лучше нескольких часов, потраченных на наведение красоты.

⌚️ Ты можешь неделями оттачивать расчёт, делать супер-красивые графики, перепроверять каждый шаг. А в это время продукт ждёт ответ, чтобы принять решение и запустить новую фичу (здесь еще можно обратиться к моему посту про управление ожиданиями). В итоге идеальная работа теряет ценность, потому что пришла слишком поздно. А еще хуже всего, когда нужно изменить подходы, так как заказчикам хочется видеть картину под другим углом)

Да, аккуратность и точность важны. Но есть разница между надежно и делать красиво. Надёжность нужна всегда: пайплайны, базовые метрики, критичные отчёты. Там ошибка бьёт по команде и бизнесу. А вот перфекционизм в исследовательских задачах чаще мешает.

Раньше я старался сделать все максимально красиво, просил дополнительные сроки на оформление исследования, а в итоге продукт приходил с правками, так как я несвоевременно уточнил о глобальной цели на ресерч. В итоге пришлось бОльшую часть переделывать, а мои красивые графики оказались никому не нужны. Грустно, но что поделать :)

😮 Хорошая стратегия — работать итерациями. Сначала собрать черновой результат, отдать на проверку, показать направлению и собрать обратную связь. Про то как ее запрашивать напишу отдельный пост, если соберется 100 реакций. Пусть он будет грубым, но уже полезным. После можно улучшать, дорабатывать, углубляться. Так и команда в курсе, и продукт двигается вперед, и ты не проваливаешься в бесконечное наведение красоты того, что потенциально с вероятностью 90% может корректироваться.

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

А что вы думаете по этому поводу?

🐳 — Делаем быстро, держим в курсе всех.
🥰 — Доводим до красоты и показываем результаты.

Пишите в комментариях свое мнение, ставьте реакции, если пост зашел!

🔛 Не бойся задавать вопросы

База, которую нужно помнить всегда.

Работаешь над новым проектом и не знаешь, куда идти — задай вопрос.
Не знаешь в какую БД нужно сходить за данным, так как только пришел — задай вопрос.
Хочешь узнать новое у коллег — задай вопрос.
Прослушал суть задачи, но хочешь понять, как ее делать — задай вопрос.
Сидишь на встрече с бизнесом и не понял зачем мы реализуем определенный проект — задай вопрос.

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

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

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

📕 Но если документации нет (а такое тоже случается), стоит самому фиксировать ответы коллег. Это поможет не возвращаться к одним и тем же вопросам по несколько раз. Записывай примеры запросов, названия сущностей и строй для себя определенный алгоритм:

1. Если нужно сделать задачу А — идём в систему Х (уже спросили у коллег, зафиксировали)
2. Проверяем данные через сервис Y,
3. На выходе ожидаем такой-то результат.

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

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

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

Тебе платят за то, чтобы ты делал работу эффективно — и вопросы тут твой инструмент 🤑

Иногда один правильно заданный вопрос экономит часы или даже дни работы ☕️

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

🐸 @zasql_python

это единственная правильная стратегия 😳

@ds_memes

💻 Написал статью про Наивный байесовский классификатор.

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

1. Ссылка на статью.
2. Датасет, с которым работал.
3. Код в Google Colab.

Первый раз писал тут, делюсь болью:

1. Столкнулся с тем, что при написании текста, страничка залагала, а при обновлении не сохранился кеш + нет автосохранения. После каждого написания текста советую нажимать "сохранить".
2. Нет конвертации в LaTeX. Поэтому пришлось писать формулы, конвертировать их в .svg, заливать в GitHub и по ссылке прикреплять в текст, вот такой замечательный пайплайн.
3. Периодически картинки не отображаются (хотя ведет на доступные ссылки) в моем GitHub.

Всем приятного чтива, а я пошел писать следующий пост!

😌😌😌🐸
😌😌😌😌
😌☺😌😌

⬆ Это я жду ваших комментов и реакций! Ставьте 🐳, делитесь и сохраняйте к себе!

Следующие посты будем разбирать математику, которая есть в A/B тестах или в ML. На примете разбор логистической регрессии.

@zasql_python

🐸 Python для аналитика

90% задач аналитик решает в SQL. Но остаются те самые 10%, где без Python никак 👩‍💻

Я собрал Google Colab, где в одном месте покрыта большая часть методов (практические все), которые реально нужны аналитику: от базовых конструкций (строки, списки, словари) до pandas/numpy, работы с API, визуализации, Spark и Airflow и др.

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

👉 Colab дублирую еще тут

Ставьте 🐳, если хотите поскорее получить такую базу знаний. И пишите, что ещё добавить в шпаргалку!

🌀 Умение просто объяснять сложное

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

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

🍪🍪 У всего есть своя аудитория.
Я знаю, что в канале собрались ребята очень разного уровня: кто-то уже работает в индустрии и глубоко копает в ресёрчи или A/B-тесты, кто-то только начинает свой путь в аналитике, а кто-то вообще пока просто наблюдает со стороны. И это классно, так как разные перспективы помогают смотреть на одни и те же вещи под разными углами. Поэтому я стараюсь чередовать форматы: где-то глубже, где-то проще, чтобы каждому было комфортно и интересно.

👀 И да, интересное наблюдение. Иногда вижу подпись: «Простыми словами о сложном».

Сразу вопрос: а что это вообще значит? Упростить НЕ РАВНО донести мысль 🧠

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

🥳 Умение аналитика не только в том, чтобы посчитать метрику или построить модель. Главное, что ожидается, это упаковать результат так, чтобы он легко ложился в голову любого человека. Где-то объяснить на пальцах, где-то достать формулы, но всегда через призму главного вопроса: зачем это нужно?

Работаем переводчиками, а чо, плотити еще сверху, так как мы считаем эскуельки и рисуем графички 💰

😮 Очень сильно помогает совет: объясняй так, будто разговариваешь с человеком, который вообще не разбирается в домене, сложных методах и так далее (например, человек из бизнеса, который отвечает за коммерческий департамент). Представь, что перед тобой первый попавшийся прохожий. Если он поймёт, значит, ты действительно донёс мысль. В его голове могут появляться самые разные вопросы, и твоя задача будет заключаться в том, чтобы выстроить понятное повествование. Иначе весь смысл разговора теряется.

А вы что думаете? Ставьте 🐳, пишите комментарии! А я пойду я готовить следующий пост 🤟

🙊 Прохожу значит я курс по SQL в своей магистратуре и тут вижу интересный кейс, решил поделиться с вами. Если честно, ни разу не видел в продовых решениях ни в аналитических таблицах CHAR, ни в хранении логов с различных сервисов, но возможно пригодиться или кто-то использовал (делитесь в комментах) 🔽

DROP TABLE IF EXISTS zasql_python_table;

create table zasql_python_table (
value1 CHAR(5),
value2 VARCHAR(5)
);

INSERT INTO zasql_python_table VALUES ('abcd', 'abcd');

SELECT CONCAT(value1, value2) as result_1_2, CONCAT(value2, value1) as result_2_1
from zasql_python_table;

🗣 Результат будет следующий 🙃

| result_1_2 | result_2_1 |
|-------------|-----------|
| abcd abcd   | abcdabcd  |

Видите пробел между abcd и abcd? Это как раз CHAR, который дополнил строку до фиксированной длины.

Ну или после этого сообщения начнуть кошмарить на собесах по SQL... 👩‍💻

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

🐸 Если очень грубо:

🥳 CHAR(n) используется для хранения строк фиксированной длины.
Если строка короче, чем n, она автоматически дополняется пробелами до нужной длины. При выводе эти пробелы обычно сохраняются (зависит от СУБД). Подходит, когда все значения примерно одинаковой длины (например, коды, индексы).

🥳 VARCHAR(n) хранит строки переменной длины.
Если строка короче n, то пустоты не добавляются, сохраняются только фактические символы. Если строка длиннее n, она будет обрезана до заданного размера. Подходит, когда длина строк сильно варьируется.

Например, в одной статье говорится следующее:

For instance, CHAR often outperforms VARCHAR in scenarios with consistently sized data due to its fixed length, resulting in faster index lookups—up to 20% quicker on average. Conversely, VARCHAR excels in space efficiency for variable-length data, making it an ideal choice for dynamic datasets. The decision between CHAR vs VARCHAR is not just about storage but also about optimizing your database’s speed and efficiency.

⬆️ CHAR часто превосходит VARCHAR в сценариях с данными одинакового размера благодаря фиксированной длине, что приводит к ускорению поиска по индексу — в среднем на 20 %.

Или в другой:

The amount of work the database engine has to perform to store and retrieve VARCHAR columns is more than it takes for a CHAR column. Every time a VARCHAR column is retrieved, the Database engine has to use the length information stored with the data to retrieve a VARCHAR column value. Using this length information takes extra CPU cycles. Whereas a CHAR column and its fixed length allow SQL Server to more easily chunk through CHAR column based on their fixed-length column definitions.

⬆️ Для хранения и извлечения VARCHAR столбцов ядру базы данных требуется больше ресурсов, чем для CHAR столбцов. При каждом извлечении VARCHAR столбца ядру базы данных приходится использовать информацию о длине, хранящуюся вместе с данными, чтобы извлечь значение столбца VARCHAR. Использование этой информации о длине требует дополнительных вычислительных ресурсов.

Авторы предлагают использовать CHAR для фиксированной длины и в этом случае скорость будет выше, но я опять скажу, что пока что ни разу не видел такие витрины, где бы использовался этот тип данных. Может вы сможете привести РЕАЛЬНЫЙ кейс, где бы это использовали.

Понравился пост? Ставьте 🐳, если понравился пост, пишите комментарии! Может вы использовали CHAR и это помогло? Нужны кейсы!

@zasql_python

Где я в итоге учусь в магистратуре и как мне?

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

💻 Поступил я в итоге на ML-инженера в МИФИ. На выбор у меня было поступление в разные магистратуры, но здесь я напишу, что вообще происходит в моей. По программе все зашло на момент сдачи вступительных испытаний.

💻 После работы или на выходных я выделяю себе время на просмотр лекций, семинаров (благо есть записи). Трачу час-два каждый день, чтобы посмотреть материалы, решить дз, закрыть проекты, чтобы потом не быть с горящей жопой, закрывая предметы. Первый семестр достаточно простой, дают очень много всего. Если смотрели вот этот пост, это просто 1/100 того, что было в материалах, а в дальнейшем я эту историю раскрутил.

😢 К сожалению, нельзя закрыть предметы, если ты применяешь методы на работе, хотя я слышал, что в каких-то местах можно. Приведу пример: я пишу много SQL-скриптов с различной сложной логикой, но при этом должен закрывать предмет, где учат делать SELECT, вставки в таблицы и их создание. Как мне кажется, предмет можно закрыть, но тут кому виднее. Многие могут написать, что-то из разряда: "так если так легко, сдай сам", будете правы.

Задания, в том числе проекты реализованы на платформе, есть мягкие и жесткие дедлайны по сдаче дз / проектов. Необязательное посещение лекций и семинаров + преподаватели открыты к обратной связи и вопросам. Например, для задачи по наивному Байесу я с преподавателем очень долго дискутировал по применению метода в определенной задаче, про это я кстати планирую написать, мне показалось, что тема весьма интересна 🍪🍪

👦 На лендинге магистратуры видел, что магистратура для начинающих специалистов (я, кек). Но мне показалось, что очень много материалов и человеку без опыта будет сложно (несмотря на то, что курсы сделаны последовательно). От 25 часов в неделю, учеба в удобное время, как указывается на сайте. Но это еще норм, так как в ВШЭ на одну из программ, куда я поступал было от 40 часов в неделю (рабочая неделя) + говорили, что понадобится еще больше времени на обучение (ШАД?) 💥

Местами я наблюдал, что материал подан без конкретной структуры, несмотря на явное разделение по модулям. То есть могла быть одна тема, которая ссылалась на тему, которую не проходили по курсу. Возможно, подразумевается, что студенты будут сами искать то, что им нужно в интернете или GPT, а затем приступать к изучению. Если так и задумывалось, то, наверное, супер гуд. Хотя я склоняюсь к тому, что нет, так как в процессе обучения курс дорабатывается. Я купил себе подписку в бета-тестеры магистратуры 👀

Из интересного, что есть — это теория вероятностей + ожидается статистика с A/B тестированием в этом семестре. По Python много всего показывают: декораторы, ООП (великий и ужасный, который обходят стороной аналитики, хотя знаю, что некоторые используют, в том числе для методов 🆎, если хотите, чтобы я подробней про это рассказал, ставьте 🐳, для ML инженера очень часто видел использование классов и это БАЗА). Но указан именно базовый Python без библиотек для анализа данных, возможно я это увижу в следующих семестрах.

Имхо, пока норм, есть косяки, но что-то новое местами для себя подчерпываю. Например, итоговый проект по Python нужно было реализовать с помощью poetry, makefile и различных зависимостей между файлами. Что-то новое для себя подчерпываю и систематизирую.

Кстати, интересный факт по поступлению в ИТМО (так как меня многие спрашивали, почему я не пошел туда): когда объявляли результаты конкурса в AI Talent Hub, удивился, что не нашел себя в списке победителей по конкурсу портфолио. Оказывается, что подал документы не на ту программу и там выиграл, но формат очный 😂, а в AITH дистанционный.

Как вам пост? Ставьте 🐳, подписывайтесь на канал, пишите комментарии!

@zasql_python

🐸 Вы когда-нибудь думали, что знаете всё, а потом жизнь показала обратное?

Эффект Даннинга-Крюгера

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

Мне эта тема откликнулась, решил поделиться с вами. Картинка выше хорошо показывает, как это выглядит на практике.

👀 У меня было такое, когда я рассказывал одному из своих знакомых (3 года назад), что я все знаю в аналитике, нахожусь в своем прайме и вообще я очень крутой специалист. На тот момент я участвовал в хакатоне без релевантного опыта аналитики. Но был убежден, что, покрутив таблички в pandas, почитав документацию, я стал боссом всей аналитики. Нанимайте меня на пост директора по аналитике, пожалуйста, ведь я крутой 🥳

В эксперименте Даннинга и Крюгера студентов просили пройти тест по грамматике, логике и чувству юмора, а потом — оценить себя. Результат показал: слабые участники переоценивали себя, сильные — недооценивали.

👉 Вот здесь можно почитать более подробно

✏️ Я пишу этот пост, чтобы напомнить себе (и не только), как важно вовремя остановиться, не пытаться выглядеть умнее, чем ты есть, особенно рядом с теми, кто действительно понимает предметную область.

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

Что можно с этим сделать?

1. Получать обратную связь от тех, кому ты доверяешь в знании предметной области. Это может быть знакомый разработчик, аналитик, продакт. Важно искать потенциальные точки роста в этом.
2. Почаще рефлексировать. Можно вести конспекты по предмету, в котором ты хочешь разбираться, стараться самостоятельно решать определенные задачи и челенджить себя.
3. Ставить реалистичные цели. Решение задач позволяет повысить самооценку и выбрать из ямы страданий.

Вот тут кстати интересная статья по разоблачению этого эффекта, интересно было почитать комменты

А что вы думаете по этому поводу? Ставьте 🐳, пишите комментарии!

@zasql_python

😮 Что не нравится в аналитике

Пишите свои комменты, вместе разбавим понедельник ✏️

— Было много случаев, когда ТЗ заказчика сильно отличалось от действительности, на это потратили больше времени. Тут была и моя ошибка. Заказчик не всегда понимает то, что ему нужно) ❓

— Бесконечное количество созвонов. Не секрет, что продуктовый аналитик обычно проводит много времени на созвонах, так как нужен аналитический саппорт по цифрам. Иногда доходило до 6-7 встреч в день. А когда работать? ⌛️

— Проблемы с данными. Никто не застрахован от того, что не будет недоезда данных, в источнике данные сломаются или еще что-то. В результате придет бизнес и начнет неистово пинать аналитику по причинам (это норма, но на это приходится тратить зачастую много времени, если нет алертов и сенсоров). ⌚️

— Быстро посчитать. Есть в этом какой-то челендж, но когда этого много, сильно утомляет, становишься как белка в колесе. 🏃‍♂️

— Отсутствие фидбека. Порой кажется, что аналитиков используют как модель LLM, чтобы ответить на промпт (главное его сделать адекватным 😂). Сделал исследование, а дальше непонятно, что делаем с этим.

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

— Когда лежит источник данных и дашборд не обновляется... 👀

И все равно, мы любим аналитику:

1️⃣ За момент, когда данные сошлись с источником
2️⃣ За инсайт, который помог команде
3️⃣ За кайф от оптимального запроса
4️⃣ За красивые цифры в эксперименте

Ставьте 🐳, жду ваших дополнений к этому списку!

@zasql_python

✅ Поговорим про p-value

Многие аналитики знают формулировку, хотя встречаются кейсы, когда люди путают понятия, предыдущий пост

👍 Правильный вариант:

p-value — это вероятность получить наблюдаемое или более экстремальное значение статистики, если нулевая гипотеза верна.

👎 Неправильный вариант, интерпретаций встречается очень много:

p-value — это вероятность, что нулевая гипотеза верна
p-value = вероятность, что результаты случайны
Чем меньше p-value, тем больше вероятность, что гипотеза H₁

🥳 Окей, вроде бы понятно, а как это прочувствовать или почему мы вообще ссылаемся на p-value?

❓

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

Самый простой вариант: это показать, что монетка нечестная (например, мы подбрасывали 10 раз монетку, 9 раз выпал орел).

H₀ (нулевая гипотеза) — Монета честная, то есть орёл и решка выпадают с равной вероятностью 50/50. p = 1/2
H₁ (альтернативная гипотеза для орлов), можно проверить одностороннюю гипотезу , тогда p > 1/2 или p != 1/2 (двустороннюю)

⚠ В данном примере мы будем проверять одностороннюю гипотезу.

В этом случае биномиальное распределение описывает все возможные исходы количества орлов и решек при подбрасывании монеты.

👀 Например, 9 орлов из 10 могли выпасть в любом порядке: и в первых 10 подбрасываниях, и вперемешку с решками. Биномиальное распределение как раз учитывает все комбинации, при которых общее число орлов равно 9, независимо от последовательности их выпадения.

👨‍🔬 Общая формула биномиального распределения:

P(X = k) = Cn^k * p^k * (1-p)^(n-k)

Эта формула показывает вероятность того, что при n подбрасываниях монеты орёл выпадет ровно k раз.

где:
n — количество подбрасываний (в нашем случае 10),
k — количество орлов (успехов),
p — вероятность орла (для честной монеты 0.5),
Cn^k (сочетания из n по k) — число способов выбрать, в каких бросках выпадет орёл.

💡 Тогда при верной H₀ подставляем вероятности p = 1/2, считаем а какая вероятность получить такие же или более экстремальные значения статистики

Считаем P(X=9), P(X=10) и складываем их между собой.
Получаем p-value ~ 0.01074

🔽 Далее, полученное значение p-value мы сравниваем с уровнем значимости.

1️⃣ Если p-value > alpha, не отвергаем H₀, говорим что монетка честная на уровне значимости alpha.
2️⃣ Если p-value < alpha, отвергаем H₀, говорим что монетка нечестная на уровне значимости alpha.

На уровне значимости 0.05 мы можем сказать, что монетка нечестная, на уровне значимости 0.01 результат на грани, но мы не можем отвергнуть нулевую гипотезу.

🙊 А вообще самый сок, это объяснить бизнесу, что такое p-value, мне кажется, это даже можно спрашивать на собесах. Именно не само определение, а как бы вы простым языком на абстрактном примере рассказали продактам, что это такое и почему мы на это смотрим. Интересно почитать будет ваши комменты.

Ставьте 🐳, если пост зашел, делитесь вашими интерпретациями p-value простым языком!

@zasql_python

Всех с субботой!

Ставьте 🐳, если нужно сделать похожий Colab с методами по 🆎, делитесь как провели эту неделю в комментариях (можно мемы 😁)

Го наберём 200 🐳

UPD: большинство методов на 🐍

✅ Про длительность спринтов

Всем привет! Этот пост будет скорее обсуждением, интересно услышать ваше мнение.

🥳 Итак, я уже успел поработать в четырех компаниях. Понятие спринта абстрактное. Если вкратце, планируется определенный список задач на аналитику / разработку, которые должны быть сделаны к концу интервала времени.

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

👀 Лично я столкнулся с тремя видами на работе:

а) Спринт отсутствует
б) Недельный спринт
в) Двухнедельный спринт

🙊 Первый вариант означает то, что мы решаем задачи по мере необходимости, а сроки расставляем в зависимости от сложности задач. Очевидный минус: нет коммита на срок выполнения задач, нет структуры. Но из плюсов: можно адекватно оценить срок выполнения без фактора наличия спринтов.

⌚️ Второй вариант: недельный спринт. Как будто бы, не особо много разницы, ну что, возьмем просто, попилим количество затрат на два и распределим по неделям. Но! У меня было чувство, что я слишком сильно зажат сроками. Постоянные встречи, доработки по задачам и т.д. В этом случае (лично у меня), получалось так, что какой-то процент задач улетал в следующий спринт + я замечал у своих коллег похожее. Это могло быть связано с недооценкой сложности задачи и иными факторами.

😃 Третий вариант: двухнедельный спринт, у меня сейчас. Кажется, что вариант является удобным, так как интервал более-менее растянут + нет такой жесткой привязки по срокам и это меньше давит. У команд разработки часто спринты по две недели, удается быть в синке и распланировать ресурсы более оптимально. Еще очевидный плюс, что задачи размера L (обычно они занимают 5-6 дней) можно без декомпозиции поместить в двухнедельный спринт. Это нам гарантирует сохранение целостности без потери имеющегося контекста. Ну, а задачи с большей сложностью нужно уже декомпозировать 😞

⌛️ Иногда спринт длится и месяц — всё зависит от специфики команды и характера задач. В некоторых отделах задачи представляют собой скорее микропроекты: например, провести серию интервью, проанализировать ответы по конкретному сегменту пользователей и подготовить презентацию результатов для бизнеса.

А как вам оптимальней работать? Какой срок для вас является самым лучшим? Ставьте 🐳, пишите комменты, будет интересно вас послушать!

@zasql_python

🔗 Text2SQL в аналитике: как мы научили ИИ понимать бизнес-запросы без посредников

В этой статье 🖤 описывают, как внедряли Text2SQL, какие модели использовали и обрисовали общую проблематику, реализуя у себя.

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

Пишете в бота: «Средний чек Москва, 2025 vs 2024, динамика в%» → Через 15 секунд получаете точный ответ с трендом.

❓ Как выглядит пайплайн? (упрощение).

1. Запрос пользователя, промпт с описанием таблицы
2. Text2SQL (LLM)
3. Определение типа визуализации.
4. Бекенд -> БД (забрать данные)
5. Чат

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

😜 В качестве MVP предлагается собрать одну витрину. В примере X5 — это табличка с > млрд. строк и ~150 колонок.

Наша цель — не просто построить вопросно-ответную систему, а создать полноценного ассистента, который учитывает контекст и историю диалога. Например, если после первого запроса пользователь пишет: «А сгруппируй не по кластерам, а по магазинам», нам необходимо объединить предыдущие сообщения с новым уточнением. Для этого мы получаем историю из backend, определяем, является ли текущий запрос продолжением, и, если да — формируем краткое суммарное описание диалога. В противном случае передаём исходный запрос без изменений.

🍪🍪 Основные вызовы при решении задачи:

1. Написать логику сборки метрик
2. Учитывать контекст предыдущих сообщений
3. Обработка естественного языка и неоднозначных формулировок
4. Борьба с галлюцинациями
5. Оптимизация скорости и ресурсов
6. Работа с большими схемами данных
7. Интерпретация результата
8. Валидация качества работы модели. В качестве метрики использовали (LLM + EX) / 2 для сравнения нескольких моделей.

🐸 Метрика для оценки качества (LLM + EX) / 2

Метрика рассчитывается через попарное сравнение отсортированных колонок. У этого подхода есть ограничения: если, например, модель вывела долю вместо процента — получим False Negative. Если пользователь сформулировал общий запрос, допускающий несколько корректных SQL-вариантов, то результат также будет считаться ошибкой.

LLM. Совпадает ли сгенерированный SQL с эталонным по логике запроса.
EX (Execution Accuracy). Совпадает ли результат выполнения запроса (таблица/агрегация) с заранее написанным ответом.

🐸 Результаты моделей:

DeepSeek R1 (0.765) — лидер по совокупному качеству: наиболее точные и осмысленные SQL-запросы.
Qwen 2.5-72B (0.425) — уверенное второе место, компромисс между качеством и ресурсами.
SQLCoder-8B (0.185) — слабый результат: частые галлюцинации и ошибки исполнения.

В итоге команда X5 остановилась на Qwen 2.5-72B.

✈️ Дальнейшие планы:

1. Поддержка нескольких таблиц
2. Поддержка запросов с джойнами
3. Внедрение классификации запросов пользователей по сложности
4. Дообучение собственной модели
5. Замена LLM на более лёгкие модели
6. Работа с произвольными Excel-файлами
7. Schema-linking на основе RAG’a

✏️ Дополнительные комментарии

Также, при выборе модели, подходящей под использование на том или ином шаге мы учитываем сложность задачи - например, для перевода технических названий колонок на русский язык с учетом контекста запроса мы выбрали использование более легковесной модели: Qwen3-4B, чтобы ускорить работу системы. Для сложных этапов как, например, генерация SQL, мы используем модели побольше.

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

🔗 За полной статьей сюда, дублирую ссылку.

Ставьте 🐳, если понравилась статья (ну и конечно, если ждете сборник методов по 🆎)

@zasql_python

❓ Вы помните свой первый собес в IT? Как это было?

Давайте разбавим пятницу не душными темами.

Мне кажется, это хорошая рубрика, особенно, для такого замечательного дня недели 🥳

🔽 Можете писать в комменты, а я пока начну.

1. У меня это был Сбер 💳

2. Собеседование было на аналитика (грейд не помню, полагаю, что младший). Команда занималась анализом пдфок, документов, точно не могу вспомнить. Меня все заманивали пойти в офис, когда я был студентом на втором курсе бакалавриата. Но я конечно же соглашался, говорил, что смогу совмещать 🔥🔥

3. Думал про себя: фига я какой классный, позвали на собеседование, сейчас буду получать много денег и работать в бигтехе. Пить матчу на кокосовом молоке 💅

4. Результат: Договорились, что я сделаю тестовое задание и пришлю различные визуализации. Я бы вам показал, только, оказывается затер это все на гите (там были графики на матплотлибе, пандас, все без выводов). Как итог, мне кинули реджект. Я немножко погрустил, но пошел дальше откликаться на доступные вакансии. И было тогда не важно, лишь бы взяли на аналитика 🙏🙏

Почувствовал, что если меня рассмотрели в бигтех, значит можно собеседоваться дальше и останавливаться на этом не нужно.

А теперь ваша очередь — где проходили свой первый собес и что из этого вышло?

Ставьте 🐳, если понравился пост и пишите, какой был ваш первый собес 🔽

@zasql_python