Vier Wege, ein KI-Job: Warum dieselbe Aufgabe unterschiedlich scheitert
Ein Tester hat denselben KI-Auftrag auf mehreren Wegen ausgeführt, um das Hundertfache der Datenmenge verarbeitet und die Läufe an verschiedenen Tagen wiederholt. Die Ergebnisse zeigen, wie unterschiedlich zwei KI-Modelle bei identischen Anweisungen Fehler machen.
Veröffentlicht am 9. Oktober • Zuerst veröffentlicht auf kotwal-itpro.github.io
Zuerst veröffentlicht auf kotwal-itpro.github.io.
Vor zwei Tagen habe ich darüber geschrieben, dass ich zwei KI-Modellen dieselben Anweisungen gegeben habe und beobachtet habe, wie sie auf entgegengesetzte Weise Fehler gemacht haben. Seitdem habe ich zwei weitere Arten hinzugefügt, den Auftrag auszuführen, ihn 100-mal größer gemacht und ihn an verschiedenen Tagen erneut laufen lassen. Hier ist, was sich geändert hat und was nicht.
Derselbe Auftrag wie zuvor. Ich habe erfundene Kundensupport-Chats, und für jeden davon muss die KI angeben, um welches Produkt es geht, welche Art von Problem vorliegt, wie sich der Kunde fühlt und ob er darum gebeten hat, kontaktiert zu werden. Ich habe die Chats selbst geschrieben, also kenne ich jede richtige Antwort.
Die ersten vier sind Batch-Dienste. Man sendet alles auf einmal und sammelt die Antworten später ein, für etwa die Hälfte des üblichen Preises. Der letzte hat überhaupt keine Warteschlange. Es ist einfach ein Computer, der die Arbeit erledigt.
Alle fünf haben das Produkt und die Problemart jedes Mal richtig erkannt. Fast alle haben auch die Nachfrage-Frage richtig beantwortet, sobald ich sie richtig erklärt hatte (das war die große Lektion vom letzten Mal).
Bei der Frage, wie sich der Kunde fühlt, trennen sich die Modelle in drei Gruppen:
Zu negativ. OpenAI (93% richtig) und mein selbst gehostetes Modell (85% richtig). Ein Kunde schreibt: „Mein Laptop hat nach drei Tagen aufgehört zu funktionieren. Sagen Sie mir, was Sie von mir brauchen.“ Das ist eine ruhige, hilfsbereite Nachricht über ein Problem. Beide stuften den Kunden als unzufrieden ein. Mein eigenes Modell tat dies doppelt so oft und verwandelte manchmal sogar zufriedene Kunden in unzufriedene.
Zu nachsichtig. Gemini (82% richtig). „Das ist wirklich frustrierend“ kam als neutral zurück.
Abhängig von einer Einstellung. Claude schnitt beide Male etwa gleich ab, 89% und 91%. Mit aktiviertem thinking verteilten sich seine Fehler etwa gleichmäßig auf zu streng und zu nachsichtig. Mit deaktiviertem thinking waren fast alle zu streng, wie bei OpenAI. Dasselbe Modell, dieselben Anweisungen, ein Schalter, und die Verteilung seiner Fehler änderte sich. Die beiden Einstellungen lieferten bei etwa 1 von 9 Chats unterschiedliche Antworten.
Wenn Sie eines aus diesem Beitrag mitnehmen: Ein Wert sagt Ihnen nicht, in welche Richtung ein Modell falsch liegt. Wenn etwas nachgelagertes unzufriedene Kunden zählt, können zwei Modelle mit ähnlichen Werten sehr unterschiedliche Zählungen liefern.
Das selbst gehostete Modell hat mich überrascht. Einmal eingerichtet, erledigte es alle 1.000 Chats in 29 Sekunden. Die gehosteten Dienste brauchten 3 bis 10 Minuten, weil man in ihrer Warteschlange wartet. Es kostete auch nur etwa 0,004 $ pro 1.000 Chats an GPU-Zeit, etwa ein Zehntel der billigsten gehosteten Option.
Der Haken ist die Einrichtung. Die Installation der Software, das Herunterladen des Modells und die Vorbereitung dauerten etwa 8 Minuten auf der gemieteten GPU, was mehr kostete als die eigentliche Arbeit. Und es war das ungenaueste der fünf Modelle bei den Gefühlen. Es ist auch ein älteres, kleineres Modell als die gehosteten, also ist das nicht das letzte Wort zum Self-Hosting.
Dann habe ich den Auftrag 100-mal größer gemacht: 100.000 Chats, auf jedem der drei Batch-Dienste.
Nichts ist verloren gegangen. Alle drei schickten alle 100.000 Antworten zurück. Keiner brauchte einen erneuten Versuch, und die Werte stimmten fast exakt mit den kleineren Läufen überein. Ich hatte erwartet, dass hier der Ärger beginnt. Tat er nicht.
Das Warten hat sich stark verändert. Gemini erledigte es in 10 Paketen von jeweils 10.000, etwa 4 Minuten pro Paket, also insgesamt 45 Minuten. Claude nahm alle 100.000 auf einmal und brauchte 2 Stunden und 44 Minuten. OpenAI war der Sonderfall. Seine Pakete brauchten am frühen Nachmittag 14 Minuten, dann verlangsamten sie sich bis zum Abend auf fast anderthalb Stunden. Derselbe Auftrag, dieselbe Größe, sechsmal langsamer, je nachdem, wann ich ihn abgesendet habe.
Der Preis pro 1.000 Chats änderte sich nicht mit der Größe: etwa 9 Cent bei OpenAI und Gemini, 5 Cent bei Claude.
Der einzige echte Fehler lag bei mir. Acht Stunden in den OpenAI-Lauf hinein brach meine Internetverbindung beim Hochladen des neunten Pakets ab, und der Auftrag stoppte. Genau dafür habe ich das Werkzeug gebaut. Es führt Buch über das, was erledigt ist, sodass es beim erneuten Ausführen desselben Befehls die letzten 20.000 Chats aufnahm und die 80.000 bereits fertiggestellten nicht erneut sendete oder bezahlte. Es wartet jetzt auch und wiederholt den Versuch, wenn die Verbindung abbricht, statt aufzugeben.
Eine Sache ging schief, bevor überhaupt Arbeit begann. Ich sendete Gemini alle 100.000 Chats als einen einzigen Auftrag. Das Hochladen dauerte fünf Minuten, dann sagte Gemini:
Sie haben Ihr aktuelles Kontingent überschritten, bitte überprüfen Sie Ihren Tarif und Ihre Abrechnungsdaten.
Das klingt nach einem Abrechnungsproblem. War es nicht. Als ich dieselbe Arbeit in Paketen von 10.000 nacheinander sendete, lief jedes Paket sofort durch. Das eigentliche Problem war, dass ein einzelner Auftrag zu groß für die Menge an Arbeit war, die mein Konto in der Warteschlange haben darf. Die Nachricht sagte das nur nicht.
Das hat mein Werkzeug verändert. Es erkennt jetzt eine „Warteschlange voll“-Antwort, wartet oder sendet kleinere Pakete und zählt sie nicht als fehlgeschlagenen Versuch für die betroffenen Datensätze.
Das war die Frage, auf die ich am ehesten eine Antwort wollte. Ich sendete exakt dieselben 1.000 Chats mit denselben Anweisungen an jeden Dienst an drei aufeinanderfolgenden Tagen: Mittwoch, Donnerstag und Freitag.
Hier kommt der seltsame Teil. Die Gesamtwerte bewegten sich von Tag zu Tag kaum: Geminis Wert für die Frage, wie sich der Kunde fühlt, lag bei 82%, 81% und 81%. Darunter war es aber jedes Mal ein anderer Satz von Chats, der richtig war. Jeder einzelne Chat, der sich änderte, wurde an einem Tag richtig und an einem anderen falsch beantwortet. Die Dienste schwanken bei den Grenzfällen, und auf welche Seite ein Fall fällt, ändert sich von Tag zu Tag.
Wenn Sie die Zahlen dieser Woche mit denen der letzten Woche vergleichen, ist ein Teil der Änderung das Modell, nicht Ihre Kunden. Wissen Sie, wie groß diese Schwankung ist, bevor Sie in eine kleine Verschiebung etwas hineinlesen.
Ich habe all das ordentlich in einer Anleitung aufgeschrieben. Das Werkzeug ist jetzt auf PyPI ( pip install steadybatch ), und der Code, die erfundenen Chats und alle Ergebnisse sind auf GitHub unter kotwal-itpro/steadybatch zu finden. Wenn Sie es zitieren möchten, hat es jetzt einen DOI: 10.5281/zenodo.23221956.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 9 • Originally published at kotwal-itpro.github.io
Originally published at kotwal-itpro.github.io.
Two days ago I wrote about giving two AI models the same instructions and watching them get things wrong in opposite ways. Since then I've added two more ways of running the job, made it 100 times bigger, and run it again on different days. Here's what changed, and what didn't.
Same job as before. I have fake customer support chats, and for each one the AI has to say which product it's about, what kind of problem it is, how the customer feels, and whether they asked to be contacted again. I wrote the chats, so I know every right answer.
The first four are "batch" services. You send everything at once and collect the answers later, for about half the usual price. The last one has no queue at all. It's just a computer doing the work.
All five got the product and the problem type right every time. Nearly all of them got the follow-up question right too, once I'd explained it properly (that was the big lesson last time).
The "how does the customer feel" question is where they split, into three groups:
Too negative. OpenAI (93% right) and my self-hosted model (85% right). A customer writes "My laptop stopped working after three days. Let me know what you need from me." That's a calm, helpful message about a problem. Both called the customer unhappy. My own model did this twice as often, and sometimes even turned happy customers into unhappy ones.
Too forgiving. Gemini (82% right). "This is really frustrating" came back as neutral.
Depends on one setting. Claude scored about the same both ways, 89% and 91%. With thinking on, its mistakes were split about evenly between too harsh and too forgiving. With thinking off, almost all of them were too harsh, like OpenAI's. Same model, same instructions, one switch, and the balance of its mistakes changed. The two settings gave different answers on about 1 chat in 9.
If you take one thing from this post: a score doesn't tell you which way a model is wrong. If something downstream counts unhappy customers, two models with similar scores can give you very different counts.
The self-hosted model surprised me. Once it was set up, it did all 1,000 chats in 29 seconds. The hosted services took 3 to 10 minutes, because you wait in their queue. It also cost about $0.004 per 1,000 chats in GPU time, about a tenth of the cheapest hosted option.
The catch is the setup. Installing the software, downloading the model and getting it ready took about 8 minutes on the rented GPU, which cost more than the actual work. And it was the least accurate of the five on feelings. It's also an older, smaller model than the hosted ones, so that isn't the last word on self-hosting.
Then I made the job 100 times bigger: 100,000 chats, on each of the three batch services.
Nothing went missing. All three sent back all 100,000 answers. None needed a retry, and the scores matched the smaller runs almost exactly. I'd half expected the trouble to start here. It didn't.
The waiting changed a lot. Gemini did it in 10 pieces of 10,000, about 4 minutes each, so 45 minutes in total. Claude took all 100,000 in one go and needed 2 hours and 44 minutes. OpenAI was the odd one. Its pieces took 14 minutes early in the afternoon, then slowed to almost an hour and a half by the evening. Same job, same size, six times slower depending on when I sent it.
The price per 1,000 chats didn't change with size: about 9 cents on OpenAI and Gemini, 5 cents on Claude.
The only real failure was on my side. Eight hours into the OpenAI run, my internet connection dropped while uploading the ninth piece, and the job stopped. This is exactly what I built the tool for. It keeps a record of what's done, so when I ran the same command again it picked up the last 20,000 chats and didn't resend, or pay for, the 80,000 that were already finished. It now also waits and retries when the connection drops, instead of giving up.
One thing went wrong before any work started. I sent Gemini all 100,000 chats as one job. It took five minutes to upload, then Gemini said:
You exceeded your current quota, please check your plan and billing details.
That sounds like a billing problem. It wasn't. When I sent the same work in pieces of 10,000, one after another, every piece went straight through. The real problem was that one job was too big for how much work my account can have waiting. The message just didn't say so.
That one changed my tool. It now recognizes a "queue full" answer, waits or sends smaller pieces, and doesn't count it as a failed attempt for the records involved.
This was the question I most wanted answered. I sent the exact same 1,000 chats, with the same instructions, to each service on three days in a row: Wednesday, Thursday and Friday.
Here's the strange part. The overall scores barely moved from day to day: Gemini's "how does the customer feel" score was 82%, 81% and 81%. But underneath, a different set of chats was right each day. Every single chat that changed was answered correctly on one day and wrongly on another. The services wobble on the borderline cases, and which side a case lands on changes from day to day.
If you compare this week's numbers with last week's, some of the change is the model, not your customers. Know how big that wobble is before you read anything into a small shift.
I've written these up properly in a guide. The tool is now on PyPI ( pip install steadybatch ), and the code, the fake chats and every result are on GitHub at kotwal-itpro/steadybatch. If you want to cite it, it now has a DOI: 10.5281/zenodo.23221956.