Метрики и закон Гудхарта: цифра, которая меняет поведение

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

История, которая повторяется в каждой второй компании. Поддержка отвечала на обращения в среднем за одиннадцать часов, клиенты жаловались. Руководитель ввёл метрику: доля тикетов с первым ответом быстрее четырёх часов. Через квартал метрика выросла с 61 до 93 процентов. Через два квартала NPS упал, а число повторных обращений по одной и той же проблеме выросло в полтора раза. Разбор показал: агенты научились отправлять на все новые тикеты шаблон «Здравствуйте, взяли ваше обращение в работу» — это засчитывается как первый ответ. Метрика измеряла ровно то, что было написано в её определении. Она просто перестала измерять то, ради чего её ввели.

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

1. Формулировка, которую обычно цитируют неверно

Фраза «когда мера становится целью, она перестаёт быть хорошей мерой» принадлежит не Гудхарту. Её сформулировала антрополог Мэрилин Стратерн в 1997 году в статье про аудит в британских университетах, и она удобна как лозунг, но теряет суть оригинала.

Чарльз Гудхарт, экономист Банка Англии, в 1975 году писал о другом и точнее: любая наблюдаемая статистическая регулярность склонна разрушаться, как только на неё оказывают давление ради управления. Он говорил не про «плохие меры», а про то, что связь между денежным агрегатом и инфляцией существовала, пока ЦБ не начал таргетировать агрегат — а после этого исчезла. То есть разрушается не метрика. Разрушается связь между метрикой и тем, ради чего вы её взяли.

Три формулировки — про одно, но с разных сторон. Гудхарт: рушится статистическая связь. Закон Кэмпбелла: показатель развращает процесс, который измеряет. Критика Лукаса: нельзя оценивать последствия смены правил по данным, собранным при старых правилах. Последнее особенно важно аналитику: исторические данные описывают систему до того, как вы объявили цель, и потому не годятся для прогноза того, что будет после.

Это прямое продолжение сквозной темы трека — «что позволяет ваш способ сбора данных» (глава 02). До введения цели логи отражали работу поддержки. После — они отражают работу поддержки плюс реакцию поддержки на то, что её измеряют этими логами. Данные те же, генерирующий их процесс — другой.

2. Механика: метрика — это всегда прокси

Вы никогда не измеряете то, что вам нужно. Вам нужно «клиенту быстро помогли» — это конструкт, он не хранится ни в одной таблице. Вы измеряете «разница между first_reply_at и created_at меньше четырёх часов» — это операционализация, у неё есть SQL-определение и она попадает в отчёт. Между конструктом и метрикой всегда есть зазор, и вопрос только в том, насколько дорого этот зазор эксплуатировать.

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

Про то, почему система в целом ведёт себя так, а не иначе, — соседний трек: Локальная оптимизация и Петли обратной связи. Метрика с премией — это усиливающая петля, замкнутая на измеряемый объект.

На картинке важна левая часть, а не правая. Слева связь была настоящей: пока никто не смотрел на цифру, быстрый первый ответ действительно означал, что клиенту помогли. Именно потому метрику и выбрали — она хорошо коррелировала с конструктом на исторических данных. Гудхарт не про то, что вы выбрали плохую метрику. Он про то, что корреляция, на основании которой вы её выбрали, была получена в режиме, где на метрику не давили.

3. Четыре разных Гудхарта

Мангейм и Гаррабрант в статье Categorizing Variants of Goodhart’s Law (arXiv:1803.04585) разложили явление на четыре механизма. Разделение не академическое: у каждого своя причина и своё лечение.

3.1 Регрессионный: отбор по прокси отбирает шум

Самый недооценённый вариант, и он работает даже без злого умысла и без изменения поведения. Пусть $G$ — истинная величина, которая вам нужна, $M$ — измеряемый прокси, и они связаны просто:

$$M = G + \varepsilon$$

где $\varepsilon$ — независимый от $G$ шум измерения. Считаем обе величины нормальными с нулевым средним. Тогда условное ожидание истинной величины при наблюдённом прокси:

