모든 AI 평가 (eval) 도구는 당신의 에이전트 (agent)가 얼마나 뛰어난지 말해줄 것입니다. 하지만 그중 거의 어느 것도 누가 결정했는지는 말해주지 않습니다.

그 수치가 어떻게 생성되는지를 살펴보기 전까지는 이것이 사소한 차이처럼 들릴 수 있습니다. 당신은 에이전트 (agent)를 실행하고, 출력값에 대해 두 번째 모델을 실행합니다. 그러면 두 번째 모델은 87%라고 말하고, 그 87%는 대시보드에, 이사회 보고서에, 그리고 어떤 모델을 출시할지에 대한 결정에 반영됩니다. 아무도 그 87%가 한 모델이 다른 모델에 대해 내린 의견이라는 사실을 기록하지 않습니다. 그 숫자는 실제로 증명된 숫자와 똑같은 옷을 입고 나타납니다.

우리는 SigNoz 해커톤의 에이전트 (Agents) 부문을 위해 Gradebook이라는 것을 만들었습니다. 이 모든 것의 밑바탕에 깔린 단 하나의 규칙은 모든 점수가 그 권위가 어디에서 왔는지를 명시하며, 헤드라인 수치는 증명된 점수만을 집계한다는 것입니다.

정답이었음을 알 수 있는 세 가지 방법

Gradebook의 점수는 정확히 하나의 출처를 가지며, 이는 텔레메트리 (telemetry) 상에 augmentloop.grade.source로 찍힙니다:

math는 검증기 (checker)가 증명 가능한 정답을 계산하여 비교했음을 의미합니다. 우리의 연습용 세계 (toy world)에서는 모델이 교차로 사이의 경로를 선택하면, Dijkstra 최단 경로 계산이 무엇이 올바른 경로였는지 말해줍니다. 여기에는 해석이 개입되지 않습니다. 그것은 사실입니다.

reality는 두 번째의 독립적인 확인이 수학 (math)이 묻는 것과는 다른 질문을 통해 그것을 증명했음을 의미합니다. 즉, 선택이 증명 가능한 최단 경로였는지 여부가 아니라, 여정이 실제로 허용 오차 범위 내에 도착했는지 여부를 확인하는 것입니다. 이 또한 사실이며 독립적인 사실인데, 이는 우리가 예상했던 것보다 더 중요하다는 것이 밝혀졌습니다.

ai_judge는 다른 모델이 점수를 매겼음을 의미합니다. 그것은 의견입니다. 스키마 (schema)에는 이를 위한 자리가 마련되어 있으며, 이는 헤드라인 수치에 절대 영향을 미치지 않습니다.

필터는 문서의 한 단락이 아니라 쿼리 (query) 안에 존재하며, 바로 이 점이 그것을 실질적으로 만듭니다. 누구나 README에 "우리는 평가를 진지하게 받아들입니다"라고 쓸 수 있습니다. 하지만 대시보드 쿼리에 있는 augmentloop.grade.source = 'math'는 당신이 직접 확인할 수 있는 실체입니다.

판사에게 투표권을 주지 않는 이유

AI 판사의 점수를 제외한 것은 취향의 문제에서 시작되었으며, 우리는 그것이 취향이라는 점을 스스로에게 솔직하게 인정했습니다. 그러다 관련 문헌들을 찾아보았고, 그것은 더 이상 단순한 취향의 문제가 아니게 되었습니다.

LLM 판사들은 자기 선호 편향 (self preference bias)을 보입니다. 이는 모델이 자신의 출력물에 체계적으로 더 높은 점수를 부여함을 의미합니다 (arXiv 2410.21819). 또한 이들은 답변이 더 나은지 여부와 상관없이 더 긴 답변에 보상을 주는 장황함 편향 (verbosity bias)을 보입니다. 또한 두 후보를 제시하는 순서에 따라 승자가 바뀌는 위치 편향 (position bias)도 나타냅니다. 이는 단 하나의 반대되는 논문이 아니라, 독립적으로 재현된 연구 결과들입니다 (arXiv 2506.02592).

