[Educational Measurement] 벤치마크 점수는 어디까지 말할 수 있을까요?

[Educational Measurement] 벤치마크 점수는 어디까지 말할 수 있을까요?
Photo by Gary Bendig / Unsplash

LLM과 AI 에이전트 평가를 공부하다 보면 자연스럽게 데이터셋, 평가 지표, LLM-as-a-Judge, 리더보드 같은 주제에 관심이 갑니다. 저 역시 처음에는 더 좋은 벤치마크를 만들기 위해 어떤 태스크를 넣어야 하는지, 정확도를 어떻게 계산해야 하는지, 평가자를 어떻게 설계해야 하는지를 주로 살펴봤습니다.

그런데 평가를 계속 고민해볼 수록, 기초를 알아야겠다는 생각을 하였습니다.

우리가 계산한 이 점수로 실제로 어디까지 말할 수 있을까요?

'모델 A가 82점을 받고 모델 B가 76점을 받았다'라는 사실에서 바로 (많은 사람들도 그러하듯) 모델 A가 더 뛰어나다고 저 또한 생각했습니다. 하지만 여기에서 “모델 A가 추론 능력이 더 뛰어납니다”, “모델 A가 실제 업무에서도 더 잘할 것입니다”, “따라서 모델 A를 도입해야 합니다”라는 결론까지 가려면 이야기가 복잡해진다고 합니다.

왜냐하면, 각 문장에는 점수표에 적혀 있지 않은 가정이 추가되기 때문입니다.

이 문제를 공부하기 위해 선택한 책이『Educational Measurement』입니다. 교육 측정 분야에서는 수십 년 동안 시험 점수와 인간의 능력 사이의 관계를 연구해 왔습니다. (ChatGPT 덕분에 알게되었네요.) 시험 문항을 어떻게 구성할지뿐만 아니라, 시험에서 얻은 점수를 어떤 능력의 증거로 해석할 수 있는지, 다른 상황에서도 그 해석이 유지되는지, 점수가 의사결정에 사용될 때 어떤 문제가 발생하는지를 체계적으로 다뤄왔다고 합니다.

https://fdslive.oup.com/www.oup.com/academic/pdf/openaccess/9780197654965.pdf

LLM 벤치마크와 교육평가는 평가 대상부터 다릅니다만, 측정이라는 관점에서는 상당히 비슷한 문제가 발생합니다. 우리가 직접 관찰할 수 있는 것은 제한된 문제에 대한 수행 결과이고, 최종적으로 알고 싶은 것은 그 뒤에 있다고 가정하는 더 넓은 능력입니다.

그중에서도 『Educational Measurement』 5판의 4장 「Validity and Validation」은 이 질문을 다루고 있습니다. Suzanne Lane과 Scott F. Marion은 validity를 점수의 해석과 사용, 그리고 그로부터 발생하는 결과를 이론과 증거가 어느 정도 뒷받침하는지를 평가하는 문제로 설명합니다. Validation은 그 판단에 필요한 증거를 수집하고 평가하며 종합하는 과정이라고 정리할 수 있습니다.

이 관점을 가져와서 벤치마크를 바라본다면,

“이 벤치마크는 잘 만든 벤치마크인가요?”에서 한 단계 더 들어가 다음을 물을 수 있게 됩니다.

이 점수에서 어떤 주장을 끌어낼 수 있으며, 그 주장을 뒷받침하는 증거는 충분한가요?

이 질문이 4장을 읽으면서 가장 크게 가져갈 수 있었던 관점입니다.


점수와 능력 사이에는 추론이 있습니다

가상의 에이전트 벤치마크를 생각해보겠습니다. 100개의 과제를 제공했고 어떤 모델이 85개를 성공했습니다. 평가 규칙에 따라 이 모델의 점수를 85점으로 계산했습니다.

관찰: 100개 과제 중 85개를 성공했습니다.
점수: Benchmark Score = 85

그런데 평가자가 다음과 같이 판단을 내린다면 어떨까요?

“이 모델은 실제 업무에서 에이전트로 일할 능력이 높습니다.”

85라는 숫자와 이 문장 사이에는 여러 단계의 추론이 들어가게 됩니다.

