Кусочек пиццы | Аналитика данных

Разбор кейса на тему оценки новой фичи в e-com

Это тестовое задание на позицию продуктового аналитика в один из российский екомов.

Задание #1

Менеджер продукта PDP внедряет новый функционал, функционал заключается в том, что на странице карточки Ювелирных украшений (Колец) появляется ссылка - «Я не знаю размер».

Вопросы:
- Как бы вы оценили полезность такого функционала до её внедрения?
- На какие метрики вы бы смотрели и как их считали?
- Что нужно считать после внедрения этого функционала?
- Что необходимо передавать в аналитические базы данных, чтобы дать ответ менеджеру, что функционал приносит дополнительную ценность?

Задание #2

Вы проводите AB тест по внедрению функционала:
Вариант A - калькулятор для подбора колец.
Вариант B - таблица размеров.
Оба варианта открываются после клика по ссылке «Я не знаю размер».

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

и получили результаты. Распределение: 10% - калькулятор, 90% - таблица размеров.

На что, по вашему мнению, стоит опираться при выборе того, какой функционал нужно выкатывать на 100%?

Давайте отвечать по порядку.

1. Как оценить полезность до внедрения 💸

Сначала про механизм.

У кольца есть размер, и покупатель часто его не знает. Особенно если берёт его в подарок.

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

Общий потенциал фичи в таком случае равен:

Потенциал = Потенциал (доп заказы) + Потенциал (снижение возвратов)

, где

Потенциал (доп заказы) = трафик карточек колец × прирост конверсии в заказ × маржа заказа

Потенциал (снижение возвратов) = заказы колец × доля возвратов по причине "неподходящий размер" × снижение доли возвратов × стоимость обработки возврата

прирост конверсии / снижение доли возвратов - это как раз эффект фичи, который мы можем заложить через MDE.

2. На какие метрики смотреть и как их считать

- Целевая метрика: маржа с учётом возвратов на участника эксперимента.

- Барьерная: доля возвратов по размеру.

- Вспомогательная: конверсия в добавление в корзину и конверсия в заказ

3. Что считать после внедрения

Добавление в корзину не равно заказу, заказ не равен выкупу, а выкуп не равен деньгам, пока не прошёл срок возврата.

Для колец это особенно важно.

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

Поэтому я бы считал эффект по когортам с закрытым окном возврата.

4. Что передавать в аналитические базы

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

Самое важное - связка заказа с тем, пользовался ли покупатель подсказкой.

Без неё не отличить эффект фичи от сезонного роста категории.

5. Какой вариант катить на 100%

В условии спрятана ловушка.

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

Я предлагаю не менять целевую метрику и принимать решение по марже

Пишите в комментах, какие кейсы вы хотели бы разобрать.

Рассмотрим их в следующих постах 🍕

Открыта вакансия ко мне команду

Ищу к себе в команду маркетингового аналитика.

Идеальный кандидат: специалист с опытом работы в маркетинговой аналитике, знакомый с инструментами веб/ мобильной аналитики, атрибуцией и умеющий оценивать эффективность каналов.

Предстоит много задач: от базовой разметки событий и работы с источниками, до участия в развитии модели LTV для анализа эффективности каналов и проведения гео тестов.

Описании вакансии

Резюме можете отправлять мне в личку или рекрутеру по ссылке выше.

Всем пиццы🍕

Что нас ждёт через несколько лет

В прошлых постах на тему харнессов мы разобрали теорию: контекст, а также скиллы, инструменты и оркестрацию.

В них же я обещал рассказать, как это реализовано у нас в компании.

Что ж, смотрите схему.

Она построена по пути задачи: от постановки до публикации результатов. Всего пять этапов:
1. Постановка задачи
2. Определение способа решения
3. Решение задачи
4. Оценка результатов
5. Публикация и обновление артефактов харнесса

1. Постановка задачи

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

В любом случае её всегда подхватывает скилл `task-groomer`. Его работа - выжать из запроса конкретику: что считаем, на какой выборке, что считаем за результат и по каким критериям его принимаем.

Если в постановке дыра, он останавливается и задает пользователю уточняющие вопросы.

Далее определяем способ решения задачи.

2. Определение способа решения

Состоит из двух подэтапов:
1. Определение домена, к которому определена задача
2. Определение агента, который будет эту задачу решать

Сначала `task-router` смотрит, к какому направлению относится задача.

Если направление ещё не активировано в репозитории (это управляется отдельным флагом админом репозитория), он говорит об этом и предлагает активировать. Писать в неактивное направление он не станет: оно доступно только на чтение.

