Eigene Klassifikation

Eldric
Ihre Domäne beibringen.

Eldrics Router klassifiziert jede Anfrage in eine Intent-Klasse, bevor er sie weiterleitet. Die Plattform liefert 128 eingebaute Klassen mit (11 Kern-Intents plus 117 Wissenschafts-Unterdomänen). Für Workflows, in denen die eingebauten Klassen nicht die richtigen Unterschiede tragen — ein Krankenhaus möchte vielleicht eine „PatientenTriage“-Klasse, eine Kanzlei eine „VertragsPrüfung“-Klasse, ein Werk eine „AnomalieTrend“-Klasse — unterstützt Eldric eigene Klassen auf Mandanten-Ebene. Zwei Wege: einen Overlay-Klassifikator trainieren oder mit einem LLM und Ihrer Taxonomie fallback fahren.


Was der Klassifikator tut

Routing fängt hier an.

Wenn Sie eine Frage stellen, läuft der Router die Anfrage zuerst durch einen kleinen Klassifikator — ein einzelner neuronaler Pass, der eine Klassen-Bezeichnung und einen Vertrauens-Wert zurückgibt. Die Klasse bestimmt, welcher Worker den Request bedient, welche Wissensbasen durchsucht werden, welches Modell gewählt wird und ob die Kaskade gelernte Gewichte / Matrix-Memory / RAG / Live-Quellen zuerst probiert.

Die eingebauten Klassen decken die offensichtlichen Top-Level-Formen ab: reiner Chat, RAG-Anfrage, Agent-Aufruf, Swarm-Anfrage, Memory-Speichern/Abrufen, Daten-Operation, Wissenschafts-Anfrage, Medien-Anfrage, Comm-Anfrage, Training-Anfrage, IoT-Anfrage — plus die 117 Wissenschafts-Unterdomänen für Genomik / Teilchenphysik / Klima / usw. Eigene Klassen sitzen neben diesen, mit denselben Routing-Semantiken; sie erweitern die Taxonomie, statt sie zu ersetzen.


Weg A — Overlay-Klassifikator

Eldric mit Ihren Beispielen trainieren.

Der Hochqualitäts-Weg. Sie liefern gelabelte Beispiele — ein paar hundert Anfragen pro neuer Klasse, jede mit der gewünschten Klasse markiert — und Eldric trainiert ein Overlay über den Basis-Klassifikator. Das Training läuft lokal (Ihre Daten verlassen den Cluster nicht), dauert auf einer kleinen GPU Minuten und produziert eine mandantenspezifische .enrn-Datei, die der Router neben der Basis-Datei lädt.

Der Ablauf:

  1. Stellen Sie Ihre gelabelten Beispiele in eine JSONL-Datei zusammen: eine Zeile pro Beispiel mit {"query": "...", "class": "VertragsPrüfung"}.
  2. POSTen Sie die Datei an /api/v1/router/custom-classes/train mit Ihrer Mandanten-ID. Der Trainings-Worker (Port 8898) fährt die ENRN-Overlay-Pipeline.
  3. Der Trainings-Worker meldet Fortschritt an die Chat-Oberfläche; sobald er eine .enrn mit Eval-Genauigkeit über Ihrer Schwelle (Voreinstellung 0.8) erzeugt, lädt der Router sie heiß nach.
  4. Neue Anfragen, die Ihren Beispielen ähneln, klassifizieren jetzt in die neue Klasse — und das Routing folgt daraus.

Pro+-Tier. Der Trainings-Korpus, die Overlay-Datei und der Eval-Bericht bleiben auf Ihrem Cluster — kein Teil des Workflows telefoniert nach Hause.


Weg B — LLM-Fallback

Kein Trainings-Korpus? Das Modell verwenden.

Der Schnellstart-Weg. Wenn Sie noch keine gelabelten Beispiele haben, aber wissen, welche Klassen Sie wollen, kann der Router auf ein LLM mit einem Prompt fallen, der Ihre Taxonomie enthält. Zwei Konfigurationen:

Automatischer Fallback

Wenn der Basis-Klassifikator ein Vertrauen unter dem Schwellwert (Voreinstellung 0.7) zurückgibt, eskaliert der Router: Er fragt ein kleines LLM „Klassifiziere diese Anfrage in eine von: [Ihre Klassenliste]“ und verwendet die Antwort des LLMs als Routing-Bezeichnung. Fügt 50–100 ms pro Anfrage für den LLM-Roundtrip hinzu; feuert nur bei den Anfragen, bei denen der Basis-Klassifikator unsicher war. In jedem Tier kostenlos, der ein Chat-fähiges Modell konfiguriert hat.

Immer-LLM

Für Mandanten ohne Überlappung mit eingebauten Klassen (ein nischenhaft regulierter Workflow mit Vokabular, das die Plattform nie gesehen hat) können Sie den Basis-Klassifikator für diesen Mandanten ausschalten und jede Anfrage durch den LLM-mit-Taxonomie-Pfad fahren. Langsamer pro Anfrage, aber kein Training nötig. Kosten hängen davon ab, auf welches Modell Sie zeigen — lokales Inferenced ist pro Anfrage kostenlos, bezahlte Cloud-LLMs rechnen pro Token ab.

Sowohl Weg A als auch Weg B sind pro Mandant konfigurierbar. Ein Mandant kann mit dem Overlay-Klassifikator für den Großteil des Traffics und LLM-Fallback für Fälle mit geringem Vertrauen fahren.


Die Entscheidung des Klassifikators sehen

Was gerade als was klassifiziert wurde.

Die Admin-Konsole → Router-Seite zeigt einen Live-Strom der Klassifikations-Entscheidungen: Anfrage (standardmäßig anonymisiert), zugewiesene Klasse, Vertrauen, Quelle (Basis / Overlay / LLM-Fallback) und der Worker, an den der Request gegangen ist. Nützlich für die Fehlersuche „warum ist diese Anfrage dort gelandet, wo sie gelandet ist“ und um Lücken in der Klassen-Taxonomie zu entdecken — wenn viele Anfragen mit niedrigem Vertrauen in der Catch-all-Klasse „general“ landen, ist das ein Signal, eine neue Klasse hinzuzufügen.

Dieselben Daten sind über die API verfügbar:

curl -X POST -H "X-API-Key: $ELDRIC_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"query":"kannst du die Freistellungs-Klausel in Vertrag X zusammenfassen"}' \
     https://<Ihr-Host>/api/v1/router/classify

# {
#   "class": "VertragsPrüfung",
#   "confidence": 0.91,
#   "source": "overlay",
#   "fallback_chain": ["base", "overlay"]
# }

Operatoren verdrahten das in eigene Dashboards, wenn sie ein klareres Bild davon wollen, welche Anfragen die Plattform sieht.


Wann welcher Weg

Eine Entscheidungs-Form.


Weiter

Tiefer einsteigen.

Für die RAG-Anleitung: RAG verwenden. Für das Kaskaden-Verhalten: RAG bei Bedarf. Für die Einbettung des Routers in den Rest des Systems: Wie es funktioniert. Für die Trainings-Worker-Seite, die die Overlay-.enrn-Dateien produziert: Funktionen § Training.