$$\mathbb{E}\lbrack G \mid M = m \rbrack = \frac{\sigma_G^2}{\sigma_G^2 + \sigma_\varepsilon^2} \cdot m$$

Коэффициент перед $m$ строго меньше единицы. Это значит: кто оказался наверху по метрике, тот в среднем ниже по настоящей величине — часть его результата была шумом. Классическая регрессия к среднему, но с практическим следствием: чем шумнее метрика, тем сильнее отбор по ней отбирает удачу вместо качества.

Корреляция прокси с целью:

$$\rho = \frac{\sigma_G}{\sqrt{\sigma_G^2 + \sigma_\varepsilon^2}}$$

Числовой пример. Пусть шум по величине равен настоящему разбросу: $\sigma_G = \sigma_\varepsilon$. Тогда $\rho \approx 0{,}71$, а коэффициент сжатия равен $0{,}5$. Отбираем верхний 1 процент по метрике. Средняя метрика у отобранных — $2{,}67$ стандартных отклонения метрики, то есть $3{,}77$ в единицах $\sigma_G$. А средняя настоящая величина у них — всего $1{,}88\,\sigma_G$. Если бы мы умели отбирать напрямую по $G$, получили бы $2{,}67\,\sigma_G$. Отношение — ровно $\rho$.

Это красивый и полезный результат: в гауссовой модели отбор по прокси даёт долю $\rho$ от того, что дал бы отбор по настоящей цели. Метрика с корреляцией 0,7 к конструкту — это не «на 70 процентов хорошо», это буквально 70 процентов достижимого при любом пороге отсечения. Отсюда практика: прежде чем ранжировать команды, сотрудников или эксперименты по метрике, оцените её шум. Метрика недельной велосити на команде из пяти человек шумна настолько, что ранжирование по ней — почти лотерея.

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

3.2 Экстремальный: в хвосте связь другая

Регулярность, наблюдённая в обычном диапазоне, не обязана сохраняться на краю. Время ответа и удовлетворённость связаны при значениях от часа до суток; при попытке довести время ответа до минуты вы получаете бота, отвечающего мгновенно и бесполезно — связь в этой точке не просто ослабла, она сменила знак. Это ровно тот случай, когда экстраполяция за пределы наблюдённых данных незаконна (глава 06 про хвосты, глава 10 про границы вывода).

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

3.3 Причинный: вы надавили не на ту стрелку

Метрика коррелирует с конструктом, но не является его причиной — оба следствия чего-то третьего. Тогда вмешательство в метрику не двигает конструкт вообще. Классика: в компаниях, где хорошо работает разработка, обычно много релизов; отсюда вывод «давайте релизить чаще» и дробление одного релиза на пять. Число релизов выросло, качество разработки — нет, потому что стрелка причинности шла в обратную сторону.

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

3.4 Состязательный: кому-то выгодно

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

4. Каталог накруток, которые вы увидите в IT

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

Исторические примеры того же механизма за пределами IT стоит знать, потому что в них цена ошибки была выше. Целевое время ожидания в четыре часа в приёмных покоях британской NHS привело к тому, что пациентов держали в машинах скорой до момента, когда счётчик можно было запустить с запасом. В США закон No Child Left Behind привязал финансирование школ к результатам тестов, что закончилось скандалом с массовым исправлением ответов учителями в Атланте. В Wells Fargo цель по числу продуктов на клиента («восемь — это отлично») закончилась примерно 3,5 миллионами счетов, открытых без ведома клиентов, и штрафом регулятора в 185 миллионов USD в 2016 году. Во всех трёх случаях метрика была разумной, цель — достигнутой, а результат — противоположным замыслу.

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

5. Метрика ломает данные, из которых считается

Аналитику это касается напрямую, даже если он не принимает решений о целях.

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

Распределение деформируется в предсказуемом месте. Порог порождает кучкование — пик прямо перед границей и провал сразу за ней. В экономике на этом построен целый метод оценки (bunching estimator у Саеза и Клевена), и он прекрасно работает как детектор накрутки в продуктовых данных.

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

Запрос-детектор. Обычный GROUP BY по корзинам, но именно он показывает то, чего не видно в средних:

