Hugging Face, 결정 모델의 공통 인터페이스 제안: Transformers에 DecisionPipeline과 /v1/systemone 엔드포인트가 추가되고 llama.cpp도 같은 API로 제공하며 choice·score·noul 세 프리미티브가 확률을 돌려줌, 정확도·보정·지연 벤치마크는 없고 예시 숫자도 완전히 일관되지는 않음

2026년 11월 10일 Hugging Face는 Aritra Roy Gosthipaty, Lysandre, Pedro Cuenca, Tom Aarsen이 쓴 긴 글 "Decision Models in Hugging Face"를 발표했습니다. 이 글은 텍스트를 쓰지 않는 종류의 모델을 위한 공통 인터페이스를 설명합니다. 결정 모델(decision model)은 고객 메시지 같은 상태와, 유형이 정해지고 허용 답이 있는 질문 묶음을 읽고, 확률이 붙은 구조화된 결정을 돌려줍니다. 글에 따르면 모델은 토큰을 하나씩 생성하는 대신, 애플리케이션이 이미 이해하는 답에 확률을 배정합니다. 인터페이스는 "State + Questions + Allowed Answers → Decisions + Probabilities"로 적혀 있습니다. 글은 이 발상을 TypeSafe AI가 Jev라는 이름으로 내놓고 "System One 모델"이라 불렀으며, 이후 커뮤니티가 사고 이론이 아니라 모델의 역할을 뜻하는 "decision model"이라는 용어로 모았다고 말합니다.

출발점이 되는 예는 지원 문의입니다. "구독료가 두 번 청구됐어요. 오늘 환불이 필요합니다." 애플리케이션은 여기서 세 가지를 알고 싶어 합니다. 어느 팀이 처리해야 하는지, 얼마나 급한지, 고객이 환불을 요청하는지입니다. 글은 먼저 언어 모델이 이 답을 담은 JSON을 쓰게 하는 방법을 보여 준 뒤 다른 방식을 주장합니다. 언어 모델에 구조화된 출력을 요청할 때의 문제를 세 가지 듭니다. 모델이 요청한 스키마를 지킨다는 보장이 없어서 잘못된 JSON, 예상치 못한 키, 허용된 선택지 밖의 답을 낼 수 있습니다. Outlines나 XGrammar 같은 제약 디코딩 라이브러리는 문법을 강제하지만 자체 작업이 더해집니다. 그리고 애플리케이션이 고정된 답 중에서 고르기만 하면 될 때 응답 전체를 생성하는 것은 불필요한 일입니다. 글은 이 점들을 뒷받침하는 측정된 속도, 비용, 정확도 비교를 싣지 않으므로, 이것들은 결과가 아니라 주장입니다.

질문에는 프리미티브라고 부르는 세 가지 유형이 있습니다. choice(선택) 질문은 여러 답 중 하나를 고르고 각 답의 확률을 돌려줍니다. score(점수) 질문은 순서가 있는 척도에서 무언가를 평가해 단계 번호의 기댓값을 돌려줍니다. 세 번째는 베르누이 분포에서 이름을 딴 "noul"로, 예/아니오 질문에 그 진술이 참일 확률로 답합니다. 선택과 점수 질문에는 결과에 confidence(신뢰도) 필드도 붙습니다. K개 선택지가 있는 선택에서 신뢰도는 최대 확률에서 1/K를 뺀 값을 1에서 1/K를 뺀 값으로 나눈 것이어서, 균등 분포면 0이고 완전히 한곳에 몰리면 1입니다. 글의 예에서 부서 질문은 "billing"을 확률 0.998, 신뢰도 0.997로 돌려줍니다. 긴급도 점수는 1.705이고 신뢰도는 0.558인데, 글은 이를 분포에 대한 기댓값이며 "중간"과 "높음" 사이의 단계가 아니라고 설명합니다.

글은 결정 모델을 두 가지 기존 방식과 비교합니다. 전통적 분류기는 출력 클래스가 분류 헤드에 고정돼 있어, 법무 같은 네 번째 부서를 추가하려면 새 데이터와 재학습이 필요할 수 있습니다. 제로샷 분류는 추론 시점에 레이블을 주며, 글은 청구, 기술 지원, 영업, 그리고 변경 후 법무에 대한 점수를 돌려주는 모델을 보여 줍니다. 글은 결정 모델의 장점이 런타임 레이블이나 확률을 발명한 데 있지 않다고 말합니다. 같은 상태에 대해 유형이 있는 여러 질문을 던질 수 있고, 순서형 점수와 예/아니오 결정을 기본으로 지원하는 하나의 인터페이스로 묶었다는 점입니다. 글 자체의 표에서 분류는 선택지에 대한 확률을 주지만 추론 시점에 레이블을 정의할 수 없고, 유형이 있는 여러 질문은 결정 모델만 갖습니다.

