Overall 하나가 가릴 수 있는 것
벤치마크의 Overall은 과제 유형별 문항 수 비중을 반영한 문항 단위 평균이라, 조합마다 다른 개선 폭을 하나의 숫자로 뭉갭니다. HealthLoopQA에서 Gemini를 프롬프트형에서 에이전트형으로 바꾸자 시뮬레이션 Overall은 43.7에서 65.8로, 실측 Overall은 64.6에서 78.5로 올랐습니다.
그런데 안전과 직결되는 이상탐지(AD) 조합만 떼어 보면 21.2 대 52.4로 격차가 더 벌어져 있었습니다. 헤드라인 숫자 하나만 보고 "에이전트로 바꾸면 좋아진다"고 판단하면, 조합별 개선 폭이 서로 크게 다르다는 사실을 놓칩니다.
맥락 내 게으름 — 계산 대신 그럴듯한 추측
연구팀이 "in-context laziness"라 이름 붙인 실패 양상은, 모델이 30일 치 시계열을 실제로 훑어 계산하는 대신 대략적인 중간값에 그럴듯한 서사를 붙여 확신에 찬 답을 내놓는 패턴입니다. 오답을 사람이 직접 검토해 확인한 관찰이며, 발생 빈도를 수치로 제시하지는 않습니다.
단일 계산(QC)만 요구하는 문항은 네 조건 모두 68.8~95.6점으로 안정적이었지만, 사건 조회 다음에 패턴 상관을 요구하는 조합(ER→PC)은 0.8~23.5점까지 무너졌습니다. 계산 능력이 없어서가 아니라, 여러 단계를 실제로 이어 붙이지 않아서 생기는 격차입니다.
설계에서 감사까지: 집계 점수에 속지 않는 평가셋 운영법
기획 단계에서는 조합별 최소 통과선을 문항 단위 평균과 나란히 선언해야 합니다. 과제유형×인지수준을 교차한 조합표를 만들고, 예컨대 "각 조합 50점 미만이면 배포 보류"처럼 Overall과 별개인 게이트를 걸어 두면, 집계 점수 상승만으로 릴리스를 승인하는 실수를 막을 수 있습니다.
게으름을 잡는 방법은 최종 답만 채점하지 않고 추론 궤적에서 중간 계산값이 실제로 등장하는지 확인하는 것입니다. 정확 계산을 건너뛴 흔적, 시점 오정렬, 근거 없는 가정이 함께 나타나면 게으름 신호로 보고 자동 재계산을 요구하는 재시도 분기를 붙입니다.
단위 불일치도 같은 계열의 함정입니다. 인슐린 주입 속도 단위를 오독해 예측값이 몇 배씩 벌어진 사례처럼, 산출값 단위가 스펙과 일치하는지는 계산 정확도와 별개로 검증해야 합니다.
운영 체크리스트에는 비대칭 비교를 걸러내는 절차가 필요합니다. 이번 사례도 프롬프트형·에이전트형을 모두 측정한 모델이 하나뿐이라 "에이전트가 낫다"는 결론을 다른 모델까지 확장할 근거는 없습니다. 사람 검토 표본은 무작위 대신 직전 실행에서 가장 낮은 조합 점수를 받은 항목 위주로 뽑아야 감사 효율이 오릅니다.
로그 필드도 미리 정해야 사후 교차검증이 가능합니다. 조합 ID, 정규화 점수, 실행 방식, 실측 여부를 필수로 남기면 시뮬레이션·실측 44개 공통 과제를 대조해 점수가 같은 방향인지 확인할 수 있습니다.
릴리스마다 조합별 표를 이전 버전과 나란히 두고 어느 조합이 새로 무너졌는지 추적합니다. 이번처럼 붕괴가 보고된 조합은 회귀 스위트에 고정 편입해 매 배포마다 재확인하고, 감사에서 나온 게으름 사례는 정성 로그로만 남기지 말고 해당 조합의 표본 수를 늘려 발생률 자체를 수치화하는 방향으로 평가셋을 키워야 합니다.
비용 측면에서도 조합별 표는 유용합니다. 붕괴한 조합에만 재계산 로직을 추가하면, 이미 68점 이상인 단일 계산 조합까지 안전장치를 씌우는 것보다 토큰 비용을 아낄 수 있습니다.
실행 요약
에이전트 평가셋은 Overall 하나가 아니라 과제유형×인지수준 조합별 표를 채점 기준으로 함께 못박아야 합니다. 이번 사례에서 단일 계산은 68.8~95.6점으로 무난했지만 다단계 패턴 조합은 0.8~23.5점까지 무너졌고, 이 격차는 궤적 검토·단위 교차검증·붕괴 조합 회귀 스위트 없이는 헤드라인 숫자만으로 드러나지 않습니다.