우선 100개의 과제가 우리가 관심을 두는 에이전트 능력이라는 construct를 충분히 대표해야 합니다. 채점 방식도 성공과 실패를 적절하게 구분해야 합니다. 비슷한 과제를 다시 제공했을 때 성능이 크게 달라지지 않아야 하며, 평가 환경 밖에서도 관련된 수행이 이어질 가능성이 있어야 합니다.

Construct(구인): 평가를 통해 측정하고자 하는 추상적인 능력이나 특성을 뜻합니다. 직접 관찰할 수 없기 때문에 여러 과제에서 나타나는 수행을 통해 간접적으로 추론합니다.
예를 들어 reasoning ability, agentic capability, tool-use ability 등이 construct가 될 수 있습니다.
벤치마크 설계에서는 먼저 “우리가 정확히 어떤 능력을 측정하려는가?”를 정의해야 합니다.

이를 간단히 정리하면 다음과 같습니다.

Task 수행
↓
관찰 결과
↓
점수
↓
능력에 대한 해석
↓
다른 상황으로의 일반화
↓
모델 선택·배포 등의 의사결정

각 화살표에는 하나 이상의 가정이 들어 있습니다. Lane과 Marion은 이를 설명하기 위해 Kane의 argument-based approach를 소개합니다.

이 접근에서 Interpretation and Use Argument(IUA)는 시험 수행에서 점수의 의미와 사용까지 이어지는 추론을 명시합니다. 이후 Validity Argument에서는 각 추론을 뒷받침하는 증거와 가정을 검토합니다.

Interpretation and Use Argument(IUA): 관찰된 시험 수행과 점수에서 출발해 그 점수를 어떻게 해석하고 어디에 사용할 것인지까지 이어지는 논리 구조를 명시한 것입니다.
Validity Argument: IUA에 포함된 각각의 추론과 가정이 실제로 충분한 증거를 가지고 있는지 검토한 논증입니다.
쉽게 말하면 “우리가 이 점수로 이런 말을 해도 되는 이유는 무엇입니까?”에 답하는 과정입니다.

LLM 평가에서도 그대로 적용해볼 수 있습니다.

가령 다음 주장이 있다고 하겠습니다.

“이 모델은 AgentBench에서 85점을 받았으므로 기업의 복잡한 에이전트 업무를 잘 수행할 것입니다.”

이 문장을 검증하려면 최소한 다음 질문이 필요합니다.

  • 벤치마크의 태스크가 실제 기업 에이전트 업무의 주요 특성을 포함하고 있습니까?
  • 85점이라는 결과는 한 번의 실행에서도 안정적으로 재현됩니까?
  • 특정 프롬프트나 tool schema에 대한 적응이 점수를 크게 좌우하지 않습니까?
  • 실제 환경에서 발생하는 오류, 재시도, 긴 실행 시간, 상태 변화가 평가에 포함되어 있습니까?
  • 벤치마크에서 높은 점수를 받은 모델이 실제 업무에서도 높은 성공률을 보입니까?

결국 중요한 질문은 85점이라는 관찰 결과를 근거로 정확히 어떤 주장을 할 수 있습니까? 가 됩니다. 벤치마크에서 몇 점 받았냐에서 질문이 멈추면 안된다는 것이죠.

벤치마크 점수는 모델의 능력에 관한 주장을 뒷받침하는 하나의 증거가 되지만, 주장의 범위가 커질수록 더 많은 근거가 필요합니다.

Validity 판단이 단순한 yes/no 판정으로 끝나기 어려운 이유도 여기에 있습니다. 어떤 점수 해석은 충분한 증거를 가지고 있을 수 있고, 더 강한 해석은 아직 근거가 부족할 수 있습니다.


Validity는 점수의 사용과 결과까지 다룹니다

4장에서 Lane과 Marion은 2014년 『Standards for Educational and Psychological Testing』의 validity 정의를 소개하면서 점수의 해석과 사용을 함께 다룹니다.

시험 점수를 어떻게 계산했는지만 확인해서는 충분하지 않습니다. 그 점수를 어떤 목적으로 사용하는지까지 살펴봐야 합니다. LLM 벤치마크에서도 이 구분은 중요합니다.

