코딩 에이전트 점수를 믿기 전에 네거티브-컨트롤 슬라이스를 추가하세요

팀원이 점심 식사 직후 채널에 스크린샷을 떨어뜨립니다. 12개의 작업입니다. 12개의 녹색 체크 표시가 있습니다. 캡션은 주간 업데이트에 백분율을 붙여넣으라고 요청합니다.

슬라이드를 만지기 전에 테스트 스위트를 엽니다. 세 가지 프롬프트는 숨겨진 테스트가 호출하는 함수 이름을 명시합니다. 하나의 피처 파일에는 여전히 예상 반환 값을 명시하는 주석이 포함되어 있습니다. 또 다른 작업은 모델이 학습 과정에서 보았을 가능성이 있는 공개 튜토리얼의 거의 복사본입니다.

완벽한 점수는 그 모양 자체로 결과가 아닙니다. 그것은 '하네스 냄새(harness smell)'입니다. 이 워크스루는 헤드라인 숫자가 누수, 깨진 단언(broken assertion), 또는 에이전트가 거부했어야 할 작업을 숨기는 것을 막기 위해 네거티브-컨트롤 슬라이스를 추가하는 방법을 보여줍니다.

하나의 백분율이 무엇을 숨기는지

코딩 에이전트 점수는 비율입니다. 분자: 통과로 표시한 시도 횟수. 분모: 계산하기로 선택한 시도 횟수. 어느 한쪽을 변경하면 모델이 변하지 않았더라도 백분율은 움직입니다.

공개된 글들은 같은 유혹을 반복합니다. 누군가 작은 비공개 세트에서 오류가 없다고 보고하고, 그 숫자는 방법론보다 더 빠르게 퍼집니다. 당신은 그 게시물을 법정 공방으로 만들 필요가 없습니다. 당신에게 필요한 것은 자체 스위트에 대한 규칙입니다. 네거티브-컨트롤 슬라이스가 옆에 점수화되기 전까지는 해결 가능한 슬라이스 통과율을 인용해서는 안 됩니다.

그 규칙은 방법론적입니다. 그것은 제품 주장이 아니며, 리더보드도 아닙니다.

실제로 실행할 세 가지 슬라이스

재실행하기에 충분히 작은 스위트를 유지하세요. 8개에서 16개의 작업이면 하네스를 디버깅하기에 충분합니다. 벤더를 순위 매기기에는 충분하지 않습니다. 나중에 아무도 그 수치를 홍보하지 않도록 보고서에 이 한계를 명시하세요.

세 개의 슬라이스를 사용하고, 그것을 느낌이 아닌 데이터로 저장하세요.

Solvable. 실제 버그 또는 작은 기능 개선을 의미합니다. 프롬프트에 패치, 테스트 이름 또는 예상 결과가 포함되어 있지 않습니다.
Negative control (네거티브 컨트롤). 에이전트가 통과해서는 안 되는 작업입니다. 예시: 저장소(repo)가 이미 명세와 일치함, 요청된 파일이 존재하지 않음, 또는 지침이 테스트와 모순됨. 여기서 통과하면 거짓 성공(false pass)입니다.
Canary (캐나리). solvable task와 같은 형태를 가지지만, 올바른 패치에 절대 나타나지 않아야 하는 고유 문자열을 추가한 것입니다. 만약 모델이 캐나리를 방출하면, 그 시도를 성공으로 간주하지 않고 오염된 것으로 처리합니다.

각 슬라이스(slice)별로 점수를 매깁니다. 이들을 하나의 마케팅 비율로 평균 내지 않습니다.

1단계: 태스크 카드 고정하기 (Freeze the task card)

모델을 호출하기 전에 작업당 하나의 JSON 객체를 작성해야 합니다. 이 카드가 데이터셋입니다. 필드가 누락된 경우, 검사기(checker)는 추측하는 대신 작업을 거부합니다.

