Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Mejores prácticas de la política de razonamiento automatizado

Esta página consolida las mejores prácticas para crear y mantener políticas de razonamiento automatizado. Lea esta información antes de crear su primera política y consúltela cuando solucione problemas. Para conocer los fundamentos conceptuales de estas prácticas, consulteConceptos de comprobación de razonamiento automatizado. Para obtener instrucciones de step-by-step creación, consulteCreación de una política de razonamiento automatizado.

Comience de forma sencilla e itere

El error más común al crear una política de razonamiento automatizado es intentar capturar todo un documento complejo de una sola pasada. En su lugar, comience con un subconjunto específico de sus reglas y vaya desarrollándolas de forma gradual.

Este enfoque tiene dos ventajas: facilita el aislamiento de los problemas (ya sabe qué sección introdujo un problema) y permite gestionar la política durante el desarrollo. Una política con 10 reglas bien probadas es más útil que una con 100 reglas no probadas.

Procese previamente los documentos con un LLM

En el caso de documentos extensos, que contengan prosa narrativa o que combinen contenido relacionado con reglas y no reglamentarias (como exenciones de responsabilidad legales o antecedentes organizacionales), someta el documento a un LLM antes de subirlo a Automated Reasoning Checks. Pídale al LLM que extraiga el contenido según las reglas explícitas de «si luego». Este paso previo al procesamiento mejora significativamente la calidad de la política extraída, ya que las comprobaciones de razonamiento automatizadas funcionan mejor con declaraciones claras y declarativas que con texto no estructurado.

Al escribir su solicitud de preprocesamiento, incluya las siguientes instrucciones para el LLM:

Para obtener plantillas de solicitudes detalladas y un flujo de trabajo step-by-step previo al procesamiento, consulte. (Opcional) Utilice un LLM para reescribir los documentos como reglas lógicas

Utilice las implicaciones (=>) para estructurar las reglas

El formato sif-then (que utiliza el operador de => implicación) es el patrón de redacción de reglas más importante. Todas las reglas que expresan una relación condicional deben usar este formato.

Las afirmaciones simples (reglas sin una estructura de «si entonces») crean axiomas, es decir, afirmaciones que siempre son ciertas. Esta afirmación eligibleForParentalLeave indica que Automated Reasoning comprueba que el derecho a la licencia parental siempre es válido, independientemente de las condiciones. Cualquier entrada que diga que el usuario no es elegible se devolvería IMPOSSIBLE porque contradice este axioma.

Las afirmaciones simples son apropiadas solo para condiciones de límite que siempre deberían cumplirse, como:

;; Account balance can never be negative
(>= accountBalance 0)

;; Interest rate is always between 0 and 1
(and (>= interestRate 0) (<= interestRate 1))

Si encuentra afirmaciones simples en la política extraída, reescríbalas como condicionales o elimínelas. Para obtener más información sobre cómo revisar la política extraída, consulte. Revise la política extraída

Escriba descripciones completas de las variables

Las descripciones de las variables son el factor principal de la precisión de la traducción. Cuando las comprobaciones de razonamiento automatizadas traducen el lenguaje natural a una lógica formal, utilizan descripciones de variables para determinar qué variables corresponden a los conceptos mencionados en el texto. Las descripciones vagas o incompletas son la principal causa de TRANSLATION_AMBIGUOUS los resultados.

Una buena descripción de las variables debe responder a cuatro preguntas:

Ejemplo: antes y después

Utilice valores booleanos para los estados no exclusivos

Al modelar estados que pueden coexistir, utilice variables booleanas independientes en lugar de una sola enumeración. Una persona puede ser tanto un veterano como un profesor. El uso de una enumeración customerType = {VETERAN, TEACHER} obliga a elegir entre ellas, lo que crea una contradicción lógica cuando ambas se aplican.

Reserve las enumeraciones para categorías que realmente se excluyan mutuamente y en las que solo se pueda aplicar un valor a la vez, por ejemplo leaveType = {PARENTAL, MEDICAL, BEREAVEMENT} (un empleado solo puede solicitar un tipo de licencia a la vez). Para obtener más información sobre los tipos personalizados, consulteTipos personalizados (enumeraciones).

