O que é um modelo de decisão e por que ele não é um LLM?

Fala aí, beleza? Nem toda IA que decide alguma coisa é um LLM 😀

Se o teu contato com IA hoje é basicamente chatbot, é muito fácil achar que tudo é a mesma coisa

Mas em crédito, regras de negócio e processos de empresa, quem bate o martelo costuma ser um modelo de decisão, com lógica explícita, e não um gerador de texto

E a diferença é mais funda do que parece: um avalia entradas contra regras (ou contra um modelo treinado), o outro prevê o próximo token por probabilidade

Bora entender isso com calma?

O que é um modelo de decisão?

Um modelo de decisão é uma estrutura que pega entradas (inputs) e transforma isso numa saída (output) usando uma lógica explícita ou aprendida

Pensa num pedido de crédito: entra renda, posse de imóvel, meses desde o último atraso… e sai uma resposta definida, tipo aprovado ou recusado

Essa lógica pode ser escrita por gente (regras, tabelas) ou aprendida a partir de dados (árvores, scorecards, classificadores)

E tem até padrão pra isso, se liga: o DMN (Decision Model and Notation) é um padrão criado pelo Object Management Group (OMG) pra descrever e modelar decisões operacionais e regras de negócio

Ele foi pensado pra funcionar junto com BPMN e/ou CMMN, modelando as decisões que existem dentro de processos e casos

Ou seja, o BPMN desenha o fluxo e o DMN descreve, com precisão, as decisões que vivem dentro dele 🙂

A versão DMN 1.5 foi adotada formalmente pelo OMG em agosto de 2024

Quais tipos de modelo de decisão existem?

Aqui entra muita coisa diferente, desde um if bem escrito até um modelo treinado com dados

O que une tudo é a mesma ideia: entradas definidas, saída definida, lógica que dá pra inspecionar

Regras de negócio:

Regras de negócio são o formato mais direto de todos: se a condição X é verdadeira, a saída é Y

Quem escreve a lógica é uma pessoa, normalmente a partir da política da empresa

A vantagem é óbvia: você lê a regra e sabe exatamente por que aquela decisão saiu daquele jeito

Tabelas de decisão:

Uma tabela de decisão organiza regras em linhas, com três partes: entradas (inputs), saídas (outputs) e regras

Cada linha diz: quando as entradas casam com essas condições, a saída é essa

No DMN, essa lógica pode ser expressa em tabelas de decisão e avaliada com a linguagem de expressões FEEL (Friendly Enough Expression Language)

E aí vem a pergunta que todo mundo faz: e se mais de uma regra casar?

Quem resolve isso é a hit policy, que define como montar o resultado da tabela:

• Unique: só uma regra pode casar (ou nenhuma)
• First: vale a primeira regra que casa
• Any: várias podem casar, mas todas precisam dar a mesma saída
• Collect: junta as saídas de todas as regras que casam
• Rule Order: também pode devolver várias regras

Resumindo: Unique, First e Any devolvem um resultado só (no Any várias regras podem casar, mas como todas dão a mesma saída, o resultado é um só), enquanto Rule Order e Collect podem devolver várias

Na documentação da Camunda, quando nenhuma hit policy é definida, o padrão é Unique

Tome cuidado: isso é o comportamento da Camunda, não dá pra assumir que todo motor DMN faz igual

Árvores de decisão:

A árvore de decisão já é um modelo aprendido: em vez de alguém escrever as regras, o algoritmo divide os dados de treino em perguntas encadeadas

No scikit-learn, o exemplo clássico é o DecisionTreeClassifier

Ele aceita os critérios de divisão gini, entropy e log_loss

Critério de divisão? É a medida que o algoritmo usa pra escolher onde quebrar os dados a cada passo

Além disso tem parâmetros como max_depth (a profundidade máxima da árvore) e splitter, que pode ser best ou random

No fim, a lógica é a mesma das regras: entradas definidas entram, uma classe definida sai

