A tramitação do OlhoNaLei

-- coluna calculada pelo próprio Postgres
is_substantive boolean GENERATED ALWAYS AS (
  bill_type = ANY (ARRAY['PL','PLP','PEC','MPV',
    'PLV','PLN','PDL','PDC','PRC','PLC',
    'PLS','PRS','RCP'])
) STORED

O site lê só a view bill_substantive. Requerimento não ocupa a tela, não entra na fila de texto e não gasta IA.

A busca por “estepe” devolvia um projeto sobre contribuição social.

PDFs com fontes sem mapa de caracteres viram uma sopa de glifos. Passava no teste de quantidade de texto, e o vetor do lixo ficava “parecido” com qualquer busca.

if imprimiveis(texto) < 0.80:    # glifos sem mapa
    texto = ocr(pdf)                 # Tesseract
if parece_lixo(trecho):
    descartar(trecho)               # 2.785 trechos

• Batch API: responde em até 24 h, com 50% de desconto. Ninguém precisa do resumo às 3 da manhã.
• Ferramenta forçada: o modelo não conversa, só preenche o formulário: resumo, título curto, 3 a 6 pontos-chave, temas, leis citadas, jabutis e impacto fiscal.
• Uma leitura, sete saídas: o texto inteiro é pago uma vez só.

// o esquema pedia: lista de strings
"key_points":
  "<item>Cria o...</item><item>..."

# converte E conta, em vez de pular calado
pontos, coagido = _as_str_list(bruto)
if coagido:
    resumo["coerced_lists"] += 1

Três camadas de defesa tratavam o caso pulando o campo, sem avisar ninguém. O erro visível virou perda silenciosa.

Ainda acontece: de 10 a 24 vezes por lote de 150, em outubro. A diferença é que agora aparece no resumo de cada rodada.

nota = Σ peso × sinal     # sinal entre 0 e 1
     × 0,5 ^ (dias / meia_vida)

meia_vida = 243 × (1 + 2 × importância)
# de 243 a 729 dias; "dias" conta
# desde a última atividade

-- cada nota vem com a explicação
signals = {"midia_hot": 1, "importancia_llm": 0.95,
           "tipo": 1, "coautoria": 0.9, ...}

Mídia em alta: toda segunda, o Sonnet busca na web os projetos em discussão, o Haiku extrai o número de cada um, e o número só vale depois de conferido no banco ou na API.

Recall@20: dos 20 resultados da busca exata, quantos a busca rápida encontra. Medido em 60 consultas reais antes de escolher.

-- 1) 400 candidatos, distância de Hamming
SELECT chunk_id FROM bill_chunk_half
ORDER BY embedding_bin
      <~> binary_quantize(v)
LIMIT 400
-- 2) reordena os 400 pelo cosseno,
--    com o vetor em meia precisão

• Preencher a coluna nova com UPDATE: 5 linhas/s, 9 horas. Um INSERT em tabela à parte: 3.333 linhas/s.
• O assistente de IA sugeriu cortar para 512 dimensões antes de medir. Teria perdido 20% do recall.
• Índice novo construído em 100 s. Busca híbrida: 8,4 ms de mediana.

with expectativa(nome, ultimo, max_horas)
as (values
  ('news',
   (select max(published_at) from news), 6),
  ('tema-em-alta',
   (select max(discovered_at) from bill_hot),
   192),
  ...)
select nome from expectativa
 where ultimo < now()
       - make_interval(hours => max_horas)

• O limite sai do ciclo de cada coisa: horário tolera 6 h; diário, 36 a 48 h; semanal, 8 dias.
• Silêncio de 12 h por alerta: alerta que vira ruído ninguém lê.
• A consulta mora no corpo da função, não numa tabela: SQL guardado e executado com privilégio de dono é porta de injeção.

É a mesma coisa medida de três jeitos.

2,22 mi execuções × ~27 KB      ≈ 59 GB
2,22 mi execuções × ~1 s × 2 GB ≈ 1,2 mil GB·h
~70% do tempo pago = esperar banco e rede

Página lenta custa dinheiro mesmo sem fazer nada: no Fluid Compute, a memória é cobrada pelo tempo de relógio. Quando o robô sobrecarregava o banco, cada página esperava mais e custava mais.

O analytics viu 26 visualizações em 2 dias. Os logs, 45 renderizações em 4 minutos: robôs percorrendo as 16.838 URLs do sitemap. Os commits de julho diziam “ISR ligado”. Ninguém tinha conferido o cabeçalho.

A consulta do sitemap checava se existia uma linha de análise, não se havia análise nela. 26.507 linhas estavam vazias: sem resumo, sem tema, sem jabuti.

Página sem análise ganhou noindex, follow, que se desfaz sozinho quando a análise chega.

O robô publica com a chave de serviço. Nela não há usuário: is_admin() é falso, o UPDATE casa zero linhas e ninguém reclama.

O post sairia no Bluesky sem ficar registrado, e cada nova tentativa publicaria de novo. O Bluesky não tem proteção contra duplicata.

• Depois de publicar, o robô relê o banco. Se não gravou, para tudo.
• Pegar a tarefa é atômico: FOR UPDATE SKIP LOCKED, trava de 6 min, até 5 tentativas.
• Achado antes de ir ao ar, no ensaio feito de dentro do banco.