Decision Models in Hugging Face

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Hugging Face의 decision model은 텍스트를 생성하는 대신 주어진 상태와 허용된 답을 평가해 여러 유형의 결정과 확률 분포를 반환하는 인터페이스를 제시한다.

📌 핵심 요약

• LLM으로 분류·라우팅 결과를 JSON으로 생성할 수 있지만, 스키마와 허용 선택지를 따르지 않을 수 있으며 Outlines·XGrammar를 통한 제약 디코딩에도 추가 연산이 필요하다.
• 전통적 분류기는 출력 클래스가 분류 헤드에 고정되지만, 제로샷 분류는 추론 시 후보 라벨을 지정한다. decision model은 이를 여러 이름 붙은 질문과 서로 다른 답변 유형을 처리하는 공통 인터페이스로 확장한다.
• decision model은 state와 questions를 입력받으며, Choice는 대안 선택, Score는 순서가 있는 척도의 평가, Noul은 예·아니요 질문의 확률적 판단을 나타낸다.
• transformers의 decision 파이프라인과 autotrust/GEV-26B-Decide를 사용한 Choice 예시는 중복 결제·환불 요청의 담당 부서로 billing을 선택하며, billing의 확률은 약 0.99827이다.
• Score는 가장 가능성 높은 등급만 고르는 대신 등급 인덱스의 기댓값을 반환하며, 긴급도 예시의 코드 출력은 약 1.70539이다. 설명 표의 확률은 코드 출력과 다르고 합계도 1이 아니며, 제공된 원문은 Score 설명 도중 끝난다.

🧩 주요 포인트

1. 추론 시 후보 라벨 지정 → 범주 변경의 유연성은 제로샷 분류에도 있으므로, decision model의 차별점은 여러 질문과 Choice·Score·Noul을 일관되게 다루는 인터페이스에 있다.
2. 허용된 답의 직접 평가 → 이미 선택지가 정해진 분류·라우팅 작업에서 전체 JSON 응답을 자기회귀적으로 생성해야 하는 필요성을 줄이는 접근이다.
3. 선택 결과와 전체 확률 분포 제공 → 대안 사이의 확률 배분과 순서 척도의 기댓값을 함께 해석할 수 있지만, 원문의 수치 불일치와 설명 중단을 고려해야 한다.

🧠 상세 정리

1. 텍스트 생성에서 선택지 평가로

글은 LLM이 질문 응답, 코드 작성, 문제 추론에 뛰어나지만 모든 문제가 텍스트 생성을 요구하지는 않는다는 문제의식으로 시작한다. 구독료가 두 번 청구되어 당일 환불을 요구하는 고객 문의에서는 담당 팀, 긴급도, 환불 요청 여부를 판단하는 것이 핵심 과제다. LLM에 JSON 출력을 요청하는 예시는 Billing, High, true를 반환하지만, 글은 같은 과제를 가능한 답의 직접 평가로 처리할 수 있는지 묻는다. 이어 transformers의 decision 파이프라인과 autotrust/GEV-26B-Decide를 사용해 담당 부서와 선택지별 확률을 반환하는 사례를 제시한다. 이 전환의 핵심은 애플리케이션이 이미 이해하는 답들에 확률을 부여하고, 그 결과를 구조화된 결정으로 받는 것이다.

2. decision model의 정의와 명칭

decision model은 입력 맥락인 state를 받아 사전에 정의된 가능한 답을 기준으로 질문을 평가하고, 구조화된 결정과 확률을 반환하는 모델로 설명된다. 기본 인터페이스는 상태, 질문, 허용된 답을 입력하면 결정과 확률이 나오는 형태다. 글은 TypeSafe AI가 Jev를 소개하면서 빠르고 직관적인 사고인 System 1에서 착안한 System One model이라는 표현을 사용했다고 전한다. 이어 커뮤니티에서는 특정 인지 이론보다 모델의 계산상 역할을 설명하는 decision model이라는 용어로 명칭이 모였다고 설명한다. 따라서 이후 논의는 명칭이 암시하는 사고방식보다, 어떤 입력을 받고 어떤 결정 분포를 반환하는지에 초점을 맞춘다.