Especifique las unidades y los formatos en las descripciones de las variables

La ambigüedad acerca de las unidades es una fuente común de errores de traducción. Si un usuario dice «Hace 2 años que trabajo aquí» y tu variable estenureMonths, es necesario que la traducción sepa cómo convertir los años en meses. Si la descripción de la variable no especifica la unidad, la traducción puede asignar tenureMonths = 2 en lugar detenureMonths = 24.

Especifique siempre:

Ejemplos:

Validación de los intervalos de valores numéricos

Para las variables numéricas, añada reglas de límite que restrinjan el rango válido. Esto evita escenarios lógicamente imposibles y ayuda a que las comprobaciones de razonamiento automatizadas produzcan resultados más significativos.

;; Account balance cannot be negative
(>= accountBalance 0)

;; Interest rate must be between 0 and 1 (0% to 100%)
(and (>= interestRate 0) (<= interestRate 1))

;; Credit score ranges from 300 to 850
(and (>= creditScore 300) (<= creditScore 850))

;; Tenure in months cannot be negative
(>= tenureMonths 0)

Sin estas reglas límite, las comprobaciones de razonamiento automatizadas podrían considerar escenarios con saldos de cuenta negativos o puntajes crediticios superiores a 1000, lo que no tiene sentido en su ámbito. Las reglas de límites son uno de los pocos casos en los que las afirmaciones simples (reglas que no tienen el formato de «si luego») son apropiadas.

Utilice variables intermedias para la abstracción

Cuando varias reglas comparten una condición común, extraiga esa condición en una variable booleana intermedia. Esto simplifica las reglas y facilita el mantenimiento de la política.

Ejemplo: niveles de membresía

En lugar de repetir la condición de membresía en todas las reglas de prestaciones:

;; Without intermediate variable (repetitive)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForFreeShipping)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForPrioritySupport)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) eligibleForEarlyAccess)

Defina una variable intermedia y haga referencia a ella:

;; With intermediate variable (cleaner)
(=> (and (> purchaseTotal 1000) (> accountAge 12)) isPremiumMember)
(=> isPremiumMember eligibleForFreeShipping)
(=> isPremiumMember eligibleForPrioritySupport)
(=> isPremiumMember eligibleForEarlyAccess)

Este patrón facilita la actualización posterior de los criterios de pertenencia; solo es necesario cambiar una regla en lugar de tres.

Usa enumeraciones para la categorización

Cuando una variable represente una categoría con un conjunto fijo de valores que se excluyen mutuamente, utilice un tipo personalizado (enumeración) en lugar de varios booleanos o una cadena. Las enumeraciones restringen los valores posibles y aclaran las reglas.

Mantenga la lógica declarativa, no procedimental

Las políticas de razonamiento automatizado describen lo que es cierto, no cómo calcularlo. Evite escribir reglas que parezcan código con pasos secuenciales o lógica de precedencia.

Del mismo modo, evite codificar la precedencia o la prioridad entre las reglas. En la lógica formal, todas las reglas se aplican simultáneamente. Si necesita expresar que una condición prevalece sobre otra, codifíquela explícitamente en las condiciones de la regla:

;; GOOD: Explicit exception handling
;; General rule: full-time employees with 12+ months get parental leave
(=> (and isFullTime (> tenureMonths 12) (not isOnProbation))
    eligibleForParentalLeave)

;; BAD: Trying to encode precedence
;; "Rule 1 takes priority over Rule 2" — this concept doesn't exist
;; in formal logic. Instead, combine the conditions into a single rule.

Convenciones de nomenclatura

La nomenclatura coherente facilita la lectura, el mantenimiento y la depuración de las políticas. Siga estas convenciones:

Evite las abreviaturas que puedan resultar ambiguas. tenureMonthsUtilícelas en lugar de tenMo y isFullTime en lugar deft. Los nombres claros ayudan tanto a los revisores humanos como al proceso de traducción.

Antipatrones comunes

