HTML para Markdown: O que os benchmarks esquecem

Um olhar sobre o que realmente sobrevive

TL/DR: Reduzir HTML a markdown simples é amplamente descrito como uma redução de tokens em cerca de 80%, ou aproximadamente 5x. Em dez páginas que medi, as reduções variaram de 1,4x a 734x. As maiores reduções não eram páginas densamente empacotadas. Eram páginas que estavam sem seus preços, especificações e valores de comparação. Classificar as melhores seções em relação à pergunta, em vez de enviar a página inteira, não resolveu o problema.

O problema, em termos simples

Quando um agente de IA lê uma página da web, ele lê tudo. Cada palavra custa dinheiro. Tokens são a unidade em que sua conta de modelo é medida, e um token é aproximadamente três quartos de uma palavra.

Uma página da web moderna é em sua maioria não palavras. É marcação, scripts, estilos e dados ocultos que o navegador usa para montar o que você vê. Enviar tudo isso para um modelo e você paga por tudo isso.

A solução padrão é reduzir a página apenas ao texto, em um formato simples chamado markdown. Quase todas as ferramentas que fazem isso relatam um resultado semelhante. A Cloudflare cita um post de blog que foi de 16.180 tokens para 3.150, uma redução de 80%. Os atores da Apify anunciam 60 a 77%. Ferramentas de código aberto relatam cerca de 80%. Os números se agrupam de forma suficientemente próxima que "cerca de 5x" se tornou a suposição de trabalho.

Eu me propus a testar algo diferente: em vez de enviar a página limpa inteira, e se você classificasse as seções em relação à pergunta feita e enviasse apenas as melhores? Essa abordagem tem um nome em uso atual, engenharia de contexto, e a ideia é que menos, mas melhor conteúdo escolhido, supera mais.

Eu queria saber se isso superava 5x o suficiente para valer a pena construir. Não superou. Mas a razão me surpreendeu, e acabou sendo mais importante do que o recurso que eu estava testando.

Como as dez páginas foram testadas

Escolhi páginas para variedade em vez de conveniência: uma página de documentação, uma página de preços de SaaS, um artigo de notícias, uma lista de produtos, um artigo da Wikipedia, um README do GitHub, uma página de produto, uma receita, um ensaio de Paul Graham (HTML escrito à mão com quase nenhuma desordem) e meu próprio site.

Para cada página, escrevi uma pergunta primeiro, antes de executar qualquer coisa, e a formulei da maneira que um estranho faria. Se uma página tinha um título chamado "Compatibilidade", minha pergunta era "posso executar isso dentro do Cursor", não "qual é a compatibilidade". Reutilizar as próprias palavras de uma página faz com que os resultados pareçam melhores do que realmente são.

Eu também escrevi a resposta correta e qual seção a continha, lendo as páginas completas eu mesmo, antes de qualquer código ser executado. Essa é a chave de resposta.

Para a etapa de conversão, usei trafilatura, um extrator de código aberto amplamente utilizado. Para deixar claro o que isso é e o que não é: eu medi essa ferramenta nessas páginas. Não testei o conversor da Cloudflare, ou de qualquer fornecedor, e nada aqui deve ser lido como uma medição de um.

Descoberta um: a linha de base de 5x não apareceu

O valor médio é 62x. A faixa varia de 1,4x a 734x, uma diferença de mais de 500 para 1.

A familiar figura de 4x a 5x não aparece em nenhuma parte desta lista. O mais próximo é a documentação do Python a 4,3x, e isso é mais próximo porque é a página mais antiquada do conjunto: HTML simples, muito pouco código de framework.

O ensaio na parte inferior explica o padrão. Paul Graham escreve seu HTML à mão, então há quase nada para remover e a conversão ajuda muito pouco. As páginas no topo são aplicações modernas em JavaScript onde a maior parte do download são dados ocultos. Remova isso e o número parece enorme.

Nenhum dos números publicados está errado, exatamente. Eles são medições das páginas que alguém escolheu, e essas eram principalmente páginas de artigos limpos de sistemas de publicação limpos. O número simplesmente não se generaliza, e está sendo citado como se o fizesse.

Descoberta dois: as maiores reduções foram exclusão, não compressão

Olhe novamente para a linha do Sentry. 542.996 tokens reduzidos para 740.

A página de preços do Sentry tem um gráfico de comparação de planos. Após a conversão, esse gráfico sobrevive como cerca de trinta rótulos de linha simples. "SSO: SAML2" e assim por diante. Nenhum valor. As marcas de verificação que mostram qual plano inclui qual recurso são desenhadas como imagens, e imagens não são texto, então elas desapareceram. O nível Enterprise não aparece de forma alguma.

740 tokens não é uma página de preços comprimida. É uma página de preços com o preço removido.

A página do produto ThermoWorks falha de forma mais silenciosa. Uma redução de 580x, e o preço do produto não aparece em nenhum lugar na saída, porque o site o preenche com JavaScript após a página ser carregada. Nada travou. A ferramenta funcionou bem e produziu um texto limpo e legível sobre um termômetro de cozinha que custa um valor desconhecido.

Meu próprio site: 10,3x, e toda a tabela de preços está faltando. Eu escrevi essa página. Eu não tinha ideia.

A lista de produtos do Tom's Guide foi a que chamou minha atenção. Cada bloco de "Especificações" e "Razões para comprar" se converte em um cabeçalho vazio. Então, quando perguntei qual laptop eu deveria pegar se quisesse trocar peças depois, a seção mais bem classificada voltou com uma recomendação confiante e nenhum número nela. Meu próprio script de teste marcou isso como um sucesso, porque o nome do produto correto estava lá. Era a resposta correta com todas as evidências removidas.

A falha não é a que eu esperava

Ao entrar, eu esperava um problema diferente: número mantido, rótulo de aviso removido. Meu site mostra um grande valor em dólares para a economia total de tokens, sentado bem ao lado de um texto explicando que os tokens são contados enquanto os dólares são estimados. Eu assumi que a conversão manteria a figura impressionante e descartaria a advertência.

Não manteve. A advertência está a 116 caracteres após o número, então eles viajam juntos não importa como eu cortei a página. Tentei tamanhos de bloco de 1500 caracteres até 300 e não consegui separá-los. Isso é sorte sobre como aquele bloco particular está escrito, não evidência de que o método é seguro.

A verdadeira falha corre na outra direção: o número é descartado e a prosa permanece!

Isso é muito mais difícil de pegar. A saída truncada parece truncada. Isso parece finalizado. Você obtém um texto suave, confiante e bem organizado com as quantidades faltando silenciosamente, e nada em lugar algum sinaliza a perda. Um agente lendo isso não pode dizer que está respondendo a partir de um resumo sem evidências nele.

Descoberta três: classificar as melhores seções não salvou

Esse foi o recurso que eu realmente me propus a testar. Classifique as seções em relação à pergunta, retorne apenas as melhores, pule o resto.

Contra HTML bruto, os números parecem espetaculares, até 1.440x. Mas qualquer produto real converte a página primeiro, então a pergunta justa é o que a classificação adiciona além da conversão. Abaixo, "k" é quantas seções você envia de volta, e "recall" é quão frequentemente a resposta correta estava realmente nelas.