거대 모델에게 객관식 답변을 시키는 것을 멈추세요

에이전트의 받은 편지함으로 지원 이메일이 도착합니다.

에이전트가 단 한 마디를 쓰기 전에, 다섯 번의 작은 호출을 합니다. 이것이 프롬프트 인젝션인가? 얼마나 급한 일인가? 고객이 실제로 원하는 것은 무엇인가? 어떤 도구가 먼저 실행되는가? 초안은 가져온 문서에 의해 뒷받침되는가?

이 모든 것이 객관식 질문입니다. 제가 본 대부분의 스택에서는, 이 모든 것을 가장 큰 모델에게 보내고, 그 모델이 단락을 작성하면 정규표현식(regex)이 그것을 분해합니다.

오직 선택만 하는 모델

Jeff는 정확히 그러한 호출을 위해 구축된 0.8B 오픈 모델입니다. 상황과 레이블이 지정된 옵션 목록을 제공하면, 한 번의 순방향 패스(forward pass)에서 각 옵션에 대한 확률을 반환합니다. 텍스트를 작성하지 않기 때문에 파싱할 것이 없습니다.

저자는 이를 '시스템 1' 모델이라고 부릅니다. 즉, 빠르고 반사적인 절차와 느리고 신중한 거대 모델로 구성된 스택의 절반입니다. 이는 호스팅되는 의사 결정 API에 대한 오픈 소스 시도로 집에서 구축되었으며, HN 스레드는 이번 주에 574 포인트를 기록했습니다.

기본 모델은 제공되는 모든 옵션에 대해 제로샷(zero-shot)으로 처리합니다. 그 위에 각각의 작업별로 약 41MB 크기의 작은 LoRA 어댑터가 아홉 개 올라갑니다: 프롬프트 인젝션 방어, 티켓 분류, 도구 선택, 근거 확인(grounding checks), 스팸 등 몇 가지 더입니다. README에 따르면, 각 어댑터는 하나의 GPU에서 한 에포크 동안, 30분에서 4시간 만에 훈련되었습니다.

제가 코드를 읽게 만든 수치들

헤드라인 설정이 제가 관심을 갖는 부분입니다. Jeff가 먼저 답변합니다. 그것이 확신하지 못할 때만 질문이 Qwen3.8-27B로 넘어갑니다. 27B 모델이 모든 것을 혼자 결정하는 것에 맞서, 여덟 개의 어댑터를 거치면서:

이 수치들은 두 모델을 MLX에 모두 올리고 27B의 단계별 추론(step-by-step reasoning) 기능을 꺼둔 M4 Max에서 얻은 프로젝트의 결과입니다. 제가 신뢰하게 된 세부 사항은 '불확실할 때' 라인이 설정된 방식입니다. 각 어댑터의 신뢰도 임계값(confidence threshold)은 별도의 보정 행(calibration rows) 세트에서 선택되었으며, 테스트 행이 채점되기 전에 고정되었습니다. 많은 모델 README에는 이 단계가 생략되어 있습니다.

또한 작은 모델이 승리하지 못하는 과제도 보여줍니다. 근거 제시(grounding, 이 답변이 출처에 의해 뒷받침되는가?)의 경우, 27B 단독으로 96.7%를 기록하고 Jeff는 96.3%로 끝납니다. 이는 300개의 질문 중 하나이며, 속도는 20배 빠릅니다. 근소한 차이로 패배하는 결과표는 홍보 자료라기보다는 측정치처럼 보입니다.

추론 없이 결정하는 방법

서버는 작은 FastAPI 앱입니다. 경로는 /v1/systemone입니다. 내부적으로 모델은 모든 옵션의 점수를 매기고, 소프트맥스(softmax)가 이 점수들을 확률로 변환합니다. 반환되는 사용량 블록에는 항상 output_tokens: 0이라고 적혀 있습니다.

제가 마음에 들었던 플래그 중 하나는 orders: 2입니다. 이 기능은 같은 질문을 옵션을 역순으로 두어 두 번째로 물어본 다음, 그 두 결과를 평균냅니다. 모델들은 목록 상단 근처의 옵션에 치우치는 경향이 있는데, 이는 두 번의 처리 과정을 거치면서 어느 정도 이를 상쇄합니다.

README 자체 예제에서 각색한 Python 클라이언트입니다 (저는 이것을 실행하지 않았습니다):

from jeff import Client
from jeff.client import choice_question

...

모든 답변에는 key, probability, 그리고 confidence가 포함되며, 여기서 confidence는 0(추측보다 나은 것이 없음)부터 1(확실함)까지의 범위입니다. 이 마지막 필드가 핵심 트릭입니다. 서버는 또한 루트 URL에서 수동으로 질문을 시도해 볼 수 있는 플레이그라운지 페이지를 제공합니다.

