asisakov

Аналитик из Wildberries

Существует легенда, что ни один ML-инженер не шарит так сильно в SQL, как аналитики!

А Дмитрий, автор канала «Дима SQL-ит», решил пойти ещё дальше и показать, что в SQL есть куда копать даже тем, кто уже уверенно с ним работает 😺

Дима работает аналитиком данных в Wildberries и публикует много теории и кейсов из практики — всё структурированно и по делу 🤝

Что рекомендую посмотреть в первую очередь:

🟡Подборки бесплатных материалов для изучения: SQL, Python, BI (дашборды), статистики и A/B тестов
🟡Как агрегатные функции в SQL (SUM, AVG, COUNT) ведут себя с NULL?
🟡SQL-ловушка: почему NOT IN ломается, а EXISTS работает — классическая проблема с NULL, на которую часто натыкаются
🟡Горячие клавиши в DBeaver, Jupyter и VS Code — семь комбинаций, которыми Дима пользуется каждый день
🟡Telegram-бот, который шлёт сообщение, когда скрипт завершился
🟡Разбор задач в Т-банк, Магнит OMNI, Авито и другие компании.....
🟡Простые разборы статистики и теории вероятностей: P-value, Формула Байеса и других тем


➡️ Подписывайтесь, чтобы не потерять: @dima_sqlit

Что случилось

Яндекс выложил в открытый доступ базовую LLM, обученную с нуля. Это AliceAI-Foundation-80B-A3B-Base - базовая ллм моделька под лицензией Apache 2.0. И это первая большая LLM Яндекса, обученная полностью с нуля, без инициализации из весов других моделей! (предыдущая Alice AI LLM 235B стартовала с весов Qwen3-235B-A22B)

🔖Эта модель - MoE Transformer на 80B параметров, из которых 3B активных. Состоит из 48 трансформерных блоков с hidden size 2048 и одного multi‑token prediction слоя. Каждый MoE‑слой содержит 512 routed experts с top‑k 10 и один shared expert. А для роутинга используется auxiliary‑loss‑free подход из DeepSeek‑V3. Из 48 attention‑слоёв 36 используют Kimi Delta Attention, а 12 full attention: после каждых трёх KDA‑слоёв расположен один full‑attention‑слой. Для агрегации представлений по глубине используется Attention Residuals (AttnRes), заменяющий обычное суммирование обучаемым взвешиванием.

На 8 из 10 бенчмарков фактологических знаний и экспертных навыков модель занимает первое место среди сравниваемых открытых претрейнов, и особенно сильна в задачах про Россию и русский язык. особенно круто, что работу с инструментами ребята заложили уже срзау в претрейн, потому что сильного reasoning без tool-use недостаточно для агентов. Напомню, что это базовая модель до посттрейна, и поэтому сравнивать напрямую с готовыми ChatGPT, Claude или Gemini некорректно. У нее еще нет ни инстракт SFT, ни полноценного RL.

Для обучения команда фактически пересобрала весь процесс обучения, начиная с корпуса данных и архитектуры до собственных scaling laws. Этапы претрейна состоят из 4-ех стадий, и их можно будет увидеть в таблице во вложении. Для построения же scaling laws брали модели на 5B и 10B параметров, обучали на 100–600B токенов с оптимизатором Muon и линейным scheduler.

Что интересного - первый запуск с предсказанным LR привёл к росту MoE-активаций и резкому скачку loss. Ребята воспроизвели проблему на небольшой модели и после стабилизации активаций вернулись к исходному прогнозу. Также была и еще одна интересность: конфигурация с меньшим batch size (8M, lr 5,5e-4) обошла большую (16M, lr 7,8e-4) в среднем на 0,46 п. п., причём улучшения были на 10 из 59 бенчмарков.

Кстати, по бенчам сравнивались с Alice AI LLM 235B, Qwen3.5-35B-A3B-Base, GLM-4.5-Air-Base (106B-A12B), Nemotron-3-Super-120B-A12B-Base и DeepSeek-V4-Flash-Base (284B-A13B). У модели при этом меньше и общих, и активных параметров, чем у всех, кроме Qwen. На 8 из 10 бенчмарков фактологических знаний, образования и экспертных навыков модель заняла первое место. Особенно сильна в задачах про Россию и русский язык, а на MATH-500 лучшие скоры.

AliceAI-Foundation-80B-A3B-Base предложена как экспериментальная база, на которой коллеги проверяют архитектурные и обучающие решения для будущей единой рассуждающей модели). На её основе будут развивать агентские возможности Алисы AI: посттрейн, SFT, полноценный RL, RLVR, работу с тулами и поиск.

