Die Analyse von AI-Konkurrenten ist fehlgeschlagen: Ein Versuch, der von Bugs und einer expandierenden Anforderungslage untergraben wurde.

Die Entdeckungsreise eines AI-Konkurrentenanalyse-Tools ist mit doppelten Herausforderungen aus Technik und Kosten verbunden. Von der multimodalen Erkennung bis zur RAG-verstärkten Generierung haben die Entwickler über 200 Yuan investiert, doch am Ende sind sie in die Fallen der komplexen Produktisierung geraten. Dieser Artikel wird diese fehlgeschlagene Experimente tiefgehend nachvollziehen, den fatalen Wendepunkt von einem einfachen Technologiestapel zu einem überladenen Geschäftssystem aufdecken und blutige Lehren für die Umsetzung von AI-Produkten liefern.

Ich habe über 200 Yuan für die API-Aufrufe von Claude ausgegeben, aber am Ende war es dennoch ein Misserfolg. Ich war sehr betrübt und habe daher diesen Artikel geschrieben. Es muss etwas gewonnen werden, ich kann nicht einfach nur mein Geld ausgeben und am Ende nichts zu haben.

Die ursprüngliche Vorstellung und der technische Ablauf

Anfangs war meine Vorstellung von der AI-Konkurrentenanalyse sehr einfach: Man gibt einen Ziel-Link ein, und das System analysiert automatisch den Seiteninhalt und gibt einen strukturierten Konkurrentenanalysebericht gemäß einem festgelegten Prompt aus.

Um diesen geschlossenen Kreislauf zu realisieren, habe ich einen mehrstufigen Verarbeitungsablauf entworfen:

1) Informationserfassung (Crawler-Skript): Dies wird in zwei separate Skripte aufgeteilt. Ein Skript ist speziell für die globale Screenshots der Webseite zuständig, das andere extrahiert den HTML-Quellcode und den gesamten Text aus der Webseite.

2) Multimodale Erkennung (VLM-Agent): Ein visuelles Modell wird eingeführt, um die im ersten Schritt erfassten Webseiten-Screenshots zu erkennen und die visuellen Informationen in den Bildern in eine Textdarstellung umzuwandeln.

3) Datenbereinigung (Clean-Agent): Dieser Agent ist für die Verarbeitung von ungeordnetem Text zuständig. Er entfernt alle unnötigen Tags und überflüssigen Code aus dem HTML-Quellcode und behält nur saubere reinen Text-Daten.

4) Berichtserstellung (Generator-Agent): Die komprimierten Screenshots und der bereinigte reine Text werden einem Agenten zur Erstellung des Analyseberichts übergeben, der sie zusammenfasst und ausgibt.

5) Prüfung und Sicherung (Review-Agent): Dies ist der Kernmechanismus zur Lösung des Problems der "AI-Halluzination" und des Vertrauens. Nachdem der Bericht geschrieben wurde, vergleicht der Review-Agent die generierten Texte mit den Originalbildern und -inhalten, um zu überprüfen, ob der Inhalt auf Fakten basiert. Wenn er nicht akzeptabel ist, wird er zurückgewiesen und neu geschrieben. Die maximale Anzahl der Wiederholungen ist auf 3 festgelegt. Wenn nach 3 Versuchen immer noch nicht die Anforderungen erfüllt sind, wird im Endbericht deutlich markiert, dass die "Zuverlässigkeit niedrig" ist.

Um die Kosten zu kontrollieren (Token zu sparen) und die Effektivität zu verbessern, habe ich im Ablauf klare technische Strategien angewendet:

1) Bildkompression: Das direkte Übergeben von Screenshots an das Modell verbraucht sehr viele Token. Daher müssen die Bilder zunächst im Vordergrund komprimiert werden.

2) Modell-Routing (Verteilung großer Modelle): Für verschiedene Aufgaben werden verschiedene leistungsstarke Modelle aufgerufen. Bei der multimodalen Erkennung, der Berichtserstellung und der endgültigen Prüfung werden leistungsstarke und teure Modelle verwendet, um die Qualität zu gewährleisten. Mechanische Aufgaben wie die Datenbereinigung werden dagegen an billigere "Kleinstmodelle" verteilt.

3) Steuerung der strukturierten Ausgabe (Prompt-Engineering): Um die Stabilität der Datenübertragung zwischen verschiedenen Agenten zu gewährleisten, habe ich aufgegeben, dass das Modell lange natürliche Sprachtexte ausgibt. Stattdessen habe ich durch Few-Shot (Wenige-Beispiel-Prompts) und klare Prompts die "Berichtserstellungs-Agenten" gezwungen, in einem strengen JSON-Format (z. B. mit Feldern wie Kernfunktionen, Preise, Zielkunden) auszugeben. Dadurch kann der nachgelagerte "Review-Agent" die Felder präzise überprüfen, anstatt in langen Texten zu verirren.

Der Wendepunkt hin zu mehr Komplexität: Einführung von RAG

Später dachte ich, dass es, wenn es ein täglich verwendetes Tool sein soll, zu ineffizient ist, jedes Mal lange Analysedokumente zu lesen. Die intuitivste Interaktion sollte "Fragen und Antworten" sein - nachdem das System die Analyse durchgeführt hat, kann ich direkt nach den Details fragen, die mich interessieren.

