# Eine wichtige KI-Kompetenz beginnt vor dem Prompt Canonical page: https://blame76.com/thoughts/ai/2026-09-21-eine-wichtige-ki-kompetenz-beginnt-vor-dem-prompt/ Category: Thoughts Type: AI Published: 2026-09-21 Updated: 2026-09-21 Tags: ki, work Ich wollte eigentlich herausfinden, welches KI-Modell für welche Aufgabe das richtige ist. Großes Modell für schwierige Dinge. Kleines Modell für einfache Dinge. Vielleicht noch ein Router davor, der entscheidet, wer ran darf. Klingt vernünftig. Nach ziemlich viel Recherche glaube ich inzwischen, dass die interessantere Frage eine andere ist: **Brauche ich für diese Aufgabe überhaupt ein Modell?** Nehmen wir etwas maximal Unspektakuläres. Eine Rechnung kommt per Mail. Das System soll damit irgendetwas Sinnvolles machen. Ist es überhaupt eine Rechnung? Das kann eine Klassifikationsaufgabe sein. Ein Modell kann helfen. Ist der Betrag größer als 75 Euro? Dafür brauche ich keine KI. Ich brauche `>`. Welchem Kunden gehört die Rechnung? Vielleicht steht eine Kundennummer darin. Dann brauche ich eine Datenbank. Oder Search. Oder einen regulären Ausdruck. Darf die Rechnung automatisch bezahlt werden? Jetzt brauche ich vermutlich vor allem Geschäftsregeln, Berechtigungen und eine ziemlich klare Vorstellung davon, was passiert, wenn das System falschliegt. Ein einziges „KI-Problem“ hat sich innerhalb weniger Minuten in fünf verschiedene Probleme zerlegt. Und natürlich könnte ich trotzdem alles zusammen in einen Prompt schreiben. Moderne Sprachmodelle sind erstaunlich gut darin, solche unsauberen Pakete irgendwie zusammenzuhalten. Sie extrahieren. Sie klassifizieren. Sie rechnen ein bisschen. Sie interpretieren Regeln. Sie suchen Zusammenhänge. Sie formulieren eine Entscheidung. Und am Ende kommt möglicherweise sogar etwas Brauchbares heraus. Das ist beeindruckend. Es ist aber auch gefährlich bequem. **Ein gutes Modell kann erstaunlich lange verdecken, dass ich meine Aufgabe schlecht zerlegt habe.** Und mehr Kontext macht das nicht automatisch besser. Auch dafür gibt es inzwischen Hinweise: Relevante Informationen können in langen Kontexten untergehen, irrelevanter Kontext kann Entscheidungen beeinflussen und bereits gesetzte Informationen können zu Ankern für spätere Antworten werden. „Mehr wissen“ und „besser entscheiden“ sind nicht dasselbe. --- Wir reden gerade viel darüber, welches Modell intelligenter ist. Frontier oder Small Language Model. Cloud oder lokal. Reasoning oder kein Reasoning. Dabei existiert zwischen `if` und Frontier-Modell eine ziemlich große Welt. Klassifikatoren. Encoder. Search. BM25. Embeddings. Decision Tables. Zustandsmaschinen. Constraint Solver. Optimierungsverfahren. Und natürlich ganz gewöhnlicher Anwendungscode. Ein Fund aus meiner Recherche hat mir besonders gefallen: In der Ettin-Studie konnte bei einer kontrollierten Klassifikationsaufgabe ein 400-Millionen-Encoder einen Decoder mit einer Milliarde Parametern schlagen. Sogar ein 150-Millionen-Encoder lag vor einem größeren Decoder. Nicht weil er plötzlich intelligenter war. Sondern weil er besser zur Aufgabe passte. Der Hammer gewinnt beim Nagel nicht, weil er das mächtigste Werkzeug in der Werkstatt ist. Er gewinnt, weil da ein Nagel liegt. --- Also vielleicht erst einmal: Liegt die Antwort bereits in vorhandenen Daten? Dann brauche ich vielleicht Retrieval oder Search. Ist die Regel vollständig beschreibbar? Dann Code. Ist die Antwortmenge geschlossen und habe ich Beispiele? Dann kann ein Encoder oder klassischer Klassifikator interessanter sein als ein generatives Modell. Habe ich kaum Beispiele oder ändern sich die Kriterien ständig? Jetzt wird ein günstiges Generalistenmodell ziemlich attraktiv. Muss tatsächlich etwas Neues geschrieben, geplant oder über viel Kontext hinweg abgewogen werden? Dann sind generative Modelle genau in ihrem Element. Und noch bevor irgendeines davon eine folgenreiche Entscheidung trifft, kommt eine andere Frage: **Was passiert, wenn es falschliegt?** Denn hohe Fehlerkosten bedeuten nicht automatisch: Nimm das größere Modell. Vielleicht bedeuten sie: Validiere deterministisch. Lass zwei Systeme unabhängig prüfen. Baue ein hartes Gate. Oder lass an dieser Stelle überhaupt nichts automatisch passieren. Und auch „Dann schaut eben noch einmal ein Mensch drauf“ ist kein Zauberspruch. Menschen können KI-Vorschläge genauso routiniert durchwinken wie jedes andere Formular. Risiko gehört deshalb nicht hinter die Modellwahl. Es gehört davor. --- Jetzt kommt allerdings das Gegenargument, das man ernst nehmen muss. Warum soll ich fünf technische Bausteine betreiben, wenn ein günstiges Generalistenmodell die ganze Aufgabe zuverlässig genug für ein paar Cent erledigt? Vielleicht sollte ich das gar nicht. Für viele Projekte kann die vernünftigste Architektur schlicht sein: **Code + Datenbank/Search + ein günstiges Generalisten-LLM + harte Risk Gates.** Kein intelligenter Router. Keine dreistufige Modellkaskade. Kein kleiner Zoo aus Spezialmodellen, den anschließend jemand füttern und überwachen muss. Und wenn das zuverlässig, schnell und günstig genug funktioniert, gibt es keinen Preis dafür, es komplizierter zu machen. Dann ist das nicht die Übergangslösung. Dann ist das die Architektur. Erst wenn Messdaten zeigen, dass Kosten, Latenz, Datenschutz oder Qualität tatsächlich zum Problem werden, lohnt sich die nächste Stufe. KISS und YAGNI haben die Einführung generativer KI offenbar überlebt. Das beruhigt mich ein bisschen. --- Für mich ist deshalb die wichtigste KI-Kompetenz 2026 nicht, das stärkste Modell zu kennen. **Sie ist, früh genug zu erkennen, wann man überhaupt keines braucht.** Nicht als Anti-KI-Reflex. Im Gegenteil. Je besser die Modelle werden, desto wichtiger wird diese Fähigkeit. Weil ein schlechtes Modell eine schlechte Architektur schnell sichtbar macht. Ein sehr gutes Modell kann sie erstaunlich lange verstecken. Ich weiß nicht, ob daraus eine allgemeingültige Regel wird. Dafür fehlen mir noch erstaunlich viele saubere Vergleiche derselben Aufgabe über Regeln, klassische Modelle, kleine LLMs und Frontier-Modelle hinweg. Als Arbeitsregel reicht es mir aber: **Vor dem Prompt kommt die Problemzerlegung.** Was versuche ich hier eigentlich zu lösen? Regel? Suche? Klassifikation? Berechnung? Risikoentscheidung? Oder tatsächlich etwas, für das ich ein Sprachmodell brauche? Das klingt nicht besonders futuristisch. Eigentlich klingt es nach ziemlich altem Handwerk. **Mit KI entdecken wir gerade wieder, warum Software Engineering existiert.**