Ein Minimum Viable Product (MVP) ist eine Version eines Produkts mit genau den Funktionen, die nötig sind, damit frühe Kunden es nutzen können und anschließend Feedback für die weitere Produktentwicklung geben können.
\nHeute möchte ich mich darauf konzentrieren, wie das bei der Auslieferung von KI-Anwendungen aussieht. Dazu müssen wir nur vier Dinge verstehen.
\nDas Pareto-Prinzip, auch bekannt als die 80/20-Regel, gilt nach wie vor, aber auf eine andere Weise, als du vielleicht denkst.
\nEine Analogie, die ich oft verwende, um dieses Konzept zu veranschaulichen, ist die folgende: Du brauchst etwas, um von Punkt A nach Punkt B zu gelangen. Vielleicht ist die Vision, ein Auto zu haben. Der MVP ist jedoch kein Chassis ohne Räder oder Motor. Stattdessen könnte er wie ein Skateboard aussehen. Du lieferst aus und stellst fest, dass das Produkt Bremsen oder eine Lenkung braucht. Also lieferst du einen Roller aus. Danach merkst du, dass der Roller mehr Hebelkraft braucht, also fügst du größere Räder hinzu und endest mit einem Fahrrad. Begrenzt durch die Kraft, die du als Mensch aufbringen kannst, fängst du an, über Motoren nachzudenken und kannst zu Mopeds, E-Bikes und Motorrädern übergehen. Dann, eines Tages, lieferst du das Auto aus.
\nWenn wir davon sprechen, dass etwas zu 80% fertig oder zu 80% bereit ist, ist das normalerweise im maschinellen Lernen gemeint. In diesem Kontext ist jede Komponente deterministisch, was bedeutet, dass 80% so viel heißt wie 8 von 10 Features fertiggestellt sind. Sobald die verbleibenden 2 Features bereit sind, können wir das Produkt ausliefern. Wenn wir jedoch der 80/20-Regel folgen wollen, könnten wir das Produkt vielleicht mit 80% der Features ausliefern und die restlichen 20% später hinzufügen – wie ein Auto ohne Radio oder Klimaanlage. Die Bedeutung von 80% kann jedoch erheblich variieren, und diese Definition lässt sich möglicherweise nicht auf eine KI-gestützte Anwendung übertragen.
\n![\"Anscombe's](\"/assets/images/anscombes_quartet.png\")
\nDas obige Bild ist ein Beispiel für Anscombe's Quartet. Es handelt sich um vier Datensätze, die nahezu identische einfache deskriptive Statistiken aufweisen, aber sehr unterschiedliche Verteilungen und Erscheinungsbilder haben. Dies ist eine klassische Erklärung dafür, warum Summary Statistics irreführend sein können.
\nBetrachten wir das folgende Beispiel:
\n| Query_id | \nscore | \n
|---|---|
| 1 | \n0.9 | \n
| 2 | \n0.8 | \n
| 3 | \n0.9 | \n
| 4 | \n0.9 | \n
| 5 | \n0.0 | \n
| 6 | \n0.0 | \n
Der durchschnittliche Score beträgt 0.58. Wenn wir die Queries jedoch innerhalb von Segmenten analysieren, könnten wir feststellen, dass wir die Mehrheit der Queries außergewöhnlich gut bedienen!
\n\n\nEhrlich sein über eigene Schwächen
\nEhrlich zu sein über das, worin du schlecht bist, ist ein hervorragender Weg, um das Vertrauen deiner Nutzer aufzubauen. Wenn du genau identifizieren kannst, wann etwas schlecht abschneiden wird, und es selbstbewusst ablehnst, dann bist du möglicherweise bereit, ein großartiges Produkt auszuliefern und deine Nutzer dabei über die Grenzen deiner Anwendung aufzuklären.
\n
Es ist sehr wichtig, die Grenzen deines Systems zu verstehen und die Eigenschaften deines Systems über Summary Statistics hinaus selbstbewusst einschätzen zu können. Das liegt daran, dass nicht alle System gleich geschaffen sind. Das Verhalten eines probabilistischen Systems könnte sich deutlich vom vorherigen Beispiel unterscheiden. Betrachten wir den folgenden Datensatz:
\n| Query_id | \nScore | \n
|---|---|
| 1 | \n.59 | \n
| 2 | \n.58 | \n
| 3 | \n.59 | \n
| 4 | \n.57 | \n
Ein solches System hat ebenfalls den gleichen Durchschnitts-Score von 0.58, aber es ist nicht so einfach, eine beliebige Teilmenge von Requests abzulehnen...
\nBetrachten wir eine RAG-Anwendung, bei der ein großer Teil der Queries Timeline-Queries betrifft. Wenn unsere Suchmaschinen diese Zeitbeschränkung nicht unterstützen, werden wir wahrscheinlich nicht gut abschneiden.
\n| Query_id | \nScore | \nQuery Type | \n
|---|---|---|
| 1 | \n0.9 | \ntext search | \n
| 2 | \n0.8 | \ntext search | \n
| 3 | \n0.9 | \nnews search | \n
| 4 | \n0.9 | \nnews search | \n
| 5 | \n0.0 | \ntimeline | \n
| 6 | \n0.0 | \ntimeline | \n
Wenn wir unter Zeitdruck stehen, um auszuliefern, könnten wir einfach ein Klassifikationsmodell bauen, das erkennt, ob es sich bei diesen Fragen um Timeline-Queries handelt oder nicht, und eine Warnung ausgeben. Anstatt ständig zu versuchen, den Algorithmus zu verbessern, können wir den Nutzer aufklären und dies tun, indem wir die Art und Weise ändern, wie wir das Produkt gestalten.
\n\n\nSegmente erkennen
\nDiese Segmente können auf verschiedene Weisen erkannt werden. Wir könnten einen Klassifikator erstellen oder ein Language Model einsetzen, um sie zu kategorisieren. Zusätzlich können wir Clustering-Algorithmen mit den Embeddings nutzen, um gemeinsame Gruppen zu identifizieren und potenziell die durchschnittlichen Scores innerhalb jeder Gruppe zu analysieren. Das einzige Ziel ist es, Segmente zu identifizieren, die unser Verständnis der Aktivitäten innerhalb bestimmter Untergruppen verbessern können.
\n
Eines der schlimmsten Dinge, die du tun kannst, ist, Monate damit zu verbringen, ein Feature zu entwickeln, das deine Produktivität nur minimal steigert, während du ein wichtigeres Segment deiner Nutzerbasis ignorierst.
\nIndem wir unsere Anwendung neu gestalten und ihre Grenzen erkennen, können wir die Leistung unter bestimmten Bedingungen potenziell verbessern, indem wir die Arten von Aufgaben identifizieren, die wir ablehnen können. Wenn wir diese Segmentdaten in eine Art In-System Observability einfließen lassen können, können wir sicher überwachen, welcher Anteil der Fragen abgelehnt wird, und unsere Arbeit priorisieren, um die Abdeckung zu maximieren.
\nEine der gefährlichsten Dinge, die ich bei der Arbeit mit Startups beobachtet habe, ist, dass wir oft denken, die KI funktioniert überhaupt... Infolgedessen wollen wir in der Lage sein, eine große, allgemeine Anwendung zu bedienen, ohne uns viele Gedanken darüber zu machen, was wir genau erreichen wollen.
\nMeiner Meinung nach sollten die meisten dieser Unternehmen versuchen, sich auf ein oder zwei bedeutende Bereiche zu konzentrieren und eine gute Nische zu identifizieren, die sie ansprechen wollen. Wenn deine App in ein oder zwei Aufgaben gut ist, wirst du mit Sicherheit hundert oder zweihundert Nutzer finden, die deine Anwendung testen und schnell Feedback geben. Wenn deine Anwendung jedoch in nichts gut ist, wird es schwer sein, sich einzuprägen und etwas zu bieten, das wiederholt genutzt wird. Du könntest vielleicht etwas Viralität erzeugen, aber sehr schnell wirst du das Vertrauen deiner Nutzer verlieren und dich in einer Position wiederfinden, in der du versuchst, Churn zu reduzieren.
\nWenn wir zu Beginn die Möglichkeit haben, GPT-4 für Vorhersagen zu nutzen, ist die Zeit bis zum Feedback sehr wichtig. Wenn wir schnell Feedback bekommen können, können wir schnell iterieren. Wenn wir schnell iterieren können, können wir ein besseres Produkt bauen.
\nDer MVP für eine KI-Anwendung ist nicht so einfach wie das Ausliefern eines Produkts mit 80% der Features. Stattdessen erfordert er ein tiefes Verständnis für die Segmente deiner Nutzer, die du gut bedienen kannst, sowie die Fähigkeit, deine Nutzer über die Segmente aufzuklären, die du nicht gut bedienst. Indem du die Grenzen deines Systems verstehst und dich auf eine Nische konzentrierst, kannst du ein Produkt aufbauen, das sich einprägt und etwas bietet, das wiederholt genutzt wird. Das ermöglicht es dir, schnell Feedback zu erhalten und schnell zu iterieren, was letztendlich zu einem besseren Produkt führt, indem du deine Stärken identifizierst.
", "source_hash": "sha256:145f757651a7540ac4d35b4afde9a79f337936029ace5840b1ff7b5d56b0fce6", "model": "moonshotai/kimi-k2.6", "generated_at": "2026-08-07T05:34:05.470981+00:00" }