El razonamiento automatizado comprueba los conceptos

En esta página se describen los componentes básicos de las comprobaciones de razonamiento automatizado. La comprensión de estos conceptos le ayudará a crear políticas eficaces, interpretar los resultados de las pruebas y depurar los problemas. Para obtener una descripción general de alto nivel de lo que hacen las comprobaciones de razonamiento automatizado y cuándo usarlas, consulteReglas.

Políticas

Una política de razonamiento automatizado es un recurso de su cuenta de AWS que contiene un conjunto de reglas lógicas formales, un esquema de variables y tipos personalizados opcionales. La política codifica las normas, reglamentos o directrices empresariales con las que desea validar las respuestas de la LLM.

Las políticas se crean a partir de documentos fuente, como manuales de recursos humanos, manuales de cumplimiento o especificaciones de productos, que describen las reglas en lenguaje natural. Al crear una política, las comprobaciones de razonamiento automatizado extraen las reglas y variables del documento y las traducen a una lógica formal que se puede verificar matemáticamente.

La relación entre las políticas, las barreras de protección y su aplicación es la siguiente:

Source Document ──► Automated Reasoning Policy ──► Guardrail ──► Your Application
  (natural          (rules + variables +           (references     (calls guardrail
   language)         custom types)                  a policy        APIs to validate
                                                    version)        LLM responses)
    

Características clave de las políticas:

• Cada política se identifica mediante un nombre de recurso de Amazon (ARN) y existe en una región de AWS específica.

• Las políticas tienen una DRAFT versión (denominada «Borrador de trabajo» en la consola) que se edita durante el desarrollo y versiones numeradas e inmutables que se crean para su implementación.

• Una barandilla puede hacer referencia al borrador de la política o a una versión numerada específica. El uso de una versión numerada significa que puede actualizarla DRAFT sin afectar a la barandilla implementada.

• Cada política debe centrarse en un dominio específico (por ejemplo, las prestaciones de recursos humanos, los requisitos para solicitar un préstamo o las normas de devolución de productos), en lugar de tratar de cubrir múltiples áreas no relacionadas.

Para obtener instrucciones paso a paso sobre cómo crear una política, consulteCreación de una política de razonamiento automatizado.

Informe de fidelidad

Un informe de fidelidad mide la precisión con la que una política extraída representa los documentos fuente a partir de los cuales se generó. El informe se genera automáticamente al crear una política a partir de un documento fuente. Proporciona dos puntuaciones clave junto con información básica detallada que vincula cada regla y variable con afirmaciones específicas del contenido fuente.

El informe de fidelidad está diseñado para ayudar a los expertos en temas no técnicos a explorar y validar una política sin necesidad de entender la lógica formal. En la consola, la pestaña Documento fuente muestra el informe de fidelidad como una tabla de sentencias atómicas numeradas extraídas del documento, en la que se muestran las reglas y variables en las que se basa cada afirmación. Puede filtrar por reglas o variables específicas y buscar el contenido de las declaraciones.

El informe de fidelidad incluye dos puntuaciones, cada una de las cuales oscila entre 0.0 y 1.0:

• Puntuación de cobertura: indica qué tan bien la póliza cubre las declaraciones de los documentos fuente. Una puntuación más alta significa que una mayor parte del contenido original está representado en la política.

• Puntuación de precisión: indica la fidelidad con la que las reglas de la política representan el material original. Una puntuación más alta significa que las reglas extraídas coinciden más con la intención del documento original.

Más allá de las puntuaciones agregadas, el informe de fidelidad proporciona una base detallada para cada regla y variable de la política:

• Informes de reglas: para cada regla, el informe identifica las afirmaciones específicas de los documentos fuente que la respaldan (afirmaciones fundamentales), explica cómo esas afirmaciones justifican la regla (justificaciones fundamentales) y proporciona una puntuación de precisión individual con una justificación.

• Informes variables: para cada variable, el informe identifica las afirmaciones fuente que respaldan la definición de la variable, explica la justificación y proporciona una puntuación de precisión individual.

• Fuentes de documentos: los documentos fuente se desglosan en declaraciones atómicas: hechos individuales e indivisibles extraídos del texto. El contenido del documento está anotado con números de línea para que pueda rastrear cada regla y variable hasta la ubicación exacta del documento original.

Reglas

