+150 XP

Denken vor dem Bauen: ein KI-Problem richtig framen

Ein Support-Team eines mittelgroßen Softwareunternehmens hat drei Monate damit verbracht, einen KI-Chatbot zu bauen. Sie haben ihn gelauncht, und innerhalb von zwei Wochen waren die Kunden wütend. Der Bot gab vage Antworten, drehte sich im Kreis und machte die Leute noch verärgerter als vorher. Als das Team schließlich in die Daten schaute, fand es etwas Peinliches: 80 % der eingehenden Fragen waren dieselben 15 Fragen, alle in den bestehenden Hilfe-Dokumenten beantwortet. Die Kunden konnten diese Dokumente nur nicht *finden*.

Sie brauchten keinen Chatbot. Sie brauchten eine bessere Suche.

So scheitern KI-Projekte am häufigsten. Nicht die Technologie ist der Schuldige, sondern das Framing. Jemand sagt „lass uns KI einbauen“, und das Team beginnt zu bauen, bevor irgendwer fragt: „welches Problem lösen wir eigentlich?“

Die Falle: Lösung zuerst denken

„Lass uns einen Chatbot einbauen“ ist eine Lösung. Es ist kein Problem.

Wenn Sie mit der Lösung anfangen, überspringen Sie den wichtigsten Schritt: zu verstehen, was kaputt ist und für wen. Am Ende bauen Sie etwas Beeindruckendes, das niemand gebraucht hat.

Lösung zuerst klingt so:

  • „Lass uns KI nutzen, um unsere Reports zusammenzufassen.“
  • „Wir sollten einen KI-Agenten für den Vertrieb bauen.“
  • „Können wir ein GPT auf unsere Website setzen?“

Problem zuerst klingt so:

  • „Unsere Manager verbringen 4 Stunden pro Woche mit Reports, die sie ohnehin nur überfliegen.“
  • „Sales Reps verlieren 30 Minuten pro Call mit der Suche nach Produktspezifikationen.“
  • „Neue Besucher erkennen nicht in unter 10 Sekunden, was unser Produkt macht.“

Achten Sie auf den Unterschied. Die zweite Liste beschreibt den Schmerz, wer ihn spürt und wie stark. Das gibt Ihnen etwas, das Sie messen und lösen können. Die erste Liste ist ein Werkzeug auf Jobsuche.

Eine einfache Framing-Methode

Bevor Sie irgendetwas bauen, schreiben Sie vier Dinge auf. Das dauert 20 Minuten und spart Monate.

1. Der Job

Welche konkrete Aufgabe versucht jemand zu erledigen? Werden Sie konkret.

Schlecht: „Den Kundensupport verbessern.“

Gut: „Einem Kunden helfen, die Antwort auf eine häufige Frage zu finden, ohne auf einen Menschen zu warten.“

2. Wer hat das Problem

Nennen Sie die konkrete Person. Ein frustrierter Kunde um 23 Uhr? Ein überarbeiteter Support-Agent? Ein Manager, der in Tickets versinkt? Jeder davon führt zu einer anderen Lösung.

3. Woran Sie erkennen, dass es funktioniert hat

Wie Sie ein messbares Erfolgskriterium definieren und Ihre Daten prüfen, behandeln wir ausführlich in der Lektion „Scoping: Daten und Erfolgskriterien“.

4. Das Einfachste, das funktionieren könnte

Das ist der entscheidende Punkt. Zwingen Sie sich zu der Frage: **was ist die *geringste* Menge Technologie, die das Problem löst**? Oft kommt in der Antwort überhaupt keine KI vor, oder nur ein winziger Teil davon.

Für das Support-Team war die einfachste Lösung eine intelligente Suchleiste über den bestehenden Dokumenten. Günstiger, schneller, und sie hat tatsächlich funktioniert.

Das Support-Beispiel durchgespielt

Machen wir das gescheiterte Chatbot-Projekt richtig.

Der Job: Ein Kunde will jetzt sofort die Antwort auf eine Routinefrage (Passwort zurücksetzen, Abrechnungsdatum, Export-Limits).

Wer: Kunden, oft außerhalb der Geschäftszeiten, die sich lieber selbst helfen als zu warten.

Erfolgsmetrik: 50 % der häufigen Fragen ohne Menschen gelöst, gemessen am Rückgang des Ticketvolumens.

Das Einfachste, das funktionieren könnte: Ein Suchfeld, das Fragen in normaler Sprache versteht und den richtigen Hilfeartikel zurückgibt. Keine Konversation. Eine Suche.

