[기획: AI 트렌드] 글 대신 확률을 돌려주는 AI 모델, 같은 질문에 0.28과 0.45가 나왔다는 보고

세 실행기에 같은 날 같은 기능이 합쳐졌다

10월 12일, llama.cpp 개발자 ngxson이 vLLM Semantic Router 팀의 「결정 모델」 지원을 본 코드에 합쳤습니다. 결정 모델은 글 대신 선택지마다 숫자 하나를 내놓는 AI 모델입니다. llama.cpp는 AI 모델을 실제로 돌려 답을 내 주는 공개 프로그램입니다. 모델은 학습으로 정해진 숫자 묶음이고, 그 숫자로 계산을 해 내는 것은 이런 프로그램의 몫입니다. 이 글에서는 이런 프로그램을 실행기라고 부릅니다.

개발자가 코드 변경을 제안하는 요청을 PR이라고 합니다. 관리자가 PR을 받아들여 본 코드에 합치는 일은 머지라고 합니다. 같은 날 llama.cpp에는 결정 모델 지원 PR이 하나 더 머지됐습니다. 이미 지원하던 모델과 비슷해 코드가 적게 들었다는 설명이 붙었습니다. 두 PR로 지원이 들어간 모델은 vLLM Semantic Router 팀이 만든 결정 모델 두 계열입니다. PR 제목에 붙은 vllm은 이 팀을 가리킵니다. 같은 이름의 실행기 vLLM에서 일어난 일은 따로 있습니다.

같은 날 실행기 Ollama에서도 결정 모델 관련 PR이 머지됐습니다. 이 PR을 올린 개발자 jmorganca는 Ollama가 따로 갖고 있던 채점 코드를 걷어냈습니다. 그리고 llama.cpp에 들어 있는 결정 모델 지원을 그대로 쓰도록 바꿨습니다. 실행기 vLLM에서도 그날 개발자 mgoin이 올린 결정 모델 PR이 머지됐습니다.

프로그램이 요청을 받는 주소를 엔드포인트라고 합니다. Ollama와 vLLM에서 결정 모델을 부르는 엔드포인트는 /v1/systemone으로 같습니다. llama.cpp에는 10월 2일 ngxson이 이 주소를 처음 넣었습니다. 그리고 10월 12일 하루에 세 실행기에서 이 주소로 결정 모델을 다루는 변경이 머지됐습니다.

출력이 글이 아니라 확률인 모델

Ollama 문서에는 결정 모델이 하는 일이 세 가지로 적혀 있습니다. 글을 분류하고, 예/아니오의 확률을 추정하고, 순서가 있는 기준에 점수를 매기는 일입니다. 문서의 예시에는 「bug」라는 선택지에 0.9781이 붙어 있습니다. 같은 예시에는 confidence라는 수치가 따로 붙는데, 선택지에 붙은 숫자와는 다른 값입니다. llama.cpp 코드 주석에도 출력의 i번째 줄이 i번째 선택지의 점수라고 적혀 있습니다. 글로 답하지 않고 선택지마다 숫자 하나를 내는 것입니다.

열흘 전 이 주소를 llama.cpp에 처음 넣은 ngxson은 결정 모델을 두고, 기존 임베딩 모델을 그럴듯하게 감싼 것일 뿐이라고 적었습니다. 임베딩 모델은 글을 숫자 묶음으로 바꿔 주는 모델입니다.

보도(검색 요약으로 확인)에 따르면 이런 모델의 출발점은 지난달 중순 TypeSafe가 내놓은 폐쇄형(회사 서버로만 쓸 수 있는) 모델 Jev였습니다. OpenAI도 이달 초 「Decisions」라는 이름의 지원을 자사 파이썬 개발 도구에 넣었습니다. 회사마다 성능 점수를 매기는 지표와 버전이 달라, 점수끼리는 견주기 어렵습니다(검색 요약으로 확인).

