- O Spegel é um navegador que transforma páginas HTML em prompts para LLM, exibindo-as em Markdown no terminal
- Com base em prompts do usuário, ele pode converter a página de forma personalizada em tempo real, permitindo configurar a exibição apenas das informações importantes, de forma concisa
- O funcionamento central é rastreamento de HTML → processamento do prompt pelo LLM → conversão e saída em Markdown
- Oferece uma UI de terminal intuitiva e leve com TUI baseada em Textual, e as visualizações e prompts podem ser gerenciados facilmente por arquivo de configuração e alterados em tempo real
- Diferente de navegadores de terminal tradicionais como Lynx, Links2 e Browsh, ele é especializado em otimização de conteúdo personalizada com uso de LLM
- Pode ser instalado facilmente com
pip install spegel e, por ser open source, é adequado para diversos experimentos e extensões
Visão geral do projeto e características
- O Spegel é um tipo de navegador web que roda no terminal e envia o HTML para um LLM para reconstruir a página com prompts definidos pelo usuário
- A saída é convertida para Markdown e exibida de forma intuitiva em uma UI de terminal baseada em Textual
- Design minimalista, sem suporte a JS e processando apenas requisições GET
- Suporta várias visualizações de transformação por meio da personalização de prompts para LLM (ex.: resumo de receita, destaque das ações principais etc.)
Personalização e exemplos de uso
- Os prompts e as visualizações podem ser gerenciados livremente pela configuração do usuário (
~/.spegel.toml)
- Exemplos:
- Extrair apenas os ingredientes e as etapas principais de uma receita
- Converter explicações complexas em um estilo simples tipo ELI5
- Se necessário, registrar várias visualizações ao mesmo tempo para alternar rapidamente entre elas
Como funciona
- O Spegel busca o HTML e o envia ao LLM junto com os prompts do arquivo de configuração
- Converte o resultado do LLM em Markdown e o renderiza no terminal via Textual
- Os prompts e as visualizações podem ser ajustados em tempo real mesmo durante a navegação
- Faz streaming do resultado linha por linha e implementa tratamento com buffer para evitar erros de formatação em Markdown
Diferenças em relação aos navegadores de terminal tradicionais
- Lynx, Links2 e Browsh apenas exibem a própria estrutura HTML no terminal
- O Spegel é especializado em transformação baseada em LLM para remover informações desnecessárias e oferecer visualizações otimizadas
- Como sites modernos dependem muito de CSS e JS, a experiência no terminal tende a ficar confusa; o Spegel extrai apenas o conteúdo essencial para melhorar foco e acessibilidade
Instalação e uso
- Instalação simples via pip:
pip install spegel
- Execução:
spegel <URL>
- É necessário personalizar o arquivo de configuração (
~/.spegel.toml); veja os exemplos no GitHub
- Código-fonte e contribuições: https://github.com/simedw/spegel
Observações
- Ainda está em fase de proof of concept, então há algumas funções incompletas e partes ainda brutas
- Não oferece suporte a requisições POST; ideias como entrada de formulários estão sendo consideradas para futuras expansões
- Mais do que um substituto para navegadores de terminal existentes, ele tem forte caráter experimental de exploração de personalização de conteúdo baseada em LLM + TUI
2 comentários
Comentários no Hacker News
Acho essa tecnologia uma ideia realmente interessante; não vai substituir completamente o navegador, mas parece capaz de criar uma forma totalmente diferente de navegar na web ao combinar busca determinística com prompts. Também acho que faria ainda mais sentido como ferramenta de linha de comando.
Como próximo passo, imagino um recurso para lidar com várias "abas" ao mesmo tempo; por exemplo, a aba 1 com a cobertura da notícia A, a aba 2 com a notícia B, a aba 3 com a Wikipedia, e então resumir esses materiais e gerar links de referência. Ainda assim, fico em dúvida se existe algum modelo estável o bastante para sustentar esse fluxo de trabalho; até os modelos SOTA mais recentes parecem ter limitações.
Esse tipo de função de ver várias coberturas lado a lado, resumir e fornecer referências é, na prática, o que o Ground News já faz. Não tenho nenhuma relação com eles; só vi a marca citada como patrocinadora em um vídeo do Kurzgesagt. Claro, a interface pode ser bem diferente.
Mesmo se eu mostrasse várias abas/views ao mesmo tempo, pensaria em fazer isso apenas dentro da mesma fonte, por exemplo: uma aba com a apresentação original otimizada para CLI, outra focada só em fact-checking (buscando respaldo no Google ou Brave). Acho que seria muito divertido experimentar nessa direção.
No fim, isso parece uma estrutura em que um LLM produz spam de SEO com força total, e outro LLM faz um resumo mais ou menos disso para devolver ao usuário. Que futuro magnífico.
Achei muito clássico o primeiro exemplo ser justamente extrair só a receita de um site famoso de receitas. Pessoalmente, é o tipo de projeto que eu recomendaria na hora; tem cara de projeto muito engenhoso.
Vejo isso, mais uma vez, como um exemplo da moda do LLM reinterpretando algo que já existia e tornando tudo muito pior e não determinístico. Estruturas padrão como schema.org/Recipe já existiam.
É interessante como, no processo de extrair a receita, o conteúdo, os ingredientes e as quantidades podem ser alterados aleatoriamente. Acho que isso revela muito bem a natureza dos LLMs nesse microcosmo, embora vá completamente na direção oposta ao que a maioria dos comentários parece esperar.
Já existem extensões que extraem apenas a receita de forma determinística, sem LLM. Por exemplo, a extensão Recipe Filter do Chrome detecta a receita na página e a mostra em um pop-up.
Gosto da ideia de que o LLM entra no meio e contorna tanto a tendência recente de textos otimizados para SEO no Google quanto a própria estrutura de SEO. Remover tudo o que é desnecessário e ficar só com a receita parece um caso muito adequado para LLM, e imagino que veremos mais usos ativos de LLMs como filtro. Claro, seria melhor se desse para extrair só a receita direto do HTML, mas a guerra de SEO ficou tão intensa que isso se tornou irrealista na prática.
Se o LLM serve para remover todos os elementos desnecessários, também vale considerar que ele pode alterar a receita de forma imprevisível. Não entendo confiar esse tipo de software probabilístico a um ambiente em que erros não podem ser tolerados.
Eu já previa esse futuro há alguns anos. Já existem ferramentas de LLM com busca embutida, e a capacidade de encadear várias buscas é realmente poderosa. Mas o Spegel opera de um jeito totalmente diferente. Acho que o bloqueador de anúncios do futuro será um pequeno LLM local e eficiente: reordenar timelines em ordem cronológica, mudar a UI, mostrar apenas certos itens, esconder automaticamente comentários de baixa qualidade... tudo isso se torna possível quando o LLM atua no meio como proxy ou agente. Tenho a sensação de que essa tendência será bastante incômoda para os anunciantes.
Também é preciso considerar que, durante a navegação na web, o LLM talvez precise processar milhões de tokens por minuto, o que implica um custo computacional alto.
Um LLM cria as partes desnecessárias, e outro LLM remove de novo essas partes desnecessárias; é como um ciclo que segue adiante sem que um atrapalhe o outro.
Acho que há potencial em usar um modelo menos complexo — talvez até baseado em LSTM — para percorrer o DOM, selecionar apenas as partes necessárias e coletá-las em uma estrutura de dados que o próprio navegador possa exibir diretamente. Dá a impressão de que o próprio autor poderia usar sua cadeia de ferramentas baseada em LLM para gerar dados de treinamento com facilidade.
Muitas pessoas parecem ignorar que HTML é apenas o começo. Se for possível transformar uma página web em outro view, então na verdade é possível fazer esse tipo de transformação com qualquer entrada que um modelo consiga receber: PDF, zip com imagens, JSON grande, qualquer coisa. No fim, o importante não é a entrada em HTML, mas o view de saída.
Sugestão de adicionar a opção
-pao spegelSeria um recurso para extrair apenas as informações desejadas com base em prompt.
Em vez de reescrever tudo de novo a cada página, acho que daria para converter para Markdown uma vez por visita e depois compartilhar versões limpas entre si, reduzindo o retrabalho computacional.
Como cada usuário tem necessidades e conhecimento prévio diferentes, acho que, por mais limpo que seja o material compartilhado, sempre vai restar um processo de ajuste individual. Ainda assim, um cache global de deduplicação, como um cache P2P via IPFS, poderia ajudar na preservação de dados, disponibilidade e economia de recursos.
Os cabeçalhos de cache servem para informar ao cliente por quanto tempo ele pode armazenar algo em cache. Seria interessante adicionar também no lado do cliente uma camada de cache que respeitasse esses cabeçalhos.
Se o objetivo for um layout consistente, talvez também haja potencial em passar ao modelo, junto com a entrada, o resultado em Markdown da última página como exemplo (
one-shot example).Como o objetivo deste projeto é uma "view personalizada baseada em prompt", acho que pelo menos valeria a pena armazenar em cache o resultado do prompt padrão.
Achei um POC realmente excelente, e ele tem bastante semelhança com a extensão do Chrome "reader view" que eu uso no dia a dia.
link da extensão reader view
A ideia é muito legal e acho que tem grande potencial também do ponto de vista de acessibilidade.
Tenho um vídeo antigo demonstrando meu agente de IA já aposentado fazendo transformação em tempo real de páginas web.
Demo transformando o HN em My Little Pony (vídeo)
Dá para ver o resultado mais ou menos a partir de 37 segundos.
Também deixei pronta uma extensão open source para Chrome; se tiver curiosidade, veja o ChromeGPT.
spegel -p "extract only the product reviews" > REVIEWS.mdSe tivesse só essa opção, já me viriam várias ideias de uso, mas parece que ainda não existe.