Если вам нужна сильная русскоязычная базовая модель для дообучения - то это самый лучший вариант! Все необходимые подробности есть в техрепорте на Хабре, а веса лежат на HF!

Техрепорт
Модель

#llm

Пыхтит

Снова понедельник

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

Только вот силы тоже все

Кстати, рутина - это вообще не наша работа. Наша работа быть человеком, а это про думать, выбирать, договариваться, планировать. На рутиниу сейчас пусть попыхтит агент. Он же не устает, не раздражается, не спрашивает лишних вопросов (иногда зря конечно, но ему виднее). Но и тут не всё так просто, агенту нужен контекст: что берем, что делаем, почему именно так делаем, а так не делаем, и что решаем в непонятных ситуациях.

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

🔠🔠🔠🔠🔠🔠

Что делать, чтобы переключиться на человеческое:

1️⃣Я не устану повторять - ломайте привычные ритуалы, пытайтесь осознанно понимать, что вы делаете в данную секунду времени!
2️⃣Дайте мозгу выпустить все, что внутри, на бумагу или другие носители информации (допустимо даже записать видосик)
3️⃣Либо побудьте в состоянии глубоко фокуса без задействования сильных мыслительных процессов (побегать например)

А пыхтит пусть агент! Говоришь ему: "сделай все иделаьно", и он конечно же прходит с результатами, но не теми, что мы ждем. Поэтому тут можно постараться заранее на неделе и:

▫️Описать процесс по составляющим: что на входе, что на выходе, что делать, и что не делать
▫️Раздать доступы и отследить, чтобы он не навертел там ничего лишнего!
▫️Попросить отправлять все на ревью нам в первое время, а потом командовать ему, чтобы уже сам принимал решения и уже советовался

Допустим, пришло письмо, а агент может отсортировать, разметить и приготовить черновик ответа. Допом если что соберет данные из таблиц, обновит статусы, и если что, пришлет утренний бриф. После встречи если что, он пришлет пасшифровку, саммари, список задач и сразу заведет тикеты. При необходимости соберет следующую встречу, найдет свободные окошки у коллег, даже заполниты пререквезиты! При этом один агент мсожет вести и несколько рутин, если контексты не конфликтуют. НО ВСЕ ЖЕ регулярно проверяйте, что агент не врет и не выдает смещенный результат.

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

А какую рутину вы уже отдали агентам?

#agents

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

Как думаете, это не слишком жестко было?

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

Почему агент может работать неправильно, даже если в конце отвечает верно?

Этим вопросом задались авторы статьи "AgentProcessBench: Diagnosing Step-Level Process Quality in Tool-Using Agents"

В существующих бенчах AgentProcessBench, GAIA и τ²-Bench есть проблема оценки только по результату: они сообщают об успешном завершении E2E задачи, но при этом не позоляют оценить сигналы, которые могли бы дать оценки исполнения скиллов по шагам - ведь по итоговому скору мы не поймем, выбрала ли модель правильный инструмент, не сломала ли свой стейт и проверила ли вообще данные перед финальным ответом!

Как вы наверно уже догадались, авторы статьи предложили оценивать сами шаги агентов, использующих тулы - и создали свой отдельный бенчмарк! И сначала взяли по 50 задач из HotPotQA, GAIA, BFCL и τ²-Bench. Чтобы снизить дисбаланс, task descriptions закодировали через E5 (преобразовали в вектора), а затем отбирали задачи с максимальным pairwise embedding distance. Идея в том, чтобы отобрать задачи, которые максимально различаются по содержанию. Далее каждую из 200 полученных задач прогнали через пять моделей разного класса, от Qwen3-4B до GPT-5. И так получили 1000 траекторий и 8509 действий.

Агенты работали с реальными инструментами:

▫️Для HotPotQA авторы подняли локальный E5-ретривер по Wikipedia
▫️В GAIA дали Google Search, Jina-браузинг и CLI для файлов
▫️Для BFCL и τ²-Bench использовали официальные наборы инструментов, которые были предложены авторами бенчей.

После, каждую траекторию размечали два опытных независимых эксперта. Совпадение между разметчиками получилось 89,1%, Cohen's kappa - 0,767 (подробнее про метрики тут). Каждое действие получало один из трёх сигналов:

➕1️⃣: шаг корректный и продвигает решение к корректному ответу
0️⃣: шаг нейтральный или исследовательский
〰️1️⃣: шаг ошибочный или вредный

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

