Ideia principal

Fazer uma máquina ler livros e normas e produzir notas funciona já na primeira tentativa. Essa é a parte fácil, e é a que a gente antecipa.

O que custa é o ajuste. Uma primeira versão permissiva detecta amplamente demais: muitas notas, ruído, qualidade insuficiente. A versão seguinte endurece os filtros, a qualidade fica excelente — e notas pertinentes, que a versão permissiva tinha visto, desaparecem. Nenhuma posição pega tudo o que importa sem pegar mais nada; ajustar é escolher de que lado o sistema vai errar.

Esse ajuste não se escreve em duas linhas de prompt. Ele toma a forma de várias dezenas de linhas de instruções: definição precisa de cada tipo de nota, critérios de validade, regras de detecção das referências regulatórias, passagem terminológica final.

Por que isso importa

Isso inverte a distribuição do esforço que você prevê ao começar. Você orça a extração e a revisão das notas; na prática, a extração vem pronta de saída e o orçamento tem que ir para as regras.

E isso aponta onde está o ativo. As notas se refazem; o corpo de regras que levou semanas para se estabilizar, não — é ele que você precisa versionar, comentar e defender.

Nuances e limites

O limiar certo depende do que você vai fazer com a base. Um material destinado a ser revisto todo dia tolera menos ruído do que um material consultado sob demanda, onde uma nota fraca custa apenas uma linha a mais.

E um limiar calibrado sobre um corpus de normas não se transporta como está para um corpus de artigos de opinião: o que as regras aprendem é tanto o corpus quanto o critério.

Questões em aberto

• Em que momento um endurecimento deixa de ganhar em qualidade mais do que perde em cobertura?