따라서 만약 당신이 모델을 출시하면서 새로운 모델이 더 나은지 결정하기 위해 판사를 사용하고 있는데, 그 판사가 후보 중 하나와 형제 관계(sibling)라면, 당신의 헤드라인 지표(headline metric)에는 불공정한 영향력이 개입되어 있음에도 불구하고 당신의 텔레메트리 (telemetry) 기록 어디에도 그 사실이 남지 않게 됩니다. 문제는 판사가 쓸모없다는 것이 아닙니다. 판사는 검사기 (checker)가 표현할 수 없는 것들에 대해 진정으로 유용하기 때문입니다. 문제는 판사의 출력값과 검사기의 출력값이 대시보드 상에서 모두 부동 소수점 (float)으로 표시되는 순간, 두 값이 동일해 보인다는 점입니다.

그 누구의 스키마 (schema)에도 자리가 없는 검사

reality 소스는 우리가 실제로 새롭다고 생각하는 부분이며, 또한 현재의 표준 어디에도 맞지 않는 부분이기도 합니다.

우리의 토이 월드(toy world)에서 reality 등급은 수학(math) 등급과 동일한 그래프로부터 실시간이 경과한 후가 아니라 동기적으로 계산됩니다. 이를 두 번째 권위로 만드는 것은 지연(delay)이 아니라 질문의 차이입니다. 수학은 선택이 증명 가능한 최단 경로(shortest path)였는지를 묻고, reality는 최적성(optimality)과 관계없이 여정이 실제로 허용 오차(tolerance) 범위 내에 도착했는지를 묻습니다. 우리는 여전히 reality를 자체적인 평가 이벤트(evaluation event)로 방출하며, 이 스팬(span)은 원래의 결정 스팬(decision span)으로 연결됩니다. 또한 상관관계 폴백(correlation fallback)으로서 동일한 gen_ai.response.id를 사용하는데, 이는 실제 제품 환경에서는 결정이 종료된 후 몇 분 또는 몇 시간 뒤에 이러한 종류의 확인이 이루어지기 때문이며, 비록 여기서는 그렇지 않더라도 텔레메트리(telemetry) 형태가 이를 지원해야 하기 때문입니다.

두 질문은 서로 일치하지 않으며, 항상 같은 방향으로 어긋납니다. 현재 실행에서 reality 등급을 포함하는 140개의 결정 중, 43개는 최단 경로 검사기(shortest path checker)에 의해 틀린 것으로 표시되었으나 여전히 허용 오차 범위 내에 도착했습니다. 반대의 경우는 없었습니다. 즉, 수학이 옳다고 판단한 것이 허용 오차를 벗어난 사례는 단 하나도 없었습니다. 140개 중 121개가 전체적으로 제시간에 도착했습니다. 어느 쪽도 틀리지 않았습니다. 그들은 서로 다른 것을 계산하며, 하나의 경로가 한쪽에서는 패배하고 다른 쪽에서는 승리할 수 있습니다.

이를 구축하면서 우리는 gen_ai.evaluation.*에 평가자 출처(evaluator provenance) 속성을 추가하자는 공개된 OpenTelemetry 제안을 발견했습니다. 여기에는 llm_judge, deterministic, human, custom이라는 열거형(enum)이 포함되어 있습니다. 우리의 math는 deterministic에 깔끔하게 매핑되고 우리의 ai_judge는 llm_judge에 매핑되지만, reality 또한 동일한 기준으로 볼 때 deterministic으로 보입니다. 수학과 reality 모두 의견(opinion)을 포함하지 않기 때문입니다. 이 열거형에는 두 개의 deterministic 등급이 서로 다른 질문에 답한다는 사실이나, 그중 하나가 실제 환경에서 사후에 도착하도록 설계되었다는 사실을 나타낼 방법이 없습니다. 우리는 이미 실행 중인 코드에서 이 문제의 형태를 겪었기에, 해당 스레드에 우리의 구현 내용을 게시했습니다.

정직함이 치른 대가

이 부분이 이 글을 단순한 설계 에세이 이상으로 만드는 지점입니다.

