LLM 평가 벤치마크가 비교 가능한 숫자를 생성하는 방법: LFORLA 메커니즘 내부

요약: 리더보드는 숫자를 신뢰할 수 있을 때만 유용합니다. LFORLA의 LLM 평가는 프롬프트를 고정하고, 심사관(judge)을 고정하며, 축별 루브릭으로 점수를 매기고, 모델이 실제로 어떤 답변을 했는지 누구나 다시 읽어볼 수 있도록 원문 기록(verbatim trail)을 공개함으로써 점수들을 비교 가능하게 만듭니다. 아래에서는 팀 모집(Oracle) 벤치마크를 구체적인 예시로 들어 실제 작동 방식을 설명합니다.

평가가 작동하는 방식

팀 모집(Team Recruitment) (Oracle) 벤치마크는 채용 에이전트 과제입니다. 모델은 오라클로부터 이력서(résumés)를 조회한 다음, 팀을 구성합니다. 이는 구성 기준에 따라 점수를 받으며, 예산 및 좌석 제약 조건에 대한 이진 게이트가 적용됩니다. 이러한 상호작용들을 숫자로 변환하는 메커니즘은 네 가지 움직이는 부분으로 이루어져 있습니다.

1. 모든 모델에게 동일한 프롬프트 제공. 각 모델은 동일한 과제 설명, 동일한 오라클 인터페이스, 그리고 동일한 제약 조건을 받습니다. 어떤 모델도 더 친근한 표현이나 추가적인 맥락을 얻지 못합니다. 이것이 비교 가능성의 기준점입니다: 입력이 다르면 출력은 비교할 수 없습니다.

2. 동일하고 고정된 심사관(judge). 단일한 심사관 설정이 모든 제출물을 평가합니다. 심사관은 모델별로 교체되지 않으며, 결과를 본 후 조정되지도 않습니다. 심사관을 고정하는 것은 리더보드 드리프트(leaderboard drift)라는 일반적인 원인을 제거하는데, 이는 단순히 채점 기준이 바뀌었기 때문에 모델의 성능이 향상된 것처럼 보이는 경우를 말합니다.

3. 축별 루브릭(Per-axis rubrics). 하나의 불투명한 점수 대신, 평가는 성능을 여러 축으로 분해합니다. 이 벤치마크의 경우, 구성 기준은 별도로 점수가 매겨지며, 예산 및 좌석 제약 조건은 이진 게이트 역할을 합니다: 통과 또는 실패. 축별 루브릭은 단일한 종합 점수만 보는 것이 아니라, 모델이 어디에서 강하고 어디서 무너지는지를 볼 수 있게 해줍니다.

4. 공개된 원문 기록 (verbatim trail). 모든 답변은 그대로 저장되고 공개됩니다. 누구나 모델이 실제로 말한 내용을, 단순히 받은 점수만으로가 아니라 다시 읽어볼 수 있습니다. 이것이 바로 책임성(accountability) 계층입니다: 만약 어떤 점수가 놀랍게 보인다면, 기록을 검토하여 스스로 판단할 수 있습니다.

실제 점수 (The real numbers)

다음은 팀 모집(Team Recruitment)에 대한 현재 리더보드(leaderboard)입니다 (Oracle):

순위가 이렇게 보이는 이유

이 작업에서 90.87과 83.1 사이의 격차는 의미가 있습니다. 왜냐하면 이 벤치마크(benchmark)는 엄격한 제약 조건 하에서의 정확한 팀 구성을 보상하기 때문입니다. 이진 예산(binary budget) 및 좌석 게이트(seat gates)를 충족하는 동시에 구성 기준을 충족하는 모델이 앞서 나갈 것입니다. 게이트를 놓치거나 좌석 할당에 오류가 있는 모델은 해당 기준과 연결된 축에서 점수를 잃습니다.

