Джудея Перл и причинное мышление: ИИ, дебаг и продукт

Зачем говорить о причинности в разработке и ИИ

Причинность — это про ответы на вопросы вида: «что изменится, если мы сделаем X?». В разработке и в ИИ таких вопросов больше, чем кажется: от «почему упал конверт» до «почему модель внезапно стала хуже на новых пользователях».

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

Почему без причинного мышления решения часто промахиваются

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

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

Где это особенно болит

• ИИ и модели: модель хорошо работает на истории, но ломается при переносе на другой регион/канал. Часто дело в скрытых факторах и смене причинных связей.
• Аналитика: метрика «ведет себя странно», но причина не в продукте, а в логировании, изменении выборки или смещении сегментов.
• Эксперименты: A/B тест проведен, но интерпретация неверна — например, из‑за перекосов в раскатке или влияния внешних событий.
• Отладка систем: устраняем видимую ошибку, но первопричина — в цепочке зависимостей, очередях, ретраях, кэше.

Что вы получите из этой статьи

Дальше мы соберем «язык причинности» для команды: как формулировать эффекты изменений, видеть конфаундеры, корректно читать эксперименты и задавать контрфактические вопросы. Итог — более предсказуемые решения в продукте и меньше сюрпризов в ИИ и продакшене.

Корреляция против причины: где нас обманывают данные

Данные отлично отвечают на вопрос «что часто происходит вместе?», но гораздо хуже — на «что из этого что вызывает?». Причинно-следственная связь — это когда изменение одного фактора приводит к изменению другого при прочих равных: если убрать или поменять причину, эффект должен (в среднем) поменяться тоже.

Причинность vs статистическая зависимость

Статистическая зависимость (корреляция) означает лишь, что два события движутся вместе: например, чем выше X, тем чаще мы видим Y. Но причинность требует более строгого утверждения: «если мы вмешаемся и изменим X, то Y изменится».

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

Пример из разработки: «после обновления выросли падения»

Фраза звучит убедительно, но это ещё не доказательство причины. Возможные альтернативы:

• Одновременно с релизом вырос трафик (например, после рекламной кампании), и система стала чаще попадать в редкие ошибки.
• Изменился состав устройств/версий ОС: пришли пользователи с более старыми телефонами.
• Поменялась система логирования: падения стали лучше фиксироваться, а не реально участились.
• Релиз выкатили не всем, а только определённой группе — и группа сама по себе «склонна» к падениям.

Во всех этих случаях есть связь «обновление ↔ падения», но причина может быть в третьем факторе (конфаундере) или в измерениях.

Почему «большие данные» не гарантируют правильных выводов

Размер выборки снижает шум, но не исправляет смещение. Если данные собраны так, что в них смешаны разные группы пользователей, разные сценарии и разные условия, вы можете получить очень «статистически значимую» корреляцию, которая не выдержит простого вопроса: «что будет, если мы целенаправленно изменим X?».

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

Причинные графы: понятный способ записать «как устроено»

Причинный граф (чаще — направленный ациклический граф, DAG) — это простая визуальная запись ваших представлений о том, как факторы влияют друг на друга. Узлы — переменные, стрелки — предполагаемое направление влияния. Если мы рисуем X → Y, мы утверждаем: изменения X способны приводить к изменениям Y (при прочих равных).

Важно, что граф — не «истина», а модель допущений. Его сила в том, что он заставляет договориться: что именно мы считаем причиной, что — следствием, и какие связи мы исключаем.

Мини-словарь: кто есть кто в графе

• Причина (cause): переменная, от которой выходит стрелка к другой.
• Следствие (effect): переменная, в которую входит стрелка.
• Медиатор (mediator): промежуточное звено в цепочке X → M → Y. Он объясняет механизм, через который X влияет на Y.
• Конфаундер (confounder): общий источник, который влияет и на X, и на Y (Z → X и Z → Y). Именно он часто делает корреляцию похожей на причинность.

Зачем фиксировать допущения явно

Когда допущения остаются «в голове», команда спорит словами: «мне кажется, причина вот в этом». Граф переводит разговор в конкретику: какие стрелки мы рисуем и почему. Это быстро выявляет пробелы: забытый конфаундер, перепутанное направление связи, смешение медиатора с причиной.

