Benchmark가 측정한 건 모델이 아니라 채점기였다 — Honcho/Hindsight 3 라운드 측정 후기

이미지
내 환경(Hermes)의 메모리 provider 두 개(Honcho·Hindsight)를 3 라운드에 걸쳐 비교했다. 1차 10/10 만점, 2차 7점대, 3차 4점대로 점수가 압축됐다. 처음엔 “task가 어려워져서”라고 봤다. 직접 답변을 보니 다른 이유였다. 요약 : 점수 10 → 7 → 4 압축의 진짜 원인은 task 난이도가 아니라 regex scorer false positive. approval_boundary 3.5점 답변이 manual review 5.0이었고, 5.0점 답변엔 risky implications가 남아 있었다. wrapper guardrail 패치까지 진행한 후기. 이런 적 있다면 글이 도움이 된다 도구·모델 비교 글에서 점수가 비슷하게 나와 어느 게 더 나은지 판단 못 한 적이 있다. LLM 답변 채점할 때 regex나 키워드 매칭이 진짜 평가를 한다고 믿어본 적이 있다. benchmark가 모델 약점이 아니라 측정 기구의 약점을 드러내는 건 처음 봤다. 측정 setup — Hermes 안에서 Hermes는 내 1인 운영 자동화 환경이다. 컴포넌트는 다음과 같다. ALIVE : canonical source-of-truth. 프로젝트 상태·결정·산출물 기록 Hermes core memory : compact durable preferences Honcho lab profile : Plastic Labs의 오픈소스 메모리 라이브러리. user-agent modeling, boundary discipline 실험용 Hindsight lab profile : semantic recall, entity graph 실험용 (내 환경 자체 구성) default Discord gateway : 사용자 I/O 메인 채널 Honcho는 stateful agent용 외부 오픈소스다. 내 환경에서는 lab profile로만 띄워두고 default gateway는 별도 inference로 운영한다. 둘 다 ...

하네스 엔지니어링 측정 2편 — Claude에 AGENTS.md 명시 인용했더니 fail-fast가 강해졌다

1편(어제)에서 N=1로 측정해서 결론을 냈다. “Codex가 fail-fast 약하다”가 아니라 “AGENTS.md 비우면 Codex도 Claude도 똑같이 약하다”였다. 지적이 들어왔다. N=1은 우연일 수 있다. Claude에 AGENTS.md 명시 인용을 직접 해본 적은 없었다. 12회 측정해서 다시 확인했다. 결론은 더 단단해졌다. 그리고 1편이 놓친 변수 하나가 새로 보였다. 요약 : Codex × Claude × 하네스 0/강제 4 condition을 각 3회씩 12회 측정. 모델 효과는 거의 0(가로축 1.0 vs 1.0, 2.83 vs 2.5), 하네스 효과는 큼(세로축 1.0 → 2.5+). Claude도 AGENTS.md를 prompt에 명시 인용하면 fail-fast 1.0 → 2.5로 올라간다. 단 1편의 Claude 채점 “중”은 prompt position 효과(메인 세션 system prompt 자동 로드)였을 가능성이 새로 보였다. 1편이 명시한 5가지 한계 중 통제한 3가지 측정 1편 본문 끝에 한계 5가지를 적었다. 그 중 2편에서 통제 가능한 것은 3가지였다. Sampling 우연 미통제 (N=1) → 12회 측정으로 분산 확인 Prompt position 미분리 → C3 격리 환경 추가로 부분 분리 Claude에 AGENTS.md 명시 인용 미측정 → C4 condition으로 직접 측정 나머지 2가지(컨벤션 vs 코드 품질, 일반화)는 이번에도 미해소다. 측정 setup, 4 condition × 3회 = 12회 같은 명세 verify_published_post() 를 4 condition으로 각 3회씩 측정했다. Condition 모델 하네스 C1 Codex 없음 (AGENTS.md 비움) C2 Codex AGENTS.md 자동 로드 C3 Claude spec만, 격리 Task agen...