Потомподключается domain-agent.

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

3. Решение задачи 🔬

За решение задач отвечает несколько агентов.

`ab-lead` отвечает за эксперименты и определяет, какой это тип теста (клиентский, квази, свитчбэк) и что надо сделать (задизайнить, оценить результаты, сделать пост-анализ). Далее он отдаёт задачу одному из шести скиллов (пример скиллов: дизайн клиентского теста, дизайн свитчбэка, оценка клиентского теста и тд).

`bi-analyst` собирает дашборды в Superset и Databricks. Если ему нужны пайплайны или витрины - идёт за этим к data-engineer.

`researcher` ведёт исследования, `debugger` разбирается, почему числа в дашбордах или витринах не сходятся, `metadata-specialist` отвечает, что значит таблица и когда обновлялась, `local-specialist` работает под уникальные задачи направления (пример: парсинг цен).

4. Оценка результатов

Перед публикацией результат уходит к `reviewer`.

Он не видел, как считали, и получает только результат с доказательствами.

Дальше смотрит глазами скептика: откуда взялась выборка, повторяются ли числа, что осталось за скобками.

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

5. Публикация и обновление артефактов харнесса

Когда ревью пройдено, включается `report-agent`. Он пишет отчёт по единому шаблону, и он единственный, кому разрешено писать в базу знаний.

Кроме того, раз в неделю запускается `librarian` и идёт по всей базе.

Ищет все, что лежит в репозитории не на своих местах: устаревшие факты, неописанные таблицы, устаревшие скрипты или ссылки и тд.
Далее он складывает находки в пулл-реквест и отдаёт владельцу направления.

Ускорило ли это мою работу?

Однозначно да.

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

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

Порой такая многозадачность выжигает мне мозг. Об этом писал в посте «Многозадачность - это ложь».

Но отказаться я уже не могу.

На этом я планировал закончить серию постов про харнессы, но если хотите узнать какие-то детали, то ставьте 🔥 и пишите вопросы в комментах.

Могу детальнее рассказать про конкретные скиллы, инструкции и тд.

В линкедине увидел новый термин – «мясной прокси»🥩

Так называют людей, которые просто копируют ответы ChatGPT или Claude в рабочие чаты, не проверяя их и иногда даже не понимая, что именно отправили.

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

Замечали в себе такое?
Я иногда замечаю..

На выходных я был на свадьбе, поэтому новых постов я не написал.

Держите топ постов за последнее время, если вдруг пропустили.

1. Как статистика применяется в бизнесе?
2. Кейс с собеседования: дизайн AB-теста для новых тарифов
3. Что такое харнесс и с чем его едят?
4. Кейс с собеседования: батчинг заказов
5. Мифы работы аналитиком данных
6. Как LLM убеждает нас верить в ошибочные гипотезы
7. Статистика в бизнесе. Часть 2
8. Я не люблю А/В-тесты
9. Метрики 101. Часть 4: Маркетплейсы
10. Метрики 101. Часть 5: Такси и доставка

Из чего состоит харнесс? Часть 2

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

2. Скиллы

Это какая-нибудь регулярная процедура, которую агент должен регулярно выполнять.

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

взять список ингредиентов -> посмотреть на уже отданные рецепты -> сходить в интернет -> найти новый рецепт -> проверить его на осмысленность -> отдать пользователю.

Обсуждаете ее с LLM и просите упаковать в скилл.

В результате вы сможете каждый раз получать новый рецепт блюда конкретно под ваш запрос.

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

Главный смысл скилла как раз в контексте.

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

3. Инструменты

Другими словами - это руки агента.

Слой инструментов занимается регистрацией, валидацией схем, извлечением аргументов, изолированным выполнением, захватом результатов и форматированием их в наблюдения, читаемые LLM.

Claude Code предоставляет инструменты по шести категориям: файловые операции, поиск, выполнение, веб-доступ, анализ кода и запуск субагентов.

Сюда же я бы отнес и MCP-коннекторы, позволяющие получить доступ к сторонним сервисам (Google Sheets, таск-трекеры, мессенджеры и тд).

4. Оркестрация

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

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

Например, чтобы делать дашборды, строить пайплайны и дизайнить а/б тесты, нужны 3 разных субагента или скилла.

Может возникнуть вопрос:

Когда делать скилл, а когда субагент?

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

Субагента - когда задача съест кучу контекста (перелопатить репозиторий, прочитать 50 отчетов), а наверх нужен только вывод.

Вернемся к орекстрации.

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

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

