- Spegel est un navigateur qui convertit les pages web HTML en prompts pour LLM et les affiche au format Markdown dans le terminal
- À partir de prompts utilisateur, il peut transformer une page en temps réel de manière personnalisée, afin de n’afficher que les informations importantes de façon concise
- Son fonctionnement repose sur crawl HTML → traitement par prompt LLM → conversion et affichage en Markdown
- Il propose une interface terminal intuitive et légère basée sur Textual, et les vues comme les prompts peuvent être gérés facilement via un fichier de configuration et modifiés à chaud
- Contrairement aux navigateurs terminal existants comme Lynx, Links2 ou Browsh, il est spécialisé dans l’optimisation personnalisée du contenu à l’aide d’un LLM
- Installation simple avec
pip install spegel, en open source, adapté à divers essais et extensions
Aperçu du projet et caractéristiques
- Spegel est une forme de navigateur web fonctionnant dans le terminal qui envoie le HTML à un LLM pour recomposer la page à l’aide de prompts définis par l’utilisateur
- La sortie est convertie en Markdown puis affichée de façon intuitive dans une interface terminal basée sur Textual
- Conception minimaliste : pas de prise en charge de JS, uniquement les requêtes GET
- Prise en charge de multiples vues de transformation grâce à la personnalisation des prompts LLM (ex. : résumé de recette, mise en avant des actions principales)
Personnalisation et exemples d’usage
- Les prompts et les vues peuvent être librement gérés via la configuration utilisateur (
~/.spegel.toml)
- Exemples :
- extraire uniquement les ingrédients et les étapes clés d’une recette
- transformer une explication complexe en une version simple, style ELI5
- enregistrer plusieurs vues en même temps pour basculer rapidement selon le besoin
Fonctionnement
- Spegel récupère le HTML et l’envoie au LLM avec les prompts du fichier de configuration
- Le résultat du LLM est converti en Markdown puis rendu dans le terminal via Textual
- Les prompts et les vues peuvent être ajustés en temps réel même pendant la navigation
- Les résultats sont diffusés ligne par ligne, avec un traitement par tampon pour éviter les erreurs de formatage Markdown
Différences avec les navigateurs terminal existants
- Lynx, Links2 et Browsh affichent surtout la structure HTML elle-même dans le terminal
- Spegel se distingue par sa transformation basée sur un LLM, spécialisée dans la suppression des informations inutiles et la fourniture de vues optimisées
- Les sites web modernes dépendent fortement du CSS et du JS, ce qui les rend encombrants en environnement terminal ; Spegel n’extrait que le contenu essentiel pour améliorer la lisibilité et l’accessibilité
Installation et utilisation
- Installation simple via pip :
pip install spegel
- Exécution :
spegel <URL>
- La personnalisation du fichier de configuration (
~/.spegel.toml) est nécessaire ; voir les exemples sur GitHub
- Code source et contribution : https://github.com/simedw/spegel
Remarques
- Le projet est encore au stade de proof of concept, avec certaines fonctions inachevées et des aspects encore bruts
- Les requêtes POST ne sont pas prises en charge ; des idées d’extension comme la saisie de formulaires sont envisagées pour la suite
- Plus qu’un remplaçant des navigateurs terminal classiques, il s’agit surtout d’une expérimentation autour de la personnalisation de contenu basée sur LLM + TUI
2 commentaires
Avis Hacker News
Je trouve que cette technologie est une idée vraiment intéressante ; sans remplacer totalement le navigateur, elle pourrait créer une manière totalement différente de naviguer sur le web en combinant recherche déterministe et prompts. Je pense que cela conviendrait encore mieux sous la forme d’un outil en ligne de commande.
Comme étape suivante, j’imagine une fonction permettant de gérer plusieurs « onglets » en même temps, par exemple l’onglet 1 avec la couverture de l’actualité A, l’onglet 2 avec l’actualité B, l’onglet 3 avec Wikipedia, puis un système qui résume ces sources et génère des liens de référence. En revanche, je me demande s’il existe vraiment un modèle suffisamment stable pour prendre en charge ce type de workflow ; même les derniers modèles SOTA donnent l’impression d’avoir leurs limites.
Cette idée de voir d’un coup d’œil les couvertures de plusieurs médias, de les résumer et de fournir des références, c’est en pratique ce que fait Ground News. Je n’ai aucun lien avec eux, j’en ai simplement entendu parler comme sponsor dans une vidéo de Kurzgesagt. L’interface peut évidemment être différente.
Même si on affichait plusieurs onglets/vues en parallèle, je pense que je le ferais uniquement à l’intérieur d’une même source, par exemple un onglet avec la représentation d’origine optimisée pour le CLI, et un autre dédié uniquement au fact-checking (chercher des justifications via Google ou Brave). Ce genre d’expérimentation me semblerait très amusant.
Si on veut résumer, c’est une structure où un LLM produit de toutes ses forces du spam SEO, puis un autre LLM le résume grossièrement avant de le recracher. Quel avenir formidable.
Voir comme tout premier exemple l’extraction d’une recette depuis un site de recettes célèbre, c’est vraiment une scène classique. Personnellement, c’est le genre de projet que j’aurais envie de recommander tout de suite ; ça donne une impression de projet très ingénieux.
Pour moi, c’est encore un exemple de la mode LLM qui réinterprète quelque chose qui existait déjà pour le rendre bien pire et non déterministe. Des structures standards comme schema.org/Recipe existaient déjà.
Je trouve intéressant que, lors de l’extraction de recettes, le contenu, les ingrédients ou les quantités soient modifiés aléatoirement. J’ai l’impression que la nature des LLM se révèle très bien dans ce microcosme, mais dans une direction totalement différente de celle qu’attend la plupart des commentaires.
Il existe déjà des extensions qui extraient uniquement les recettes de manière déterministe, sans LLM. Par exemple, l’extension Chrome Recipe Filter détecte une recette dans la page et l’affiche dans une fenêtre pop-up.
J’aime le fait que le LLM s’intercale au milieu pour contourner la tendance récente à l’écriture optimisée pour le SEO chez Google ainsi que toute la structure SEO elle-même. Retirer tout le superflu pour ne garder que la recette me semble être un cas d’usage particulièrement adapté aux LLM. J’ai le pressentiment qu’on verra davantage de cas où les LLM seront activement utilisés comme filtres. Bien sûr, ce serait mieux si on pouvait extraire directement la recette depuis le HTML, mais la guerre du SEO est devenue si intense que cela n’est plus réaliste.
Si le LLM est utilisé pour supprimer tous les éléments inutiles, il faut aussi considérer qu’il peut modifier la recette de manière imprévisible. Je ne comprends pas qu’on puisse faire confiance à un logiciel probabiliste dans un environnement où l’erreur n’est pas permise.
J’anticipais déjà ce futur depuis des années. Il existe déjà des outils LLM avec recherche intégrée, et la capacité à enchaîner plusieurs recherches est vraiment puissante. Mais Spegel fonctionne d’une manière totalement différente. À mon avis, les bloqueurs de pub du futur seront de petits LLM locaux et efficaces : ils pourront par exemple trier une timeline par ordre chronologique, modifier l’interface, n’afficher que certains éléments, masquer automatiquement les commentaires de faible qualité, etc. Tout cela devient possible quand le LLM agit au milieu comme proxy ou agent. J’ai le pressentiment que cette évolution sera assez désagréable pour les annonceurs.
Il faut aussi penser au fait qu’en navigation web, un LLM pourrait devoir traiter des millions de tokens par minute, avec le coût de calcul que cela implique.
J’ai l’impression d’être dans une boucle où un LLM produit du contenu inutile, puis un autre LLM retire à nouveau l’inutile, le tout sans même se mal comprendre.
Je pense qu’il y a du potentiel avec un modèle moins complexe (même basé sur des LSTM, à mon avis) qui parcourrait le DOM, sélectionnerait uniquement les parties utiles et les collecterait directement dans une structure de données à afficher dans le navigateur. J’ai aussi le sentiment qu’on pourrait facilement produire des données d’entraînement en utilisant la chaîne d’outils LLM de l’auteur.
Beaucoup de gens semblent oublier que le HTML n’est qu’un point de départ. Si l’on peut transformer une page web en une autre vue, alors on peut en réalité transformer n’importe quelle entrée que le modèle accepte : PDF, zip contenant des images, gros JSON, peu importe. Au final, l’important n’est pas l’entrée HTML mais la vue produite en sortie.
Proposition d’ajouter l’option
-pà spegelafin d’extraire uniquement les informations souhaitées sur la base d’un prompt.
Je pense qu’au lieu de réécrire la page à neuf à chaque fois, on pourrait la convertir une fois en Markdown lors de la visite, puis partager entre nous des versions propres, ce qui réduirait le coût de reconstruction.
Comme chaque utilisateur a des besoins et des connaissances préalables différents, je pense que, même avec une ressource commune très propre, il restera toujours un travail d’ajustement personnel. En revanche, un cache global de déduplication de type P2P (IPFS, etc.) pourrait aider à préserver les données, garantir leur disponibilité et économiser les ressources.
Les en-têtes de cache servent à indiquer au client combien de temps il peut conserver les informations en cache. Je me dis qu’il serait bien d’ajouter côté client une couche de cache qui respecte aussi ces en-têtes.
Si l’objectif est d’obtenir une mise en page cohérente, il serait aussi possible de transmettre au modèle le résultat Markdown de la dernière page comme exemple en contexte (one-shot example).
Comme ce projet vise une « vue personnalisée fondée sur des prompts », je pense qu’on pourrait au moins mettre en cache et réutiliser le résultat du prompt par défaut.
J’ai trouvé que c’était un très bon POC, et il y a de nombreux points communs avec l’extension Chrome « reader view » que j’utilise habituellement.
lien vers l’extension reader view
L’idée est extrêmement sympa et me semble avoir un fort potentiel aussi du point de vue de l’accessibilité.
Il existe une vieille vidéo où mon agent IA aujourd’hui à la retraite fait une démonstration de transformation en temps réel de pages web.
démo vidéo transformant HN en My Little Pony
On peut voir le résultat à partir d’environ 37 secondes.
J’avais aussi créé une extension Chrome open source, donc si cela vous intéresse, voir ChromeGPT
spegel -p "extract only the product reviews" > REVIEWS.md
Si seulement cette option existait, j’aurais plein d’idées d’usage, mais il semble qu’elle ne soit pas encore disponible.