어떤 모델이 에이전트 벤치마크에서 1위를 기록했다고 가정해보겠습니다. 이 결과를 가지고 다음 두 가지 상황에서 사용할 수 있습니다.

“이 평가 환경에서 모델 A가 비교 대상 중 가장 높은 성공률을 기록했습니다.”

벤치마크 결과만 보면 상당히 맞는 주장입니다. 어떤 기업은 다음과 같이 판단할 수 있습니다.

“모델 A가 1위이므로 사내 업무 자동화 플랫폼의 기본 모델로 채택하겠습니다.”

이 결정에는 훨씬 많은 가정이 필요합니다. 벤치마크에서는 짧은 단일 도구 호출을 주로 평가했는데 실제 업무에서는 30분 동안 여러 시스템의 상태를 추적하고, 오류가 발생하면 복구해야 하며, 권한 문제까지 처리해야 할 수 있습니다.

이 경우 리더보드의 1위라는 사실만으로 실제 업무 적합성을 충분히 설명하기 어려워졌습니다.

따라서 validation에서는 점수 계산 과정과 함께 다음 연결도 살펴봅니다.

Score
→ Interpretation
→ Generalization
→ Decision
→ Consequence

점수를 어디에 사용하는지에 따라 요구되는 증거의 수준도 달라집니다.

연구용 모델 비교와 수억 원 규모의 시스템 도입에서 동일한 수준의 validation을 요구하기는 어렵습니다. 후자의 의사결정에는 비용, 보안, 안정성, 장시간 수행 능력, 장애 복구와 같은 추가 요소까지 고려해야 합니다.

이 관점은 벤치마크 리더보드를 읽을 때 특히 유용합니다.

Agent benchmark score = 82

라는 결과와

이 모델은 실제 기업 업무를 수행할 수 있습니다.

라는 문장 사이에는 수많은 가정이 들어 있습니다.

Validity 연구의 중요한 기능 중 하나는 이 가정을 명시하고 각각에 증거를 요구하는 것입니다.


같은 점수라면 비슷한 의미로 해석할 수 있어야 합니다

점수를 비교하려면 또 하나의 전제가 필요합니다. 같은 평가에서 비슷한 점수를 받은 대상은 우리가 측정하려는 construct에 대해서도 비슷한 수준으로 해석할 수 있어야 합니다.

예를 들어 두 학생이 수학 시험에서 모두 80점을 받았다고 하겠습니다.

한 학생의 점수에는 수학 능력이 주로 반영되어 있고, 다른 학생의 점수에는 어려운 언어 표현을 얼마나 이해했는지가 크게 작용했다면 두 점수를 동일한 방식으로 비교하기 어려워집니다.

LLM 평가에서도 비슷한 문제가 발생할 수 있습니다. 한국어 모델과 영어 모델의 reasoning 능력을 비교하는 벤치마크가 있다고 가정해보겠습니다. 영어 원문을 한국어로 번역하는 과정에서 일부 문제의 조건이 모호해졌고, 한국어 모델의 실패 상당수가 번역 오류가 발생한 문항에 집중되어 있습니다.

결과는 다음과 같을 수 있습니다.

Model A: 82
Model B: 76

숫자만 보면 6점 차이가 존재합니다. 하지만 이 차이 전체를 reasoning ability의 차이라고 해석하려면 번역 품질이 결과에 미친 영향을 먼저 확인해야 합니다.

모델 종류에 따라 tool schema 이해 방식이 크게 달라지는 경우에도 같은 질문을 할 수 있습니다. 특정 모델이 익숙한 API 표현이나 프롬프트 포맷을 사용했다면 점수에는 우리가 측정하고 싶은 에이전트 능력 외의 요소가 함께 들어갈 가능성이 있습니다. 따라서 모델 간 점수 비교에서는 단순한 점수 차이와 함께 그 점수가 각 모델에서 동일한 construct를 얼마나 일관되게 나타내는지도 확인할 필요가 있습니다.


공정성도 점수의 의미와 연결됩니다

Lane과 Marion은 fairness를 validity와 밀접하게 다룹니다. 평가 대상은 측정하려는 construct를 충분히 드러낼 기회를 가져야 하며, 목표 construct와 관계없는 특성이 특정 대상에게 지속적으로 유리하거나 불리하게 작용하는지도 검토해야 합니다.

