OpenAI hat eine neue API namens Decisions vorgestellt und versucht, die Markteinführung zum Erfolg zu führen.
Die API bewertet Text, Bilder oder beides und liefert typisierte Antworten etwa 10-mal schneller als die ältere Responses API. Sie können Wahrscheinlichkeiten, Auswahlen aus einem festen Satz oder Bewertungen anhand einer Rubrik erhalten. Das Ziel ist es, Entwicklern zu helfen, Inhalte zu klassifizieren, Anfragen zu routen und Aufgaben zu priorisieren. Die Ankündigung erreichte heute Hacker News mit einem öffentlichen Beta-Flag, einer Testumgebung und SDK-Beispielen in fünf Sprachen.
Das Problem sind die Beispiele selbst. Sie sind gespickt mit Fehlern, Tippfehlern und einer unverständlichen Frage des Kundendienstes, die auffordert, zukünftige Gebühren zu stoppen, anstatt ein Abonnement zu kündigen. Das gesamte Erlebnis liest sich wie eine öffentliche Beta im weitesten Sinne des Wortes, und das ist die Geschichte, die es wert ist, erzählt zu werden.
Geschwindigkeit versprechen
Die Decisions API wird als schnellere Alternative zur Responses API angepriesen. OpenAI sagt, sie liefert typisierte Antworten etwa 10-mal schneller, wobei Wahrscheinlichkeiten, Auswahlen und Bewertungen als Antworttypen verfügbar sind.
Eine Anfrage hat drei Teile: Eingabe, Fragen und ein Modell. Die Eingabe kann Text, Bilder oder beides sein. Die Fragen sind die Quelle für die typisierten Antworten. Das Modell ist gpt-6-luna, das einzige, das derzeit verfügbar ist. Der dedizierte Endpunkt ist POST /v1/decisions.
Die SDK-Beispiele decken Python, JavaScript, Go, Ruby und Java ab. Jedes benötigt eine bestimmte Version oder höher, um ausgeführt zu werden. Die Ankündigung verweist Leser auf das OpenAI SDK für Installationsanweisungen.
Testumgebung
Die Testumgebung ist der Ort, um Fragen und Eingaben zu testen, bevor man Code schreibt. Sie ermöglicht es Ihnen, mit der API zu experimentieren, ohne sich auf eine vollständige Bereitstellung festlegen zu müssen. Das ist ein vernünftiger Ansatz, obwohl es erwähnenswert ist, dass die Testumgebung der Ort ist, an dem die unverständliche Frage auftaucht.
Die Testumgebung soll es Entwicklern ermöglichen zu sehen, was die API kann, bevor sie etwas darauf aufbauen. Die Ankündigung sagt nicht, ob die Testumgebung die gleiche Infrastruktur wie die Produktions-API verwendet, daher ist es schwierig zu beurteilen, wie repräsentativ ihre Ergebnisse sind. Aber für einen ersten Eindruck erfüllt sie ihren Zweck.
Kennzeichnung „Öffentliche Beta“
Die Decisions API befindet sich in der öffentlichen Beta-Phase, und OpenAI erwartet, innerhalb der kommenden Wochen die allgemeine Verfügbarkeit zu erreichen. Das ist ein gewöhnlicher Launch-Zyklus, und es ist nicht ungewöhnlich, dass eine Beta-Version noch einige Ungereimtheiten aufweist. Ungewöhnlich ist jedoch, wie sichtbar diese Ungereimtheiten in der Dokumentation selbst sind.
Die Ankündigung achtet darauf, dies als Beta zu präsentieren. Sie stellt die API nicht als fertiggestellt dar. Aber die SDK-Beispiele sind die Dokumentation für diese API, und sie sind noch nicht für den Einsatz bereit.
Probleme mit den SDK-Beispielen
Die SDK-Beispiele zeigen, wie eine Anfrage mit Text- und Bildeingabe gesendet wird und wie die Antwort auf eine bestimmte Frage überprüft werden kann. Die Beispiele sollen kopiert und eingefügt werden, was eine vernünftige Erwartung ist. Stattdessen enthalten sie eine Reihe kleiner Fehler, die sich zu einem größeren Problem summieren.
Hier ist, was die Beispiele falsch machen:
- Die Liste der Kundenservicefragen enthält eine unverständliche Frage zum Stoppen von Gebühren anstelle der Stornierung eines Abonnements.
Die Unverständliche Frage
Die Liste der Kundenservicefragen ist das deutlichste Beispiel dafür, was an dieser Dokumentation nicht stimmt. Die Liste enthält drei Kundenservicefragen, und die dritte ist ein einziges Chaos. Sie fragt nach dem Stoppen zukünftiger Gebühren, was nicht das ist, was das Beispiel eigentlich erreichen will. Es soll eine Kundenservicefrage sein, nicht eine Bildanalysefrage, und es liest sich wie ein Entwurf, der veröffentlicht wurde, bevor er überprüft wurde.
Die Frage soll eine Kundenservicefrage sein, und sie liest sich wie ein Entwurf, der nie fertiggestellt wurde.
Das ist ein echtes Problem für ein Unternehmen mit der Reichweite von OpenAI. Die SDK-Beispiele sind die primäre Dokumentation für diese API, und sie sind noch nicht für den Einsatz bereit.
Beispiel für eine Prädikat-Frage
Die Prädikat-Frage ist das Beispiel, das tatsächlich funktioniert. Sie fragt, ob ein Produktfoto sichtbare Schäden zeigt, wie z. B. einen Riss, ein Loch oder eine Delle. Die Anfrage kombiniert das Bild mit Anweisungen, nach diesen spezifischen Schadensarten zu suchen, und weist das Modell an, Schatten und Beschädigungen der Verpackung zu ignorieren.
Es ist ein vernünftiger Anwendungsfall, und das Beispiel zeigt, wie die Anfrage mit der URL des Bildes, kodiert in Base64, strukturiert werden kann. Das Curl-Beispiel für die Befehlszeilenversion ist vollständig und sieht so aus, als würde es funktionieren, wenn man es direkt kopiert.
Die Prädikat-Frage ist ein gutes Beispiel dafür, was die API kann. Es ist ein spezifischer, konkreter Anwendungsfall, den Entwickler verstehen und replizieren können. Die Tatsache, dass es das einzige Beispiel ist, das tatsächlich funktioniert, ist aussagekräftig.
Versionen und Tippfehler
Die SDK-Beispiele erfordern bestimmte Versionen der OpenAI-Pakete jeder Sprache. Python benötigt 3.26.0 oder später. JavaScript benötigt 7.30.0 oder später. Go benötigt 3.73.0 oder später. Ruby benötigt 0.101.0 oder später. Java benötigt 4.78.0 oder später.
Das sind vernünftige Versionsnummern. Weniger vernünftig ist jedoch, dass jedes Beispiel seine eigene Version desselben Tippfehlers enthält. Der Eingangs-Array in jedem Beispiel verwendet den falschen Parameter-Namen, so dass die Anfrage nicht geparst werden kann. Das Python-Beispiel vergisst außerdem eine schließende Klammer in Zeile 13, was einen Syntaxfehler verursachen würde, wenn man versucht, es auszuführen.
Die SDK-Beispiele sind die primäre Dokumentation für diese API. Wenn die Beispiele fehlerhaft sind, ist die Dokumentation fehlerhaft. Ein Entwickler, der das Python-Beispiel unverändert kopiert, erhält einen Syntaxfehler. Ein Entwickler, der das JavaScript-Beispiel unverändert kopiert, erhält einen Parsing-Fehler. Ein Entwickler, der das Go-Beispiel unverändert kopiert, erhält einen Parsing-Fehler. Ein Entwickler, der das Ruby-Beispiel unverändert kopiert, erhält einen Parsing-Fehler. Ein Entwickler, der das Java-Beispiel unverändert kopiert, erhält einen Parsing-Fehler.
Das ist eine Menge an Reibung für den Start einer Beta-Version.
Liste der Fragen des Kundenservice
Die Liste der Fragen des Kundenservice ist ein separates Problem. Sie ist nicht Teil der SDK-Beispiele, aber sie ist Teil der Ankündigung, und es ist erwähnenswert. Die Liste enthält drei Fragen: eine Anfrage zur Stornierung eines Abonnements, eine Anfrage zur Umstellung auf eine jährliche Abrechnung und eine Anfrage zur Stoppung zukünftiger Gebühren.
Die dritte Frage ist die, die keinen Sinn ergibt. Sie fragt nach der Stoppung zukünftiger Gebühren, was keine Anfrage zur Stornierung eines Abonnements ist. Es ist eine verschwommene Version der anderen beiden Fragen und erscheint in den Beispielen als eigenständiger Punkt.
Das ist eine kleine Kleinigkeit, aber es ist eine Kleinigkeit, die die Ankündigung unvollständig wirken lässt. Eine Beta sollte ein Werk in Bearbeitung sein, aber die Ankündigung liest sich, als sei sie ohne abschließende Überprüfung veröffentlicht worden. Die SDK-Beispiele sind die Dokumentation für diese API, und sie sind noch nicht bereit.
Urteil über die Beta
Die Decisions API befindet sich in einer öffentlichen Beta, und die Ankündigung besagt, dass sie in den kommenden Wochen allgemein verfügbar sein wird. Das ist eine vernünftige Erwartung für eine Beta. Die API selbst kann solide sein. Das Playground kann nützlich sein. Das Modell kann leistungsfähig sein.
Was nicht solide ist, ist die Dokumentation. Die SDK-Beispiele sind voller Fehler, Tippfehler und einer unklaren Frage des Kundenservice, die wie ein Entwurf wirkt, der nie fertiggestellt wurde. Für ein Unternehmen mit dem Einfluss von OpenAI ist das ein Problem. Die Dokumentation ist die Dokumentation, und wenn die Dokumentation defekt ist, ist die API defekt.
Die Ironie ist, dass das Prädikatsfragebeispiel tatsächlich funktioniert. Es ist das einzige Beispiel, das funktioniert. Es zeigt, wie eine Anfrage mit Text- und Bildeingabe strukturiert wird, und es erzeugt eine Wahrscheinlichkeit, die Entwickler nutzen können. Aber es ist ein einzelnes Beispiel, und es ist von fehlerhaftem Code umgeben.
Die Ankündigung versucht ihr Bestes, um den Start zum Erfolg zu verhelfen. Sie bietet ein Playground, SDK-Beispiele und ein öffentliches Beta-Flag. Sie bietet keinen funktionierenden Code. Das ist die Lücke, und das ist die Geschichte hier.
Die Decisions API ist eine echte Sache. Die öffentliche Beta ist eine echte Sache. Die SDK-Beispiele sind es noch nicht, zumindest nicht in ihrer aktuellen Form. Das Playground kann nützlich sein. Das Modell kann leistungsfähig sein. Aber die Dokumentation ist defekt, und defekte Dokumentation ist ein Misserfolg, nicht eine Beta.
Für Entwickler ist die Botschaft einfach: Verwenden Sie das Playground, um die API zu testen, aber kopieren Sie die SDK-Beispiele nicht direkt. Lesen Sie sie zur Struktur, überprüfen Sie dann die offizielle API-Referenz auf die korrekten Parameternamen und Syntax. Die API kann gut sein. Die Dokumentation nicht. Das ist die Realität dieses Starts, und das ist die Geschichte, die es wert ist, erzählt zu werden.
Quellenmaterial: „Decisions API is in public beta“, openai.com.
Das Notizbuch abonnieren.
Die besten Geschichten des Tages und jedes neue Urteil, in klarem Deutsch, um sieben im Postfach. Eine Mail am Tag, nicht mehr.