-- Гистограмма времени первого ответа корзинами по 20 минут.
-- width_bucket(value, low, high, count): корзина i покрывает [low + (i-1)*w, low + i*w),
-- где w = (high - low) / count. Здесь w = 480 / 24 = 20 минут.
-- Значения >= 480 попадут в корзину 25 (переполнение) — это нормально, но её надо видеть.
SELECT
    width_bucket(
        extract(epoch FROM t.first_reply_at - t.created_at) / 60.0,
        0, 480, 24
    )                                                        AS bucket_20min,
    count(*)                                                 AS tickets,
    min(t.first_reply_at - t.created_at)                     AS min_time,
    max(t.first_reply_at - t.created_at)                     AS max_time
FROM support.tickets AS t
WHERE t.first_reply_at IS NOT NULL
  AND t.created_at >= date '2026-01-01'
GROUP BY 1
ORDER BY 1;

Корзина 12 покрывает интервал 220–240 минут — ровно перед порогом в четыре часа. Если в ней вдвое больше тикетов, чем в соседних, а в корзине 13 провал, обсуждать среднее время ответа больше не нужно: у вас на руках прямое свидетельство того, что процессом управляет счётчик, а не клиент.

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

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

Не «можно ли эту метрику накрутить» — накрутить можно любую. Правильный вопрос:

Какой способ поднять эту метрику самый дешёвый, и устраивает ли он нас?

Если самый дешёвый способ поднять «долю тикетов без повторного обращения в течение 14 дней» — это действительно решать проблему клиента с первого раза, метрика спроектирована хорошо. Гудхарт никуда не делся, просто оптимизация под метрику совпала с тем, чего вы хотите. Это и есть цель дизайна, а не «неуязвимая метрика», которой не бывает.

Отсюда конкретная практика — red team метрики. Прежде чем вносить цифру в OKR, соберите на полчаса людей, которые будут по ней работать, и задайте один вопрос: «как поднять это на 20 процентов за две недели, ничего по существу не улучшив». Список из пяти-шести способов появляется всегда. Дальше по каждому: во что это обойдётся тому, кто так сделает; заметим ли мы; какая метрика при этом сломается. То, что вы не готовы допустить, отправляется в защитные метрики и в детекторы.

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

7. Парная защитная метрика

Единственный приём, который работает почти всегда: у целевой метрики должна быть парная защитная, которая ломается при попытке накрутить основную. Идея старая — Энди Гроув в «High Output Management» описывал её как pairing indicators, — но в продуктовой практике она до сих пор применяется реже, чем нужно.

Два правила, без которых пара не работает.

Защитная метрика асимметрична. Целевую вы двигаете вверх и требуете доказательства, что рост настоящий. Защитную вы не улучшаете — вы следите, чтобы она не ухудшилась. Поэтому в эксперименте она проверяется односторонним тестом и без поправки на множественность в консервативную сторону: guardrail должен срабатывать легко, а не требовать значимости на уровне открытия (глава 09). Пропустить настоящую поломку здесь дороже, чем лишний раз остановить раскатку.

Считать нужно комбинированный результат, а не две цифры по отдельности. Пример. Базовая конверсия в оплаченный заказ — 4,0 процента, доля возвратов — 6 процентов. Чистая доля покупок, оставшихся у клиента:

$$4{,}0 \cdot (1 - 0{,}06) = 3{,}76\ \text{процента}$$

В тесте конверсия выросла до 4,4 процента (плюс 10 процентов относительно), но доля возвратов поднялась с 6 до 16 процентов:

$$4{,}4 \cdot (1 - 0{,}16) = 3{,}696\ \text{процента}$$

Итог — минус 1,7 процента относительно базы. В отчёте «конверсия +10 процентов, p = 0,004» это выглядит победой; в отчёте по чистой метрике — проигрышем. Именно поэтому комбинированная метрика должна быть посчитана заранее и лежать на том же экране, что и целевая. Про экономику этого расчёта — Юнит-экономика.

Запрос, который считает целевую и защитную вместе:

