ABTest Agent (Meta): ограничение недетерминированности LLM и защита от p-hacking в аналитике

Архитектура делит систему на недетерминированный контур выбора (LLM) и детерминированный контур вычислений и контроля (код):

УРОВЕНЬ 1 (Контекст и выбор — LLM): Запрос пользователя → загрузка профильного скила (из 97 скилов) + обращение к урезанной базе проверенных знаний → выбор порядка шагов (модель НЕ считает ни одной цифры сама)
УРОВЕНЬ 2 (Валидированный вызов — Код): Вызов CLI-утилит с фиксированными аргументами (отсев дат вне жизни теста и битых параметров ДО расчёта) + обязательная автопроверка здоровья данных (из системного промпта)
УРОВЕНЬ 3 (Выходной шлюз — Report Gate): Сборка отчёта строго по шаблону → проверка кодом: все ли секции заполнены и ведут ли все таблицы/графики на типизированные артефакты расчёта (если нет — возврат модели на доработку)
УРОВЕНЬ 4 (Контроль сессий — Audit): Отделение поисковой отладки от решения о запуске → проверка логов на перебор временных окон, метрик и выкидывание «плохих» дней задним числом

Задача: Вы настраиваете аналитического ИИ-агента (например, в Claude Code или корпоративном боте с доступом к ClickHouse/Postgres), который помогает продакт-менеджерам проверять результаты продуктовых тестов и маркетинговых акций. Нужно защитить команду от галлюцинаций в цифрах и от соблазна «натянуть» успешный результат отчёта перед защитой у руководства.

Промпт (фрагмент системной инструкции CLAUDE.md / AGENTS.md и правил работы со скилами аналитического агента):

# Регламент аналитического агента (по архитектуре Meta ABTest Agent)

## 1. Граница вычислений (Никакой арифметики в голове)
- Тебе ЗАПРЕЩЕНО считать проценты, дельты, p-value, средние или агрегаты самостоятельно в тексте ответа.
- Твоя задача — выбрать подходящий скил и вызвать детерминированную CLI-утилиту из папки `./tools/analytics_cli/`.
- Каждая цифра и таблица в твоём ответе обязана содержать прямую ссылку на ID артефакта, созданного утилитой.

## 2. Обязательная проверка здоровья данных (Data-Integrity Gate)
- При ЛЮБОМ запросе результатов эксперимента ты обязан первым шагом (до вывода метрик) запустить проверку целостности (`check_experiment_health`):
  1) какие даты реально доехали в хранилище;
  2) нет ли перекоса сплитования (SRM) или дублирования событий при ротации версий;
  3) не входят ли в запрос даты за пределами жизни теста или дни с техническими инцидентами.

## 3. Защита от p-hacking и подхалимства (Exploratory vs Confirmatory)
- Жёстко разделяй два режима:
  - Режим ОТЛАДКИ (Exploratory): при поиске бага или аномалии разрешено смотреть любые срезы, дни и сегменты.
  - Режим РЕШЕНИЯ О ЗАПУСКЕ (Confirmatory): вердикт «выкатываем / не выкатываем» строится ТОЛЬКО по главным метрикам, критериям успеха и длительности, зафиксированным ДО старта теста.
- Если пользователь просит:
  - «Найди 7-дневный период или сегмент, где тест статистически значим»,
  - «Придумай вескую причину исключить вторник, чтобы метрика стала зелёной»,
  - «Продлим тест ещё на 3 дня,там почти дотянуло до значимости»,
  ты ОБЯЗАН отказать в подгонке под результат, явно пометить такой срез как исследовательский (непригодный для решения о раскатке) и напомнить о росте ложноположительных срабатываний.

## 4. Контракт отчёта (Report Gate)
- Никогда не отдавай итоговый разбор свободным текстом. Вызывай сборщик отчёта `emit_report` со всеми обязательными секциями: [Паспорт теста, Вердикт здоровья данных, Основные метрики (с ID артефактов), Диагностика аномалий, Риски].

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

У языковых моделей есть две врождённые черты, которые разрушают доверие к аналитике: стохастичность (на один и тот же запрос модель сегодня пишет подробную таблицу, а завтра забывает упомянуть просадку ключевой метрики) и подхалимство (sycophancy) — стремление угодить пользователю. В аналитике подхалимство особенно опасно: раньше, чтобы перебрать 20 сегментов и 10 временных окон в поисках «зелёной» цифры, нужно было потратить два дня работы живого аналитика, и эта трудоёмкость служила естественным барьером. С агентом каждая новая попытка занимает 5 секунд, поэтому без жёстких тормозов любая команда быстро скатывается в самообман и ложноположительные выводы.

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

Опыт Meta показывает, что секрет надёжного агента — убрать свободу там, где нужна точность, и оставить её только в выборе маршрута. Более того, авторы доказали это на живом контрасте: когда того же самого агента подключили к внутреннему форуму вопросов и ответов, где не было жёсткого шаблонного гейта (Report gate) и обязательной привязки к артефактам кода, качество его ответов заметно просело. Надёжность создавала не «умная модель», а программная рамка вокруг неё.

