TypeChat: Chat-basierte AI-Plattform

 (microsoft.github.io)
3 Punkte von GN⁺ 2023-07-21 | 2 Kommentare | Auf WhatsApp teilen
  • Die größte Schwierigkeit beim Hinzufügen natürlicher Spracheingaben zu bestehenden Apps besteht darin, die Nutzerabsicht in eine Struktur zu überführen, der Software zuverlässig vertrauen kann; TypeChat ist eine Bibliothek, die genau dieses Problem mit TypeScript-Typen lösen will
  • Da freie Textantworten von LLMs instabil zu parsen sind, lenkt TypeChat Antworten auf JSON und ergänzt eine Schema-Validierung, damit daraus Daten werden, die eine App verarbeiten kann
  • TypeScript-Typen können JSON-Strukturen präzise ausdrücken und sind ein Format, dem LLMs im Training häufig begegnet sind, wodurch sie sich gut als Antwortschema eignen
  • Wenn eine Antwort nicht zum Typ passt, kann der TypeScript-Compilerfehler erneut als Feedback verwendet werden, um sie zu korrigieren; so lässt sich die Typsicherheit noch vor Nachbearbeitung oder Nutzerbestätigung erhöhen
  • TypeChat kann mit npm install typechat installiert werden, ist als Open Source unter der MIT-Lizenz veröffentlicht und bietet auch Integrationen für die OpenAI API und den Azure OpenAI Service

Natürliche Sprachabfragen in von Apps verarbeitbare Daten umwandeln

  • Moderne Large Language Models lassen sich zwar leicht an Chat-Assistenten anbinden, doch natürliche Sprache zuverlässig in bestehende App-Oberflächen zu integrieren, ist eine eigene Herausforderung
  • TypeChat konzentriert sich darauf, Nutzeranfragen in eine Form zu überführen, die eine App verarbeiten kann, und Abläufe zu ermöglichen, denen Entwickler und Nutzer vertrauen können
  • Die veröffentlichte Bibliothek verwendet Typdefinitionen aus der Codebasis, um strukturierte AI-Antworten zu erhalten, und zielt auf Typsicherheit ab
  • Die Installation ist mit dem folgenden Befehl möglich
npm install typechat

Statt Natural-Language-Parsing: JSON und Typen

  • LLMs sind grundsätzlich auf Gespräche in natürlicher Sprache wie Englisch ausgerichtet; selbst wenn man Regeln wie „antworte als Aufzählung“ in den Prompt schreibt, ist das für normale Software oft schwer zuverlässig zu parsen
  • Wenn man um eine Antwort in JSON bittet, lässt sich in der Regel ein Format erzeugen, das Apps leichter verarbeiten können
    • Im Beispiel wird eine Bestellung mit je einem „blueberry muffin“ und einem „grande latte“ in JSON mit einem items-Array umgewandelt
  • Ein einfaches Beispiel hilft zwar dabei, eine Struktur vorzugeben, definiert aber nicht ausreichend, was die AI zurückgeben soll, und liefert auch keine Validierungskriterien

TypeScript-Typen als Antwortschema verwenden

  • TypeChat fügt dem Prompt TypeScript-Typen hinzu, um dem LLM die zurückzugebende JSON-Struktur vorzugeben
  • Im Beispielschema enthält der Typ Response ein Feld items: Item[], und Item besitzt die Felder name, quantity sowie die optionalen Felder size und notes
  • TypeScript eignet sich gut dazu, JSON präzise zu beschreiben, und da LLMs vielen Typdefinitionen begegnet sind, ist es nützlich zur Steuerung des Antwortformats
  • Wenn eine Antwort nicht zum Typ passt, validiert der TypeScript-Compiler sie anhand der Typdefinitionen, die gültiger TypeScript-Code sind
  • Das Feedback aus Compilerfehlern kann genutzt werden, um Antworten zur Korrektur anzuleiten und den Ablauf zu robusteren typkonformen Antworten zu machen

