Ich sitze jetzt seit ein paar Tagen mit dieser OpenGradient-Designentscheidung und das, was wirklich heraussticht, ist, dass du keinen einzelnen Verifizierungslevel für eine gesamte Anwendung auswählen musst....
hier ist die Mechanik. Auf OpenGradient kann eine einzelne atomare Transaktion Verifizierungsmethoden mischen - TEE für LLM-Überlegungen, ZKML für ein Risikomodell, Vanilla für Analysen, alles zusammen abgerechnet. Das Netzwerk zwingt nicht einen Vertrauenlevel für alles, was du tust....
gemischte Verifizierung. Eine Transaktion....
was ich denke, dass oft übersehen wird, ist, wie ungewöhnlich das im Vergleich zu den meisten "verifizierbaren KI"-Pitches ist, die einfach eine Methode wählen und sie überall anwenden. OpenGradient behandelt den Vertrauenlevel als eine Entscheidung pro Komponente, anstatt plattformweit....$RE
ich finde es tatsächlich gut, dass die OPG-Abrechnung unabhängig davon geschieht, welche Verifizierungsmethode darunter verwendet wurde - die Komplexität wird vom Protokoll absorbiert, nicht auf den Entwickler abgewälzt, der zwischen den Methoden wählen muss....
aber ich will nicht so tun, als ob das Mischen von Verifizierungsmethoden ohne Trade-offs ist. Das Kombinieren von TEE und ZKML in einer Transaktion bedeutet immer noch, dass die langsamste Komponente, normalerweise das ZKML-Stück, den Gesamtverzögerungsboden festlegt.... $BTW
ich habe einmal eine Pipeline gebaut, die schnelle und langsame Validierungsschritte gemischt hat, und ich habe auf die harte Tour gelernt, dass der langsamste Schritt immer gewinnt.
was ich immer noch nicht klären kann, ist, ob OpenGradient es einem Entwickler erlaubt, pro-Komponente Timeout-Limits innerhalb einer gemischten Verifizierungs-Transaktion festzulegen, oder ob das Ganze standardmäßig auf das langsamste Stück wartet??
@OpenGradient
$OPG #OPG