Vor ein paar Tagen habe ich ein kleines Testexperiment gemacht. Ich habe einen On-Chain-Announcement an eine KI zur Zusammenfassung übergeben und dann einen weiteren Agenten daraus eine Beobachtungsliste erstellen lassen. Der ausgegebene Text war logisch klar, die Formulierungen präzise und sah so aus, als wäre er vollständig einsatzbereit. Aber ich habe lange gezögert und am Ende doch nicht auf „übernehmen“ geklickt.
Der Grund ist ganz einfach: Ich kenne den genauen Aufrufpfad nicht. Welches Modell verwendet wurde, ob die Prompt(s) in einer Zwischenschicht umgeschrieben wurden, und ob die finale Ausgabe exakt nach der ursprünglichen Anfrage generiert wurde – diese Fragen kann ich alle nicht beantworten. Eine KI-Ausgabe, die sich nicht nachvollziehen lässt, mag noch so schön sein – sie hat keinen wirklichen Wert.
Wegen dieses Details bin ich noch einmal zu @OpenGradient zurückgegangen. Bisher hatte ich es als einen normalen KI-Chat-Eingang betrachtet und gedacht, dahinter seien einfach nur mehr Modelle verbunden. Aber nachdem ich die Architektur gesehen habe, wurde mir klar: Das Kernproblem ist nicht die Anzahl der Modelle. OpenGradient zerlegt das Modell-Hosting, die Inferenz-Ausführung und die Verifikations-/Beweisführung in drei unabhängige Module. Nach jeder Anfrage wird außerdem eine nachvollziehbare Ausführungsroute generiert. Welches Modell du aufgerufen hast, auf welchem Knoten die Inferenz lief, und ob das Verifikationsergebnis bestanden hat – jeder Schritt wird protokolliert.
Dieses Design ist für Leute wie mich, die bei KI-Ausgaben eine Art „Vertrauenskapflicht“ im Kopf haben, praktisch die einzige Lösung. Besonders die TEE-Route interessiert mich. Wenn der Inferenzprozess in eine vertrauenswürdige Ausführungsumgebung verlagert wird, können Betreiber der Knoten deine Anfragedaten nicht anfassen. Das Ergebnis trägt außerdem eine attestation-Signatur. ZKML und Vanilla stehen jeweils für unterschiedliche Kosten- und Vertrauenswürdigkeitsanforderungen: OpenGradient verlangt nicht, dass alle Szenarien die schwerste Beweisführung nutzen. Stattdessen soll sich die Verifikationsmethode an die Komplexität der Aufgabe anpassen.
Viele glauben, dass es bei AI Agents reicht, wenn sie flüssig antworten. Aber sobald ein Agent ein Wallet, Datenquellen oder automatisierte Ausführungsaufgaben einbindet, lassen sich fehlerhafte Ausgaben nicht nur durch nachträgliche Screenshots sauber rekonstruieren. Du musst beweisen können, dass er „nicht einfach wild herumgerechnet hat“, bevor du ihn wirklich arbeiten lassen darfst.
#OPG
Deshalb schaue ich mir OP GG jetzt an und achte nicht auf den Preis. Ich sehe nach, ob die echten Inferenzanfragen zunehmen, ob die Verifikationsaufzeichnungen kontinuierlich wachsen und ob Entwickler bereit sind, ihre Agenten über das SDK ins Netzwerk einzubinden. Nur wenn diese Dinge sich bewegen,
OPG, nicht auf den Preis schaue ich. Ich sehe, ob die echten Inferenzanfragen steigen, ob die Verifikationsaufzeichnungen kontinuierlich zunehmen und ob Entwickler bereit sind, die Agents über das SDK in das Netzwerk einzubinden$OPG
Der Grund ist ganz einfach: Ich kenne den genauen Aufrufpfad nicht. Welches Modell verwendet wurde, ob die Prompt(s) in einer Zwischenschicht umgeschrieben wurden, und ob die finale Ausgabe exakt nach der ursprünglichen Anfrage generiert wurde – diese Fragen kann ich alle nicht beantworten. Eine KI-Ausgabe, die sich nicht nachvollziehen lässt, mag noch so schön sein – sie hat keinen wirklichen Wert.
Wegen dieses Details bin ich noch einmal zu @OpenGradient zurückgegangen. Bisher hatte ich es als einen normalen KI-Chat-Eingang betrachtet und gedacht, dahinter seien einfach nur mehr Modelle verbunden. Aber nachdem ich die Architektur gesehen habe, wurde mir klar: Das Kernproblem ist nicht die Anzahl der Modelle. OpenGradient zerlegt das Modell-Hosting, die Inferenz-Ausführung und die Verifikations-/Beweisführung in drei unabhängige Module. Nach jeder Anfrage wird außerdem eine nachvollziehbare Ausführungsroute generiert. Welches Modell du aufgerufen hast, auf welchem Knoten die Inferenz lief, und ob das Verifikationsergebnis bestanden hat – jeder Schritt wird protokolliert.
Dieses Design ist für Leute wie mich, die bei KI-Ausgaben eine Art „Vertrauenskapflicht“ im Kopf haben, praktisch die einzige Lösung. Besonders die TEE-Route interessiert mich. Wenn der Inferenzprozess in eine vertrauenswürdige Ausführungsumgebung verlagert wird, können Betreiber der Knoten deine Anfragedaten nicht anfassen. Das Ergebnis trägt außerdem eine attestation-Signatur. ZKML und Vanilla stehen jeweils für unterschiedliche Kosten- und Vertrauenswürdigkeitsanforderungen: OpenGradient verlangt nicht, dass alle Szenarien die schwerste Beweisführung nutzen. Stattdessen soll sich die Verifikationsmethode an die Komplexität der Aufgabe anpassen.
Viele glauben, dass es bei AI Agents reicht, wenn sie flüssig antworten. Aber sobald ein Agent ein Wallet, Datenquellen oder automatisierte Ausführungsaufgaben einbindet, lassen sich fehlerhafte Ausgaben nicht nur durch nachträgliche Screenshots sauber rekonstruieren. Du musst beweisen können, dass er „nicht einfach wild herumgerechnet hat“, bevor du ihn wirklich arbeiten lassen darfst.
#OPG
Deshalb schaue ich mir OP GG jetzt an und achte nicht auf den Preis. Ich sehe nach, ob die echten Inferenzanfragen zunehmen, ob die Verifikationsaufzeichnungen kontinuierlich wachsen und ob Entwickler bereit sind, ihre Agenten über das SDK ins Netzwerk einzubinden. Nur wenn diese Dinge sich bewegen,
OPG, nicht auf den Preis schaue ich. Ich sehe, ob die echten Inferenzanfragen steigen, ob die Verifikationsaufzeichnungen kontinuierlich zunehmen und ob Entwickler bereit sind, die Agents über das SDK in das Netzwerk einzubinden$OPG
