Modelo de Risco de Crédito

O que Modelo de Risco de Crédito faz?

Levantamento de Modelagem

Portão rígido: a primeira resposta após esta habilidade ser acionada deve esclarecer a solicitação de modelagem antes de qualquer modelagem, seleção de recursos, ajuste ou geração de relatório. Não pule este levantamento porque o usuário deu uma tarefa de modelagem ampla. Comece com um bloco de perguntas conciso cobrindo cada item abaixo; se o usuário já especificou um item, repita-o como confirmação e peça apenas correção. Não treine ou finalize suposições até que o usuário responda, a menos que o usuário diga explicitamente para prosseguir com os padrões após ver o bloco de levantamento.

1. Objetivo da modelagem:
   • Rejeitar ou classificar maus clientes / candidatos de alto risco.
   • Selecionar bons clientes / candidatos de alta qualidade.
   • Precificar risco, definir linha de crédito, prioridade de cobrança, revisão de fraude ou outro objetivo.
   • Definir a saída do modelo: probabilidade, pontuação, nota, ponto de corte, ranking ou estratégia de política.
2. Família de modelos:
   • Scorecard / regressão logística WOE.
   • LightGBM.
   • XGBoost.
   • Regressão linear/logística sem scorecard.
   • CatBoost, random forest, rede neural, modelo de sobrevivência/vintage ou outro modelo.
   • Múltiplos modelos para comparação campeão/desafiador.
3. Valor Y:
   • Se o usuário der um alvo claro, use-o.
   • Caso contrário, sugira opções com base no objetivo de negócio, rótulos disponíveis, vintage, taxa de inadimplência acumulada (overdue roll rate), janela MOB e lógica de rejeição/exclusão.
   • Confirme a direção do valor alvo: 1 = evento de risco / mau a menos que o usuário diga o contrário.
4. Divisão da amostra:
   • OOT padrão para o mês completo mais próximo/mais recente.
   • A validação pode ser um mês próximo ou uma divisão aleatória estratificada dos dados não-OOT.
   • Confirme se o treinamento exclui validação e OOT.
   • Se existir um campo de instituição/canal, pergunte se uma amostra OOS de instituição/canal é necessária além do OOT de tempo.
5. Ajuste de parâmetros:
   • Pergunte se deve executar apenas uma linha de base padrão, ajuste leve ou busca de hiperparâmetros mais profunda.
   • Para scorecards, padrão de no máximo 15 recursos do modelo, no máximo 7 bins por recurso, base_score = 600, odds = 0,05, pdo = 60.
   • Para LightGBM/XGBoost, use hiperparâmetros iniciais comuns e ajuste somente após o diagnóstico de primeira passagem.
6. Recursos derivados:
   • Pergunte se deve adicionar recursos derivados.
   • Se sim, pergunte se combinações WOE e recursos de combinação de árvore de decisão são aceitáveis, ou se apenas fórmulas brutas implantáveis são permitidas.
7. Relatório e restrições:
   • Pergunte se o usuário tem um modelo de relatório. Se sim, corresponda a ele; se não, use o relatório de validação de risco de crédito padrão.
   • Pergunte apenas se ambíguo: o idioma do relatório final deve seguir o idioma do usuário. Solicitações de usuários chineses geram relatórios e nomes de abas em chinês; solicitações de usuários de inglês geram relatórios e nomes de abas em inglês.
   • Para modelos de scorecard, confirme que o relatório de validação do modelo deve usar o formato exato do modelo de relatório de validação de desenvolvimento de modelo de scorecard, a menos que o usuário solicite explicitamente outro modelo.
   • Pergunte sobre quaisquer variáveis obrigatórias, variáveis proibidas, restrições de política, restrições de monotonicidade, faixas de pontuação, metas de taxa de aprovação ou limitações de implantação.
8. Estratégia pós-modelagem:
   • Após a conclusão da validação do modelo, pergunte se o usuário precisa de sugestões de estratégia, tabelas de ponto de corte ou regras de política.
   • Se sim, produza candidatos a estratégia a partir de faixas de pontuação, classificação de risco do modelo e regras de recursos derivados de alto lift.

Fluxo de Trabalho Principal