В статье есть хороший пример с саппорт-агентом. Пользователь говорит, что у него gold-статус и просит повышенную компенсацию. Агент вызывает get_user_details, видит в системе regular и просит подтверждение статуса. Авторы, следовательно, ставят этому шагу ➕1️⃣: модель проверила данные через тул.

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

Авторы прогнали 20 LaaJ-моделей из шести семейств, чтобы смоделировать ответы разметчиков. Лучшей стала Gemini-3-Flash-Preview-Thinking: 81,6% точности по отдельным шагам и только 65,8% при поиске первой ошибки в траектории. У сильнейшей открытой модели, Qwen3-30B-A3B-Thinking-2507, точность 68,5% и 52,0% соответственно.

Ещё был отдельный опыт с обучением через GRPO. На 800 размеченных траекториях модель получала reward за точность step-level разметки, ещё 200 оставили для проверки. Validation StepAcc вырос с 55,3% до 74,6%. Судя по постановке, здесь тренировали именно процессный evaluator, который ставит метки шагам. Агентов, собиравших траектории, этот эксперимент не затрагивал (базовую модель авторы не озвучили).

На что я рекомендую обратить внимание:

▫️Забрать идею сохранять траекторию и результаты тулколов вместе с результатом
▫️Попробовать разметить на своих трейсах первый ошибочный шаг, чтобы затем найти узкое горлышко;
▫️Ну и очевидно мерить не только финальный результат!

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

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

Статья
Код

#papers

⚡ Почему p-value ничего не решает и как научиться доводить A/B-тест до реального бизнес-решения?

Большинство аналитиков совершают одну и ту же ошибку: считают, что задача теста — получить «значимый» p-value. Гипотеза кое-как сформулирована, метрики выбраны наспех, а решение о запуске принимается по одной цифре. В итоге — тесты, которые невозможно защитить перед бизнесом, и споры «нравится или нет» вместо аргументированного вывода.

Аслан Байрамкулов — руководитель направления алгоритмических продуктов в ЦУМ, 10+ лет в аналитике и больше 6 лет профессиональноально занимается экспериментами и причинно-следственным выводом (Яндекс.Такси, X5 Retail Group, МТС, Wildberries) — проведёт бесплатный вебинар «A/B-тесты в продуктовой аналитике» и разберёт эксперимент от идеи фичи до рекомендации бизнесу.

Вы узнаете:
🔶Как превратить размытое «улучшим checkout» в проверяемую гипотезу с механизмом, метрикой и аудиторией;
🔶Как строить дерево метрик — целевую, второстепенные и guardrails — вместо бессвязного списка KPI;
🔶Как правильно считать MDE, размер выборки и длительность теста, чтобы не гнаться за шумом;
🔶Какие проверки данных (assignment, logging, population, SRM) нужно пройти до анализа эффекта;
🔶Почему сегментный сигнал нельзя просто раскатывать на всю аудиторию;
🔶Как оформить неоднозначный результат в decision tree и executive memo, а не в таблицу с p-value.
На вебинаре разберём один сквозной кейс — упрощение пути совершения заказа в интернет-магазине. Пройдём весь путь эксперимента: от идеи и гипотезы до готового решения — запускать фичу на всех, придержать, доработать или перезапустить тест.

🎁 ПОЛУЧИТЕ 3 КУРСА (PYTHON, SQL, PANDAS) В ПОДАРОК ЗА РЕГИСТРАЦИЮ НА ЭФИР!

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

🛎️Регистрируйтесь, эфир совсем скоро!

Команда DevCrowd* запустила ежегодное исследование специалистов по работе с данными

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

В этом году фокус на том, как меняется профессия: что AI реально сделал с составом работы, где проходят границы между дата-сайентистом, ML- и MLOps-инженером, что происходит с порогом входа в профессию и рынком труда. Часть вопросов задается третий год подряд, что дает реальную динамику, а не просто срез.

Опрос анонимный, 12–15 минут. В ноябре ребята опубликуют отчет со всеми данными, а также списками рекомендованных телеграм-каналов и курсов, собранными из ответов участников.

Мне самому очень интересно узнать мнения, потому что наша команда лидирует направление AI-трансформации в аналитике у нас в Яндекс Лавке, потому что я на своих глазах и проектах буквально вижу как все меняется. И конечно же хочется понять прямо на статистике, как это происходит у коллег с других компаний и в частности у коллег с бигтехов

Пройти опрос: https://survey.devcrowd.ru/data-2026

*DevCrowd — это независимые исследования IT-профессий: 15 000+ участников, публичные отчеты по Golang, SRE , мобильным разработчикам и другим направлениям

