원문은 tengli.dev에 게시되었습니다.

mcpgrade에 LLM 기반의 평가(eval) 기능을 추가했을 때, 첫 번째 실제 실행 결과는 마치 특종처럼 보였습니다. 완벽한 정적 점수(static score)를 가진 서버인 context7이 도구 선택(tool selection)에서 62%의 실패율을 기록한 것입니다. 모델에게 두 개의 도구 카탈로그를 보여주었을 때, 8개의 작업 중 5개에서 "잘못된" 도구를 선택했습니다.

만약 제가 그 수치를 그대로 출시했다면, 그것은 틀린 결과였을 것입니다. 단순히 조금 틀린 것이 아니라, 체계적이고 불공정하게 틀린 것이었습니다. 이 포스트는 제가 어떻게 그 오류를 잡아냈는지에 관한 이야기입니다. 왜냐하면 이 실패 모드(failure mode)는 현재 사람들이 구축하고 있는 대부분의 에이전트 벤치마크(agent benchmarks)에도 일반화될 수 있기 때문입니다.

설정 (The setup)

mcpgrade의 --eval 모드는 다음과 같이 작동합니다: 서버의 도구 카탈로그를 읽고, 현실적인 단일 단계 작업(예: "장애가 논의된 Slack 채널을 찾으세요")을 합성하며, 모델에게 전체 카탈로그를 보여준 뒤 세 가지를 측정합니다. 즉, 올바른 도구를 선택하는지, 유효한 인자(arguments)를 채우는지, 그리고 어떤 도구로도 처리할 수 없는 작업을 올바르게 거부(refuse)하는지 측정합니다.

세 개의 실제 서버를 대상으로 한 1라운드 실행에는 약 12센트가 소요되었으며, 다음과 같은 결과가 나왔습니다:

정적 점수가 매우 우수한 두 서버가 실제 테스트에서는 실패하는 것처럼 보였습니다. 정적 분석(static analysis)이 가치가 없거나, 아니면 평가(eval)가 고장 났거나 둘 중 하나였습니다.

평가(eval)가 고장 났다

모든 "실패(miss)"는 하나의 원인으로 추적되었습니다. Slack의 post_message는 thread_ts를 필요로 하는데, 이는 get_channel_history를 이전에 호출해야만 얻을 수 있는 값입니다. context7의 get-library-docs는 resolve-library-id에서 나오는 라이브러리 ID가 필요합니다. 이것들은 **파이프라인 도구 (pipelined tools)**입니다. 즉, 필요한 인자가 다른 도구에 의해 생성됩니다.

제 작업 합성기(task synthesizer)는 그 사실을 몰랐습니다. 스레드 타임스탬프(thread timestamp) 없이 "장애에 관한 스레드에 답장하세요"와 같은 작업을 생성했습니다. 모델은 매우 합리적으로 (스레드를 찾기 위해) 먼저 get_channel_history를 선택하거나, 혹은 작업을 거절했습니다. 하지만 제 채점기(grader)는 이 두 가지 선택 모두를 오답으로 처리했습니다.

모델은 혼란스러워하지 않았습니다. 모델이 맞았습니다. 벤치마크(benchmark)가 올바른 다단계 추론 (multi-step reasoning)을 실패로 채점하고 있었던 것입니다. 그리고 메모리(memory)의 93% 점수가 내내 모든 것을 말해주고 있었습니다. 해당 모델의 도구(tools)들은 단일 단계(single-step) 방식이었기에 점수가 괜찮게 나왔던 것입니다.

해결책은 합성 프롬프트 (synthesis prompt)에 하나의 제약 조건을 추가하는 것이었습니다: 모든 작업은 요구되는 모든 매개변수 (parameter)에 대해 구체적인 값을 포함해야 한다. 예를 들어, "#incidents 채널의 thread 1721581200.123456에 답장하세요"와 같이 구성하면, 이제 단일 시도 선택 (single-shot selection)이 공정한 질문이 됩니다. 2라운드 결과: context7 38% → 100%, slack 54% → 100%.

