심리측정으로 설계하는 SJT와 LLM 평가
Psychometrics는 평가 점수가 안정적이고 적절한 근거를 갖는지 확인하는 관점이고, SJT는 실제 상황 속 판단을 측정하는 문항 구조다. LLM judge를 쓰는 AI 평가 앱에서도 construct, reliability, validity, calibration, drift monitoring이 제품 요구사항이 된다.
Script Companion
오디오와 함께 스크립트 보기
- 01
Psychometrics는 평가 도구가 무엇을 얼마나 안정적으로 측정하는지 묻는 관점이다. AI 평가 앱이 면접 답변, 상담 품질, 업무 역량을 평가하려면 단순히 그럴듯한 점수를 내는 것만으로는 부족하다. 먼저 측정하려는 대상, 즉 construct가 정의되어야 한다. construct가 없으면 문항이 무엇을 겨냥하는지, 점수가 어떤 의사결정에 쓰일 수 있는지 해석하기 어렵다. 그래서 평가 설계의 출발점은 좋은 프롬프트가 아니라 무엇을 측정할지에 대한 명확한 정의다.
- 02
Situational Judgment Test, 즉 SJT는 상황, 선택지, 판단 이유를 통해 실제 trade-off 판단을 드러내는 문항 형식이다. 좋은 SJT는 정답 맞히기 게임이 아니라 업무 상황에서 어떤 우선순위를 세우는지 보여준다. incident response에서는 롤백, 완화, 공지, 원인분석의 순서를 볼 수 있고, customer support QA에서는 환불 요구, 정책 위반, 분노한 고객 사이의 응대 우선순위를 볼 수 있다. code review eval과 agent benchmark에서도 상황은 달라지지만 construct, 선택지, 근거, 채점 키를 분리하는 원리는 같다.
- 03
Reliability는 평가 결과가 일관되게 나오는지를 본다. 같은 construct를 묻는 문항들이 함께 움직이는지 보는 internal consistency, 사람 평가자와 LLM judge가 얼마나 일치하는지 보는 inter-rater reliability, 같은 응답을 시간이 지나 다시 평가해도 안정적인지 보는 test-retest reliability가 있다. LLM judge에서는 temperature, model version, prompt version도 reliability에 영향을 준다. 그래서 평가 지표는 상황에 맞게 골라야 하며, 점수 하나가 반복 가능하다는 증거 없이 운영 판단에 바로 연결해서는 안 된다.
- 04
지표 선택도 평가 설계의 일부다. human 1명과 LLM 1명이 pass와 fail처럼 범주형 판정을 내리면 Cohen's kappa로 단순 일치율에서 우연 일치를 뺀다. 평가자가 3명 이상이거나 일부 응답만 평가한 누락 데이터가 있으면 Krippendorff's alpha가 더 잘 맞는다. 여러 SJT 문항을 하나의 역량 점수로 합산한다면 Cronbach alpha로 internal consistency를 확인할 수 있다. 다만 UCLA OARC가 경고하듯, alpha가 높다고 해서 단일 construct가 보장되는 것은 아니다.
- 05
Validity는 이 평가가 의도한 것을 적절히 측정한다는 증거다. content validity는 문항이 실제 업무 내용을 대표하는지, construct validity는 문제해결력과 단순 영어 유창성처럼 다른 요소를 분리하는지, criterion validity는 평가 점수가 온콜 성과 같은 외부 성과와 관련 있는지 묻는다. face validity는 응시자가 문항을 실제 업무처럼 납득할 수 있는지도 본다. 중요한 점은 타당도가 한 번 획득하는 인증서가 아니라 누적 증거라는 것이다. 그래서 업무 성공 기준을 construct로 정의하고, 문항 수와 상황 범위, 난이도, 채점 방식, human review 조건을 blueprint로 먼저 만든다.
- 06
SJT의 scoring 방식은 평가 목적에 따라 달라진다. best answer는 가장 적절한 선택지 하나를 고르게 하고, rank order는 선택지를 좋은 순서로 정렬하게 한다. rate effectiveness는 각 선택지의 효과성을 1점에서 5점으로 평가하게 하며, open response는 자유 서술을 rubric이나 LLM judge로 채점한다. open response는 답변의 근거와 사고 과정을 더 풍부하게 볼 수 있지만, 채점 reliability를 별도로 검증해야 한다. 특히 LLM judge를 쓴다면 점수만 저장하지 말고 evidence span과 rationale을 함께 남겨야 한다.
- 07
LLM judge는 자동 채점기라기보다 평가자에 가깝다. 따라서 human expert가 만든 gold set을 준비하고, judge prompt, scoring guide, model version, temperature를 고정한 뒤 human-judge agreement를 계산해야 한다. OpenAI는 LLM judge가 80% 이상 human preference agreement에 도달할 수 있지만 position bias와 verbosity bias가 과제라고 설명하고, 자동 점수는 human feedback으로 보정하라고 권고한다. 운영 전에는 anchor 응답으로 calibration을 하고, 운영 중에는 새 모델, 새 prompt, 새 rubric이 들어올 때 같은 anchor set을 다시 채점해 기준점이 움직였는지 확인한다.
- 08
문항 품질 점검에서는 난이도, 변별도, cueing, construct-irrelevant variance, adverse impact를 본다. 모두 맞히거나 모두 틀리는 문항은 난이도 조정이 필요하고, 고성과자와 저성과자의 차이를 드러내지 못하면 construct와 상황을 다시 봐야 한다. 문장 길이만으로 정답을 추측할 수 있으면 선택지의 길이와 톤을 맞춘다. 영어 실력이 점수를 좌우하면 언어 난이도를 통제해야 한다. Columbia Public Health의 IRT 설명처럼 변별도가 음수라면 능력이 높을수록 정답 확률이 낮아지는 이상 신호이므로 문항을 폐기하거나 다시 써야 한다.
- 09
Silent failure는 점수가 조용히 그럴듯해 보이지만 측정 품질이 무너지는 경우다. LLM judge가 긴 답변에 높은 점수를 주면 verbosity bias를 의심하고 길이 통제와 evidence-first 채점을 적용한다. 문항이 너무 쉬우면 obvious best answer가 있는지 보고 distractor를 개선한다. 같은 rubric인데 채점 이유가 달라지면 rubric drift를 의심하고 anchor set 재채점과 rubric versioning이 필요하다. 평가 로그에는 rubric_version, judge_model, prompt_version, anchor_set_version을 함께 남기고, 월별 점수 분포뿐 아니라 evidence 유형 분포도 비교해야 한다.
- 10
고위험 평가에서는 LLM judge가 최종 결정자가 되면 안 된다. 채용, 승진, 징계, 교육 선발, 신용·보험처럼 개인에게 실질적 영향을 주는 경우에는 human final decision, 감사 로그, appeal 경로, adverse impact review가 배포 조건이 된다. European Commission의 EU AI Act 안내는 documentation, traceability, transparency, human oversight, lifecycle monitoring을 요구하고, NIST AI RMF도 AI 위험관리를 운영 가능한 절차로 만들도록 설계된 프레임워크다. 정리하면 AI 평가 앱에서 먼저 물어야 할 질문은 프롬프트가 잘 채점하는가가 아니라, 이 점수로 어떤 결정을 해도 되는가다.
같은 레이어
L12에서 이어 듣기
- LLM API 기초와 운영 감각 길이 미정
- 운영 자산으로 보는 프롬프트 엔지니어링 길이 미정
- 임베딩과 벡터 운영의 핵심 경로 길이 미정
- RAG 기초: 검색, 주입, 생성의 운영 기준 길이 미정
- LLM 도구 호출의 설계와 운영 길이 미정
- 에이전트 오케스트레이션 운영 기준 길이 미정
- LLM 비용과 지연을 운영 지표로 읽는 법 길이 미정
- LLM 보안과 운영 방어 계층 길이 미정
- LLM 운영을 위한 관측성과 평가 길이 미정
- 에이전틱 LLM의 컨텍스트 파이프라인 길이 미정
- 상태 머신으로 LLM 워크플로를 다루기 길이 미정
- AI 워크플로를 위한 Temporal Durable Execution 길이 미정
- Human-in-the-loop AI 워크플로 설계 길이 미정
- AI 앱의 온톨로지와 역량 모델링 길이 미정