3. LLM의 JSON 생성이 갖는 제약

글은 분류와 라우팅 같은 구조화된 작업에 LLM을 사용하고 JSON으로 결정을 받는 방식이 이미 널리 쓰인다는 점을 인정한다. 다만 명시적으로 지시해도 유효하지 않은 JSON, 예상하지 못한 키, 허용된 선택지 밖의 답을 생성할 수 있어 요청한 스키마 준수가 보장되지는 않는다고 지적한다. Outlines와 XGrammar는 생성 단계마다 허용 토큰을 제한해 지원되는 문법이나 JSON 스키마의 구조적 제약을 강제할 수 있다. 그러나 이러한 제약 디코딩에도 추가 작업이 필요하며, 선택지만 고르면 되는 상황에서 전체 응답을 자기회귀적으로 생성하는 연산 자체가 불필요할 수 있다는 것이 글의 주장이다. 이는 decision model을 검토하는 동기로 제시되며, 제공된 본문에는 구체적인 속도나 비용 비교 측정치는 없다.

4. 전통적 분류기의 고정된 출력 클래스

전통적 분류의 예시는 고객 지원 요청을 Billing, Technical support, Sales의 세 부서로 배정하는 모델이다. 이런 모델은 학습 사례를 통해 입력과 미리 정해진 라벨 사이의 대응을 배우며, 일반적으로 분류 헤드가 클래스마다 하나의 로짓을 출력한다. softmax는 이 로짓들을 확률 분포로 바꾸므로, 선택지에 확률을 부여하는 기능 자체는 decision model만의 특징이 아니다. 글이 강조하는 제약은 출력 클래스가 분류 헤드에 고정되어 있다는 점으로, Legal 같은 네 번째 부서를 추가해도 기존 모델에 해당 출력이 자동으로 생기지는 않는다. 새로운 범주를 처리하려면 헤드 수정, 학습 데이터 수집, 재학습 또는 적응이 필요할 수 있으며, 글은 이를 다음에 소개하는 제로샷 분류와 대비한다.

5. 제로샷 분류와의 공통점 및 차이

제로샷 분류는 모든 출력 범주에 맞춰 모델을 별도로 학습하는 대신 추론 시 후보 라벨을 전달해 고정 클래스의 제약을 일부 해소한다. facebook/bart-large-mnli 예시는 중복 결제 문장을 billing, technical support, sales로 평가하고, 후보에 legal을 추가한 뒤에도 다시 확률을 반환한다. billing의 점수는 세 후보일 때 약 0.84668, 네 후보일 때 약 0.81858로 제시되며 두 경우 모두 가장 높다. 글은 흔한 구현 방식으로 자연어 추론 모델이 각 후보를 가설로 바꾸고 입력이 그 가설을 얼마나 함의하는지 평가하는 방법을 설명한다. decision model과의 유사성을 인정하면서도, 차별점은 실행 시 라벨 지정의 발명이 아니라 여러 이름 붙은 질문과 답변 유형을 일관된 인터페이스로 조직하는 데 있다고 정리한다.

6. state, questions와 세 가지 기본 유형

decision model 요청의 두 구성 요소는 평가할 정보인 state와 알아내려는 내용을 정의하는 questions다. state는 문자열이나 구조화된 JSON 객체일 수 있으며, 지원되는 옴니모달 모델에서는 다른 모달리티도 사용할 수 있다고 설명한다. 예시 JSON은 고객 메시지와 함께 subscription 값 pro, previous_tickets 값 2를 포함해 평가 맥락을 표현한다. 질문의 기본 유형은 여러 대안 중 하나를 고르는 Choice, 순서가 있는 척도를 평가하는 Score, 예·아니요 질문을 확률적으로 판단하는 Noul이다. 글은 이들을 공통 인터페이스에서 다루는 점을 강조하지만, 제공된 원문에서는 Choice와 Score의 예시까지만 이어지고 Noul의 구체적인 계산이나 출력 사례는 제시되지 않는다.

