평가 워크플로
AutomationBench 레시피는 로컬 머신에서 Harbor를 실행합니다. 각 시도마다 CPU 샌드박스가 할당되며, AutomationBench는 이 샌드박스에 에이전트 루프, 시뮬레이션된 애플리케이션, 어설션 기반 평가기를 설치합니다. 모델은 사용자의 추론 엔드포인트에서 실행됩니다. 샌드박스에는 GPU나 실제 애플리케이션의 사용자 인증 정보가 필요하지 않습니다. 이 레시피는 Harbor의BaseAgent 및 BaseEnvironment 인터페이스를 구현하며, 공개된 CoreWeave Sandboxes 소프트웨어 개발 키트(SDK) 호출을 사용합니다. 네이티브 auto-bench 평가기를 수정 없이 그대로 실행하므로 업스트림 AutomationBench Harbor 어댑터가 필요하지 않습니다. Harbor, AutomationBench, cwsandbox SDK 버전은 레시피에 고정되어 있습니다.
사전 요구 사항
시작하기 전에 다음을 준비하세요.- 로컬 머신에 설치된
uv및 Git. 이 레시피를 실행하려면 Python 3.13 이상이 필요합니다. Python이 설치되어 있지 않으면uv가 요구 사항에 맞는 Python 버전을 다운로드합니다. - 샌드박스 액세스 권한이 있는 CoreWeave API 액세스 토큰.
- 선택한 동시성을 감당할 수 있는 동시 샌드박스 할당량 및 샌드박스당 vCPU 2개와 메모리 4GiB를 허용하는 리소스 정책.
- 도구 호출을 지원하는 추론 엔드포인트, API 키, 충분한 추론 할당량. 이 예시에서는 Serverless Inference API 키를 생성하세요.
- 로컬 머신에서 샌드박스 API 및 패키지 저장소에 액세스할 수 있는 네트워크 연결, 그리고 샌드박스에서 GitHub, Debian 및 Python 패키지 저장소, 추론 엔드포인트에 액세스할 수 있는 네트워크 연결.
레시피 설치하기
레시피 저장소를 복제하고 버전이 고정된 의존성을 설치하세요:모델 및 사용자 인증 정보 설정
시크릿 관리자에서 사용자 인증 정보를 불러와 프로세스 환경에 로드하세요.CWSANDBOX_API_KEY에는 CoreWeave 샌드박스 사용자 인증 정보를, MODEL_API_KEY에는 추론 사용자 인증 정보를 설정하세요. 키는 .env 파일에 저장하지 마세요.
.env 파일에는 모델 엔드포인트, 모델 이름, 프로젝트(선택 사항)만 설정하세요. Serverless Inference 예시에서는 다음 설정을 사용하세요. [WANDB-TEAM]과 [WANDB-PROJECT]는 액세스 권한이 있는 이름으로 바꾸세요.
MODEL_PROJECT는 Serverless Inference 사용량 추적에 사용되는 OpenAI-Project 헤더를 설정합니다.
여기서 사용한 모델 ID는 예시일 뿐이며 반드시 이 모델을 사용할 필요는 없습니다. 사용 가능한 모델에서 도구 호출을 지원하는 모델을 선택하세요. 호환되는 다른 공급자나 직접 서빙하는 모델을 사용하려면 .env 파일의 모델 설정을 변경하세요. [INFERENCE-HOST]와 [MODEL-ID]를 사용 중인 공급자의 값으로 바꾸세요.
MODEL_API_KEY에 로드하고, CWSANDBOX_API_KEY는 설정된 상태로 두세요. 공급자가 프로젝트 헤더를 사용하지 않는다면 명령어를 실행하기 전에 .env 파일에서 MODEL_PROJECT를 제거하고, 상속된 MODEL_PROJECT 환경 변수가 있으면 설정을 해제하세요. 엔드포인트는 샌드박스에서 접근할 수 있어야 합니다. localhost는 사용자의 머신이 아니라 샌드박스 자체를 가리킵니다. 다른 API 프로토콜을 사용하려면 네이티브 평가기 옵션을 그에 맞게 조정해야 합니다.
이 레시피는 샌드박스 오퍼레이션에 CoreWeave 인증을 명시적으로 사용합니다. 샌드박스 토큰은 호스트에만 남아 있으며, 샌드박스를 생성할 때는 모델 구성과 추론 키만 주입됩니다. 작업 설정에는 사용자 인증 정보 값이 포함되지 않습니다.
사용자 인증 정보 처리에 관한 전반적인 지침은 환경 변수 및 시크릿을 참조하세요. 다운로드한 로그와 트레이스에는 작업 데이터와 공급자 오류 메시지가 포함될 수 있으므로 안전하게 관리하세요.
설정 확인 실행하기
샌드박스 하나로 단순한 작업 하나를 평가하세요.results-smoke/job-result.json 파일에서 완료된 시도 수와 오류가 발생한 시도 수를 확인하세요. 종료 상태가 0이면 오류 상태이거나 누락된 시도가 남아 있지 않다는 뜻입니다. 모델이 작업의 어설션을 통과했다는 의미는 아닙니다. 네이티브 agent/automationbench.json 내보내기에는 passed, score, 소요 시간, 토큰 사용량이 기록됩니다. 검증기는 passed와 score를 각각 pass와 partial_credit라는 이름의 Harbor 보상에 매핑합니다. job-result.json의 stats.evals 항목은 metrics 아래에 전체 시도에 대한 각 보상의 평균을 보고합니다. 보상이 없는 시도는 0으로 계산됩니다. reward_stats는 보상 값별로 해당하는 시도를 나열합니다.
에이전트는 api 도구 세트를 사용하고, 응답 단계는 최대 50개로 제한되며, 샌드박스당 한 번에 하나의 작업만 실행하고, 공급자의 기본 추론 설정을 따릅니다. 시도 재시도를 Harbor가 관리하도록 네이티브 전체 작업 자동 복구는 비활성화되어 있습니다. 단, 모델 클라이언트는 개별 요청을 내부적으로 재시도할 수 있습니다.
병렬성 높이기
설정 확인에 성공하면 먼저 일부 데이터로 작게 시작하세요:
점수가 부여된 세트를 평가하려면 해당 작업 목록을 선택하고, 할당량 범위 내에서 동시성 수준을 지정하세요.
용량 및 추론 한도 실패 재시도
이 레시피는 원래 시도 이후 최대 5회까지 재시도하도록 Harbor의RetryConfig를 설정하며, 재시도 간 대기 시간은 각각 30, 60, 120, 240, 300초입니다. 재시도 허용 목록에는 다음 예외가 포함됩니다.
SandboxResourceExhaustedErrorSandboxUnavailableErrorSandboxRequestTimeoutErrorEnvironmentStartTimeoutErrorApiRateLimitErrorApiUsageLimitError
ApiUsageLimitError를 재시도 대상에서 제외합니다. 이 레시피는 이 예외를 제외 집합에서 빼고 허용 목록에 추가합니다. 어댑터는 네이티브 평가기에서 발생하는 최종 추론 할당량 및 요청 속도 제한 메시지 중 인식 가능한 메시지를 해당 Harbor 예외에 매핑합니다. 이 매핑은 공급자의 오류 텍스트에 의존하므로, 공급자가 다른 형식으로 오류를 보고하는 경우 로그를 확인하세요.
용량이나 크레딧이 계속 부족한 경우에는 결국 용량이나 크레딧이 다시 확보되어야 합니다. 재시도 후에도 오류가 해결되지 않으면 스크립트는 0이 아닌 코드로 종료되며 마지막 오류를 유지합니다. 일반적인 어설션 실패, 응답 거부, 형식이 잘못된 도구 호출 JSON, 에이전트 실행 timeout은 재시도 정책을 트리거하지 않습니다.
Harbor는 재시도하기 전에 실패한 시도의 디렉터리를 삭제합니다. 레시피의 시도 종료 훅은 그 전에 각 시도를 결과 및 사용 가능한 로그와 함께 보관합니다. 점수를 보고할 때는 이러한 시도 기록을 보존하고 인프라 복구가 있었음을 밝히세요. 모델 실패를 더 나은 재시도 결과로 슬그머니 바꿔치기하지 마세요.
결과 및 느린 시도 검사
각 출력 디렉터리에는 다음 아티팩트가 포함됩니다.
작업 소요 시간과 토큰 사용량은 네이티브 내보내기에서 확인하세요. 어댑터는 Harbor의 집계 에이전트 토큰 및 비용 필드를 채우지 않습니다. 결과와 함께 모델, 엔드포인트, 벤치마크 리비전, 작업 목록, 추론 설정, 동시성, 재시도 정책을 기록하세요. run을 중단한 경우 내보낸 작업만 완료된 평가로 보고하고, 결과가 부분 결과임을 표시하세요.
step 수나 출력 토큰이 적더라도 작업 시간의 대부분을 모델 응답 시간이 차지할 수 있습니다. 지연의 원인을 샌드박스 리소스로 판단하기 전에
model_time_s와 tool_time_s를 비교하고 agent/eval.log 파일을 검사하세요. 공급자가 형식이 잘못된 도구 호출 JSON을 거부하는 것은 모델 또는 프로토콜 실패이며, 샌드박스 할당량이 소진되었다는 증거가 아닙니다. AutomationBench는 턴 도중에 중단된 롤아웃을 내보내기의 summary.aborted_tasks 필드에 나열합니다. 이러한 롤아웃의 작업별 errors 배열은 비어 있을 수 있으므로 작업 오류뿐 아니라 해당 필드와 로그도 확인하세요.
설정에는 11분의 timeout이 적용됩니다. 에이전트 실행에는 별도로 45분의 timeout이 적용되며, 그 안에서 실행되는 네이티브 평가 명령어에는 40분의 timeout이 적용됩니다. 각 샌드박스의 수명 한도는 1시간이며, timeout이 지나지 않았더라도 이 한도에 도달하면 샌드박스가 종료됩니다. 에이전트 실행 timeout은 이 정책에 따라 재시도되지 않습니다.
중지 및 정리
포그라운드 run을 중지하려면 Ctrl+C를 누르고 Harbor가 종료될 때까지 기다리세요. 이 작업은 해체(teardown) 시delete=True를 설정합니다. 프로세스가 강제 종료되었거나 정리 작업이 실패했다면, 남은 샌드박스를 삭제하기 전에 먼저 로컬 러너를 중지하세요. 그래야 러너가 대체 샌드박스를 생성하지 않습니다.
러너가 중지되면 러너의 출력 디렉터리에서 정리 작업이 완료되었는지 확인하세요.
results-smoke를 중단한 작업의 디렉터리로 바꾸세요. 스크립트는 기록된 샌드박스 ID만 삭제하고 각 샌드박스의 종료 상태를 출력합니다. 이미 존재하지 않는 샌드박스는 not_found로 보고됩니다. 종료 코드가 0이 아니면 삭제 또는 종료 상태 확인에 실패했다는 뜻이므로 원인을 조사하세요. 호스트 프로세스가 사라지더라도 샌드박스는 설정된 수명 한도를 넘어 실행되지 않습니다.
검증 범위
레시피 개발 과정에서 네이티브 평가기는 Serverless Inference의openai/gpt-oss-120b를 사용해 8개의 병렬 CPU 샌드박스에서 공개 작업 800개 중 730개의 결과를 내보냈습니다. 이 run은 완료 전에 중단되었으므로 해당 결과를 벤치마크 점수로 볼 수는 없습니다. Harbor 재시도 스케줄링은 별도로 검증했습니다. 검증에는 SandboxResourceExhaustedError 주입, 30초 백오프, 그리고 실제로 완료되어 결과를 내보내고 정리까지 마친 작업 1개가 포함되었습니다. 이 레시피는 초기 실험에서 사용한 환경 훅을 공개 SDK 호출 기반의 BaseEnvironment 구현으로 대체합니다. 이 리팩터링은 오프라인 테스트로 검증되었지만 실제 서비스 환경에서는 아직 실행되지 않았습니다. 높은 Harbor 동시성으로 전체 데이터셋을 실행하는 경우도 아직 검증되지 않았습니다.
오프라인 테스트와 선택적으로 수행할 수 있는 통제된 재시도 확인 방법은 레시피 README를 참조하세요.