[Agent Eval 구현 노트 4] 장시간 평가의 복구와 provenance

시리즈 허브 · 구현 노트 4/4

평가 실행도 운영 시스템이다

소수 case를 실행할 때는 process를 다시 시작하면 된다. Population과 반복 횟수가 커지면 상황이 달라진다.

  • Network error 하나로 전체 run이 중단될 수 있다.
  • Provider quota와 local resource limit이 다르다.
  • 재시작 후 무엇을 이미 실행했는지 판별해야 한다.
  • Dataset이나 scoring policy가 바뀐 결과를 잘못 재사용할 수 있다.
  • Accuracy가 달라졌을 때 입력, 모델, runtime 중 무엇이 바뀌었는지 알아야 한다.

이때 checkpoint, execution identity와 provenance는 부가 기능이 아니라 평가 결과를 신뢰하기 위한 기본 계약이 된다.

Checkpoint와 graceful stop

장시간 평가의 checkpoint와 resume 시퀀스

안전한 중단 흐름은 다음과 같다.

  1. 일정 개수의 execution이 settle될 때마다 checkpoint를 원자적으로 쓴다.
  2. 종료 signal을 받으면 새로운 request dispatch를 중단한다.
  3. 이미 진행 중인 request가 settle될 때까지 기다린다.
  4. 마지막 checkpoint를 기록하고 process를 종료한다.
  5. Resume 시 execution identity와 run policy를 검증한다.
  6. 재사용 가능한 결과를 제외하고 나머지만 dispatch한다.

Process가 강제 종료되면 마지막 signal checkpoint는 만들 수 없다. 그래서 signal handler만 믿지 않고 periodic checkpoint도 필요하다.

Execution identity

같은 파일 경로만으로 과거 결과를 재사용하면 위험하다. 파일 안의 request나 expectation이 바뀌었을 수 있기 때문이다.

Execution identity는 보통 다음 요소로 만든다.

test case path
+ stable test case ID
+ repetition index
+ projected execution plan digest

Projected plan의 digest를 포함하면 request context, history 또는 expected path가 바뀐 결과를 stale result로 재사용하지 않는다.

Resume compatibility에는 execution identity 외에도 다음 run-level 조건이 필요하다.

  • Dataset selection과 revision
  • Validation·selection policy
  • Scoring fields와 alternative policy
  • Model·provider·tier
  • Runtime revision
  • Concurrency·continuation 같은 execution policy

조건이 다르면 resume이 아니라 새로운 run으로 취급해야 한다.

여기서 source repository revision만으로 원격 model configuration까지 항상 설명할 수 있는 것은 아니다. Model ID, serving revision, sampling parameter와 feature flag가 repository 밖에서 바뀔 수 있다면 별도의 opaque identity로 artifact에 기록해야 한다. 그렇지 않으면 동일 commit과 plan digest인데 실제 model 조건은 다른 실행을 비교하게 된다.

Atomic checkpoint

Checkpoint를 결과 파일에 직접 덮어쓰다 process가 죽으면 JSON 전체가 깨질 수 있다. 임시 파일에 완성된 snapshot을 쓴 뒤 atomic rename하는 방식이 안전하다.

serialize current state
  → write temporary file
  → fsync when required
  → atomic rename
  → previous complete snapshot replaced

Checkpoint artifact와 finished artifact의 상태도 구분한다. Reporting command가 미완료 population을 최종 결과로 오해하지 않도록 checkpoint, interrupted, finished 같은 result type을 명시한다.

실행 budget을 두 축으로 관리한다

최대 concurrency와 최소 request 시작 간격은 서로 다른 문제를 해결한다.

  • Max concurrency: CPU, memory, connection pool과 runtime capacity 보호
  • Min start interval: provider rate limit과 request window 보호

둘을 하나의 sleep 설정으로 합치면 remote provider와 local model의 다른 제약을 표현하기 어렵다. Local 환경에서는 start interval을 낮추고 concurrency를 측정값에 맞출 수 있지만, 둘 다 무제한으로 해석해서는 안 된다.

Continuation이나 retry에도 별도 budget을 둔다. 현재 continuation budget만 있다면 transport retry를 같은 숫자로 해석하지 말고, retry를 도입할 때 원인·backoff·최대 횟수를 독립된 policy로 기록해야 한다. 그렇지 않으면 case 하나가 반복 discovery나 transient error로 전체 run capacity를 점유할 수 있다.

Provenance reference model

평가 artifact에 포함할 provenance와 비교 경계

최종 artifact에는 score뿐 아니라 비교 조건을 함께 저장한다.

Input provenance

  • Dataset·schema revision
  • Locale, device와 selection
  • Test case count와 반복 횟수
  • Validation 결과와 제외 population

Execution provenance

  • Model·provider·tier
  • Runtime revision 또는 image identity
  • Timeout, concurrency와 request pacing
  • Continuation·retry policy

Scoring provenance

  • Match fields
  • Alternative path policy
  • Scorer revision
  • Judge model과 prompt revision을 사용했다면 그 식별자

Per-execution evidence

  • 실제 structured action과 parameters
  • Path별 verdict와 failure category
  • Error type과 어느 step에서 발생했는지
  • Fixture와 실제 호출의 구분

Stateful episode를 추가하면 여기에 initial state revision, environment backend, operation ID, mutation count와 verified post-state도 포함해야 한다. Replay checkpoint와 episode checkpoint는 재사용 조건이 다르므로 같은 identity 규칙으로 합치지 않는 편이 안전하다.

A/B 비교 전에 확인할 것

두 artifact의 aggregate accuracy부터 빼지 않는다. 먼저 비교 가능한 조건인지 검사한다.

같은 population인가?
  → 같은 selection·반복인가?
    → 같은 scoring policy인가?
      → 의도한 변수만 달라졌는가?
        → aggregate와 per-case transition 비교

Population이 다르면 accuracy delta와 함께 추가·삭제·제외된 case를 먼저 보고한다. 같은 ID라도 projected plan digest가 다르면 동일 execution으로 직접 비교하지 않는다.

운영 체크리스트

  • Periodic checkpoint와 graceful stop을 모두 지원하는가
  • Checkpoint write가 원자적인가
  • Execution identity가 projected plan 변경을 감지하는가
  • Resume 전에 run policy compatibility를 검사하는가
  • Concurrency와 request start interval이 분리돼 있는가
  • Retry·continuation에 별도 budget이 있는가
  • Artifact에 input·execution·scoring provenance가 들어가는가
  • Aggregate뿐 아니라 per-case transition을 비교할 수 있는가

평가를 반복 가능한 실험으로 만들려면 모델 결과만 저장해서는 부족하다. 어떤 입력을 어떤 조건과 정책으로 실행했고, 어디서 실패했는지까지 남아야 다음 의사결정의 비용을 낮출 수 있다.

이전: 구현 노트 3. 경로 채점의 함정과 discovery continuation

처음으로: 시리즈 허브

You may also enjoy