우리의 헤드라인 지표(headline metric)에는 두 가지 결함이 있었고, 그 두 가지 모두 우리를 자만하게 만들었습니다. 분자(numerator)는 오직 정답 결정(correct decisions)에 들어간 비용만을 합산했기 때문에, 오답에 소비된 모든 달러는 보이지 않았습니다. 이는 틀리는 비용(cost of being wrong)을 전체 프레임으로 삼는 프로젝트로서는 정반대의 방식이었습니다. 또한, 결정(decisions)이 아닌 점수(grades)를 집계했기 때문에, 수학 점수(math grade)와 현실 점수(reality grade)를 모두 생성하는 하나의 결정은 정답 카운트에 두 번 기록되는 반면, 그 비용은 한 번만 기록되었습니다.

우리는 이 두 가지를 모두 수정했습니다. 분자는 모든 비용을 포함하도록 변경되었습니다. 헤드라인은 단일 점수 소스(single grade source)로 범위를 제한하여, 하나의 결정이 해당 소스 내에서 최대 하나의 점수만 생성할 수 있도록 했습니다. 이는 문제를 임시방편으로 때우는 대신 구조적으로 중복 계산을 제거하는 방식입니다. 현실 점수(Reality grades)는 별도의 인접 패널로 이동하여, 혼합되지는 않되 눈으로 확인할 수는 있게 되었습니다.

리포지토리(repo)에 커밋된 실행 결과에서, 이 수정이 수치에 미친 영향은 다음과 같습니다:

자만하게 만들었던 버전은 오직 정답 결정에 들어간 비용인 $0.341049를 389개의 점수로 나누었습니다. 여기서 389개는 이미 한 번 집계된 268개의 수학 점수와 121개의 현실 점수의 합이었습니다. 그 결과는 정답 결정당 $0.000877로 나타났습니다.

정직한 버전은 모든 비용인 $0.403804를 정확히 한 번씩만 집계된 268개의 정답 결정으로 나눕니다. 그 결과는 정답 결정당 $0.001507로 나타납니다.

수치가 산출되는 대시보드입니다. 상단의 $grade_source 변수가 특정 의견을 헤드라인에 포함할지 여부를 결정합니다.

우리는 우리가 내놓을 수 있었던 수치보다 1.72배 더 나쁜 헤드라인 수치를 발표했습니다. 두 수치 모두 리포지토리의 기록을 통해 수동으로 재계산이 가능하며, 이것이 두 수치가 그나마 가치를 지니는 유일한 이유입니다.

우리 자신의 채점기(grader)는 최적의 모델에 대해 거짓말을 하고 있었다

모든 결정을 채점하는 목적은 각 종류의 결정에 대해 여전히 충분히 좋은 가장 저렴한 모델을 찾는 것입니다. 저희가 만든 가상 세계는 세 가지를 실행합니다: 두 경로 중 더 빠른 것을 고르기, 이동 시간을 추정하기, 다음 교차로를 선택하기. 여섯 개의 제공업체에서 나온 일곱 개의 모델이 각각 모든 60개 질문에 답합니다.

한동안 모든 모델이 모든 것에서 같은 점수를 받았고, 저희는 거의 이것을 발견으로 작성할 뻔했습니다. 하지만 그것은 발견이 아니었습니다. 그것은 저희 자체 테스트 장치(harness)의 버그 세 개였으며, 깨끗한 성공(clean sweep)이 고장 난 테스트가 가진 전형적인 형태이기 때문에 저희는 그 문제들을 찾아보게 되었습니다.

프롬프트들이 답을 넘겨주고 있었던 것입니다. 경로 질문은 각 후보 모델의 총 시간을 옆에 인쇄했기 때문에, 과제는 화면에 이미 있는 두 숫자 중 더 작은 것을 고르는 것이었습니다. 추정 질문은 반대 결함이 있어 지도를 전혀 제공하지 않았고, 따라서 모델에게 한 번도 본 적 없는 그래프에 대해 질문했고 그 0점은 모델의 어떤 한계라기보다는 눈가림(blind guessing) 점수였습니다.

그리고 실제 질문들이 자리 잡자, 가장 강력한 모델조차 가장 어려운 유형에서 0점을 받았습니다. 그것 역시 저희의 문제였습니다. 저희 파서(parser)는 응답의 첫 번째 숫자를 가져갔고, 작업 과정을 보여주는 모델은

SigNoz에 있는 동일한 표입니다. 상단의 next_hop을 보면: 세 모델이 20/20점을 받았으며, 비용(cost) 열이 논쟁의 핵심입니다.