1. Complete o levantamento de modelagem obrigatório e documente as suposições escolhidas. Se a primeira solicitação do usuário for subespecificada, faça as perguntas de levantamento primeiro; não pule diretamente para código, exploração de dados ou treinamento de modelo.
2. Defina o alvo e o ponto de observação explicitamente: data da solicitação, janela de desempenho, definição de mau, exclusões, fonte da amostra e chave de desduplicação. Nunca infira um alvo a partir de nomes de colunas sem verificar o dicionário de dados disponível, rótulos ou instruções do usuário.
3. Se o usuário fornecer um relatório de modelo anterior, planilha de scorecard, diagrama de fluxo de desenvolvimento ou modelo de relatório, use-o como referência para nomenclatura, faixas de pontuação e formato do relatório. Para relatórios de validação de modelo de scorecard, o modelo de relatório de validação de desenvolvimento de modelo de scorecard é o formato padrão obrigatório quando disponível; corresponda exatamente a ele. Se não for fornecido, use o fluxo de trabalho de desenvolvimento de risco de crédito padrão e a estrutura de relatório para relatórios não-scorecard ou rascunhos de saídas de scorecard.
4. Separe as amostras antes da seleção de recursos:
   • Use o mês ou janela de tempo OOT especificada pelo usuário exatamente.
   • Extraia a validação da amostra não-OOT restante, estratificada pelo alvo quando a validação aleatória for solicitada.
   • Ajuste bins, codificadores, escaladores, seleção de recursos e parâmetros do modelo apenas no treinamento.
   • Mantenha o OOT intocado para validação final, não para escolha do modelo.
5. Construa uma linha de base que corresponda à família de modelos selecionada. Se o usuário disser "com base no scorecard original", analise as variáveis do scorecard original e reajuste ou pontue-as como uma linha de base bloqueada antes de adicionar recursos.
6. Treine a primeira versão do modelo com parâmetros conservadores/padrão e, em seguida, diagnostique se ele está sobreajustando, subajustando, instável ao longo do tempo, mal calibrado, sem sinal ou limitado pela qualidade dos dados.
7. Otimize com base no diagnóstico. Compare cada mudança aceita com a linha de base e o modelo atual usando primeiro o KS de validação, depois estabilidade OOT, AUC, PSI, direção dos coeficientes, correlação/VIF, calibração e capacidade de implantação.
8. Se o desempenho for excepcionalmente forte, investigue vazamento de dados antes de otimizar ou finalizar.
9. Gere um relatório final na mesma estrutura do relatório anterior, quando existir. Relate tanto o desenvolvimento quanto a validação do modelo, não apenas um despejo de métricas estilo notebook.
10. Pergunte se uma camada de estratégia é necessária após a validação do modelo. Não presuma que o relatório do modelo sozinho é o entregável final de negócio.

Idioma de Saída

• Corresponda ao idioma do usuário em documentos finais, planilhas, nomes de abas, rótulos de gráficos e resumos narrativos, a menos que eles solicitem explicitamente outro idioma.
• Se o usuário escrever em chinês, produza texto de relatório em chinês e nomes de abas em chinês. Se o usuário escrever em inglês, produza texto de relatório em inglês e nomes de abas em inglês.
• Mantenha identificadores técnicos, como nomes de variáveis brutas, nomes de arquivos, expressões SQL, nomes de modelos e abreviações de métricas, inalterados quando traduzi-los reduziria a rastreabilidade.

Disciplina de Dados e Divisão

• Trate o vazamento de tempo como o principal modo de falha. Qualquer recurso calculado após o ponto de solicitação/observação deve ser excluído ou deslocado.
• Para OOT mensal, use como padrão o mês completo disponível mais próximo/mais recente, a menos que o usuário especifique outra janela de tempo. Use meses de calendário exatos, como 2025-09, não rótulos relativos, nas saídas.
• A validação pode ser um mês/janela de tempo próximo ou uma amostra aleatória estratificada dos dados não-OOT. Prefira o modo de validação solicitado pelo usuário; caso contrário, escolha o modo que melhor corresponda ao tamanho da amostra e às necessidades de estabilidade temporal e declare a escolha.
• Antes da divisão final, marque meses anormais com muito poucas amostras totais ou muito poucas amostras ruins. Reporte-os e sua razão; não os filtre automaticamente, a menos que o usuário aprove explicitamente.
• Se existir um campo de instituição/canal, suporte OOS de instituição/canal além do OOT de tempo. Separe claramente OOT de tempo, OOS de instituição/canal, validação e treinamento nos relatórios.
• Reporte contagens de amostras de treino, validação e OOT, contagens de maus, taxas de maus, AUC, KS, PSI e distribuição de pontuação.
• Se a validação for aleatória estratificada, calcule-a após remover o OOT.
• Mantenha pontuações no nível da linha com row_id, data, split, alvo, probabilidade, logit e pontuação para que cada tabela de relatório possa ser reproduzida.

