Microsoft-Decision-1의 확률대로 바로 처리해도 될까: 질문 500개에서 라벨을 뒤바꿔 봤습니다

Microsoft-Decision-1의 확률대로 바로 처리해도 될까: 질문 500개에서 라벨을 뒤바꿔 봤습니다

결정 모델은 글을 쓰지 않습니다. 판단할 내용과 질문, 그리고 정해 둔 답 목록을 주면 답마다 확률을 돌려줍니다. Microsoft가 새로 낸 Microsoft-Decision-1도 이런 모델입니다. OpenRouter 모델 페이지는 이 출력을 "보정된(calibrated) 확률"이라고 부르고, 이 확률로 애플리케이션이 바로 처리할지, 미룰지, 사람에게 검토를 맡길지 정할 수 있다고 설명합니다.

저희가 궁금한 것도 바로 그 쓰임새입니다. 확률이 높으면 애플리케이션이 알아서 처리하고, 나머지만 사람에게 넘기는 방식입니다. Microsoft 글에는 "90%라고 한 예측은 대표적인 사례에서 열 번 중 아홉 번쯤 맞아야 한다"는 문장이 있습니다. 벤치마크 36개에 걸친 보정 점수(100이면 확신하는 정도와 실제로 맞히는 비율이 같다는 뜻)도 그래프로 실었는데, Decision-1이 92.2점으로 7개 모델 중 3위, Jev 1.13.0이 93.7점입니다. 이 점수를 어떻게 계산했는지는 적혀 있지 않습니다. 같은 요청을 여덟 가지 방식으로 바꿔 넣었을 때 답이 바뀐 비율은 평균 1.3%였고, 선택지 설명을 바꿔 쓰거나 선택지 순서를 뒤집거나 섞었을 때는 한 건도 바뀌지 않았다고 합니다. 이 변화는 모두 뜻이 같은 입력입니다.

이번 주 초 저희는 공개 결정 모델 laya가 선택지 이름이 정의와 어긋나면 정의가 아니라 이름을 따른다는 것을 확인했습니다. TREC 정확도가 88.6%에서 22.2%로 떨어졌고, laya의 확률은 틀린 답을 맞은 답보다 더 높게 줄 세웠습니다. 뜻이 같은 입력이 아니라 뜻이 서로 부딪히는 입력입니다. 그래서 Decision-1을 포함한 결정 모델 네 개에 같은 질문을 던졌습니다.

1. 정상 라벨에서 확률 0.9를 기준으로 삼으면 답이 몇 개나 통과하고, 그중 몇 개가 틀리나?
2. 선택지 이름과 정의가 서로 어긋나면 각 모델은 무엇을 따르고, 위 숫자는 어떻게 바뀌나?

Decision-1을 처음 붙여 보신다면 요청 형식과 저희가 부딪힌 점을 정리한 실전 가이드를 먼저 보셔도 좋습니다.

측정 방법

• 데이터: TREC 질문 500개입니다. 질문이 어떤 종류의 답을 원하는지(약어, 사물, 설명, 사람, 장소, 숫자) 고르는 과제이고, 앞 글과 같은 파일과 정의를 썼습니다. AG News 기사 제목 200개도 함께 돌렸는데, 결과가 TREC와 다른 곳만 본문에 적었습니다. decider-ai 1.6.0 소스(decider/data/core.py)의 공개 과제 구성에서 trec은 학습에서 뺀(held-out) 과제로, ag_news는 학습 과제로 지정돼 있습니다. decider 자체의 미세조정 구성일 뿐, 바탕이 된 기반 모델이 TREC를 본 적이 있는지는 알 수 없습니다.
• 모델

- API: Microsoft-Decision-1과 Jev 1.13을 OpenRouter의 System One 엔드포인트로 불렀습니다. 응답에 찍힌 버전은 microsoft-decision-1-20261009, jev-1.13-20260917입니다.

- 로컬: decider-4b v2.1(공식 BF16 GGUF, llama.cpp)과 laya 0.3.7입니다.

• 조건 (요청 하나에 질문 하나)

- 정상: 선택지마다 원래 이름과 정의를 붙입니다.