Дополнительно граф помогает заранее понять, какие данные вообще нужны. Например, если вы подозреваете конфаундер Z, но его не измеряете, это важный риск: оценка эффекта X на Y может быть смещена.

Как граф превращает спор «почему» в проверяемую модель

С графом проще задавать проверяемые вопросы: какие переменные контролировать, чтобы отделить эффект X от влияния Z; через какой медиатор идет эффект; какие наблюдения должны измениться, если мы вмешаемся в X.

Так причинный граф становится «контрактом» между продуктом, аналитикой и разработкой: мы не просто смотрим на цифры, а явно описываем, как устроена система, и проверяем это по данным и экспериментам.

Наблюдение, вмешательство и контрфакты: 3 уровня вопросов

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

1) Наблюдение: что мы видим

Наблюдательные вопросы звучат так: «У кого чаще случается отток?», «Какие пользователи больше платят?», «С чем коррелирует падение конверсии?». Здесь мы описываем мир как он есть — без заявлений о том, что именно вызвало эффект.

Это полезно для мониторинга, сегментации и поиска сигналов, но опасно для выводов вида «значит, нужно сделать X».

2) Вмешательство: что будет, если мы поменяем X

Вопрос «если повысить цену, вырастет прибыль?» — это не про наблюдение, а про вмешательство: мы мысленно «крутим ручку» цены и хотим понять эффект изменения.

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

3) Контрфакт: что было бы, если бы мы поступили иначе

Контрфактический вопрос: «Если бы мы не выкатывали релиз, произошёл бы инцидент?», «Если бы алерт сработал на 10 минут раньше, снизился бы ущерб?». Это критично для разборов инцидентов и спорных решений: команда спорит не о фактах (они уже случились), а об альтернативных сценариях и ответственности причин.

Как путаница уровней ломает аналитику и дебаг

Типичный сбой: увидеть корреляцию (уровень наблюдения) и принять продуктовое решение так, будто это доказанный эффект вмешательства. В дебаге аналогично: симптом принимают за причину, потому что «всегда вместе». Полезная привычка — сначала явно формулировать, на каком уровне вопроса вы находитесь, и какие данные/эксперименты нужны именно для него.

Интервенции и do(): как формулировать эффект изменения

Обычные данные почти всегда смешивают два разных смысла: что мы наблюдаем и что мы намеренно меняем. Do-оператор Джудеи Перла нужен именно для того, чтобы разделить эти утверждения. Запись вида P(Y | do(X = x)) читается как «что будет с Y, если мы вмешаемся и принудительно установим X в x», а не «что происходит, когда X просто оказался равен x».

«Мы увидели» против «мы сделали»

Когда вы смотрите на логи продукта, вы чаще всего видите условие вида P(Y | X = x): например, «конверсия выше у пользователей, у которых включена реклама». Но это может быть следствием отбора: рекламу могли включать более активным сегментам, или она включалась в часы пикового спроса.

Do-оператор фиксирует другое утверждение: P(Y | do(X = x)) — это эффект переключателя, а не «характеристика тех, у кого так получилось».

Пример: do(реклама=вкл) vs «реклама включена» в данных

• Наблюдение: «У пользователей с реклама=вкл средний чек выше». Это E[чек | реклама=вкл].
• Интервенция: «Если мы принудительно включим рекламу пользователям, что станет со средним чеком?» Это E[чек | do(реклама=вкл)].

Разница критична: в наблюдении «реклама=вкл» может быть маркером сегмента (например, премиум‑пользователи видят другой формат), а в интервенции мы говорим о последствиях реального изменения настройки.

Зачем это нужно для фич и изменений алгоритмов

Команды часто делают выводы из корреляций: «после запуска фичи метрика выросла», «модель чаще показывает этот блок — значит, блок полезен». Но причинный вопрос звучит иначе:

• «Как изменится метрика, если мы включим фичу всем (или конкретному сегменту)?»
• «Что будет, если мы заменим ранжирование на новую версию, не меняя остального?»

В терминах do() это помогает честно сформулировать цель: оценить эффект вмешательства, а не описать «портрет» пользователей/сессий, где вмешательство встречается.