-- Целевая и защитные метрики поддержки в одном разрезе: неделя x команда.
WITH t AS (
    SELECT
        tk.ticket_id,
        tk.team_id,
        date_trunc('week', tk.created_at) AS week,
        tk.created_at,
        tk.first_reply_at,
        tk.closed_at
    FROM support.tickets AS tk
    WHERE tk.created_at >= date '2026-01-01'
      AND tk.created_at <  date '2026-07-01'
),
reopened AS (
    SELECT ticket_id, count(*) AS reopen_count
    FROM support.ticket_status_changes
    WHERE old_status = 'closed' AND new_status = 'open'
    GROUP BY ticket_id
)
SELECT
    t.week,
    t.team_id,
    count(*) AS tickets,

    -- ЦЕЛЕВАЯ: доля тикетов с первым ответом быстрее 4 часов.
    -- Условие IS NOT NULL внутри выражения, а не в WHERE: тикет без ответа — это
    -- нарушение SLA, а не отсутствие данных. Если убрать его в WHERE, знаменатель
    -- тихо уменьшится ровно на самые плохие случаи, и метрика вырастет сама собой.
    round(avg((t.first_reply_at IS NOT NULL
               AND t.first_reply_at - t.created_at <= interval '4 hours')::int), 3)
        AS sla_hit_rate,

    -- ЗАЩИТНАЯ 1: доля тикетов, которые пришлось открывать заново.
    -- coalesce обязателен: без него NULL > 0 даёт NULL, avg пропускает NULL,
    -- и в знаменателе остаются только переоткрытые тикеты — метрика станет единицей.
    round(avg((coalesce(r.reopen_count, 0) > 0)::int), 3) AS reopen_rate,

    -- ЗАЩИТНАЯ 2: медиана времени до фактического закрытия, в часах.
    -- percentile_cont игнорирует NULL, поэтому незакрытые тикеты в неё не попадают —
    -- отдельно смотрим их долю.
    round(percentile_cont(0.5) WITHIN GROUP (
              ORDER BY extract(epoch FROM t.closed_at - t.created_at) / 3600.0
          )::numeric, 1) AS median_resolution_hours,
    round(avg((t.closed_at IS NULL)::int), 3) AS still_open_rate

FROM t
LEFT JOIN reopened AS r USING (ticket_id)
GROUP BY t.week, t.team_id
ORDER BY t.week, t.team_id;

Два комментария в запросе — это не педантизм. Обе ошибки (WHERE вместо условия внутри агрегата и забытый coalesce) дают метрику, которая улучшается от ухудшения реальности, и обе встречаются в проде регулярно. Подробнее об этом классе ошибок — глава 04.

8. Детекторы: писать заранее, а не после скандала

Правило: если вы придумали способ накрутки на red team, вы обязаны написать запрос, который его ловит, в тот же день. Детектор, написанный после того, как накрутка обнаружилась, уже бесполезен — он подтверждает то, что и так известно.

Пример детектора для «закрыл тикет, а клиент завёл новый»:

-- Маскированные закрытия: тикет закрыт, и в течение 24 часов тот же клиент
-- завёл новое обращение той же категории. Формально SLA соблюдён, фактически нет.
SELECT
    date_trunc('week', t.closed_at) AS week,
    t.team_id,
    count(*)                                              AS closures,
    count(*) FILTER (WHERE nxt.ticket_id IS NOT NULL)     AS masked_closures,
    round(100.0 * count(*) FILTER (WHERE nxt.ticket_id IS NOT NULL)
          / count(*), 1)                                  AS masked_pct
FROM support.tickets AS t
LEFT JOIN LATERAL (
    -- LATERAL + LIMIT 1: берём максимум одно последующее обращение,
    -- иначе JOIN размножит строки и доля «замаскированных» уедет вверх.
    SELECT n.ticket_id
    FROM support.tickets AS n
    WHERE n.customer_id = t.customer_id
      AND n.category    = t.category
      AND n.created_at  >  t.closed_at
      AND n.created_at  <= t.closed_at + interval '24 hours'
    ORDER BY n.created_at
    LIMIT 1
) AS nxt ON true
WHERE t.closed_at IS NOT NULL
  AND t.closed_at >= date '2026-01-01'