교육평가의 fairness 개념을 모델 평가에 그대로 대응시키기는 어려운 것 같습니다. 사람과 모델은 평가 대상의 성격이 크게 다르기 때문입니다. 그럼에도 다음 질문은 LLM 벤치마크에서도 상당히 유용하게 작용할 수 있습니다.

측정하려는 능력과 직접적인 관계가 없는 조건이 특정 모델의 점수를 체계적으로 바꾸고 있나요?

예를 들어 한국어 추론 능력을 평가하는 벤치마크에서 문제 대부분이 영어 데이터셋의 기계 번역으로 만들어졌다고 하겠습니다. 번역 과정에서 어색한 표현이나 의미 손실이 반복적으로 발생한다면 최종 점수에는 다음 두 요소가 함께 영향을 줄 수 있습니다.

Observed score
= reasoning ability의 영향
+ 번역된 표현을 처리하는 능력의 영향

이 상태에서 점수를 그대로 “한국어 reasoning 능력”이라고 해석하려면 추가 검증이 필요합니다. 에이전트 평가에서도 비슷합니다. 특정 모델이 사용하는 tool-call format과 벤치마크의 API schema가 유난히 유사하다면 해당 모델이 얻는 이점 중 일부는 일반적인 tool-use 능력과 구분해서 살펴봐야 합니다. 이러한 요인을 확인하지 않으면 모델 간 차이를 능력 차이로 과도하게 해석할 수 있습니다.


반복할 때 달라지는 점수는 얼마나 믿을 수 있을까요?

Reliability 역시 validity와 긴밀하게 연결됩니다. 측정을 반복했을 때 결과가 얼마나 안정적으로 유지되는지는 해당 점수를 해석할 때 중요한 증거가 됩니다.

LLM 평가에서는 이 문제가 더욱 직접적으로 드러나게 되는데요, 같은 모델을 같은 벤치마크에서 5번 실행했다고 가정해보겠습니다.

Run 1: 83
Run 2: 72
Run 3: 80
Run 4: 68
Run 5: 82

평균은 77점입니다. 그러나 바로 다음과 같은 질문이 떠오릅니다.

  • 모델 자체의 stochasticity가 얼마나 영향을 주었습니까?
  • temperature나 sampling 설정은 동일했습니까?
  • 평가에 사용한 task sample이 달라졌습니까?
  • LLM-as-a-Judge의 판정이 실행마다 달라졌습니까?
  • 외부 API나 tool environment의 상태가 달랐습니까?
  • 동일한 문제에서 모델이 반복적으로 실패했습니까, 아니면 실패 지점이 매번 달라졌습니까?

단일 점수만 기록하면 이 정보는 대부분 사라집니다. (평균값이 늘 그러하죠)

Educational Measurement에서는 이러한 여러 오차 원천을 체계적으로 분석하는 방법 중 하나로 Generalizability Theory를 다룹니다.

Generalizability Theory(G-Theory, 일반화 가능도 이론): 점수 변동을 하나의 오차로 처리하지 않고 task, 평가자, 실행 횟수 등 여러 오차 원천으로 나누어 분석하는 측정 이론​입니다.

LLM 평가에서도 비슷한 관점을 취할 수 있습니다.

관찰된 점수 변동
=
모델 차이
+ task 차이
+ run 차이
+ judge 차이
+ environment 차이
+ interaction

이 가운데 어느 요소가 전체 variance의 상당 부분을 차지하는지 분석하면 벤치마크 점수의 신뢰성을 훨씬 구체적으로 설명할 수 있습니다. 예를 들어 모델 간 평균 점수 차이가 2점인데 실행 간 표준편차가 5점이라면 리더보드 순위를 그대로 가져가기는 어렵습니다. 반대로 여러 실행과 여러 task subset에서도 모델 간 차이가 일관되게 유지된다면 비교에 대한 근거가 강해지게 됩니다.

Reliability는 어떤 조건이 바뀌어도 이 점수의 의미가 유지됩니까?에 대한 이야기입니다.

벤치마크가 잘못 측정하는 두 가지 방식

