장애 조치는 두 번째 모델이 점수를 매기지 않은 패치를 승인할 수 있습니다. 첫 번째 영수증은 게이트가 이를 바인딩하지 않는 한 디스크에 남아 있게 됩니다. 이 랩 사후 분석(postmortem)에서는 재현 과정, 원인 요인, 그리고 해결책을 기록합니다.
작성 범위 (Scope of this write-up)
본 글은 고객사 사고 사례가 아닌 통제된 랩 재현 테스트입니다. 여기서는 생산 환경 지표, 고객 정보 또는 시간 측정치를 주장하지 않습니다. 독자들은 제안된 게이트를 신뢰하기 전에 자체 테스트를 실행해야 합니다.
결론부터 말씀드리자면 (The conclusion up front)
영수증은 diff, 프롬프트(prompt), 모델, 그리고 작업 공간 생성 정보를 모두 포함해야 합니다. 일치하는 diff 해시만으로는 완료된 검토가 아닙니다. 바인딩된 필드 중 하나라도 누락되면 게이트는 실패 처리됩니다 (fails closed).
랩 타임라인 (Lab timeline)
재현 과정은 재활용된 작업 공간 하나와 두 개의 불투명한 모델 ID를 사용합니다. 이 ID들은 제품 모델 이름이 아닌 랩 레이블입니다. 아래의 각 단계는 파일 확인 또는 명령어 실행을 의미합니다.
- T0은 이전 영수증을 재활용된 작업 디렉터리로 복사합니다.
- T1은 model A를 기록하고 diff에 대한 통과(pass) 영수증을 작성합니다.
- T2는 model A를 제거하고 재시도를 위해 model B를 선택합니다.
- T3은 receipt.json이 이미 디스크에 존재하므로 점수 매기기를 건너뜁니다.
- T4는 diff 해시만 확인하는 단순한 게이트(naive gate)를 실행합니다.
- T5는 작업 로그 모델과 영수증 모델 ID를 비교합니다.
- T6은 바인딩된 게이트를 실행하고 외부 영수증을 거부합니다.
단순 게이트가 통과한 이유 (Why the naive gate passed)
단순 검사는 저장된 해시 하나만 비교한 후, 더 이상 찾지 않았습니다. diff 바이트는 일치했기 때문에 프로세스는 성공으로 반환되었습니다. 재활용된 서버 환경은 이러한 단일 필드 확인을 속이기 쉽게 만듭니다.
def naive_accept(receipt, diff_sha256):
return receipt.get('diff_sha256') == diff_sha256 and receipt.get('verdict') == 'pass'
이 헬퍼 함수는 모델 ID와 작업 공간 생성을 완전히 무시합니다. 또한 어떤 검토 이유가 저장되었는지 여부도 무시합니다. 따라서 파일의 존재 유무만으로 완료된 검토 시도로 간주됩니다.
기여 요인 (Contributing factors)
- 영수증은 모든 시도에서 공유되는 고정된 이름을 사용했습니다.
- 작업 공간 재사용은 장애 조치(failover) 후에도 이전 점수 파일을 유지했습니다.
- 장애 조치는 파일 존재를 새로운 시도의 완료로 간주했습니다.
- 게이트는 스코어러의 신원 없이 diff 해시를 신뢰했습니다.
- 에이전트와 게이트는 하나의 쓰기 가능한 서버 디렉토리를 공유했습니다.
- 어떤 시도 ID도 작업 로그를 승인된 영수증과 연결하지 않았습니다.
- 정리(Cleanup)는 성공했을 때만 실행되었기 때문에, 충돌 시 이전 파일이 남아 있었습니다.
지속 가능한 수정 사항 (What the durable fix changes)
이 수정은 모델에게 더 열심히 노력하라고 요구하지 않습니다. 다른 시도의 영수증을 인증하는 것을 거부합니다. Bootstrap은 어떤 에이전트가 시작되기 전에 작업 공간 생성을 만듭니다.
예상되는 모델 ID는 시도가 시작될 때 캡처됩니다. 게이트는 해시를 재계산하고 모든 바운드 필드를 비교합니다. 누락된 필드는 소프트 경고가 아니라 실패한 작업입니다.
영수증 바인더 (Receipt binder)
다음 프로그램을 job image에 bind_receipt.py로 저장하세요. 이 프로그램은 일반 CI 이미지에서 Python 3.9 이상을 대상으로 합니다. 이는 호스팅되는 검토 서비스가 아닌, 제안된 로컬 게이트입니다.
#!/usr/bin/env python3
'''eval 영수증을 diff, prompt, model, 및 작업 공간 생성에 바인딩합니다.'''
...
실험실용 명령어 (Commands for the lab)
이 게이트를 CI에 연결하기 전에 자체 테스트를 실행하세요. 자체 테스트가 실패한다는 것은 바인더 자체가 신뢰할 수 없다는 의미입니다.
python3 bind_receipt.py selftest
재신(reasons) 파일은 짧은 문자열의 JSON 배열이어야 합니다. 객체나 빈 배열은 설계상 거부됩니다.
독립적인 점수 파일이 존재하는 후에만 영수증을 작성하세요. 에이전트가 스스로 패스 비트를 선택하게 두지 마세요.
python3 bind_receipt.py write \
--diff patch.diff \
--prompt prompt.txt \
...
병합될 예정인 시도와 비교하여 검증하세요. 필드 불일치는 재시도 없이 작업을 실패시켜야 합니다.
python3 bind_receipt.py verify \
--diff patch.diff \
--prompt prompt.txt \
...
Bootstrap 규칙 (Bootstrap rules)
이 규칙들은 프롬프트가 아닌 job image에 적용하세요. 이 규칙들은 무료 서버가 다른 시도를 재실행하는 것을 막습니다.
- bootstrap 과정에서 Mint WORKSPACE_GEN.
- 선택 후 MODEL_ID를 Export하고 해당 값을 고정(freeze)합니다.
- 각 영수증을 시도 ID로 명명된 디렉터리 아래에 저장합니다.
- 이전 생성으로 남겨진 모든 영수증 경로는 무시합니다.
- verify가 0이 아닌 값으로 종료되면 작업을 실패 처리하고 재시도하지 않습니다.
- 병합(merge) 전에 작업 로그의 모델 ID와 영수증을 비교합니다.
- 영수증 누락은 건너뛴 검사(skipped check)가 아니라 실패로 간주합니다.
의사 결정 테이블 (Decision table)
이 표는 단순한 차이 확인(naive diff check)과 경계 게이트(bound gate)를 비교합니다. 마지막 행만 유효한 병합 경로입니다. 관찰된 다른 모든 상태는 닫혀 있으며 병합을 차단합니다.
| 관찰된 상태 | 단순 게이트 (Naive gate) | 경계 게이트 (Bound gate) |
|---|
| 동일한 차이, 새로운 모델 ID | 수락 (accept) | 거부 (reject) |
| ... | | |
'거부(reject)' 읽는 방법
verify 명령어는 일치하지 않는 필드 이름을 출력하고 1로 종료됩니다. 운영자는 해당 줄을 사고 증상으로 간주해야 합니다. 실행 후 작업 로그에서 이 줄을 삭제해서는 안 됩니다.
모델 ID 불일치는 스코어러(scorer)가 영수증 이후에 변경되었음을 의미합니다. 워크스페이스 생성(workspace_generation) 불일치는 서버가 상태를 재사용했음을 의미합니다. diff_sha256 불일치는 패치가 스코어링 이후에 이동했음을 의미합니다.
거부된 줄을 빌드 기록의 시도 ID 옆에 저장하십시오. 그 기록이 실패한 인증에 대한 감사 추적(audit trail)입니다. 나중에 검토할 때 장애 조치(failover)와 잘못된 패치를 분리할 수 있습니다.
고유한 실패 클래스 (Distinct failure class)
이 실패는 오래된 캐시 키(stale cache key)도 아니고 락 파일 재시도(lockfile retry)도 아닙니다. 영수증 파일은 의도적으로 다른 시도의 유효성을 가집니다. 지속적인 해결책은 더 긴 시간 제한(longer timeout)이 아니라 신원 바인딩(identity binding)입니다.
무료 서버 작업 계약 (Free server job contract)
무료 서버에서는 bootstrap 과정에서 에이전트가 쓰기 가능한 스코어 경로를 모두 지워야 합니다. 바인더(binder)가 존재할 때도 삭제가 필요합니다. 오염된 디렉터리는 에이전트가 신뢰할 수 있는 다른 파일들을 숨깁니다.
네 가지 경계 값(bound values)을 작업 환경으로 Export하십시오. 그 값들을 프롬프트 텍스트로 전달하는 것이 아니라 플래그(flags)로 전달해야 합니다. 프롬프트 텍스트는 검토 중인 에이전트에 의해 수정될 수 있습니다.
무료 모델 접근 방식의 적합성 (Where free model access fits)
공개 사항: 본 문서는 MonkeyCode의 제품 홍보 목적으로 작성되었습니다. MonkeyCode는 이 방식을 운영자 제공 무료 모델 접근 방식으로 간주합니다. 다른 운영자 제공 주장으로는 무료 서버 옵션이 사용됩니다.
재사용된 서버는 어제의 영수증을 오늘의 차분(diff) 옆에 보관할 수 있습니다. 또한 무료 모델 접근 방식은 실패한 시도 후 스코어러를 전환할 수도 있습니다. 이 두 가지 조건은 영수증 바인딩을 선택 사항이 아닌 실용적인 것으로 만듭니다.
본 초안은 모델, 할당량(quota), 하드웨어 또는 기간을 명시하지 않습니다. 또한 무료 접근이 영구적이라고 주장하지도 않습니다. 해당 접근 방식에 맞춰 용량을 계획하기 전에 현재 약관을 확인하십시오.
만약 나중에 그 접근 방식이 사용 불가능해지더라도 바인더는 여전히 중요합니다. 작업 공간을 재활용하는 모든 호스트가 같은 구멍(hole)을 가지고 있습니다. bind_receipt.py를 작업 이미지에 넣고 불일치 시 병합(merge)을 차단하십시오.
테스트 계획
첫 번째 로컬 확인으로는 자체 테스트를 사용하십시오. 그런 다음 아래의 고정 요소(fixture) 케이스들을 CI에 추가하십시오.
- 모델 A의 영수증을 생성한 후, 모델 B로 검증하고 종료 코드 1이 예상되는지 확인합니다.
- 모델 ID는 유지하고 작업 공간 생성을 변경한 후, 종료 코드 1이 예상되는지 확인합니다.
- 쓰기(write) 후 차분 바이트를 하나 변경하고 해시 불일치가 예상되는지 확인합니다.
- 쓰기(write) 후 프롬프트 바이트를 하나 변경하고 해시 불일치가 예상되는지 확인합니다.
- 이유와 함께 실패 판결을 작성하고, 검증(verify)이 이를 거부하는지 예상합니다.
- 빈 이유 목록(empty reasons list)을 쓰기(write)에 전달하고, 명령어가 예외를 발생시키는지 예상합니다.
- 영수증 파일을 제거하고, 검증(verify)이 안전하게 실패(fail closed)하는지 예상합니다.
- 동일한 네 가지 필드로 작성하고 검증하며, 종료 코드 0이 예상되는지 확인합니다.
새로운 시도의 새로운 증거 없이 verify를 재시도하지 마십시오. 거부(reject)는 일시적인 네트워크 오류가 아니라 기록된 데이터입니다.
제한 사항
해시는 검토의 품질을 측정하지 않습니다. 일치하는 영수증이라 하더라도 차분에 대한 약한 해석을 설명할 수 있습니다. 게이트는 오직 신원과 이유의 존재 여부만 확인합니다.
적대적인 실행 환경(hostile runner)은 파일 내 모든 바인딩된 필드를 위조할 수 있습니다. 이 바인더는 모델 공급업체에 대한 증명 서비스가 아닙니다. 팀이 이미 신뢰하는 실행 환경과 결합하십시오.
Model id는 운영자(operator)가 제공하는 불투명한 문자열입니다. 이 스크립트는 모델을 나열하거나 선택하지 않습니다. 시도는 점수 산정이 시작되기 전에 해당 ID를 캡처해야 합니다.
작업 공간(Workspace generation)은 에이전트(agent)가 아닌 부트스트랩(bootstrap)에서 나와야 합니다. 만약 에이전트가 이 값을 발행(mint)한다면, 시도 기록을 다시 작성할 수 있습니다. 그러면 게이트는 에이전트가 작성한 이야기를 인증하게 됩니다.
무료 액세스는 사전 통지 없이 파이프라인에 변경될 수 있습니다. 특정 모델이나 서버 좌석이 계속 사용 가능하다고 가정하지 마십시오. 이 문서는 그러한 가용성 세부 정보를 검증하지 않습니다.
셀프 테스트는 원격 모델을 전혀 호출하지 않습니다. 임시 파일만으로 게이트 로직을 확인합니다. 녹색 셀프 테스트가 검토된 패치의 증거는 아닙니다.
이 접근 방식을 건너뛰어야 하는 경우
팀이 모델 실행에 대한 공급업체 서명 증명을 필요로 할 때는 건너뜁니다. 이 스크립트는 그러한 종류의 증명을 제공할 수 없습니다. 서명된 증명(attestation)에는 다른 제어 평면(control plane)이 필요합니다.
별도의 릴리스 정책이 없는 배포에서는 건너뜁니다. 바인더(binder)는 릴리스 승인 위원회(release approval board)가 아니라 CI 체크입니다. 통과된 영수증이 유일한 프로덕션 게이트여서는 안 됩니다.
작업 공간이 작업 완료 후 항상 파괴되는 경우에도 건너뜁니다. 또한 모델 ID가 시도 간에 변경될 수 없는 경우에도 건너뜁니다. 그 좁은 경우에는 더 간단한 diff 해시로 충분할 수 있습니다.
쿼터 계획, 비용 예측 또는 하드웨어 크기 결정용으로는 건너뜁니다. 이 문서는 그러한 운영상의 숫자를 검증하지 않습니다. 용량(capacity)은 공급업체 문서를 사용하고, 이 실험실 게이트를 사용하지 마십시오.
마무리
페일오버가 이전 점수를 다시 재생할 수 있도록 영수증을 바인딩하십시오. 작업 공간 생성은 에이전트 프로세스 외부에서 발행(mint)하십시오. 모델, 프롬프트 또는 diff가 일치하지 않으면 닫힘(Fail closed)으로 처리하십시오.