Key Takeaway
Las consecuencias quedan claras antes de la puesta en producción
Una política candidata puede ejecutarse junto con la producción en el mismo tráfico, registrando lo que habría decidido sin tocar a un cliente. El efecto se ve en toda la cartera antes de comprometerse, no un trimestre después.
Evidencia, no jerarquía
Cada ejecución se registra al instante, sin crear un data warehouse ni esperar a un analista. Las decisiones de sus reglas ya son los datos, así que los debates sobre políticas se resuelven con hechos, no con opiniones.
La mejora es un bucle, no un proyecto
Cambiar la lógica es una edición, no un ciclo de lanzamiento, y cualquier cosa que envíes puede grabarse desde su primera ejecución. La siguiente pregunta ya tiene su evidencia esperando, y el mismo bucle está listo para la siguiente.
Cada gráfico de este artículo se extrae de un conjunto de datos de muestra creado para la demostración, no de una cartera de crédito real. La mecánica es el producto. Los números están aquí para mostrar la forma del cambio.
El argumento, resuelto
Cada prestamista tiene esta reunión. Growth dice que el umbral de aprobación es demasiado alto y que el libro está rechazando negocios que podría escribir con seguridad. El riesgo dice que lo demuestres. Luego no pasa nada durante un trimestre, porque demostrarlo significa una extracción de datos, un analista, una reconstrucción del modelo y una cola.
La demostración en nuestro Página de Decision Intelligence Ese argumento está resuelto.
Los préstamos son el ejemplo, no el punto. Cualquier decisión que incluya un umbral tiene esta forma: un nivel de descuento, una puntuación de fraude, una regla de enrutamiento de siniestros, una verificación de elegibilidad, una rango de precios. Cambie en su propio dominio y la mecánica siguiente es idéntica.
La demostración explica ese caso en milisegundos. Esto es lo que se encuentra debajo.
Siga una decisión
Antes de abrir cualquier parte, aquí está el Todo el camino que recorre un préstamo., y se ejecuta de la misma manera cada vez.
Llega una solicitud: algunos datos sobre un prestatario. La regla los lee y devuelve una decisión junto con el monto. Esa decisión no se devuelve ni se olvida. En el momento en que se formula, todo queda por escrito: qué entró, qué salió, qué versión de la póliza respondió y cuándo. Cada solicitud, cada vez.
Ese historial es lo que convierte un montón de decisiones puntuales en algo de lo que se puede aprender. La página Statistics lee esos registros y los representa, para que pueda ver cómo se dividieron las decisiones, cómo se movió el dinero y qué cambió cuando cambió la política.
Ese es el ciclo, y es la idea detrás de Decision Intelligence: decidir → registrar → analizar → mejorar, y vuelta otra vez. Y no es necesario que pruebe una versión a la vez. Varias políticas candidatas pueden calificar las mismas aplicaciones en paralelo, cada una registrando lo que habría hecho, de modo que pueda compararlas entre sí antes de comprometerse con alguna.
Estos mismos datos de ejecución proporcionan la base para la monitorización continua del riesgo crediticio.
El resto de este artículo sigue un recorrido por este tema, comenzando con la regla misma.
Qué se ejecuta cuando mueves un control deslizante
Todo el proyecto tiene cinco reglas. Ésa es toda la lógica de los préstamos: nada oculto en una aplicación, nada en un procedimiento almacenado, nada en una hoja de cálculo en la computadora portátil de alguien.
Toda la lógica de préstamos en una sola carpeta. Dos de las cinco reglas llevan una segunda versión.
Entre los dos, un Decision Flow recorre cinco pasos.
El flujo en su totalidad. Tres reglas de banda se ejecutan una al lado de la otra, alimentan una puntuación y la mesa de políticas decide.
- Derive las razones. Un préstamo de 210.000 euros no significa nada por sí solo. Frente a 120.000 euros de ingresos, la relación préstamo-ingresos es de 1,75. El flujo también calcula el préstamo más grande que aún encajaría dentro del límite de asequibilidad, que se convierte en la contraoferta más adelante.
- Puntuación tres dimensiones. Tres Decision Table analizan cada uno una cosa y otorgan puntos: historial crediticio, asequibilidad y carga de deuda existente. Cada uno es una pequeña cuadrícula que un analista de crédito puede leer en voz alta. La tabla de asequibilidad también plantea un hard fail si el solicitante está demasiado apalancado, lo que es un veto en lugar de una deducción.
- Súmalo. Las tres tablas producen una puntuación de riesgo de 0 a 100. Cada solicitante recibe una.
- Aplicar la política. Una cuarta mesa toma la puntuación y la bandera de fallo difícil y devuelve la decisión. Este es el que importa para este artículo, así que aquí está completo.
Versión 1. Cuatro filas, dos columnas de entrada, dos columnas de salida.
La primera fila es el veto: fracaso total, declive, razón AFFORDABILITY_BREACH. La segunda fila aprueba cualquier cosa con una puntuación de 75 o más. La fila tres envía 55 a 74 para revisión manual. La cuarta fila rechaza el resto. Cuatro filas, y cada una es una frase que un empresario diría en voz alta.
5.Precio y tamaño de la oferta. APPROVE obtiene el monto solicitado, DECLINE obtiene cero y REVIEW se dirige a una persona con un monto sugerido que nunca excede lo que el solicitante puede pagar. El pago mensual se calcula al APR actual y se mantiene en un solo lugar, por lo que un cambio de tarifa equivale a una edición.
Esa es toda la regla. Cubrimos diseño de cuadro de mando de crédito y asequibilidad, precios y APR en un solo flujo en profundidad en otros lugares. Para este artículo, todo lo anterior es contexto. Lo interesante es lo que sucede cuando cambia una de esas cuatro filas.
La política cambia, la evidencia permanece
De vuelta a la reunión. El lado del crecimiento quiere un listón más bajo. Entonces lo bajamos.
APPROVE pasó de 75 a 60. REVIEW pasó de 55 a 42.
Ese es el cambio. Dos números. Las mismas cuatro filas, las mismas columnas, los mismos códigos de motivo, el mismo veto intacto en la fila uno.
La diferencia. Dos filas marcadas como modificadas, dos celdas resaltadas, todo lo demás idéntico.
Esto es lo que importa más que la edición en sí:la versión 1 no llegó a ninguna parte.
Antes de realizar el cambio, se creó una nueva versión, por lo que la edición llegó a la versión 2. La tabla anterior todavía está allí, aún es legible, aún se ejecuta y aún se adjunta a cada decisión que tomó. Si un regulador pregunta en dieciocho meses por qué se rechazó a un solicitante en mayo pasado, la respuesta no es una reconstrucción de la memoria o una culpa de git en un archivo de configuración. La tabla exacta que realizó la llamada todavía existe, al igual que el registro de la llamada.
Por qué la versión anterior sigue ejecutándose
Si la versión 2 es la mejora, ¿por qué la versión 1 sigue ejecutándose y completando los registros?
Porque elegiste mantenerlo ahí. Puede dirigir la producción a la "última versión" y dejar que cada nueva versión se haga cargo automáticamente. Aquí no lo haces deliberadamente: fijas la producción en la versión 1 y la mantienes a cargo para que el cambio permanezca bajo tu control hasta que hayas visto lo que realmente hace la versión 2. La versión 2 se ejecuta junto con las mismas aplicaciones y registra silenciosamente lo que habría decidido. Ningún cliente lo ve, ningún dinero se mueve a causa de ello. Esto es Pruebas A/B en riesgo de crédito, corre sobre la población viva sin exponerla.
Luego comparas los dos registros. Si la versión 2 se mantiene, cambia y la versión 1 se detiene. Si no es así, se enterará por el precio de un poco de almacenamiento en lugar de una cuarta parte de los préstamos incobrables.
Una diferencia, a propósito
Hay una versión 1 y una versión 2 del fluir también. Si los coloca uno al lado del otro, encontrará exactamente una diferencia: el nodo que llama a la política está anclado a la política v1 en uno y a la política v2 en el otro.
Una variable. Mismo alias, misma estrategia, mismo nombre de salida, diferente versión fijada.
Todo lo demás se comparte. Mismos ratios, mismas tres tablas de puntuación...
Eso es deliberado y es la diferencia entre una demostración y un experimento. Cuando las mismas aplicaciones pasan por ambos flujos y los gráficos divergen, hay exactamente una explicación candidata, porque hay exactamente una diferencia. Nadie en la sala puede argumentar que las bandas de crédito se desviaron o que alguien cambió silenciosamente los precios en el medio.
Lo que nos mostró Statistics
Todo lo que hay aquí sale de un solo lugar: los troncos.
Cada carrera deja un récord
Cuando se ejecuta una regla al iniciar sesión, DecisionRules mantiene todo. La entrada completa que llegó, la salida completa que regresó, qué versión respondió y cuándo. Ni un contador, ni una muestra. El récord.
Cada aplicación se registró dos veces, una por versión, en el mismo instante.
Esa es la materia prima. Statistics no necesita un almacén, un proceso ETL ni un solicitud para un equipo de analítica. Lee los registros que ya existen.
Tres opciones
Analizar una regla se reduce a tres preguntas: qué regla, qué ventana y qué campo.
Los dos primeros son recolectores. El tercero es el Data Dictionary, y merece la pena un minuto por su procedencia. Nadie lo declara y nadie lo mantiene. Se ensambla a partir de los propios registros, por lo que enumera los campos que realmente aparecieron en ejecuciones reales, ordenados en tres ámbitos:
- Entradas: los datos que llegaron con cada llamada
- Salidas: lo que la regla devolvió
- Metadatos: los datos técnicos de la ejecución: versión, estado, marca de tiempo, tiempo de ejecución, etc.
Nadie escribió esta lista. Se ensambla a partir de lo que realmente devolvió la regla.
La consecuencia práctica: el diccionario describe lo que su regla realmente hizo, no lo que un esquema dice que debería hacer. Si un campo dejó silenciosamente de producirse hace tres semanas, no estará en la lista, y vale la pena conocer esa ausencia.
Para esta regla, Salidas contienen los once campos que reúne el flujo. La página de demostración muestra dos de ellos, decision y approvedAmount, porque esos son los dos sobre los que discute la empresa. Los otros nueve se encuentran en los mismos registros, a un clic de distancia, que es la forma de responder a la pregunta de seguimiento en lugar de a la primera.
La comparación funciona de dos maneras
Al activar el selector de comparación y elegir una segunda regla, cada gráfico se dibujará dos veces. Hay dos situaciones en las que se usaría y responden a preguntas diferentes.
Ambas versiones, mismos días. Esta es la ejecución paralela descrita anteriormente. La versión 1 sirve a la producción, la versión 2 se registra al mismo tiempo y ambas cubren las mismas aplicaciones durante el mismo período. La pregunta es: ¿la nueva política habría decidido de manera diferente sobre las mismas personas? Debido a que la población es literalmente idéntica, cualquier brecha entre líneas es la política y nada más.
Versión antigua antes, versión nueva después. Una vez que cambia, la versión 1 se detiene y la versión 2 toma el control, por lo que las dos nunca aparecen el mismo día. En su lugar, compara entre períodos. En el gráfico siguiente, la parte principal indica abril, cuando la versión 1 todavía estaba a cargo y registró 1.992 decisiones por sí sola. La comparación muestra mayo, cuando la versión 2 se hizo cargo y registró 2.008. Dos ventanas, dos versiones, un gráfico, sin superposiciones en ninguna parte.
Dos ventanas, dos versiones, un gráfico. Las líneas nunca comparten un día.
Eso funciona porque cada lado de la comparación tiene su propio rango de fechas. La pregunta que responde es diferente a la del recorrido paralelo. La nueva política no decidiría de manera diferente, pero ahora que está activa, ¿se está comportando como dijo la prueba? Esta es la comparación que la mayoría de los equipos realizan, porque es la que indica si la promesa sobrevivió al contacto con la producción.
Se se puede ver el momento en que llegó.
Así es como se ve un recorrido paralelo cuando amplías la ventana lo suficiente como para captar el inicio.
Nadie anotó esto. La línea verde comienza donde comienza la segunda versión.
La versión 1 ha estado funcionando desde principios de abril. A finales de mes presentamos la versión 2 junto con ella y desde ese día ambos iniciamos sesión.
Nadie anotó ese gráfico. No hay ningún marcador de implementación, ninguna nota de versión fijada al eje, ningún analista agrega contexto después del hecho. La línea verde simplemente comienza donde lo hace la segunda versión, porque los registros saben cuándo comenzó y el gráfico dibuja lo que dicen los registros. La brecha entre las líneas se abre inmediatamente y nunca se cierra.
Eso es lo que le ofrece "auditar cada decisión". La historia de su lógica no es un documento que alguien deba recordar actualizar. Está en los datos.
La combinación de decisiones y por qué el motivo es más importante
Ahora reduzca la ventana a mayo, de modo que ambas versiones cubran exactamente los mismos días y las mismas aplicaciones cada una.
decision es un campo de texto, por lo que Statistics cuenta sus valores. Tres valores, tres barras, representadas dos veces.
Mismas aplicaciones, mismas puntuaciones. Sólo se movían las líneas dibujadas a través de ellos.
- DECLINE[955] → [575]
- REVIEW[729] → [540]
- APPROVE[324] → [893]
Mismas aplicaciones. Mismas puntuaciones, porque nada de lo que produce una puntuación cambió. Sólo se movieron las líneas trazadas a través de ellas, y la cartera se reorganizó en torno a las nuevas líneas.
La columna REVIEW es la que nadie predice. Bajar el umbral APPROVE de 75 a 60 no sólo convirtió los rechazos en aprobaciones. Sacó una porción de la antigua cola de revisión hacia la aprobación directa, que es el costo de suscripción manual que sale del escritorio en lugar del volumen que va al libro. Ese beneficio nunca aparecería en una prueba retrospectiva de modelo que solo analizara los préstamos buenos y malos.
Ahora, el mismo gráfico muestra reasonCode. Este gráfico es más importante, y conviene explicar por qué.
El hallazgo. La puntuación insuficiente cayó, la brecha de asequibilidad no se movió en absoluto.
decision indica qué ocurrió. Hay tres valores: APPROVE, REVIEW y DECLINE. Es la acción que experimenta el solicitante y la cifra que aparece en el informe de volumen.
reasonCode indica qué fila se activó. Esto importa porque dos solicitantes pueden recibir DECLINE por motivos completamente distintos:
-
INSUFFICIENT_SCOREsignifica que no superaron el umbral. Es un criterio de negocio negociable. Si el umbral baja, esa persona puede convertirse en cliente. -
AFFORDABILITY_BREACHsignifica que no pueden pagar el crédito. No es un criterio negociable, sino un límite. Ningún cambio de umbral debería convertir a esta persona en cliente.
La decisión muestra la misma palabra, pero debajo hay significados opuestos.
El gráfico de motivos aporta esa distinción. BORDERLINE sigue exactamente a REVIEW, de 729 a 540. STRONG_PROFILE sigue exactamente a APPROVE, de 324 a 893. Tres de los cuatro motivos no añaden información al gráfico de decisiones. Todo el valor de este gráfico está en el cuarto: separa DECLINE en dos motivos que no guardan relación entre sí.
Esa separación es el hallazgo. INSUFFICIENT_SCORE bajó de 580 a 200. AFFORDABILITY_BREACH se mantuvo en 375 de 375. No fue una cifra cercana ni aproximada. Las mismas 375 personas fueron rechazadas por el mismo motivo con ambas políticas, porque el veto está en la primera fila de la tabla y los umbrales están en las filas dos y tres.
Ese número resume el argumento de seguridad. Relajar el apetito de riesgo es una decisión de negocio. Prestar a alguien que demuestra que no puede pagar es un problema de cumplimiento normativo. Son cuestiones distintas, por eso ocupan filas diferentes y mover una no puede alterar la otra. Si AFFORDABILITY_BREACH hubiera bajado junto con INSUFFICIENT_SCORE, se habría empezado a prestar a personas sin capacidad de pago y el gráfico de decisiones habría sido idéntico en ambos casos.
La principal lección de diseño es separar lo negociable de lo no negociable en filas distintas. Así es posible avanzar con rapidez en un aspecto sin poner en riesgo el otro. El gráfico de motivos confirma si el diseño funcionó.
El dinero
approvedAmount es un valor numérico, por lo que Statistics lo representa a lo largo del tiempo en lugar de contarlo.
El promedio aumentó casi a la mitad. El suelo y el techo no se movían.
La ventana de este gráfico, comparada con la anterior, donde apareció por primera vez la versión 2. Ese gráfico abarca abril y mayo, y el promedio de la versión 1 es de 57.432 euros, arrastrado por un mes en el que la versión 2 no existía en absoluto. Se limita a mayo, donde ambas versiones cubren los mismos días, y la media de la versión 1 es de 69.288 €.
Misma regla, mismos registros, número diferente y ninguno está mal. Vale la pena interiorizarlo: el rango de fechas es parte de la medición. Si está comparando dos cosas, asegúrese de que la ventana sea justa para ambas, o estará midiendo el calendario en lugar del cambio.
Las cifras que no se movieron son tan informativas como la que sí lo hizo. El promedioaumentó casi a la mitad. El mínimose mantuvo en cero, por lo que ambas versiones aún rechazan directamente a los peores solicitantes. El máximose quedó en 450.000 €, por lo que ninguna de las versiones otorga un préstamo mayor al solicitado por el solicitante.
El banco no subió su techo ni bajó su piso. Movió su centro. Ésa es la huella digital de un cambio de umbral. Si en cambio el máximo se hubiera movido, se sabría que alguien había tocado los precios en lugar de la política.
Un control más en el mismo gráfico: cambiar la métrica de promedio a suma. Los promedios describen al solicitante, las sumas describen el libro. Mismo campo, mismos registros, dos reuniones diferentes. El analista de crédito quiere el promedio. El director financiero quiere la suma.
Y el hecho de que las dos líneas corran paralelas día tras día en lugar de cruzarse y volverse a cruzar es en sí mismo el hallazgo. Una brecha sistemática significa una causa sistemática. Un puñado de aplicaciones afortunadas parecerían ruido.
Todo el registro, ni un solo campo.
Hasta ahora, cada gráfico responde a una pregunta sobre un campo. Tarde o temprano alguien deja de confiar en el agregado y dice: muéstrame uno.
El Raw Data Table no está vinculado a ningún campo. Muestra los registros.
Una fila por decisión. Los gráficos son el argumento, esta es la evidencia.
Aquí es donde los controles deslizantes en la parte superior de la página de demostración y toda la población en los gráficos resultan ser la misma cosa. Encuentra la aplicación que cambió. Mire los ingresos que llegaron, el puntaje que obtuvo, la fila que coincidió, la cantidad que regresó.
Los gráficos son el argumento. La mesa es la evidencia. La mayoría de las discusiones sobre un cambio de política terminan en el momento en que alguien pone un registro real en la pantalla.
Llevándolo contigo
Dos salidas, dependiendo de si necesitas el número una vez o para siempre.
Una vez: exporta cualquier vista a CSV. La descarga incluye un archivo de metadatos que describe exactamente lo que se exportó, lo que suena como una limpieza hasta que seis meses después se cuestiona un número en un paquete de tablero y alguien tiene que decir de dónde vino.
Para siempre: el BI API Sirve los mismos registros de auditoría que lee la página Statistics, filtrados por regla, versión y fecha, y hay un registro personalizado. Conector Power BI construido encima de él. Su herramienta de BI consulta las decisiones en sí en lugar de una hoja de cálculo que alguien exportó en marzo y dejó de actualizar en abril.
El circuito se cierra
Esto es lo que ocurrió, en orden.
Alguien tenía una opinión sobre la umbral de aprobación. Los registros ya existían porque cada ejecución fue auditada. La política constaba de cuatro filas en una tabla, por lo que cambiarla requirió una edición y produjo una nueva versión en lugar de destruir la anterior. Ambas versiones se ejecutaron en las mismas aplicaciones: la anterior todavía estaba en producción y la nueva registraba lo que habría hecho. El flujo fijó cada versión, por lo que el experimento tenía exactamente una variable. Statistics leyó los registros y marcó la diferencia. La discusión se resolvió con números en lugar de jerarquía, y nadie tuvo que arriesgar un préstamo para averiguarlo.
Luego, la versión 2 se puso en marcha y comenzó a iniciar sesión por derecho propio. Y la siguiente pregunta ya tiene sus pruebas esperando.
Eso es lo que significa aquí Decision Intelligence. No es un panel integrado en un motor de reglas, sino las decisiones que ya ya se toman, mantenidas en una forma que se se puede ver, cuestionar y mejorar. Auditar, analizar, mejorar y dar la vuelta.
La demostración sobre el Página de Decision Intelligence es esta regla, correr. Mueva los controles deslizantes nuevamente y observe cómo funciona.
Ivan Peresta trabaja en DecisionRules, donde su función abarca análisis de producto, servicios profesionales y soporte al cliente. Participa en todo el ciclo de vida de las funcionalidades del producto, desde el diseño inicial y la reflexión sobre UX hasta las pruebas prácticas, la documentación y la entrega orientada al cliente. Su trabajo cierra la brecha entre el desarrollo del producto y las personas que realmente lo utilizan, ya sea ayudando a un cliente a diseñar su sistema de reglas o asegurándose de que una nueva función se lance con guías claras y ejemplos funcionales.