결정 모델을 쓰는 프로그램이라면 이 숫자를 보고 다음 동작을 고르게 됩니다. 가령 「bug」에 붙은 숫자가 미리 정한 기준선을 넘으면 개발팀에 넘기는 식입니다. 그러니 같은 질문에는 같은 숫자가 나와야 합니다.

같은 질문, 0.28과 0.45

세 실행기에서 머지가 이어진 그날, ivoras라는 사용자가 llama.cpp에 버그 보고를 올렸습니다. 막 지원이 들어간 vLLM Semantic Router 팀의 모델에서 생긴 일이었습니다.

실행기는 여러 사람이 보낸 요청을 한꺼번에 묶어 계산하곤 합니다. 이 묶음을 배치라고 합니다. 배달 기사가 같은 방향 주문 여러 건을 한 차에 싣고 나가는 것과 비슷합니다. 같은 차에 다른 주문이 실렸다고 음식 맛이 바뀌어서는 안 됩니다.

ivoras에 따르면 요청 하나를 혼자 보낼 때 「예」일 확률은 매번 0.2839였습니다. 더 짧은 요청과 같은 배치에 넣으면 매번 0.449~0.450이 나왔습니다. 질문은 그대로인데, 함께 묶인 요청에 따라 확률이 0.17가량 오른 것입니다. 그는 보고 제목에 원인 추정도 적었습니다. 짧은 요청과 함께 묶이면 실행기가 이 모델의 입력을 여러 조각으로 나눠 계산한다는 것입니다. 이 모델은 입력 문장의 앞뒤 전체를 한꺼번에 보고 판단하는 방식입니다. 그래서 입력이 조각나면 각 조각이 입력 전체를 보지 못한 채 계산될 수 있습니다. llama.cpp 관리자 ggerganov도 같은 날 수정 PR에서, 이런 방식의 계산은 한 번에 처리되는 묶음 하나에 다 들어가야 한다고 적었습니다. 이 보고에는 「확인 전 버그」 표시가 붙어 있고, 원인도 확정되지 않았습니다.

그날 ngxson이 올린 수정 PR도 머지됐습니다. 이 계열에서 여러 요청을 함께 처리할 때의 문제를 고치는 PR입니다. 그러니 이미 끝난 일로 볼 수도 있습니다. 하지만 ngxson은 설명에 「100% 확실하지는 않지만」이라는 단서를 달고, 문제를 고치는 것 같다고 적었습니다. 이 PR에는 위 버그 보고가 언급되지 않습니다. 보고도 우리가 열어 본 시점에 열린 채였습니다. 이 수정이 그 보고를 닫는지는 아직 확인되지 않았습니다. 그리고 숫자가 달라진 사례는 이 보고 하나가 아니었습니다.

다른 실행기에서도 숫자가 흔들렸다

vLLM 쪽 PR에서도 비슷한 지적이 나왔습니다. bf16은 숫자를 적는 자릿수를 줄인 형식입니다. 계산이 빠른 대신 적을 수 있는 값이 띄엄띄엄 놓인 눈금처럼 정해져 있어서, 값이 조금만 달라져도 한 눈금씩 건너뜁니다. 로짓은 모델이 확률로 바꾸기 전에 내는 원점수입니다. 이 PR을 검토한 리뷰어에 따르면, 동시에 요청이 몰릴 때 한 선택지의 로짓이 이 눈금 하나만큼 움직인다고 합니다. 그러면 박빙인 선택, 즉 두 선택지의 점수가 거의 같던 선택이 뒤집힙니다. 리뷰어는 이 항목에 「별도로 수정됨」이라고 표시해 두었습니다.

이 PR을 올린 mgoin도 차이 하나를 보고했습니다. 목표는 모델 제작자가 내놓은 기준 코드, 즉 참조 구현과 같은 답을 내는 것이었습니다. 그런데 B300이라는 GPU(그래픽 처리 장치)에서 일본어 문항 하나를 돌리자 선택지 확률이 참조 구현과 최대 0.031 달랐습니다. mgoin은 그 원인을 찾지 못했다고 적었습니다.