Los siguientes patrones suelen provocar problemas en las políticas de razonamiento automatizado. Si encuentra resultados inesperados en las pruebas, compruebe si su póliza contiene alguno de estos antipatrones.

Axiomas en lugar de implicaciones

Como se describe enUtilice las implicaciones (=>) para estructurar las reglas, las afirmaciones simples crean axiomas que siempre son ciertos. Este es el antipatrón más común y el más dañino: hace que categorías enteras de entradas regresen. IMPOSSIBLE

Síntoma: pruebas que deberían volver VALID o que, en IMPOSSIBLE su lugar, deberían INVALID volver.

Solución: busca afirmaciones simples en tus reglas y rescríbelas como implicaciones, o elimínalas si no representan condiciones límite.

Variables superpuestas

Tener dos variables que representan conceptos iguales o similares (por ejemplo, tenureMonths ymonthsOfService) confunde el proceso de traducción. Las comprobaciones de razonamiento automatizadas no pueden determinar qué variable usar para un concepto determinado, lo que provoca traducciones y TRANSLATION_AMBIGUOUS resultados inconsistentes.

Síntoma: las pruebas se obtienen TRANSLATION_AMBIGUOUS incluso con un texto de entrada claro e inequívoco.

Solución: fusiona las variables superpuestas en una sola variable con una descripción completa. Actualice todas las reglas que hacen referencia a la variable eliminada.

Políticas demasiado complejas

Las políticas con demasiadas variables, condiciones muy arraigadas o aritmética no lineal pueden superar los límites de procesamiento y arrojar resultados. TOO_COMPLEX

Síntoma: las pruebas regresan TOO_COMPLEX o se agota el tiempo de espera.

Solución: simplifica la política. Elimine las variables no utilizadas, divida las reglas complejas en reglas más simples utilizando variables intermedias y evite la aritmética no lineal (exponentes, números irracionales). Si su dominio es realmente complejo, considere la posibilidad de dividirlo en varias políticas específicas.

Reglas contradictorias

Las reglas que se contradicen entre sí imposibilitan que las comprobaciones de razonamiento automatizadas lleguen a una conclusión. Por ejemplo, una norma establece que los empleados a tiempo completo tienen derecho a una licencia, mientras que otra dice que los empleados de su primer año no lo son, sin especificar qué ocurre con los empleados a tiempo completo durante su primer año.

Síntoma: en IMPOSSIBLE las pruebas se obtienen datos que implican normas contradictorias.

Solución: compruebe el informe de calidad para ver si hay reglas contradictorias. Resuelva los conflictos fusionando las reglas en una sola regla con condiciones explícitas o eliminando una de las reglas en conflicto. Para obtener más información, consulte Revise la política extraída.

Variables no utilizadas

Las variables a las que ninguna regla hace referencia añaden ruido al proceso de traducción. La traducción puede asignar valores a las variables no utilizadas, desperdiciando la capacidad de procesamiento y provocando posibles TRANSLATION_AMBIGUOUS resultados cuando la variable no utilizada compite con una variable activa similar.

Síntoma: TRANSLATION_AMBIGUOUS resultados inesperados o traducciones que asignan valores a variables que no afectan a ninguna regla.

Corrección: elimina las variables no utilizadas. En la consola, busca indicadores de advertencia junto a las variables. A través de la API, consulte el informe de calidad de GetAutomatedReasoningPolicyBuildWorkflowResultAssets con--asset-type QUALITY_REPORT.

Faltan valores de enumeración

Si la enumeración no incluye un valor para todas las categorías posibles que puedan mencionar los usuarios, la traducción podría fallar o producir resultados inesperados si la entrada no coincide con ningún valor definido.

Síntoma: las pruebas se devuelven TRANSLATION_AMBIGUOUS o NO_TRANSLATIONS cuando la entrada menciona una categoría que no está en la enumeración.

Solución: añade un NONE valor OTHER o a tu enumeración para gestionar las entradas que no coincidan con las categorías definidas. Actualiza las descripciones de los valores de enumeración para aclarar cuándo se aplica cada valor.