4장에서 특히 기억해둘 만한 개념이 있습니다. 바로, Construct underrepresentationConstruct-irrelevant variance입니다.

1. Construct underrepresentation: 측정해야 할 능력의 일부가 빠져 있습니다

Construct underrepresentation은 평가가 목표 construct의 중요한 일부를 충분히 포함하지 못하는 문제를 의미합니다.

예를 들어 “에이전트 능력”을 다음과 같이 정의했다고 하겠습니다.

  • 계획 수립
  • 적절한 도구 선택
  • 인자 구성
  • 여러 단계의 상태 추적
  • 오류 탐지
  • 실패 후 복구
  • 장기적인 목표 유지

그런데 실제 벤치마크에는 다음 유형의 문제가 대부분이라고 하겠습니다.

사용자 요청
→ 적절한 API 하나 선택
→ arguments 생성
→ 종료

이 평가에서는 tool selection과 argument generation은 꽤 잘 측정할 수 있습니다. 하지만 장시간 상태 추적, 오류 복구, 계획 수정, 장기 목표 유지 같은 능력은 거의 관찰되지 않습니다.

이때 모델이 95점을 받아도 다음 주장은 상당한 추가 근거가 필요합니다.

“이 모델은 높은 수준의 agentic capability를 가지고 있습니다.”

평가에 포함되지 않은 능력에 대해서는 점수가 충분한 정보를 제공하지 못하기 때문입니다. 이 문제는 문항을 많이 추가한다고 자동으로 해결되지 않습니다. 현재와 동일한 유형의 single-turn tool-calling 문제를 100개에서 10,000개로 늘려도 long-horizon planning을 측정하지 않는다는 문제는 그대로 남습니다.

따라서 벤치마크를 검토할 때 task 개수와 함께 construct coverage를 살펴봐야 합니다. 예를 들어 다음과 같은 표를 그려볼 수 있습니다.

목표 능력평가 포함 여부평가 비중
Tool selectionO높음
Argument generationO높음
Multi-step planning낮음
State trackingX없음
Error recoveryX없음
Long-horizon executionX없음

이 표만 만들어도 “에이전트 능력 85점”이라는 표현을 어느 범위까지 사용할 수 있는지가 훨씬 선명해집니다.

Reasoning benchmark에서도 동일합니다.

수학적 추론, 인과 추론, 공간 추론, 논리 추론, 불확실성 추론을 모두 reasoning이라는 construct에 포함한다고 정의하면서 실제 문항의 80%가 수학 word problem으로 구성되어 있다면 벤치마크가 reasoning 전체를 얼마나 대표하는지 검토해야 합니다.

Construct underrepresentation은 측정하고 싶다고 정의한 능력 중 실제 평가에서는 무엇을 관찰하지 못하고 있습니까? 에 대한 답을 다루고 있습니다.


2. Construct-irrelevant variance: 측정 대상과 관계없는 요소가 점수에 섞입니다

두 번째 문제는 Construct-irrelevant variance입니다.

목표 construct와 직접적인 관계가 없는 요소가 점수 차이를 만들어내는 경우를 의미합니다. 추론 능력을 평가한다고 가정해보겠습니다. 문제의 논리 구조는 간단하지만 영어 표현이 매우 어렵습니다. 어떤 모델은 논리적 추론 과정에서 실패했고, 다른 모델은 영어 문장을 정확히 이해하지 못해서 실패했습니다.

결과표에서는 두 모델 모두 다음과 같이 기록됩니다.

incorrect

그런데 실패의 원인은 서로 다르기 때문에 관찰된 점수에는 다음과 같은 요소가 함께 들어갈 수 있습니다.

Observed score
=
reasoning ability의 영향
+ English comprehension의 영향

이 점수를 그대로 reasoning score라고 해석하려면 영어 이해 능력이 점수에 미치는 영향을 확인해야 합니다.

LLM-as-a-Judge에서도 평가하려는 대상이 답변의 정확성과 유용성인데 judge가 긴 답변을 선호하는 경향성이 있다고 할 때, 점수에는 다음과 같은 요소가 추가될 수 있습니다.

Judge score
=
answer quality의 영향
+ verbosity preference의 영향

