소프트웨어 안에서 AI가 하는 일의 상당수는 쓰는 것이 아니라 고르는 것입니다. 이 지원 요청을 어느 팀에 넘길지, 얼마나 급한지, 고객이 환불을 원하는지 같은 판단입니다. 새로운 종류의 판단 모델은 텍스트를 생성하는 대신 확률로 이런 질문에 바로 답하며, Hugging Face가 이제 자사 도구 전반에 이들을 위한 공통 인터페이스를 마련했습니다. 개발자에게는 한 판단 모델로 만든 라우터나 분류기를 연결 코드를 다시 쓰지 않고 다른 모델로 바꿀 수 있게 된다는 뜻입니다.
인터페이스는 간단합니다. 판단할 정보인 상태를 텍스트나 구조화된 JSON으로 보내고, 이름 붙인 질문을 함께 보냅니다. 질문마다 세 가지 기본 유형 중 하나를 씁니다. choice는 선택지 중에서 골라 각각의 확률을 돌려주고, score는 순서가 있는 척도로 평가해 기대 단계를 돌려주며, noul은 예/아니요 질문에 예일 확률로 답합니다. choice와 score 답변에는 신뢰도 값도 붙는데, 선택지에 고르게 퍼진 경우가 0, 완전히 확신하는 경우가 1이 되도록 조정됩니다. Hugging Face의 청구 예시에서 모델은 billing에 0.998을 줬고, 이는 신뢰도 0.997에 해당합니다.
새로운 점은 기반 구조입니다. Transformers에 DecisionPipeline, AutoModelForDecision, DecisionConfig가 생겼고, transformers serve는 /v1/systemone 엔드포인트를 제공합니다. 우리가 리뷰하는 llama.cpp도 같은 엔드포인트로 판단 모델을 제공하므로, Hugging Face의 모델용으로 쓴 요청이 로컬 GGUF 모델에서도 작동합니다. Hub에는 decision-model 태그가 생겼고, 모델은 일반 Trainer로 미세조정할 수 있으며 choice 질문은 선택지에 대한 단순 교차 엔트로피로 학습합니다. 글에 따르면 인터페이스 뒤의 모델은 ModernBERT 같은 인코더부터 큰 생성 모델 위에 판독 부분을 얹은 것까지 다양합니다.
맥락이 중요합니다. 우리가 리뷰한 TypeSafe AI의 Jev는 System One 모델이라는 이름으로 이 개념을 알렸고, Google도 같은 세 가지 질문 유형을 쓰는 Gemini Decisions API를 막 내놓았습니다. 공유된 개방형 형식이 있으면 이들끼리, 그리고 채팅 모델에 JSON을 요청하는 방식과 비교하기 쉬워집니다. 글이 지적하듯 후자는 스키마를 깨거나 허용된 선택지 밖에서 답할 수 있습니다.
한계는 실무적입니다. 표준 인터페이스가 어떤 모델을 정확하거나 보정된 상태로 만들지는 않으며, 신뢰도 값은 다시 척도를 맞춘 확률일 뿐 보장이 아닙니다. 한 댓글 작성자가 짚었듯 실제 운영에서 어려운 부분은 임계값을 정하고 나중에 도착하는 실제 결과와 대조해 확인하는 일입니다. 다른 모델 제작사들이 자체 API를 고집하지 않고 이 형식을 채택할지가 그 중요성을 결정할 것입니다.