Scorecards:

O scorecard é uma forma comum de apresentar um modelo de classificação, normalmente uma regressão logística, como pontos por variável

Cada variável soma pontos: renda, posse de imóvel, meses desde o último atraso e por aí vai

No fim, a pontuação total vira a decisão

É muiiito fácil de ler, e esse é justamente o motivo de ele existir 😀

Classificadores treinados em geral:

Classificador treinado é a categoria mais ampla: um modelo que aprende, a partir de dados, a mapear entradas para uma classe

A árvore de decisão e a regressão logística por trás do scorecard são exemplos disso

O ponto que importa aqui: a saída é sempre uma das opções definidas antes, nunca um texto livre

Como um LLM chega a uma resposta?

Agora o outro lado da história

Um LLM é autorregressivo: ele estima a distribuição de probabilidade do próximo token com base em todos os tokens anteriores, escolhe um token, coloca no fim da sequência e repete

Token? É o pedacinho de texto com que o modelo trabalha, a resposta vai sendo montada um token por vez

Por dentro, o LLM gera logits para cada token do vocabulário, e esses logits viram probabilidades via softmax

Aí a escolha do token pode usar amostragem:

• top-k: escolhe só entre os K tokens mais prováveis
• top-p: escolhe dentro do menor conjunto cuja probabilidade acumulada passa de p

Percebeu a diferença?

O LLM gera texto plausível, token a token, ele não pega entradas definidas e avalia contra uma regra

Não existe uma linha da tabela que você aponta e diz: foi por isso

Modelo de decisão x LLM: onde a lógica muda

Colocando lado a lado fica bem mais claro:

Critério	Modelo de decisão	LLM
O que entra	Inputs definidos (ex: renda, posse de imóvel)	Uma sequência de tokens
O que sai	Output definido (aprovado, recusado, uma classe, uma pontuação)	Texto gerado, token a token
Como decide	Regra, tabela de decisão ou modelo treinado	Probabilidade do próximo token
Determinismo	Regra e tabela: mesma entrada, mesma saída; árvore: treino só é reprodutível com random_state fixo	Servido por API, pode variar mesmo com temperatura 0
Auditabilidade	Dá pra apontar a regra ou os pontos que levaram à decisão	Não existe uma regra explícita pra apontar
Onde costuma ser usado	Crédito, regras de negócio, decisões dentro de processos	Tarefas de linguagem aberta

A linha de determinismo merece uma parada, porque é onde mais gente se confunde

Determinismo no treino:

No DecisionTreeClassifier, as features são permutadas aleatoriamente a cada divisão

Então a melhor divisão encontrada pode variar mesmo com os mesmos dados de treino

Quer treino reprodutível? Fixe o random_state

Caso você esqueça disso, pode treinar duas vezes e ganhar duas árvores diferentes, e aí vai passar um tempo caçando um bug que não é bug haha

Determinismo na execução:

Uma regra ou uma tabela de decisão avalia a entrada e devolve a saída que está escrita ali, a mesma entrada gera a mesma saída

Já um LLM servido por API pode dar saídas diferentes pro mesmo prompt mesmo com temperatura 0

O motivo está na infraestrutura: diferenças de aritmética de ponto flutuante e de batching

Ou seja, zerar a temperatura não transforma um LLM em tabela de decisão 😛

Por que crédito e regras de negócio ainda usam modelos interpretáveis?

Em crédito, o uso tradicional é de modelos simples e interpretáveis, como scorecards e regressão logística

E não é por falta de opção mais sofisticada não

É porque a regulação protege o consumidor de recusas baseadas em modelos caixa-preta que ninguém consegue interpretar

Aqui a diferença com o LLM fica gritante: num scorecard você mostra quais variáveis somaram quais pontos, numa tabela você mostra qual regra casou

Dá pra explicar a decisão pra quem foi recusado, pro auditor e pro time interno

