Lesson:dwkv failed run fail closed
| 제목 | 불완전 실행과 HTTP 400은 결과 matrix에서 fail-closed로 격리해야 한다 |
|---|---|
| 궁금했던 점 | 왜 일부 실패/partial payload를 삭제하지 않고 provenance manifest로 남겨야 하는가? |
| 해본 것 | independent multi-seed online sweeps를 실행하고 partial payload를 checkpoint/repair하여 전체 matrix를 채우려 했다. |
| 당시 조건 | archive에는 incomplete sweep, HTTP 400 request failure, seed 일부만 존재하는 control, server startup-timeout repair cell이 포함되어 있다. |
| 실제 결과 | 예를 들어 control은 seeds 1–5만 존재했고, 다른 payload는 1,800 requests 중 3개, 2,400 중 4개, 2,400 중 20개가 실패했다. patch cells는 다른 process의 prompt pool을 사용해 pair-mate와 workload가 달라졌다. `FAILED_RUNS.md`는 10개 artifact를 paper_grade=false로 분류하고 Git commit/SHA-256/recovery path를 보존한다. |
| 왜 그랬는지 | `complete:true`는 old harness가 planned cells에 도달했다는 뜻일 뿐 request failure, prompt provenance, pairing validity를 복구하지 않는다. 실패 payload를 결과에 섞지 않되, 재현·감사 가능한 provenance로 보존해야 한다. |
| 다음에 기억할 것 | 실험 runner는 request-level failure를 즉시 기록하고 complete/finalize를 거부하며, partial payload를 별도 경로에 보관한다. repair run은 동일 immutable trace와 provenance가 입증될 때만 paired cell로 인정한다. |
| 언제 맞는지 | experiment runners, benchmark data quality, failure recovery, reproducibility audits |
| 신뢰도 | 중간 |
| 관련 자료 | removed failed/partial run manifest, unseeded prompt provenance README, legacy runner tests for fail-closed behavior |
| 자료 출처 | 우리 기록 |
| 작성자 | S3ResearchAgent |
| 처음 작성한 시각 (UTC) | 2026-07-19T01:46:53.522174Z |
| 마지막 수정 시각 (UTC) | 2026-07-19T01:46:53.522174Z |
근거 dwkv-failed-runs: experiments/archive/FAILED_RUNS.md; experiments/archive/pre_seed_fix/README.md; tests/legacy/test_sharegpt_harness.py
로그 · 확인 범위: 일부 자료 확인 · S3ResearchAgent · 2026-07-19T01:46:53.522174Z
실패 수량, recovery commit/SHA, pairing invalid 조건, fail-closed test를 확인함.