Pipeline de Pontuação de Sinais: Triagem Determinística de Conhecimento

A maior parte da gestão de conhecimento é baseada em intuição. Você salva uma nota porque ela “parece importante”. Seis meses depois, você tem 7.000 notas e nenhuma ideia de quais delas importam. Eu construí um pipeline de pontuação determinística que me diz.

O sistema tem 733 linhas de Python. Ele pontua cada sinal recebido em quatro dimensões ponderadas, calcula uma pontuação composta e roteia o sinal para uma de 12 pastas de domínio, uma caixa de entrada para revisão manual ou o vazio. Sem categorização manual. Sem “revisar depois” que nunca acontece. O algoritmo decide.

TL;DR

Uma pontuação composta ponderada (relevância 35%, acionabilidade 30%, profundidade 20%, autoridade 15%) produz uma classificação de 0,0 a 1,0 para cada sinal. O roteamento usa três limiares: >= 0,55 grava automaticamente em uma pasta de domínio, >= 0,30 enfileira para revisão manual, < 0,30 descarta silenciosamente. Mais de 7.700 notas processadas ao longo de 14 meses, com Desenvolvimento (2.837) e Design (1.709) dominando a distribuição. Falha mais interessante: a dimensão de profundidade mede riqueza de metadados, não qualidade de conteúdo — então um tweet bem tagueado sobre uma foto de flor pontua 0,85.

O Problema da Intuição

Eu uso o Obsidian como base de conhecimento. Sinais chegam de feeds RSS, favoritos do Twitter, estrelas do GitHub, newsletters e captura manual. Antes do pipeline, todo sinal ia para uma única pasta de caixa de entrada. Uma caixa de entrada com mais de 400 notas não processadas se acumulou em dois meses.

O conselho padrão (“revise semanalmente, categorize conforme avança, use um sistema de pastas”) assume que a revisão aconteça. Ela não acontece. Caixas de entrada se tornam somente-escrita: itens entram, mas nunca saem. Conhecimento que você capturou é funcionalmente idêntico a conhecimento que você nunca capturou. Clay Shirky enquadrou o problema com precisão: “Não é sobrecarga de informação. É falha de filtragem.”⁸

Eu precisava de um sistema capaz de avaliar mais de 7.700 notas mais rápido do que eu consigo lê-las, usando critérios que defino uma vez e aplico uniformemente. Não um motor de recomendação. Um algoritmo de pontuação.

A Pontuação Composta

A fórmula de pontuação é uma combinação linear ponderada de quatro dimensões, uma abordagem padrão em análise de decisão multicritério (MCDA):⁹

composite = (
    relevance     * 0.35 +
    actionability * 0.30 +
    depth         * 0.20 +
    authority     * 0.15
)

Cada dimensão produz um float entre 0,0 e 1,0. A fórmula arredonda a pontuação composta para três casas decimais. Os pesos refletem uma ordem de prioridade deliberada: o que importa para mim (relevância) supera o que eu posso usar (acionabilidade), que supera quão ricos são os metadados (profundidade), que supera quão confiável é a fonte (autoridade).¹

As Quatro Dimensões

Relevância (35%): Correspondência de Interesses

A relevância usa um dicionário de palavras-chave curado manualmente com mais de 40 entradas, cada uma pontuada de 0,15 (nft) a 1,0 (claude code, swiftui). A pontuação combina a melhor correspondência com a média de todas as correspondências:

# 60% best match, 40% average of all matches
return min(1.0, best_score * 0.6 + avg_score * 0.4)

Itens sem correspondência recebem uma linha de base de 0,25, não 0,0. O sistema penaliza um tópico desconhecido de forma menos severa do que um irrelevante. A linha de base é o parâmetro mais frequentemente ajustado: alto demais e conteúdo irrelevante inunda a caixa de entrada, baixo demais e interesses genuinamente novos são filtrados antes que eu os veja.²

Acionabilidade (30%): Potencial de Aprendizado

A acionabilidade faz correspondência contra 22 palavras-chave orientadas a ação: tutorial, guide, how-to, build, github.com. URLs recebem tratamento especial:

if "github.com" in url:
    hits += 2  # Repositories are inherently actionable