Какие данные нужны, чтобы отвечать на вопросы про do()

Идеальный источник — рандомизированный эксперимент: он напрямую приближает do(X=x), потому что назначение X не зависит от скрытых причин.

Если эксперимента нет, понадобятся данные и допущения, которые позволяют «развязать» наблюдаемую связь:

• измеренные факторы, которые влияют и на X, и на Y (потенциальные конфаундеры: сезонность, источник трафика, сегмент, цена, устройство);
• четкое определение интервенции (что именно меняем и что остается неизменным);
• стабильные правила логирования и идентификации воздействия (кто реально «получил» изменение);
• достаточно вариативности X, чтобы сравнение было осмысленным.

Без этого формула с do() останется правильно заданным вопросом — но на него невозможно будет надежно ответить по имеющимся данным.

Конфаундеры: главный источник ложных «причин»

Конфаундер (confounder) — это переменная, которая влияет и на предполагаемую причину X, и на результат Y. Из‑за неё данные легко «убеждают» нас, что X вызывает Y, хотя на самом деле оба меняются из‑за третьего фактора.

Почему среднее и регрессия часто ошибаются

Если в выборке не учтён конфаундер, то простое сравнение средних («у тех, кто сделал X, конверсия выше») или регрессия («Y зависит от X») смешивают эффекты: часть изменения Y объясняется не X, а скрытой переменной.

Классическая ловушка: мы добавили в модель «все доступные признаки», но не включили намерение пользователя (или включили его плохой прокси). Тогда коэффициент при X становится «магнитом», который притягивает эффект намерения — и выглядит значимым.

Пример из продукта: активность и конверсия

Допустим, аналитика показывает: пользователи с высокой активностью (много сессий) чаще покупают. Возникает соблазн сделать вывод: «увеличим активность — вырастет конверсия».

Но конфаундером может быть, например, интерес/потребность: люди, которые уже хотят купить, и чаще заходят, и чаще оформляют заказ. Если мы начнём «разгонять активность» пушами и триггерами, то можем поднять число сессий, но не конверсию — или даже ухудшить её из‑за раздражения.

Практика: как искать конфаундеры в доменной логике и логах

Начинайте не с формул, а с вопроса: «Что могло заставить пользователя и сделать X, и прийти к Y?». Частые кандидаты — сегмент, сезонность, канал привлечения, скидки, задержки доставки, качество трафика, намерение.

Дальше проверьте это по логам: сравните распределения таких факторов между группами X=1 и X=0, посмотрите временные сдвиги (что было раньше), найдите переменные, которые меняются до X. Если потенциальный конфаундер существует и различается между группами, причинный вывод без контроля (или без эксперимента) становится рискованным.

Эксперименты и причинный эффект: как правильно читать A/B

A/B тест ценен тем, что отвечает на причинный вопрос: «что изменится, если мы сделаем X?». При корректной рандомизации различия между группами в среднем компенсируются, и разница в метрике становится оценкой эффекта вмешательства — того самого «do()» из причинного подхода.

Когда A/B действительно измеряет причинный эффект

Тест измеряет причинный эффект, когда выполнены три условия: пользователи (или сессии) случайно попали в группы; воздействие реально отличается только по тестируемому фактору; измерение метрики одинаково для обеих групп.

Важно уточнить, что именно является вмешательством. «Включить новый алгоритм ранжирования» — одно вмешательство. «Показать новый UI + изменить логику уведомлений» — уже пакет, и эффект нельзя честно приписать одной причине.

Что может пойти не так

Перекрёстное влияние (interference). Если пользователи взаимодействуют (маркетплейсы, соцсервисы, реферальные механики), эффект одного пользователя может зависеть от группы другого. Тогда разница A/B — смесь прямого и сетевого эффектов.

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

Нарушение рандома и экспозиции. Пользователь мог попасть в тест, но не увидеть изменение (кеш, редиректы, разные клиенты). Либо наоборот — часть контроля увидела тест. Тогда вы измеряете не «эффект фичи», а «эффект назначения в тест» (intention-to-treat), и это нужно назвать явно.

Метрики и окна измерения

