Spring-AI-Client beantwortet typisierte Fragen ohne ein einziges Token
Victoria Shinder3 Min. LesezeitChristian Tzolov stellt Spring AI TypeSafe vor, ein Projekt der Spring-AI-Community, das die gehostete Jev-API von TypeSafe AI in Spring-Anwendungen einbindet. Der Beitrag sagt unmissverständlich, worum es nicht geht: Dies ist kein Chat-Modell. Der Dienst klassifiziert, bewertet und entscheidet — und erzeugt nie Text. Übergeben wird ein State, also der zu beurteilende Gegenstand, zusammen mit einer Sammlung typisierter Fragen; beantwortet werden alle in einem einzigen Aufruf.
Die gesamte Schnittstelle besteht aus drei Primitiven. Ein Noul stellt eine Ja/Nein-Frage und liefert einen Wahrheitswert zwischen 0 und 1 — ohne eigenes Konfidenzfeld, weil die Zahl bereits die Sicherheit ist; 0,5 heißt unentschieden. Ein Choice wählt ein Label aus einer Menge und liefert Gewinner, Wahrscheinlichkeit je Option und eine Konfidenz. Ein Score ordnet den State auf einer Skala ein und liefert einen stetigen Wert, die Legende, Wahrscheinlichkeiten je Stufe und eine Konfidenz. Ein Support-Ticket durch drei dieser Fragen ergibt: Dringlichkeit 0,95, Abteilung billing hinter der Verteilung {billing: 0.87, technical: 0.13, sales: 0.0}, Konfidenz 0,82 und Verärgerung 1,1 auf einer dreistufigen Skala.
Eine Messung im Beitrag sollte das Produkt überdauern. Dasselbe Ticket mit nackten Labels statt beschriebener Optionen — "billing", "technical", "sales" ohne Erläuterung, was sie jeweils bedeuten — senkt die Konfidenz von 0,82 auf 0,60. Die Beschreibungen sind keine Dokumentation für Menschen, sie sind Eingabedaten.
Der Rest ist Spring-Verdrahtung, und der Autor benennt ihre Grenzen. JevJudge setzt Kriterien zusammen, jedes eine Frage samt Schwellenwert, und liefert ein Urteil pro Kriterium; liegt eines unter der Untergrenze des Judge, lautet das Ergebnis INCONCLUSIVE statt FAILED, und failOnInconclusive(true) gibt es für Teams, denen eine ungeprüfte Antwort schlimmer ist als eine abgelehnte. JevSelfRefineAdvisor schließt die Schleife um einen ChatClient: Das Modell antwortet, der Judge prüft alle Kriterien in einem Aufruf, und bei Nichtbestehen werden der whenFalse-Satz des gescheiterten Kriteriums, sein Wert und sein Schwellenwert an den ursprünglichen Prompt gehängt und der Aufruf wiederholt — bis zu einer einstellbaren Zahl von Versuchen.
Die Einschränkungen stehen offen da. Jev streamt nicht; ein Aufruf liefert nach einigen hundert Millisekunden, nicht Token für Token. Der State muss String, Objekt, Array oder null sein — eine nackte Zahl oder ein Boolean ergibt HTTP 422. Gearbeitet wird pro Dokument, ein Reranking der Top 20 kostet also zwanzig Aufrufe, und der Beitrag rät, die Liste vorher zu filtern. Ein Choice benennt immer einen Gewinner, „keines davon" muss deshalb als eigener Noul gefragt werden. Und Konfidenz ist als Routing-Signal beschrieben, nicht als Qualitätsmaß.
⚠ Beide Artefakte stehen in Version 0.1.0 auf Maven Central unter org.springaicommunity, es handelt sich um ein Community-Projekt und nicht um einen Teil von Spring AI selbst, und aufgerufen wird ein gehosteter Fremddienst, der Konto und API-Schlüssel verlangt. Die Latenzangabe und die Kostenangabe — Tausendstel eines Cent, nach TypeSafes eigenem Benchmark — stammen vom Anbieter. Der Beitrag hält fest, dass die zitierten Ausgaben aus echten Läufen stammen, und legt offen, wo ein Demo gescriptet ist: Das Wetterwerkzeug im Self-Refine-Beispiel liefert absichtlich −125 °C.
Was das bedeutet
Die Entwurfsidee lässt sich vom Anbieter trennen. Mehrere enge Fragen statt einer breiten, alle gegen einen State in einem Durchgang beantwortet, und an jeder Antwort eine Konfidenz, damit Code entscheidet, was als Nächstes passiert — nicht ein Fließtext. Diese Form ist übernehmenswert, unabhängig davon, was am anderen Ende steht.
Der Ansatz zielt auf die hässlichste Stelle des heutigen Stapels. Eine parsebare Zahl aus einem zweiten Chat-Modell zu bekommen, verlangt ganzzahlige Skalen, Beispielantworten, Temperatur null, ein JSON-Schema und einen Parser — und dann einen Wiederholungsversuch, wenn doch ein Satz zurückkommt. Jede dieser Schichten existiert, damit sich ein Textgenerator wie ein Klassifikator verhält. Eine Komponente, die keinen Text erzeugt, braucht sie nicht.
Die Frage vor der Einführung betrifft die Abhängigkeit, nicht die Schnittstelle. Eine Routing-Entscheidung, die bisher ein if war, wird zum Netzaufruf bei einem Unternehmen, dessen Benchmark man nicht nachstellen und dessen Modell man nicht festnageln kann. Für manche Entscheidungen ist das ein vernünftiger Tausch, für andere nicht — und Version 0.1.0 einer Community-Integration ist der richtige Moment, das zu klären.
Quelle: https://spring.io/blog/2026/09/21/spring-ai-typesafe-structured-judgment