System-1-KI: Was Jev, Clef und Clairic für digitale Anwendungen verändern

Wie die Redaktion die Vorschläge nutzen könnte

Bleiben wir bei den Fachartikeln. Ein Beitrag über den Austausch einer Ölheizung erklärt auch, welche Förderungen infrage kommen. Er gehört deshalb zu den Themen „Heizung“ und „Förderung“. Photovoltaik kommt nur in einem kurzen Vergleich vor. Eine Stichwortsuche sieht diesen Unterschied nicht.

Wir würden dem Modell den Artikel, die verfügbaren Themen und eine Beschreibung ihrer Bedeutung geben. Die Fragen sind konkret: Behandelt der Beitrag hauptsächlich Heizungen? Erklärt er Fördermöglichkeiten? Für jedes Thema liefert das Modell eine Bewertung. Neue Kategorien erfindet es nicht, und den Artikel schreibt es auch nicht um.

Im CMS prüft die Redaktion diese Vorschläge neben dem bestehenden Beitrag, bestätigt sie oder ändert sie. Nach der Freigabe nutzt die Website die Zuordnungen für Themenübersichten, Suchfilter und weiterführende Artikel. Das Modell übernimmt damit eine Vorarbeit, die sonst für jeden Beitrag einzeln anfällt.

Sind die Kategorien im alten System sauber gepflegt und lassen sie sich eindeutig ins neue übertragen, reicht eine normale Migration. Das Modell lohnt sich erst dort, wo die neue Struktur eine inhaltliche Beurteilung verlangt. Ob die Vorschläge Arbeit sparen, zeigt sich daran, wie viel die Redaktion noch korrigieren muss.

Was System-1-Modelle anders machen

Ein klassisches Sprachmodell erzeugt seine Antwort schrittweise, Token für Token. Das können einzelne Wörter, Wortteile oder andere Zeichenfolgen sein. Es kann dabei strukturierte Daten genauso liefern wie Fließtext. Auch die Themenzuordnung aus unserem Beispiel ließe sich damit umsetzen.

Die hier vorgestellten System-1-Modelle berechnen vorgegebene Entscheidungen oder Felder dagegen in einem Modelldurchlauf, ohne dafür eine Antwort als Textfolge zu erzeugen. Für das CMS heißt das: Das Modell liefert direkt Bewertungen zu den festgelegten Themen, ohne zusätzliche Textausgabe. Das kann Rechenaufwand und Antwortzeiten reduzieren, gerade bei vielen gleichartigen Aufgaben.

„System 1“ ist an die Unterscheidung zwischen schnellem und langsamem Denken angelehnt. Gemeint ist hier ein technischer Ansatz, keine menschliche Denkfähigkeit. Automatische Klassifikation gibt es schon lange. Bei diesen Modellen lassen sich die Fragen und Antwortmöglichkeiten aber in natürlicher Sprache beschreiben, ohne für jede neue Einteilung ein eigenes Modell zu trainieren. Typesafe hat diesen Ansatz mit Jev vorgestellt (englisch).

Jev, Clef und Clairic im Vergleich

Jev und die Clef-Modelle sind für Einordnungen und Bewertungen gedacht. Clairic macht etwas anderes: Es liest konkrete Angaben aus Dokumenten heraus. Bei der Themenzuordnung im CMS geht es um passende Kategorien, bei einem Datenblatt um Werte, die im Dokument stehen.

Bei Jev lohnt sich ein Blick darauf, was regulär und was experimentell ist. Typesafe hat die Bildeingabe im Oktober experimentell freigeschaltet, auch für die bereits vorhandene Version 1.13. Für eine Anwendung, die Dokumente als Bilder verarbeiten soll, würden wir sie noch nicht wie eine Standardfunktion einplanen.

Clef und Clef-flash unterscheiden sich vor allem in der Größe. Parameter sind die beim Training erlernten Werte eines Modells, und mehr davon heißt nicht automatisch bessere Ergebnisse bei jeder Aufgabe. Für eine klare Zuordnung reicht oft die kleinere Variante, die weniger Rechenleistung braucht. Ob sie mit mehrdeutigen Anfragen genauso gut zurechtkommt, zeigt erst der Vergleich mit den eigenen Daten.

