Für die Frage, wie sich meine iOS-App auf Android bringen ließe, habe ich sechs KI-Modelle befragt — alle mit demselben Prompt. Bei der wichtigsten Komponente, der Spracherkennung, gingen sie auseinander. Die Mehrheit empfahl den bequemen Weg. Eine einzelne Gegenstimme stellte die entscheidende Frage, die zwei der Mehrheitsmodelle gar nicht erst aufwarfen — und behielt recht. Die Projektentscheidung folgte am Ende der Minderheit.
In einem früheren Teil dieser Serie ging es um eine Nacht, in der ein günstiges Modell einen Bug löste, den die teuren nicht anfassten. Diese Folge dreht sich um eine verwandte, aber andere Falle: Was, wenn sich mehrere KIs einig sind? Ist eine Mehrheitsmeinung unter Modellen ein gutes Zeichen?
Ich wollte wissen, ob und wie sich meine Transkriptions-App auch für Android bauen ließe. Statt ein einzelnes Modell zu fragen, gab ich denselben ausführlichen Rechercheprompt an mehrere KI-Modelle — und legte ihre Antworten nebeneinander. Am Ende waren es sechs Antworten: Minimax M3, GPT-OSS-120B, Gemma-4-26b, Qwen3.7Max und GLM-5.2, wobei Minimax M3 in zwei Rollen antwortete (einmal als schneller Praktiker, einmal als Qualitäts-Gutachter).
Bei fast allem einig
Das Ergebnis war zunächst beruhigend eintönig. Beim Oberflächen-Baukasten, bei der Datenbank, bei der Übersetzung, bei der Zusammenfassung — überall dasselbe Bild, sechs Modelle, ein Konsens. Wer nur zwei davon gefragt hätte, wäre mit einem sehr guten Gefühl aus dem Gespräch gegangen.
Dann kam die Spracherkennung. Das Herzstück der App — der Teil, der zuhört und mitschreibt. Und plötzlich zerfielen die sechs Modelle in drei Lager: drei setzten auf Googles bequeme Standard-Schnittstelle, zwei auf eine bekannte Open-Source-Lösung, eines auf einen dritten, weniger offensichtlichen Weg.
Der Bruch: eine übersehene Anforderung
Meine App hat ein Detail, das leicht zu übersehen ist: Beim Abspielen einer Aufnahme wird das gerade gesprochene Wort im Text hervorgehoben — es wandert mit. Damit das funktioniert, muss die Spracherkennung für jedes einzelne Wort einen Zeitstempel liefern: Wann genau wurde es gesagt?
Genau hier trennte sich die Spreu vom Weizen. Denn Googles bequeme Standard-Schnittstelle liefert diese Wort-Zeitstempel nicht zuverlässig. Wer sie empfiehlt, ohne das zu prüfen, empfiehlt etwas, das ein Kernfeature der App unmöglich macht.
| Modell | Empfahl für die Spracherkennung | Wort-Zeitstempel bedacht? |
|---|---|---|
| Minimax M3 | Google ML Kit | nicht bedacht |
| GPT-OSS-120B | Google Speech Services | nicht bedacht |
| Minimax M3 · Qualitäts-Check | ML Kit oder Sherpa-ONNX | nur am Rande |
| Gemma-4-26b | whisper.cpp | ja — ML Kit abgelehnt |
| Qwen3.7Max | whisper.cpp | ja — ML Kit abgelehnt |
| GLM-5.2 | Sherpa-ONNX (Streaming) | ja — als Ausschlusskriterium |
Die eine Stimme, die die richtige Frage stellte
Zwei der drei Modelle, die den bequemen Google-Weg empfahlen, verloren über die Wort-Zeitstempel kein Wort. Sie gaben die naheliegende Standardantwort — ohne sie gegen das zu halten, was meine App tatsächlich können muss.
Ein Modell, GLM-5.2, machte es anders. Es benannte die Zeitstempel-Lücke als Ausschlusskriterium — im Klartext:
Tödliches Problem für diese App: Die Standard-Schnittstelle liefert im Live-Betrieb keine oder nur unzuverlässige Wort-Zeitstempel. Das Feature „Wiedergabe mit Wort-Hervorhebung" lässt sich damit kaum umsetzen.
Statt der bequemen Lösung — und statt der naheliegenden Open-Source-Alternative, die für Echtzeit eigentlich nicht gebaut ist — empfahl GLM-5.2 einen dritten Weg, der Streaming, Wort-Zeitstempel und Hardware-Beschleunigung vereint. Es war die durchdachteste Antwort. Und sie kam von einer Minderheit von einem.
Warum ich der Minderheit gefolgt bin
Am Ende übernahm meine Architektur-Entscheidung genau diese Minderheitsposition — nicht, weil sie besonders klang, sondern weil sie als einzige zu dem passte, was die App wirklich leisten muss. Die Mehrheit hatte eine generische Standardantwort gegeben; die Minderheit hatte meine konkrete Anforderung geprüft.
Fairerweise: „Recht behalten" heißt hier nicht, dass GLM-5.2 eine bewiesene Wahrheit lieferte. Ob die Google-Schnittstelle im Jahr 2026 wirklich keine brauchbaren Zeitstempel bietet, muss ich am echten Gerät noch verifizieren. Aber GLM-5.2 stellte die richtige Frage — und das ist bei einer Architektur-Entscheidung oft mehr wert als eine schnelle Antwort.
Die Lehre schließt an den ersten Teil an. Dort galt: Das teuerste Modell ist nicht automatisch das beste. Hier gilt: Der Konsens mehrerer Modelle ist kein Qualitätssiegel. Mehrere KIs können denselben bequemen Reflex teilen. Der eigentliche Gewinn eines Modellvergleichs liegt nicht im Abstimmen — sondern darin, die abweichende Stimme ernst zu nehmen und jede Antwort an der eigenen, konkreten Aufgabe zu messen. Wie man diese Haltung in einen greifbaren Arbeitsablauf übersetzt, zeigt der nächste Teil zum Multi-Modell-Setup.
Transparenzhinweis: Dieser Artikel beschreibt einen dokumentierten Modellvergleich aus der eigenen Produktentwicklung. Es bestehen keine wirtschaftlichen Verbindungen zu den genannten Modellanbietern oder Google. Die zitierte Modellaussage stammt aus dem Recherche-Protokoll des Projekts. Die Behauptung zu den Wort-Zeitstempeln ist begründet, aber am Zielgerät noch zu verifizieren — der Artikel kennzeichnet sie entsprechend als Position, nicht als bewiesene Tatsache. Der Artikel wurde mit KI-Unterstützung (Claude) recherchiert und geschrieben; die redaktionelle Verantwortung liegt bei Marco Fuhrmann.