AI4AI 테스트 타임: 하네스로 강한 모델의 능력을 약한 모델에 전수하기

Who Should Read

작고 싼 모델을 쓰는데 정확도가 모자라 프롬프트·파이프라인을 손보고 있는 LLM 앱 개발자

Core Mechanics

• 강한 모델이 약한 모델용 하네스를 짠다
  • 파인튜닝 없이, 강한 builder 모델이 라우팅·프롬프트·코드 풀이기를 만들어 약한 target 모델을 돕는다.
  • builder는 데이터 5%(195개)만 보고 여러 번 고쳐 가며 하네스를 만든다.
• 핵심은 추론을 코드로 빼는 것이다
  • 흔들리는 추론을 결정적 코드로 넘기고, 벤치마크별 라우팅과 답 형식 강제를 넣은 하네스가 효과적이었다.
  • 더 길게 추론시키거나 여러 번 샘플링하는 것은 주된 원인이 아니었다.
• builder 품질이 플랫폼보다 중요하다
  • Cursor, Claude Code, GPT Codex 중 어디서 짜느냐의 차이는 작았다.
  • builder의 reasoning effort를 올리면 하네스 품질이 단조롭게 좋아졌다.
• 검증을 더 자주 돌려도 소용없다
  • 검증 횟수와 최종 정확도는 거의 무관했다.
  • 5% 검증 점수는 전체 점수와 거의 일치했다.
• 약한 모델일수록 이득이 크고 강한 모델엔 역효과도 난다
  • 정확도가 낮아 개선 여지(headroom)가 클수록 향상폭이 컸다.
  • 이미 강한 Gemini-3.5-flash에서는 일부 과제에서 오히려 점수가 내려갔다.

Evidence

• 평균 정확도 0.49에서 0.91로
  • GPT-5.4-mini 무스캐폴드 0.488 대비 최고 하네스(GPT-5.5, GPT Codex) 0.912, +0.423.
  • Theory-of-Mind 4개 벤치마크 3900문항 기준이며, 57개 실행 평균은 0.763(+0.275)이고 전부 기준선을 넘었다.
• 더 큰 모델보다 낫다
  • GPT-5.4 무스캐폴드는 0.619, 하네스를 붙인 GPT-5.4-mini 최고치는 0.912.
  • 사람이 만든 UserHarness는 0.939로 여전히 약간 높다.
• effort 올리면 단조롭게 상승
  • Opus-4.7 builder는 low 0.711, medium 0.793, high 0.807, x-high 0.856.
  • x-high와 high 비교는 p=0.013이다.
• 결정적 코드 비중과 정확도
  • 코드로 직접 답한 비율과 정확도의 Pearson r=0.72(n=18).
  • 최고 하네스는 기준선 오답 1717개를 고치고 정답 105개를 깼다(McNemar, 3900문항).

How to Apply

• 오늘 하네스 기본기 점검하기
  • 지금 쓰는 약한 모델 호출에 temperature 0, 답 형식 강제 파싱, 유형별 라우팅이 있는지 확인하고 없으면 넣는다.
  • 논문 하네스의 거의 전부(95~100%)가 이 기본기를 썼다.
• 강한 모델에게 하네스 코드를 짜게 하기
  • 라벨이 있는 검증 샘플 5% 정도를 주고 가장 강한 모델을 높은 reasoning effort로 돌려 라우터·파서·규칙 코드를 만들게 한다.
  • 검증 평가는 5회 안팎으로 제한하고 원문의 지시 파일 형식을 참고한다.
• 독립 하네스 2~3개 만들어 최고 선택하기
  • 같은 설정으로 여러 번 만들어 검증 점수가 가장 높은 것을 쓴다.
  • 결정적 풀이기 방식은 규칙 하나가 틀려도 점수가 크게 흔들리므로 검증에서 걸러야 한다.
• 이미 강한 모델엔 선택적으로 적용하기
  • 하위 과제별 기준선 정확도를 먼저 재고 개선 여지가 큰 곳에만 규칙을 넣는다.
  • 기준선이 높은 과제에 넣으면 정답을 깨뜨릴 수 있다.

Try It

# Claude Code 또는 Claude/ChatGPT에 붙여넣기 (논문 방법의 간이 버전)

너는 하네스 builder다. 목표: 약한 모델이 아래 과제를 더 잘 풀도록 추론 시점 하네스를 설계한다. 모델 가중치는 바꾸지 않는다.
과제 설명: {{과제 설명}}
라벨 있는 검증 샘플: {{검증 샘플 20~50개}}

규칙:
1. 샘플을 보고 유형별로 분류한 뒤 코드로 결정적으로 풀 수 있는 부분을 찾아라.
2. 유형별 라우팅, 프롬프트 템플릿, 답 형식 강제 파서를 만들어라.
3. temperature 0을 쓰고, 모델 호출이 꼭 필요한 항목만 호출하라.
4. 검증 답을 하드코딩하지 마라.

출력: 파이썬 코드, 설계 이유, 예상되는 실패 유형.

이어서 해 볼 것: 실패한 샘플을 붙여 넣고 하네스를 수정하게 하라. 총 5회 안팎으로 제한하라.

Terminology

관련 논문

• 같은 시뮬레이션, 다른 근거: 도구 출력을 파일로 넘기면 LLM 에이전트 정확도가 어디서 깎이나

  긴 툴 출력을 파일로 넘기자 GPT-5.1은 정확도 11.3%p 하락, 정식 출력 지정하니 회복

• 가짜 뉴스가 진짜 폭락을: LLM 트레이딩 에이전트 대상 정보 주입 공격

  가짜 헤드라인 한 줄로 LLM 트레이딩 에이전트 62%를 조종했다(프롬프트 주입은 14%)

• Harness Engineering 101: LLM은 뇌, harness는 몸

  에이전트는 JSON 배열을 관리하는 루프이고, 16개 챕터로 직접 만들어 본다

• Harness²: 에이전트 harness를 스스로 고쳐 쓰는 재귀 최적화 프레임워크

  모델은 고정하고 harness를 재귀로 고쳤더니 벤치마크 점수가 최대 11.8%p 올랐다

• 해고된 Savannah 경찰관, ICE 요원 남편에게 Flock 계정 공유

  경찰관이 Flock 계정을 남편(ICE 요원)에게 공유했고, 감사에서 983건 검색이 드러나 해고됐다

• tmux와 Claude Code: 세션, send-keys, 그리고 한계선

  tmux로 Claude Code 여러 개를 돌리면 편하지만 에이전트 4개쯤에서 한계가 온다

• Hybrid Reasoning Agents: 잠재 공간에서 생각하고 텍스트로 행동하는 LLM 에이전트

  잠재 공간 추론과 텍스트 도구 호출을 섞었더니 성능 10.4%↑, 토큰 최대 54.7%↓