도구에 변화를 주는 것은 Hugging Face 스택의 지원입니다. Transformers에는 이제 DecisionPipeline, AutoModelForDecision 클래스, DecisionConfig 클래스가 있습니다. 호환되는 버전의 Transformers로 "transformers serve"를 실행하면 /v1/systemone 엔드포인트가 열리고, 글은 세 질문을 담은 요청 하나가 유형이 있는 세 답을 돌려주는 예를 보여 주며 사용량은 입력 148토큰, 출력 0토큰입니다. llama.cpp도 같은 API로 결정 모델을 제공합니다. 예에서는 "llama serve -hf ggml-org/Kev-4B-GGUF"를 실행하며 기본 서버 포트는 9931입니다. 글은 이 인터페이스가 호환되는 자기회귀 언어 모델에서도 동작한다고 덧붙입니다. Transformers가 결정 프롬프트를 만들고, 한 번의 배치 순전파로 답 레이블의 로짓을 읽어 softmax를 적용하며 텍스트는 생성하지 않으므로, 새 모델을 학습하지 않고도 인터페이스를 시험해 볼 수 있습니다.

발견과 학습에 관해서는, Hub에 새 "decision-model" 태그가 생겼습니다. 글에 따르면 결정 모델이 같은 백본을 공유할 필요는 없어서, 일부는 ModernBERT 같은 인코더 기반이고 일부는 더 큰 생성형 언어 모델 기반입니다. 학습에서는 결정 모델을 Trainer API로 미세조정할 수 있습니다. 글은 일부러 작게 만든 예를 주는데, 지원 메시지 6건으로 autotrust/JEV-9B를 학습률 1e-3으로 30스텝 미세조정하며, 선택 질문에는 선택지에 대한 일반 교차 엔트로피를 씁니다. 글은 TRL의 정식 학습 지원이 곧 온다고 하며, 관련 풀 리퀘스트 huggingface/trl#8040이 글을 쓰던 시점에 아직 열려 있었다고 밝힙니다. 또 Qwen 같은 모델을 LoRA와 결정 점수 헤드로 미세조정하는 Unsloth 레시피도 안내합니다.

독자가 염두에 둘 한계가 있습니다. 글 본문은 이름이 언급된 어떤 결정 모델에 대해서도 정확도, 보정, 지연에 관한 벤치마크를 싣지 않으므로, "믿을 만하고 보정된 결정"은 글이 밝히는 목표이지 발견이 아닙니다. 이 기사는 글에 링크된 이미지나 페이지를 열어 보지 않았습니다. 예시 숫자도 완전히 일관되지는 않습니다. 한 표에는 긴급도 확률이 0.10, 0.26, 0.72로 나오는데 셋을 더하면 1.08이므로 이 표는 유효한 확률 분포가 아니고, 출력된 결과는 0.0149, 0.2648, 0.7203입니다. 한 문장은 이기는 확률을 0.80이라 하고서 이어 0.99로 계산합니다. 선택지가 셋일 때 공식은 0.80이면 신뢰도 0.70, 0.99이면 0.985를 주는데, 글에는 0.98로 찍혀 있습니다. 출력값 가운데 두 가지는 출력된 확률로 다시 계산할 수 있습니다. choice 신뢰도는 (0.99827 − 1/3) ÷ (1 − 1/3) ≈ 0.9974, score 기댓값은 0 × 0.0149 + 1 × 0.2648 + 2 × 0.7203 ≈ 1.705로, 둘 다 출력된 결과와 맞습니다. 글은 score 신뢰도의 공식을 밝히지 않으므로, 앞의 0.558은 글이 보고한 값일 뿐이며 이 기사에서 검증하지 않았습니다. 표와 본문 속 숫자는 예시로 읽어야 합니다. 언급된 모델 autotrust/GEV-26B-Decide, ggml-org/Kev-4B-GGUF, autotrust/JEV-9B는 이 기사에서 시험하지 않았고, 글은 이름 외의 라이선스나 사양을 밝히지 않습니다.

지금 JSON을 쓰는 언어 모델로 티켓을 분류하고 위험을 점수화하거나 콘텐츠를 거르는 팀에게 실무적인 질문은 좁습니다. 고정된 답에 확률을 돌려주는 모델이 그 결정에 맞는지, 그리고 자기 언어와 분야에서 충분히 좋은 체크포인트가 있는지입니다. 글이 제공하는 것은 공통 API, 일반 언어 모델에서 시험해 보는 방법, 작은 학습 레시피입니다. 결정 모델이 현재 방식을 이긴다는 증거는 제공하지 않습니다. 그 비교는 팀 자신의 데이터로 해야 합니다.