Dezessete Mil Sinais

Meu vault do Obsidian contém 17.913 notas de sinais. Cada uma é um artigo de pesquisa, post de blog, aviso de segurança ou discussão de comunidade que meu scanner identificou como potencialmente relevante para um dos nove tópicos que acompanho: segurança de IA, agentes LLM, Claude/Anthropic, SwiftUI/iOS, design systems, creative coding, pesquisa em ML, ciência e segurança. Essa é a camada operacional do que chamo de infraestrutura de gosto — a ideia de que julgamento estético e editorial precisa ser codificado em sistemas, não aplicado de forma improvisada.

Desses 17.913 sinais, li talvez 200 com atenção. Outros 500 influenciaram uma decisão, um post de blog ou uma escolha de design. Os 17.213 restantes são ruído que escaneei, pontuei e arquivei sem agir.

O ruído não é desperdício. O ruído é o instrumento.

O Problema da Pontuação

Cada sinal recebe uma pontuação composta de 0 a 1, ponderada em quatro dimensões: relevância (corresponde aos meus tópicos), acionabilidade (posso fazer algo com isso), profundidade (tem substância) e autoridade (a fonte é confiável). Sinais com pontuação acima de 0,55 são escritos nas pastas de domínio. Sinais entre 0,40 e 0,55 vão para a inbox. Abaixo de 0,40, são ignorados.

Os limites são calibrados, não escolhidos. Eles surgiram de meses de escaneamento, revisando o que caiu em cada categoria e ajustando até que a relação sinal-ruído parecesse adequada. 0,55 era alto demais inicialmente (perdia artigos que se mostraram importantes). 0,30 era baixo demais (a inbox enchia de lixo). Os limites atuais produzem aproximadamente 15-30 escritas de domínio e 10-20 itens de inbox por escaneamento em todos os tópicos.

O sistema de pontuação tem vieses que eu entendo:

Artigos de pesquisa começam com autoridade 0,75. Um artigo do arXiv com categoria e palavras-chave correspondentes pontua 0,75 antes de qualquer avaliação de conteúdo. Isso é deliberado: pesquisa revisada por pares de campos relevantes tem credibilidade de base que posts de blog e discussões do HN não têm.

Avisos de segurança começam com autoridade 0,95. Um CVE do NVD ou um GHSA do GitHub pontua alto independentemente do conteúdo, porque a existência de um aviso de vulnerabilidade já é o sinal. O conteúdo é secundário em relação ao fato.

Discussões do HN começam com autoridade 0,55. Discussões de comunidade são valiosas para sentimento e descoberta, mas pouco confiáveis para fatos. Uma história com muitos pontos no HN sobre um novo artigo é um mecanismo de descoberta, não uma fonte. O artigo em si é a fonte.

Essas bases codificam meu julgamento sobre confiabilidade de fontes. Uma pessoa diferente com prioridades diferentes definiria bases diferentes. As bases não são verdade objetiva. São uma opinião codificada sobre de onde vem a confiança. A metodologia completa de pontuação está documentada no meu pipeline de pontuação de sinais.

O Que o Ruído Ensina

A maioria dos escaneamentos produz 80-100 escritas de domínio e 20-40 itens de inbox. A maior parte é ruído: artigos que nunca vou ler, avisos para software que não uso, discussões sobre tópicos que acompanho mas sobre os quais não atuo.

O ruído ensina três coisas:

A forma do campo. Quando escaneamentos de ai-safety consistentemente retornam artigos sobre interpretabilidade mecanicista e RLHF, isso me diz onde a comunidade de pesquisa está focada. Quando escaneamentos de llm-agents de repente produzem cinco artigos sobre revisão de código por agentes em uma semana, isso me diz que uma tendência está se formando. Os artigos individuais podem ser ruído. A distribuição de frequência é sinal.

A base para surpresa. Um artigo pontuando 0,65 no tópico ai-safety é comum. Um artigo pontuando 0,91 é surpreendente. A surpresa só é significativa porque eu tenho uma base do que 0,65 representa. O ruído estabelece a base. O sinal é o desvio dessa base.

As lacunas na minha cobertura. Quando o ataque à cadeia de suprimentos do LiteLLM aconteceu, meu pipeline scan-intel o capturou via correspondência de palavras-chave no HN. O pipeline não tinha fontes de avisos de segurança (NVD, OSV, GHSA) na época. A lacuna era invisível até que um incidente caiu por ela. Expandi o pipeline para adicionar três fontes de avisos de segurança na semana seguinte. O ruído dessas novas fontes está me ensinando como é o tráfego normal de avisos. A próxima lacuna será visível mais cedo.

A Expansão

O pipeline começou com 6 fontes. Agora tem 12:

Cada fonte adicionou ruído. Cada fonte também capturou algo que as outras perderam. A vulnerabilidade de path traversal do LangChain apareceu no GHSA, mas não no HN. O artigo Claudini autoresearch apareceu no arXiv 12 horas antes de aparecer no HN. O credential stealer do LiteLLM apareceu no OSV com o identificador MAL-2026-2144 que o NVD ainda não carregava.