Las reglas son la base de una política de razonamiento automático. Cada regla es una expresión lógica formal que captura una relación entre variables. Las reglas se expresan mediante un subconjunto de SMT-LIB sintaxis, un formato estándar para la lógica formal que las comprobaciones de razonamiento automático utilizan para la verificación matemática. Consulte Permisos de KMS para las políticas de razonamiento automatizado

La mayoría de las reglas deben seguir un formato «si es entonces» (implicativo). Esto significa que las reglas deben tener una condición (la parte «si») y una conclusión (la parte «entonces»), conectadas por el operador de implicación. =>

Well-formed reglas (formato si-entonces):

;; If the employee is full-time AND has worked for more than 12 months,
;; then they are eligible for parental leave.
(=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave)

;; If the loan amount is greater than 500,000, then a co-signer is required.
(=> (> loanAmount 500000) requiresCosigner)

Las aserciones simples (reglas sin una estructura si-entonces) crean axiomas, afirmaciones que siempre son verdaderas. Esto es útil para comprobar las condiciones límite, como los saldos de las cuentas que tienen valores positivos, pero también puede hacer que ciertas condiciones sean lógicamente imposibles y generar IMPOSSIBLE resultados inesperados durante la validación. Por ejemplo, la mera afirmación (= eligibleForParentalLeave true) significa que las comprobaciones de razonamiento automático consideran que el usuario reúne las condiciones para solicitar el permiso parental. Cualquier entrada que mencione que no es elegible generará un resultado de validación IMPOSSIBLE porque contradice este axioma.

;; GOOD: Useful to check impossible conditions such as 
;; negative account balance
(>= accountBalance 0)

;; BAD: This asserts eligibility as always true, regardless of conditions.
eligibleForParentalLeave

Las reglas admiten los siguientes operadores lógicos:

Operador	Significado	Ejemplo
=>	Implicación (si-entonces)	(=> isFullTime eligibleForBenefits)
and	AND lógico	(and isFullTime (> tenure 12))
or	OR lógico	(or isVeteran isTeacher)
not	NOT lógico	(not isTerminated)
=	Igualdad	(= employmentType FULL_TIME)
>, <, >=, <=	Comparación	(>= creditScore 700)

Para conocer las mejores prácticas sobre la redacción de reglas eficaces, consulteMejores prácticas de la política de razonamiento automatizado.

Variables

Las variables representan los conceptos de su dominio que las comprobaciones de razonamiento automatizado utilizan para traducir el lenguaje natural en lógica formal y para evaluar las reglas. Cada variable tiene un nombre, un tipo y una descripción.

Las comprobaciones de razonamiento automático admiten los siguientes tipos de variables:

Tipo	Description (Descripción)	Ejemplo
BOOL	Valor verdadero o falso	isFullTime— Si el empleado trabaja a tiempo completo
INT	Número entero	tenureMonths— Número de meses que el empleado ha trabajado
NUMBER	Número decimal	interestRate— Tasa de interés anual expresada en decimal (0,05 significa 5%)
Tipo personalizado (enumeración)	Un valor de un conjunto definido	leaveType— Uno de los siguientes: PARENTAL, MÉDICO, DE DUELO, PERSONAL

aviso

Modele su dominio utilizando únicamente los tipos de variables de la tabla anterior. Evite diseñar una política que dependa de datos no compatibles (como cadenas sin procesar o texto de formato libre) o que requiera el paso de traducción para calcular o interpretar un valor. Intente minimizar la complejidad de la traducción.

Las comprobaciones de razonamiento automatizadas están diseñadas para interpretar el lenguaje natural y no se aplican a todas las formas de verificación. Por ejemplo, la validación de que una contraseña cumple un conjunto de requisitos se gestiona mejor mediante un código determinista basado en reglas, ya que depende de evaluar el valor bruto carácter por carácter en lugar de utilizar el lenguaje natural.

nota

En una definición de política, los nombres de las variables, los nombres de los tipos personalizados y los valores definidos en los tipos personalizados comparten un único espacio de nombres. Cada uno de estos nombres debe ser único en las tres categorías. No puede usar el mismo nombre para una variable y un tipo, y el mismo valor no puede aparecer en más de un tipo personalizado. Por ejemplo, si un LeaveType tipo define un OTHER valor, ningún otro tipo (por ejemploSeverity) puede definirlo OTHER también y no se puede asignar un nombre a ninguna variableOTHER. Si necesita un valor similar en más de un tipo, póngale como prefijo el nombre del tipo para que cada nombre sea único y, al mismo tiempo, conserve su significado (por ejemplo, LeaveType_OTHER ySeverity_OTHER).