7. Choice: 선택과 대안별 확률

Choice는 전통적 분류와 가장 가까운 유형으로, 담당 부서처럼 구별되는 대안들에 확률을 부여하고 가장 높은 확률의 선택지를 고른다. 예시에서는 billing을 결제·환불, technical을 버그·기술 문제, sales를 가격·구독에 대응시키고 중복 결제와 환불 요청을 평가한다. autotrust/GEV-26B-Decide의 출력은 billing을 선택하며, 확률은 billing 약 0.99827, technical 약 0.00102, sales 약 0.00071로 제시된다. 같은 출력에는 confidence 약 0.99740도 별도 필드로 포함되지만, 제공된 본문은 이 값의 계산 방식을 설명하지 않는다. 글은 선택지별 로짓을 softmax로 확률화하고 최댓값을 선택하는 과정을 설명하면서, 최종 선택뿐 아니라 나머지 대안에 배분된 확률도 모델의 판단을 이해하는 데 유용하다고 강조한다.

8. Score: 순서 척도의 기댓값과 원문의 한계

Score는 긴급도를 0은 low, 1은 medium, 2는 high처럼 순서가 있는 등급으로 정의하고, 등급 인덱스에 확률을 곱해 더한 기댓값을 반환한다. 코드 출력의 확률은 각각 약 0.01491, 0.26479, 0.72030이며, score는 약 1.70539로 제시된다. 반면 이어지는 설명 표는 0.10, 0.26, 0.72를 사용하고 결과를 1.7로 설명하는데, 이 표의 확률 합계는 1.08이어서 코드 출력과도 맞지 않는다. 글은 기댓값이 중간과 높음 사이의 가상 등급을 선택했다는 뜻은 아니라고 구분하지만, 제공된 원문은 그 설명을 마치기 전에 끊긴다. 따라서 Score의 핵심 원리는 정리할 수 있으나, 표의 수치를 일관된 확률 분포로 받아들이거나 잘린 뒷부분의 설명을 추정해 보완할 수는 없다.

🧾 핵심 주장 / 시사점

• decision model의 위치는 기존 분류와 완전히 단절된 방식보다, 제로샷 분류의 유연성을 여러 질문과 답변 유형으로 확장한 인터페이스로 이해하는 편이 원문의 설명에 부합한다.
• 전체 확률 분포를 반환하면 선택된 부서뿐 아니라 다른 부서에 배분된 확률도 볼 수 있고, Score에서는 순서 척도를 기댓값으로 표현할 수 있다.
• 글은 텍스트 생성의 연산 부담을 문제로 제기하지만 성능 비교 수치를 제시하지 않으며, Score 설명에는 수치 불일치와 원문 중단이라는 해석상 한계가 있다.

✅ 액션 아이템

• 분류·라우팅 작업에서 LLM의 JSON 생성과 decision model의 허용된 답 직접 평가 방식 비교.
• autotrust/GEV-26B-Decide의 Choice 예시에서 billing 선택과 약 0.99827의 확률을 전체 확률 분포와 함께 검토.
• Score의 약 1.70539를 등급 인덱스의 기댓값으로 해석하고, 설명 표의 수치 불일치와 원문 중단을 고려.

❓ 열린 질문

• 현재 분류·라우팅 작업은 허용된 답이 정해져 있어 LLM의 JSON 생성 대신 decision model의 직접 평가를 적용할 수 있는가?
• 동일한 state에 Choice·Score·Noul 중 어떤 유형의 질문을 함께 적용할 필요가 있는가?
• Score 설명 표의 확률이 코드 출력과 다르고 합계도 1이 아닌 이유는 무엇인가?