Pipeline de Limpeza Opcional

Execute um pipeline leve de limpeza de dados e triagem de variáveis antes da modelagem quando a qualidade dos dados brutos for incerta, quando o usuário solicitar pré-processamento ou quando um modelo de scorecard/logístico precisar de variáveis candidatas mais limpas. Para modelos de árvore gradient-boosted, este pipeline pode ser ignorado ou suavizado porque as árvores podem tolerar melhor dados ausentes, não linearidades e variáveis correlacionadas; ainda execute verificações de vazamento, amostra e estabilidade.

• Carregue e formate os dados sem modificar o arquivo original.
• Marque meses anormais pela contagem total de amostras e contagem de amostras ruins, mas não os descarte por padrão.
• Calcule taxas de valores ausentes/gerais; se existir um campo de instituição/canal, também calcule-as por instituição/canal.
• Remova variáveis com alta taxa de ausência apenas quando o limite for acordado ou claramente prejudicial.
• Calcule IV geral; se existir um campo de instituição/canal, também calcule IV por instituição/canal e sinalize variáveis que são fracas em muitas instituições/canais.
• Calcule PSI por mês; se existir um campo de instituição/canal, também calcule PSI mensal por instituição/canal e sinalize instabilidade concentrada.
• Opcionalmente, execute a redução de ruído por Importância Nula para identificar variáveis de ruído comparando o ganho real do LightGBM com o ganho de permutação de rótulo.
• Remova variáveis de alta correlação usando o princípio existente de "manter a melhor variável no grupo correlacionado".
• Registre cada rodada de remoção de variáveis com limite, variável removida e motivo da remoção.

Engenharia de Recursos

• Comece com os recursos brutos originais mais as variáveis de negócios necessárias, como idade da empresa / tempo de estabelecimento da empresa, quando o usuário as solicitar.
• Faça uma triagem básica da qualidade dos dados:
  • Remova recursos onde um valor domina 95%+, a menos que explicitamente exigido pelo negócio.
  • Remova variáveis inutilizáveis, instáveis, pós-resultado, duplicadas ou logicamente inválidas.
  • Preserve as variáveis de linha de base forçadas ao reproduzir um scorecard existente, mesmo que violem filtros genéricos; divulgue este bloqueio.
• Calcule tanto o IV bruto/univariado, quando útil, quanto o IV do scorecard agrupado após a agrupamento no conjunto de treino. Rotule-os separadamente; não chame o IV bruto não agrupado de IV do scorecard.
• Classifique os recursos importantes com um composto ponderado de importância LightGBM, IV e IV agrupado. Se o usuário não especificar pesos, normalize os ranks ou pontuações percentis e use um padrão equilibrado, como ganho LightGBM 0,4, IV 0,3, IV agrupado 0,3; mantenha a contagem de divisão LightGBM como diagnóstico secundário.
• Use Importância Nula como uma etapa opcional de redução de ruído para grandes conjuntos candidatos: treine um modelo de importância LightGBM real, treine um ou mais modelos de permutação de rótulo/nulos e sinalize variáveis cujo ganho real não está suficientemente acima do ganho nulo.
• Mantenha o nome do recurso original, rótulo de negócio (chinês/inglês), fórmula, recursos pais, taxa de ausência, IV, IV agrupado, AUC/KS de recurso único, ganho/divisão LightGBM, status de triagem e motivo da triagem.

Variáveis Derivadas