El papel fundamental de las descripciones de variables

Las descripciones de las variables son el factor más importante para la precisión de la traducción. Cuando las comprobaciones de razonamiento automático traducen el lenguaje natural en lógica formal, utilizan descripciones de variables para determinar qué variables corresponden a los conceptos mencionados en el texto. Las descripciones vagas o incompletas conducen a TRANSLATION_AMBIGUOUS resultados o a asignaciones de variables incorrectas.

Ejemplo: Cómo afectan las descripciones a la traducción

Pensemos en un usuario que pregunta: «Llevo trabajando aquí dos años. ¿Tengo derecho a la licencia parental?

Descripción vaga (es probable que falle)	Descripción detallada (es probable que tenga éxito)
tenureMonths: «Cuánto tiempo ha trabajado el empleado».	tenureMonths: «El número de meses completos en los que el empleado ha estado empleado ininterrumpidamente. Cuando los usuarios mencionen años de servicio, conviértalos en meses (por ejemplo, 2 años = 24 meses). Establézcalo en 0 para las nuevas contrataciones».

Si la descripción es vaga, es posible que las comprobaciones de razonamiento automático no sepan convertir «2 años» en 24 meses o que no asignen la variable en absoluto. Con la descripción detallada, la traducción es inequívoca.

Las buenas descripciones de variables deberían:

• Explique lo que representa la variable en un lenguaje sencillo.

• Especifique la unidad y el formato (por ejemplo, «en meses», «con un decimal donde 0,15 significa el 15%»).

• Incluya sinónimos no obvios y frases alternativas que los usuarios puedan usar (por ejemplo, «Establézcalo en verdadero cuando los usuarios mencionen que trabajan «tiempo completo» o «jornada completa»).

• Describa las condiciones límite (por ejemplo, «Establézcalas en 0 para los nuevos empleados»).

Tipos personalizados (enumeraciones)

Los tipos personalizados definen un conjunto de valores con nombre que puede adoptar una variable. Son equivalentes a las enumeraciones (enumeraciones) en los lenguajes de programación. Utilice tipos personalizados cuando una variable represente una categoría con un conjunto fijo de valores posibles.

Ejemplos:

Escriba el nombre	Valores posibles	Caso de uso
LeaveType	PARENTAL, MÉDICO, DE DUELO, PERSONAL	Clasifique el tipo de licencia que solicita un empleado
Severity	CRÍTICO, MAYOR, MENOR	Clasifique la gravedad de un problema o incidente

Cuándo usar enumeraciones en lugar de booleanos:

• Usa las enumeraciones cuando los valores se excluyan mutuamente; una variable solo puede tener un valor a la vez. Por ejemplo, leaveType puede ser PARENTAL o MÉDICO, pero no ambos a la vez.

• Utilice variables booleanas independientes cuando los estados puedan coexistir. Por ejemplo, una persona puede ser tanto veterana como maestra. El uso de una customerType = {VETERAN, TEACHER} enumeración obligaría a elegir entre ellas, creando una contradicción lógica cuando ambas se aplican. En su lugar, usa dos valores booleanos: y. isVeteran isTeacher

sugerencia

Si es posible que una variable no tenga ningún valor de la enumeración, incluya un OTHER valor o. NONE Esto evita problemas de traducción cuando la entrada no coincide con ninguno de los valores definidos.

Traducción: del lenguaje natural a la lógica formal

La traducción es el proceso mediante el cual las comprobaciones de razonamiento automático convierten el lenguaje natural (preguntas de los usuarios y respuestas del LLM) en expresiones lógicas formales que se pueden verificar matemáticamente comparándolas con las reglas de su política. Comprender este proceso es fundamental para solucionar problemas y crear políticas eficaces.

Las comprobaciones de razonamiento automatizadas validan el contenido en dos pasos distintos:

1. Traducir: las comprobaciones de razonamiento automatizado utilizan modelos básicos (LLM) para traducir la entrada del lenguaje natural a la lógica formal. Este paso asigna los conceptos del texto a las variables de su política y expresa las relaciones como declaraciones lógicas. Como en este paso se utilizan LLM, es posible que contenga errores. Las verificaciones de razonamiento automatizadas utilizan varios LLM para traducir el texto de entrada y, a continuación, utilizan la equivalencia semántica de las traducciones redundantes para establecer una puntuación de confianza. La calidad de la traducción depende de qué tan bien las descripciones de las variables coincidan con el idioma utilizado en la entrada.

2. Validar: las comprobaciones de razonamiento automático utilizan técnicas matemáticas (mediante solucionadores de SMT) para comprobar si la lógica traducida es coherente con las reglas de tu política. Este paso es correcto desde el punto de vista matemático: si la traducción es correcta, el resultado de la validación será coherente.

importante

Esta distinción en dos pasos es fundamental para la depuración. Si está seguro de que las reglas de la política son correctas, cuando una prueba falla o arroja resultados inesperados, lo más probable es que el problema se produzca en el paso 1 (traducción), no en el paso 2 (validación). La validación matemática es sólida y, si la traducción capta correctamente el significado de la entrada, el resultado de la validación será correcto. Centra tus esfuerzos de depuración en mejorar las descripciones de las variables y en garantizar que la traducción asigne las variables correctas con los valores correctos.

Ejemplo: La traducción en acción

Dada una política con variables isFullTime (BOOL), tenureMonths (INT) y eligibleForParentalLeave (BOOL) y la entrada:

• Pregunta: «Soy empleado a tiempo completo y llevo 18 meses aquí. ¿Puedo tomar la licencia parental?»

• Respuesta: «Sí, tiene derecho a la licencia parental».

El paso 1 (traducir) produce:

Premises: isFullTime = true, tenureMonths = 18
Claims: eligibleForParentalLeave = true

El paso 2 (validar) compara estas asignaciones con la regla de la póliza (=> (and isFullTime (> tenureMonths 12)) eligibleForParentalLeave) y confirma que la reclamación sí lo esVALID.

Para mejorar la precisión de la traducción:

• Escribe descripciones detalladas de las variables que cubran cómo los usuarios se refieren a los conceptos en el lenguaje cotidiano.

• Elimine las variables duplicadas o casi duplicadas que puedan confundir la traducción (por ejemplo, tenureMonths ymonthsOfService).

• Elimine las variables no utilizadas a las que no haga referencia ninguna regla, ya que dificultan el proceso de traducción.

• Usa pruebas de preguntas y respuestas para validar la precisión de la traducción con entradas de usuario realistas. Para obtener más información, consulte Prueba de una política de razonamiento automatizado.

Hallazgos y resultados de validación

Cuando las comprobaciones de razonamiento automatizado validan el contenido, producen un conjunto de hallazgos. Cada conclusión representa una afirmación fáctica extraída de la entrada, junto con el resultado de la validación, las asignaciones de variables utilizadas y las reglas políticas que respaldan la conclusión. El resultado global (agregado) se determina ordenando los hallazgos por orden de gravedad y seleccionando el peor resultado. El orden de gravedad de peor a mejor es:TRANSLATION_AMBIGUOUS,IMPOSSIBLE,INVALID,SATISFIABLE,VALID.

Estructura de un hallazgo

El tipo de resultado determina qué campos están presentes en el hallazgo. Consulte la Referencia de los resultados de la validación sección para obtener una descripción detallada de cada tipo de búsqueda. Sin embargo, la mayoría de los tipos de búsqueda comparten un translation objeto común que contiene los siguientes componentes:

premises

El contexto, las suposiciones o las condiciones se extraen de la entrada y que afectan a la forma en que se debe evaluar una reclamación. En los formatos de preguntas y respuestas, la premisa suele ser la pregunta en sí misma. Las respuestas también pueden contener premisas que establecen restricciones. Por ejemplo, en «Soy un empleado a tiempo completo con 18 meses de servicio», las instalaciones son isFullTime = true ytenureMonths = 18.

claims

Las afirmaciones fácticas que el razonamiento automatizado comprueba para comprobar su precisión. En un formato de preguntas y respuestas, la afirmación suele ser la respuesta. Por ejemplo, si dice «Sí, reúne los requisitos para el permiso parental», la afirmación eseligibleForParentalLeave = true:

