Measure Methodology

measure-methodology — как не обмануться собственным измерением

Скилл вырос из двух независимых документов, написанных в один день (2026-08-23) двумя контурами, не видевшими друг друга: методика производительности прошивок (ESP32, perf-methodology.md: «вся история багов должна стать методикой») и база ловушек бенчмарка локальных моделей (Codeaudit, 11 дефектов стенда до первой публикации). Убрав предмет, оба документа говорят одно и то же. Это ядро — то общее; предмет живёт в профилях.

Главный закон: стенд поверяется раньше объекта

Измерительный инструмент — такой же объект испытаний, как и измеряемое, и проверяется теми же процедурами. Пока не показано, что стенд выдаёт максимум на заведомо верном входе и меньше максимума — на заведомо неверном, его числа не значат ничего. «Скрипт отработал и напечатал таблицу» — наличие ВЫХОДА, а не РЕЗУЛЬТАТА (#SA-3 глобальной доктрины).

Цена урока фактом: в бенчмарке LLM из 11 найденных дефектов 7 были в стенде, не в моделях, и пять из них делали балл не связанным с работой модели (случайный эталон; ноль за верный ответ в другом регистре; полный балл за 1/200 работы; режим API обрывал ответ у всех). Рейтинг моделей, выданный до поверки стенда, был бы правдоподобен и целиком ложен.

Три исхода любого измерения — различать явно, не смешивать

Смешение первого со вторым — «занятая видеокарта выглядит как плохая модель», «слабый RSSI выглядит как медленная прошивка». Смешение первого с третьим — самое дорогое: «все модели проваливают пакетную классификацию» при дефекте режима API. Смешение в ОБРАТНУЮ сторону тоже бывает и обходится не дешевле: зацикливание/таймаут объекта — это первое (свойство объекта, воспроизводится детерминированно на конкретном входе), но по внешнему виду (нет ответа, аномальное время) неотличимо от второго и потому часто ошибочно исключается из среднего, занижая видимую частоту отказов объекта.

Поверка стенда — чек-лист ДО первого прогона

1. Оракул: заведомо верный вход → ровно максимум по каждой метрике. Эталон восстанавливать из того же источника, что видит объект (из промпта / из файла на плате), а НЕ из внутренних переменных генератора — иначе оракул повторит ошибку стенда и они «согласятся».
2. Мутант: заведомо неверный вход → меньше максимума. Тест, не умеющий краснеть, — не тест.
3. Жулик: попытка получить максимум нечестно — дубликаты, константа, «перечислить всё подряд», пустая заглушка. Находится ТОЛЬКО намеренной попыткой сжульничать.
4. Формы: содержательно верный вход в иной форме (регистр, пробелы, обёртка, порядок полей, разделитель дробной части) — тот же результат. Иначе стенд меряет форму, не содержание.
5. Мутация окружения: сломать оснастку (спрятать раннер, занять ресурс) — результат обязан пометиться как сбой среды, а не стать нулём объекта.
6. Инструкция: всё, что влияет на результат, названо объекту явно (скрытый штраф — несправедливость, не строгость).
7. Прибор нельзя «подкрутить» измеряемым: RSSI фиксировать рядом с каждым сетевым замером, min_free_heap сбрасывать перезагрузкой, модель выгружать между вариантами — состояние стенда от предыдущего прогона не должно утекать в следующий.

Протокол прогона

• Одна переменная за раз. Решающий эксперимент: тот же объект, тот же вход, отличается ровно один параметр стенда. Так за один запрос разоблачён format='json' (13 токенов против 2893 у одной модели на одном промпте).
• При детерминированном стенде единица выборки — экземпляр набора, не повтор. Если объект и оснастка детерминированы (temperature=0, фиксированные seed), повторный прогон ТОГО ЖЕ входа даёт то же значение и не добавляет статистической мощности — это псевдорепликация: N одинаковых точек считаются за N независимых наблюдений, и p-value занижается в сторону мнимой значимости. Ошибка систематически работает В ПОЛЬЗУ желаемого вывода «различия есть», поэтому особенно опасна. Мощность растит смена ВХОДА (новый экземпляр набора при том же генераторе), а не повтор одного и того же прогона. Перед статистикой — обязательная дедупликация: идентичные наблюдения внутри одной точки сравнения схлопываются в одно.
• Повторы ≥2 (лучше ≥3) нужны там, где есть источник недетерминизма (температура > 0, живое железо, сеть); разброс важнее среднего. Один прогон ничего не доказывает (прошивка: 15 с → 1,1 с → 10 с на трёх подряд). Разброс при заведомо детерминированных настройках — сам по себе аномалия, требующая толкования.
• Значимость различия — три исхода, не два. «Не значимо» и «доказанно равны» — разные утверждения; смешение первого со вторым выдаёт нехватку мощности за доказательство равенства. Триада: p < порог → различимы; иначе доверительный интервал разницы целиком внутри практического порога эквивалентности → доказанно неразличимы; иначе → мощности не хватило (нужна не более уверенная интерпретация того же числа, а больше данных или признание предела).
• Сравнение по единой шкале валидно только для однородной работы. Если объекты сравниваются сразу по нескольким разнородным задачам и знак разницы между ними МЕНЯЕТСЯ от задачи к задаче — единый средний балл не измеряет никакой величины, и наращивание выборки этого не чинит: усредняется разное. Проверка дёшева — посчитать разброс разницы ВНУТРИ одной задачи и сравнить с разбросом ПО набору задач; если по набору заметно больше, разница не в шуме измерения, а в разной специализации объектов. Правило: агрегировать только внутри однородного класса, различие «в среднем по всему» — не публиковать как факт об объектах.
• Отказ объекта — тоже РЕЗУЛЬТАТ, если он свойство объекта, а не среды. Зацикливание, превышение лимита времени, испорченный формат ответа — это не «сбой среды, исключить из выборки», а исход, который объект произвёл сам, детерминированно, на конкретном классе входа. Такой отказ оценивается низшим баллом и остаётся в выборке; исключается из выборки только то, что не дошло до объекта (обрыв соединения, недоступность стенда). Смешение этих двух исключает реальные провалы из среднего и завышает объект.
• Смена версии стенда → полный перепрогон. Смешивать в одной таблице числа разных версий проверки нельзя; прогон, начатый до правки, останавливать, а не дописывать.
• Сырые данные сохраняются рядом с агрегатом (полный ответ, полный лог), не только preview[:400] — иначе на этапе толкования нечего открыть.

Выход прогона: блок «ТРЕБУЕТ ТОЛКОВАНИЯ» — обязателен (#SA-4)

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

Три пункта из семи в последнем прогоне оказались поведением объекта, а не сбоем — и это тоже штатный исход толкования: вопрос задан, ответ записан, балл оставлен. Толкование — не поиск оправданий объекту, а разделение трёх исходов.

Отдельный метод: написать вывод для внешнего читателя

Факт: из 11 дефектов бенчмарка 4 последних и самых дорогих нашла не поверка и не шесть раундов аудита четырьмя моделями, а подготовка публикации. Механизм: аудит спрашивает «правильно ли сделано» (локально), статья — «что это значит» (глобально). Число 0,00 у всех безупречно по коду и разваливается на фразе «все модели проваливают задачу», потому что фраза требует причины, а причины нет. Отсутствие объяснения — и есть сигнал.

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

Чего НЕ делать

• Не наращивать аудиторов одного вида при вырожденном результате: шесть раундов аудита кода четырьмя моделями не нашли дефект на стыке кода с поведением API. Менять ВИД проверки (оракул → мутация окружения → жульничество → толкование → внешний читатель), а не аудитора.
• Не доверять агрегату без сырых данных под рукой.
• Не продолжать прогон после правки стенда «с того места» — только заново.
• Не приписывать объекту то, что не воспроизвелось повтором; и не списывать на среду то, что воспроизвелось во всех повторах.
• Не субъективную проверку человеком заменять автотестом: ручная навигация поймала лаги, которых автотесты не видели (ESP32, P-023); чтение сырого ответа поймало дефект, которого не видел аудит (Codeaudit, дефект 7). Это не слабость метода, а отдельный его канал.

Предметные профили

Профиль не повторяет ядро — он заполняет его под конкретное железо и метрики (как §0 у ESP32 «заполняется под каждую плату»).

Связанные скиллы и доктрина

incident-log — запись найденного дефекта стенда как W-/P-инцидента; self-learning — каталог классов (error-classes.md: C-022 «одинаковый результат у всех принят за свойство объектов»), триаж уроков; code-audit-core — аудит кода стенда (один из видов проверки, не единственный); six-corner-audit — стерильный проход по готовому отчёту. Глобальная доктрина: #SA-3 (тест обязан уметь краснеть), #SA-4 (вопрос «что это значит» задаёт инструмент), #AH-1 (число из конфига — не измерение).

История

• 2026-08-23 — создан контуром Codeaudit по решению оператора после того, как ESP32 (perf-methodology.md) и Codeaudit (llm-benchmark-pitfalls.md) независимо написали документы одного класса. Ядро — общее обоих; профиль LLM — из базы ловушек; профиль прошивок остаётся в зоне ESP32 (§12), сюда — только ссылка.
• 2026-08-23, вечер — дополнено по итогам первого прогона v2 (4 экземпляра набора, ловушки 17–19, D-048): псевдорепликация при детерминированном стенде (единица выборки — экземпляр, не повтор), три исхода значимости вместо двух, невалидность единой шкалы при знакопеременной разнице между объектами, разграничение «отказ объекта / сбой среды» уточнено до частого случая обратной путаницы (детерминированное зацикливание объекта похоже на сбой среды).