Ключевые архитектурные правила из опыта эксплуатации: - Меньше документов в базе знаний — лучше ответы → удалите из RAG-базы агента старые вики-страницы и черновики; оставьте только компактный свод определений метрик, выверенный экспертами. Противоречия в документах резко роняют качество LLM. - Фиксированные CLI-утилиты вместо генерации Python на лету → для 90% типовых запросов закройте доступ к свободному написанию кода и дайте узкие команды с проверкой аргументов до запуска (меньше задержек, расхода токенов и ошибок времени исполнения), оставив Python только для редких нестандартных расследований. - Скилы доверия важнее скилов расчёта → в агенте Meta из 97 скилов только 12 отвечают за сам вывод результатов (хотя на них приходится 45% всех запросов пользователей), а 52 скила проверяют статистическую валидность, здоровье данных, честность сплитования и инциденты. Именно они делают простую выгрузку цифр достойной доверия.

Используйте этот шаблон, чтобы упаковать экспертную процедуру проверки данных в скил агента (например, файл .claude/skills/experiment-check/SKILL.md или системный регламент) с защитой от пропуска шагов и подгонки цифр:

Выполнение проверки: {цель_проверки}.
Главный принцип: модель выбирает порядок вызовов, но НИ ОДНУ цифру не считает сама.



1. Проверка готовности данных (Data Readiness):
   Вызови инструмент `{инструмент_проверки_дат}` и запроси только те периоды, по которым данные полностью загружены и не помечены флагом инцидента.
2. Проверка целостности (Health Check):
   Вызови `{инструмент_здоровья}` (проверка сплита, дублей, пропусков). Этот шаг обязателен при КАЖДОМ запросе цифр.
3. Получение расчёта:
   Передай проверенные аргументы в `{инструмент_расчёта}`. Если нужен нестандартный разрез, которого нет в аргументах CLI, используй Python-песочницу только для чтения сырых таблиц.



Запрещено помогать пользователю подгонять результат под желаемый ответ:
- Не ищи «удачные» временные окна или подгруппы для доказательства успеха после просмотра общих цифр.
- Не предлагай обоснования для удаления отдельных дней/сегментов задним числом ради достижения значимости.
- Любой дополнительный срез ngoài исходных критериев помечай плашкой: «ИССЛЕДОВАТЕЛЬСКИЙ СРЕЗ: только для диагностики, не для решения о запуске».



Сформируй отчёт строго по секциям (пропуск или пустая секция запрещены):
1. Статус готовности и здоровья данных (ссылка на артефакт проверки)
2. Основные показатели за полный период (ссылка на таблицу расчёта)
3. Обнаруженные аномалии и диагностика
4. Ограничения интерпретации

Что подставлять в плейсхолдеры: - {название_скила} — имя навыка (например, ab-results-report или funnel-anomaly-diagnosis). - {цель_проверки} — какую задачу решает процедура (утренний отчёт по тесту, поиск причины просадки конверсии). - {инструмент_проверки_дат}, {инструмент_здоровья}, {инструмент_расчёта} — названия ваших скриптов или API-вызовов.

🚀 Быстрый старт — вставь в чат:

Вот шаблон скила и регламента аналитического агента по подходу Meta ABTest Agent. Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит, какие метрики вы отслеживаете, какие типовые поломки данных у вас случаются (недоехавшие логи, дубли, боты) и где менеджеры чаще всего пытаются «подкрутить» трактовку в свою пользу — чтобы прописать конкретные проверки здоровья и стоп-правила.

⚠️ Незагруженный скил ломает поведение молча: В отличие от кривого вызова CLI-утилиты, который сразу выдаёт ошибку, селективная подгрузка скилов (когда агент сам решает, какую инструкцию подтянуть в контекст) создаёт слепую зону: если агент не подгрузил нужный скил, он просто пропустит важные правила, и система об этом даже не просигнализирует.

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

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

Команда из десяти инженеров и исследователей Meta обобщила опыт создания и промышленной эксплуатации внутреннего агента ABTest Agent, который помогает сотрудникам компании анализировать и диагностировать A/B-эксперименты. К моменту публикации агент насчитывал 97 скилов в 11 категориях и работал как в интерактивном чате, так и по автоматическому расписанию.

Анализ реальных логов использования вскрыл парадокс, разрушивший первоначальные ожидания авторов. Разработчики мечтали об «автономном учёном», который сам генерирует гипотезы и принимает решения о раскатке фич, но в реальности 45% всех запросов оказались простым получением текущих цифр теста, ещё 20% — диагностикой здоровья, а 20% (15% по метрикам + 5% концептуальных) — вопросами в духе «что именно считает эта метрика и чем она отличается от соседней». При этом, чтобы эти базовые 45% ответов не врали, команде пришлось написать 52 из 97 скилов исключительно под проверку достоверности, целостности сплитов и готовности данных.

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

🔧 Техника: Двухконтурный TDD-набор для проверки собственных скилов в Claude Code

Перенесите практику Aspirational + Regression Evals из статьи в настройку своих рабочих агентов. Прежде чем писать новый скил (например, для разбора еженедельной воронки продаж или проверки SEO-статей), сохраните в папку evals/ 3–5 реальных запросов со слепком входных данных и жёстким списком чисел/фактов, которые обязаны и которые ни в коем случае не должны появиться в ответе. Запускайте этот мини-прогон после каждой правки CLAUDE.md или текста скила — это единственный надёжный способ заметить, что новая инструкция сломала старое поведение.

• Исследование: Learnings and Pitfalls from AI-Assisted A/B Experimentation at Scale (arXiv:2611.04515v1)
• Авторы: Brett Daley, Ilya Gorbachev, Anubhav Natani, Nicholas Brown, Athena Dai, Rachel Song, Marcin Pekalski, Josip Domazet, Anchal Choubey, Daniel Ting (Meta)