Hier passt eine Technik namens semantische Suche. Semantische Suche bedeutet, nach *Bedeutung* zu matchen, nicht nur nach Keywords. Ein Kunde tippt „ich kann mich nicht einloggen“ und findet den Artikel „Passwort zurücksetzen“, obwohl keines dieser Wörter übereinstimmt. Eine klassische Keyword-Suche würde ihn verpassen.

Eine einfache Version davon können Sie mit einem Embedding-Modell bauen (ein Werkzeug, das Text in eine Liste von Zahlen verwandelt, die seine Bedeutung repräsentieren, sodass ähnliche Bedeutungen nahe beieinander liegen). Hier ein minimales Beispiel mit der OpenAI-API in Python:

python
from openai import OpenAI
client = OpenAI()

# Your existing help articles
docs = [
    "Resetting your password: click Forgot Password on the login screen.",
    "Your billing date is the day you first subscribed.",
    "You can export up to 10,000 rows on the free plan.",
]

def embed(text):
    return client.embeddings.create(
        model="text-embedding-3-small",
        input=text
    ).data[0].embedding

# A customer's question
question = "I can't log in to my account"
q_vec = embed(question)
doc_vecs = [embed(d) for d in docs]

# Find the closest article by meaning
import numpy as np
scores = [np.dot(q_vec, d) for d in doc_vecs]
best = docs[int(np.argmax(scores))]
print("Best match:", best)

Das gibt den Passwort-Artikel zurück, obwohl der Kunde nie „Passwort“ gesagt hat. Damit ist das ganze Problem gelöst, ohne Chatbot, ohne Konversationsfluss und mit weit geringerem Risiko, dass die KI falsche Antworten erfindet.

Eine klare, kostenlose Einführung dazu, wie Embeddings und semantische Suche funktionieren, finden Sie im Embeddings-Guide von OpenAI.

What Are Word and Sentence Embeddings?

Watch on YouTube

Wann Sie den Chatbot wirklich brauchen

Problem zuerst zu denken heißt nicht „niemals KI bauen“. Es heißt, das Richtige zu bauen.

Wenn Ihre Analyse zeigt, dass die meisten Fragen *einzigartig* sind, ein Hin und Her erfordern („mein Export ist fehlgeschlagen, hier ist mein Fehler, was mache ich jetzt?“) und Schlussfolgerungen über mehrere Dokumente hinweg nötig sind, dann verdient ein konversationeller KI-Assistent seinen Platz.

Der Test ist einfach. Fragen Sie: braucht das Problem eine Konversation oder nur eine Antwort?

  • Nur eine Antwort: Suche, eine Zusammenfassung, ein einzelner KI-Call.
  • Eine Konversation: ein Chatbot oder Assistent.

Die meisten Teams gehen standardmäßig von „Konversation“ aus. Die meisten Probleme brauchen nur „Antwort“.

Eine kurze Entscheidungs-Checkliste

Schicken Sie jede KI-Idee vor dem Bauen durch diese Fragen:

  1. Kann ich das Problem beschreiben, ohne eine Technologie zu nennen? Wenn Sie es nur als „so eine KI-Sache“ beschreiben können, haben Sie es noch nicht verstanden.
  2. Wer spürt den Schmerz, und wie oft? Seltener Schmerz rechtfertigt selten ein Projekt.
  3. Was ist die dümmste Lösung, die funktionieren könnte? Probieren Sie die zuerst. Eine Tabelle, eine bessere Suchleiste, ein gespeichertes Prompt-Template.
  4. Wie sieht Erfolg als Zahl aus? Was Sie nicht messen können, können Sie nicht verbessern.
  5. Was passiert, wenn die KI sich irrt? Eine falsche FAQ-Antwort ist ärgerlich. Eine falsche medizinische oder juristische Antwort ist gefährlich. Höhere Stakes bedeuten einfachere, stärker kontrollierte Designs.

Wissenscheck

1. Was ist laut der Lektion der häufigste Grund, warum KI-Projekte scheitern?

2. Welches der folgenden Beispiele ist „Problem zuerst“ statt „Lösung zuerst“ gedacht?

3. Warum betont die Lektion die Frage „was ist das Einfachste, das funktionieren könnte?“ beim Framen eines KI-Problems?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die den Unterschied zwischen Lösung-zuerst und Problem-zuerst korrekt beschreiben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Die einfache Framing-Methode empfiehlt, vor dem Bauen welche der folgenden Punkte aufzuschreiben? Wählen Sie ALLE zutreffenden.