Окно наблюдения — скрытая часть формулировки. Эффект «на 1 день» может отличаться от эффекта «на 14 дней»: новизна интерфейса, адаптация пользователей, сезонность.

Также метрика может включать задержанные последствия. Например, рост кликов сегодня может ухудшить удержание через неделю. Если окно слишком короткое, A/B выглядит победой, хотя причинный эффект по важной цели отрицательный.

Как связать A/B и причинный граф

Причинный граф помогает проговорить: узел T — это ваше вмешательство (флаг/фича), узел Y — целевая метрика, а остальные узлы — пути, через которые T влияет на Y.

Полезный приём: перед запуском описать «do(T=1)» словами — какое именно действие в системе меняется, у кого, и какие побочные каналы (уведомления, выдача, цены, нагрузка) могут стать альтернативными путями влияния. Тогда чтение результатов становится честным причинным выводом, а не угадыванием по цифрам.

ИИ и причинность: устойчивость, перенос и ошибки обобщения

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

Почему «модель предсказывает» не означает «модель понимает причины»

Предсказательная модель может опираться на удобные суррогатные признаки. Например, «дорогой смартфон» как прокси платежеспособности или «время суток» как прокси типа аудитории. Это может давать высокий скор на валидации, но при изменении среды прокси ломаются: люди меняют устройство, расписание, поведение, а реальная причина целевого события остаётся прежней.

Причинное мышление заставляет спросить: какие факторы действительно влияют на результат, а какие просто идут рядом. Это снижает риск построить систему, которая «угадала прошлое», но не переносится в будущее.

Сдвиги распределений: что ломается при переносе на другой контекст

Сдвиг распределений — это когда данные «сегодня» отличаются от данных «вчера»: другой регион, сезон, интерфейс, канал трафика, правила модерации, экономика. В таких условиях модель может:

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

Именно здесь проявляются ошибки обобщения: модель «умная» в одном контексте и неожиданно «слепая» в другом.

Что даёт причинное мышление для устойчивости и переносимости

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

На практике это означает: формулировать гипотезы как эффекты вмешательств — «что изменится, если мы сделаем X?» — и проверять, не является ли X лишь следствием других факторов. Такой подход помогает выбирать фичи, корректнее строить офлайн‑оценку и честнее интерпретировать улучшения.

Где применимо: ранжирование, рекомендации, скоринг, детекция аномалий

• Ранжирование и рекомендации: отличать «пользователь выбрал» от «пользователю показали». Позиция в выдаче, формат карточки и частота показов — это вмешательства, которые сами создают данные.
• Скоринг: учитывать, что решения системы меняют поведение клиентов (feedback loop).
• Детекция аномалий: не путать «аномалию» с ожидаемым эффектом внешнего изменения (распродажа, новый тариф, сбой партнёра).

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

Отладка систем: поиск первопричины вместо симптомов

Типичный сценарий в продакшене: метрика просела, алерты горят, команда открывает дашборды и начинает «чинить то, что видно». Часто это заканчивается улучшением симптома и ухудшением системы: скорость выросла, а конверсия упала; точность модели поднялась, но жалобы пользователей участились.

Причинное мышление помогает задать правильный вопрос: не «что изменилось рядом с метрикой», а «какое изменение породило просадку — и через какой механизм». Это дисциплинирует отладку так же, как хорошие логи: вы не подменяете объяснение совпадением.

Первопричина, медиаторы и побочные эффекты

Полезно разделять три роли:

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

«Дерево причин» и проверка гипотез

Практика: от целевой метрики строится дерево возможных причин, а не список «подозрительных графиков». Для каждой ветки формулируется проверяемая гипотеза: если причина X верна, то при вмешательстве Y должно измениться Z. Дальше — минимальный тест: откат фичи, выключение компонента, ограниченный эксперимент, симуляция нагрузки.

Контрфактический вопрос против «фикса не того»

Перед тем как коммитить исправление, задайте контрфактический вопрос: «Что бы произошло с метрикой, если бы мы не вносили изменение X при прочих равных?» Если вы не можете описать этот сценарий даже качественно, велик риск лечить корреляцию. Контрфакты заставляют уточнять механизм — и чаще приводят к точечному, безопасному ремонту, а не к серии случайных правок.