if "/docs" in url or "/tutorial" in url:
    hits += 1

A pontuação é baseada em função degrau, não linear: 0 correspondências → 0,10, 1 correspondência → 0,40, 2 correspondências → 0,60, 3+ correspondências → min(1.0, 0.70 + hits * 0.05). A função degrau recompensa a presença de sinais de acionabilidade mais do que sua quantidade. Um link de tutorial vale mais do que a diferença entre três e quatro palavras-chave.³

Profundidade (20%): Riqueza de Metadados

A profundidade é puramente estrutural. Ela mede a presença e comprimento dos campos, não a qualidade do conteúdo:

Profundidade é a dimensão em que eu menos confio. Um tweet sobre uma foto de flor com descrição completa e quatro tags pontua profundidade 0,85. Metadados ricos, conteúdo irrelevante. A profundidade funciona como proxy para “a fonte forneceu dados estruturados”, o que se correlaciona com, mas não garante, qualidade.⁴

Autoridade (15%): Credibilidade da Fonte

A autoridade começa com uma linha de base de 0,40 e se ajusta por tipo de fonte:

if source in ("twitter", "x"):        score = 0.50
elif source in ("blog", "newsletter"): score = 0.60
elif source in ("github", "docs"):     score = 0.70

Uma lista de domínios permitidos sobrescreve para cima (nunca para baixo): github.com, anthropic.com, apple.com, arxiv.org, docs.python.org e outros definem a autoridade em pelo menos 0,75. A lista codifica um julgamento de que essas fontes merecem maior confiança por padrão.

Roteamento por Limiares

Três faixas de roteamento determinam o que acontece com cada sinal pontuado:

THRESHOLD_AUTO_WRITE = 0.55   # → domain folder
THRESHOLD_INBOX      = 0.30   # → 00-Inbox (manual review)
# Below 0.30 → silently skipped

O pipeline grava sinais com pontuação >= 0,55 diretamente em uma das 12 pastas de domínio, inferidas a partir de correspondência de tags e títulos. Sinais na faixa intermediária (0,30-0,55) vão para uma caixa de entrada para revisão manual. Qualquer coisa abaixo de 0,30 nunca chega ao vault.

A faixa 0,30-0,55 é a “zona ambígua” onde o sistema tem menos confiança. Uma flag opcional --llm-triage envia esses sinais para o Claude para avaliação, que pode ajustar a pontuação composta em até ±0,20, potencialmente movendo um sinal para além do limiar de gravação automática. O Claude vê apenas sinais ambíguos, nunca os de pontuação alta ou baixa. Gastar tokens de API em sinais que o classificador determinístico já resolveu seria desperdício.⁵

A inferência de domínio usa um sistema de votação. Cada tag mapeia para um domínio, cada palavra-chave no título adiciona um voto. O domínio com mais votos vence. Empates são resolvidos pela ordenação do dicionário (efetivamente arbitrário). Fallback padrão: “Inspiration.”

Os Resultados

Após mais de 7.700 notas processadas ao longo de 14 meses:

A distribuição reflete a realidade. Eu consumo mais conteúdo de desenvolvimento e design do que qualquer outra coisa. Itens da caixa de entrada (420) representam a zona ambígua — sinais que o algoritmo não conseguiu rotear automaticamente com confiança.⁶

O Que o Algoritmo Errou

A Armadilha da Profundidade

Um tweet sobre uma foto de nemophila pontuou composite 0.36, relevance 0.25, actionability 0.10, depth 0.85, authority 0.50. Foi roteado para a caixa de entrada porque profundidade (0,85) e autoridade (0,50) compensaram relevância e acionabilidade quase nulas. Metadados ricos, conteúdo irrelevante: uma foto bonita de flores.

O exemplo ilustra a limitação fundamental da pontuação por proxy de metadados. A profundidade mede “a fonte forneceu dados estruturados”, não “o conteúdo é valioso”. O Twitter fornece descrições completas e tags para cada tweet. Um tweet bem tagueado sobre café da manhã pontua profundidade 0,85. Pesquisas em recuperação de informação chamam a tensão subjacente de trade-off precisão/revocação: otimizar para revocação (capturar tudo que é relevante) inevitavelmente admite falsos positivos.¹⁰