결정은 생성이 아니다

제가 확장하고 싶은 주장은 다음과 같습니다. Jeff의 도움을 받든 안 받든 말입니다. 에이전트가 거대 모델에게 '어떤 도구를 사용할까요?'라고 물으면, 프롬프트 비용을 지불하고 몇 초를 기다린 후 산문(prose) 답변을 받고 그것을 파싱해야 합니다. 게다가 얼마나 확신했는지에 대한 정직한 신호도 얻지 못합니다. 분류기(classifier)는 보정된 확률(calibrated probability)을 제공하며, 그 확률 자체가 핵심 특징입니다. 이는 언제 에스컬레이션(escalate)해야 하는지를 정확히 알려줍니다.

이것은 일반적인 설계 방식을 뒤집습니다. 거대 모델은 모든 작은 호출에 대한 기본값이 되는 것이 아니라, 어려운 경우를 위한 폴백(fallback)이 됩니다. 에이전트 루프가 빨라지고, 청구서 금액은 줄어들며, 대부분의 스택에서 부족한 무언가를 얻게 됩니다. 바로 '확신하지 못하니 더 똑똑한 사람에게 물어보세요'라고 말해주는 숫자를요.

제가 시작할 곳은 가드 어댑터(guard adapter)입니다. 모든 도구 출력 앞에 프롬프트 주입 검사(prompt-injection check)를 하는 것은, 테이블당 체크 시간이 약 0.1초 정도 걸리므로 모든 것에 적용하기에 충분히 저렴합니다.

주의할 점 (Where it bites)

이러한 경계면들은 현실이며, 이슈 트래커도 이를 솔직하게 보여줍니다.

• 한 번에 하나의 결정만 가능합니다. 서버는 기다리지 않고 잠금(lock)을 획득합니다. 다른 요청과 중복되는 요청은 HTTP 529 오류와 함께 1초 재시도 힌트를 받습니다. issue #7에서, 동시성(concurrency)이 단지 2인 경우 평가를 수행했을 때 287개 행 중 100개가 손실되었습니다. Python 클라이언트는 재시도를 하지 않으므로, 큐는 사용자가 직접 관리해야 합니다.
• 노트북 숫자는 헤드라인에 쓸 만한 수치가 아닙니다. 대략 30ms라는 수치는 거대한 하드웨어에서 나온 것입니다. Issue #8에서는 노트북 RTX 3070 Ti를 사용하여 약 2GB만 사용했을 때, 중앙값(median)이 144ms에서 274ms 사이였습니다.
• 제로샷 성능은 고르지 않습니다. HN 스레드에서 한 사용자는 자신이 수행하는 작업에서는 70%의 성능을 보였지만, 비교한 호스팅 API는 94%를 기록했습니다. 또 다른 사용자는 0.8B 모델이 채용 공고 레이블에는 쓸모없다고 평가하고 2B 모델이 더 낫다고 했습니다. README에 있는 큰 수치들은 어댑터에서 나온 것입니다. 단독으로만 보면 기본 점수는 가드 작업에서 46.9%입니다. 하지만 가드 어댑터를 사용하면 98.4%를 기록합니다.
• 미리 보기 버전입니다. README에서는 v1.2를 커뮤니티 미리 보기(community preview)라고 부르며, 장기적인 기반이 될 v1.3이 임박했다고 말하고 있습니다.

어댑터(Adapters)는 베이스 버전 간에 가져가지지 않지만, 학습 데이터는 그렇게 됩니다.

유지 관리자는 빠르게 움직입니다. Issue #1에서 26일 이후로는 어떤 옵션도 선택되지 않았다는 것을 발견했습니다. 이는 수정되어 며칠 만에 v1.1로 출시되었으며, 학습 데이터에는 32,000개의 추가 긴 목록 질문이 포함되었습니다.

제가 실행하지 않은 것들

저는 README, 서버 및 클라이언트 코드를 읽었고, 세 개의 이슈와 HN 스레드를 확인했습니다. 하지만 직접 실행하지는 않았습니다. 설치 과정은 전체 Python ML 환경과 1.7 GB 모델 다운로드가 필요하며, 이는 포스팅 하나에 설치하기에는 너무 많은 양입니다. 위에 언급된 모든 숫자는 프로젝트 자체의 수치이거나 특정 이슈에서 가져온 것입니다.

직접 시도해 보신다면, 서버를 시작하고 플레이그라운드를 열어 직접 받은 다섯 개의 인박스 질문을 던져보세요.

당신의 에이전트(agent) 결정 중 0.8B 모델에게 가장 먼저 맡기고 싶은 것은 무엇이며, 절대로 맡기지 않을 결정은 무엇인가요?