Симуляция A/A тестов и зачем это нужно

A/A тест — это эксперимент, где обе группы одинаковы. Он нужен, чтобы проверить: работает ли наша система экспериментов честно и не выдумывает эффекты там, где их нет.

Самое главное, для чего мы проводим синтетический A/A тест (на большом количестве итераций) — это контроль ошибки первого рода. Ошибка первого рода (False Positive Rate) — это вероятность найти изменения там, где их нет. То есть мы заранее знаем, какой процент экспериментов ложно прокрасится (обычно, это очень маленькие вероятности в районе 0.01, 0.05, иногда 0.1, но достаточно редко).

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

В некоторых компаниях есть команда A/B платформы, которая занимается валидацией метрик, применением критериев к различным выборкам / метрикам.

В компании важно уметь пересчитывать ошибки I и II рода на разных срезах. Без этого мы не можем быть уверены, что группы изначально одинаковые. Если этого не будет, то утверждать о том, что изначально выборки были одинаковые (предположение для A/B теста) сказать нельзя. Метрики на предпериоде до эксперимента могут разъезжаться.

В каких случаях стоит запускать проверки?

1. Когда в компании уже есть процесс пересчёта метрик и нужно убедиться, что он работает корректно.
2. Когда появляется новая поверхность или метрика. Важно проверить, что группы не расходятся случайно.
3. Когда есть риск выбросов: несколько объектов могут сильно влиять на результат и завышать вероятность ложных срабатываний.

Я видел историю, когда был запущен эксперимент одним аналитиком, но при подведении итогов на определенном срезе покупателей (кто фактически видел эту фичу), получили ошибку первого рода 0.15 на целевой метрике (по которой мы принимаем решением), хотя ожидалось 0.05, то есть ошибку первого рода мы не контролируем => эксперимент невалиден. Затем я посмотрел, что происходило с группами на предпериоде, целевая метрика по группам разъехалась очень сильно, а это нарушает ключевое предположение A/B теста.

Как запустить синтетическую проверку?

Давайте запустим симуляцию: 10 000 A/A тестов на случайных группах и посмотрим, как ведут себя p-value

import numpy as np
import matplotlib.pyplot as plt
from scipy import stats

data = np.random.normal(loc=100, scale=10, size=10_000)
alpha = 0.05

p_values = []

for _ in range(10_000):

    idx = np.random.permutation(len(data))
    
    a_idx, b_idx = np.array_split(idx, 2)
    a, b = data[a_idx], data[b_idx]
    
    _, p = stats.ttest_ind(a, b)
    p_values.append(p)

print('Ошибка первого рода:', np.mean(np.array(p_values) < alpha)) # в идеале здесь будет значение в районе 0.05
plt.hist(p_values, bins=50, edgecolor="black")
plt.xlabel("p-value")
plt.title("Распределение p-value в A/A тесте (10000 симуляций)")
plt.show()

Что мы ожидаем увидеть в ходе синтетического A/A теста?

Равномерное распределение p-value, которое говорит нам о том, что все хорошо, нет проблем. Это значит, что система работает корректно: ложные срабатывания происходят ровно с той частотой, которую мы задали. Можно думать про это как про честную монетку (предположим, что мы подкидываем ее 100 раз, а затем проводим 10 000 симуляций): иногда выпадет значимо, но ровно с той частотой, которую мы сами задали (например, 5% при alpha=0.05).

A/A тесты — это краш-тест для платформы экспериментов. Если они честные, бизнес может доверять результатам A/B.

Понравился пост? Ставьте 🐳, пишите комментарии, что думаете по поводу A/A тестов.

5 фишек Clickhouse для аналитиков

И снова на диване.

1️⃣ Отрисовка бар-чарта прямо в терминале

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

bar(x, min, max, width)

где х - название колонки, min и max - диапазон, а width - ширина бара в символах.

2️⃣ Словари для доступа к часто используемым справочникам

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

joinGet('dictionary_name', 'attribute', key)

3️⃣ Функция для воронки продукта

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

windowFunnel(window_seconds)(
    timestamp_column,
    event1_condition,
    event2_condition,
    ...,
    eventN_condition
) 