{
  "id": "neg-03",
  "slice": "negative",
...

solvable 카드는 `

단계 4: 지표를 올바른 순서로 읽기

다음 네 가지 숫자를 이 순서대로 보고, 앞선 수치 중 하나라도 문제가 있다면 그 자리에서 멈추세요.

Canary 히트 카운트. 히트가 있다는 것은 프롬프트, 로그 또는 스코러가 마커를 아티팩트에 유출했다는 의미입니다. 하네스를 수정하세요. 패스율을 인용하지 마십시오.
네거티브 슬라이스에서의 거짓 패스 카운트. 패스가 나왔다는 것은 테스트가 약하거나, 에이전트가 제약 조건을 무시했거나, 해결 가능한 작업을 네거티브로 레이블링했다는 의미입니다. 이 세 가지 모두 측정 버그입니다.
기권율(Abstain rate). 불가능한 작업에 대해 절대 기권하지 않는 에이전트는 더 도움이 되는 것이 아닙니다. 임의의 diff를 만들어내려고 합니다. 기권 횟수를 그 자체의 결과로 기록하세요. 이를 실패에 포함시키면서 그렇게 말하지 마십시오.
해결 가능 패스율(Solvable pass rate). 이제야 보고합니다. 이 실행 ID에 대해 passes / solvable_n으로 보고하십시오. 엔벨로프 파일(envelope file)을 첨부하세요. 이것을 정확도(accuracy)라고 부르지 말고, 다른 재시도 예산(retry budget)을 사용한 실행과 비교하지 마십시오.

주간 업데이트에 사용할 문장이 필요하다면, 다음 형식을 사용하십시오: "이 실행 ID에서 거짓 패스 횟수와 Canary 히트가 모두 0이었을 때 해결 가능 패스율은 X/Y였습니다. N은 모델 순위를 매기기에는 너무 작습니다." 보고서에서 X와 Y를 채우세요. 검사기가 출력할 때까지 비워두십시오.

무료 실행이 적합한 경우

이 루프를 노트북에서 실행할 수 있습니다. 또한, SSH 세션이 끊어져도 실행이 중단되지 않도록 배치(batch)를 무료 서버에 파킹하고, 하네스를 디버깅하는 동안 유료 할당량을 소모하지 않도록 모델을 무료 액세스로 호출할 수 있습니다.

공개: 이 기사는 MonkeyCode의 제품 홍보의 일환으로 준비되었습니다.

MonkeyCode는 이 초안이 다루도록 요청받은 오픈 소스 프로젝트입니다. 운영자는 단지 두 가지 가용성 주장만을 제공했습니다: 무료 모델 액세스, 그리고 무료 서버 옵션. 본 기사에서는 모델 이름, 토큰 할당량, 머신 크기 또는 기간을 명시하지 않습니다. 그러한 세부 사항들은 변합니다. 배치 작업을 계획하기 전에 현재 프로젝트 문서를 읽고, 기억이나 이전 게시물에서 얻은 쿼터를 인용하지 마십시오.

하네스 디버깅에는 무료 경로를 사용하고, 출시 숫자를 위해 사용하는 것이 아닙니다. 현재 가지고 있는 모든 무료 모델 액세스를 사용하여 후보 패치를 생성하십시오. 각 시도는 하나의 JSONL 행으로 저장합니다: task_id, verdict, patch, stdout, attempt. 서버에서 slice_scorer.py를 실행하거나, JSONL 홈을 복사하여 로컬에서 실행하십시오. 원본 파일을 보관하십시오. 파일 없이 제시된 백분율은 소문입니다.

만약 그러한 액세스가 없다면, 방법론의 어떤 것도 그것에 의존하지 않습니다. 검사기는 순수한 Python으로 되어 있습니다. 규율(discipline)은 호스트가 아니라 방법론의 산물입니다.

이 숫자가 마케팅이 아닌 이유

마케팅은 하나의 수치, 상승하는 화살표, 그리고 제목에 모델 이름을 원합니다. 이 방법론은 의도적으로 그러한 형태를 거부합니다.

더러운 네거티브 슬라이스(negative slice)가 있는 해결 가능한 통과율은 깨진 테스트, 유출된 답변, 또는 운 좋은 재시도와 양립 가능합니다. 이를

여덟 가지 작업으로는 순위(ranking), 고객에게 보여줄 신뢰 구간(confidence interval), 또는 코딩 능력에 대한 주장을 뒷받침할 수 없습니다. 이 검사기는 코드를 컴파일하지 않습니다. 여전히 verdict를 생성하는 실제 테스트 명령이 러너(runner)에 필요합니다. 이 초안에 대해 모델이 점수를 받은 적이 없으므로 인용할 측정된 통과율도 없습니다.

시간 초과(Timeouts), 불안정한 테스트(flaky tests), 네트워크 호출은 여전히 verdict를 변경시킬 것입니다. 이를 엔벨로프(envelope) 안에 고정하거나, 점수가 흔들리는 것(score jitters)을 받아들이십시오.

누가 사용하지 말아야 하는가

통계적으로 유의미한 비교가 필요하다면 이 방법을 건너뛰세요. 당신에게 필요한 것은 점심 식사 크기의 조각이 아니라, 더 크고 사전 등록된(pre-registered) 스위트와 고정된 숨겨진 세트입니다.

코드가 안전에 매우 중요한 경우에도 건너뛰세요. JSONL 검사기는 보안 검토(security review), 라이선스 검토(license review), 또는 diff를 읽는 것을 대체할 수 없습니다.

광고에서 단일 백분율을 인용할 계획이라면 이 또한 건너뛰세요. 이 검사기는 그 문장을 보류하도록 설계되었습니다. 이에 맞서 싸운다는 것은 측정값이 아니라 슬로건을 원했다는 의미입니다.

다음 단계

직접 관리하는 리포지토리(repo)에서 해결 가능한 네 가지 작업을 선택하세요. 통과해서는 안 되는 네 가지 부정 제어(negative controls)를 작성하십시오. 캐나리아(canaries) 두 개를 추가하세요. 엔벨로프를 고정시키세요. 검사기를 실행하세요. 만약 headline_allowed가 false라면, 모델을 언급하기 전에 스위트를 수정하세요.

첫 번째 노이즈가 많은 배치(noisy batch)를 보관할 장소가 필요할 때, 무료 MonkeyCode 서버 세션만으로도 JSONL 파일을 온전하게 유지하면서 반복 작업을 할 수 있습니다. 현재 제한 사항은 직접 확인하고, 그 다음 보고서를 작업 옆에 아카이브하세요. 아카이브가 결과입니다. 백분율은 선택사항입니다.