Продуктовые решения: думать эффектами, а не сигналами

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

Почему корреляции толкают к неверным решениям

Типичная ловушка: «пользователи, которые включают функцию X, удерживаются лучше — значит, надо продвигать X». Но включение X может быть просто маркером «вовлечённых» или «опытных» пользователей. Если начать агрессивно продвигать X всем, эффект может оказаться нулевым или отрицательным (дополнительные шаги, перегруз интерфейса, раздражение от подсказок).

Полезный сдвиг мышления: перестать спрашивать «с чем связана метрика?» и начать спрашивать «что произойдёт, если мы сделаем Y?». Это и есть переход от сигналов к эффектам.

Как формулировать гипотезу в терминах причинного эффекта

Хорошая продуктовая гипотеза звучит как причинное утверждение:

«Если мы изменим Y (вмешательство), то M (целевой эффект) изменится на Δ за T времени, потому что меняется механизм K. Побочные эффекты — R.»

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

«Поднять метрику» vs «изменить механизм»

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

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

Согласование начинается не с расчётов, а с общего описания причинной модели: что мы считаем причинами, что — следствиями, какие факторы могут «маскировать» эффект.

Практика: на созвоне перед экспериментом за 15 минут зафиксируйте (1) вмешательство, (2) основной эффект, (3) ключевой механизм, (4) риски и альтернативные объяснения, (5) что именно будет считаться успехом. Тогда A/B перестаёт быть «проверкой метрики» и становится проверкой причинного утверждения, понятного всем участникам.

Отдельно полезно помнить о скорости цикла «гипотеза → вмешательство → измерение → откат/закрепление». Если вы используете TakProsto.AI для создания веб‑, серверных или мобильных приложений через чат (React на фронте, Go + PostgreSQL на бэкенде, Flutter для мобайла), то причинный подход помогает не просто быстро «собрать фичу», а сразу описать интервенцию (что именно меняем) и критерии эффекта. А такие возможности платформы, как planning mode, снапшоты и rollback, упрощают безопасные эксперименты: вы быстрее проверяете do(X) на практике и так же быстро возвращаетесь к стабильной версии, если эффект оказался не тем.

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

Причинный анализ полезен только тогда, когда он превращается в повторяемый командный процесс. Ниже — короткий чеклист, который можно использовать на планировании фичи, разборе инцидента или перед запуском A/B.

1) Мини-чеклист перед любыми выводами

• Сформулировать вопрос в форме эффекта: «Что изменится, если мы сделаем X?» вместо «Почему метрика Y такая?».
• Нарисовать причинный граф (хотя бы на доске): ключевые переменные, стрелки влияния, где именно происходит вмешательство.
• Перечислить конфаундеры: факторы, которые влияют и на X, и на Y (сезонность, сегменты пользователей, каналы трафика, нагрузка, изменения UI, политика выдачи и т.д.).

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

Если можно — делайте эксперимент: рандомизация чаще всего дешевле, чем месяцы споров.

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

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

3) Проверить себя на прочность

Спросите: какие альтернативные объяснения ещё совместимы с наблюдениями? Что будет, если конфаундер измерен плохо или пропущен?

Полезная практика — простая проверка чувствительности к допущениям: «Насколько сильным должен быть невидимый фактор, чтобы перевернуть вывод?».

4) Документировать причинные гипотезы как часть спецификации

Записывайте причинную модель рядом со спеком изменения: цель, предполагаемый механизм, ключевые конфаундеры, метрики, ожидаемый знак эффекта, план проверки и критерии отката. Так причинность становится не «философией», а частью инженерного контроля качества.

Если команда часто делает внутренние разборы или публичные заметки по экспериментам, можно дополнительно формализовать это как процесс «обучения организации»: например, выдавать внутренние шаблоны для do‑формулировок, хранить графы допущений рядом с задачами и поощрять публикации. Кстати, в TakProsto.AI есть программа начисления кредитов за контент о платформе и реферальная программа — это может стать приятным бонусом, если вы делитесь практиками причинного анализа и инженерными кейсами на материале реальных проектов.