Clef-omni verarbeitet zusätzlich Audio. Das hilft, wenn eine Einteilung den gesprochenen Text und das Bild gemeinsam berücksichtigen soll. Die Ausgabe bleibt eine Bewertung vorgegebener Optionen, keine Transkription und keine frei formulierte Videobeschreibung.

Clairic wurde am 19. Oktober als Preview vorgestellt. Bei Textauszügen kann es Fundstellen zurückgeben, was die Prüfung am Original erleichtert. Daneben bietet es eigene Funktionen für Schätzungen und Prognosen. In einer Anwendung müssen diese von tatsächlich ausgelesenen Angaben unterscheidbar bleiben. Ein geschätzter Wert darf nicht so aussehen, als stünde er im Dokument. Cloudflares Vorstellung von Clairic (englisch) beschreibt diese Aufgaben.

Produktdaten aus Lieferantendokumenten übernehmen

Ein zweites Beispiel ist ein Kundenportal, in dem technische Angaben zu Produkten gepflegt werden. Lieferanten schicken ihre Datenblätter als unterschiedlich aufgebaute PDFs. Im Portal gibt es dafür feste Felder, etwa Modellbezeichnung, Betriebsspannung und Abmessungen. Bisher sucht jemand die Angaben im Dokument und tippt sie ab.

Hier würde ein Extraktionsmodell wie Clairic die vorgegebenen Angaben im Dokument suchen. Das Portal zeigt die gefundenen Werte neben dem Original und schlägt sie zur Übernahme vor. Fehlt die Betriebsspannung im Dokument, muss das Feld leer bleiben. Eine Zahl aus einer anderen Tabelle ist kein brauchbarer Ersatz.

Hier zeigt sich der Unterschied zwischen den beiden Beispielen. Jev oder Clef bewerten, welche der vorgegebenen Kategorien zutrifft. Clairic liefert einen konkreten Wert, den wir vorher nicht kennen. Eine Anwendung kann beide Aufgaben verbinden, etwa zuerst die Art des Dokuments bestimmen und dann die dazu passenden Angaben abfragen. Für sauber strukturierte Lieferantendaten ist ein direkter Import allerdings meist der einfachere Weg.

Open Weights: Was sich selbst betreiben lässt

Bei einer Anbieter-API schicken wir Daten an einen externen Dienst und bekommen das Ergebnis zurück. Um die Modellinfrastruktur kümmert sich der Anbieter. Für einen begrenzten Einstieg ist das praktisch, weil keine eigene Umgebung für das Modell eingerichtet werden muss.

Open Weights bedeutet, dass die erlernten Modellparameter verfügbar sind. Ob und unter welchen Bedingungen sie genutzt, verändert und weitergegeben werden dürfen, regelt die jeweilige Lizenz. Ob auch Trainingscode und ausreichende Informationen über die Trainingsdaten offenliegen, ist damit nicht gesagt. Open Weights und eine vollständig offene KI-Entwicklung sind deshalb zwei verschiedene Dinge. Die Open Source Initiative erläutert diese Unterscheidung (englisch).

Die Gewichte von Clef, Clef-flash und Clef-omni stehen unter Apache 2.0 zur Verfügung (Modellbeschreibungen auf Englisch). Damit kommt auch ein Betrieb in einer passenden Cloud-Umgebung oder im Rechenzentrum des Kunden infrage. Bei Clairic ist dieser Schritt angekündigt, zum hier beschriebenen Stand aber noch nicht verfügbar.

Eigener Betrieb kommt infrage, wenn Daten die festgelegte Infrastruktur nicht verlassen sollen oder viele gleichartige Aufgaben anfallen. Er braucht geeignete Hardware, eine unterstützte Laufzeit und jemanden, der die Umgebung betreut. Ein heruntergeladenes Modell bringt keine Updates, keine Kapazitätsplanung und keine Fehlerüberwachung mit.