confidence

Una puntuación de 0.0 a 1.0 representa el grado en que ciertas comprobaciones del razonamiento automático tienen que ver con la traducción del lenguaje natural a la lógica formal. Las puntuaciones más altas indican una mayor certeza. Una confianza de 1,0 significa que todos los modelos de traducción coincidieron en la misma interpretación.

untranslatedPremises

Referencias a partes del texto de entrada original que corresponden a premisas pero que no se han podido traducir a una lógica formal. En ellas se destacan partes de la entrada que el razonamiento automatizado reconoció como relevantes, pero que no pudo asignar a las variables de las políticas.

untranslatedClaims

Referencias a partes del texto de entrada original que corresponden a afirmaciones pero que no se han podido traducir a una lógica formal. Un VALID resultado solo cubre las afirmaciones traducidas; las afirmaciones no traducidas no se validan.

Referencia de los resultados de la validación

Cada hallazgo es exactamente uno de los siguientes tipos. El tipo determina el significado del resultado, los campos disponibles en la búsqueda y la acción recomendada para la aplicación. Todos los tipos de búsqueda que incluyen un translation campo también incluyen un logicWarning campo que aparece cuando la traducción contiene problemas lógicos independientes de las reglas de la política (por ejemplo, afirmaciones que siempre son verdaderas o siempre falsas).

Resultado	Búsqueda de campos	Acción recomendada
VALID	translation— Las premisas traducidas, las afirmaciones, el puntaje de confianza y cualquier referencia no traducida. supportingRules— Las reglas de la póliza que prueban que las afirmaciones son correctas. Cada regla incluye su identificador y el ARN de la versión de la política. claimsTrueScenario— Un escenario (conjunto de asignaciones de variables) que demuestre cómo las afirmaciones son lógicamente verdaderas.	Entregue la respuesta al usuario. claimsTrueScenarioPara fines de registro supportingRules y auditoría, proporcionan una prueba de validez verificable matemáticamente. Compruebe si hay untranslatedPremises partes untranslatedClaims de la entrada que no se hayan validado.
INVALID	translation— Las premisas traducidas, las afirmaciones, el puntaje de confianza y cualquier referencia no traducida. contradictingRules— Las normas de la política que infringen las reclamaciones. Cada regla incluye su identificador y el ARN de la versión de la política.	No entregue la respuesta. Usa translation (para ver lo que se ha reclamado) y contradictingRules (para ver qué reglas se han infringido) para reescribir la respuesta o bloquearla. En un ciclo de reescritura, pasa las reglas contradictorias y las afirmaciones incorrectas al LLM para generar una respuesta corregida.
SATISFIABLE	translation— Las premisas traducidas, las afirmaciones, el puntaje de confianza y cualquier referencia no traducida. claimsTrueScenario— Un escenario que demuestre cómo las afirmaciones podrían ser lógicamente ciertas. claimsFalseScenario— Un escenario que demuestre cómo las afirmaciones pueden ser lógicamente falsas en diferentes condiciones.	Compare claimsTrueScenario e claimsFalseScenario identifique las condiciones que faltan. Vuelva a escribir la respuesta para incluir la información adicional necesaria para crearlaVALID, pida al usuario que aclare las condiciones que faltan o entregue la respuesta con la salvedad de que puede estar incompleta.
IMPOSSIBLE	translation— Las premisas traducidas, las afirmaciones, el puntaje de confianza y cualquier referencia no traducida. Inspeccione las instalaciones para identificar las contradicciones. contradictingRules— Las reglas de la política que entran en conflicto con las instalaciones o entre sí. Si se rellena, la contradicción puede estar en la propia política.	Compruebe si la entrada contiene afirmaciones contradictorias (por ejemplo, «Trabajo a tiempo completo y también a tiempo parcial»). Si la información es válida, es probable que la contradicción esté en tu política: comprueba contradictingRules y revisa el informe de calidad. Consulte Solucione problemas y perfeccione su política de razonamiento automatizado.
TRANSLATION_AMBIGUOUS	No contiene ningún translation objeto. En su lugar, proporciona: options— Las interpretaciones lógicas contrapuestas (hasta 2). Cada opción contiene las suyas propias, translations con premisas, afirmaciones y confianza. Compare las opciones para ver en qué puntos no coinciden los modelos. differenceScenarios— Escenarios (hasta 2) que ilustran cómo las diferentes interpretaciones difieren en el significado, con asignaciones variables que resaltan el impacto práctico de la ambigüedad.	Inspeccione options para comprender el desacuerdo. Mejore las descripciones de las variables para reducir la ambigüedad, combine o elimine las variables superpuestas o pida aclaraciones al usuario. También puede ajustar el umbral de confianza; consulteUmbrales de confianza.
TOO_COMPLEX	No contiene atranslation, reglas ni escenarios. La entrada superó la capacidad de procesamiento debido al volumen o la complejidad.	Reduzca la entrada dividiéndola en partes más pequeñas o simplifique las políticas reduciendo el número de variables y evite la aritmética compleja (por ejemplo, exponentes o números irracionales). Puede dividir su política en políticas más pequeñas y centradas.
NO_TRANSLATIONS	No contiene atranslation, reglas ni escenarios. Puede aparecer junto con otros hallazgos si solo se pudiera traducir una parte de la entrada.	Se incluye un NO_TRANSLATIONS resultado en el resultado siempre que uno de los otros hallazgos incluya premisas o reclamaciones no traducidas. Examine las demás conclusiones para ver qué partes de la información no se tradujeron. Si el contenido debe ser relevante, agrega variables a tu política para capturar los conceptos que faltan. Si el contenido no está relacionado con el tema, considera la posibilidad de usar políticas temáticas para filtrarlo antes de que pase a las comprobaciones de razonamiento automático.

