Der naheliegende Weg zur automatischen Bildauswertung führt über spezialisierte Computer-Vision-Modelle, die auf eine einzige Aufgabe trainiert sind. Ein Erfahrungsbericht aus dem Umfeld von Jev, OpenJev und SemIf beschreibt einen anderen Aufbau: Ein allgemeines Sprachmodell mit Bildverständnis bewertet die Bilder. Neu ist daran nicht das Modell, sondern die Steuerung. Statt eine Antwort ausformulieren zu lassen, liest der Autor die Token-Wahrscheinlichkeiten der API aus – ein Mechanismus, den viele nur zum Debuggen nutzen, hier aber als Messinstrument dient.
Der Autor beschreibt, wie er über Jev und die darum entstandenen, selbst hostbaren Projekte wie OpenJev und SemIf auf diese Möglichkeit gestoßen ist. Ihm sei dabei klar geworden, dass sich die Wahrscheinlichkeiten einzelner Tokens direkt abfragen lassen – für manche Leser ist das ein alter Hut, für ihn war es neu. Aus dieser Beobachtung ist ein kleines Python-Werkzeug entstanden, das Webcam-Bilder nicht mit klassischer Bildverarbeitung analysiert, sondern mit einem Sprachmodell, das Bilder sehen kann. Der Aufbau lässt sich mit wenigen Mitteln nachbauen.
Wie ein Jev-ähnlicher Wrapper für LLMs Fragen in Buchstaben verwandelt
Das Muster ist einfach. Formuliert wird zuerst ein Zustand, also der Kontext, und darunter eine Frage mit vorgegebenen Antwortmöglichkeiten, von denen jede einen Buchstaben bekommt. Der Autor nennt als Beispiel einen Zustand wie „Meine Bestellung kam beschädigt an und ich möchte eine Rückerstattung“, dazu die Frage, welches Team zuständig ist, und die Optionen [A] billing, [B] shipping, [C] returns. Die Anweisung am Ende lautet, ausschließlich den Buchstaben der besten Option auszugeben.
Dieser Bauplan ist der Kern des Jev-Formats, das als Vorlage dient. Die Fragen tragen dabei Typen, die sich an der erwarteten Antwort orientieren: einer für Ja-Nein-Fragen, einer für Auswahlfragen und einer für Einschätzungen auf einer geordneten Skala. Aus jedem dieser Typen wird im Prompt eine Liste von Buchstaben. Damit lässt sich ein und derselbe Ablauf für völlig unterschiedliche Inhalte verwenden, solange die Antwort auf eine von höchstens zwanzig Optionen passt.
Token-Wahrscheinlichkeiten mit Logprobs auslesen, statt eine Antwort abzuwarten
Man kann sich ein Sprachmodell wie ein Gremium vorstellen, das über eine Frage abstimmt, aber nur das Ergebnis bekannt gibt. Normalerweise siehst du die fertige Antwort und erfährst nichts über die Verteilung dahinter. Logprobs ändern das: Sie zeigen, mit welcher Wahrscheinlichkeit das Modell jedes in Frage kommende Token gewählt hätte. Deshalb genügt ein Buchstabe als Antwort – seine Wahrscheinlichkeit ist bereits die Bewertung der Option.
Technisch ist der Aufwand gering, sofern das Backend mitspielt. Der Request bekommt nur wenige zusätzliche Parameter: die Ausgabe wird auf ein einziges Token begrenzt, Logprobs werden aktiviert und die Zahl der zurückgegebenen Alternativen wird festgelegt. Weil nur ein Token entsteht, ist die Ausgabe praktisch sofort da, auch wenn der Bericht betont, dass die Verarbeitung der Eingabe weiterhin Zeit kostet. Bei vielen Fragen zum selben Zustand lässt sich der gemeinsame Prefix per KV-Cache wiederverwenden, wenn die Serverseite das unterstützt.
Der attachments-Parameter bringt Bilder in das Format
Bis hierhin ist das nichts, was sich nicht auch mit Text erledigen ließe. Dasselbe Verfahren funktioniert aber auch mit Vision-Modellen. Das dokumentierte Jev-Format kennt nach Angaben des Autors bislang nur Text- oder JSON-Zustände, also hat er für seine Experimente ein Feld namens attachments ergänzt. Es nimmt entweder Dateipfade oder Data-URLs mit Base64-kodierten Bilddaten entgegen. Bilder werden einmal geladen und stehen dann allen Fragen desselben Frames zur Verfügung.
Der Wrapper prüft dabei den MIME-Typ und akzeptiert die üblichen Formate. Anschließend landen die Bilder im Prompt, je nach Anbieter entweder als Bildeintrag neben dem Text oder als Bild-URL. An der Logik ändert sich nichts: Das Modell sieht den Zustand, die Frage und die Buchstabenoptionen und gibt ein Token zurück. Der Unterschied zur klassischen Bildverarbeitung: Die Bedingung steckt nicht im Modell, sondern im Text.
Webcam-Bilder mit Python und LLM bewerten: der Ablauf des Skripts
Das Beispiel ist ein eigenständiges Python-Programm, das sich über uv samt Abhängigkeit direkt starten lässt. OpenCV kommt darin nur vor, um bequem an die Kamera zu gelangen und das Vorschaubild anzuzeigen – tatsächliche Bildverarbeitung findet nicht statt. Der Ablauf ist kurz: ein Frame wird gelesen, im Fenster angezeigt und als JPEG kodiert. Aus den Bytes entsteht eine Base64-Daten-URL, die als Attachment in den Request wandert.
Damit die Vorschau flüssig bleibt, läuft die Auswertung in einem Thread-Pool mit genau einem Worker. Solange eine Bewertung läuft, aktualisiert das Skript weiter nur das Vorschaubild und überspringt neue Auswertungen. Ist das Ergebnis da, wird eine Tabellenzeile gedruckt, mit einer Spalte pro Frage und der gemessenen Bildrate für ausgewertete Frames. Die Zeitmessung umfasst dabei auch die Bildkodierung, nicht nur den API-Aufruf.
Die Fragetypen liefern unterschiedliche Arten von Zahlen. Eine Ja-Nein-Frage gibt die Wahrscheinlichkeit für den Wahr-Wert aus, eine Auswahlfrage die wahrscheinlichste Option samt vollständiger Verteilung, eine Einschätzung auf einer Skala einen Erwartungswert zwischen den Stufen. Pro Frage sind zwei bis zwanzig Kriterien erlaubt, die Buchstaben reichen von A bis T. Die Tabelle ist damit kein Klassifikationsergebnis, sondern eine Reihe von Messwerten, die sich über die Zeit beobachten lässt.
Warum llama.cpp und OpenAI verschiedene Endpunkte brauchen
Beim Auslesen der Alternativen unterscheiden sich die Anbieter, und das Skript fängt diese Unterschiede ab. Gegen eine lokal laufende llama.cpp-Instanz geht die Anfrage an den Chat-Completions-Endpunkt mit aktivierten Logprobs und einer hohen Zahl an Alternativen. Gegen OpenAI nutzt der Autor den Responses-Endpunkt, weil dort die Logprobs der Ausgabe über einen eigenen Include-Parameter angefordert werden müssen. In beiden Fällen sorgt ein Sampling-Parameter dafür, dass keine Alternativen vorzeitig weggeschnitten werden.
Zurück kommen nicht zwangsläufig alle Optionen. Das Skript normalisiert die Logprobs daher über eine Exponentialfunktion relativ zum besten Wert und setzt fehlende Optionen zunächst auf null. Fehlt eine Option, deren normierte Wahrscheinlichkeit nicht vernachlässigbar klein ist, bricht das Programm mit einem Fehler ab, statt ein schiefes Ergebnis zu präsentieren. Ein weggelassenes Token darf schließlich nicht besser abschneiden als die letzte tatsächlich zurückgegebene Alternative.
Zur Einrichtung gehört ein llama.cpp-Binary, das der Autor als vorkompilierte Datei für seine GPU bezieht und nach dem Entpacken über einen Serverbefehl startet. Dazu kommen das Modell mit rund sieben Gigabyte und ein Multimodal-Projektor mit etwa 175 Megabyte. Der API-Schlüssel wird nur dann mitgeschickt, wenn die Zieladresse tatsächlich auf den OpenAI-Host zeigt. Alles andere läuft über den lokalen Server auf Port 8060.
Ein Frame pro Sekunde: was die gemessenen Werte bedeuten
Der Autor nennt konkrete Zahlen für seinen Aufbau. Mit einem 12B-Modell auf einer RTX 3090 erreicht er ungefähr ein Frame pro Sekunde, wobei pro Frame drei Fragen gestellt werden. Über die OpenAI-API waren es in seinem Versuch nur rund 0,2 Frames pro Sekunde, was er selbst darauf zurückführt, dass er keine Mühe darauf verwendet hat, einen separaten Verbindungsaufbau pro Frage und Frame zu vermeiden. Für ein Live-System ist das wenig, für eine Beobachtung über Zeit brauchbar.
Dass spezialisierte Computer-Vision-Modelle deutlich effizienter arbeiten, räumt der Bericht ausdrücklich ein. Der Vorteil liegt woanders: Eine Bedingung lässt sich ändern, indem man sie in normaler Sprache beschreibt, und ein neuer Fragetyp braucht kein neues Training. Wer schon einmal eine Erkennungspipeline angepasst hat, weil sich eine Anforderung verschoben hat, weiß, was das wert sein kann.
Für den praktischen Einsatz heißt das: Der Ansatz ist kein Ersatz für schnelle, eng umrissene Bilderkennung, sondern eine Ergänzung für alles, was sich schwer in feste Klassen pressen lässt. Am ehesten passt er dort, wo sich die Frage häufiger ändert als das Bild. Dort liefert ein LLM-Wrapper für Vision-Modelle die Antwort als Verteilung statt als Satz.
Quelle: allanrbo.blogspot.com