Он не будет это делать в 100 случаях из 100, т.к. промпт - это все-таки рекомендация, а не обязательное условие.

Если вы хотите сделать этот процесс надежнее, то придется настраивать workflow (например, в n8n) с обязательными триггерами.

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

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

Хуки.

Это код, который выполняется на событие, например перед вызовом инструмента, после записи файла или в начале сессии. Хук просто срабатывает.

Цепочки внутри скилла.

Один скилл в конце своей работы сам вызывает следующий.
У меня так собран пайплайн для постов.

Команда написания черновика в конце сама дергает факт-чекинг, потом ревью, потом редактуру.

Последовательность прописана заранее, модель ее не выбирает.

Ставьте 🔥, если хотите поподробнее узнать про мой кейс реализации харнесса для задач аналитики. Разберу в отдельном посте.

Ставьте 🧡, если хотите больше постов про работу с ИИ.

А если хотите освежить знания в статистике или метриках, загляните на https://data-slice.ru/

Что такое харнесс и с чем его едят?

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

Harness (в переводе с английского - обвязка) - это грубо говоря набор инструментов вокруг LLM, превращающий чат-бот в полноценного агента.

Иногда в интернете проводят параллель с компьютером и представляют харнесс в виде операционной системы.

Операционная система на компьютере позволяет нам управлять компьютером, операционная система над моделью позволяет управлять моделью.

Также нашел другое классное определение: Harness - это сбруя.

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

Окей, с определением разобрались.

Из чего состоит харнесс?🛠

В целом, в лучших практиках выделяют 12 различных компонентов.

Я же в своей презентации давал упрощенный формат и выделял только 4: контекст, скиллы, инструменты, оркестрация.

Пройдемся по каждому.

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

1. Контекст

Контекст - это область знаний, в рамках которых оперирует модель.

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

Управление контекстом - одна из ключевых задач при работе с харнессом.

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

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

Архитектурно я делю контекст на три слоя.

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

Загружаемый по требованию - скиллы, инструкции, справочники.

В постоянный контекст попадает только название и одна строка «когда меня вызывать», а полный текст подтягивается, когда скилл реально запустился.

Временный - история конкретной задачи, план, вызовы инструментов, промежуточные результаты. Живет ровно столько, сколько идет задача.

Как это реализовать?

Расскажу про 4 приема, которые предлагает Anthropic.

Just-in-time доступ
Не загружайте данные заранее, храните ссылки: путь к файлу, id дашборда, текст запроса. Модель сама сходит и достанет, когда понадобится.

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

Субагенты
Грязную работу вроде «перелопатить 200 файлов и собрать статистику» отдаете отдельному агенту с собственным чистым окном.

Наверх он возвращает выжимку на 1-2 тысячи токенов вместо всего, что прочитал.

Компактификация.
Когда история подходит к лимиту, она сжимается в резюме, и разговор продолжается с чистого окна.

И отдельно хочется сделать ремарку про инструкции.

Частая ошибка - прописывать жесткую логику «если пользователь сказал X, сделай Y» на все случаи жизни.

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

Рабочий вариант посередине. Описываете принципы и даете пару показательных примеров.

Во второй части разберу оставшиеся три компонента.

Ставьте 🔥, если ждете продолжение.

А если хотите освежить знания в статистике или метриках, загляните на https://data-slice.ru/

Завтра буду проводить вебинар по использованию ИИ в аналитике для школы Simulative.

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

Буду рад всем😉

Дата: 29.08.2026
Время: 12:00 по мск

Ссылка на вебинар

Выкатил новый апдейт интерактивного тренажера по статистике

https://data-slice.ru/

Что добавил:
• Модуль по временным рядам
• Поиск по темам и ключевым словам
• Обновил иерархии метрик
• Внес небольшие правки в дизайн

Дальше планирую добавить роудмапы по основным ролям в области работы с данными.

Пишите в комменты, чего вам не хватает на сайте.

Буду очень рад обратной связи🍕

Кейс с собеседования: батчинг заказов

Этот кейс встретился на тех. интервью в в суперапп из Катара, занимающийся доставкой еды, продуктов, товаров и тд.

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

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

Одним словом: задизайнить а/б тест.

Давайте решать кейс по порядку.

1. Метрики

Чтобы разобраться с метриками давайте подумаем о механизме работы фичи.

Формально у нас работает трехсторонний маркетплейс: клиент - поставщик - компания.

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

Итак, про компанию.

У любого заказа есть постоянная часть расходов: подача курьера, поездка до клиента и ожидание на точке.

