초록색 체크 표시(Green Check)는 다음 실행에서 읽기 전까지는 학습된 것이 아니다

• 현재의 PASS는 하나의 입력이 통과했음을 증명할 뿐, 이후의 실행이 이전의 실패로부터 얻은 교훈을 사용했음을 증명하지는 않습니다.
• 최소한의 수신 체인(receipt chain)은 실패한 바이트(failed bytes), 하나의 제한된 수정(bounded edit), 홀드아웃 결과(held-out result), 현재 해시(current hash), 그리고 다음 실행 읽기 상태(next-run read status)로 구성됩니다.
• 고정된 SkillOpt-Sleep 모의 실행(mock run)은 홀드아웃 평가(held-out evaluation)를 0.3333에서 1.0으로 이동시켰으며 유해한 수정을 차단했습니다.
• 이는 고정된 모의 수락 계약(mock acceptance contract)에 대한 증거이지, 프로덕션 품질(production-quality), 수익(revenue), 또는 지능(intelligence) 측정값은 아닙니다.

야간 로그는 PASS로 끝납니다. 운영자에게는 여전히 해결되지 않은 질문이 하나 남아 있습니다: 어제의 수정 사항이 내일의 입력에 도달했는가?

그 차이가 바로 증거 체인(evidence chain)의 핵심 역할입니다. 이 가이드는 매일 밤 반복적인 조사를 수행하지만, 다음 날 아침의 입력이 어제의 수정을 읽었는지 증명할 수 없는 엔지니어를 위한 것입니다.

초록색 체크가 증명할 수 없는 세 가지 상태

**재작성 (Rewrite)**은 문서나 설정이 변경되었음을 의미합니다. 이는 오직 바이트(bytes)가 변경되었음만을 증명합니다.

**현재 PASS (Current PASS)**는 현재의 입력이 체크를 통과했음을 의미합니다. 이는 해당 바이트에 대한 해당 체크의 판정만을 증명합니다.

**감사 가능한 학습 (Auditable learning)**은 실패, 수정, 평가, 해시, 그리고 다음 실행 읽기 수신 확인(next-run read receipt)을 함께 유지합니다. 이는 수락된 변경 사항이 이후의 실행에 도달했음을 보여줄 수 있습니다.

처음 두 가지 수신 확인만 존재하는 경우에는 세 번째 레이블을 사용하지 마십시오.

다섯 가지 수신 확인이 다음 실행에 도달함을 증명하는 방법

1. 실패한 바이트 보존 (Preserve the failure bytes)

실패한 입력, 질문, 점수 또는 실행 후 측정값(post-run measurement)을 유지하십시오. 이를 생성한 문서 또는 구성 바이트를 유지하십시오. 실패 분류(failure classification)와 하나의 실행 식별자(run identity)를 추가하십시오.

입력이 없는 점수만으로는 무엇이 수정되었는지 알 수 없습니다. 동일한 수신 확인 내에서 입력과 출력의 해시(hash)를 생성하고, 요약본으로 대체하는 대신 원래의 실패 텍스트를 유지하십시오.

2. 하나의 제한된 수정 수행 (Make one bounded edit)

하나의 제한된 부분만 변경하십시오: 추가, 삭제 또는 교체. 동일한 수락 시도(acceptance attempt) 내에서 프롬프트(prompt), 평가기(evaluator), 데이터(data) 및 라우터(router)를 변경하지 마십시오.

Microsoft의 SkillOpt README는 기술 문서(skill document)를 "동결된 에이전트(frozen agent)의 학습 가능한 상태"라고 부릅니다. 이 문서는 수락(acceptance)을 "보류된 검증 점수(held-out validation score)를 엄격하게 개선하는" 후보로 설명하며, "거부된 편집 버퍼(rejected-edit buffer)"를 명시합니다. 유용한 운영 규칙은 마케팅적 주장보다 더 좁습니다: 작은 편집은 다음 결과와 비교할 수 있는 흔적을 남깁니다.

