- Spegel es un navegador que convierte páginas web HTML en prompts para un LLM y las muestra como Markdown en la terminal
- Con base en prompts del usuario, puede transformar la página en tiempo real de forma personalizada, para mostrar solo la información importante de manera concisa
- Su funcionamiento central es rastreo de HTML → procesamiento del prompt con LLM → conversión y salida en Markdown
- Ofrece una UI de terminal intuitiva y ligera basada en Textual, y las vistas y prompts pueden gestionarse fácilmente con un archivo de configuración y modificarse en tiempo real
- A diferencia de navegadores de terminal existentes como Lynx, Links2 y Browsh, está especializado en optimizar contenido personalizado para el usuario mediante LLM
- Se puede instalar fácilmente con
pip install spegel, y al ser open source es ideal para diversos experimentos y extensiones
Resumen del proyecto y características
- Spegel es una especie de navegador web que funciona en la terminal; envía el HTML a un LLM para reconstruir la página con prompts definidos por el usuario
- La salida se convierte a Markdown y se muestra de forma intuitiva en una UI de terminal basada en Textual
- Diseño minimalista: no soporta JS y solo procesa solicitudes GET
- Soporta múltiples vistas de transformación mediante personalización de prompts para LLM (por ejemplo, resumen de recetas, destacar acciones principales, etc.)
Personalización y ejemplos de uso
- Los prompts y vistas pueden gestionarse libremente mediante la configuración del usuario (
~/.spegel.toml)
- Ejemplos:
- Extraer solo los ingredientes y pasos clave de una receta
- Transformar explicaciones complejas a un estilo ELI5 sencillo
- Si es necesario, se pueden registrar varias vistas al mismo tiempo para cambiar rápidamente entre ellas
Cómo funciona
- Spegel obtiene el HTML y lo envía al LLM junto con los prompts del archivo de configuración
- Convierte el resultado del LLM a Markdown y lo renderiza en la terminal mediante Textual
- Los prompts y vistas pueden ajustarse en tiempo real incluso durante la navegación
- Transmite el resultado línea por línea e implementa un búfer para evitar errores de formato en Markdown
Diferencias frente a navegadores de terminal tradicionales
- Lynx, Links2 y Browsh solo muestran en la terminal la propia estructura HTML
- Spegel está especializado en usar transformación basada en LLM para eliminar información innecesaria y ofrecer vistas optimizadas
- Los sitios web modernos dependen mucho de CSS y JS, lo que vuelve confusa la experiencia en terminal; Spegel extrae solo el contenido esencial para mejorar el enfoque y la accesibilidad
Instalación y uso
- Instalación sencilla con pip:
pip install spegel
- Ejecución:
spegel <URL>
- Es necesario personalizar el archivo de configuración (
~/.spegel.toml); consulta los ejemplos en GitHub
- Código fuente y contribuciones: https://github.com/simedw/spegel
Notas
- Sigue en fase de Proof-of-Concept, por lo que hay funciones incompletas y detalles aún toscos
- No soporta solicitudes POST; se están considerando ideas de expansión futura como entrada de formularios
- Más que un reemplazo de los navegadores de terminal existentes, tiene un fuerte carácter experimental para explorar la personalización de contenido basada en LLM+TUI
2 comentarios
Opinión de Hacker News
Me parece una idea realmente interesante; no reemplazará por completo al navegador, pero combinando búsqueda determinista con prompts podría crear una forma totalmente distinta de navegar por la web. Creo que encajaría mejor como una herramienta de línea de comandos.
Como siguiente paso, me imagino una función para manejar varias "pestañas" al mismo tiempo; por ejemplo, en la pestaña 1 un reporte de la noticia A, en la pestaña 2 la noticia B, en la pestaña 3 Wikipedia, y que luego resuma esos materiales y genere enlaces de referencia. Pero me pregunto si de verdad existe un modelo lo bastante estable para soportar ese flujo de trabajo; incluso los modelos SOTA más recientes parecen tener límites.
Esa función de ver de un vistazo reportes de varios medios, resumirlos y dar referencias es, en la práctica, lo que ya hace Ground News. No tengo ninguna relación con ellos; solo vi que los mencionaban como patrocinador en un video de Kurzgesagt. Claro que la UI puede ser distinta.
Aun si se mostraran varias pestañas o vistas al mismo tiempo, yo pensaría hacerlo solo dentro de la misma source; por ejemplo, una pestaña con la representación original optimizada para CLI y otra enfocada únicamente en fact-checking (buscar sustento del contenido con Google o Brave). Siento que sería un experimento muy divertido.
Básicamente es una estructura donde un LLM genera con todas sus fuerzas spam SEO basado en LLM, y luego otro LLM lo resume por encima y lo vuelve a escupir. Vaya futuro tan increíble.
Se siente muy clásico que el primer ejemplo sea extraer solo la receta de un sitio de recetas famoso. Personalmente, eso me hace querer recomendar el proyecto de inmediato; se siente muy ingenioso.
Yo lo veo otra vez como otro ejemplo de la moda LLM: reinterpretar algo que ya existía para volverlo mucho peor y no determinista. Estructuras estándar como schema.org/Recipe ya existían.
Me parece interesante que durante la extracción de recetas el contenido, los ingredientes o las cantidades puedan alterarse aleatoriamente. Creo que la naturaleza de los LLM se revela muy bien en este microcosmos, aunque en una dirección completamente distinta a la que esperan la mayoría de los comentarios.
Ya existen extensiones que extraen solo la receta de forma determinista y sin LLM. Por ejemplo, la extensión Recipe Filter de Chrome muestra la receta en un popup cuando la detecta dentro de la página.
Me gusta que el LLM se meta en medio y esquive tanto la tendencia reciente de Google hacia textos optimizados para SEO como la propia estructura SEO. Quitar todo lo innecesario y dejar solo la receta me parece un caso que le queda muy bien a un LLM. Presiento que aparecerán más casos de uso donde se use activamente al LLM como filtro. Claro, sería mejor poder extraer solo la receta directamente del HTML, pero la guerra del SEO se ha vuelto tan intensa que en la práctica ya no es posible.
Si el LLM se va a usar para quitar todo lo innecesario, también hay que considerar que podría alterar la receta de forma impredecible. No entiendo confiar en software probabilístico en un entorno donde los errores son inaceptables.
Llevo años imaginando un futuro así. Ya existen herramientas LLM con búsqueda integrada, y la capacidad de encadenar varias búsquedas es realmente poderosa. Pero Spegel va por un camino totalmente distinto. Creo que los bloqueadores de anuncios del futuro serán LLM locales, pequeños y eficientes; por ejemplo, podrían reordenar un timeline en orden cronológico, cambiar la UI o mostrar solo ciertos elementos. También podrían ocultar automáticamente comentarios de baja calidad. Todo eso es posible cuando el LLM actúa en medio como proxy o agente, y presiento que esa tendencia les va a resultar bastante incómoda a los anunciantes.
También hay que pensar que, durante la navegación web, un LLM podría tener que procesar millones de tokens por minuto, y por tanto el costo computacional sería enorme.
Un LLM crea lo innecesario, y otro LLM vuelve a quitar lo innecesario; me parece un ciclo que fluye sin que se malinterpreten entre ellos.
Creo que podría tener potencial si se usa un modelo menos complejo —incluso uno basado en LSTM— para recorrer el DOM, seleccionar solo lo necesario y recopilarlo en una estructura de datos que luego el navegador muestre directamente. Además, da la impresión de que sería fácil crear datos de entrenamiento usando la cadena de herramientas basada en LLM del propio autor.
Mucha gente parece pasar por alto que el HTML es solo el comienzo. Si puedes transformar una página web en otra vista, en realidad puedes hacer lo mismo con cualquier entrada que el modelo pueda aceptar: PDF, zip con imágenes, JSON grandes, lo que sea. Al final, lo importante no es la entrada HTML sino la view de salida.
Propongo agregar la opción
-pa spegel.Sería una función para extraer solo la información deseada a partir de un prompt.
Creo que, en vez de reescribir cada página desde cero cada vez, se podría convertir a Markdown después de una sola visita y luego compartir entre todos esas versiones limpias, reduciendo así el costo de recomputación.
Como cada usuario tiene necesidades y conocimientos previos distintos, creo que aunque se cree material compartido muy limpio, igual seguirá habiendo un proceso de ajuste personal. Aun así, un caché global de duplicados, como un caché P2P con IPFS o similar, podría ayudar con la preservación de datos, la disponibilidad y el ahorro de recursos.
Los cache headers sirven para indicar al cliente cuánto tiempo puede guardar algo en caché. Pienso que también estaría bien agregar una capa de caché del lado del cliente que respete esos headers.
Si el objetivo es lograr un layout consistente, también podría funcionar pasarle al modelo, junto con la entrada, el resultado en Markdown de la última página como ejemplo (
one-shot example).Como el objetivo de este proyecto es una "vista personalizada basada en prompts", al menos tendría sentido guardar en caché el resultado del prompt por defecto.
Me pareció un POC realmente excelente, y tiene bastantes similitudes con la extensión de Chrome "reader view" que uso normalmente.
enlace de la extensión reader view
La idea me parece muy buena y creo que también tiene mucho potencial desde el punto de vista de accesibilidad.
Hay un video viejo donde se muestra a mi agente de IA ya retirado transformando páginas web en tiempo real.
Demo: convertir HN en My Little Pony (video)
Más o menos desde el segundo 37 se puede ver el resultado.
También dejé hecha una extensión open source de Chrome, así que si les da curiosidad pueden revisar ChromeGPT.
spegel -p "extract only the product reviews" > REVIEWS.mdSi tan solo tuviera esta opción, se me ocurren varios usos, pero parece que todavía no existe.