이만한 차이는 무시해도 된다는 반론이 나올 법합니다. 가장 높은 선택지가 넉넉히 앞서 있으면 맞는 말입니다. 문제는 두 선택지가 박빙일 때입니다. 우리는 확률을 기준선에 견줘 다음 동작을 고를 때도 같은 문제가 생긴다고 봅니다. 앞의 배치 보고에서 나온 차이는 이 범위를 훌쩍 넘습니다.

글로 답하는 보통의 AI 챗봇과 무엇이 다르냐고 물을 수도 있습니다. 우리가 보기에 차이는 출력을 누가 어떻게 받느냐에 있습니다. 글로 된 답은 표현이 조금 달라져도 사람이 읽고 넘깁니다. 결정 모델은 숫자 하나가 곧 출력이고, 그 숫자를 프로그램이 기준선에 바로 견줍니다. 기준선 근처에서는 숫자가 조금만 달라져도 다음 동작이 바뀝니다.

참조 구현과의 차이를 수치로 밝힌 PR은 더 있습니다. 열흘 전 ngxson이 처음 지원을 넣을 때 밝힌 참조 구현과의 최대 확률 차이는 약 0.022였습니다. 10월 12일에 올라온 또 다른 PR의 작성자는 이 비교를 표로 제시했습니다. 이 글에서는 이런 표를 일치표라고 부릅니다. 작성자에 따르면 공개 결정 과제 231건 전부에서 참조 구현과 답이 같았습니다. 확률 차이도 최대 100만분의 2.4였습니다. 같은 모델을 llama.cpp에 이미 있던 가장 비슷한 모델 구조 정의로 읽자 그중 4건의 답이 달라졌습니다. 확률 차이는 0.33까지 벌어졌습니다. 모두 작성자 자신의 시험이고, 이 PR은 아직 머지되지 않았습니다.

확률은 모델 하나의 숫자가 아니다

Ollama 문서에는 confidence라는 수치에 관한 경고도 적혀 있습니다. confidence는 모델이 한 답을 다른 답들보다 얼마나 강하게 고르는지 나타내는 수치입니다. 문서에 따르면 이 수치가 높다고 해서 답이 맞는다는 보장은 없습니다. 일치표로 알 수 있는 것도 실행기가 참조 구현과 같은 숫자를 내는지까지입니다. 그 숫자가 맞는지는 일치표로 알 수 없습니다. 우리는 「5.9GB라던 27B 모델, 본가 llama.cpp가 읽게 된 형식은 약 7.2GB였다」에서도 실행기 사이의 일치 수치가 품질의 증거는 아니라고 봤습니다.

확인할 것은 셋입니다.

• 배치 버그 보고의 처리. 같은 날 머지된 수정이 이 보고를 닫는지, 확인된 버그로 분류되는지 봅니다.
• 일치표가 기본이 되는지. 새 결정 모델 지원 PR마다 일치표가 붙는지 봅니다.
• 성능 지표의 통일. 회사마다 다른 지표와 버전으로 잰 점수가 한 기준으로 모이는지 봅니다.

그날 머지되거나 올라온 PR과 보고에서도, 각 모델의 확률은 입력이 같아도 배치 구성과 동시 부하, 장비에 따라 달라졌습니다. 실행기 구현이 참조 구현과 다른 숫자를 낸 사례도 있었습니다. 이 중에는 고쳐질 버그일 수 있는 차이도, 원인을 모르는 차이도 섞여 있습니다. 그래도 지금 시점에서 우리는 결정 모델의 확률을 모델 하나의 숫자가 아니라, 모델과 실행기와 실행 조건이 함께 낸 숫자로 봅니다. 성능 점수는 회사마다 지표가 다르고 대부분 자체 측정입니다(검색 요약으로 확인). 우리는 그 점수로 내 실행기에서 나올 숫자까지 알 수는 없다고 봅니다. 그래서 이 범주에서는 실행기 PR에 붙는 일치표가 성능 점수만큼 읽을 가치가 있다고 우리는 봅니다.