모델 간 답변 길이가 크게 다르다면 verbosity bias가 리더보드 순위까지 바꿀 수 있게 됩니다.

Agent benchmark에서는 평가 환경 자체가 construct-irrelevant variance의 원천이 될 수 있습니다.

  • 특정 실행 시점에 API 장애가 발생합니다.
  • 일부 모델에게만 tool timeout이 집중됩니다.
  • 모델별로 서로 다른 retry 정책이 적용됩니다.
  • 외부 웹사이트의 상태가 시간에 따라 달라집니다.
  • tool schema의 표현 방식이 특정 모델에 유리합니다.

이러한 환경 차이가 충분히 통제되지 않는다면 최종 점수에는 에이전트 능력과 환경 운이 함께 들어갑니다. 실제로 에이전트 벤치마크를 만들 때, 이러한 환경 통제를 일관성 있게 유지하게 하는 것이 정말 어려웠습니다.

Construct-irrelevant variance는 다음 질문으로 기억할 수 있습니다.

측정하려는 능력 외에 무엇이 이 점수에 영향을 주고 있나요?

두 질문만으로도 벤치마크를 보는 방식이 달라집니다

두 개념을 함께 놓으면 벤치마크 설계를 빠르게 점검할 수 있습니다.

문제핵심 질문LLM 평가 예시
Construct underrepresentation측정해야 할 능력 중 무엇이 빠졌습니까?Agent benchmark에서 error recovery 평가가 없음
Construct-irrelevant variance측정 대상 외에 무엇이 점수에 섞였습니까?Reasoning benchmark에서 번역 품질이 점수에 영향

첫 번째는 coverage의 문제이고, 두 번째는 contamination의 문제로 생각할 수 있습니다.

좋은 벤치마크를 평가할 때 “문항이 몇 개입니까?”, “accuracy가 몇 점입니까?”를 확인한 뒤 이 두 질문을 생각하는 것이 필수일 것 같습니다.


82점이라는 숫자가 말해주는 것

벤치마크 논문에 다음 결과가 적혀 있다고 하겠습니다.

Accuracy = 82.4%

이 숫자가 가장 확실하게 말해주는 것은 다음 사실입니다.

해당 모델이 특정 데이터, 특정 프롬프트, 특정 실행 환경, 특정 채점 절차에서 82.4%의 점수를 기록했습니다.

여기에서 한 단계 더 나아가면 다음과 같은 말을 하고 싶어질 것입니다.

“이 모델은 reasoning을 잘합니다.”

여기에는 점수에서 construct로 넘어가는 해석이 추가됩니다. 다음 문장은 더 많은 추론을 포함합니다.

“이 모델은 실제 에이전트 업무에서도 잘할 것입니다.”

평가 환경에서 다른 환경으로의 일반화가 추가됩니다. 다음 문장은 또 한 단계 더 나갑니다.

“따라서 이 모델을 실제 서비스에 채택해야 합니다.”

점수가 의사결정의 근거로 사용됩니다.

82.4%
→ 이 벤치마크에서 높은 성능
→ 해당 construct에서 높은 능력
→ 실제 환경에서도 높은 수행
→ 실제 시스템에 채택할 가치가 있음

아래로 전개될 수록 더 많은 증거가 필요합니다. 이 때문에 벤치마크를 볼 때 결과표 직후에 다음 질문을 던지는 사고 프레임을 가져야 할 것입니다.

이 점수는 무엇을 말할 자격이 있습니까?

그리고 그 답을 찾기 위해 다시 평가 설계를 살펴봅니다.

  • 측정하려는 construct는 정확히 무엇입니까?
  • task는 해당 construct의 주요 요소를 얼마나 포함하고 있습니까?
  • 중요한 능력이 평가에서 빠져 있지는 않습니까?
  • 목표 능력과 관계없는 요소가 점수에 영향을 주고 있지는 않습니까?
  • 반복 실행에서도 결과가 안정적으로 유지됩니까?
  • 모델 간 점수를 동일한 의미로 비교할 수 있습니까?
  • 평가 환경 밖에서도 성능이 유지된다는 증거가 있습니까?
  • 이 점수를 실제 의사결정에 사용할 만큼 충분한 근거가 있습니까?

