Ein bisschen Selbst-Experiment.
Ziel: Meine persönlichen Gesundheits- und Reisedaten nutzen, um mir personalisierte Ernährungs- und Trainingsempfehlungen zu geben – mit Frontier-Modellen, aber so, dass dabei keine privaten Informationen an sie geleakt werden.
Strategie: Ein lokales Modell (Qwen 3.8 Flash Next) zur Orchestrierung verwenden und leistungsstarke Remote-Modelle als Tool-Call nutzen, um von höherem Denkvermögen und Wissen zu profitieren, das das lokale Modell nicht hat.
Dreistufiger Ansatz für Datenschutz:
Keine Weitergabe personenbezogener Daten oder Leckage meiner Identität über den Schreibstil –> Das lokale Modell schreibt die Anfragen an das Frontier-Modell, nicht ich
Keine Weitergabe, wer ich bin, über den Zahlungsweg –> zkAPI
Keine Weitergabe, wer ich bin, über Netzwerk/IP –> Tor
Du brauchst alle drei (und schließlich haben wir auch alle drei, zumindest in gewissem Umfang)
Eine Skill-Datei lehrt das lokale Modell, wann und wie es minimal-datenoffenlegende Anfragen an Remote-Modelle konstruiert. Verwende zkAPI in einer mit Tor verpackten Form als CLI-Tool.
Und alles funktioniert! Ich habe die Empfehlungen zurückbekommen; Informationen von Frontier-Modellen haben geholfen, sie zu verbessern.
Hauptmängel:
* Tor ist wirklich nicht für Anfrage-für-Anfrage De-Linking optimiert, was die einzige Form von Netzwerk-Layer-Privatsphäre ist, die in der heutigen Welt wirklich Sinn ergibt (lange laufende Identifier sind zu fragil). Wahrscheinlich nicht privat genug und gleichzeitig Latenz 10-100x höher, als sie sein könnte.
* Die Request-Konstruktionsstrategien der Skill-Datei sind definitiv weit davon entfernt, optimal zu sein.
* Qwen 3.8 Flash Next ist immer noch zu langsam, als dass es sich angenehm anfühlen würde. Es läuft zwar bequem mit 20-30 TPS, aber es würde sich erst ab 100+ wirklich schnell anfühlen.
* Es gibt einen Tradeoff: Je vorsichtiger du bist, welche Daten du einem Remote-Modell gibst, desto weniger kann es dir helfen
https://github.com/ethereum/zkapi/pull/16/changes
Ziel: Meine persönlichen Gesundheits- und Reisedaten nutzen, um mir personalisierte Ernährungs- und Trainingsempfehlungen zu geben – mit Frontier-Modellen, aber so, dass dabei keine privaten Informationen an sie geleakt werden.
Strategie: Ein lokales Modell (Qwen 3.8 Flash Next) zur Orchestrierung verwenden und leistungsstarke Remote-Modelle als Tool-Call nutzen, um von höherem Denkvermögen und Wissen zu profitieren, das das lokale Modell nicht hat.
Dreistufiger Ansatz für Datenschutz:
Keine Weitergabe personenbezogener Daten oder Leckage meiner Identität über den Schreibstil –> Das lokale Modell schreibt die Anfragen an das Frontier-Modell, nicht ich
Keine Weitergabe, wer ich bin, über den Zahlungsweg –> zkAPI
Keine Weitergabe, wer ich bin, über Netzwerk/IP –> Tor
Du brauchst alle drei (und schließlich haben wir auch alle drei, zumindest in gewissem Umfang)
Eine Skill-Datei lehrt das lokale Modell, wann und wie es minimal-datenoffenlegende Anfragen an Remote-Modelle konstruiert. Verwende zkAPI in einer mit Tor verpackten Form als CLI-Tool.
Und alles funktioniert! Ich habe die Empfehlungen zurückbekommen; Informationen von Frontier-Modellen haben geholfen, sie zu verbessern.
Hauptmängel:
* Tor ist wirklich nicht für Anfrage-für-Anfrage De-Linking optimiert, was die einzige Form von Netzwerk-Layer-Privatsphäre ist, die in der heutigen Welt wirklich Sinn ergibt (lange laufende Identifier sind zu fragil). Wahrscheinlich nicht privat genug und gleichzeitig Latenz 10-100x höher, als sie sein könnte.
* Die Request-Konstruktionsstrategien der Skill-Datei sind definitiv weit davon entfernt, optimal zu sein.
* Qwen 3.8 Flash Next ist immer noch zu langsam, als dass es sich angenehm anfühlen würde. Es läuft zwar bequem mit 20-30 TPS, aber es würde sich erst ab 100+ wirklich schnell anfühlen.
* Es gibt einen Tradeoff: Je vorsichtiger du bist, welche Daten du einem Remote-Modell gibst, desto weniger kann es dir helfen
https://github.com/ethereum/zkapi/pull/16/changes