GROUP BY 1, 2
ORDER BY 1, 2;

Пример для эксперимента, где целевая метрика — конверсия, а защитная — возвраты:

-- Конверсия, возвраты и «чистая» конверсия по вариантам эксперимента.
WITH assigned AS (
    SELECT a.user_id, a.variant, a.assigned_at
    FROM ab.assignment AS a
    WHERE a.experiment_id = 'checkout_2026_03'
),
orders AS (
    SELECT
        a.user_id,
        o.order_id,
        -- EXISTS вместо LEFT JOIN на refunds: если у заказа два частичных возврата,
        -- JOIN удвоит строку и доля возвратов окажется завышенной.
        EXISTS (
            SELECT 1 FROM shop.refunds AS r WHERE r.order_id = o.order_id
        ) AS refunded
    FROM assigned AS a
    JOIN shop.orders AS o
      ON o.user_id = a.user_id
     AND o.created_at >= a.assigned_at   -- заказы ДО попадания в эксперимент не считаем
)
SELECT
    a.variant,
    count(DISTINCT a.user_id)                                    AS users,
    count(DISTINCT o.user_id)                                    AS buyers,
    round(100.0 * count(DISTINCT o.user_id)
          / count(DISTINCT a.user_id), 2)                        AS conversion_pct,
    round(100.0 * count(o.order_id) FILTER (WHERE o.refunded)
          / nullif(count(o.order_id), 0), 2)                     AS refund_pct,
    -- комбинированная метрика: покупатели, у которых остался хотя бы один невозвращённый заказ
    round(100.0 * count(DISTINCT o.user_id) FILTER (WHERE NOT o.refunded)
          / count(DISTINCT a.user_id), 2)                        AS net_conversion_pct
FROM assigned AS a
LEFT JOIN orders AS o ON o.user_id = a.user_id
GROUP BY a.variant
ORDER BY a.variant;

Обратите внимание на o.created_at >= a.assigned_at: без этого условия в конверсию попадут покупки, сделанные до попадания в эксперимент, и разница между вариантами размоется. Это та же дисциплина знаменателя, о которой шла речь в главе 04 и главе 09.

9. Реестр определений: метрика без версии — не метрика

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

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

-- Что требует внимания: действующие метрики без защитной пары
-- или с просроченным пересмотром определения.
SELECT
    md.metric_key,
    md.version,
    md.construct,
    md.guardrail_key,
    md.review_by,
    current_date - md.review_by AS days_overdue
FROM analytics.metric_definition AS md
WHERE md.valid_to IS NULL                       -- только действующие версии
  AND (md.guardrail_key IS NULL OR md.review_by < current_date)
ORDER BY (md.guardrail_key IS NULL) DESC, days_overdue DESC;

Версионирование определений — часть управления данными, разбор в соседнем треке: Качество данных и governance. Связь реестра с дашбордами — глава 13: дашборд без владельца решения и порога уже был назван там ритуалом, а метрика без них — тем более.

10. Жизненный цикл метрики

У метрики есть срок годности, и его лучше признать заранее, чем обнаружить постфактум.

Важен переход L → S. Он не случается сам: это результат того, что метрику спроектировали так, что дешёвый путь совпал с нужным. И важен переход G → D — самый частый в реальности. Метрика накручена, никто этого не заметил, цифра продолжает докладываться наверх, решения принимаются по ней. Именно здесь работа аналитика: из всех состояний вы отвечаете за то, чтобы система не сидела в D годами.

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

11. Где Гудхарт слабее и почему

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

Метрика как ограничение, а не как максимизируемая величина. Это про SLO. Цель не «поднять доступность как можно выше», а «не выйти за бюджет ошибок». Как только цель — порог, который не надо превышать, исчезает смысл оптимизировать метрику бесконечно, и высвобожденный бюджет тратится на скорость поставки. Разбор — SLI и SLO и Бюджет ошибок. Обратная сторона: пороги порождают кучкование (раздел 5), поэтому распределение возле границы всё равно нужно смотреть.

