Warum ChatGPT aktuell Zeitverschwendung ist

Eine erste kurze Analyse - ChatGPT ist aktuell in gewissen (IT) Kreisen in vieler Munde. Manche sehen bereits die Suchmaschine von Google in Gefahr. Man könnte jetzt die mathematischen und technischen Grundlagen von solchen Systemen beleuchtet und aufdecken, wo die derzeitigen und künftigen Schwachstellen liegen. Und erklären, weshalb es in Bezug auf solche Systeme sinnvoll ist, Worte und Begriffe wie Intelligenz und Lernen mit Bedacht zu wählen.

Ich möchte in diesem Beitrag aber vielmehr an praktischen Beispielen aufzeigen, weshalb die Verwendung von ChatGPT zurzeit bei den ersten paar Fragen eine reine Spielerei ist und dann sehr rasch in Zeitverschwendung übergeht.

Bevor ich mit den Beispielen beginne sei aber noch gesagt, dass die derzeitigen Ergebnisse von OpenAI mit ChatGPT unter einem technischen Aspekt durchaus zu würdigen sind. Es ist auch keinesfalls so, dass die Antworten immer falsch sind. Gerade das "Sprachgefühl" ist bemerkenswert gut. Aber gerade auch dadurch entsteht der falsche Eindruck einer Intelligenz die derzeit noch nicht vorhanden ist. Ich habe zuerst mit Englisch begonnen und dann die Beispiele für diesen Beitrag auf Deutsch gemacht. Die Ergebnisse sind in den Beispielen zwischen Englisch und Deutsch gut vergleichbar. Die bei diesen Beispielen gefundenen Schwächen sind auch in Englisch vorhanden.

Eine generelle Schwäche der derzeitigen Version ist die fehlende Belastbarkeit. Auf dieselbe Fragen bekommt man nicht immer dieselbe Antwort. Wie sich gezeigt hat ist gerade die Funktion "Regenerate Response" ein richtiger "Horoskop"-Button. Dadurch, dass man nicht immer dieselben Fakten auf dieselbe Frage bekommt, ist es als System schlicht nicht nutzbar, wenn man auf verlässliche Antworten und Werte angewiesen ist.

Aber nun genug der Sätze, schauen wir uns ein paar konkrete Beispiele an.

Dieses erste Beispiel zeigt die Grenzen des sprachlichen Verständnisses auf. Die Frage kursiert in den Schulen immer wieder in der Mittelstufe und die meisten Kindern in diesem Alter haben keine grosse Mühe den sprachlichen Kontext zu verstehen um auf die richtige Antwort zu kommen. Das System hat Mühe mit Doppeldeutungen und Sarkasmus - zugegeben letzterer ist nicht jedermanns Sache.

Nun schauen wir uns die mathematische Aufgabe 8+8/8+8*8-8 an. So ein typisches Beispiel, welches auch hin und wieder in Chats und Post auftaucht um die mathematischen Grundlagen der Rechenreihenfolgen in Erinnerung zu rufen. Jeder halbwegs vernünftige Taschenrechner liefert das richtige Resultat. Wir geben ChatGPT mehrere Chancen und fragen die gleiche Fragen mehrmals ab, teils mit "Regenrate Response", teils in einem neuen Chat. Schauen wir uns die Antworten an:

Das Gute zuerst. Die Herleitung stimmt, aber weshalb schreibt er im ersten Satz gleich das falsche Resultat hin? Rechnungsweg korrekt, falsche Antwort bei der eigentlichen Lösung, würde wohl einen Teil der Punktzahl im Mathetest geben.

Jetzt wird es leider nur noch abenteuerlicher ... 

An diesem Beispiel sieht man sehr gut was ich meine mit, das System ist nicht belastbar. Aber für eine letztlich doch einfache mathematische Aufgabe keine einzige vollständig korrekte Lösung?

Das Jahr vergeht schnell, Ostern naht. Wann ist nächstes Jahr schon wieder Ostern? Fragen wir ChatGPT - oder besser doch nicht?

Alle Feiertagskalender die ich konsultiert haben geben an, dass Ostern im Jahr 2023 am Sonntag, 9. April 2023 ist. Kann ja mal passieren, man hat nie ausgelernt. Schreiben wir ChatGPT, dass das nicht stimmt, und welches das richtige Datum ist.