3. 보류된 작업에 대해 재평가 (Re-evaluate on held-out work)

해당 후보를 유도했던 예시들만으로 수락하지 마십시오. 편집을 만드는 단계에서는 작업을 제외하고, 그 보류된 작업(held-out work)을 수락 결정에 사용하십시오.

평가기(evaluator)가 판결을 내릴 수 없거나, 차이를 노이즈(noise)와 분리할 수 없는 경우 unknown으로 기록하십시오. 거부된 편집은 경계(boundary)에 대한 증거로 남습니다; 이는 조용히 삭제되어서는 안 됩니다.

4. 해시(hashes)로 체인 결합 (Bind the chain to hashes)

다음 필드들을 연결된 영수증(linked receipts)에 넣으십시오:

• failure: 원래의 실패, 분류, 입력 해시(input hash)
• edit: 변경된 바이트(bytes) 또는 설정, 변경 해시(change hash)
• evaluation: 초기 및 보류된 결과, 작업 버전(task version)
• decision: 수락(accept), 거부(reject), 또는 unknown, 사유 포함
• consume: 다음 실행 식별자(next-run identity), 로드된 식별자(loaded identifier), 현재 해시(current hash), 읽기 상태(read status)

현재 바이트가 영수증 해시와 일치하지 않는 경우, 새 문서에 오래된 PASS를 부착하지 마십시오. 해시는 어떤 바이트가 평가되었는지를 말해주는 경계입니다.

5. 다음 실행의 읽기 영수증 요구 (Require the next-run read receipt)

수락된 버전을 원장(ledger)에 기록하는 것만으로는 충분하지 않습니다. 다음 실행 시 무엇을 로드했는지 보고해야 합니다.

읽기 영수증(read receipt)에는 최소 네 가지 값이 필요합니다: 다음 실행 식별자(next-run identity), 로드된 파일 또는 설정의 안정적인 식별자(stable identifier), 로드 시점의 현재 해시(current hash), 그리고 기계가 읽을 수 있는 읽기 상태(machine-readable read status)입니다. 만약 평가자(evaluator)가 수락된 버전이 경로 A에 있음에도 불구하고 경로 B를 읽는다면, 해당 교훈이 루프(loop)에 도달하지 못한 채 평가는 통과될 수 있습니다.

고정된 모의 영수증 (The pinned mock receipt)

저는 커밋 7da46ae693ee0329b80225c0128a37d65db10e9e에 명시된 명령어를 실행했습니다:

python3 -m skillopt_sleep.experiments.run_experiment --persona researcher --assert-improves

새로운 리포지토리 실행 결과 종료 코드(exit code) 0을 반환했습니다:

tasks: 12   tokens(approx): 0
baseline held-out : 0.3333
after  held-out   : 1.0   (lift +0.6667)
...

이 실험 결과는 하나의 좁은 범위의 진술만을 뒷받침합니다: 이 고정된 모의(mock) 환경에서는, 홀드아웃(held-out) 점수가 상승했고 유해한 편집(harmful edit)이 거부되었다는 점입니다. 이것은 5개 필드로 구성된 '다음 실행 영수증(next-run receipt)'이 아니며, 프로덕션 에이전트가 0.6667만큼 더 똑똑해졌거나, 수익을 개선했거나, 혹은 모든 작업에 일반화(generalized)되었다는 것을 보여주지 않습니다.

증거 체인(evidence chain)의 비용

실질적인 비용은 단순히 해시(hash) 계산에만 국한되지 않습니다. 기록의 일관성을 유지하고, 홀드아웃 경계(held-out boundary)를 보호하며, 다음 실행 시 수락된 버전을 읽는지 확인하는 과정이 포함됩니다.