- 뒤바꿈: 정의마다 다음 범주의 이름을 붙입니다. 그래서 "사람"을 뜻하는 정의에 location이라는 이름이 붙습니다. 정답은 언제나 정의가 뜻하는 범주입니다.

- 역순: 정상 선택지를 순서만 거꾸로 넣습니다.

- 반복: 정상 요청을 한 번 더 보냅니다.

• "바로 처리"의 뜻: 모델의 최고 확률이 0.9 이상이면 그 답을 받아들인다고 보았습니다. 숫자는 세 가지를 냅니다. 받아들인 답의 비율, 받아들인 답 중 틀린 비율, 그리고 전체 500개 중 틀린 채 통과한 수입니다. 0.9는 진단용 기준일 뿐 권장값이 아닙니다. Decision-1과 Jev는 최고 확률과 다른 confidence 값도 따로 돌려주는데, 이 글에서는 처음부터 끝까지 최고 확률을 썼습니다.
• 규칙: 조건, 지표, 결과마다 쓸 문장을 채점 전에 정해 먼저 커밋했습니다. API 요청은 질문마다 순서를 섞어 몇 초 안에 이어서 보냈습니다. API 요청 8,400건이 모두 성공했고(36건은 속도 제한에 걸려 다시 보냄), API 비용은 모두 0.094달러였습니다.

정상 라벨에서

구간은 Wilson 95% 구간입니다.

이 과제에서 0.9 기준으로 가장 많은 답을 통과시킨 모델은 Decision-1이었고, 받아들인 466개 중 6개가 틀렸습니다. decider-4b는 훨씬 조심스러웠습니다. 0.9에 이른 답이 40%뿐이라, 같은 규칙을 쓰면 일의 60%가 사람에게 넘어갑니다. 임계값이 같아도 모델에 따라 사람이 맡을 일의 양이 크게 달라집니다.

아래 그림의 왼쪽은 이 관계 전체를 보여 줍니다. 가장 확신하는 답부터 차례로 받아들일 때, 받아들인 답 중 틀린 비율이 어떻게 늘어나는지를 그렸습니다.

이름과 정의가 어긋나면

Decision-1은 정의를 따랐습니다. 정확도는 96.4%에서 95.2%가 됐습니다. 맞히던 질문 7개가 틀리고 틀리던 1개를 맞혔는데(p = 0.070), 사전에 정한 규칙으로는 차이를 말할 수 없습니다. 다만 변화량의 부트스트랩 구간(−2.4에서 −0.2%p)은 0을 포함하지 않습니다. 그래서 성능이 유지됐다고 단정하지 않습니다. 눈에 띄게 달라진 것은 확신하는 정도입니다. 0.9 이상인 답이 93.2%에서 80.0%로 줄었고, 받아들인 답 중 틀린 답은 정상 라벨에서 466개 중 6개, 라벨을 뒤바꿨을 때 400개 중 5개였습니다. 두 비율은 반올림하면 모두 1.3% 안팎입니다. 확률은 여전히 맞은 답과 틀린 답을 잘 갈랐습니다(AUROC 0.869, 구간 0.779-0.946).

Jev와 decider-4b도 이름보다 정의를 더 많이 따랐지만 정확도는 떨어졌습니다. Jev가 7.8%p, decider-4b가 15.8%p 떨어졌습니다(둘 다 p < 0.001). 두 모델 모두 확신이 크게 줄어서, 0.9 규칙을 쓰면 뒤바뀐 질문의 대부분이 사람에게 넘어갑니다(Jev 57%, decider-4b 88%). 그 대신 받아들인 답은 대부분 맞았습니다.

laya는 앞 글과 마찬가지로 이름을 따랐습니다. 자동 처리에서 문제가 되는 것은 표의 마지막 칸입니다. laya가 90% 이상 확신한 뒤바뀐 질문 115개 중 110개가 틀렸습니다. 확률이 틀린 답을 맞은 답보다 높게 줄 세웠습니다(AUROC 0.362, 구간 0.311-0.415). 이 조건에서는 최고 확률 0.9 기준도 확신에 찬 오답을 걸러내지 못했습니다.

SOTAAZ 강좌

이 강좌만 $10 · 23강 · 전 강의 무료무료로 보기 →

같은 뜻, 다른 순서, 그리고 한 번 더