Woher weiss er, dass der 09.04.2023 nun korrekt ist? Kann man ihm einfach falsche Fakten unterjubeln? Nein, keine Angst. Wenn man das nächste Mal erneut fragt, gibt er wieder das falsche Resultat aus. Hier bleibt es für einmal belastbar falsch.

Gehen wir zurück auf die Fähigkeit der Sprache. Schliesslich ist es ja letztlich ein trainiertes Sprachmodell. Wann war schon wieder die Mondlandung? Ich meinte es war 1968 - nicht wahr?

Die Antwort ergibt irgendwie wenig Sinn so. Die Frage mit "Ja" beantworten und dann andere Fakten liefern. Hier sieht man die Grenze des "Verständnisses", wenn zwei (oder mehr) Informationen überprüft und beantwortet werden müssen. Einerseits geht es darum, ob es die USA waren und andererseits geht es um das Jahr.

Es geht aber noch besser mit der sprachlichen Verwirrung:

Alles klar? Wussten Sie, dass Gagarin den Weltraum nicht verlassen konnte? Wo wollte er hin?

Gut, zurück zur Erde. Wie Sie sicher wissen, kann man die Höhe eines Berges gegen unterschiedliche Referenzpunkte messen oder besser ausgedrückt berechnen. Gegenüber dem Meer ist die üblichste. Hier lassen wir einmal die unterschiedlichen Meerhöhen bei Seite. Dazu könnten sie in Basel bestimmt mehr erzählen. Neben der reinen Höhe über Meer gibt es noch die Höhe gemessen vom Erdmittelpunkt aus. Also welcher Berg ragt am höchsten ins "All" könnte man sagen. Oder welcher ist am "Längsten", wenn man seine Höhe unter dem Meer auch dazu zählt. Fragen wir einmal nach, welcher der Höchste ist, gemessen am Erdmittelpunkt.

Der lügt wie gedruckt, anders kann man es nicht formulieren. Ignoriert zuerst die Frage bezüglich dem Referenzpunkt, behauptet dann dass quasi immer gegen den Meeresspiegel gemessen wird und schliesst damit, dass es überhaupt keine Rolle spielt und der Mount Everest sowieso der Höchste ist.

ChatGPT soll auch sehr gut im Programmieren sein. Muss sich Stackoverflow fürchten? Ich glaube noch nicht. Aber schauen wir uns einmal ein Programm von ChatGPT an. Wir wollen berechnen lassen, wie ähnlich sich zwei Namen sind:

Sieht syntaktisch gut aus, lässt sich auch ausführen. Aber ergibt es auch einen Sinn, resp. ist es nützlich? Kaum. Das Programm gibt für die Namen "Abcd" und "bcd" eine Ähnlichkeit von 0 aus, obwohl nur ein Buchstabe fehlt. Leider der am Anfang. Es berücksichtig überhaupt nicht die bereits gezählten Fehler. Fazit: Syntaktisch korrekt, inhaltlich unbrauchbar. Aber geben wir ChatGPT eine zweite Chance:

Da war mal was mit Levenshtein. Zugegeben, die Idee ist gar nicht schlecht. Edit-Distanz verwenden und das Resultat als Prozentsatz zur Länge des längeren Wortes berechnen. Wäre da nicht die Tatsache, dass das Programm einen Laufzeitfehler wirft. Eine Funktion "levenshtein" gibt es in JavaScript nicht und diese wurde weder im Code definiert noch wurde eine externe Bibliothek mit einer solchen Funktion eingebunden. Fazit: Gut gemeint, der Code funktioniert aber nicht.

Gefährlich ist es, dass ChatGPT durch die hin und wieder durchaus sprachliche Eloquenz eine Intelligenz vortäuscht, die definitiv nicht vorhanden ist. Das zeigt das nachfolgende primitive Beispiel:

Der Vorteil für die Menschen ist, dass ein solches System damit leicht als nicht menschlich zu entlarven ist. Es beherrscht SABTA, dass muss man ihm lassen (Sicheres Auftreten Bei Totaler Ahnungslosigkeit).

