LLM logprobs로 만든 Jev식 단일 토큰 분류 래퍼 (비전 모델 포함)

TL;DR Highlight

답을 글자 1개로 강제하고 logprobs를 읽었더니 웹캠 프레임도 분류됐다

Who Should Read

LLM으로 분류·라우팅 판단을 빠르고 싸게 하고 싶은 백엔드 개발자

Core Mechanics

답을 알파벳 한 글자로 강제한다
- State, Question, 보기 [A][B][C]를 프롬프트에 넣고 글자 하나만 답하게 한다.
- max_completion_tokens를 1로 두어 긴 답변 생성을 피한다.
logprobs로 후보별 확률을 읽는다
- logprobs: true와 top_logprobs: 20을 요청에 추가한다.
- 응답에는 선택한 글자와 대안 토큰들의 로그 확률이 같이 온다.
질문마다 한 번씩 호출한다
- 질문이 여러 개면 같은 State에 질문만 바꿔 반복 호출한다.
- 백엔드가 지원하면 공통 State 앞부분은 KV 캐시(이전 계산 재사용)로 아낄 수 있다.
비전 모델에도 그대로 통한다
- 글쓴이는 Jev 요청 형식에 attachments 필드를 직접 추가해 이미지를 보냈다.
- 웹캠 프레임을 base64 JPEG으로 보내 사람 유무, 실내외, 밝기를 표로 출력한다.
속도는 로컬이 훨씬 빨랐다
- RTX 3090의 Gemma 4 12B는 프레임당 질문 3개로 약 1 FPS가 나왔다.
- OpenAI gpt-6-luna는 약 0.2 FPS였다.

Community Reactions

입력보다 보기를 앞에 두라는 의견
- 트랜스포머는 과거 토큰만 보므로 보기를 State 앞에 두면 모든 단어가 보기를 고려해 처리된다는 블로그 댓글이 있었다.
- 그러면 reasoning을 꺼서 시간과 비용을 아끼고 결과도 좋아질 수 있다고 한다.
보기 밖 답이 나오면 어쩌냐는 반론
- "D"나 "추가 정보 필요"라고 답하면 어떻게 되냐는 질문이 나왔다.
- 보정(calibration)도 없다는 지적이 함께 있었다.
Jev보다 못할 거라는 의견
- 일반 LLM은 RLHF와 에이전트용으로 훈련돼 확률이 덜 정확할 거라는 의견이 있었다.
- 일부는 Jev보다 비용이 수십~수백 배 크고 느리다고 평가했다.
지연 시간 경험과 래퍼 공유
- 말이 끝났는지 판단하는 실시간 용도에서 같은 프롬프트의 일반 LLM이 Jev보다 느리고 망설였다는 경험이 있었다.
- 임의의 OpenAI 호환 엔드포인트에서 Jev를 쓰게 해 주는 래퍼 jevper를 만들었다는 댓글이 있었다.

How to Apply

기존 분류 호출에 logprobs 붙이기
- 오늘 라우팅이나 분류 프롬프트 하나를 골라 보기에 글자를 붙인다.
- max_completion_tokens 1, logprobs true, top_logprobs 20을 넣고 확률 분포를 찍어 본다.
확률로 자동 처리 임계값 정하기
- 1위 글자 확률이 낮으면 사람 검토나 큰 모델로 넘기는 분기를 만든다.
- 로그 샘플로 임계값을 정한다.
보기를 State 앞에 배치해 비교하기
- 같은 입력에서 보기를 앞에 둔 버전과 뒤에 둔 버전의 정확도를 비교한다.
- reasoning을 끄고 지연과 비용도 함께 잰다.
공통 State를 접두사로 고정하기
- 질문이 여러 개면 State를 프롬프트 앞부분에 고정하고 질문만 뒤에 붙인다.
- 백엔드의 prefix 캐시 지원 여부를 확인한다.

Try It

복사해서 바로 해보기

# Claude나 ChatGPT에 붙여넣는 프롬프트 (원문 방식의 간이 버전: logprobs 대신 글자 하나로 답하게 함)

State: {{상황 설명}}

Question: {{질문}}
Options:
[A] {{보기1}}
[B] {{보기2}}
[C] {{보기3}}

Answer with the letter of the best option only.

# API로 돌릴 때는 아래 파라미터를 추가해 보기
# max_completion_tokens: 1, logprobs: true, top_logprobs: 20

# 이어서 해 볼 것: 보기를 State 앞으로 옮겨 결과가 달라지는지 비교

Terminology

logprobs모델이 각 토큰을 고를 확률을 로그로 보여주는 값이다. 객관식에서 보기별 확신도를 보는 것과 비슷하다.

KV 캐시앞부분 입력을 처리한 중간 계산을 저장해 두고 재사용하는 기법이다. 같은 머리말이 반복될 때 계산을 건너뛴다.

Jev원문에서 언급된 프로젝트로, 텍스트 State와 질문 형식으로 판단 확률을 얻는 API다. 글쓴이는 이를 흉내 낸 래퍼를 만들었다.

Grammar-Based Decoding출력이 정해진 문법이나 JSON 형식만 따르도록 생성을 제한하는 방식이다. 댓글에서 Jev와 같은 것이냐는 질문이 나왔다.