저희 자체 제출 결과인 GLM 5.2의 78.0점은 두 선두 주자 모두보다 낮습니다. 저희는 이 점수를 공개하는데, 벤치마크를 운영하는 사람들이 자신들의 결과를—심지어 좋지 않은 결과까지도—보여줄 의향이 있을 때만 그 벤치마크가 신뢰할 수 있기 때문입니다. 이 점수는 우리 모델이 이 특정 작업에서 어느 위치에 있는지 알려줄 뿐, 모든 면에서 더 못하다는 것을 의미하지는 않습니다.

모델을 선택하는 실무자에게 이것이 의미하는 바

리더보드 점수는 보편적인 순위가 아니라, 특정한 제약 조건 하의 특정 작업에 대한 신호입니다. 팀 모집 벤치마크는 채용 에이전트(recruitment-agent) 행동을 측정합니다: 오라클에게 질의하고, 팀을 구성하며, 예산 및 좌석 제한을 준수하는 것입니다. 만약 귀하의 사용 사례가 이와 유사하다면, 그 순위는 직접적으로 관련성이 있습니다. 하지만 요약(summarization)이나 코드 생성(code generation)이 사용 사례라면 그렇지 않습니다.

축별 평가 기준(per-axis rubrics)이 더 유용한 결과물입니다. 이는 어떤 차원들이 측정되었는지 알려주므로, 귀하의 워크로드에 해당 차원들이 중요한지 여부를 물어볼 수 있게 합니다. 원문 기록은 높은 점수가 진정한 역량을 반영하는지 아니면 이진 게이트를 운 좋게 통과한 것인지를 확인할 수 있게 해줍니다.

리더보드 읽는 법: 짧은 체크리스트

• 과제 확인. 점수를 가중치 부여하기 전에 해당 벤치마크가 실제 사용 사례와 유사한지 확인하세요.
• 평가자 확인. 평가자가 고정되어 있는지, 그리고 그 내용이 공개되었는지 문의하세요. 변동하는 평가자는 역사적 비교를 신뢰할 수 없게 만듭니다.
• 축(Axes) 읽기. 단순히 종합 점수만 보지 말고, 각 축별 결과를 살펴보세요. 단 하나의 숫자가 모델의 실패 지점을 숨길 수 있습니다.
• 과정 추적 확인. 몇 가지 원문 답변을 열어보세요. 기록이 점수를 뒷받침하지 못한다면, 그 점수는 의심해야 합니다.
• 제한 조건(Gates) 주목. 예산이나 좌석 제한 같은 이진 제약 조건은 점수에 큰 영향을 미칠 수 있습니다. 어떤 제한 조건들이 존재하는지 이해하세요.

솔직한 한계점 (Honest limitations)

이 벤치마크는 하나의 과제군을 다룹니다. '팀 구성(Team Recruitment)'에서의 점수가 다른 영역으로 자동으로 이전되지는 않습니다. 이진 게이트(binary gates)의 특성상, 단 하나의 제약 조건 실패가 최종 숫자에 지나친 영향을 미칠 수 있으며, 이는 뉘앙스를 압축합니다. 여기에 표시된 리더보드는 스냅샷이며 모델은 계속 변화합니다. 마지막으로, 저희가 자체 모델을 제출했으므로, 저희의 해석을 이 이해 상충(conflict of interest)을 염두에 두고 읽어주시기 바랍니다. 원문 기록(verbatim trail)이 존재하는 이유도 바로 여러분이 저희 말만 믿지 않도록 하기 위함입니다.

결론 (Conclusion)

비교 가능한 LLM 평가는 규율에 달려 있습니다: 동일한 프롬프트, 동일한 평가자, 축별 루브릭(per-axis rubrics), 그리고 공개된 기록이 필요합니다. '팀 구성(Team Recruitment) (Oracle)' 리더보드에는 Nemotron 3 Ultra가 90.87점, HY3가 83.1점, 저희의 GLM 5.2가 78.0점으로 표시되어 있습니다. 전체 결과와 원문 답변은 lforla.org에서 확인하세요.