Nutzung von TypeChat und Beispiele

  • TypeChat kann als Datenschema-Ansatz verwendet werden, um Nutzerabsichten in strukturierte Antworten zu überführen
  • Der Beispielcode definiert ein SentimentResponse-Interface, das die Stimmung einer Nutzereingabe als negative, neutral oder positive einstuft
  • Mit createLanguageModel(process.env) wird ein sprachmodellbasiertes Modell aus Umgebungsvariablen erzeugt; danach wird die Schemadatei eingelesen und mit createJsonTranslator<SentimentResponse> ein Übersetzer erstellt
  • Wenn translator.translate(request) erfolgreich ist, wird response.data.sentiment ausgegeben, andernfalls eine Fehlermeldung
  • Neben Datenschemata lassen sich auch API-Schemata verwenden, um einfache Programme aufzubauen
  • Die Nutzung wird in den docs und examples gezeigt

Open Source und Modellneutralität

  • TypeChat ist Open Source unter der MIT-Lizenz und auf GitHub veröffentlicht
  • Der Einfachheit halber werden Standardintegrationen für die OpenAI API und den Azure OpenAI Service bereitgestellt
  • Das Designziel ist Modellneutralität; angestrebt wird ein Ansatz, der mit APIs im Stil von Chat Completions genutzt werden kann
  • Derzeit funktioniert TypeChat am besten mit Modellen, die sowohl auf Fließtext als auch auf Code trainiert wurden
  • Das Paket ist auf npm verfügbar und kann direkt ausprobiert werden

Verwandte Beiträge

2 Kommentare

 
sungwoo 2023-07-26

Haha, ich wollte die Nachricht nach dem Lesen posten, aber gegen die AI komme ich nicht an.
 
