Na RGS, LLMs locais reduziram a triagem de 500 tarefas de cinco dias úteis para dois

Antes de cada ciclo de planejamento na RGS, as equipes de desenvolvimento levam centenas de tarefas, e cada uma precisa ser avaliada por vários critérios de priorização. Um deles é o compliance de TI: a implementação da tarefa ajuda a cumprir os requisitos da legislação? Anastasia, responsável pela área de compliance de TI, contou no Habr como reduziu a triagem de cerca de 500 tarefas de cinco dias úteis para dois. Ela não tinha orçamento de desenvolvimento e não sabe programar: todo o pipeline foi montado com ferramentas gratuitas e roda num notebook.

Por que o filtro por palavras-chave não funcionou

O piloto envolveu dois «trens», ou seja, duas grandes frentes de desenvolvimento. Só o primeiro ciclo já gerou cerca de 500 tarefas, e a triagem tomou uma semana do único especialista. Durante todo esse tempo, parou o trabalho que justifica a existência do compliance: a análise de novos requisitos e o acompanhamento de projetos complexos. Conectar os demais trens consumiria a maior parte de um trimestre, e ampliar a equipe para atender ao pico de demanda não era possível.

A busca por palavras não funcionava: as equipes redigem as tarefas de maneiras diferentes, e o que se precisa avaliar é o sentido. Por isso, Anastasia decidiu testar a hipótese da forma mais barata possível. Ela fez uma exportação anonimizada das tarefas e entregou o material a alguns modelos externos, junto com uma instrução sobre os critérios. Depois de várias iterações do prompt, o resultado se estabilizou, mas a concordância com as avaliações dos especialistas ficou em cerca de 60%, com erros concentrados principalmente na direção da superestimação. Para começar, isso bastou: um modelo cauteloso demais descarta com segurança o que o especialista não precisa olhar.

Montagem local: n8n, Ollama e a base de avaliações validadas

A primeira versão tinha três pontos fracos: o preparo manual das exportações, a perda de sentido na anonimização e a dependência de serviços externos, que na Rússia podem deixar de funcionar. Uma solução corporativa não saiu de imediato, e Anastasia optou por um modelo local. Os dados não saem do computador, e não há necessidade de serviços externos. O preço são as limitações do notebook: as tarefas são enviadas em lotes, e modelos pesados demais travavam a máquina de vez.

O orquestrador é o n8n, um construtor visual de fluxos de trabalho. Os modelos rodaram via LM Studio e Ollama, e no fim a escolha foi o Ollama. O pipeline funciona assim: exportação das tarefas, limpeza do texto para remover lixo técnico, envio ao modelo junto com a instrução, resposta em formato estrito (nível numa escala e uma justificativa curta) e gravação do resultado.

O elemento central é a base de avaliações já validadas, usada com RAG. Ao receber uma tarefa, o modelo localiza tarefas parecidas que o especialista avaliou e se apoia nelas. Sem essa base, as primeiras versões mostravam apenas 20% de precisão. Depois de ajustes na seleção de exemplos, no prompt e no conjunto de modelos (Qwen e GPT-oss), a montagem chegou a 70–80% na amostra de teste e processava 500 tarefas em cerca de 12 horas. São aproximadamente 1,5 minuto por tarefa.

Para comparar as variantes de forma justa, Anastasia pediu a uma IA que escrevesse um programa comum. Ele confronta as avaliações de vários algoritmos com as dos especialistas e calcula quatro indicadores: acerto exato, acerto com tolerância de um degrau da escala, descarte do que é desnecessário e direção dos erros. A superestimação significa uma revisão a mais; a subestimação, o risco de deixar passar uma tarefa importante.

De 55–60% no fluxo real a 78–82%

A amostra de teste se mostrou otimista. Em tarefas reais, a primeira boa versão deu apenas 55–60%: o fluxo real traz mais formulações e sistemas novos, e parte das tarefas vem de trens que estão só começando a participar da priorização. Em seguida, Anastasia testou várias avaliações de modelos diferentes ou de um mesmo modelo com parâmetros distintos, conhecimento adicional e contexto enriquecido, inclusive via MCP. O critério de seleção era simples: se a precisão de uma variante caía quando novos trens eram conectados, ela era descartada.

As versões que sobreviveram levam mais tempo que a inicial, 12–24 horas para 500 tarefas, mas entregam 78–82% em dados reais, e os erros de superestimação e subestimação agora estão equilibrados. Em vez de um filtro para o especialista, surgiu um algoritmo que atribui os valores por conta própria, enquanto o especialista os confere quando necessário. A lógica econômica é simples: o tempo do computador custa menos que o do especialista, e quanto mais preciso o algoritmo, menos revisão manual.

O processo também mudou em abrangência. Antes, só as tarefas novas eram avaliadas manualmente, e as alteradas não eram reavaliadas por falta de tempo. Agora o algoritmo exporta sozinho as tarefas novas e as com descrição modificada antes do início da implementação, atribui as avaliações, entrega um arquivo para revisão e grava o valor do critério no campo usado para calcular a prioridade. A gravação pode ser imediata ou feita depois da revisão. Em vez de dois trens, o processo atende nove.

Limitações e próximos passos

A solução tem pontos fracos, e a autora os admite. Ela depende de um único notebook e de um único especialista, e 80% de precisão é um bom resultado para um modelo local, mas não elimina a verificação por amostragem. Anastasia pretende conferir periodicamente se a precisão não está caindo. A instância corporativa do algoritmo já funciona em modo restrito e entrega precisão comparável seis vezes mais rápido. Na avaliação de Anastasia, o que resta é remover as restrições.

Para quem trabalha com isso na prática, a conclusão é a seguinte. O esquema «ler, comparar com as regras, avaliar» serve para muitos processos operacionais. O mínimo necessário: uma base acumulada de avaliações de especialistas para o RAG, métricas que considerem a direção dos erros e testes no fluxo real, e não só numa amostra. Na RGS, um processo semelhante já está sendo lançado em modo de teste. O papel do especialista, nesse cenário, muda: ele passa a gerenciar o processo e a tomar decisões onde elas realmente são necessárias.