이 질문들에 답하기 위해 주장을 명시하고 필요한 증거를 수집하며 그 증거가 주장을 어느 정도 지지하는지 검토하는 작업이 validation입니다.

결국 좋은 벤치마크란, 그 점수로 어떤 말을 할 수 있는지를 설명할 수 있어야 하지 않을까요?

그리고 좋은 벤치마크 연구자는 높은 점수를 발견했을 때 바로 모델의 능력을 확정하기 전에 우리가 관찰한 것은 무엇이고, 그 관찰에서 추론한 것은 무엇입니까? 를 생각해볼 것입니다.


출처

  • Suzanne Lane, Scott F. Marion, 「Validity and Validation」, Educational Measurement, 5th Edition, Chapter 4.
  • American Educational Research Association, American Psychological Association, National Council on Measurement in Education, Standards for Educational and Psychological Testing, 2014.
  • Michael T. Kane의 Argument-Based Approach to Validation 관련 논의. Educational Measurement 5판 4장에서 Interpretation and Use Argument(IUA)와 Validity Argument의 틀로 소개됩니다.

Read more

멀티 에이전트 시스템에서 먼저 설계해야 하는 것

멀티 에이전트 시스템에서 먼저 설계해야 하는 것

최근 OpenRouter가 Fusion이라는 기능을 공개했습니다. 여러 모델이 같은 질문에 답하고, judge 모델이 그 답변들을 읽은 뒤 하나의 결과로 합성하는 방식입니다. OpenRouter는 deep research 벤치마크에서 이 구조가 단일 frontier 모델보다 더 높은 점수를 냈다고 설명했습니다. 이 발표에서 눈에 들어온 부분은 “여러 모델을 붙였더니 성능이 올랐다”는 결과 자체보다, 성능을 올리는 방식이었습니다.

By harheem
Text-to-SQL 에이전트만으로 신뢰할 수 있는 데이터 에이전트를 만들 수 있을까?

Text-to-SQL 에이전트만으로 신뢰할 수 있는 데이터 에이전트를 만들 수 있을까?

자연어로 질문하면 SQL을 생성하고, 실행한 뒤, 결과를 요약해 주는 데이터 에이전트는 이제 꽤 익숙한 패턴이 되었습니다. 저도 데이터 에이전트를 설계한다고 하면 가장 먼저 text-to-SQL 구조를 떠올렸습니다. 사용자의 질문을 받고, 관련 schema를 찾고, 필요한 테이블과 컬럼을 고른 뒤 SQL을 생성합니다. 이후 SQL을 실행하고, 결과를 다시 자연어로 설명하는 방식입니다. 흐름을 단순화하면 다음과

By harheem
[논문 리뷰] LLM 모델은 답하기 전에 성공 가능성을 알고 있을까?

[논문 리뷰] LLM 모델은 답하기 전에 성공 가능성을 알고 있을까?

Sparse Reward Subsystem in Large Language Models를 읽고, 내부 신뢰도 신호를 어디까지 실제 업무에 활용할 수 있을지 정리합니다. LLM의 추론 성능은 빠르게 좋아지고 있습니다. 하지만 모델이 왜 특정 문제를 잘 풀고, 어떤 상황에서 실패하는지는 여전히 설명하기 어렵습니다. 실제 업무에서는 이 문제를 완화하기 위해 모델에게 직접 자신감을 말하게 하기도 합니다. 예를

By harheem
DeepSeek 이후, 한국 오픈소스 AI 생태계는 무엇을 갖춰야 할까

DeepSeek 이후, 한국 오픈소스 AI 생태계는 무엇을 갖춰야 할까

모델 공개를 넘어, 작동하는 생태계로 2025년 이후 글로벌 오픈소스 AI 생태계에서 가장 큰 변화는 모델 성능 향상만으로 설명하기 어렵습니다. 더 중요한 변화는 오픈소스가 AI 시스템 설계의 기본 전제로 자리 잡기 시작했다는 점입니다. DeepSeek R1 이후 중국 사례에서 확인할 수 있듯이, 모델은 더 이상 완결된 결과물로만 다뤄지지 않습니다. 이제 모델은 재사용하고,

By harheem