• 기록 (Records): 실패(failure), 편집(edit), 평가(evaluation), 소비(consume)라는 네 가지 작은 영수증 유형을 유지합니다. 원래의 실패 데이터와 홀드아웃 데이터를 보존합니다.
• 해시 (Hashes): 평가 대상인 바이트(bytes)와 수락된 버전에 대한 해시를 계산합니다. 이번 복구 과정에서는 CPU 시간이나 저장 용량을 벤치마킹하지 않았습니다.
• 평가 (Evaluation): 홀드아웃 작업을 재실행(replay)하고 결과를 판단합니다. 실제 백엔드는 재실행, 판단 또는 성찰(reflection)을 위해 프로바이더(provider) 예산을 소모하지만, 고정된 모의(mock)는 그렇지 않습니다.
• 운영 (Operations): 보존 정책을 선택하고, 스키마 변경(schema changes)을 처리하며, 누락된 기록을 탐지합니다. 이러한 점검은 일회성 설정 작업이 아니라 반복적인 유지보수 작업입니다.

고정된 SkillOpt-Sleep 문서는 “로컬 evidence.jsonl을 작성한다”, “모의 백엔드(mock backend)는 프로바이더(provider) 호출을 수행하지 않는다”, 그리고 “드라이 런(dry-run) 시에도 여전히 프로바이더 호출 및 비용이 발생한다”라는 문구를 사용합니다. 또한 운영자에게 보존 정책(retention policy)을 설정할 것을 요구합니다. 따라서 tokens(approx): 0은 이 모의 결과(mock result)의 속성이지, 실제 운영 비용이 아닙니다. 프로바이더 예산(provider budget)은 실제 백엔드에서 측정해야 할 운영 비용이며, 이 글에서 임의로 만들어낸 숫자가 아닙니다.

작은 루프(loop)를 위한 최소 요건은 스키마(schema), 홀드아웃 세트(held-out set), 보존 규칙(retention rules), 그리고 읽기 점검(read check)입니다. 정확한 API 청구 금액, 스토리지 점유율(storage footprint), 그리고 실제 소요 시간(wall-clock time)은 배포 측정값으로 남겨두어야 합니다. 모의 결과(mock result)를 통해 이 값들을 임의로 채워 넣지 마십시오.

야간 조사(nightly investigation)에서의 적용 위치

홀드아웃 세트(held-out set)와 방어 가능한 정확성 신호(defensible correctness signal)가 존재하는 반복 테스트, 정기 조사, 또는 안정적인 데이터 변환(data transformations)에 이 체인(chain)을 사용하십시오.

홀드아웃(holdout)이 오염되었거나, 평가기(evaluator)가 실패하거나, 실행 간에 작업이 너무 많이 변경되거나, 또는 다음 실행의 읽기 영수증(read receipt)이 누락된 경우에는 unknown을 반환하십시오. 주관적인 편집(subjective edit)은 여전히 유용할 수 있지만, 반복 가능한 수용 경계(repeatable acceptance boundary) 없이는 이 학습 주장(learning claim)을 얻을 수 없습니다.

반복되는 에이전트(agent)를 운영한다면, Anicca 진단 엔트리 포인트(diagnostic entry point)를 사용하여 측정 가능한 영수증(receipt)의 다섯 가지 필드를 확인하십시오: 실패 기록(failure record), 제한된 편집(bounded edit), 홀드아웃 결과(held-out result), 현재 해시(current hash), 그리고 다음 실행 읽기 상태(next-run read status)입니다. 만약 한 필드라도 누락되었다면 unknown으로 기록하십시오. 이 글의 모의 영수증(mock receipt)과 어떠한 수익 결과(revenue result)도 진단 결과가 아닙니다.

이 체인은 다음 실행이 읽기 영수증(read receipt)을 반환할 때에만 종료됩니다.

출처

출처

• Anicca public landing page
• Microsoft SkillOpt README, pinned commit
• Microsoft SkillOpt-Sleep README, pinned commit
• SkillOpt deterministic experiment source, pinned commit
• SkillOpt-Sleep results, pinned commit
• Anicca diagnostic entry point: verify the next-run evidence receipt