4️⃣ Найти цепочку событий

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

sequenceMatch('pattern')(timestamp, cond1, cond2, ..., condN) 

5️⃣ Функции для АВ-тестов

ClickHouse позволяет делать анализ АВ-тестов прямо в SQL, спектр доступных функций довольно широкий. Приведу два примера:

studentTTest(sample1, sample2) -- равенство стредних

proportionsZTest(successes1, trials1, successes2, trials2) -- равенство долей (конверсий) в двух группах

P.S. Возможно, твоя задача решается проще, чем ты думаешь, нужно всего лишь загуглить или заджипитить)

Ставь 🔥, если узнал что-то новое

Ставь 🤕, если все это знал

#SQL_на_диване
@Divan_data

SGR Deep Research: как из чёрного ящика агентов сделать прозрачную и надёжную систему

Сегодня у нас на повестке дня крайне интересный инженерный проект от наших соседей по тг. Но начнем с конца.

Все мы примерно представляем, как работает вызов инструментов у агентов. LLM сам решает, какие Tools вызывать, в какой последовательности и зачем. Модель адаптируется к результатам, может прерывать выполнение – в общем, полноценная автономия.

Звучит красиво и работает, но в прикладном продакшене у такого подхода есть обратная сторона:
– мониторинг и логирование практически невозможны – цепочка вызовов превращается в чёрный ящик,
– сложно отлаживать и объяснять решения модели,
– A/B-тестирование и контроль качества превращаются в боль.

Именно здесь появляется альтернатива – Schema-Guided Reasoning (SGR). О самой подобной идее много кто уже где-то так или иначе упоминал даже в крупных стартапах, но, что примечательно, впервые end-to-end ее описал и формализовал автор канала "LLM под капотом" (@llm_under_hood) Ринат Абдулин. Вот дока.

Основная концепция: вместо того, чтобы давать модели полную свободу, мы описываем чёткую схему рассуждений в виде структурированного вывода.
Один запрос – один прозрачный reasoning-пайплайн: Анализ → Поиск → Обработка → Вывод.

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

Звучит интересно, правда? Да. Выглядит, как подход, который теоретически может подвинуть классические agent-фреймворки, если речь идёт о продакшене и задачах бизнеса. Прозрачность и контролируемость тут не просто nice-to-have, а буквально вопрос выживания продукта.

А еще это настоящий качественный скачок для маленьких моделей, которые плохи в вызове инструментов сами по себе. Например, Qwen3-4B показывает на Function Calling низкие 2%, а с SGR выдает стабильные 85-90%! Таким образом, целый огромный класс моделей, которые до этого для не подходили для агентных задач, теперь становятся для них открытыми. Это ключевое открытие.

Ну так вот. На основе описанной Ринатом техники другой наш друг, Валера с канала @neuraldeep, уже собрал полноценный опенсорсный production-ready проект SGR Deep Research. О Валере и его предыдущих проектах мы писали вот тут – почитайте.

Его SGR Deep Research – это система для многошагового поиска и анализа информации в интернете. Реализовано:

➖ Вызов инструментов по схеме Schema-Guided Reasoning. Причем подход гибридный, с двухфазной архитектурой: принудительное структурированное рассуждение (JSON Schema) + детерминированное выполнение. Это позволяет даже 4B моделям проявлять агентные свойства, недоступные через классический Function Calling.
➖ Прозрачное логирование на каждом шаге: от уточнения запроса и генерации плана до веб-поиска, анализа и финального отчёта, все трекается.
➖ Работа на легких моделях вроде gpt-4o-mini и qwen instruct от 4b до 32b (+можно подключать свои).
➖ OpenAI-совместимый API с персистентными агентами: каждый агент получает уникальный ID для продолжения исследования.

Где это лучше, чем полноценный агентный Tools? Там, где важна прозрачность + работа с малыми моделями. Например: работа с документами, корпоративные исследования, факт-чекинг, call-центры. Плюс – возможность запускать агентов на потребительском железе вместо дорогих API.

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

Еще раз:
Ссылка на проект
Ссылка на канал Рината – автора идеи
Ссылка на канал Валеры – автора кода (здесь можно следить на развитием проекта)