• Quando o usuário disser para usar os padrões, trate as variáveis derivadas como habilitadas. Gere uma ampla biblioteca de variáveis derivadas onde os dados e as restrições de implantação permitirem:
  • Aritmética bruta: diferença, razão, razão inversa, participação, diferença relativa, média, soma, min/máx, diferença absoluta.
  • Recursos de janela e tendência: razão janela curta/janela longa, média mensal, aceleração mensal, diferença recente vs. histórico.
  • Transformações: log, clipping/winsorização, percentil, indicadores de ausente/valor especial.
  • Combinações WOE: soma WOE, diferença WOE, produto WOE, WOE min/máx, diferença absoluta WOE.
  • Combinações de árvore: recursos de folha de árvore de decisão de 2 a 3 níveis ou agrupamentos de regras compactas construídos a partir de 2 a 3 variáveis fortes.
  • Interações de grupo: combinações de crédito, consulta, utilização, inadimplência, saldo e idade da empresa do mesmo grupo familiar.
• Acompanhe a capacidade de implantação de cada variável derivada. Prefira fórmulas brutas mais simples quando vários candidatos tiverem desempenho de validação/OOT semelhante, mas não exclua combinações WOE ou combinações de árvore por padrão.
• Permita que variáveis derivadas participem da triagem e seleção de modelo por padrão. Exija uma variável derivada no modelo final apenas quando ela melhorar o desempenho de validação/OOT, estabilidade ou melhorar materialmente a interpretabilidade; caso contrário, reporte que variáveis derivadas foram geradas e rejeitadas.
• Registre fórmulas derivadas em uma forma pronta para implantação usando recursos de origem, não apenas nomes de exibição gerados.
• Adicione uma tabela ou aba de auditoria de variáveis derivadas ao entregável final sempre que variáveis derivadas forem geradas, incluindo fórmula, variáveis pais, capacidade de implantação, status de triagem, IV e status de seleção final.

Parâmetros Padrão

Use esses padrões, a menos que o usuário forneça alternativas.

• Scorecard:
  • Limite de recursos: 15 ou menos variáveis finais.
  • Limite de agrupamento: 7 ou menos bins por recurso, incluindo bins de ausente/especial quando possível.
  • Escala de pontuação: base_score = 600, odds = 0,05, pdo = 60.
  • Triagem de recursos: remova variáveis com 95%+ mesmo valor, a menos que obrigatório; remova IV agrupado abaixo de 0,05, a menos que obrigatório; inspecione tendência WOE e lógica de negócio.
  • Limite de correlação: sinalize correlação absoluta acima de 0,5.
  • Multicolinearidade: use regressão logística stepwise, verificações de sinal de coeficiente e VIF.
• Linha de base LightGBM:
  • Objetivo: classificação binária, a menos que o usuário tenha escolhido regressão/ranking.
  • Parâmetros iniciais típicos: learning_rate 0,03-0,08, num_leaves 15-63, max_depth 3-7 ou irrestrito com folhas pequenas, min_data_in_leaf 100-1000 dependendo do tamanho da amostra, feature_fraction 0,7-0,9, bagging_fraction 0,7-0,9, bagging_freq 1, lambda_l1 0-5, lambda_l2 0-20, parada antecipada na validação.
• Linha de base XGBoost:
  • Parâmetros iniciais típicos: eta 0,03-0,08, max_depth 3-6, min_child_weight 20-200, subsample 0,7-0,9, colsample_bytree 0,7-0,9, gamma 0-5, reg_alpha 0-5, reg_lambda 1-20, parada antecipada na validação.
• Regressão linear/logística:
  • Padronize ou transforme recursos em WOE conforme apropriado.
  • Ajuste a força de regularização e a penalidade após verificar a estabilidade dos coeficientes e o desempenho da validação.

Agrupamento e WOE

• Ajuste os bins WOE apenas no treinamento. Aplique os mesmos limites de bin e bin ausente à validação e OOT.
• Use árvore de decisão, quantil e bordas de bin manuais/de negócio para agrupar. Prefira agrupamento de negócio para variáveis nos modelos de scorecard quando a lógica de negócio existir. A lógica de agrupamento de negócio inclui intervalos de idade, limites de utilização, níveis de índice de inadimplência,

...

[truncado para tradução]