GN⁺ 2023-07-21
Hacker-News-Kommentare

  • Ich sehe nicht so recht, worin hier der Mehrwert besteht.
    Die zentrale Nachricht an das LLM steht hier: https://github.com/microsoft/TypeChat/blob/main/src/typechat...
    Im Grunde wirkt es so, als würde man mit einem festen Prompt strukturierte Daten zurückgeben lassen und dazu etwas Automatisierung und Vendor-Lock-in packen. Die meisten dieser LLM-Bibliotheken sind kaum mehr als dürftige APIs, die die darunterliegenden APIs umhüllen; ein Skript, das dasselbe macht, lässt sich leicht schreiben und ist flexibler, wenn sich Modell und Nutzeranforderungen ändern.
    Wenn man zum Beispiel den Prompt ändern oder Python-Klassen verwenden will, gibt es einen großen Unterschied im Arbeitsaufwand zwischen so einer Bibliothek und einem Ansatz, bei dem man API-Aufrufe und Text-Templates dem Nutzer direkt bereitstellt (https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/llm...)

    • Der Wert liegt hier: 1) Man lässt den TypeScript-Type-Checker über das vom LLM zurückgegebene Ergebnis laufen, 2) wenn Typfehler auftreten, sammelt man sie und baut daraus einen „Korrektur-Prompt“, um eine Ausgabe zu erzeugen, die den Type-Check eher besteht, 3) auch Fälle, in denen die Heuristik aus 2) scheitert, werden sauber behandelt.
      https://github.com/microsoft/TypeChat/blob/main/src/typechat...
      Aus meiner Erfahrung mit ähnlichen Experimenten funktioniert die Heuristik aus 2) erstaunlich gut bei relativ einfachen Typen, also Records und Arrays ohne tiefe Verschachtelung und mit begrenzter Nutzung von Typvariablen. Allein mit Prompts, die das LLM anweisen, Werte relativ einfacher Typen zurückzugeben, kann man nützliche Anwendungen bauen, und diese Bibliothek hat Wert, weil sie den Bedarf reduziert, dieses Anfrage-Muster selbst zu implementieren, und eine Standardintegration in TypeScript-Codebasen bietet.
    • Fast alle LLM-Bibliotheken, die man derzeit sieht, funktionieren so. Am Ende läuft es darauf hinaus, das LLM zu bitten, etwas auf eine bestimmte Weise zu tun, und ich habe gesehen, dass es sich bei komplexen Bedingungen weniger an Anweisungen hält und zu seinem Standardverhalten zurückkehrt.
      Trotzdem scheint die Nutzung von Bibliotheken der richtige Weg zu sein, also beobachte ich weiter, welcher Ansatz ausreichend ausgereift wird.
    • Ich verstehe nicht, wo hier Vendor-Lock-in sein soll. Das ist eine Open-Source-Bibliothek, und in der verlinkten Datei sind sogar Konfigurationen für die beiden Anbieter ChatGPT und Bard enthalten.
    • Der Wert liegt darin, unstrukturierte Daten in strukturierte Daten umzuwandeln und sicherzustellen, dass sie die Schema-Beschränkungen erfüllen.
      Wenn man zum Beispiel 1000 Freitextantworten aus einer Produktumfrage hat, kann man ein Schema erstellen und für jede Antwort TypeChat ausführen, um einen Datensatz aus diesem Freitext zu erhalten. Das ist extrem nützlich.
    • Je besser die Abstraktion wird, desto leichter wird es, etwas Nützliches zu programmieren.

  • Es gibt einen Punkt, den ich nicht verstehe.
    Warum geht man durch diesen komplizierten Prozess, hofft auf eine gültige Antwort, hängt am Ende einen Validator an, erkennt ungültige Antworten und bittet das Modell dann flehentlich, bitte in der gewünschten Syntax zu antworten?
    Wenn man nur Tokens sampelt, die dem angeforderten Format entsprechen, kann man gültige JSON-Syntax garantieren. Statt jedes Mal gierig das Token mit der höchsten Punktzahl zu wählen, nimmt man einfach das Token mit der höchsten Punktzahl unter denjenigen, die dem gewünschten Format entsprechen.
    Microsofts Guidance macht das bereits so: https://github.com/microsoft/guidance
    OpenAI scheint jedoch nicht die vollständigen Scores aller Tokens offenzulegen, sondern nur die Top-Tokens. Wenn man das Modell lokal betreibt, ist es einfach, Guidance zu verwenden und zu garantieren, dass das JSON jedes Mal korrekt ist, und die Generierung ist auch schneller — seltsam.

    • Das ist ähnlich wie die Geschichte mit den braunen M&Ms[0]. Wenn das Modell semantisch korrekte Daten zurückliefert, sollte man zumindest erwarten können, dass die Syntax stimmt. Wenn es das nicht schafft, muss man die Antwort ohnehin verwerfen.
      Außerdem scheint es auf diese Weise schwierig zu sein, die gesamte Komplexität von TypeScript-Typen abzubilden.
      [0] https://www.snopes.com/fact-check/brown-out/
    • Auf diese Weise kann man zwar syntaktisch korrektes JSON garantieren, aber ob es semantisch korrekt ist, ist eine andere Frage.
      Wenn das Modell eigentlich ein anderes Token einfügen möchte, man es aber zwingt, { zu setzen, könnte die Qualität des danach erzeugten Textes sinken. Ich bin nicht sicher, das ist nur ein Gedanke.
    • Das Sampling nur gültiger Tokens halte ich für sehr vielversprechend.
      Ich habe einmal ein Open-Source-LLM für JSON-Parsing feinabgestimmt und dabei festgestellt, dass für manche Einsatzzwecke selbst 70B Parameter ohne Guided Token Sampling übertrieben sein können. Ich habe auch mit deutlich kleineren Modellen ziemlich gute Ergebnisse gesehen, und die Kombination aus Fine-Tuning kleiner Modelle und Guided Token Sampling scheint interessant.
      Für sehr allgemeine Anwendungen ist Fine-Tuning jedoch möglicherweise nicht perfekt. Es wird problematisch, wenn Eingaben hereinkommen, die im Trainingsdatensatz nicht vorgesehen waren.
    • LLMs können komplexere Szenarien verarbeiten. In einem Verkaufsautomaten könnte man zum Beispiel einfach seine Bestellung sagen, statt den ganzen Bestellvorgang durchzugehen, und das System könnte Formulierungen wie „ein paar Schokoriegel“ anhand des Bestands interpretieren.
      Im Web ergibt das natürlich keinen Sinn. Dort ist es viel einfacher, einfach ein paar Produkte mit der Maus anzuklicken.
    • Wie Llama.cpp kürzlich beschrieben hat, wurde grammatikbasiertes Sampling hinzugefügt, das die Token-Auswahl darauf beschränkt, einem festen Format zu folgen.
      https://github.com/ggerganov/llama.cpp/pull/1773

  • Es fühlt sich an, als würde Anders Hejlsberg alles bauen, woran ich gerade denke.
    Strukturierte Anfragen und Antworten sind mit 100%iger Sicherheit die nächste Evolutionsstufe von LLMs. Die Leute sind Chatbots bereits überdrüssig, und wenn man ohne Textparsing und Prompt-Sorgen irgendein Backend anschließen kann, wäre das gewaltig.

    • Ich möchte ein lokal laufendes LLM mit von mir bereitgestellten aktionsfähigen Interfaces verbinden. So etwas wie „Uhrzeit prüfen“, „Kalender prüfen“ oder „einem Nutzer eine Nachricht schicken“.
      TypeChat scheint in die richtige Richtung zu gehen. Man könnte sich eine zusätzliche Schicht vorstellen wie: „Ordne diese JSON-Eingabe nach Möglichkeit einer der möglichen Aktionen zu.“
      Ich sehe eine saubere hybride Zukunft, in der Bots, also LLMs und Ähnliches, echte Code-Schichten miteinander verbinden. Mal werden sie Teil der Erfassung und Verschlagwortung, mal Teil der Reaktion auf Eingaben.
      Insgesamt ein sehr spannendes Feld, aber alles bewegt sich so schnell, dass ich mich noch nicht tief eingearbeitet habe. Viele kluge Leute arbeiten daran, deshalb habe ich das Gefühl, dass man warten sollte, bis sich der Staub etwas gelegt hat. Trotzdem scheint es schon an dem Punkt zu sein, an dem ich das Home-Interface, von dem ich träume, bauen könnte.
    • Ich habe gestern gerade etwas Ähnliches implementiert, allerdings mit Fokus auf funktionenzentriert statt auf Objekte.
    • Als dynamischer Mapper für die Backend-Schicht könnte das enorm sein.
      Man denke etwa an API-Payloads, die sich rund um Java-Consumer ständig ändern. Im Bankensektor, mit riesigen JSON-Payloads, habe ich in einer Java-Backend-Umgebung extra eine NodeJS-Schicht gebaut, um bei Verstand zu bleiben.
      Mapping ist ein Bereich, in dem LLMs glänzen können.
    • Sehenswert: https://news.ycombinator.com/item?id=36750083

  • Mit einer zugespitzten Lesart gesagt: Wir treten langsam in die Werkzeugisierungsphase von AI ein. Die Leute merken, dass hier nicht besonders viel echter Wert geschaffen wird, aber es ist zu viel Geld in AI investiert worden, also fließt weiter Kapital hinein. Es ist auch ein gutes Thema, um wissenschaftliche Arbeiten darüber zu schreiben, und LangChain ist fast ein Witz, hat aber 10 Millionen Dollar Seed-Finanzierung bekommen.
    DeFi/Krypto hat diese Phase vor zwei Jahren durchlaufen. Es wird ein paar Jahre lang einen seltsamen Schwebezustand geben, und dann werden die Leute langsam merken, dass AI kein Produkt, sondern eine Funktion ist, nur begrenzten Anwendungsbereich hat und die Welt nicht retten wird. Wegen all der Edge Cases wird es kein autonomes Fahren geben, und operieren wird sie auch nicht, weil sie Menschen töten könnte.
    Selbst bei den nützlichsten AI-Tools wie Copilot habe ich immer gesagt, dass sie bestenfalls am Rand nützlich sind. Im besten Fall sparen sie einem ein paar Klicks bei Google, und Agenten sind überhaupt nicht „intelligent“. Vor ein paar Jahren hatten wir mit Chatbots schon einmal eine ähnliche Blase[1], und heute interessiert das niemanden mehr. Das „Metaverse“ war viel schneller vorbei, aber dieselbe Massenpsychologie war am Werk. Erst ist es „das nächste große Ding“, dann eben doch nicht.
    [1] https://venturebeat.com/business/facebook-opens-its-messenger...

    • Der Aussage, AI sei nur eine Blase mit begrenztem Anwendungsbereich, widerspreche ich entschieden.
      Du greifst dir ausgerechnet die schwierigsten Einsatzfälle für AI heraus, etwa autonomes Fahren und Chirurgie. Die Arbeit der meisten Menschen ist nicht eine Frage von Leben und Tod und daher sehr gut für Automatisierung geeignet. Selbst wenn in Berufen, in denen es um Leben und Tod geht, ein menschlicher Faktor bleibt, werden sie wahrscheinlich durch AI-Agenten ergänzt. Zum Beispiel könnte es Pflicht werden, dass Ärzte oder Pflegekräfte bei Diagnosen mit AI zusammenarbeiten, auch wenn die Operation selbst von einem Menschen durchgeführt wird.
      Vergleichst du die Chatbot-Blase von vor ein paar Jahren ernsthaft mit heute? ChatGPT hat in wenigen Monaten 100 Millionen Nutzer erreicht, und wirklich sehr viele Menschen haben es ausprobiert. Die Chatbot-Blase von vor ein paar Jahren hatte kaum Präsenz.
      Dass Copilot und Ähnliches nur am Rand nützlich seien, liegt daran, dass wir gerade die schlechteste Version sehen. ChatGPT hat mein Leben verändert, und es führt noch nicht einmal Code aus. Code Interpreter schon, aber den habe ich noch nicht getestet.
      Um 2030 herum werden Menschen wahrscheinlich keinen Code mehr tippen, sondern Maschinen Prompts geben und AI-Agenten dirigieren. Bis dahin dürfte vermutlich auch der Großteil der Berufe automatisiert sein.
      AI ist nicht bloß ein Trend, sondern wird jede Branche verändern, und zwar viel schneller, als die Leute denken. Dieser Zynismus, der die Implikationen von AI herunterspielt, indem er sie mit dem Metaverse vergleicht, ist absurd und fantasielos. Gerade bei AI-Agenten gibt es zwar noch viel zu tun, aber wir werden wahrscheinlich viel schneller dort ankommen, als die Leute denken, und die Auswirkungen werden enorm sein.
    • Jedes Mal, wenn ich ChatGPT benutze, habe ich das Gefühl, eine andere Technik zu sehen als andere Leute. Es heißt, es beantworte jede Frage und bringe einem alles bei, aber in Wirklichkeit fühlt es sich eher wie ein Content-Farm-Dienst an. Bei Copilot ist es ähnlich: Meistens ist es einfacher, den Code selbst zu schreiben, als unter schlechten Beispielen das am wenigsten schlechte herauszusuchen und die Bugs zu beheben.
      Andererseits hat AlphaGo nicht lange gebraucht, um von einem Zustand, in dem es schlechte Züge „halluzinierte“, zum besten Go-Spieler der Welt zu werden. Wenn das bei Sprachmodellen ebenfalls möglich ist, könnte GPT-x die heutige Diskussion komplett wegfegen.
    • Der Aussage „Es wird kein echter Wert geschaffen“ widerspreche ich entschieden. In meinem Anwendungsfall gibt es ein sehr klares Gegenbeispiel.
      GPT-4 ist enorm hilfreich, wenn Fachleute Randaufgaben erledigen, bei denen ihre eigenen Fähigkeiten grundsätzlich ausreichen, das Domänenwissen aber schwächer ausgeprägt ist.
      Ich schreibe seit 10 Jahren Code und lerne seit Kurzem zum ersten Mal Machine Learning; ich nutze GPT-4 jeden Tag und bin sehr zufrieden.
      Natürlich können die Ecken und Kanten gelegentlich nerven. Für mich ist das handhabbar und keine große Last. Ich habe mich daran gewöhnt, sie zu ignorieren oder zu umgehen, und der Umgang mit solchen Werkzeugen ist definitiv eine eigene Fähigkeit.
      Ich glaube, der gelieferte Wert wird weiter wachsen. Wir haben noch nicht einmal alle tief hängenden und mittel hoch hängenden Früchte geerntet.
    • Der entscheidende Unterschied zu DeFi/Krypto ist, dass man dort, so technisch beeindruckend es auch war, das eigene Handeln komplett ändern musste, um überhaupt den ersten Nutzen daraus zu ziehen.
      Moderne AI, in der Praxis meist LLMs, ist in fast allen Wirtschaftssektoren sofort breit einsetzbar. Deshalb bauen und veröffentlichen bereits viele Menschen Funktionen damit. In dieser Technologie steckt enorm viel Wert. Verändert sie die Welt vollständig? Nein. Aber sie reicht aus, um neue Produktkategorien zu schaffen und einen großen Teil der Fähigkeiten bestehender Produkte grundlegend zu verbessern.
    • Ich halte das für eine ziemlich vernünftige Interpretation. AI ist vielseitig nutzbar und für manches wirklich gut, aber nicht die Universallösung, auf die die Leute hoffen.

  • Ich verstehe nicht, warum von den Sprachassistenten von Apple, Google, Amazon und Microsoft bisher keiner ein LLM in den Dienst integriert hat und warum OpenAI noch keinen eigenen Sprachassistenten veröffentlicht hat.
    Wenn Websites außerdem wie bei RSS standardisierte URLs für AI-Interaktionen exponieren und ihre Schnittstelle über TypeChat offenlegen würden, könnte uns das ein gutes Stück weiterbringen.

    • Es ist gut möglich, dass OpenAI einen eigenen Assistenten baut. Karpathys „Building a kind of JARVIS @ OреոΑӏ“ deutet darauf hin, und Microsoft arbeitet natürlich vermutlich auch daran, Cortana mit dem OpenAI-LLM zu integrieren oder neu zu interpretieren.
      Der Wert liegt allerdings weit stärker in der Fähigkeit, tatsächlich Aktionen auszuführen, als in einem rein sprachbasierten LLM. Am Beispiel von Alexa braucht man ein System, das Smart-Home-Steuerung vorhersehbar und debuggbar verarbeitet. Sonst werden die Leute schnell genervt.
      Ich halte das eindeutig für machbar, aber Systeme wie die heutige Alexa oder Siri oder das weniger genutzte Cortana bestehen aus jahrelang gewachsenen Regeln und Software auf Basis schwächerer Modelle und nutzen viele Hooks und APIs. Damit das funktioniert, muss man die Hauptteile des Systems umbauen und es zugleich verbessern, ohne die aktuelle Qualität zu verschlechtern, und das braucht Zeit.
      Dazu kommt, dass solche Assistenten tatsächlich kein Geld verdienen und meist ein Verlustgeschäft sind. Sie sind nur für große Unternehmen wertvoll, die auf anderem Weg Geld verdienen oder ihr Geschäft vorantreiben können, etwa über Smartphones oder Shopping, daher ist der Anreiz für Startups gering.
      Ich habe früher sowohl bei Cortana als auch bei Alexa gearbeitet und auch viel darüber nachgedacht, auf Basis der LLM-Fortschritte eine neue Version von Grund auf zu bauen. Die Technik war insgesamt naheliegend, und es gab neue Ideen für Anwendungsfälle, die jetzt möglich geworden sind, aber ich konnte kein tragfähiges Geschäftsmodell finden. Deshalb mache ich inzwischen etwas völlig anderes.
    • Als ich zum ersten Mal verstanden habe, was ChatGPT ist, war mein Gedanke: „Ah, so hätte Siri eigentlich sein sollen.“
    • Seit ich ChatGPT und Bing benutzt habe, wirkt es fast lächerlich, mit Alexa zu sprechen. Es ist wirklich frustrierend zu sehen, wie gute Hardware seit Jahren von miserabler Software ausgebremst wird.
    • Microsoft macht genau das, um Cortana in Windows 11 zu ersetzen.
    • Ich hoffe wirklich auf etwas, das sich zur Steuerung von Home Assistant verwenden lässt.
      Dafür eine Cloud-basierte API zu nutzen, ist mir allerdings viel zu unsicher, deshalb hätte ich gern etwas, das auf einem Server im Haus läuft. Gleichzeitig müssten Spracherkennung und Antwortzeit sehr schnell sein, sodass man überhaupt nicht das Gefühl hat zu warten.
      Ich habe schon einige DIY-Versuche für persönliche Assistenten gesehen, aber sie hatten immer eine ziemlich hohe Latenz, sodass sie bei häufiger Nutzung schnell nerven würden.

  • Es gibt diesen Punkt, dass man leicht Antworten wie { "name": "grande latte" } bekommen kann.
    Wenn der Typ aber Item = { name: string; ... size?: string; } ist, verstehe ich nicht, wie das verhindern soll, dass man name: "grande latte" erhält.
    In der Beispielantwort steht "size": 16, und das wird als „ziemlich gut“ bezeichnet, obwohl nicht einmal der tatsächlich angeforderte Typ zurückgegeben wird. Vermutlich ist das einfach ein Tippfehler im Beispiel; wenn ja, wirkt die Grundidee trotzdem ziemlich cool.

    • Danke, dass du darauf hingewiesen hast. In einer früheren Fassung des Blogposts wurde ein anderes Schema verwendet, bei dem size versehentlich als number definiert war. Das Schema wurde geändert, aber ich habe den Prompt nicht erneut ausgeführt; das sollte jetzt korrigiert sein.
    • Ich finde dieses Beispiel insgesamt ziemlich schwach. Das Problem geht über einen einfachen Tippfehler hinaus.
      Wahrscheinlich will man von vornherein gar kein String-Feld name. Es gibt nichts, was Werte wie { name: “the brown one”, size: “the espresso cup”, … } verhindert, und das ist im Grunde genauso schlecht wie einfach den ursprünglichen String zu parsen.
      Vermutlich möchte man für jedes Feld einen großen String-Union-Typ, der die bekannten Werte repräsentiert. Dann kann man das LLM darauf einschränken, eines davon zu treffen.
      Allerdings frage ich mich, warum man das an eine Typsyntax binden sollte. Etwas wie Zod, wo man solche Union-Typen aus Laufzeitdaten aufbauen kann, erscheint dafür passender.
      Man braucht auch Einschränkungen wie, dass die Menge eine positive ganze Zahl und kein Bruch sein muss. Natürlich kann man JSON-Werte später validieren, aber dann sieht der Benutzer zwei Arten von Fehlern: einmal Fehler vom LLM in flüssig-menschlicher Sprache und einmal seltsam technische Fehler wie „Der Mengenwert ist zu groß“.
      Für solche Dinge scheint Typsyntax am falschen Ort zu sein.
    • Das wirkt einfach wie ein Dokumentationsfehler. Offenbar wurde beim Fertigstellen der Präsentation spät von Unzen auf Standardgrößen umgestellt und vergessen, den Ausgabewert entsprechend anzupassen.
      Mit dem bereitgestellten Code gibt es keine Möglichkeit, wie das System „grande“ auf 16 abbilden könnte, und 16 scheint auch sonst nirgends verwendet zu werden.
    • Im folgenden Abschnitt wird behandelt, was passiert, wenn man den Typ ignoriert, also war das vermutlich in diesem Sinn gemeint.

  • Es wirkt so, als würde das LLM wiederholt ausgeführt, bis es etwas ausgibt, das die Typprüfung besteht, und dann mit der Fehlermeldung erneut gepromptet.
    Eine nette Idee, und es scheint auch zu funktionieren, aber bei großen Modellen und langen Eingabeprompts können die Kosten hoch werden. Es dürfte keine Lösung für alle Szenarien sein.

    • Wäre es bei OpenAI nicht zumindest intern besser, die neue Function-Calling-Funktion zu verwenden?
    • Ich weiß nicht genau, wie TypeChat funktioniert, aber Guidance [1] ist ein ähnliches Projekt und kann das Format tatsächlich erzwingen, indem es in das Token-Sampling integriert wird.
      [1]: https://github.com/microsoft/guidance
    • Die meisten Produkte würden sich vermutlich zuerst um Product-Market-Fit kümmern und danach versuchen, die Kosten zu senken.
      Außerdem ist die Annahme ziemlich plausibel, dass sich Modelle in diese Richtung verbessern werden, weil der Markt strukturierte Ausgaben verlangt.

  • Ich habe diese Woche etwas sehr Ähnliches, aber mit kleinerem Umfang, für Laravel PHP gebaut und veröffentlicht: https://github.com/adrenallen/ai-agents-laravel
    Ich denke, Engineers sollten mit einem gegebenen LLM leicht neue „Bots“ starten können. Es gibt viel langweilige Arbeit dabei, Funktionen in ein von ChatGPT verstandenes Format umzuwandeln, Antworten zu verarbeiten und dann wieder zu parsen.
    Mit solchen Systemen kann man sich darauf konzentrieren, echten PHP-Code zu schreiben und ein paar klare Kommentare hinzuzufügen, und der Bot kann diesen Code dann bei jeder Aufgabe direkt als Werkzeug verwenden.
    Außerdem macht dieser Ansatz das Teilen von Code viel einfacher. Wenn jemand eine Funktion schreibt, kann man sie in einen neuen Bot übernehmen und sofort verwenden. Dass damit die „Schicht zur Umwandlung, damit das LLM sie nutzen und verstehen kann“ entfällt, ist großartig und beschleunigt das Bauen erheblich.
    Es ist noch nicht perfekt, aber ich denke, dass am Ende alles in diese Richtung gehen wird, wenn wir den Code anderer besser nutzen wollen. Wenn man daran denkt, wie wir heute beim Coden Paketmanager verwenden, hätte ich gern einen Paketmanager für KI-spezifische Tools. Man installiert eine Bibliothek zum „Abrufen des Wetters“, fügt sie meinem Bot hinzu, und jetzt kann er das Wetter abrufen.

    • Ich arbeite an einem ähnlichen, aber breiter angelegten Ansatz und habe deshalb einen Stern vergeben. Einige Ideen sind wirklich elegant.

  • Moment, geht es hier um Runtime-Validierung von Objekten gegenüber TypeScript-Typdefinitionen? Wenn das als eigenständige Bibliothek oder Funktion ausgeliefert werden kann, könnte das in TypeScript-Codebasen für Dinge wie die Validierung von API-Antwort-Payloads ein absoluter Gamechanger sein.

  • Ich bin sehr überrascht, dass hier nicht guidance [0] verwendet wird.
    Es könnte das Ausfüllen von Pflichtfeldern vorschlagen, den Bedarf an Validierung[1] verringern und am Ende vermutlich auch GPU-Zeit sparen.
    Es gibt sicher einen Grund dafür, und ich würde ihn wirklich gern kennen.
    Nebenbei gesagt habe ich genau so etwas gebaut, und dann kam Microsoft plötzlich herein und hat mir das Mittagessen weggegessen.
    [0] https://github.com/microsoft/guidance
    [1] https://github.com/microsoft/TypeChat/blob/main/src/typechat...