Zusammenfassung:

Aus meiner Sicht ist die Fehlerrate von ChatGPT aktuell viel zu hoch, um produktiv einen Mehrwert zu bieten. Jede Antwort muss analysiert und kritisch hinterfragt werden. Man ist wesentlich effizienter, wenn man die Antworten selber mit Suchmaschinen, welche Quellen liefern, oder direktem Quellenzugriff recherchiert. Obwohl gewisse Antworten hin und wieder sprachlich verblüffen, ist es meiner Meinung nach aktuell Zeitverschwendung, ChatGPT aktiv zu nutzen.

P.S. Die Fähigkeit auf Rückantwort(en) zu reagieren, ist noch eingeschränkt. Auch hier gilt: Singular bleiben und sich wenn möglich auf die ursprüngliche Frage fokussieren. Sonst wiederholt er einfach die vorherige Antwort.

API oder Kundenschnittstelle?

Lohnt sich eine API-First Strategie, oder sollte man besser zuerst die Kundenschnittstelle im Fokus haben?

Doch was ist, wenn ein API auch eine Kundenschnittstelle ist?

 

Eine Frage der Perspektive

Was genau "die Kundenschnittstelle" ist, liegt letzlich an der Prespektive. Oder anders formuliert: Es hängt davon ab, was für Kunden Sie haben und wie diese genau mit Ihnen interagieren. Im B2C-Geschäft mit natürlichen Personen als Kunden ist ein API in der Regel keine Kundenschnittstelle. Ein API muss auf der Kundenseite implementiert werden um sinnvoll genutzt werden zu können. Das bedeutet, dass Sie bspw. im Kontext von Open-Banking im Sinne eines offenen API à la PSD2 mindestens teilweise die Kundenschnittstelle verlieren. Jedenfalls potentiell für jene Aktivitäten, die Sie via API zur Verfügung stellen. Nutzt Ihr Kunde eine APP eines Drittanbieters, besetzt dieser Drittanbieter die Kundenschnittstelle. Er kann in dieser APP (je nach Funktionalität) auch einen Bankwechsel anbieten. Sie haben als Bank ein API angeboten (und eine andere auch) und nun werden Sie einfach ausgetauscht.

Im Falle von B2B kommt es auf die konkrete Dienstleistung und Ausgestaltung der Nutzung an, ob ein API als Kundenschnittstelle angesehen werden kann. Ist die Nutzung exklusiv und die Implementierung des API nicht einfach ersetzbar, d.h. nicht jeder kann/darf es nutzen und das API selber (die Spezifikation) ist proprietär, dann kann das API im Kontext durchaus als Kundenschnittstelle angesehen werden.

Vermischen Sie nicht die technische Sicht der Dinge mit dem Business

Die Frage nach API-First oder Kundenschnittstelle stellt sich in dieser Form nur aus Sicht Business. Es gibt aber auch noch eine rein technische Sicht. API-First ist nicht gleichzusetzen mit Open-API oder Open-Banking etc. Wer Funktionen zuerst als sauberes API implementiert, muss dieses weder allen zugänglich machen noch als "public" veröffentlichen. Stellen Sie also sicher, dass Sie bei der Formulierung der Strategie präzise sind und intern ein gemeinsames Verständnis haben, was aus Sicht Business gemeint und gewollt ist. Und bewahren Sie der IT die interne Freiheit, die Anforderungen architektonisch so umzusetzen, wie es aus Sicht IT am sinnvollsten und nachhaltigsten ist. Eine technische API-First Strategie kann gerade im Kontext von Microservice-Architekturen ein sinnvoller Ansatz sein. Natürlich ist es später einfacher ein Public-API anzubieten, wenn man bereits intern auf standartisierte API setzt. Dennoch gibt es durchaus Unterschiede zwischen rein internen und öffentlich angebotenen API. Das fängt bei den Use-Cases an und hört nicht bei API-Management-Anforderungen wie dem Zählen und Verrechnen der Nutzung auf. Von daher muss am Anfang der Spezifikation klar sein, wer der Nutzer des API ist. Es gibt kein API welches für alle Use-Cases gleichermassen geeignet ist.