저희 TREC 500개에서는 선택지 순서를 뒤집어도 Decision-1의 답이 하나도 바뀌지 않았습니다. 데이터는 다르지만, 순서를 바꿔도 답이 바뀌지 않았다는 Microsoft의 보고와 같은 방향입니다.

똑같은 요청을 두 번 보냈을 때는 API 모델 두 개가 로컬 모델과 달랐습니다. Decision-1은 답 1개가 바뀌었고, 확률은 500개 중 439개에서 조금씩 달랐습니다. 500개 전체로 본 차이의 중앙값은 0.0004였지만 41개는 0.01 넘게 달랐고, 가장 큰 차이는 0.060이었습니다. Jev는 답 4개가 바뀌었습니다. 로컬 모델 두 개는 두 번 모두 확률까지 똑같았습니다. 호스팅 모델로 임계값을 맞춘다면, 임계값 근처의 확률은 다음 호출에서 반대편으로 넘어갈 수 있다는 뜻입니다.

AG News 기사 제목 200개에서는 세 가지가 TREC와 달랐습니다.

• Decision-1과 선택지 순서: 순서를 뒤집자 답이 3개 바뀌었고, 같은 요청을 다시 보냈을 때도 2개가 바뀌었습니다. 두 수가 모두 0보다 커서, 여기서는 순서가 영향을 줬는지 말하지 않습니다.
• 라벨을 뒤바꿨을 때 decider-4b: 정확도가 거의 그대로였습니다(90.5%에서 90.0%, 저희 기준으로 차이를 말할 수 없음). TREC에서는 15.8%p 떨어졌습니다. AG News는 decider-4b의 학습 과제이고 TREC는 아닙니다(아래 측정 방법 참고).
• 라벨을 뒤바꿨을 때 Jev: AUROC 구간이 0.5를 포함했습니다(0.62). 그래서 이 경우에는 확률이 여전히 오답을 제대로 가려냈는지 말할 수 없습니다.

이 결과가 말하는 것과 말하지 않는 것

• 말하는 것: 이 과제에서 최고 확률 0.9 규칙을 쓰면, Decision-1은 대부분의 질문을 혼자 처리했을 것이고 받아들인 답 중 1% 남짓만 틀렸을 것입니다. 선택지 이름이 정의와 어긋날 때도 그랬습니다.
• 말하는 것: "확률이 높다"만으로는 안전하지 않습니다. laya는 뒤바뀐 질문 115개에서 90% 넘게 확신했고, 그중 110개가 틀렸습니다.
• 말하지 않는 것: Decision-1이 어디서나 잘 보정돼 있다는 뜻은 아닙니다. TREC는 짧고 깔끔한 6지선다 과제입니다. 실제 숫자는 여러분의 라벨, 데이터, 임계값이 정합니다. 모델에게 처리를 맡기기 전에, 정답을 아는 사례 몇백 개로 먼저 확인해 보시기 바랍니다.
• 말하지 않는 것: 속도는 비교하지 않았습니다. 요청을 하나씩 보냈고, 속도 제한에 걸리면 기다렸습니다.
• 호스팅 모델은 바뀝니다. 이 숫자는 microsoft-decision-1-20261009의 결과입니다. OpenRouter는 가중치가 계속 갱신된다고 밝혔습니다.

한계

• 주 과제 하나(TREC 500개)와 보조 과제 하나(AG News 200개)만 썼습니다. Decision-1과 Jev의 학습 데이터는 공개되지 않았고, TREC는 널리 알려진 데이터셋입니다.
• 반복 조건을 빼면 조건마다 한 번씩만 돌렸습니다.
• 0.9라는 임계값과 최고 확률을 점수로 쓴 것은 저희의 선택입니다. confidence를 쓰면 숫자가 달라집니다.
• laya의 뒤바꿈, 이름만, A/B 라벨 결과는 앞 글의 결과를 다시 썼습니다. 새로 돌린 정상 조건 결과가 앞 글과 확률까지 똑같은 것을 확인한 뒤에 썼습니다.

계획서, 스크립트, 모든 요청과 응답(계정 식별자는 지움)은 아래 재현 패키지에 있습니다. decider-4b를 얼마나 줄이면 확률이 달라지는지는 따로 쓴 글에 정리했습니다.