Семейство метрик вместо одной. DORA-метрики устроены как две пары: две про скорость (частота развёртываний, время от коммита до прода) и две про устойчивость (доля неудачных изменений, время восстановления). Улучшать одну пару за счёт другой бессмысленно — показатель просто перекладывается. То же в HEART (Google, статья Родден и соавторов на CHI 2010) и в SPACE, где сознательно собраны разнородные измерения, чтобы ни одно не читалось в одиночку. См. также Метрики интерфейса и Продуктовые метрики.

Входные метрики вместо выходных. Подход, описанный в «Working Backwards» про Amazon: команда отвечает за то, на что напрямую влияет (число товаров в каталоге, скорость страницы), а выручка остаётся результатом, который наблюдают, но не назначают целью конкретной команде. Работает, если причинная связь входных метрик с выходной проверена — иначе получается причинный Гудхарт из раздела 3.3.

Разделение измерения и вознаграждения. Самая сильная и самая непопулярная мера. Закон Кэмпбелла говорит именно о давлении: показатель искажается тем сильнее, чем больше на нём висит. Метрика, по которой не платят премию и не увольняют, деградирует значительно медленнее. Деминг в четырнадцати пунктах требовал прямо: устранить количественные нормы для рабочих и числовые цели для менеджмента. Практический компромисс, который обычно достижим: метрики команд — да, метрики отдельных людей — нет. См. Оценка и рост и Планирование и оценки.

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

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

12. Гудхарт в ML и в LLM-системах

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

Обучение с подкреплением дало явлению отдельное имя — reward hacking, или specification gaming. Каноническая иллюстрация: агент в гоночной игре обнаружил, что кружиться на месте, собирая бонусы, даёт больше очков, чем финишировать. Систематизация проблемы — Concrete Problems in AI Safety (Amodei и соавторы, 2016); коллекция реальных случаев — список Виктории Краковны.

Для прикладного инженера практическая часть такая:

• Офлайн-метрика — прокси для продуктовой. Рост AUC или nDCG на отложенной выборке не обязан означать рост удержания; связь надо проверять экспериментом (глава 09). Разбор офлайн-метрик — Оценка моделей.
• Бенчмарк, ставший целью, перестаёт различать модели. Как только на публичный лидерборд начинают целиться, разница между моделями на нём говорит о подгонке под бенчмарк не меньше, чем о качестве — включая утечку тестовых данных в обучение. См. Оценка и бенчмарки.
• Рекомендательная система, оптимизирующая кликабельность, оптимизирует кликабельность. Это ровно та ситуация, где нужна защитная метрика: доля досмотров, доля жалоб, разнообразие выдачи, удержание на горизонте месяца.
• LLM-судья — тоже метрика с зазором. Если вы правите промпт до тех пор, пока оценка судьи не вырастет, вы оптимизируете под судью, а не под пользу. Нужна отложенная выборка, которую вы не видели во время итераций, — та же логика, что и с множественными сравнениями в главе 08.

13. Чек-лист перед тем, как назначить цифру целью

1. Какой конструкт мы на самом деле хотим двигать? Записан ли он текстом рядом с формулой?
2. Метрика — рычаг или индикатор? Есть ли основания считать её причиной, а не следствием?
3. Как её поднять на 20 процентов за две недели, ничего не улучшив? (Список из пяти пунктов.)
4. Какой из этих способов самый дешёвый и устраивает ли он нас?
5. Какая парная защитная метрика ломается при каждом из способов?
6. Посчитана ли комбинированная метрика, где целевая и защитная сведены в одно число?
7. Написан ли SQL-детектор для каждого способа накрутки — сегодня, а не потом?
8. Насколько метрика шумная? Выдержит ли она ранжирование или только сравнение с интервалом?
9. Лежит ли цель внутри исторического диапазона метрики или мы экстраполируем?
10. Кто владелец решения и какое действие произойдёт при пересечении порога?
11. Привязана ли метрика к деньгам конкретных людей? Можно ли эту привязку убрать?
12. Когда мы её пересмотрим, и записана ли эта дата в реестре?

14. Типичные ошибки