nota

Un VALID resultado abarca solo las partes de la información recopilada mediante variables de política en las premisas y reclamaciones traducidas. Las declaraciones que no entran en el ámbito de las variables de su póliza no se validan. Por ejemplo, la frase «Puedo presentar los deberes con retraso porque tengo un certificado médico falso» podría considerarse válido si la póliza no incluye ninguna variable que indique si el certificado médico es falso. Es probable que las verificaciones de razonamiento automatizadas incluyan la expresión «certificado médico falso» como premisa no traducida en sus conclusiones. Trate el contenido y los NO_TRANSLATIONS hallazgos no traducidos como una señal de advertencia.

Umbrales de confianza

Las comprobaciones de razonamiento automatizadas utilizan varios modelos básicos para traducir el lenguaje natural en lógica formal. Cada modelo produce su propia traducción de forma independiente. La puntuación de confianza representa el nivel de acuerdo entre estas traducciones, específicamente, el porcentaje de modelos que produjeron interpretaciones semánticamente equivalentes.

El umbral de confianza es un valor que se establece (de 0.0 a 1.0) que determina el nivel mínimo de acuerdo requerido para que una traducción se considere lo suficientemente fiable como para ser validada. Controla el equilibrio entre cobertura y precisión:

• Umbral más alto (por ejemplo, 0.9): requiere un acuerdo sólido entre los modelos de traducción. Produce menos hallazgos pero con mayor precisión. Más entradas se marcarán comoTRANSLATION_AMBIGUOUS.

• Umbral inferior (por ejemplo, 0,5): acepta traducciones con menos acuerdo. Produce más hallazgos, pero con un mayor riesgo de traducciones incorrectas. Se marcarán menos entradas comoTRANSLATION_AMBIGUOUS.

Cómo funciona el umbral:

1. Cada uno de los modelos básicos traduce la entrada de forma independiente.

2. Las traducciones que están respaldadas por un porcentaje de modelos igual o superior al umbral se convierten en hallazgos de alta confianza con un resultado definitivo (VALID,INVALID, etc.).

3. Si una o más traducciones están por debajo del umbral, las comprobaciones de razonamiento automatizado arrojan un TRANSLATION_AMBIGUOUS resultado adicional. Este resultado incluye detalles sobre los desacuerdos entre los modelos, que puedes utilizar para mejorar las descripciones de las variables o pedir aclaraciones al usuario.

sugerencia

Comience con el umbral predeterminado y ajústelo en función de los resultados de las pruebas. Si ves demasiados TRANSLATION_AMBIGUOUS resultados para entradas que deberían ser inequívocas, céntrate en mejorar las descripciones de las variables en lugar de reducir el umbral. Reducir el umbral puede reducir TRANSLATION_AMBIGUOUS los resultados, pero aumenta el riesgo de validaciones incorrectas.