Troquei LLMs por SOM e destravei a leitura de exames no Fleury

Hook

Tempo estimado de leitura: 6 min

Eu passei meses refinando prompt, encadeando chamada de GPT e me estressando pra ler pedido médico no Grupo Fleury, só pra ver a nossa precisão travar em 85%. Dava raiva. A gente pagava uma conta salgada todo mês, esperava mais de dois segundos por documento e ainda tomava erro de JSON no meio da esteira.

Aí resolvi testar uma abordagem com SOM (System One Model) e basicamente consegui destravar uma evolução de dois anos em dois dias. A gente superou a barreira dos 85% e cravou 92% de precisão na leitura dos exames, despencando o tempo de resposta e o gasto com tokens. Se o seu time ainda coloca LLM generativo pra tomar decisão simples e classificar texto tipado, vocês tão queimando dinheiro à toa.

O contexto

No Grupo Fleury, o desafio do nosso produto era bem direto na teoria e bem chato na prática: pegar o texto de pedidos médicos escaneados, quase sempre com OCR ruidoso e abreviações truncadas, e extrair as siglas exatas de cada exame do catálogo oficial.

A nossa arquitetura antiga sofria pra fazer isso. A gente rodava três chamadas GPT em fila (uma pros exames, outra pros dados do pedido e uma terceira pro local) e depois ainda jogava tudo num BERT pra tentar ligar o texto solto à sigla certa. Cada arquivo demorava quase cinco segundos no fluxo total. A gente ficava queimando dinheiro em token de saída gerando JSON, sempre no risco do modelo inventar um campo ou quebrar o parse da nossa aplicação.

Usar LLM generativo pra isso custa caro e demora. Modelo autorregressivo fica prevendo a próxima palavra pra cuspir texto livre; colocar ele pra decidir se um exame tá ou não presente no pedido é basicamente usar marreta pra apertar parafuso. E foi aí que o conceito de System One Models (SOM), que veio forte com soluções como o Jev da TypeSafe e o Microsoft-Decision-1, mudou a nossa visão.

A lógica do SOM é outra: em vez de mandar prompt e esperar geração de texto, a gente passa o texto do pedido e opções fechadas com perguntas tipadas. O modelo faz uma única passagem na rede e devolve probabilidades calibradas (seja um booleano sim/não, uma múltipla escolha ou uma régua de notas). Sem geração de texto, sem erro de formato e com a resposta pronta pra cair direto na lógica do software.

O que aconteceu

Fechamos a sala em outubro de 2026 para uma maratona de dois dias. A meta era direta: arrancar a etapa pesada de leitura de exames que dependia de GPT e colocar inferência de passagem única na veia, testando o Microsoft-Decision-1 e o Jev direto pelo OpenRouter.

A nossa primeira tentativa foi ingênua. A gente tentou jogar o catálogo completo de exames de uma vez só pro modelo avaliar todas as opções em modo exaustivo. Quando abri a planilha e calculei a projeção daquele teste bruto, quase caí da cadeira: rodar o catálogo inteiro bateria mais de dezoito mil dólares por mês na escala real da Fleury, do grupo Fleury. Deu ruim logo de cara.

Percebi na hora que precisávamos de um filtro prévio e barato antes de bater na API. Daí desenhei a estratégia do S80Y, criando uma lógica de K adaptativo que define a quantidade exata de siglas candidatas com base nas menções do próprio texto, usando uma contagem local que não gasta um único centavo de token.

Com essa abordagem de pé, disparamos 51 rodadas ao vivo contra o nosso conjunto fechado de 527 documentos de teste, misturando pedidos médicos reais pseudonimizados com entradas sintéticas bem difíceis.

Os números validaram o teste na hora. O custo mensal da etapa de exames, que antes nos custava US$ 839 na combinação de GPT com BERT, despencou para US$ 406 no S80Y. E o tempo de resposta mediano caiu de aproximadamente 2,2 segundos para 1,20 segundo por arquivo. Foi basicamente conseguir avançar dois anos de melhorias de produto em apenas dois dias de bancada, comprovando o impacto real desse novo modelo no nosso desenvolvimento de software.

O momento de virada

Eu percebi que tentar jogar todo o catálogo de exames de uma vez só pro modelo era pura burrice. O pulo do gato não era paralelizar tudo no desespero, mas sim fazer uma pré-filtragem local em milissegundos antes mesmo de encostar na rede. No pipeline S80Y, a gente basicamente conta quantas siglas têm match exato no texto bruto (o nosso nA) e calcula dinamicamente a quantidade de candidatas: K = clamp(round(12 * nA + 10), 20, 120). Se o pedido médico cita dois exames óbvios, a gente manda umas 34 perguntas; se cita dez, abre o leque. Cortamos metade dos tokens sem perder nada de contexto clínico.