Допустим, у нас есть 3 заказа. Мы можем повезти их как в одной поездке, так и в нескольких.

В случае группировки всех заказов в одну поездку - расходы на курьера будут ниже, т.к. постоянная часть расходов (ставка за выезд, например) будет распределяться по 3м заказам вместо одного.

Это важно учитывать, поэтому смотрим на метрику Delivery Cost per Order, а рядом держим batch rate (количество заказов в динамике в одной поездке).

Теперь, про клиента.

Маршрут на три точки длиннее одного.

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

Смотрим на распределение времени доставки (Click-To-Eat).
Как минимум нам будут интересны среднее/ медиана и 95й перцентиль, чтобы оценить, разброс критических значений распределения.

Можно добавить еще метрик, но мы пока ограничимся.

2. Что по поводу гипотез?

Сформулируем нулевую (H0) и альтернативную (H1) гипотезы.

H0: батчинг не снижает стоимость доставки
H1: батчинг снижает стоимость на MDE%

MDE в данном случае берем по истории похожих экспов (100% они уже были) или пытаемся высчитать из юнит-экономики. Я бы целился в 2%.
Это мы и будем тестить.

3. Теперь guardrail

За барьерную метрику я бы предложил взять Средний рейтинг клиента на заказ (Average Order Rating), долю отмен (Cancelation Rate), и долю опозданий (DelayRate).

Если одна из метрик выскакивает за 2 стандартных отклонения -> стопаем эксперимент.

4. Как оценить эффект?

Третий вопрос самый интересный.

Ранее я писал про сетевой эффект и это тот самый кейс.

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

Поэтому в нашем кейсе недостаточно делать поклиентский тест. Необходимо оценивать эффект через switchback, где единица рандомизации - пара "зона × тайм-слот".

Тайм-слот это отрезок, внутри которого в зоне работает один режим. Например час: с 12 до 13 в центре батчинг включён, с 13 до 14 выключен, порядок случайный.

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

Единица анализа - тоже слот, а не заказ.

Метрику агрегируют до слота и сравнивают слоты между собой. Размер выборки в данном случае - количество переключений между слотами.

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

Ставьте 🙏, если хотите узнать и про другие этапы собеса в эту компанию.

Ставьте🔥, если хотите больше разборов кейсов.

Ну и заходите на сайт data-slice.ru, если хотите освежить знания в статистике или метриках.

Оч рекомендую послушать крутой доклад от CEO Y combinator "Garry Tan: Own Your Intelligence" https://youtu.be/eRrc1pUY5oU?si=FmtbTRsVODdySV7L

Статистика в бизнесе. Часть 2

Первый пост собрал на удивление много реакций, поэтому, как и обещал, выкладываю второй.

В этот раз - про то, как определять, что влияет на метрику и как моделировать ее динамику в будущем.

🔮 Уровень 4. Что влияет на метрику и что будет дальше

Вопрос бизнеса: что влияет на метрику, и как она будет вести себя в будущем?

Можно заметить, что вопрос выше состоит из 2х частей.
Разберем каждую из них отдельно.

Что влияет на метрику

Довольно часто мы хотим понимать, как изменение одного фактора на 1 единицу влияет на изменение метрики в среднем.

Это необходимо, чтобы заложить эту цифру в юнит-экономику или фин. модель.

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

На этот вопрос позволяет ответить линейная регрессия.

Формула регрессии: y = β₀ + β₁x + ошибка, где

β₁ - , на сколько в среднем меняется выручка (y), когда трафик прирастает на одного посетителя (x).

β₀ - значение выручки при x = 0.

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

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

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

Что будет дальше

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

Это та же самая регрессия, в которой вместо фактора подставляется время.

Но просто продлить прямую по времени вперед не получится, и вот почему.

Декомпозиция

То, что мы видим на графике, - это несколько движений сразу.
Поэтому ряд сначала раскладывают на тренд, сезонность и остаток.

Тренд показывает, куда метрика движется на самом деле.

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

Остаток - шум, который моделировать не нужно.

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

Автокорреляция

Разделили, но остается вторая особенность.

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

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

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

Стационарность

Последнее требование. Модели ждут, что среднее и дисперсия ряда не меняются во времени.

Растущая выручка этому не удовлетворяет, поэтому ряд дифференцируют - переходят от самих значений к их приростам.

Модели

Ниже перечень, основных моделей используемых для прогнозирования временных рядов.

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

ARIMA работает с автокорреляцией: описывает ряд через его собственное прошлое - авторегрессию (зависимость от предыдущих значений) и скользящее среднее (зависимость от предыдущих ошибок).

