В работе аналитика данные часто говорят одно, интуиция — другое, а неопределенность сопровождает на каждом шагу. Важно уметь применять ее в свою пользу и не бояться.
В этой статье хочу поделиться, как работать с неопределенностью: какие у нее есть виды, как она обманывает мозг и какие есть способы сделать ее понятнее.
Всем привет! Меня зовут Вова Сыропятов, я антифрод-аналитик в Garage Eight. Ключевая задача моей команды — реактивно минимизировать потери от случившихся инцидентов и проактивно митигировать риски.
За время работы в этой области я понял, что умение работать с неопределенностью не менее важно, чем умение работать с данными. Нужно не делать вид, что ее нет, а научиться с помощью конкретных практик получать новую информацию и делать выводы. Некоторое время я вырабатывал эти инструменты для работы с неопределенностью по наитию, а потом прочитал «Антихрупкость» Нассима Талеба и осознал, что у того, что я делал интуитивно, есть название.
Два вида неопределенности
Начнем с видов неопределенности. Их можно обозначить как измеримая и неизмеримая:
Измеримая. Это та неопределенность, с которой умеет работать статистика. Можно не знать точного значения и распределения, но иметь возможность построить доверительный интервал, оценить риск, выставить порог. Именно с ней учат работать на курсах.
Неизмеримая. Здесь неизвестна даже форма пространства возможных исходов. Помню период, когда одна из моих моделей начала вести себя странно: метрики были в норме, ошибок не было, но модель потихоньку смещалась. Я несколько дней докручивал параметры, думал, что это технический дрейф. Оказалось, что изменилось само поведение пользователей, и никакая докрутка не могла это исправить. На основе новых действий клиентов модель решала уже иную задачу, ориентируясь не на команду, а на полученные данные. В таком случае никакой доверительный интервал или риск неприменимы, потому что это неизвестность.
Проблема заключается в том, что с обоими видами часто борются одинаково с помощью увеличения набора данных или применения аналитических инструментов. Это помогает в случае с измеримой неопределенностью. При этом в случае неизмеримой это намного чаще лишь увеличивает сложность системы, которая всё равно не предскажет то, что принципиально непредсказуемо. И именно в борьбе с неизмеримой неопределенностью Талеб оказался для меня полезнее любого учебника по статистике.
Идеи из «Антихрупкости», которые пригодятся в борьбе с неопределенностью
Так совпало, что я прочитал «Антихрупкость» в момент, когда за несколько лет работы накопилось уже множество ситуаций, которые я не мог объяснить. После прочтения в мою практику прочно внедрились три идеи, которые помогают бороться сразу с обоими видами неопределенности.
Асимметрия последствий. Когда неопределенность измерима, стандартный вопрос звучит как «Какой вариант более вероятен?». Но есть ситуации, когда вероятность успеха не так важна, как вероятность ошибки. Осознав это, я перестал вести разговоры со стейкхолдерами в формате «Мы уверены на 80%» и начал задавать вопрос «Какая ошибка для нас критична?». Это куда более продуктивный разговор, потому что он вскрывает реальные приоритеты.
Например, мы выявили механику, которую небольшая группа пользователей начала использовать в обход задуманного сценария, таким образом, по сути, злоупотребляя продуктом. Чтобы справиться с этим, мы можем раскатить изменение на всех пользователей, немного ухудшив их UX, или не менять ничего. И как раз здесь, в зависимости от того, насколько критичны эти ухудшения, мы принимаем решение — раскатывать обновление или нет. В одном из следующих разделов есть подробный пример такого выбора.
Антихрупкость. Эта практика напрямую вытекает из первой и связана уже с неизмеримой неопределенностью. Она приходит неожиданно, и знакомые инструменты часто тут оказываются бесполезны. Поэтому нужно выстроить систему так, чтобы после инцидентов система становилась сильнее, а не просто выживала. То есть каждый неожиданный кейс должен что-то оставлять после себя: обновленную модель, новый триггер в мониторинге, расширенное покрытие. Аналитик не просто извлекает сигнал, а намеренно встраивает его в систему, чтобы следующий похожий удар она встретила уже подготовленной.
Наглядный пример — история с моделью из первого раздела. Именно она подсветила изменение поведения, которое мы потом использовали как сигнал. Аномалия стала данными, и это антихрупкость на практике.
Стратегия штанги. Эта идея объединяет первые две и часто используется в инвестировании. Суть в том, чтобы вложить большую часть ресурсов в надежные и предсказуемые решения, а малую долю оставить на эксперименты с потенциально успешными. Для инвестирования это диверсификация активов на низкорисковые и высокорисковые. Для аналитиков — большая часть работы на проверенных подходах с предсказуемым результатом, а небольшая доля времени и ресурсов — на эксперименты, где цена ошибки ограничена, но выигрыш может окупиться многократно.
При этом важно, что мы не выделяем ресурс на какое-то усредненное решение, потому что оно может оказаться одновременно и рискованным, и невыгодным или неэффективным. Лучше иметь несколько разносторонних инструментов вместо одного идеально оптимизированного, но бесполезного в неопределенности. «Среднее» решение — скоринговая модель среднего уровня сложности, которая вроде бы учитывает всё, но ни в чем не является лучшей. Базовое — классический скоринг на исторических данных по известным сценариям. Экспериментальное — поведенческая аналитика на новые фрод-паттерны, где данных мало, но потенциал детекции высокий.
Хороший пример — расследование кейсов. Стандартный кейс прогоняется по согласованным инструкциям с предсказуемым результатом. Надежно, быстро, без сюрпризов. Высокорисковая сторона включается, когда инструкция ничего не дает, но кейс всё равно выглядит фродовым по отдельным показателям. Тогда мы берем его в спринт на дискавери. Это уже эксперимент: можем потратить время и не найти ничего, а можем обнаружить новую схему. Если находим, то проверяем весь поток клиентов на основе нового выявленного паттерна, дополняем инструкцию и системы алертинга. То есть один эксперимент потенциально улучшает всю систему целиком.
Все три идеи полезны в работе с неопределенностью, но, конечно, не избавляют от нее. Остаются ситуации, когда неизвестность всё равно вводит в заблуждение.
Как неопределенность ломает мышление
Если понимать, как неизвестность может влиять на принятие решений, можно вовремя избежать искажений восприятия. Свои выводы я сделал ценой ошибок, но, возможно, вы сможете их не допустить. Я вижу пять наиболее частых ловушек.
Самая частая ошибка — иллюзия точности. Когда данных много, кажется, что неопределенность снижается. Это не всегда так: иногда больше данных означает лишь более детальный портрет прошлого, а будущее при этом остается таким же туманным. Просто появляется красивый дашборд, который дает ощущение контроля.
Противоядие простое: перед началом анализа явно сформулировать, что именно ты не знаешь. Это дисциплинирует и не дает зарыться в данные без конкретной цели.
Рядом живет зацикленность на первом объяснении. Мозг очень хочет найти причину быстро, и первая правдоподобная гипотеза часто становится «принятой» еще до проверки. После этого все последующие данные интерпретируются в ее пользу — ты уже не анализируешь, а защищаешь готовое решение. Я периодически ловлю себя на этом, особенно когда тороплюсь.
Помогает одна привычка: разделять момент генерации гипотез и момент их проверки, не смешивать эти два режима в одну кашу.
Есть путаница между «не знаю» и «нет данных». Они звучат похоже, но это разные состояния. «Нет данных» можно исправить. «Не знаю» иногда означает, что данные есть, но они не дают ответа — и это нужно признать, а не продолжать собирать информацию в надежде, что она сложится в ответ сама собой.
Самая коварная ловушка — паралич на вопросе «С чего начать работу с неопределенностью?». И я имею в виду не ситуацию, когда задача понятна, но решение неочевидно. Я говорю про момент, когда ты вообще не знаешь, с какого конца подступиться. В таком случае первое, что реально помогает, — остановиться и не бросаться в данные сразу, собрать вовлеченных стейкхолдеров, получить контекст и экспертное мнение, формализовать требования, определить образ результата и декомпозировать задачу. И только после этого определять, какие данные нужны, каких не хватает и что делать дальше. Паралич в такие моменты возникает не от сложности задачи, а от попытки решить ее целиком, не разобрав на части.
И последнее — уверенность, выращенная на успешных кейсах. Когда несколько решений подряд оказались правильными, появляется ощущение, что ты «понял систему». И это опасное место, потому что система могла просто быть стабильной в тот период. Поэтому я периодически пересматриваю старые решения, чтобы понять, какие факторы реально определили исход. Иногда оказывается, что «правильное решение» было правильным по случайным причинам. Это неприятно, но лучше знать об этом до того, как начнешь считать случайный паттерн своей методологией.
Почему избавиться полностью от причины неопределенности не всегда хорошее решение
В моей практике был кейс, который позволил сделать немало выводов о работе с неизвестностью. В Garage Eight ко мне пришел руководитель с посылом «что-то идет не так»: юнит-экономика по региону резко дестабилизировалась. Обычно показатели юнит-экономики живут в достаточно предсказуемом коридоре, а здесь случилось что-то крупное и непонятное. Коллеги обратились ко мне, потому что это мой профиль. При этом сначала я был в тупике: было непонятно, что искать, где искать и какие данные вообще релевантны.
Первое, что помогло, — не начинать сразу копаться в данных, а подготовить все инструменты для этого и собрать контекст. Я выстроил фреймворк: типизировал задачу, нашел пересечения, определил вовлеченные отделы, составил список данных, которые нужны, чтобы понять, что происходит. Уже на этом этапе неопределенность немного отступила, потому что появился конкретный план.
Дальше начался ресерч, и с каждым новым кусочком данных картина становилась чуть яснее. В какой-то момент появилась гипотеза про фрод, я начал ее проверять, подтянул данные из всех вовлеченных отделов. Постепенно проблема, которая казалось крупной и непонятной, превратилась в конкретный кейс с известной механикой. Но история на этом не закончилась.
Когда решение было найдено, возникло естественное желание как можно быстрее его раскатить. Но раскатывать решение сразу на всех — отдельная ловушка, в которую легко попасть в момент эйфории от успеха. Потому что любое решение в антифроде касается не только конкретной группы людей, но и всех пользователей. И прежде чем что-то запускать, нужно было честно ответить на вопрос «А что это решение сделает с продуктом в целом?».
Я пошел по кругу заново. Собрал вовлеченные отделы, расписал риски, проговорил каждый сценарий, привлек отдел, который отвечает за репутацию. Когда мы сложили всё вместе и посчитали VaR от наших потенциальных действий, картина оказалась неприятной: потери от False Positive во временной перспективе превышали сэкономленные от борьбы с фродом средства. То есть технически идеальное решение в реальности было бы хуже, чем отсутствие действий, просто с временным лагом, который не был виден сразу. Вот так выглядит асимметрия последствий, когда она прилетает не из данных, а из твоего же решения.
Дальше началась, наверное, самая трудоемкая часть всего кейса — поиск компромисса. Мы несколько итераций прорабатывали варианты вместе с командой: чем можно пожертвовать, чем нельзя, где граница между приемлемым False Positive и неприемлемым, как выглядит решение, которое ловит не всех фродеров, но при этом не разрушает экономику нормальных клиентов. Каждый вариант считался, обсуждался, снова считался. В итоге мы пришли к решению, которое намеренно оставляло часть проблемы нерешенной, потому что цена полного решения оказалась выше цены самой проблемы.
Самый сложный урок, который я вынес из этого кейса: «решить полностью» и «решить правильно» — это не одно и то же. Иногда правильное решение — это осознанный компромисс, до которого ты доходишь не в одиночку и не с первого раза, а через несколько итераций с людьми, которые видят проблему под другим углом.
Вместо выводов
Всегда хочется закончить чем-то вдохновляющим, но в случае с неопределенностью это не очень честно. Она не исчезнет после прочтения Талеба или применения конкретных практик. Оба ее вида останутся, при этом можно будет с ними работать и получать выгоду.
Я постоянно пользуюсь четырьмя практиками, которые рекомендую использовать и вам:
Перед началом анализа я явно формулирую, что именно не знаю. Не «давайте разберемся», а конкретный список неизвестных. Это звучит банально, но дисциплинирует и не дает зарыться в данные без направления.
В разговорах со стейкхолдерами я обсуждаю конкретный компромисс в каждом сценарии: что теряем, если действуем, и что теряем, если не действуем. Решение принимается исходя из того, какие потери критичнее.
Когда решение найдено, не тороплюсь его раскатывать. Сначала прохожу круг со всеми вовлеченными отделами и отвечаю на вопрос, что это решение сделает с продуктом в целом, а не только с той частью, которую я чиню.
И последнее: регулярно пересматриваю старые решения и правила. Не потому что они были плохими, а потому что среда меняется: появляются новые паттерны, новые инструменты, меняется поведение пользователей. То, что работало год назад, могло устареть — важно замечать это как можно раньше.
Задача аналитика не в том, чтобы победить туман, а в том, чтобы принимать даже внутри него хорошие решения. Они не всегда могут быть оптимальными с технической точки зрения, зато будут честными относительно ограничений и принятыми с пониманием цены ошибки.
Расскажите, как вы работаете с неопределенностью. Буду рад обсудить в комментариях.