Reproducibility & One-Variable Testing — как превращать эксперименты в инженерный процесс
Если два запуска отличаются одновременно seed, denoise, prompt, model и resolution, невозможно понять причину результата. Профессиональный workflow должен позволять повторить тест и изменять по одной переменной за итерацию.
0 из 11 проверок
Состояние сохраняется в localStorage этого браузера. Workflow и файлы ComfyUI не изменяются.
Повторяемость нужна не ради науки, а ради быстрых решений
Когда результат можно повторить, любое улучшение или ухудшение можно связать с конкретным изменением. Без этого пользователь оценивает набор случайностей и не строит надёжный production recipe.
Для Archviz это особенно важно: мы должны отличать улучшение материала от изменения геометрии, света, seed или local mask.
Что нужно фиксировать для воспроизводимого запуска
| Категория | Что сохранить |
|---|---|
| Workflow | точная версия JSON / commit / hash |
| Inputs | те же images, masks, references |
| Models | filenames / versions / relevant custom nodes |
| Controls | effective values, включая linked inputs |
| Sampling | seed, steps, sampler, scheduler, CFG/guidance, denoise |
| Canvas | working resolution / resize mode / batch |
| Runtime profile | какие groups enabled/bypassed |
| Result | checkpoint previews + final output |
Менять одну переменную за тест
Если цель — определить влияние denoise, seed, prompt и ControlNet strength должны оставаться неизменными. Если тестируется Canny, Depth и sampler не меняются между вариантами.
Это делает A/B comparison интерпретируемым.
Seed — часть конфигурации эксперимента, а не кнопка случайности
При сравнении архитектурных настроек seed нужно фиксировать. Иначе изменение композиционных деталей, людей или материалов может быть связано с новым noise pattern, а не с тестируемым параметром.
В workflow со shared seed нужно проверить всех consumers: один источник может одновременно влиять на несколько samplers / noise nodes.
Записывать фактические значения, а не только то, что видно в widget
Если sampler получает steps или denoise через linked input, локально сохранённый widget не является authoritative. В benchmark log нужно записывать effective upstream value.
То же относится к selectors: stored value и текущий selected source могут расходиться.
Golden Run — эталон, относительно которого измеряются изменения
После того как workflow стабилен, полезно зафиксировать один проверенный прогон: inputs, model manifest, controls, seed, checkpoints и final output. Это становится baseline.
Любое обновление custom nodes, model weights или topology можно затем проверять против Golden Run и быстро замечать regression.
Оценивать не «красивее», а заранее выбранные критерии
| Критерий | Что наблюдать в Archviz |
|---|---|
| Geometry preservation | камера, пропорции, openings, facade rhythm |
| Material realism | microdetail, roughness cues, texture stability |
| Lighting coherence | направление, exposure, local integration |
| Artifact rate | AI chaos, halos, duplicated details, broken people |
| Locality | изменения происходят только там, где разрешено |
| Runtime cost | VRAM, время, количество активных моделей |
Обновление модели или custom node — это изменение системы
Даже если JSON не изменился, новая версия custom node может изменить inputs, defaults или execution behavior. Поэтому версия окружения входит в reproducibility contract.
Production STABLE и experimental LAB полезно разделять именно по этой причине: эксперимент не должен незаметно менять baseline production workflow.
Практика: провести один настоящий A/B benchmark
- Выбрать один стабильный input.
- Зафиксировать seed и все controls.
- Выбрать только одну переменную.
- Сделать A и B без других изменений.
- Сохранить одинаковые checkpoints.
- Оценить заранее выбранные критерии, а не общее впечатление.
- Записать вывод и оставить лучший вариант новым baseline только после повторной проверки.