Работая над статьёй ИИ не изменит IT, я обратила внимание, что ключ ко многим проблемам нейросетей — это закон Гудхарта: «Когда мера становится целью, она перестаёт быть хорошей мерой». Закон этот настолько универсальный, что захотелось посвятить ему отдельную статью.
Он объясняет, почему ChatGPT галлюцинирует, когда его поощряют за правдоподобность, школьники учатся списывать ради хороших оценок, а поисковики постоянно обновляют алгоритм ранжирования.
«Сделал и забыл» — это не про сайты, не про SEO и не про цифровой маркетинг. В этой статье разберёмся, почему это не чья-то злая воля, а системная закономерность. И как, понимая её, выстраивать устойчивые процессы.
Почему любые показатели со временем начинают врать
Экономист Чарльз Гудхарт сформулировал свой закон в виде полушуточного отступления, наподобие законов Мёрфи, но в каждой шутке есть доля шутки, и есть немало связанных концепций. Так, социолог Дональд Кэмпбелл ещё в 1969 году отмечал, что
введение индикаторов, по которым оценивается работа того или иного института, неизбежно приводит к искажению как самих индикаторов, так и социальных процессов, которые они призваны измерять.
Закон Кэмпбелла показывает, что проблема выходит далеко за рамки экономики. Она укоренена в самой природе систем управления и оценки. Когда политика направлена на рост показателя, люди находят способы его увеличить, не помогающие достичь исходной цели.
Чарльз Гудхарт сформулировал это иначе, для экономической и политической модели:
Любая наблюдаемая статистическая закономерность будет иметь тенденцию к нарушению, как только на неё будет оказано давление в целях контроля.
Больше объяснения даёт формулировка «Агентской проблемы»:
Тот, кто ставит цель (принципал — начальник, правительство), имеет неполное представление о реальном процессе (карта не равна территории). Тот, кто выполняет задачи (агент — сотрудник, подрядчик), обладает всей полнотой информации, но его личные интересы (премия, избегание наказания) могут не совпадать с интересами принципала.
Здесь и появляется ловушка Гудхарта: агент понимает, по каким конкретным параметрам его будут оценивать. Его рациональное решение — максимизировать эти параметры, даже в ущерб реальной цели принципала. К примеру, учитель готов «натаскивать на тест», а не учить мыслить, потому что от результатов теста зависит его репутация и зарплата. А ученик готов списывать ради хорошей оценки, которая обеспечивает его безопасность и поощрение.
Как метрики искажают IT-процессы
Из-за того, что внимание направлено на абстрактные метрики, истинные цели могут остаться в тени. Яркий пример — у разработчиков есть метрика «code coverage» (покрытие кода тестами). Мы стремимся повысить этот показатель, но на самом деле наша цель — это качественный и надёжный продукт. На практике же погоня за высоким процентом покрытия часто приводит к созданию бессмысленных тестов, которые не проверяют ничего полезного, а лишь «накручивают» цифру. Эта метрика не позволяет оценить, насколько реализация проекта соответствует техническому заданию. Направление внимания на достижение высокого показателя по code coverage отвлекает от удовлетворения реальных потребностей пользователей.
Аналогично KPI тестировщиков часто измеряют по количеству найденных багов. Кажется, что чем больше багов ты нашёл, тем лучше работаешь. Чем больше заведено задач в трекере, тем выше шанс на премию. Но такой процесс мотивации может привести к тому, что тестировщик начинает создавать баги-пустышки, дубликаты или дробить одну сложную проблему на множество мелких. Например, если поле ввода номера телефона валидируется сложным набором правил, можно описать все найденные проблемы одной задачей, а можно — десятком отдельных. Второй способ искусственно увеличивает метрику, но не несёт реальной пользы. Часто такие мелкие правки приводят к тому, что при исправлении одного бага появляется другой, и наоборот. Только собрав все требования в одной модели, можно верно реализовать функционал, но это уронит KPI тестировщика.
Когда эффективность сотрудников измеряют как производительность, случаются и другие забавные казусы. Например, перед стартом работы по проекту, мы имеем 0 строчек кода, а когда проект закончен — в нём не менее N строк. Поэтому процесс разработки в упрощённой модели представляется как рост кода. Вы уже понимаете, к чему я веду? Конечно, этот KPI породил всем известный «индусский» код, когда вместо использования циклов с итераторами, использовались локальные переменные с последовательным присваиванием значений: i = 0; i = 1; i = 2… Естественно, тело цикла тоже не выносилось в отдельную функцию, ведь это могло уменьшить объём кода!
Конечно, при введении новых метрик нужен критический подход всех участников. Позвольте рассказать вам об одном забавном случае.
История эта произошла в 1982 году в команде разработки компьютера Lisa, предшественника Macintosh. Руководители, которых сейчас бы назвали «эффективными менеджерами» придумали измерять вклад каждого инженера строками кода. Они разработали форму регулярного отчёта, одно из полей которой нужно было заполнить числом: сколько строк кода было написано за прошедшую неделю.
Билл Аткинсон, один из создателей ключевых компонентов системы, полагал, что истинная цель — не объём кода, а его изящество и скорость. Метрика же поощряла раздутые и небрежные программы.
В тот период он работал над оптимизацией механизма расчёта регионов для графического интерфейса. И когда он реализовал улучшенный алгоритм, скорость работы с регионами возросла в 6 раз, а код уменьшился на 2000 строк. Когда Билл закончил эту оптимизацию, пришло время заполнять форму для отчёта. Дойдя до части «Строки кода», он на секунду задумался, а затем ввёл число: -2000. Говорят, через пару недель руководители перестали просить Билла заполнять форму, и он с радостью подчинился.
Когда агент не подстраивается под систему, а показывает, что у каждой модели есть границы применения, то адаптироваться приходиться принципалу. Хотя в большинстве случаев менеджмент не может совсем отказаться от метрик. Ведь оценка эффективности управления без них невозможна! Но каждый раз, когда мы строим управление для роста целевых показателей, люди учатся обходить систему, порой даже не осознанно. К примеру, можно увидеть закон Гудхарта в таком явлении как инфляция сторипоинтов.
И сторипоинты, и велосити — это метрики, которые вычисляются на основе статистики работы команды в предыдущий период. В сторипоинтах оценивается сложность задач, а velocity — это скорость, с которой команда решает задачи (измеряется в сторипоинт/спринт). Сложность задач оценивается интуитивно, используя усреднённый опыт команды. Велосити — статистический показатель. Такие оценки могут использоваться для прогнозов на длительный период, или, точнее, на период, соотносимый с периодом сбора статистики, по которому строится оценка. Но стоит начать использовать эту меру как цель — например, стремиться к повышению велосити, или считать, что все запланированные на спринт задачи должны быть выполнены — как мера перестаёт работать.
Если человек вынужден работать сверхурочно, чтобы закрыть все запланированные таски, то на планировании он подстрахуется и повысит оценку. Однако есть и обратная тенденция: человек редко делает задачу быстрее, чем по оценке, поэтому всегда есть вероятность, что задача не будет выполнена в срок. В итоге команда плавно увеличивает оценку сложности. И задача, которая раньше стоила 3 сторипоинта, оценивается уже в 5 сторипоинтов. Это и называется инфляция сторипоинтов, они дешевеют, и одновременно растёт скорость разработки.
При этом реальная продуктивность команды может даже снижаться. Проблема усугубляется, если команда работает короткими спринтами — тогда объёмные архитектурные задачи вообще перестают «влезать» в спринт и не берутся в работу. Изначальная цель — разработка качественного продукта и возможность чёткого планирования доставки новых фич подменяется ростом абстрактной скорости разработки.
Бесконечный цикл поисковой оптимизации
Сфера SEO — это наглядная иллюстрация закона Гудхарта в действии. Вся её механика построена на бесконечном цикле, где такая метрика, как ранг сайта, становясь целью, теряет свою эффективность.
Как устроена гонка:
Поисковик вводит метрику. Google и другие системы ранжируют сайты с помощью сложного алгоритма — по сути, функции, которая вычисляет релевантность сайта для конкретного запроса.
SEO-специалисты максимизируют метрику. Узнав (или предположив) параметры этой функции, оптимизаторы начинают изменять сайты, чтобы максимизировать её значение и вывести их в топ выдачи.
Срабатывает закон Гудхарта. Когда сайты оптимизированы для поисковиков, они становятся бесполезны для человека. Насыщенные ключевыми словами, нечитабельные, не отвечающие на реальный запрос пользователя страницы засоряют выдачу. Одновременно с этим растёт показатель отказов — пользователи не задерживаются на таких сайтах.
Поисковик меняет правила. Если оптимальные по метрике сайты не соответствуют цели — значит мера испортилась. И поисковая система обновляет свой алгоритм ранжирования. Она добавляет новые критерии, чтобы понизить оценку мусорным сайтам и продвинуть те, что действительно решают проблемы пользователей.
Цикл начинается заново. Специалисты по SEO изучают новые требования поисковых систем и снова начинают оптимизировать сайты под обновлённую функцию ранжирования.
Кажется, что этот цикл превращает работу по оптимизации сайта в пустую трату времени, да и про пользователя легко забыть.
Как преодолевается ловушка Гудхарта
В упрощённой модели, где есть только сайт, SEO и ранжирование результатов выдачи, мы автоматически попадаем в бесконечную ловушку Гудхарта. Но в реальности веб-приложения создаются для диалога между компанией и клиентом, и поэтому у разработчиков и СЕО-специалистов всегда есть более важная цель — оптимизация для конечного пользователя. Повышение метрики ранжирования нужно для роста органического трафика, но клиенты могут прийти и по сарафанке, и повторно. И для них важно, что сайт помогает в решении проблемы. Поэтому для долгосрочного выгодного сотрудничества компания вкладывается в развитие веб-приложения не только для улучшения позиции в поисковой выдаче. В этом и кроется секрет победы над законом Гудхарта.
Работа грамотного SEO-специалиста — это не слепая оптимизация под метрику поисковой системы, а сбалансированный подход:
С одной стороны, понимание и использование алгоритмов для повышения видимости.
С другой, оптимизация под реального человека: создание понятного, полезного и доступного ресурса, который помогает компании достичь своих бизнес-целей через удовлетворение потребностей клиента.
Закон Гудхарта заставляет поисковую систему менять меру, чтобы лучшим в поиске оказывался не просто «оптимизированный» сайт, а по-настоящему хороший. Но для SEO-специалистов успех возможен только при сбалансированном достижении разнородных целей. И чтобы этот баланс был достижим в управляемом процессе, используется набор из разных метрик. Важно, что эти меры не связаны линейно, чрезмерная максимизация одной приводит к падению другой. Самые важные метрики можно собрать в такие независимые группы:
Позиция в выдаче, охваты, доля кликов.
Индексируемость и скорость загрузки.
Обратные ссылки, упоминания и цитирование.
Конверсия и стоимость привлечения клиента.
Успех в SEO достигается не тогда, когда сайт идеально подогнан под текущий алгоритм поисковика, а когда он стабильно привлекает и удерживает целевую аудиторию. Поэтому система сбалансированных показателей — не просто список для отслеживания, а инструмент для принятия управленческих решений. Она позволяет разорвать цикл реактивной оптимизации и выстроить проактивную стратегию, где улучшение технических параметров, рост авторитетности и работа над пользовательским опытом идут параллельно, усиливая друг друга.
Эта стратегия — использование сбалансированной системы разнородных метрик для противодействия закону Гудхарта — довольно универсальна. Давайте посмотрим, какие «балансировочные» метрики можно использовать в других ситуациях, где проявляется закона Гудхарта.
Метрики-мишени и метрики-балансиры
Ловушку закона Гудхарта невозможно обойти, меняя одну «плохую» метрику на другую. Надёжная стратегия — это наблюдение за набором парамеров, и сбалансированный рост нескольких разнонаправленных показателей. Такая система заставляет оптимизировать процесс в целом, не позволяя жертвовать качеством ради формальных цифр.
В простейшем случае такая система состоит из двух типов метрик. На примере SEO это может выглядеть так:
Основная метрика («Гудхарт-мишень»): Показатель, который мы хотим улучшить, но который неизбежно деградирует, если станет единственной целью (например, позиция в выдаче).
Балансировочная метрика: Показатель, который контролирует качество и конечную ценность нашей работы (например, глубина просмотра сайта или конверсия).
Работая над улучшением первой, мы обязаны отслеживать влияние наших действий на вторую. Если балансировочная метрика ухудшается — это сигнал, что мы попали в ловушку Гудхарта и наши изменения ведут к негативным последствиям. Такой подход заставляет не просто «накручивать» цифру, а искать решения, которые улучшают обе метрики одновременно.
Рассмотрим другие примеры.
Code Coverage
Гудхарт-мишень: Покрытие кода тестами.
Балансировочная метрика: Количество дефектов, дошедших до продакшена (собранное через баг-трекер, краш-репорты или отзывы пользователей, обращения в техподдержку).
Как это работает: Высокий процент покрытия тестами теряет всякий смысл, если количество багов в рабочей версии продукта не уменьшается. Эта связка метрик заставляет команду сосредоточиться не на написании любых тестов ради процента, а на создании содержательных тестов, которые реально отлавливают критические сценарии ошибок. Если code coverage растёт, но не защищает от багов — значит, проблема не в тестах, а в их качестве или в процессе разработки в целом.
Инфляция сторипоинтов
Гудхарт-мишень: Velocity или обязательство закрыть все задачи спринта.
Балансировочные метрики: Техническое качество реализации (например, количество новых багов, связанных с завершёнными задачами, или прирост задач в бэклоге из-за технического долга), график burndown.
Как это работает: Погоня за скоростью приводит к инфляции сторипоинтов и накоплению «технического долга». Чтобы это контролировать, можно напрямую связывать фичи с багами, которые они породили, в системе задач. В этом случае burndown-график перестаёт быть монотонно убывающей функцией, ведущей в ноль. Он начинает «подпрыгивать» вверх при добавлении новых багов, наглядно демонстрируя истинную стоимость «быстрой» реализации. Цель смещается с «закрыть как можно больше поинтов» на «закрыть цельную фичу с минимальным количеством дефектов».
Универсальный алгоритм
Оказаться в ситуации сработавшего закона Гудхарта мы можем всегда, когда смещаем внимание с реальной цели на численные показатели. Что делать, если работа на одну метрику не приводит к успеху?
1. Определите «Гудхарт-мишень», моделирующую цель. Что сейчас оптимизируется?
2. Сформулируйте более подробное описание цели в реальном мире.
3. Найдите 1-2 «метрики-балансира», которые измеряют качество достижения цели, но не связаны напрямую с первой метрикой.
4. Принимайте решения, глядя на разные параметры. Если «мишень» растёт, а «балансиры» падают — вы идёте не туда. Если растут обе — вы на правильном пути!
Заключение: посмотрите на свои процессы через призму Гудхарта
С одной стороны, закон Гудхарта — это забавная закономерность, которая проявляется при использовании упрощенной модели. Зная, что карта не равна территории, мы должны быть всегда готовы к тому, что агент адаптируется к управлению неожиданным образом. Даже если этот агент — наш собственный мозг.
С другой стороны, эта «словесная формула» позволяет заметить и описать проблему, которая требует вашего внимания и новых подходов к управлению. Мы не можем изменить природу человека, но мы можем делать более точные модели реальности, и находить балансировочные метрики, которые помогут не упустить из виду реальную цель.
А вы замечали в своей работе или жизни моменты, когда погоня за одной единственной цифрой приводила к неожиданным результатам? Поделитесь своими историями — вместе мы соберём коллекцию иллюстраций к этому универсальному закону!