Ein Minimum Viable Product (MVP) ist eine Version eines Produkts mit gerade genug Funktionen, um von frühen Kunden nutzbar zu sein, die dann Feedback für die zukünftige Produktentwicklung geben können.
\n\nHeute möchte ich mich darauf konzentrieren, wie das beim Ausliefern von KI-Anwendungen aussieht. Dafür müssen wir nur 4 Dinge verstehen:
\nDas Pareto-Prinzip, auch bekannt als 80/20-Regel, gilt immer noch, aber auf eine andere Weise als Sie vielleicht denken.
\n\nEine Analogie, die ich oft verwende, um dieses Konzept zu verdeutlichen, ist folgende: Sie brauchen etwas, um von Punkt A nach Punkt B zu gelangen. Vielleicht ist die Vision, ein Auto zu haben. Das MVP ist jedoch kein Chassis ohne Räder oder Motor. Stattdessen könnte es wie ein Skateboard aussehen. Sie liefern aus und stellen fest, dass das Produkt Bremsen oder Lenkung braucht. Also liefern Sie einen Scooter aus. Danach stellen Sie fest, dass der Scooter mehr Hebelwirkung braucht, also fügen Sie größere Räder hinzu und erhalten ein Fahrrad. Begrenzt durch die Kraft, die Sie als Mensch aufbringen können, denken Sie über Motoren nach und können sich in Mopeds, E-Bikes und Motorräder verzweigen. Und eines Tages liefern Sie das Auto aus.
\n\nWenn man davon spricht, dass etwas zu 80% fertig oder zu 80% bereit ist, ist das normalerweise im Machine-Learning-Sinne gemeint. In diesem Kontext ist jede Komponente deterministisch, was bedeutet, dass 80% sich in 8 von 10 fertigen Features übersetzen. Sobald die verbleibenden 2 Features fertig sind, können wir das Produkt ausliefern. Wenn wir jedoch der 80/20-Regel folgen wollen, könnten wir das Produkt möglicherweise mit 80% der Features ausliefern und dann die verbleibenden 20% später hinzufügen, wie ein Auto ohne Radio oder Klimaanlage. Die Bedeutung von 80% kann jedoch erheblich variieren, und diese Definition gilt möglicherweise nicht für eine KI-gestützte Anwendung.
\n\n![\"Anscombe's](\"/assets/images/anscombes_quartet.png\")
\nDas obige Bild ist ein Beispiel für Anscombes Quartett. Es ist eine Reihe von vier Datensätzen, die nahezu identische einfache deskriptive Statistiken aufweisen, aber sehr unterschiedliche Verteilungen und Erscheinungsbilder haben. Dies ist eine klassische Erklärung dafür, warum zusammenfassende Statistiken irreführend sein können.
\n\nBetrachten Sie das folgende Beispiel:
\n\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 jedoch die Anfragen innerhalb von Segmenten analysieren, könnten wir feststellen, dass wir die Mehrheit der Anfragen außergewöhnlich gut bedienen!
\n\n\n\n\nZugeben, worin man schlecht ist
\nEhrlich zu sein, worin man schlecht ist, ist eine großartige Möglichkeit, Vertrauen bei den Nutzern aufzubauen. Wenn Sie genau erkennen können, wann etwas schlecht funktionieren wird, und es selbstbewusst ablehnen können, dann sind Sie möglicherweise bereit, ein großartiges Produkt auszuliefern und gleichzeitig Ihre Nutzer über die Einschränkungen Ihrer Anwendung aufzuklären.
\n
Es ist sehr wichtig, die Grenzen Ihres Systems zu verstehen und in der Lage zu sein, die Eigenschaften Ihres Systems über zusammenfassende Statistiken hinaus sicher zu verstehen. Dies liegt daran, dass nicht alle Systeme gleich sind. Das Verhalten eines probabilistischen Systems könnte sich sehr vom vorherigen Beispiel unterscheiden. Betrachten Sie den folgenden Datensatz:
\n\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 einen durchschnittlichen Score von 0,58, aber es ist nicht so einfach, eine Teilmenge von Anfragen abzulehnen...
\n\nBetrachten Sie eine RAG-Anwendung, bei der ein großer Teil der Anfragen Zeitleisten-Anfragen betrifft. Wenn unsere Suchmaschinen diese Zeitbeschränkung nicht unterstützen, werden wir wahrscheinlich nicht gut abschneiden können.
\n\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, könnten wir einfach ein Klassifikationsmodell erstellen, das erkennt, ob diese Fragen Zeitleisten-Fragen sind oder nicht, und eine Warnung ausgeben. Anstatt ständig zu versuchen, den Algorithmus zu verbessern, können wir den Nutzer aufklären, indem wir die Art und Weise ändern, wie wir das Produkt gestalten.
\n\n\n\n\nSegmente erkennen
\nDas Erkennen dieser Segmente könnte auf verschiedene Weise erreicht werden. Wir könnten einen Klassifikator konstruieren oder ein Sprachmodell verwenden, um sie zu kategorisieren. Zusätzlich können wir Clustering-Algorithmen mit den Embeddings nutzen, um gemeinsame Gruppen zu identifizieren und möglicherweise die mittleren 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 Sie tun können, ist, Monate damit zu verbringen, eine Funktion zu entwickeln, die Ihre Produktivität nur geringfügig erhöht, während Sie ein wichtigeres Segment Ihrer Nutzerbasis ignorieren.
\n\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 einbringen können, können wir sicher überwachen, welcher Anteil der Fragen abgelehnt wird, und unsere Arbeit priorisieren, um die Abdeckung zu maximieren.
\n\nEine der gefährlichen Dinge, die mir bei der Arbeit mit Startups aufgefallen sind, ist, dass wir oft denken, dass die KI überhaupt funktioniert... Infolgedessen wollen wir in der Lage sein, eine große allgemeine Anwendung zu bedienen, ohne viel darüber nachzudenken, was genau wir erreichen wollen.
\n\nMeiner Meinung nach sollten sich die meisten dieser Unternehmen darauf konzentrieren, ein oder zwei bedeutende Bereiche zu fokussieren und eine gute Nische zu identifizieren, die sie ansprechen können. Wenn Ihre App in einer oder zwei Aufgaben gut ist, gibt es keine Möglichkeit, dass Sie nicht hundert oder zweihundert Nutzer finden könnten, um Ihre Anwendung zu testen und schnell Feedback zu erhalten. Wenn Ihre Anwendung hingegen in nichts gut ist, wird es schwer sein, in Erinnerung zu bleiben und etwas zu bieten, das wiederholt genutzt wird. Sie könnten etwas Viralität bekommen, aber sehr schnell werden Sie das Vertrauen Ihrer Nutzer verlieren und sich in einer Position wiederfinden, in der Sie versuchen, die Abwanderung zu reduzieren.
\n\nWenn wir von vornherein die Fähigkeit haben, GPT-4 für Vorhersagen zu nutzen, ist die Zeit bis zum Feedback sehr wichtig. Wenn wir schnell Feedback erhalten können, können wir schnell iterieren. Wenn wir schnell iterieren können, können wir ein besseres Produkt entwickeln.
\n\nDas MVP für eine KI-Anwendung ist nicht so einfach wie das Ausliefern eines Produkts mit 80% der Features. Stattdessen erfordert es ein tiefes Verständnis der Segmente Ihrer Nutzer, die Sie gut bedienen können, und die Fähigkeit, Ihre Nutzer über die Segmente aufzuklären, die Sie nicht gut bedienen. Indem Sie die Grenzen Ihres Systems verstehen und sich auf eine Nische konzentrieren, können Sie ein Produkt entwickeln, das in Erinnerung bleibt und etwas bietet, das wiederholt genutzt wird. Dies ermöglicht es Ihnen, schnell Feedback zu erhalten und schnell zu iterieren, was letztendlich zu einem besseren Produkt führt, indem Sie Ihre Kraftakte identifizieren.
", "source_hash": "sha256:628188f6afb27695d03e01274d59eb0b52134258149bbac07bab13c678413b93", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-15T20:07:27.839698+00:00" }