Die Betriebsentscheidung treffen wir deshalb gemeinsam mit der vorhandenen IT. Datenverarbeitung, Auslastung, Kosten und Zuständigkeiten müssen zusammenpassen. Die Überlegungen gleichen denen bei der Wahl zwischen Cloud und On-Premise für Webanwendungen, nur kommt die passende Modellhardware dazu.

Was bei der Integration geprüft werden muss

Für einen Test brauchen wir Beispiele aus dem echten Arbeitsablauf, einschließlich unvollständiger und mehrdeutiger Eingaben. Vorher muss feststehen, was als richtig gilt und welcher Fehler welche Folgen hat. Die Redaktion kann eine falsche Themenzuordnung vor der Veröffentlichung korrigieren. Ein unbemerkt falsch übernommener Produktwert landet später in Angeboten und Bestellungen.

Auch die Angaben zur Modellsicherheit prüfen wir gegen diese Beispiele. Ein Wert von 95 Prozent ist eine Modellausgabe, keine bestätigte Trefferquote von 95 Prozent im eigenen Prozess. Erst eine passende Auswertung zeigt, welche Fälle automatisch weiterlaufen können und welche jemand ansehen muss.

Berechnungen, Berechtigungen und verbindliche Geschäftsregeln bleiben im Anwendungscode. Das Modell schlägt eine Zuordnung oder einen Wert vor. Ob dadurch ein Artikel veröffentlicht oder ein Datensatz geändert wird, entscheidet die Anwendung anhand der vereinbarten Regeln.

Clairic im Test mit Rechnungen

Für unser Rechnungswerkzeug milchrechnung.at haben wir ausprobiert, ob Clairic Angaben aus PDF-Rechnungen in ein Formular übernehmen kann. Dafür verwendeten wir künstlich erstellte Rechnungen, deren richtige Werte feststanden. Unser Prototyp las den Text aus den PDFs und ließ Clairic nach Rechnungsnummer, Datum, Beträgen und einzelnen Rechnungspositionen suchen.

Vorhandene Kopfdaten wie Rechnungsnummer und Datum wurden fast immer richtig erkannt. Bei den einzelnen Positionen bekam unser Prototyp Beschreibung, Menge und Preis dagegen nicht zuverlässig zusammen. In einem Fall übernahm er die 20 Prozent Umsatzsteuer als Rabatt, obwohl auf der Rechnung gar kein Rabatt angegeben war. Die Zahl stand tatsächlich im Dokument, nur im falschen Zusammenhang.

Für eine automatische Übernahme ganzer Rechnungen hat das nicht gereicht. Deshalb haben wir den Prototyp nicht in die öffentliche Anwendung eingebaut. Einzelne Angaben zur Prüfung vorzuschlagen wäre für uns der sinnvollere nächste Einsatz: Der Nutzer sieht den gefundenen Wert neben der Rechnung und entscheidet, ob er ihn übernimmt.

Welches Modell zur Anwendung passt

Für die Themenzuordnung im CMS würden wir Jev und die passenden Clef-Varianten gegeneinander testen. Kommen Bild und Ton zusammen, kommt Clef-omni ins Spiel. Für das Herauslesen einzelner Dokumentangaben ist Clairic ein Kandidat, sofern der Preview-Stand zur geplanten Nutzung passt. Soll das Modell auf eigener Infrastruktur laufen, schränkt das die Auswahl weiter ein.

Eine Anbieter-Demo zeigt, was grundsätzlich geht. Für die Entscheidung zählen die Ergebnisse mit den eigenen Daten, die nötige Nachbearbeitung und die Kosten des gesamten Ablaufs. Ein günstiger Modellaufruf bringt nichts, wenn danach fast jeder Datensatz von Hand korrigiert werden muss. Eine zuverlässig erledigte Teilaufgabe spart dagegen schon viel Arbeit.

Für uns erweitert das die Möglichkeiten bei der Integration von KI in Websites und Fachanwendungen. Viele Anwendungen brauchen keinen Chat. Sie brauchen eine verlässliche Zuordnung, ein nachvollziehbar ausgelesenes Feld und eine Oberfläche, in der jemand den Vorschlag mit wenig Aufwand prüfen kann.