O sistema de dedup baseado em aliases colapsa duplicatas entre fontes. O mesmo CVE aparecendo no NVD, OSV e GHSA produz uma nota de sinal, não três. Na primeira execução ao vivo, 6 de 85 sinais de segurança foram deduplicados por alias. A taxa de dedup vai aumentar conforme as fontes amadurecem.

A Disciplina de Triagem

Dezessete mil sinais exigem uma disciplina de triagem. A minha é simples: escanear a saída, ler as pontuações altas, arquivar o resto.

Um escaneamento típico leva 3 minutos para rodar e 2 minutos para revisar. Leio cada sinal acima de 0,80 (geralmente 2-5 por escaneamento). Passo os olhos na faixa de 0,60-0,80 em busca de surpresas. Ignoro tudo abaixo de 0,60, a menos que uma palavra-chave chame minha atenção.

O escaneamento é habitual. Escaneamento matinal, escaneamento noturno. Alguns dias produzem mais de 100 escritas de domínio (quando um novo lote do arXiv é publicado). Alguns dias produzem zero (quando a janela de retrospectiva de 7 dias já foi totalmente deduplicada). A variação é normal. O hábito é constante.

Os sinais que mais importam são os que mudam o que eu construo ou escrevo. O artigo Claudini (0,83) se tornou um post de blog. O ataque à cadeia de suprimentos do LiteLLM (0,67 do HN, depois confirmado via OSV a 0,62) se tornou um post de blog e duas atualizações de citação em posts existentes. O dataset LICA (encontrado manualmente, não pelo scan-intel) se tornou um plano de engine de gosto em design. O artigo SlopCodeBench (0,77) se tornou um candidato a citação para o post sobre compound context.

A maioria dos sinais não se torna nada. Eles se arquivam silenciosamente no vault, estabelecem a base e esperam pelo dia em que um novo sinal se conecta a um antigo e produz um insight que nenhum dos dois continha sozinho.

O Vault como Memória

O vault não é uma lista de leitura. Não pretendo ler os 17.213 sinais que não li. O vault é uma memória consultável do que o campo produziu no tempo em que estive observando — uma forma de topologia do conhecimento onde a estrutura das conexões importa mais do que qualquer nó individual.

Quando escrevo um post de blog sobre segurança da cadeia de suprimentos, posso pesquisar no vault cada sinal marcado com “security” e “supply-chain” nos últimos 90 dias. A pesquisa retorna o ataque LiteLLM, o comprometimento do Trivy, o benchmark MCPTox, o ataque Clinejection e uma dúzia de CVEs afetando pacotes de infraestrutura de IA. Cada um é uma citação potencial, um ponto de dados ou um contra-argumento.

Quando planejo um novo recurso, posso pesquisar sinais relacionados ao domínio. O dataset LICA apareceu em uma execução do scan-intel como um sinal de design-systems com pontuação 0,72. Eu não o teria encontrado por busca direcionada porque não estava procurando datasets de design gráfico. O escaneamento o surfou porque as palavras-chave (“design systems”, “typography”) correspondiam. O vault fez a conexão.

Os 17.213 sinais não lidos não são esforço desperdiçado. São contexto indexado que posso consultar quando necessário. O escaneamento é barato. A indexação é automática. O valor é latente até o momento em que uma pergunta se conecta a uma resposta que foi arquivada meses atrás. Isso é compound context na prática: cada sinal depositado hoje pode se tornar a peça que faltava em uma síntese futura.

FAQ

Quais ferramentas você usa?

O scanner é um script Python personalizado (scan_intel.py, ~1.200 linhas) que busca em 12 fontes, pontua com um motor de triagem, deduplica em três camadas (URL, ID do artigo, aliases de avisos) e escreve notas em markdown para um vault do Obsidian. O vault usa Dataview para consultas. A configuração está em JSON. O estado (IDs já vistos) está em JSON com poda a cada 90 dias.

Quanto isso custa?

Zero. Todas as fontes são APIs de nível gratuito ou feeds RSS públicos. arXiv, Semantic Scholar, OSV e a API Algolia do HN não requerem autenticação. O NVD tem um nível gratuito com limites de taxa (5 requisições a cada 30 segundos). Os avisos do GitHub usam a CLI gh, que se autentica via sua sessão existente do GitHub.

Como você evita sobrecarga de informação?

Os limites de pontuação e a disciplina de triagem. Gasto 2 minutos por escaneamento revisando a saída. Sinais abaixo de 0,60 são arquivados sem leitura. O vault cresce, mas minha atenção não escala junto. O vault é uma memória, não uma tarefa de leitura.

Posso usar esse sistema?

A arquitetura é portável: buscar em APIs, pontuar com critérios ponderados, deduplicar, escrever em uma base de conhecimento. As fontes, palavras-chave e limites específicos são calibrados para meus interesses. Você precisaria definir seus próprios tópicos, palavras-chave e bases de autoridade. O motor de pontuação e a lógica de dedup são agnósticos de domínio. Meu guia do Obsidian cobre a arquitetura do vault e padrões de consulta em detalhes, e meu post sobre hybrid retriever explica como combino busca por palavras-chave e busca semântica nesse corpus.