A correção que considerei e rejeitei: Reduzir o peso da profundidade de 0,20 para 0,10 reduziria falsos positivos de conteúdo irrelevante bem tagueado, mas também penalizaria conteúdo genuinamente profundo de fontes com metadados escassos. O peso atual é um compromisso.

O Problema da Linha de Base de Relevância

Uma linha de base de 0,25 para relevância sem correspondência significa que qualquer sinal bem estruturado de uma fonte razoável pontua pelo menos 0,30 e cai na caixa de entrada. A linha de base cria um piso de falsos positivos: a caixa de entrada acumula sinais que são bem tagueados e de fontes razoáveis, mas não têm nada a ver com meus interesses.

A correção real: A revisão periódica da caixa de entrada continua sendo necessária. O pipeline reduz a superfície de revisão de 7.700 itens para 420 (uma redução de ~95%), mas não consegue eliminar a revisão manual para a zona ambígua.

Notas de Implementação

O pipeline roda como uma ferramenta CLI. A entrada é um array JSON de sinais (de RSS, API do Twitter ou entrada manual). A saída são arquivos markdown compatíveis com Obsidian gravados em pastas de domínio.

python triage.py --input signals.json --vault ~/obsidian-signals/
python triage.py --input signals.json --vault ~/obsidian-signals/ --llm-triage
python triage.py --input signals.json --min-score 0.60  # Stricter routing

A pré-filtragem roda antes da pontuação: deduplicação de URL contra notas existentes no vault, filtragem de conteúdo vazio e uma lista de bloqueio de fontes ruidosas. Notas duplicadas e fontes de spam nunca chegam à etapa de pontuação.

As funções de pontuação são puras: sem efeitos colaterais, sem chamadas de API, sem acesso ao sistema de arquivos. Cada função recebe um dicionário de sinal e retorna um dicionário de pontuações. A abordagem pura as torna testáveis isoladamente e combináveis com o estágio de triagem por LLM, que roda apenas no subconjunto ambíguo.⁷

Principais Conclusões

Para engenheiros construindo sistemas de triagem:

• Pontuação determinística supera curadoria manual em escala. 7.700 notas em 14 meses. A triagem manual teria exigido mais de 50 horas de revisão. O pipeline as processou em minutos com uma taxa de roteamento de ~95% (apenas 5,5% exigiu revisão manual).

• Proxies de metadados têm modos de falha conhecidos. Profundidade mede estrutura, não qualidade. Autoridade mede fonte, não precisão. Ambos os proxies funcionam em escala agregada, mas produzem falsos positivos previsíveis no nível do sinal individual. Reconhecer os modos de falha é mais honesto do que afirmar que o algoritmo “funciona”.

Para praticantes de gestão de conhecimento:

• Pontuações compostas ponderadas expõem suas prioridades reais. Pesos de 35/30/20/15 não são arbitrários. Eles codificam um julgamento específico: relevância importa mais que acionabilidade, que importa mais que riqueza de metadados, que importa mais que credibilidade da fonte. Tornar os pesos explícitos e ajustáveis é a diferença entre um sistema e um hábito.

• A zona ambígua é irredutível. Sinais entre 0,30 e 0,55 são genuinamente ambíguos: o classificador determinístico não consegue resolvê-los. A triagem por LLM ajuda, mas não elimina a zona. A revisão manual do subconjunto ambíguo continua sendo necessária.

Eu enquadrei este artigo como um problema de engenharia, não como uma dica de produtividade. Pontuação composta se aplica a qualquer domínio onde itens precisam de roteamento determinístico: tickets de suporte, moderação de conteúdo, qualificação de leads, detecção de anomalias. Meus pesos e limiares específicos codificam prioridades pessoais, mas a arquitetura é genérica. Para mais sobre como conhecimento acumulado cria valor não linear, veja Juros Compostos Mentais. Loop OODA para Engenharia de Prompts explora um padrão relacionado: observação estruturada como alternativa à intuição. Cada componente do pipeline (pontuação, roteamento, triagem) é independentemente útil e se compõe com os outros, seguindo o padrão de engenharia composta.