E a grande sacada do Decision-1 tá na primitiva booleana, o noul. Em vez de torcer pro LLM cuspir um JSON válido e pagar caro por cada token gerado na resposta, a gente envia as perguntas em lote e recebe probabilidades calibradas em uma única passada de inferência. Token de saída custa literalmente zero.

A montagem da chamada fica super direta no endpoint do Azure Foundry, sem depender de SDK pesado:

import json
import urllib.request

def avaliar_exames(texto_pedido: str, candidatas: list[dict], url: str, api_key: str):
    questions = {
        item["sigla"]: {
            "type": "noul",
            "instructions": f"O exame {item['nome']} ({item['sigla']}) foi solicitado no pedido?",
            "criteria": {"true": "Exame explicitamente pedido.", "false": "Não mencionado ou descartado."}
        }
        for item in candidatas
    }
    payload = json.dumps({"model": "microsoft-decision-1", "state": texto_pedido, "questions": questions}).encode("utf-8")
    req = urllib.request.Request(f"{url}/providers/microsoft/v1/systemone", data=payload, headers={"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"})
    with urllib.request.urlopen(req) as resp:
        respostas = json.loads(resp.read().decode("utf-8")).get("answers", {})
    return [sigla for sigla, dados in respostas.items() if dados.get("noul", 0) >= 0.93]

Esse script envia o laudo no state e avalia as candidatas em paralelo. A engenharia de software tradicional reassume o controle: um if com limiar de 0,93 filtra as aprovações na hora, sem alucinação de formato, destravando os 92% de precisão no nosso produto.

Lições que aprendi

Depois de bater tanta cabeça com medições e rodadas de teste no produto, algumas coisas ficaram bem óbvias. Dá pra resumir a experiência em quatro pontos que teriam me poupado noites em claro se alguém tivesse me avisado antes.

Primeiro: encurtar pergunta achando que tá economizando token é cilada. Na empolgação de baratear a chamada da API, a gente tentou enxugar as descrições e deixar só o nome canônico do exame. O resultado foi um tombo feio de quase 9 pontos no F1. O modelo precisa dos sinônimos ricos e das variações clínicas ali no critério pra bater o martelo com segurança, principalmente quando a escrita médica vem cheia de abreviações.

Segundo: se a resposta cabe num conjunto fechado, usar LLM generativo é jogar dinheiro no lixo. Não tem por que pagar caro por token de saída e esperar dois ou três segundos pra receber um JSON com um valor fixo. O System One resolve isso numa passada direta, sem cobrar nada pelo retorno e entregando o dado na hora.

Terceiro: decisões em cascata ganham de paralelismo cego. No início dava vontade de disparar tudo ao mesmo tempo. Mas aprendi rápido que dividir a responsabilidade em etapas sequenciais com pré-filtros inteligentes funciona muito melhor. Você faz a triagem rápida primeiro e só aciona lógicas pesadas onde realmente existe ambiguidade.

E por último, calibração teórica não se sustenta sozinha no nosso português. O modelo pode prometer uma precisão linda nos testes gringos de benchmark, mas com termos médicos reais a distribuição muda. Congelar limiar de confiança sem rodar uma bateria de testes com dados próprios é garantia de susto em produção.

O que eu diria ao meu eu do passado

Se eu pudesse voltar alguns meses no tempo, eu bateria no meu próprio ombro e falaria: para de gastar semanas afinando prompt imenso pra resolver o que é, basicamente, uma sequência de checagens condicionais.

A gente perdeu dias preciosos tentando forçar LLM generativo a cuspir JSON perfeito em cadeias longas, criando camadas e camadas de validação só pra contornar alucinação de formato. Pô, o que a gente precisava de verdade era só de uma pontuação rápida e calibrada pra saber qual caminho seguir no fluxo do produto.

Confia mais na divisão clássica: joga a inferência probabilística rápida pro modelo System One decidir em milissegundos e deixa as regras de negócio dentro do código determinístico tradicional. O ganho real de velocidade e entrega do time não depende de aumentar o tamanho do modelo. Vem direto de simplificar o contrato da API.

Economiza neurônio. E resolve de vez.

Reflexão final

Pra mim, a engenharia de software com IA tá mudando de rota. A gente passou tempo demais forçando LLM a cuspir texto corrido quando, no fundo, só precisava de um medidor estatístico rápido e calibrado na porta de entrada.

Ver o SOM destravando nosso produto no Fleury me provou como que essa tecnologia é promissora. Dá pra cortar custo e derrubar latência sem depender de malabarismo em cima de prompt.

Como o seu time resolve triagem e classificação hoje? Vocês ainda tão brigando com tempo de resposta alto? Me conta aqui nos comentários. E se você conhece alguém na equipe que vive sofrendo com validação de JSON quebrando em produção toda semana, manda esse post pra ele. A conversa tá só começando.