Wählen Sie alle richtigen Antworten aus.

Die Lösung auf das Problem zuschneiden

Sobald Sie das Problem kennen, passen Sie das Werkzeug daran an. Übertreiben verschwendet Geld und schafft zusätzliche Fehlerquellen. Zu klein dimensionieren lässt den Schmerz ungelöst. Hier eine grobe Leiter, von einfach bis komplex:

Level 0: Keine KI

Eine besser organisierte FAQ-Seite. Ein Suchfilter. Ein Template. Manchmal ist das echte Problem, dass Informationen versteckt sind, nicht dass sie fehlen. Prüfen Sie das immer zuerst.

Level 1: Ein einzelner KI-Call

Ein Prompt, eine Antwort. „Fasse dieses Dokument zusammen.“ „Klassifiziere diese E-Mail als dringend oder nicht.“ Kein Gedächtnis, keine Konversation. Günstig, vorhersehbar, leicht zu testen.

python
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "Classify the support email as 'billing', 'technical', or 'other'. Reply with one word."},
        {"role": "user", "content": "My card was charged twice this month."}
    ]
)
print(response.choices[0].message.content)  # billing

Dieses eine Snippet könnte jede eingehende E-Mail automatisch an das richtige Team weiterleiten. Allein das könnte den echten Engpass des Support-Teams lösen.

Level 2: KI plus Ihre eigenen Daten

Das ist das Beispiel der semantischen Suche von vorher, oft RAG genannt (Retrieval-Augmented Generation: die KI sucht relevante Informationen in Ihren Dokumenten und antwortet dann damit). Gut, wenn Antworten aus *Ihren* Inhalten kommen müssen und nicht aus dem Allgemeinwissen des Modells.

Level 3: Ein konversationeller Assistent

Mehrstufiger Chat, Gedächtnis für den Gesprächsverlauf, vielleicht die Fähigkeit, Aktionen auszuführen. Am mächtigsten und am teuersten zu bauen und zu pflegen. Reservieren Sie das für Probleme, die Dialog brauchen.

Die Lehre: fangen Sie auf dem niedrigsten Level an, das das Problem löst. Nach oben können Sie immer klettern. Nach unten klettern (einen überdimensionierten Chatbot wieder herausreißen) ist schmerzhaft und öffentlich.

Warum das Sie rettet

Erst framen fühlt sich langsam an. Tatsächlich ist es der schnellste Weg. Das Support-Team hat drei Monate verloren, um das Falsche zu bauen. Das richtige Framing hätte es zu einem Suchfeld geführt, das es in zwei Wochen hätte ausliefern können.

Jede Stunde, die Sie in die vier Framing-Fragen stecken (der Job, wer, die Metrik, die einfachste Lösung), spart Ihnen Wochen, in denen Sie etwas bauen, das niemand verlangt hat.

Key Takeaways

  • Beginnen Sie mit dem Problem, nie mit dem Werkzeug. Wenn Sie Ihre Idee nur als „lass uns KI einbauen“ beschreiben können, haben Sie sie noch nicht geframt. Nennen Sie den Schmerz, wer ihn spürt und wie oft.
  • Definieren Sie eine messbare Erfolgsmetrik, bevor Sie bauen. „‚Wie mache ich‘-Tickets um 40 % senken“ schlägt „Support verbessern“, weil Sie es tatsächlich überprüfen können.
  • Probieren Sie immer zuerst die dümmste Lösung. Bessere Suche, ein gespeicherter Prompt, eine Routing-Regel. Viele „KI-Projekte“ sind auf Level 0 oder Level 1 gelöst, ohne dass ein Chatbot in Sicht ist.
  • Passen Sie die Komplexität an das Problem an. Brauchen Sie eine Antwort? Nutzen Sie Suche oder einen einzelnen KI-Call. Brauchen Sie eine Konversation? Dann, und nur dann, bauen Sie einen Assistenten.
  • Fragen Sie, was passiert, wenn die KI sich irrt. Höhere Stakes verlangen einfachere, stärker kontrollierte Designs, keine spektakuläreren.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Job, Nutzer, Metrik und die einfachste Lösung definieren, bevor Sie bauen
  • Beginnen Sie mit der niedrigsten Fähigkeitsstufe, die das Problem löst
Vollständiges Action Playbook ansehen →

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.