Hugging Face präsentiert die Decision Models (Entscheidungsmodelle), eine Modellfamilie, die keine Antworten schreibt, sondern vordefinierte Optionen bewertet und eine Wahrscheinlichkeitsverteilung über diese Optionen zurückgibt. Das Unternehmen sucht nach einer gemeinsamen Schnittstelle für diese Modelle, ohne eine einzige Architektur vorzuschreiben.
- Hugging Face stellt Entscheidungsmodelle vor, die vordefinierte Optionen bewerten.
- Sie geben Wahrscheinlichkeiten zurück und erzeugen keinen Text, was Klassifizierung und Routing vereinfacht.
- Transformers, llama.cpp und Unsloth unterstützen das Format bereits.
- Native Trainingsunterstützung in TRL steht noch in einem offenen Merge Request.
Große Sprachmodelle (LLMs), die ihre Antwort Token für Token, also Textstück für Textstück, erzeugen, sind sehr effektiv beim Verfassen von Texten, Programmieren oder logischen Schlussfolgerungen. Aber nicht alle Probleme erfordern die Generierung von Text. Nehmen wir ein Kundensupportsystem, das folgende Nachricht erhält: „Ich wurde zweimal für mein Abonnement belastet. Ich brauche heute eine Rückerstattung. » Es muss bestimmen, welches Team die Anfrage bearbeiten soll, wie dringend sie ist und ob der Kunde eine Rückerstattung verlangt.
Man kann einen LLM bitten, diese Antworten als JSON-Objekt zurückzugeben. Dieser Ansatz ist bereits weit verbreitet für Klassifizierung und Routing, hat aber mehrere Grenzen. Es ist nicht garantiert, dass das Modell das geforderte Schema einhält: Es könnte ungültiges JSON produzieren, unerwartete Schlüssel hinzufügen oder außerhalb der erlaubten Auswahlmöglichkeiten antworten. Bibliotheken für eingeschränkte Dekodierung wie Outlines und XGrammar reduzieren dieses Risiko, indem sie die erlaubten Tokens in jedem Schritt einschränken, aber sie bedeuten zusätzliche Arbeit. Schließlich, wenn die Anwendung nur zwischen bekannten Antworten wählen muss, kann die vollständige Textgenerierung überflüssig sein.
Eine auf Wahrscheinlichkeiten basierende Schnittstelle
Ein Entscheidungsmodell erhält einen Zustand, also die zu bewertende Information, und eine Liste von Fragen. Es gibt Entscheidungen zusammen mit Wahrscheinlichkeiten zurück. Die Quelle unterscheidet drei Fragetypen. Der Typ choice wählt eine Option aus mehreren aus. Der Typ score bewertet etwas auf einer geordneten Skala. Der Typ noul beantwortet eine Ja/Nein-Frage in probabilistischer Form.
Im vorgestellten Beispiel weist das Modell autotrust/GEV-26B-Decide der Servicefrage folgende Wahrscheinlichkeiten zu: Billing 0,998, Technical support 0,001 und Sales 0,001. Für die Dringlichkeit erhalten die Stufen low, medium und high jeweils 0,10, 0,26 und 0,72. Der zurückgegebene Score entspricht dem Erwartungswert dieser Verteilung, also 1,7, und nicht einem halbwegs gewählten Level. Auf die Frage „Fordert der Kunde eine Rückerstattung? » gibt das Modell direkt die Wahrscheinlichkeit für eine positive Antwort zurück, hier 0,92.
Das Konzept des Vertrauens, das für Fragen des Typs choice und score berechnet wird, fasst die Konzentration dieser Wahrscheinlichkeiten zusammen. Das Konzept ist nicht völlig neu: Das Unternehmen TypeSafe AI hatte Jev vorgestellt, das als „System One »-Modell bezeichnet wurde. Der Begriff „Entscheidungsmodell » hat sich schließlich in der Community durchgesetzt, da er die rechnerische Rolle des Modells beschreibt, ohne auf eine bestimmte Kognitionstheorie zu verweisen.
Ein Ökosystem im Aufbau
Das neue Format wird bereits von mehreren Tools unterstützt. Die Transformers-Bibliothek bietet eine DecisionPipeline, eine Klasse AutoModelForDecision und eine Klasse DecisionConfig sowie einen Zugangspunkt /v1/systemone nach dem Start eines lokalen Servers. Die Inferenz-Engine llama.cpp akzeptiert diese Modelle ebenfalls über dieselbe API. Die Quelle zitiert das Modell ggml-org/Kev-4B-GGUF, das auf Port 9931 bereitgestellt wird. Der Hub bietet einen speziellen Tag, decision-model, da diese Modelle nicht unbedingt dieselbe Architektur teilen: Einige basieren auf Encodern wie ModernBERT, andere auf größeren generativen Modellen.
Nachdem die Inferenz geregelt ist, geht die Quelle auf das Training ein. Ein Demobeispiel verfeinert das Modell autotrust/JEV-9B, um Supportanfragen weiterzuleiten, mithilfe der Trainer-API. Native Trainingsunterstützung in TRL ist Gegenstand eines Merge Requests, PR #8040, der zum Zeitpunkt der Artikelverfassung noch offen war. Außerdem bietet Unsloth ein Rezept an, um ein generatives LLM wie Qwen mithilfe von LoRA und einem Scoring-Head in ein Entscheidungsmodell umzuwandeln.