SARIMA - ее сезонное расширение, которое учитывает сезонность явно.

SARIMAX - добавляет к ряду внешние факторы: промо, праздники, изменение цены.

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

Ставьте 🔥, если хотите разбор ещё каких-то концепций из статистики через призму бизнеса - соберу часть 3.

Как LLM убеждает нас верить в ошибочные гипотезы

Замечали ли вы, что ИИ часто вам поддакивает?
Истории, когда ИИ открыто врет, а при уточнении отвечает "точно я был не прав" уже превратились в мем. Но у этого «подхалимства» есть обратная, куда более опасная сторона.

Свежее исследование MIT подсветило фундаментальную проблему: ИИ спроектирован так, чтобы поддакивать нам (AI Sycophancy), загоняя даже опытных специалистов в «спираль заблуждений» (delusional spiraling).

Давайте разберем, как устроен этот механизм и почему обычный здравый смысл тут не всегда спасает. 👇

Что такое AI Sycophancy и как оно работает
Подхалимство моделей - прямой результат их обучения. Нейросети получают «награду», когда их ответ нравится человеку. В итоге ИИ выучил простое правило: чтобы пользователь остался доволен, нужно согласиться с его мнением, а не указывать на логические дыры

Как это выглядит на практике:

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

🔸В текстах и текстах для презентаций: Вы приводите слабый аргумент, а бот хвалит вашу «глубокую мыслительную работу».

🔸В разработке и дата-анализе: Вы выдвигаете неверную гипотезу о баге или просадке метрик, а ИИ поддакивает: «Да, ваша логика безупречна, проблема именно в этом».

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

Самые неприятные выводы из статьи MIT ⚠️

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

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

И здесь есть три важных вывода:

™️ Отсутствие галлюцинаций не спасает.

Даже если привязать ИИ к правдивой базе знаний и запретить ему выдумывать факты (через RAG), он все равно загонит вас в ошибку. Бот не врет напрямую, он просто делает cherry-picking - выдает только те реальные факты, которые подкрепляют ваше заблуждение, и умалчивает об опровержениях.

™️ Знание о подхалимстве не защищает.

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

™️ Спираль замыкается незаметно.

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


Как с этим работать (правила ИИ-гигиены)


™️ Программируйте ИИ на жесткую критику.

Забудьте наводящие вопросы.
Промптите от обратного:

«Я пришел с такой идеей/гипотезой: [X]. Выступи в роли жесткого эксперта и критика. Разнеси мою логику. Найди минимум 3 слабых места и причины, почему это не сработает».

™️ Требуйте опровергающие аргументы.

Заставляйте бота искать альтернативные точки зрения:

«Какие факты, метрики или контраргументы противоречат моей позиции?»

™️ Сначала думаем сами - потом открываем чат.

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

™️ Практикуйте «аналоговый режим».

Периодически решайте задачи, пишите тексты и анализируйте проблемы вообще без нейросетей.

Постоянная срезка углов через ИИ создает когнитивный долг - мозг постепенно разучивается критически мыслить и самостоятельно строить сложные причинно-следственные связи.

Как часто вы ловили ИИ на том, что он радостно поддакивал очевидным ошибкам? Делитесь в комментариях! 👇

🔗 Ссылка на исследование MIT (февраль 2026): Sycophantic Chatbots Cause Delusional Spiraling, Even in Ideal Bayesians

отвечает только на вопрос, насколько наблюдаемая разница необычна для мира без эффекта.

Практический вывод: p-value решает, отвергаем ли мы гипотезу, но ничего не говорит о размере эффекта. Что именно вы получили - показывает доверительный интервал из Уровня 2.

Выбор критерия.

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

Цена ошибки здесь выше всего: неверный критерий занижает разброс, и тест начинает находить эффекты, которых нет. Команда раскатывает изменение, а метрика в проде не растёт.

Критерий выбирается первым - все дальнейшие расчёты делаются под конкретную статистику.

Ошибки I и II рода.

Задают требуемый размер выборки и цену риска. Ошибка I рода - вероятность принять шум за эффект и внедрить бесполезное. Ошибка II рода - вероятность не заметить настоящий эффект и упустить рабочее решение.

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

Мощность и объём выборки.

Уровень значимости, мощность, размер эффекта и дисперсия вместе определяют размер выборки.

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

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

Все эти концепции я разобрал в интерактивном формате на сайте. Заходите, если хотите освежить знания.

Если пост соберёт много реакций❤️‍🔥, сделаю продолжение про остальные концепции и их применение в бизнесе.