모델을 학습시키지 말고, 하네스(Harness)를 진화시키세요.

저는 Hugging Face에서 작성한 아주 훌륭한 블로그 포스트를 읽었습니다. 그들은 어려운 법률 에이전트 벤치마크(benchmark)에서 0%의 점수를 기록한 동결된(frozen) 오픈 모델을 가져와서, 가중치(weights)는 그대로 둔 채 자동화된 루프(loop)를 통해 그 주변의 코드만을 다시 작성하게 했습니다.

그 코드 레이어가 바로 하네스(harness)입니다. 즉, 모델에 컨텍스트(context)를 제공하고, 도구 호출(tool calls)을 실행하며, 실행이 언제 종료될지를 결정하는 런타임 래퍼(runtime wrapper)인 것입니다.

루프가 완료되었을 때, 이 시스템은 해당 벤치마크의 주요 지표에서 Sonnet 4.6과 거의 대등한 성능을 보여주었으며, 작업당 비용은 약 7배 더 낮았습니다. 가중치는 전혀 변경되지 않았습니다.

이러한 이득은 모델이 실패하고 있었던 지점 덕분에 발생했습니다. 심사관(judge)은 정확히 요청된 파일명으로 올바른 위치에 저장된 파일만을 채점하는데, 모델은 법률 분석은 계속 올바르게 수행하면서도 파일명을 잘못 지정하거나, 임시 폴더(scratch folder)에 저장하거나, 혹은 아예 쓰지 않는 실수를 반복하고 있었습니다.

따라서 0%라는 점수는 법률적 추론(legal reasoning)을 측정하고 있었던 것이 아니었습니다. 그것은 하네스(harness)를 측정하고 있었던 것입니다.

해당 레이어를 수동으로 튜닝하는 것은 느리고 모델마다 특화되어야 하기에, 그들은 이를 자동화했습니다. Claude 제안자(proposer)가 반복(iteration)마다 정확히 하나의 메커니즘을 추가하고, 외부 루프(outer loop)는 그것이 현재의 최고 기록을 명확히 경신할 때만 유지하도록 하여, 수락된 메커니즘들이 복리로 쌓이게 합니다.

이 루프가 발견한 사실은 에이전트(agents)가 실제로 어디에서 실패하는지에 대해 많은 것을 시사합니다.

→ 가장 큰 단일 이득은 지능이 아니라 파일 처리(file handling)였습니다. 결과물을 심사관이 기대하는 정확한 위치에 배치하는 자동화된 단계는, 추가적인 모델 토큰(tokens) 소모 없이 모든 프롬프트(prompt) 변경보다 더 나은 성과를 냈습니다.

→ 코드 수정 사항은 모델 간에 전이(transferred)되었지만, 프롬프트 플레이북(prompt playbooks)은 그렇지 않았습니다. 동일한 하네스는 같은 계열의 더 작은 모델 성능을 14포인트 끌어올렸지만, 튜닝된 프롬프트는 이미 수행할 수 있었던 작업을 수행하는 다른 모델 계열에 오히려 악영향을 주었습니다.

→ 하네스(harness)는 그 무엇보다 중요했습니다. 동일한 모델, 동일한 심사관, 동일한 작업 조건에서 5개의 서로 다른 하네스를 사용했을 때 점수는 3.5%에서 80.1% 사이를 기록했습니다.

이러한 이득은 결국 정체기에 도달하며, 남은 실패 지점들은 실제 역량의 격차(capability gaps)처럼 보입니다. 어느 시점에 이르면 래퍼(wrapper)의 기술은 한계에 다다르고, 모델이 직접 작업을 수행해야만 합니다.

하지만 교훈은 유효합니다. 벤치마크 점수는 모델과 그 하네스(harness)를 함께 측정하며, 하네스가 고정되기 전까지는 어느 쪽이 실패했는지 알 수 없습니다.

이 글을 읽어보시기를 강력히 추천합니다: https://t.co/3ZIeKhsngn

또한 저는 얼마 전 에이전트 하네스 엔지니어링(agent harness engineering)에 대한 심층 분석 글을 작성했습니다. 여기에는 오케스트레이션 루프(orchestration loop), 도구(tools), 메모리(memory), 컨텍스트 관리(context management), 그리고 상태가 없는(stateless) LLM을 유능한 에이전트로 만드는 모든 요소가 포함되어 있습니다.

해당 기사는 아래에 인용되어 있습니다.