Manus 2.0 ist online gegangen. Der Produktmanager für KI-Anwendungen befasst sich letztendlich mit der Routing-Architektur, anstatt mit „monolithischen KI-Anwendungen“.
Kürzlich wurde Manus 2.0 online gestellt. Meiner Meinung nach ist die größte Erkenntnis für Produktmanager von KI-Anwendungen, dass die Konzentration auf die Router-Produktarchitektur der lohnendste Weg für Gründungen im Bereich KI-Anwendungen ist.
Leider sehe ich bei Gründern im Inland, dass sie ausschließlich einzelne KI-Anwendungen mit nur einem Zugangsweg entwickeln, also ein bestimmtes KI-Modell als Basis nutzen, um ihre eigenen KI-Produkte aufzubauen.
Diese Produktarchitektur hat ein Problem: Was passiert, wenn sich ein KI-Modell nicht gut entwickelt und schlechter ist als das der Konkurrenz? Und die Investoren werden unweigerlich folgende Frage stellen:
Wird die Obergrenze von KI-Anwendungen von Modellanbietern übertroffen? Was ist Ihre Wettbewerbsfähigkeit?
Daher bestimmt eine Produktarchitektur den Überbau des Produkts, das Geschäftsmodell und die technischen Barrieren. Die Produktarchitektur von MANUS baut dagegen die Fähigkeiten der KI-Basismodelle verschiedener Unternehmen ein, um ein Produkt zu erstellen – diese Produktarchitektur ist unschlagbar.
Ähnlich dem Fass-Effekt hat jeder Modellanbieter seine eigenen Stärken und Schwächen. Aber bei mir sind Sie alle Teile meines Puzzles, die ich zu dem endgültigen Produkterlebnis zusammensetzen kann, das ich den Nutzern anbiete, sodass ich mir keine Sorgen um die einzelnen Schwächen irgendeines Modells machen muss.
Zum Beispiel das kürzlich populäre 5.5 OPS: Die neueste Version von Claude kann viele AE-Videoschneider und Videobearbeiter ersetzen. ChatGPT Astra zeichnet sich dagegen durch 3D-Konstruktion und Codierfähigkeiten aus. Ein Produkt, das all diese Funktionen vollständig integriert, stellt die Obergrenze von KI-Anwendungen dar.
Eines ist stärker bei der AE-Bearbeitung, das andere bei der Bedienung von Blender über Astra. Wenn beide kombiniert werden, entsteht zumindest ein unschlagbares KI-Anwendungsprodukt.
Einfache Shell-Anwendungen, die nur als Hülle für KI-Funktionen dienen, haben keine Wettbewerbsfähigkeit.
Im Folgenden werden zwei verschiedene Formen von KI-Produktarchitekturen vorgestellt
Die Architektur einzelner Anwendungen verbindet die Softwareentwicklung direkt mit der Bereitstellung allgemeiner Modelle, sodass die zwischengeschalteten Fähigkeiten zur Verteilung und Integration fehlen.
Für die Router-Architektur müssen Produktmanager die Stärken, Schwächen und Fähigkeitsunterschiede verschiedener KI-Modelle vollständig verstehen. Tatsächlich weisen die KI-Modelle verschiedener Anbieter bereits deutliche Unterschiede auf: Zum Beispiel konzentriert sich GROK stärker auf die physische Welt und bereitet sich auf Roboter und Tesla vor, ChatGPT ist stärker bei Text und Codierung, und Claude zeichnet sich durch Codierung, Bearbeitung und Erstellung aus.
Das Verständnis von Benchmarks ist eine grundlegende Fähigkeit für Produktmanager von KI-Shell-Anwendungen, die eine Finanzierung anstreben
Verschiedene Benchmarks repräsentieren unterschiedliche Branchenführerschaft, zum Beispiel in der Erstellung, bei Liedern oder in der Mathematik. Diese verschiedenen Benchmarks haben ihre eigenen Bewertungspunkte.
Produktmanager von KI-Shell-Anwendungen, die die Router-Architektur nutzen, kennen für ihre jeweiligen Nutzungsszenarien zuerst die Schwächen und Stärken der einzelnen Modelle bei den Bewertungen.
Wenn Ihr Produkt allgemein ausgerichtet ist, müssen Sie verschiedene Benchmarks auswählen. Produktmanager sollten nicht nur KI-Produktdesign betreiben, sondern sich auch ernsthaft mit akademischer Forschung und Branchenbewertungsmethoden befassen. Das heißt, KI-Produktmanager müssen unbedingt wissenschaftliche Fähigkeiten und sogar Python-Kenntnisse kombinieren, um ihre Produktarbeit zu erledigen.
Viele KI-Produktmanager können keine Produkte mit Router-Architektur entwickeln und sind nicht bereit, Englisch und wissenschaftliche Arbeit zu lernen
Warum bleiben viele KI-Produktmanager immer noch auf Ebene von Workbuddy, anstatt die von mir erwähnte Router-Architektur umzusetzen? Der Hauptgrund ist, dass dies ein tiefes Verständnis der Fähigkeiten und Bewertungen der einzelnen Modelle sowie der Unterschiede bei den internen Basismodellen und Datensätzen erfordert. Dafür braucht das Team mindestens ein Mitglied mit wissenschaftlichem Hintergrund, und 99% der heutigen KI-Produkte verfügen nicht über diese Fähigkeit.
Anders ausgedrückt: Produktmanager mit Hintergrund in Softwareentwicklung können sich nicht tief in ein Forschungsteam integrieren, da ihre gesamte Denkweise nicht auf die Untersuchung von Nutzeranforderungen, sondern auf das Lesen von Forschungsartikeln ausgerichtet ist.
Daher müssen selbst bei KI-Anwendungen, die nur als Shell dienen, KI-Produktmanager wissenschaftliche Literatur lesen.
Das war der heutige Beitrag.
Dieser Artikel stammt aus dem WeChat-Offiziellen Konto „Kevin's Momente, die die Welt verändern“ (ID: Kevingbsjddd), Autor: Kevin's Stories, veröffentlicht mit Genehmigung von 36Kr.