Так, я тут с опросом оказывается немного накосячил - в последнем пункте долно было быть не "Пишите в комментарии, почему", а "Dropout"

book‑to‑skill

Как превратить любую книгу в навык

Если вы уже пробовали закидывать PDFки в чат‑ботов и получали либо хреновы пересказы, либо полные галлюцинации, то есть хороший шанс протестировать новый подход к работе с этим. А именно перейти на загрузку релевантного текста по запросу! (кстати, звучит как RAG, и это почти он и есть). Этот скилл берёт документ/книгу/статью почти любого формата (PDF, EPUB, DOCX, TXT, MD, HTML, MOBI и т. д.) и ПРЕВРАЩАЕТ В ОТДЕЛЬНЫЙ СКИЛЛ, в который агент ходит только тогда, когда мы спросим о необходимой нам информации из определенной главы.

В ридми написано, что это экономит токены и дает более точные ответы

Ставится супер просто

git clone https://github.com/virgiliojr94/book-to-skill.git ~/.claude/skills/book-to-skill
cd ~/.claude/skills/book-to-skill

pip install -r requirements.txt # python 3.10+, poppler‑utils (pdftotext) и docling

/book-to-skill ./my‑book.pdf my‑book # → ~/.claude/skills/my-book/

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

Когда это применимо?

▫️Берем ADR, ранбуки, логи, гайды, превращаем в один навык и спрашиваем потом по ним как по базе знаний
▫️Иногда может быть полезно сразу задать по сути несколько вопросов вместо листания длинныз документов
▫️Можно кстати еще собрать свой кластер быстрых знаний при работе над дипломом или статьей, где будут лежать несколько статей, собственные заметки и новые материалы для анализа

Короче, вот ссылка: https://github.com/virgiliojr94/book-to-skill/tree/master

Кстати, там написано, что книга на 120к токенов контекстка смогла со скилло мзнаять всего лишь 4к токенов. Хотя хз сколько там было сожжено при создании этого скилла 🤣
Не суть, ведь можно зато собрать сразу дофига книжек/статей и по ним вести свой ресерч, не заводя отдельный RAG. Мне кажется в этом и преимущество скилла!

#agents #llm #books

Так, я тут внезапно залетел в соревку kaggriculture

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

#competition

Практический хардкорный ML

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

19 сентября в Москве оффлайн и в трансляции онлайн пройдет Practical ML Conf - хардкорная конференция от Яндекса, где обсуждают практическое применение ML. Это микс технических докладов, жарких дискуссий и мощного нетворкинга. Кстати в программе почти в каждом из залов можно встретить легенд! Я бы сказал доклады и дискуссии только из легенд и состоят 😈

Зачем туда идти (помимо классического кайфа от крутых Яндексовых тусовок):

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

🐍 Организаторы поймали того самого автора известного кодинг-агента Ouroboros (Антону привет💪). Он расскажет про его петлю самоулучшения и как они обошли Codex, Claude Code и Cursor по бенчмаркам. Плюс будут разборы Computer-Use агентов: как они работают в реальном браузере и какие грабли на них наступили.

⚡️ Как ужать стоимость прогона LLM до предела: KV-aware-маршрутизация, спекулятивное декодирование, разделение prefill/decode и многоуровневый кеш.

🧠Также в меню жаркие дискуссии и доклады от топов R&D Яндекса, Сбера, Т-Банка и Авито. Разберут экономику массового инференса, эволюцию рекомендаций и подходы к обучению LLM.

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

Главная фишка этого года - Yandex ML Prize

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

Где и когда:

🗓 19 сентября (суббота), Москва, Loft Hall #8 + Онлайн-трансляция в зале "Сеть"
✏️ Регистрация открыта прямо сейчас! (офлайн по персональным приглашениям, онлайн для всех)

Бронируйте в своих календарях, регайтесь по ссылке ниже и пересылайте пост коллегам! Это отличный повод развиртуализироваться, обсудить ML-грабли в кулуарах и классно провести техническую субботу!

👉 Занять место на конференции: https://pmlconf.yandex.ru/

Интересная история про чела из Платы

Короче, есть пост от бывшего сотрудника Мексиканского банка Плата, где он рассказывает, что снял короткое видео, где сравнил Banco Plata и Т-Банк. Он успел поработать в Тиньке, а на тот момент работал в Плате. Сам ролик залетел!