이것은 리더보드(leaderboard)라기보다는 라우팅 테이블(routing table)에 가깝습니다. 다음 교차로를 선택하는 작업에서 7개의 모델 중 3개인 gemini-2.5-flash-lite, gpt-4o-mini, deepseek-chat가 20/20점 만점을 기록했습니다. claude-sonnet-4.6은 동일한 작업에서 19/20점을 기록했는데, 비용은 앞서 언급한 세 모델보다 각각 28.5배, 20.6배, 15.6배 더 높았습니다. 여정 시간을 추정하는 작업에서는 이 세 모델 중 두 모델인 gemini와 gpt-4o-mini가 0점으로 무너졌습니다. deepseek-chat는 그들과 합류하지 못하고 대신 13/20점을 기록했습니다. Sonnet은 0점을 기록한 두 모델 중 가장 저렴한 gemini 비용의 188.8배를 지불하고 19/20점에 도달했습니다. Gemini와 gpt-4o-mini는 한 가지 결정 유형에서는 Sonnet을 이겼지만, 동일한 실행 과정에서 다른 결정 유형에서는 Sonnet에 대해 0점을 기록했습니다. 이는 단지 어떤 결정을 내리도록 요청받았느냐에 따라 결정되었습니다. 더 빠른 경로를 선택하는 작업에서 누군가가 기록한 최고 점수는 20점 만점에 14점이며, 이는 Sonnet의 점수이기도 합니다. 따라서 이 열은 누군가를 순위 매기는 곳이라기보다 전체 분야의 약점으로 남아 있습니다. 이 7개 모델 중 어떤 단일 순위도 세 개의 열을 모두 통과하지 못하며, 이것이 바로 모델당 하나의 수치를 발표하는 대신 결정 유형별로 채점해야 한다는 논거입니다.

솔직하게 말하자면, 이 세 가지 버그 중 두 가지는 이 작업이 시작되기 전부터 저희의 문제였으며, 모든 질문에 단 하나의 토큰(token)으로 답할 수 있었던 동안에는 두 가지 모두 보이지 않았습니다. 질문을 실제적인 것으로 만드는 과정이 이 버그들을 드러냈습니다.

한계점에 대한 명시

우리는 장난감 세계(toy world)의 오라클(oracle)을 소유하고 있습니다. 우리가 교차로를 작성하고, 최단 경로를 계산하며, 우리 자신의 정답지에 따라 채점합니다. 이것은 실제적인 한계이며, 누군가 우리 대신 말하기 전에 미리 언급할 가치가 있습니다.

이것은 또한 채점 기계(grade machine)를 검증 가능하게(checkable) 만드는 바로 그 이유이기도 합니다. 우리가 굳이 장난감 세계(toy world)를 구축한 이유는, 증명 가능한 정답지(answer key)만이 그 어디에도 주관이 개입되지 않은 점수를 얻을 수 있는 유일한 방법이기 때문입니다. 실제 제품 환경(product surface)으로 넘어가는 순간, 우리는 그것을 잃게 되며 현실적인 점수(reality grades)나 심사위원(judges)에게 의존할 수밖에 없습니다. 따라서 장난감 세계가 증명하는 것은 좁은 범위입니다. 그것은 메커니즘이 출처(provenance)를 정확하게 기록한다는 것을 증명하며, 현실적인 점수 경로(reality grade path)가 이를 실제 기질(substrate)로 옮겨가야 하는 과제를 안게 됩니다.

또 다른 한계는 메트릭 파이프라인(metric pipeline)이 의도적으로 결정별 ID(per decision id)를 포함하지 않는다는 점입니다. 응답 ID(response id)를 메트릭 레이블(metric label)로 사용하면 카디널리티(cardinality)가 폭발하기 때문입니다. 이는 메트릭 파이프라인 내부에서의 중복 제거(deduplication)가 불가능함을 의미하며, 각 결정을 한 번씩만 세는 진정한 카운트(true count) 수정 작업은 트레이스 쿼리(trace query)로 넘어가야 합니다.

실행하기 (Run it)

API 키도, 모델 호출도 필요 없으며, 모든 머신에서 동일한 수치가 나옵니다:

pip install -e reference-library -e toy-world
python -m toyworld