판정 모델은 문장을 만들지 않고 답을 고른다

기계에게 묻는 방법이 둘이다.

하나는 답을 문장으로 받아서 우리가 다시 읽어 내는 것이다.

하나는 답이 될 수 있는 것을 미리 적어 두고 그중에서 고르게 하는 것이다.

골라 온 답은 읽어 낼 필요가 없고, 대신 무엇을 후보로 적었는지가 답을 좌우한다.

여기까지가 핵심이다

여기서부터는 위 네 줄을 다시 적는다. 이 글의 범위는 답의 후보를 미리 못 박고 묻는 방식이 무엇을 바꾸는가이다. 지표를 만들기 전에 정의를 먼저 적는다는 이야기는 숫자보다 정의를 먼저 쓴다에 두었고, 이 글은 그 순서를 사람이 아니라 기계에게 묻는 자리에 붙인다.

문장을 생성하는 모델에게 “이 문의는 어느 팀 담당인가”라고 물으면 문장이 돌아온다. 소프트웨어는 그 문장을 다시 읽어서 팀 이름을 꺼내야 하고, 모델이 형식을 조금만 다르게 쓰면 그 단계가 깨진다. 은 그 단계를 없애는 쪽을 택한다. 답이 될 수 있는 것을 부르는 쪽이 미리 적어 보내고, 모델은 그중 하나를 확률과 함께 돌려준다. TypeSafe 의 Jev 가 이 방식의 상용 구현이고, 아래 내용은 2026년 9월 21일자 공식 문서를 기준으로 적었다.

정의

단위: 답의 후보가 정해진 질문 하나가 한 건이다. 그 한 건에 고른 답과 확률이 함께 돌아온다.

범위: 후보를 어떻게 적는지, 그렇게 물으면 무엇이 사라지고 무엇이 새로 생기는지를 다룬다.

제외 대상: 모델을 어떻게 훈련하는지, 그 확률을 행동과 금액에 어떻게 연결하는지는 이 글의 범위가 아니다.

실패 조건: 후보 목록을 잘못 적어 놓고 모델이 틀렸다고 판단하는 상태다.

후보를 적는 세 가지 모양

질문에 넣는 입력을 state 라고 부른다. 원문, 신원, 관계, 정책, 지금 확정된 사실을 함께 넣을수록 판정이 정확해진다. 그 state 위에 물을 수 있는 질문의 모양은 셋이다.

모양	묻는 방식	돌아오는 값
Choice	이 문의는 어느 팀 담당인가	적어 둔 후보 중 하나 (`billing`)
Noul	이 메시지가 환불 요청인가	참일 확률 (`0.95`)
Score	이 고객이 얼마나 화가 났는가	서술해 둔 등급 사이의 위치 (`1.4`)

셋 다 답의 공간을 부르는 쪽이 정의한다는 점에서 같다. Choice 는 이름의 목록으로, Noul 은 참과 거짓으로, Score 는 양 끝에 말로 써 둔 눈금으로 공간을 정한다.

서로 독립인 질문은 한 번의 호출에 묶어 같은 state 위에서 함께 묻는다. 묶인 질문끼리는 서로의 답을 보지 못하므로, 한 축의 판정이 다른 축을 물들이지 않는다.

해석하는 단계가 사라진다

두 경로를 나란히 두면 없어지는 칸이 보인다.

문장을 받아서 쓸 때

요청 원문과 함께 무엇을 판단해 달라고 문장으로 적어 보낸다.
응답 설명이 섞인 문장이 돌아온다. 길이와 형식은 매번 다를 수 있다.
해석 받는 쪽이 그 문장에서 값을 꺼낸다. 형식이 어긋나면 여기서 실패한다.

후보를 적어 보낼 때

요청 state 와 함께 답이 될 수 있는 것의 목록을 적어 보낸다.
응답 목록 안의 값 하나와 확률이 정해진 자리에 담겨 돌아온다.
해석 이 칸이 없다. 값을 그대로 쓴다.

세 번째 칸이 사라진 것이 이 방식의 성질이다. 그 대신 첫 번째 칸의 책임이 커진다. 목록에 없는 답은 모델이 고를 수 없으므로, 후보를 잘못 적으면 모델은 잘못된 후보 중에서 성실하게 하나를 고른다.