Через некоторое время его пригласили на серьезную встречу с топ-менеджером и HR, и по словам чела к нему было несколько претензий про то, что он "сделал сайт с формой, куда собирал телеграмы желающих работать в Plata — компании лиды, себе реферальный бонус". Чел пишет что не знал, что так нельзя, и удалил в тот же день, также были вопросы к общению в комментах и слив внутренних данных. Это он отрицает и говорит, что с порога летели только обвинения, разговаривать никто не пытался.

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

Это все по словам чела, ссылку на оригинал выше я приложил

Пост кстати разлетелся и в телеге, и в тредсе, и в линкедыне:

В коммментариях пишут, что он же сам, уже после увольнения, записал видео, где рассказал, что менеджеры вызывали его и объясняли, что снимать можно, а что нелья. И что после этого разговора он выпустил ещё два ролика в том же духе. Звучит как чела попросили, а он проигнорировал.

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

Есть еще третья группа комментаторов, где рандомные люди из финтехов рассказывают, что у них в контракте прописан прямой запрет упоминать имя банка где-либо, кроме LinkedIn, и любая публичная коммуникация проходит через юристов, комплаенс и PR. Кто-то еще ишет, что прописано это далеко не везде, и если в договоре упоминаний могло и не быть.

Есть кстати еще прямо интересная ссылочка, которая показывает, как именно чел собирал "телеграмы желающих работать в Plata". Рекомендую ознакомиться, и возможно вы поменяете свое мнение. Потому что та самая форма выглядела вот так: "Хочешь работать в Plata? Помогу дойти до оффера"

Вот и делайте выводы

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

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

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

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

#career #softskills

В чем соль A/B-экспериментов

В хэшах и в рандоме говорите вы

Раньше я думал, что для обычного A/B теста мы берем user_id, считаем или не считаем хэш, делим на 2 и отправляем четных ~50% пользователей в контроль, остальных в тест. Ну типа подшаманил немнога, и сплитовалка готова.

Кстати, user_id % 2 — это вообще не рандомизация. id часто выдаются шардами, пачками, например по типу регистрации. И четность здесь спокойно коррелирует с реальными свойствами юзера. Хэш нужен, а чтобы порвать эту связь.

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

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

bucket = H(experiment_id + ":" + unit_id) % 10000

Прикольно, что в этой схеме для одного теста входы не меняются, и пользователь остаётся в своем бакете. Но стоит нам посчитать разбивку для нового теста (с новым experiment_id), то сразу получаем другую рассплитовку. При этом соль по сути не меняет расчет хэша, мы скорее меняем вход в сам хэш. И это могут быть уникальные раскладки для каждого теста. Типа salt = 'new_awesome_algorithm'.

НО соль - это immutable experiment_id. И по-хорошему туда не стоит класть имя эксперимента. Если во фразе 'new_awesome_algorithm' кто-то решит поправить опечатку в названии или переименовать конфиг, то весь сплит поедет посреди теста. И тот же id нельзя переиспользовать при перезапуске: будут те же группы, уже затронутые влиянием от прошлого прогона.

И даже разделитель при склейке обязателен! Представьте кейсы, когда у нас есть ("exp1", "23") и ("exp12", "3"), и без разделителя это выдаст один и тот же хэш. Сам hash() в питоне рандомизируется между процессами. А hashCode() и CRC32 плохо перемешивают биты, и соседние соли могут дать скоррелированные разбиения (то есть ровно ту проблему, ради которой мы соль и завели). Можно брать murmur3 / xxhash / md5, 64 бита. И всегда брать одну и ту же реализацию на бэке, на фронте, в мобилке и в табличке, которую мы потом перепроверим.

Всегда следите за руками:

▫️Менять соль, experiment_id, unit или алгоритм посреди теста не стоит даже пробовать
▫️Ровное 50/50 разделение у нас только по бакетам, но не по живым людям! Поэтомучекаем хи-квадрат на соотношение групп. Это вроде бы называется SRM (эксперты поправьте)
▫️Один пользователь всё ещё может попасть сразу в два теста - и это норм, если соли независимые: рандомизации ортогональны, оценка эффекта не смещается. Разводим только конфликтующие фичи, и для этого делают слои: внутри слоя тесты взаимоисключающие, между слоями независимые

Короче, нормальный контракт сплитовалки выглядит так:

🙂 Стабильный unit_id (не забываем про анонимных юзеров!)
🙂 Неизменный алгоритм с нормальным перемешиванием
🙂 Неизменный experiment-specific salt
🙂 Заранее продуманная схема изменения трафика - классика, когда расширяемся симметрично (5/5 → 10/10 → 50/50)
🙂 Регулярно считаем A/A!

Давайте не будем считать статистику по плохим данным! Давайте делать это четенько!

#ab #statistics #analytics