Daher habe ich beschlossen, RAG (Retrieval Augmented Generation) in das Produkt einzuführen:

Vektorisierte Speicherung: Nachdem der Konkurrentenanalysebericht erstellt wurde, wird er direkt in Vektoren (Embedding) umgewandelt und in einer Vektordatenbank gespeichert. Die Schnittstrategie ist hier auf 800 Wörter pro Block festgelegt, wobei 10% Überlappung beibehalten wird, um die semantische Verknüpfung des Kontexts zu gewährleisten.

Suche und Q&A: Wenn eine Frage im Vordergrund gestellt wird, sendet das System die aktuelle Frage und die historische Konversation zusammen als Kontext an die Vektordatenbank. Die Fragmente werden nach Relevanz priorisiert und zurückgerufen. Schließlich wird die Antwort von einem großen Modell zusammengefasst und gegeben. Die Entwicklungskosten für diesen Schritt allein sind eigentlich nicht sehr hoch.

Der Beginn des Albtraums: Versacken in die Dschungel von Scheinanforderungen und Bugs

Aber gerade durch die Einführung des Q&A-Mechanismus und den Drang zur "Produktisierung" kamen alle möglichen Schwierigkeiten auf uns zu, und die Komplexität der Szenarien stieg linear an.

1) Logiklücken und Randfälle

Die Q&A-Funktion ist stark von der Intentionenerkennung abhängig.

Wenn ich eine Frage stelle, die nichts mit den Konkurrenten zu tun hat, muss das System eine spezielle Logik haben, um diese zu behandeln.

Wenn ich nach einem Konkurrenten frage, dessen Daten noch nicht in der Datenbank erfasst wurden, muss der Agent dies korrekt erkennen und "Keine Daten in der Datenbank" zurückgeben.

Um diese Randfälle intelligent genug zu behandeln, ist der Arbeitsaufwand sehr groß.

2) Anforderungsexplosion und Geschäftssystem

Wenn ich es zu einem vollständigen SaaS-Produkt machen und es meinen Freunden zur Verfügung stellen möchte, muss ich Account-Login und -Registrierung sowie die Datenisolierung für mehrere Mandanten implementieren.

Bei der Anmeldung mit verschiedenen Accounts müssen die Berichte und Q&A-Einträge vollständig unabhängig voneinander sein.

Außerdem muss ich ein Token-Verbrauchsbuchungssystem erstellen.

3) Erschöpft durch Randfunktionen

Das Ergebnis war, dass das System in Bugs versank.

Anfangs habe ich mit Gradio (einem Framework speziell für Python-Demos) die Kernlogik des MVP aufgebaut, und es lief in weniger als einem Tag.

Aber später, um die Benutzeroberfläche zu optimieren und es zu einem echten Produkt zu machen, habe ich das Frontend in Next.js + React umgebaut und dann die peripheren Systeme wie Account, Buchung und Datenisolierung hinzugefügt.

Um die Bugs dieser Randfunktionen zu beheben, habe ich drei ganze Tage verbracht, und es gab immer noch ständig Fehler.

Dies widerspricht vollständig meiner ursprünglichen Absicht, "Zeit und Kosten mit AI zu sparen".

Reflexion und Zusammenfassung

Schließlich habe ich beschlossen, es endgültig aufzugeben.

Für die Entwicklung der Kernlogik der AI habe ich weniger als 50 Yuan ausgegeben, aber für die Behebung der Bugs in den umgebenden Systemen habe ich mehr als dreimal so viel Geld und Energie aufgewendet, und am Ende war es immer noch nicht richtig.

Obwohl es mir wehtut, habe ich zumindest etwas gelernt.

Wenn ich dieses Projekt noch einmal in die Hand nehmen würde, würde ich alle aufwendigen technischen Ansammlungen vermeiden und vollständig von Pragmatismus und Kosten aus gehen.

Für ein Effizienzsteigerungstool für Einzelpersonen oder kleine Teams müssen eigentlich nur zwei Dinge richtig gemacht werden:

Erste Infrastrukturaufbau: Erfassung der ursprünglichen Informationen der Website und Erstellung eines hochwertigen Basiskonkurrentenanalyseberichts.

Regelmäßige Verfolgung: Regelmäßig (z. B. wöchentlich/monatlich) die Erfassung durchführen und basierend auf den ursprünglichen Daten und dem vorherigen Bericht eine "Vergleichsanalyse" erstellen (klar angeben, welche neuen Funktionen hinzugefügt wurden und welche Kerntexte geändert wurden).

Dies sollte ausreichen, um die geschäftlichen Probleme zu lösen.

Was die RAG-Q&A und das komplexe Mehrbenutzersystem angeht, sind diese in der frühen Phase des Projekts überhaupt keine Kernanforderungen, sondern reine zusätzliche Belastungen.

Dieser Artikel stammt aus dem WeChat-Account "Jeder ist ein Produktmanager" (ID: woshipm), Autor: Yu Ze. Veröffentlicht von 36Kr mit Genehmigung.