Quelle est réellement cette architecture
Un vision transformer, converti au format ONNX et compressé à environ 40 MB, divisé en deux parties afin que chacune reste sous la limite de taille de fichier de la plateforme d'hébergement. Il est réassemblé dans le navigateur et sa somme de contrôle est vérifiée avant toute exécution.
L'inférence s'effectue via WebAssembly, ce qui permet à un environnement d'exécution compilé de tourner à une vitesse proche du natif dans un onglet de navigateur. L'environnement d'exécution lui-même est un binaire WASM compressé chargé aux côtés des poids.
Rien de tout cela n'est plus exotique. Ce qui relevait de la démonstration de recherche en 2021 est aujourd'hui une manière courante de distribuer un modèle, et les navigateurs ont fait l'essentiel du travail.
Ce que cela apporte
| Bien immobilier | Dans le navigateur | Sur un serveur |
|---|---|---|
| L'image quitte votre appareil | No impossible | Yes requis |
| Coût par vérification | Yes zéro | No calcul réel |
| Accord de traitement des données nécessaire | No | Yes |
| Fonctionne sans réseau après le chargement | Yes | No |
| Le modèle peut rester privé | No il est téléchargé | Yes |
| La première vérification est instantanée | No le modèle se télécharge une seule fois | Yes |
La première ligne est la raison d'être des autres. Puisqu'il n'y a pas de point de terminaison pour les téléversements, il n'y a pas de réservoir contenant les photographies d'autres personnes, pas de politique de conservation à rédiger, pas de faille à divulguer et rien à remettre sur demande.
La seconde ligne explique pourquoi le service peut être gratuit sans compteur d'utilisation. Une vérification ne coûte rien à fournir, il n'y a donc aucun coût par image à amortir, ce qui change la nature de la tarification.
Ce que cela coûte
Trois compromis réels, exposés clairement, car une page qui ne liste que des avantages relève de la publicité.
- La première vérification est lente. Quarante mégaoctets doivent arriver avant que quoi que ce soit ne se produise. Sur une connexion rapide, cela prend quelques secondes ; sur une mauvaise connexion, c'est plus long. Les vérifications suivantes réutilisent le modèle mis en cache et démarrent immédiatement.
- Les appareils anciens peinent. L'inférence nécessite de la mémoire et une puissance de calcul qu'un téléphone vieux de cinq ans ne possède peut-être pas confortablement. Un serveur se moquerait de l'appareil que vous tenez entre vos mains.
- Le modèle est public. Tout ce qui est téléchargé sur un navigateur peut être conservé. Un modèle côté serveur peut être propriétaire ; celui-ci ne le peut pas, et les poids constituent de toute façon un point de contrôle de recherche ouvert.
Le troisième point mérite d'être abordé directement. Distribuer un modèle au client revient à le céder. C'est un compromis acceptable ici car les poids sont déjà publiés et le travail qui rend l'outil utile réside dans le calibrage, le découpage en tuiles et l'interprétation construits autour de ceux-ci.
Les problèmes d'ingénierie qui méritent d'être connus
Diviser un fichier volumineux
Les plateformes d'hébergement statique plafonnent la taille des fichiers individuels. Un modèle de 40 MB dépassait la limite, il est donc livré sous la forme de deux parties déterministes qui sont réassemblées dans le navigateur et vérifiées par rapport au hachage d'un manifeste avant utilisation. Une partie corrompue ou substituée échoue de manière explicite plutôt que de produire silencieusement des scores erronés.
Ne rien charger tant que ce n'est pas nécessaire
Le modèle, l'environnement d'exécution et le lecteur de justificatifs ne sont pas récupérés au chargement de la page. Ils arrivent lors de la première interaction, de sorte qu'une personne lisant un article ne télécharge rien de tout cela. Cela permet de maintenir des pages rapides pour la grande majorité des visiteurs qui n'effectuent jamais de vérification.
Décoder les formats complexes
HEIC provenant d'iPhone, AVIF, TIFF et JPEG XL nécessitent tous un décodage avant l'évaluation. Les navigateurs gèrent désormais la plupart d'entre eux de manière native, ce nom supprime ce qui constituait autrefois la plus grande part du travail côté client dans un outil de ce genre.
Quand cette architecture est le mauvais choix
Elle n'est pas universellement supérieure. Un serveur a davantage de sens lorsque le modèle est propriétaire et mérite d'être protégé, lorsqu'il est trop volumineux pour être distribué, lorsque vous avez besoin de résultats dans un pipeline dorsal plutôt que devant une personne, ou lorsque vous exigez un temps de réponse garanti quel que soit l'appareil.
Pour un outil qu'un utilisateur ouvre pour vérifier une image suspecte, rien de tout cela ne s'applique, et la propriété de confidentialité vaut plus que tout ce qu'un serveur pourrait ajouter.
Ce que cela exclut
Faire le choix du client a des conséquences au-delà de la confidentialité, et certaines d'entre elles constituent des limitations qu'il vaut mieux nommer plutôt que de présenter comme des fonctionnalités.
Il n'y a pas d'historique. Un résultat n'existe que dans l'onglet qui l'a produit, de sorte qu'aucune recherche ultérieure n'est possible à moins qu'il n'ait été exporté. C'est le coût direct de l'absence de compte, et c'est la fonctionnalité la plus demandée que l'architecture rend complexe.
Il n'y a pas d'état partagé. Deux personnes ne peuvent pas voir la même file d'attente, et une équipe ne peut pas examiner les vérifications des autres. Un lien partagé transporte un unique résultat, ce qui couvre une conversation et non un flux de travail.
Il n'y a pas d'API. Tout ce qui s'exécute dans un onglet de navigateur ne peut pas être appelé depuis un pipeline dorsal, ce qui exclut totalement les usages à plus fort volume. Ce sont de réelles lacunes, et la position honnête est qu'elles constituent le prix à payer pour la propriété qui importe le plus.