Num texto gerado por probabilidade de próximo token, essa explicação não sai de graça

Modelo de decisão ou LLM: quando usar cada um?

Sem fórmula mágica, mas o critério é bem claro

Use regra, tabela ou classificador quando:

• a decisão se repete muitas vezes com a mesma lógica
• as entradas são estruturadas (campos, números, categorias)
• a saída esperada é fixa (aprovar, recusar, classificar, pontuar)
• alguém vai precisar auditar e explicar o porquê

Use um LLM quando:

• a tarefa é de linguagem aberta (resumir, redigir, conversar, interpretar texto)
• não existe uma saída fixa esperada
• variação na resposta não é um problema

E os dois podem coexistir no mesmo processo, cada um fazendo o que faz de melhor

Só que aí vale pensar com calma em qual parte da decisão fica com qual peça, e se você está montando um agente, escolher qual modelo usar no agente é outra conversa importante

Também vale lembrar que nem tudo deve ir pra IA generativa, e entender quando não vale delegar tarefas ajuda a não jogar uma decisão auditável num lugar onde ela não deveria estar

Conclusão

Recapitulando: um modelo de decisão aplica lógica explícita ou aprendida sobre entradas definidas e devolve uma saída definida

Pode ser regra de negócio, tabela de decisão no DMN, árvore de decisão, scorecard ou outro classificador treinado

Um LLM é outra coisa: ele gera texto prevendo o próximo token por probabilidade, com logits, softmax e amostragem

Por isso é esse tipo de modelo que aparece quando a decisão precisa ser repetível e explicável, como em crédito

Quer sentir a diferença na prática? Pega uma tabela de decisão DMN e brinca com as hit policies, ou treina uma DecisionTreeClassifier com random_state fixo e olha as divisões que ela criou

Depois compara com a resposta de um LLM pro mesmo problema, a diferença fica muito clara =)

Até o próximo post!

Perguntas frequentes

Um modelo de decisão pode usar machine learning ou só regras fixas?

Pode ser os dois. Regras de negócio e tabelas de decisão são lógica escrita por pessoa, enquanto árvores de decisão e scorecards são modelos aprendidos a partir de dados. O que define a categoria não é como a lógica nasceu, é entrada definida virando saída definida

Por que crédito usa scorecard em vez de um modelo mais complexo?

Porque a regulação de crédito cobra interpretabilidade: o modelo não pode ser uma caixa preta que ninguém consegue explicar. O scorecard resolve isso apresentando uma regressão logística como pontos por variável, tipo renda e posse de imóvel, fácil de ler linha a linha

Dá pra reproduzir o mesmo resultado de uma árvore de decisão treinando de novo?

No DecisionTreeClassifier do scikit-learn, as features são permutadas aleatoriamente a cada divisão, então a melhor divisão pode variar mesmo com os mesmos dados. Pra garantir treino reprodutível é preciso fixar o random_state

Um LLM com temperatura 0 sempre dá a mesma resposta?

Não necessariamente. Mesmo com temperatura 0, LLMs servidos por API podem dar saídas diferentes pro mesmo prompt, por causa de ponto flutuante e batching na infraestrutura. Isso é bem diferente de uma tabela de decisão, onde a mesma entrada sempre bate na mesma regra

O que acontece quando mais de uma regra de uma tabela de decisão casa ao mesmo tempo?

Depende da hit policy configurada. Unique só permite uma regra casar, First pega a primeira que casa, Any exige que todas deem a mesma saída, e Collect junta as saídas de todas. Na Camunda, quando nenhuma hit policy é definida, o padrão usado é Unique

DMN substitui o BPMN?

Não, eles trabalham juntos. O DMN foi pensado pra funcionar junto com BPMN e/ou CMMN, descrevendo com precisão as decisões que existem dentro de processos e casos. O BPMN cuida do fluxo, o DMN cuida da lógica da decisão