• Считать Гудхарта проблемой мотивации. «Наши люди так не сделают» — не аргумент; оптимизация под метрику происходит и без умысла, начиная с регрессионного варианта.
• Одна метрика на всё. North Star без сопровождающего семейства становится мишенью быстрее любой другой цифры.
• Защитная метрика есть, но её никто не смотрит. Guardrail без правила остановки и без места на том же экране — украшение.
• Требовать от защитной метрики значимости. Асимметрия: целевая доказывает рост, защитная должна легко срабатывать на ухудшение.
• Ранжировать людей и команды по шумной метрике. Отбор по прокси с корреляцией 0,5 даёт половину достижимого и много обиженных.
• Сравнивать «до цели» и «после цели» как эффект улучшения. Это структурный разрыв, а не эффект (глава 10).
• Смотреть только на агрегат. Кучкование у порога видно на гистограмме и невидимо в среднем.
• Не версионировать определение. Через полгода никто не помнит, почему в марте случился скачок, и спор идёт о цифрах вместо решений.
• Ставить цель за пределами наблюдённого диапазона. «Хотим 99 при истории 60–70» — почти гарантированный экстремальный Гудхарт.
• Оставлять ввод значения метрики в руках того, кого она оценивает. Контур замкнут, дальше вопрос только времени.

Источники

• Charles Goodhart. Problems of Monetary Management: The U.K. Experience (1975) — оригинальная формулировка; краткий обзор истории цитаты в статье Википедии.
• Donald T. Campbell. Assessing the Impact of Planned Social Change (1976) — закон Кэмпбелла.
• Marilyn Strathern. «Improving ratings»: audit in the British University system, European Review, 1997 — источник самой цитируемой формулировки.
• David Manheim, Scott Garrabrant. Categorizing Variants of Goodhart’s Law, arXiv:1803.04585, 2018 — четыре механизма, разобранные в разделе 3.
• Jerry Z. Muller. The Tyranny of Metrics, Princeton University Press, 2018 — каталог провалов управления по метрикам в медицине, образовании, полиции, армии.
• Andrew Grove. High Output Management — парные показатели как рабочая практика.
• Colin Bryar, Bill Carr. Working Backwards — входные и выходные метрики.
• Nicole Forsgren, Jez Humble, Gene Kim. Accelerate и dora.dev — четыре метрики как сбалансированный набор.
• Nicole Forsgren и соавторы. The SPACE of Developer Productivity, ACM Queue, 2021 — почему одну метрику продуктивности брать нельзя.
• Kerry Rodden, Hilary Hutchinson, Xin Fu. Measuring the User Experience on a Large Scale (CHI 2010) — фреймворк HEART.
• Betsey Stevenson, Justin Wolfers и обзор Bunching Хенрика Клевена, Annual Review of Economics, 2016 — метод оценки кучкования у порогов.
• Steven Levitt, John List. Was There Really a Hawthorne Effect at the Hawthorne Plant?, AEJ: Applied Economics, 2011 — переанализ, из-за которого эффект стоит цитировать осторожно.
• Dario Amodei и соавторы. Concrete Problems in AI Safety, 2016; Victoria Krakovna, Specification gaming examples in AI.
• Betsy Beyer и соавторы. Site Reliability Engineering — SLO как ограничение, а не как максимизируемая цель.
• Документация PostgreSQL: width_bucket и математические функции, агрегаты и FILTER, LATERAL.

Мини-итог

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

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

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

Что дальше

Трек закончен. Дальше — то, к чему он примыкает:

• Системное мышление — механика того, почему метрика меняет систему: обратные связи, задержки, локальная оптимизация, точки воздействия. Прямое продолжение этой главы.
• Управление продуктом и Аналитика и решения — как метрики живут в продуктовом контуре и как из них получаются приоритеты.
• Инженерия данных и Базы данных — если узким местом стали не выводы, а витрины и скорость запросов.
• Машинное обучение — когда описательного и причинного ответа мало и нужен прогноз.
• Вероятность и статистика — аппарат под всем, что было в главах 05–10.
• Системный анализ — работа с заказчиком, из которой берётся настоящий вопрос.

Куда двигаться дальше по порталу целиком — Карта треков и маршруты.