만약 당신의 에이전트 벤치마크 (agent benchmark)가 실제 사용자는 문제없이 사용하는 도구들에 대해 유능한 모델이 실패하는 모습을 보인다면, 당신이 다단계 도구 (multi-step tools)에 대해 단일 단계 질문 (one-step questions)을 던지고 있는 것은 아닌지 확인하십시오. 제 경험상, 자체 제작된 대부분의 "도구 선택 정확도 (tool selection accuracy)" 수치들은 이 버그로 인해 실패율이 조용히 부풀려져 있습니다.

3라운드: 차별화가 되는가?

모두에게 100%를 주는 벤치마크는 장식에 불과합니다. 그래서 3라운드에서는 수정된 평가 (eval)를 firecrawl에 적용했습니다. firecrawl은 26개의 도구를 가지고 있으며, 제 36개 서버 스캔 결과에서 가장 낮은 정적 점수를 기록했던 대상입니다. 만약 평가가 실제 무언가를 측정하고 있다면, 무질서한 카탈로그는 더 낮은 점수를 받아야 합니다. 그리고 실제로 두 가지 특정 방식으로 낮은 점수를 받았습니다:

1. 선택 오류가 정적 규칙 (static rules)이 이미 지적했던 명명 충돌 (naming collisions) 지점에서 정확히 발생했습니다. 84%의 선택 정확도를 보였는데, 나머지 16%의 오류는 무작위가 아니었습니다: extract↔scrape, agent_status↔check_crawl_status, feedback↔search_feedback — 이는 정적 규칙(N002, C001)이 이름과 설명만으로 이미 지적했던, 혼동하기 쉬운 동일한 쌍들이었습니다. 이것이 제가 가장 원했던 결과입니다: 정적 린트 (static lint)가 실제 모델의 혼란을 예측한다. 저렴하고 무료이며 10초면 끝나는 스캔이 LLM 평가 (eval)와 동일한 실패 지점을 찾아낸 것입니다.

2. 거절(Refusal)의 붕괴. 의도적으로 범위를 벗어난(out-of-scope) 작업이 주어졌을 때, 모델은 작고 잘 문서화된 카탈로그에서는 100% 정확하게 거절했습니다. 하지만 Firecrawl의 26개 퍼지 도구(fuzzy tools)에 대해서는 **50%**의 확률로 거절에 실패했습니다. 절반의 경우, 모델은 그럴듯하게 들리는 도구를

둘째로, 더 미묘한 문제입니다: 제가 만든 합성 태스크(synthetic tasks)가 그것들을 생성한 스키마(schemas)를 치켜세울 수 있다는 점입니다. 합성기(synthesizer)는 태스크를 작성하기 위해 카탈로그를 읽습니다. 따라서 잘못 작성된 카탈로그는 그 자체의 잘못된 어휘로 표현된 태스크를 생성하게 됩니다. 해결책은 홀드아웃 저작(held-out authoring) 방식입니다. 즉, 실제 통합 실패(integration failures)로부터 의도(intents)를 도출하고, 도구 이름(tool names)을 전혀 보지 않는 단계를 거쳐 이를 의역(paraphrase)한 뒤, 어떠한 설명(descriptions)도 건드리기 전에 테스트 분할(test split)을 고정하는 것입니다.

두 문제 모두 현재 리포지토리의 추적된 이슈(tracked issues on the repo)로 등록되어 있습니다. 이것이 바로 단순히 리더보드(leaderboard)만 공개하는 대신 방법론(methodology)을 공개하는 이유입니다. 독자들은 마치 코드를 디버깅하듯 여러분의 벤치마크(benchmark)를 디버깅할 수 있기 때문입니다.

전체 원시 수치(raw numbers)와 방법론은 리포지토리의 docs/eval-calibration.md에서 확인할 수 있습니다. 만약 에이전트 벤치마크를 구축하면서 다른 체계적인 불공정 패턴(systematic unfairness patterns)을 발견했다면, 알려주시기 바랍니다. 이슈(issue)를 생성해 주세요.

저는 대형 기술 기업에서 프로덕션 AI 에이전트 통합(AI agent integrations) 업무를 수행하고 있으며, mcpgrade는 개인 프로젝트입니다. 평가는 모든 OpenAI 호환 엔드포인트(OpenAI-compatible endpoint)에서 실행됩니다. 본인의 API 키를 직접 사용하세요.