Key Takeaway
As consequências ficam claras antes da produção
Uma política candidata pode rodar em paralelo com a produção no mesmo tráfego e registrar o que decidiria sem afetar o cliente. O impacto em toda a carteira fica visível antes da mudança, não um trimestre depois.
Evidências, não hierarquia
Cada execução pode ser registrada na hora, sem criar um data warehouse nem esperar por um analista. As decisões das regras já são os dados, então debates sobre políticas são resolvidos com fatos, não opiniões.
Melhoria é um ciclo, não um projeto
Alterar a lógica é uma edição, não um ciclo de release, e cada mudança pode ser registrada desde a primeira execução. A próxima pergunta já encontra evidências disponíveis, e o mesmo ciclo fica pronto para continuar.
Cada gráfico neste artigo é extraído de um conjunto de dados de amostra criado para a demonstração, e não de uma carteira de empréstimos ativa. A mecânica é o produto. Os números estão aqui para mostrar a forma da mudança.
O argumento, resolvido
Todo credor tem essa reunião. A Growth diz que o nível de aprovação é muito alto e que o livro está recusando negócios que poderia ser escrito com segurança. O risco diz para provar isso. Então nada acontece durante um trimestre, porque provar isso significa uma extração de dados, um analista, uma reconstrução do modelo e uma fila.
A demonstração em nosso Página Decision Intelligence é esse argumento, resolvido.
O empréstimo é o exemplo, não o ponto. Qualquer decisão com um limiar tem este formato: um nível de desconto, uma pontuação de fraude, uma regra de encaminhamento de sinistros, uma verificação de elegibilidade, uma faixa de precificação. Troque em seu próprio domínio e a mecânica abaixo será idêntica.
A demonstração explica isso em milissegundos. Aqui está o que está por baixo dele.
Uma decisão do início ao fim
Antes de abrirmos qualquer parte, aqui está o todo o caminho que um empréstimo percorre, e funciona sempre da mesma maneira.
Chega um requerimento: alguns fatos sobre um mutuário. A regra os lê e devolve uma decisão junto com o valor. Essa decisão não é devolvida e esquecida. No momento em que é feita, tudo fica escrito: o que entrou, o que saiu, qual versão da política foi atendida e quando. Cada pedido, sempre.
Esse registro é o que transforma uma pilha de decisões pontuais em algo com o qual você pode aprender. A página Statistics lê esses registros e os desenha, para que você possa ver como as decisões foram divididas, como o dinheiro foi movimentado e o que mudou quando a política mudou.
Esse é o ciclo, e é a ideia por trás do Decision Intelligence: decidir → registrar → analisar → melhorar, e novamente. E você não precisa experimentar uma versão de cada vez. Várias políticas candidatas podem pontuar as mesmas aplicações em paralelo, cada uma registrando o que teria feito, para que você possa compará-las antes de se comprometer com qualquer uma.
O restante deste artigo segue uma volta, começando com a própria regra.
O que acontece ao mover um controle deslizante
Todo o projeto tem cinco regras. Essa é toda a lógica do empréstimo: nada escondido em um aplicativo, nada em um procedimento armazenado, nada em uma planilha no laptop de alguém.
Toda a lógica de empréstimo em uma pasta. Duas das cinco regras trazem uma segunda versão.
Entre os dois, um Decision Flow executa cinco etapas.
O fluxo na íntegra. Três regras de banda funcionam lado a lado, alimentam uma pontuação e a tabela de políticas decide.
- Derive as proporções. Um empréstimo de 210.000€ não significa nada por si só. Contra 120.000 euros de rendimento, o relação entre empréstimo e renda é de 1,75. O fluxo também calcula o maior empréstimo que ainda caberia dentro do limiar de capacidade de pagamento, que se torna a contraproposta posteriormente.
- Pontue três dimensões. Cada um dos três Decision Tables analisa uma coisa e atribui pontos: histórico de crédito, capacidade de pagamento e carga de dívida existente. Cada um é uma pequena grade que um oficial de crédito pode ler em voz alta. A tabela de capacidade de pagamento também gera uma reprovação grave se o requerente estiver excessivamente alavancado, o que representa um veto e não uma dedução.
- Adicione tudo. As três tabelas produzem uma pontuação de risco de 0 a 100. Cada solicitante recebe uma.
- Aplique a política. Uma quarta mesa pega a pontuação e a bandeira de hard fail e retorna a decisão. Este é o que importa para este artigo, então aqui está na íntegra.
Versão 1. Quatro linhas, duas colunas de entrada, duas colunas de saída.
A primeira linha é o veto: falha grave, declínio, motivo AFFORDABILITY_BREACH. A linha dois aprova qualquer coisa com pontuação de 75 ou superior. A linha três envia 55 a 74 para revisão manual. A linha quatro recusa o resto. Quatro linhas, e cada uma delas é uma frase que um empresário diria em voz alta.
5. Preço e tamanho da oferta. APPROVE recebe o valor solicitado, DECLINE recebe zero e REVIEW vai para uma pessoa com um valor sugerido que nunca excede o que o solicitante pode pagar. O pagamento mensal é calculado no APR atual, mantido em um só lugar, portanto, uma alteração na taxa equivale a uma edição.
Essa é toda a regra. Nós cobrimos design de cartão de crédito e capacidade de pagamento, preços e APR em um único fluxo em profundidade em outro lugar. Para este artigo, tudo acima é contexto. A parte interessante é o que acontece quando uma dessas quatro linhas muda.
A política muda, as evidências permanecem
De volta à reunião. O lado do crescimento quer um padrão mais baixo. Então abaixamos.
APPROVE passou de 75 para 60. REVIEW passou de 55 para 42.
Essa é a mudança. Dois números. As mesmas quatro linhas, as mesmas colunas, os mesmos códigos de razão, o mesmo veto intocado na linha um.
A diferença. Duas linhas marcadas como alteradas, duas células destacadas, todo o resto idêntico.
Aqui está o que importa mais do que a edição em si: a versão 1 não foi a lugar nenhum.
Antes de fazer a alteração, uma nova versão foi criada, então a edição chegou à versão 2. A tabela antiga ainda está lá, ainda legível, ainda em execução e ainda anexada a todas as decisões tomadas. Se um regulador perguntar em dezoito meses por que um solicitante foi recusado em maio passado, a resposta não será uma reconstrução da memória ou uma culpa git em um arquivo de configuração. A tabela exata que fez a chamada ainda existe, assim como o log da chamada.
Por que a versão antiga continua em execução
Se a versão 2 é a melhoria, por que a versão 1 ainda está em execução e preenchendo os logs?
Porque você escolheu mantê-lo lá. Você poderia apontar a produção para a "versão mais recente" e deixar que cada nova versão assumisse automaticamente. Aqui você deliberadamente não faz isso: você fixa a produção na versão 1 e a mantém no comando para que a mudança permaneça sob seu controle até que você veja o que a versão 2 realmente faz. A versão 2 é executada nos mesmos aplicativos e registra silenciosamente o que teria sido decidido. Nenhum cliente vê isso, nenhum dinheiro é movimentado por causa disso. Isso é Teste A/B em risco de crédito, execute a população viva sem expô-la.
Então você compara os dois logs. Se a versão 2 persistir, você muda e a versão 1 para. Caso contrário, você descobriu o preço de algum armazenamento, em vez de um quarto dos empréstimos inadimplentes.
Uma diferença intencional
Existe uma versão 1 e uma versão 2 do fluxo também. Se você colocá-los lado a lado, encontrará exatamente uma diferença: o nó que chama a política está fixado à política v1 em um e à política v2 no outro.
Uma variável. Mesmo alias, mesma estratégia, mesmo nome de saída, versão fixada diferente.
Todo o resto é compartilhado. As mesmas proporções, as mesmas três tabelas de pontuação…
Isso é deliberado e é a diferença entre uma demonstração e um experimento. Quando as mesmas aplicações passam pelos dois fluxos e os gráficos divergem, existe exatamente uma explicação candidata, porque existe exatamente uma diferença. Ninguém na sala pode argumentar que as faixas de crédito mudaram ou que alguém alterou discretamente os preços entre elas.
O que Statistics mostrou
Tudo daqui sai de um só lugar: as toras.
Cada execução deixa um registro
Quando uma regra é executada com logon, DecisionRules mantém tudo. A entrada completa que chegou, a saída completa que voltou, qual versão respondeu e quando. Não é um contador, não é uma amostra. O registro.
Cada aplicativo foi registrado duas vezes, uma vez por versão, no mesmo instante.
Essa é a matéria-prima. Statistics não precisa de um warehouse, de um trabalho ETL ou de um ticket para uma equipe de análise. Ele lê os logs que você já possui.
Três escolhas
A análise de uma regra se resume a três questões: qual regra, qual janela e qual campo.
Os dois primeiros são catadores. O terceiro é o Data Dictionary, e vale um minuto pela sua origem. Ninguém o declara e ninguém o mantém. Ele é montado a partir dos próprios logs, portanto lista os campos que apareceram genuinamente nas execuções reais, classificados em três escopos:
- Entradas: os dados que chegaram com cada chamada
- Resultados: o que a regra enviou de volta
- Metadados: os fatos técnicos da execução: versão, status, carimbo de data/hora, tempo de execução e assim por diante…
Ninguém escreveu esta lista. É montado a partir do que a regra realmente retornou.
A consequência prática: o dicionário descreve o que sua regra realmente fez, e não o que um esquema diz que deveria fazer. Se um campo parou silenciosamente de ser produzido há três semanas, ele não estará na lista, e vale a pena conhecer essa ausência.
Para esta regra, as Saídas contêm os onze campos que o fluxo monta. A página de demonstração mostra dois deles, decision e approvedAmount, porque esses são os dois sobre os quais a empresa discute. Os outros nove estão nos mesmos registros, a um clique de distância, e é assim que você responde à pergunta de acompanhamento, e não à primeira.
A comparação funciona de duas formas
Ao ativar o seletor de comparação e escolher uma segunda regra, cada gráfico será desenhado duas vezes. Existem duas situações em que você faria isso e elas respondem a perguntas diferentes.
Ambas as versões, nos mesmos dias. Esta é a execução paralela descrita acima. A versão 1 atende à produção, a versão 2 registra junto e ambas cobrem os mesmos aplicativos no mesmo período. A questão é: a nova política teria decidido de forma diferente sobre as mesmas pessoas? Como a população é literalmente idêntica, qualquer lacuna entre as linhas é a política e nada mais.
Versão antiga antes, versão nova depois. Depois de mudar, a versão 1 para e a versão 2 assume, de modo que as duas nunca aparecem no mesmo dia. Em vez disso, você compara os períodos. No gráfico abaixo, o lado primário mostra abril, quando a versão 1 ainda estava no comando e registrou 1.992 decisões sozinha. O lado da comparação mostra maio, quando a versão 2 assumiu e registrou 2.008. Duas janelas, duas versões, um gráfico, sem sobreposição em nenhum lugar.
Duas janelas, duas versões, um gráfico. As linhas nunca compartilham um dia.
Isso funciona porque cada lado da comparação carrega seu próprio intervalo de datas. A pergunta que ela responde é diferente da execução paralela. A nova política não decidiria de forma diferente, mas agora que está em vigor, está se comportando da maneira que o teste disse que se comportaria? Essa é a comparação que a maioria das equipes realmente faz, porque é ela que informa se a promessa sobreviveu ao contato com a produção.
O momento em que a nova versão entrou
Esta é a aparência de uma execução paralela quando você amplia a janela o suficiente para capturar o início dela.
Ninguém anotou isso. A linha verde começa onde a segunda versão começa.
A versão 1 estava em execução desde o início de abril. No final do mês apresentamos a versão 2 junto com ele, e a partir desse dia ambos estavam logando.
Ninguém anotou esse gráfico. Não há marcador de deploy, nenhuma nota de lançamento fixada no eixo, nenhum analista adicionando contexto após o fato. A linha verde simplesmente começa onde a segunda versão começa, porque os logs sabem quando ela começou e o gráfico desenha o que os logs dizem. A lacuna entre as linhas abre imediatamente e nunca fecha.
É isso que “auditar cada decisão” traz para você. A história da sua lógica não é um documento que alguém precise se lembrar de atualizar. Está nos dados.
A distribuição das decisões e a importância do motivo
Agora restrinja a janela para maio, para que ambas as versões cubram exatamente os mesmos dias e as mesmas aplicações cada uma.
decision é um campo de texto, então Statistics conta seus valores. Três valores, três barras, representadas duas vezes.
Mesmas aplicações, mesmas pontuações. Apenas as linhas traçadas através deles se moviam.
- DECLINE[955] → [575]
- REVIEW[729] → [540]
- APPROVE[324] → [893]
Mesmas aplicações. Mesmas pontuações, porque nada que produza uma pontuação mudou. Apenas as linhas traçadas através deles se moveram e o portfólio se reorganizou em torno das novas linhas.
A coluna REVIEW é aquela que ninguém prevê. A redução do limiar APPROVE de 75 para 60 não apenas converteu recusas em aprovações. Ele puxou uma fatia da antiga fila de revisão para aprovação direta, que é o custo de subscrição manual saindo da mesa, em vez do volume indo para o livro. Esse benefício nunca apareceria num modelo de backtest que analisasse apenas empréstimos bons e empréstimos ruins.
Agora, o mesmo gráfico mostra reasonCode. Este é o gráfico mais importante, e vale explicar o motivo.
A descoberta. A pontuação insuficiente caiu, a violação da capacidade de pagamento não mudou.
decision informa o que aconteceu. Há três valores: APPROVE, REVIEW e DECLINE. É a ação percebida pelo solicitante e o número que entra no relatório de volume.
reasonCode informa qual linha foi acionada. Isso importa porque dois solicitantes podem receber DECLINE por motivos totalmente diferentes:
-
INSUFFICIENT_SCOREsignifica que a pontuação não superou o limiar. É uma decisão de negócio negociável. Se o limiar baixar, essa pessoa pode se tornar cliente. -
AFFORDABILITY_BREACHsignifica que a pessoa não pode pagar o empréstimo. Não é uma decisão negociável, mas um limite. Nenhuma mudança de limiar deveria transformar essa pessoa em cliente.
A decisão mostra a mesma palavra, mas os significados por trás dela são opostos.
O gráfico de motivos acrescenta essa distinção. BORDERLINE acompanha REVIEW exatamente, de 729 para 540. STRONG_PROFILE acompanha APPROVE exatamente, de 324 para 893. Três dos quatro motivos não acrescentam nada ao gráfico de decisões. Todo o valor deste gráfico está no quarto: ele separa DECLINE em dois motivos sem relação entre si.
Essa separação é a descoberta. INSUFFICIENT_SCORE caiu de 580 para 200. AFFORDABILITY_BREACH permaneceu em 375 de 375. Não foi um valor próximo nem aproximado. As mesmas 375 pessoas foram recusadas pelo mesmo motivo nas duas políticas, porque o veto está na primeira linha da tabela e os limiares estão nas linhas dois e três.
Esse número resume o argumento de segurança. Flexibilizar o apetite de risco é uma decisão de negócio. Emprestar para alguém que comprovadamente não pode pagar é um problema de compliance. São questões diferentes, por isso ficam em linhas diferentes e mover uma não pode alterar a outra. Se AFFORDABILITY_BREACH tivesse caído junto com INSUFFICIENT_SCORE, o banco teria começado a emprestar para pessoas sem capacidade de pagamento e o gráfico de decisões pareceria idêntico nos dois casos.
A principal lição de design é separar o negociável do não negociável em linhas diferentes. Assim, uma parte pode avançar rapidamente sem colocar a outra em risco. O gráfico de motivos confirma se o desenho funcionou.
O dinheiro
approvedAmount é um valor numérico, então Statistics o representa ao longo do tempo em vez de contá-lo.
A média subiu quase pela metade. O chão e o teto não se moveram.
Compare a janela deste gráfico com a anterior, onde a versão 2 apareceu pela primeira vez. Esse gráfico abrange abril e maio, e a média da versão 1 é de 57.432 euros, arrastada por um mês em que a versão 2 não existia. Estreito para maio, onde ambas as versões cobriram os mesmos dias, e a média da versão 1 é de € 69.288.
Mesma regra, mesmos logs, número diferente e nenhum deles está errado. Vale a pena internalizar: o período faz parte da medição. Se você estiver comparando duas coisas, certifique-se de que a janela seja justa para ambas ou esteja medindo o calendário em vez da mudança.
Os números que não mudaram são tão informativos quanto os que mudaram. O média aumentou quase pela metade. O mínimo permaneceu em zero, então ambas as versões ainda recusam liminarmente os piores solicitantes. O máximo ficou em € 450.000, então nenhuma das versões concede um empréstimo maior do que o solicitado pelo requerente.
O banco não aumentou o teto nem baixou o piso. Ele mudou seu meio. Essa é a impressão digital de uma mudança de limiar. Se, em vez disso, o máximo tivesse mudado, saberíamos que alguém tocou nos preços e não na política.
Mais um controle no mesmo gráfico: mude a métrica de média para soma. As médias descrevem o solicitante, as somas descrevem o livro. O mesmo campo, os mesmos registros, duas reuniões diferentes. O oficial de crédito quer a média. O CFO quer a soma.
E o facto de as duas linhas correrem paralelamente dia após dia, em vez de se cruzarem e recruzarem, é em si uma constatação. Uma lacuna sistemática significa uma causa sistemática. Alguns aplicativos sortudos pareceriam ruído.
O registro completo, não apenas um campo
Cada gráfico até agora responde a uma pergunta sobre um campo. Mais cedo ou mais tarde alguém deixa de confiar no agregado e diz: mostre-me um.
O Raw Data Table não está vinculado a um campo. Mostra os registros.
Uma linha por decisão. Os gráficos são o argumento, esta é a evidência.
É aqui que os controles deslizantes no topo da página de demonstração e toda a população nos gráficos acabam sendo a mesma coisa. Encontre o aplicativo que capotou. Veja o rendimento que chegou, a pontuação que ganhou, a linha que deu certo, o valor que voltou.
Os gráficos são o argumento. A mesa é a evidência. A maioria dos argumentos sobre uma mudança de política termina no momento em que alguém coloca um registo real no ecrã.
Como levar os dados com você
Duas saídas, dependendo se você precisa do número uma vez ou para sempre.
Uma vez: exporte qualquer visualização para CSV. O download inclui um arquivo de metadados que descreve exatamente o que foi exportado, o que parece uma tarefa doméstica até que um número em um pacote de tabuleiro seja questionado seis meses depois e alguém precise dizer de onde veio.
Para sempre: o BI API exibe os mesmos logs de auditoria que a página Statistics lê, filtrados por regra, versão e data, e há um personalizado Conector Power BI construído em cima dele. Sua ferramenta de BI consulta as próprias decisões, em vez de uma planilha que alguém exportou em março e parou de atualizar em abril.
O ciclo se fecha
Isto é o que aconteceu, em ordem.
Alguém teve uma opinião sobre a limiar de aprovação. Os logs já existiam, pois cada execução foi auditada. A política tinha quatro linhas em uma tabela, portanto, alterá-la exigia uma edição e produzia uma nova versão em vez de destruir a antiga. Ambas as versões rodavam nos mesmos aplicativos, com a antiga ainda servindo a produção e a nova registrando o que teria feito. O fluxo fixava cada versão, então o experimento tinha exatamente uma variável. Statistics leu os logs e fez a diferença. A discussão foi resolvida com números em vez de antiguidade, e ninguém precisou arriscar um empréstimo para descobrir.
Então a versão 2 foi ao ar e começou a fazer login por conta própria. E a próxima pergunta já tem suas evidências aguardando.
Isso é o que Decision Intelligence significa aqui. Não um painel preso a um mecanismo de regras, mas as decisões que você já está tomando, mantidas de uma forma que você pode analisar, questionar e melhorar. Auditar, analisar, melhorar e voltar atrás.
A demonstração no Página Decision Intelligence é esta regra, em execução. Mova os controles deslizantes novamente e observe o funcionamento.
Ivan Peresta trabalha na DecisionRules, onde seu papel abrange análise de produto, serviços profissionais e suporte ao cliente. Ele participa de todo o ciclo de vida das funcionalidades do produto, desde o design inicial e pensamento de UX até testes práticos, documentação e entrega voltada ao cliente. Seu trabalho faz a ponte entre o desenvolvimento do produto e as pessoas que realmente o utilizam, seja ajudando um cliente a projetar seu sistema de regras ou garantindo que um novo recurso seja lançado com orientações claras e exemplos funcionais.