Tanzen Sie nur auf mehreren Hochzeiten gleichzeitig, wenn Sie sich nicht umziehen müssen

Das eine tun und das andere nicht lassen, könnte man sagen. Könnte man. Sollte man aber nicht in jedem Fall. Die Umsetzung einer Strategie braucht Zeit und bindet Ressourcen. Verschiedene Strategien gleichzeitig anzugehen kann daher dazu führen, dass keine so richtig umgesetzt werden kann und in Fahrt kommt. Schlimmsten Falls kommen die unterschiedlichen Strategien einander sogar in die Quere und behindern einander gegenseitig. Ist das API keine Kundenschnittstelle, fahren Sie eine Kundenschnittstellen-Strategie nur dann parallel zur einer API-First Strategie, wenn Sie das API ziemlich 1:1 für die Kundenschnittstellen-Strategie nutzen können und beide eine vergleichbare Timeline haben. Falls etwas nicht zutreffend ist, setzen Sie die beiden Strategien lieber sequenziell um.

Was ist die Motivation einer API-First Strategie?

Ein API hat zwei grosse Vorteile:

1. Es hat eine hohe Wiederverwendbarkeit;
2. Die konkrete Nutzung durch einen Endbenutzer kann verschieden implementiert werden (via APP, Web-Applikation, oder mittels Chat-Bot etc.).

Die Erstellung erfordert einen klaren Fokus und die Definition von klaren Use Cases. Damit befasst man sich eingehend mit dem Business und dem möglichen Kundennutzen. Dadurch dass ein API unabhängig einer konkreter Client-Implementierung ist, ist ein API grundsätzlich auch langlebiger und die Investition daher nachhaltiger. Obwohl es klare Use Cases braucht (zumindest sehr zu empfehlen!), können damit später auch immer wieder Use Cases abgedeckt werden, an welche man bei der Spezifikation so noch nicht gedacht hat.

Last but not least kann mit einer API-Strategie die Entwicklung einfacher modularisiert werden. Beispielsweise kann das API intern Implementiert werden, während man gewisse darauf basierende APP-Funktionen in einem Outsourcing entwickeln lässt.

Was ist die Motivation einer GUI-basierten Kundenschnittstellen Strategie?

Eine direkte GUI-basierte Kundenschnittstelle ist sofort durch einen Endkunden nutzbar. Der Nutzen ergibt sich somit unmittelbar nach Fertigstellung. Dadurch ist ein rasches Kundenfeedback möglich und das Produkt kann rasch verbessiert und angepasst werden. So wie es von den Kunden letztlich in der Realität wirklich gebraucht wird. Greift der Business-Case nicht, waren in der Regel weniger Investitionen notwendig. In einer agiler Entwicklung können damit auch früher Feedbacks von Fachleuten (Business) abgeholt werden, da diese mit einer GUI etwas anfangen können und Teile davon frühzeitig bewerten können.

Es gibt mehr Leute (vor allem auch vom Business), welche eine GUI spezifizieren können um Funktionen zu beschreiben, als eine saubere API-Spezifikation zu verfassen.

Wie entscheidet man am besten?

Die richtige Antwort ist natürlich die am wenigsten hilfreiche: Kommt drauf an. Während noch bis vor ein paar Jahren generelle Strategien wie "Mobile-First" angesagt waren, geht die Tendenz mehr Richtung Entscheid pro Produkt/Projekt. Es gibt dann nicht mehr eine generelle "API-First Strategie" für das Unternehmen. Vielmehr entscheidet man für jedes Produkt/Projekt individuell, welche Strategie sich besser eignet. Für die Modernisierung der etablierten Trading-Plattform eignet sich vielleicht eine API-First Strategie. Für das neue APP-Produkt, wo man sich zur Hypothek noch gleich den Haus-Service und den Termin mit dem Kaminfeger für das Cheminée buchen kann, vielleicht eher eine Kundenschnittstelle-Strategie, wo direkt nur die eigentliche APP entwickelt wird, ohne öffentliche API der Funktionen.

Das Wichtigste ist, dass die Entscheidung bewusst und nach klar definierten Kriterien gefällt wird. Ein generelles Richtig oder Falsch gibt es nicht.