Hugging Face의 의사결정 모델 – 구조화된 확률적 출력을 위한 새로운 인터페이스

TL;DR

Hugging Face는 컨텍스트(상태)와 구조화된 질문을 받아 선택지, 점수 또는 신뢰도가 포함된 이진 확률을 반환하는 의사결정 모델(decision‑model) API를 도입했습니다. 이를 통해 애플리케이션이 구조화된 의사결정만 필요로 할 때 텍스트 생성 과정을 거칠 필요가 없어집니다.

의사결정 모델이란 무엇인가

의사결정 모델은 상태(state)(모든 입력 데이터)와 choice(선택), score(점수), **noul(이진)**이라는 세 가지 기본 요소로 정의된 질문 세트를 입력받아, 선택된 답변(또는 기대값)과 전체 확률 분포가 포함된 decision(의사결정) 객체를 반환합니다.

State + Questions + Allowed Answers → Decisions + Probabilities

이 모델은 자유 형식의 텍스트를 생성하지 않습니다. 대신 각 가능한 답변에 대한 로짓(logit)을 직접 평가하고 소프트맥스(softmax)를 적용하여, 애플리케이션이 프로그래밍 방식으로 사용할 수 있는 보정된 확률을 산출합니다.

일반적인 LLM 프롬프팅을 대체해야 하는 이유

표준 LLM을 사용하여 JSON을 출력하는 방식에는 세 가지 단점이 있습니다:

  1. 스키마 위반 – 모델이 잘못된 형식의 JSON이나 예상치 못한 키를 생성할 수 있습니다.
  2. 디코딩 오버헤드 – 제약 조건이 있는 생성 도구(예: Outlines, XGrammar)는 스키마를 강제하지만 계산 비용을 추가합니다.
  3. 불필요한 생성 – 자기회귀 디코딩은 이산적인 의사결정만 필요할 때도 전체 토큰 시퀀스를 계산합니다.

의사결정 모델은 토큰 수준의 생성을 완전히 우회함으로써 이러한 문제를 방지합니다.

기존 분류 접근 방식과의 비교

속성 전통적 분류기 제로샷 분류기 의사결정 모델
선택지에 대한 확률 ✅ ✅ ✅
추론 시 정의된 레이블 ❌ ✅ ✅
요청당 다중 유형 질문 ❌ ❌ ✅
순서형 점수 및 이진 Bernoulli 결정 지원 ❌ (작업별) ❌ (적응 필요) ✅

전통적인 분류기는 고정된 헤드를 가지고 있어, 새로운 레이블을 추가하려면 아키텍처 변경과 재학습이 필요합니다. 제로샷 분류기는 런타임 레이블을 허용하지만 요청당 단일 분류 작업으로 제한됩니다. 의사결정 모델은 이 패러다임을 단일 호출 내의 다중 유형 질문으로 확장합니다.

세 가지 기본 요소 상세 설명

Choice – 이산 옵션에 대한 확률 분포

모델은 옵션당 로짓을 반환하며, 소프트맥스를 통해 확률로 변환됩니다. 가장 높은 확률의 옵션이 choice로 보고되며, confidence 지표가 분포의 뾰족한 정도를 정량화합니다.

{
  "department": {
    "type": "choice",
    "choice": "billing",
    "confidence": 0.9974,
    "probabilities": {
      "billing": 0.9983,
      "technical": 0.0010,
      "sales": 0.0007
    }
  }
}

Score – 순서형 척도의 기대값

순서형 질문(예: 긴급도)의 경우, 모델은 각 단계에 대한 확률을 반환하고 **기대 지수(expected index)**를 점수로 계산합니다.

{
  "urgency": {
    "type": "score",
    "score": 1.70,
    "legend": {"0":"low","1":"medium","2":"high"},
    "confidence": 0.558,
    "probabilities": {"0":0.015,"1":0.265,"2":0.720}
  }
}

Noul – Bernoulli (예/아니오) 확률

이진 결정은 *P(yes)*를 나타내는 단일 확률 noul을 반환합니다.

{
  "refund": {"type": "noul", "noul": 0.995}
}

신뢰도 지표

choice 및 score 질문의 경우, confidence는 상위 확률이 균등 기준치를 얼마나 초과하는지를 측정합니다:

$$C = \frac{p_{\text{max}} - \frac{1}{K}}{1 - \frac{1}{K}}$$

여기서 K는 옵션의 수입니다. 균등 분포는 C = 0을 산출하고, 결정론적 분포는 C = 1을 산출합니다.

생태계 통합

1. 🤗 Transformers를 통한 서빙

  • 새로운 클래스: DecisionPipeline, AutoModelForDecision, DecisionConfig.
  • 다른 파이프라인과 동일한 API; /v1/systemone HTTP 엔드포인트 지원.
  • 예시 curl 요청은 세 가지 유형의 답변과 토큰 사용 통계가 포함된 JSON 객체를 반환합니다.

2. llama.cpp를 통한 서빙

  • llama.cpp는 동일한 /v1/systemone API를 구현하여, GGUF 의사결정 모델(예: ggml-org/Kev-4B-GGUF)을 코드 변경 없이 서빙할 수 있습니다.
  • 백엔드 전반에 걸친 진정한 인터페이스 호환성을 보여줍니다.

3. 허브에서 모델 탐색

  • 전용 decision-model 태그는 아키텍처(인코더 전용, 생성형 LLM, 멀티모달 변형)에 관계없이 모델을 집계합니다.
  • 사용자는 허브 UI를 통해 트렌드 의사결정 모델을 탐색할 수 있습니다.

4. 의사결정 모델 학습

  • 의사결정 모델은 Transformers 라이브러리의 일급 객체이며, 표준 Trainer API로 미세 조정할 수 있습니다.
  • 간단한 예제로 JEV-9B를 소규모 라우팅 데이터셋에서 미세 조정하여, model.decision_config.prepare_inputs로 입력을 준비하고 선택 로짓에 대해 교차 엔트로피 손실을 계산하는 방법을 보여줍니다.
  • 곧 제공될 TRL 지원(huggingface/trl#8040)은 학습 파이프라인을 단순화할 것입니다.
  • Unsloth는 생성형 LLM(예: Qwen)을 의사결정 모델로 변환하는 LoRA 기반 레시피를 제공합니다.

개발자를 위한 시사점

  • 지연 시간 감소 – 토큰별 생성이 없으며, 단일 순방향 패스로 모든 답변을 얻습니다.
  • 더 높은 신뢰성 – 구조화된 출력은 스키마 준수를 보장하여 사후 처리 검증을 제거합니다.
  • 유연성 – 런타임에 정의된 답변 세트와 다중 질문 유형을 통해 단일 요청으로 복잡한 의사결정 워크플로우(라우팅, 점수 매기기, 이진 검증)를 수행할 수 있습니다.
  • 생태계 결속 – 공유 인터페이스를 통해 추론 서버, 모델 허브, 학습 도구가 모델별 어댑터 없이 상호 운용될 수 있습니다.

결론

의사결정 모델은 분류의 재발명이 아니라, 확률적 의사결정을 소프트웨어를 위한 일급 출력으로 만드는 표준화된 비생성적 계약입니다. Hugging Face는 choice, score, 이진 기본 요소를 공통 API로 통합함으로써 다양한 모델 백엔드와 다운스트림 애플리케이션 전반에서 신뢰할 수 있고 보정된 의사결정을 가능하게 합니다.

Sources