|
Здравствуйте. Хочу поделиться результатом эксперимента по поведенческой реконструкции программы csview в рамках бенчмарка ProgramBench (wfxr__csview.8ac4de0) и обсудить одну методологическую проблему.
Суть эксперимента:
Задача — восстановить поведение программы, имея только скомпилированный бинарный файл и документацию. Оценка выставляется на основе набора поведенческих тестов (поведенческий бенчмарк).
В ходе работы использовался итеративный цикл: наблюдаемое различие в поведении → гипотеза о его происхождении → минимальное изменение → повторное наблюдение → регрессионная проверка → внешняя оценка.
Ключевой момент: был получен результат, который, на первый взгляд, выглядит парадоксальным. Один и тот же стабилизированный код (submission) сначала получил официальную оценку 69, а затем, без какого-либо изменения самого кода, — SOLVED (✅ 335 tests, average 100). Криптографическая идентичность submission была подтверждена (SHA-256: a7b055b8dea5...).
Проблема:
Анализ показал, что расхождение было вызвано дефектами в слое оценщика (evaluator) и тестовой инфраструктуры, а не ошибками в восстановленном поведении программы:
Несоответствие пространств имён: JUnit-отчёт формировал имена тестов с префиксом eval.tests.*, а эталонный список ожидал tests.*. Из-за буквального сравнения строк evaluator не видел ни одного пройденного теста из этой группы. После устранения только этого несоответствия в логике evaluator (без изменения кода csview) все 153 теста были зачтены.
Саморазрушение окружения: Одна из тестовых веток содержала команду обновления pytest (pip install -U pytest). Это обновление приводило к падению pytest на этапе загрузки плагина, ещё до выполнения тестов csview. В результате тесты не запускались, и evaluator фиксировал ошибку. Удаление флага -U (обновление) из команды в evaluator (опять же, без изменения кода csview) восстановило работоспособность ветки.
Таким образом, переход от 69 к SOLVED стал следствием исправления измерительной инфраструктуры, а не улучшения реконструкции.
Вопрос для обсуждения:
В бенчмарках, где оценка строится на сравнении поведения (поведенческие тесты), как методологически корректно отделить поведение самой восстанавливаемой программы от поведения измерительной системы (evaluator, тестовое окружение, утилиты)?
В данном случае мы имеем ситуацию, когда один и тот же объект измерения даёт кардинально разные оценки в зависимости от состояния измерительного прибора. Не приводит ли это к тому, что оптимизация под бенчмарк может идти по пути компенсации артефактов самого бенчмарка, а не восстановления истинного поведения целевой программы?
Будет интересно услышать мнение сообщества: как в подобных задачах следует выстраивать валидацию, чтобы оценка отражала именно качество реконструкции, а не успешность обхода багов в тестовом стенде? А может авторы бенчмарка, просто зарабатывают на своём бенчмарке?
С полным отчётом по эксперименту можно ознакомиться здесь: [https://docs.google.com/document/d/1NbpElrrBYEYk93hfqGjMcFdgVmulMajdV-LfMvcEvlo/edit?usp=sharing].
Заранее благодарю за комментарии.
|