확률은 판정이 맞을 빈도다

돌아오는 확률은 교정(calibration)되어 있다고 문서가 주장한다. 0.2 를 매긴 건들을 모으면 그중 20% 쯤이 실제로 맞고, 0.8 을 매긴 건들은 80% 쯤 맞는다는 뜻이다.

여기서 한 가지를 분명히 해야 한다. 이것은 개별 답 하나에 대한 보장이 아니라 같은 확률을 받은 무리 전체의 성질이다. 0.8 을 받은 건 하나가 맞을지 틀릴지는 이 성질로 알 수 없다. 알 수 있는 것은 그런 건을 백 개 모았을 때 여든 개쯤 맞으리라는 것뿐이다.

아닌 것

문장을 만드는 모델의 상위 호환이 아니다. 요약, 번역, 코드 작성은 아예 대상이 아니다. 답의 후보를 미리 적을 수 없는 일에는 쓸 수 없고, 그런 일이 여전히 대부분이다.

정확도를 보장한다는 말이 아니다. 교정이 맞추려는 것은 정확도가 아니라 확률의 정직함이다. 확률이 정직하면 언제 사람에게 넘길지 정할 수 있게 되지만, 정직한 0.55 는 여전히 0.55 다.

판정이 맞을 확률과 그 판정대로 했을 때 이길 확률은 다르다. 이 혼동은 돈이 걸린 판단에서 특히 큰 손실을 낳는다. 나는 연준 성명 92건에 “직전보다 매파적인가”를 물어 0.7 이상으로 답한 24건을 골라 봤는데, 그 24건 이후 나스닥이 실제로 내린 비율은 46% 로 동전던지기와 다르지 않았다. 텍스트 판정 자체가 틀린 것이 아니다. 성명이 매파적이어도 시장이 그만큼 예상하고 있었으면 가격은 움직이지 않는데, state 에 그 예상을 넣지 않았다.

한 가지 예시

이 블로그와 별도로 쓰는 개인 위키에 붙여 봤다. 질문을 받으면 색인 240행 중에서 답이 있을 페이지를 고르게 하는 용도다. 질의 한 번에 1초, 입력 2만 토큰, 0.0008 달러가 들었다.

처음에는 색인의 줄마다 번호를 붙이고 그 번호를 Choice 의 후보로 썼다. 답이 매번 1번 행으로 쏠렸다. 후보가 1, 2, 3 이면 그 기호 자체에는 고를 근거가 없으므로, 모델이 판정이 아니라 자리를 고른 것이다. 벤더가 권하는 “해당 없음” 후보를 넣어 봤더니 답이 없어야 하는 질의만 좋아지고 정답이 있는 질의는 0.79 에서 0.44 로 떨어졌다(2회 재현). 번호를 버리고 페이지 이름 자체를 후보로 적자 1위 확률이 1.00 으로 올라가고 쏠림이 사라졌다. 늘어난 토큰은 4% 였다.

후보를 무엇으로 적었는지가 답을 좌우한다는 것이 이 자리에서 나온 결론이다. 모델을 바꾼 것이 아니라 후보 목록만 바꿨는데 판정이 달라졌다.

같은 일이 판단 기준에서도 일어났다. “이 질문에 직접 답하는 페이지가 있는가”로 물었더니 관련 페이지 둘을 정확히 찾아 놓고도 없다고 답했다(0.30). 기준을 “여러 페이지에 나뉘어 있어도 된다”로 고치자 0.55 로 올라갔고, 대조로 둔 없는 주제의 질의는 0.02 에 그대로 있었다.

다음에 열 것

이 글의 범위는 후보를 적어 묻는 방식까지다. 아직 다루지 않은 내용은 아래와 같다.

확률을 행동에 잇는 다리: 판정이 맞을 확률을 성과에 곱하기 전에 무엇을 먼저 검사해야 하는지, 사실과 해석과 결정을 어떤 층으로 나눠야 하는지.
state 설계: 무엇을 넣고 무엇을 빼야 판정이 쓸모를 갖는지. 위의 연준 사례가 실패한 자리다.
좁히기와 판정의 분업: 로컬 임베딩으로 후보를 240행에서 20행으로 줄이고 판정만 외부에 맡기면, 비용과 후보 수 상한과 외부로 나가는 내용이 함께 줄어든다.