Refinamiento de políticas de razonamiento automatizado en Amazon Bedrock

Refinar una política de razonamiento automatizado en Amazon Bedrock ha sido un ciclo manual de diagnóstico, edición manual, nueva prueba y repetición. Hoy anunciamos un refinamiento automático de políticas, que automatiza el trabajo de diagnóstico y reparación en ese ciclo. El motor de refinamiento diagnostica pruebas fallidas y propone soluciones de lógica formal. Usted aprueba cada cambio antes de que entre en vigor.

Las comprobaciones de razonamiento automatizadas en Amazon Bedrock Guardrails utilizan una verificación formal para demostrar la exactitud de las respuestas. En traducciones inequívocas del lenguaje natural a la lógica formal, ofrecen hasta un 99% de precisión de verificación, como se informa en el anuncio de GA. Para comenzar, debe crear una política de razonamiento automatizado a partir de un documento fuente y validarla con casos de prueba. Los clientes nos dijeron que este ajuste iterativo crea el mayor punto de fricción en el desarrollo de políticas.

En esta publicación, analizamos dos nuevos modos de refinamiento: refinamiento iterativo para problemas de reglas y refinamiento variable ambiguo para problemas de lenguaje. Para cada modo, mostramos un flujo de trabajo de API completo (iniciar, sondear, recuperar) y un flujo de trabajo de consola repetible para convertir políticas fallidas en políticas aprobadas.

Qué son realmente las comprobaciones de razonamiento automatizado

Las comprobaciones de razonamiento automatizado traducen el lenguaje natural en lógica formal y luego aplican técnicas de razonamiento automatizado para producir un resultado: VÁLIDO, NO VÁLIDO, SATISFIABLE, IMPOSIBLE o TRADUCCIÓN_AMBIGUA. Para obtener una introducción completa sobre cómo funcionan las políticas, consulte nuestra publicación de anuncios de GA.

Para esta publicación, el concepto clave es el proceso de validación de dos pasos. Primero, el paso de traducción asigna entradas/salidas en lenguaje natural a asignaciones de variables utilizando las descripciones de variables en su política. En segundo lugar, el paso de validación aplica sus reglas formales a esas asignaciones. Cuando una prueba falla, la causa raíz se encuentra en uno de esos dos pasos y cada modo de refinamiento apunta a uno diferente. La Figura 1 traza ese proceso de extremo a extremo.

Probando su póliza. Usted valida una política adjuntando pruebas: cada prueba es texto de entrada/salida más el resultado esperado. Ejecute pruebas individualmente o en lotes. Los fallos le indican exactamente en qué se diferencia la política de su intención.

Por qué es necesario perfeccionar las políticas: dos modos de fracaso

Recuerde el proceso de dos pasos: traducir (lenguaje natural a asignaciones de variables) y luego validar (lógica formal para encontrar). Una prueba fallida significa que uno de estos pasos produjo algo que no esperaba. Las comprobaciones de razonamiento automatizado muestran dos señales de error distintas que se asignan claramente a cada paso.

Modo de falla 1: problemas con las reglas (la lógica es incorrecta)

En caso de error en la emisión de una regla, la traducción funciona correctamente: las variables correctas tienen los valores correctos, pero el resultado de la validación no coincide con sus expectativas. El problema radica en sus reglas: una regla es demasiado permisiva, demasiado restrictiva o no existe por completo. Concretamente, esperabas INVÁLIDO pero obtuviste SATISFIABLE porque una regla faltante o demasiado permisiva deja pasar una mala respuesta. O esperabas SATISFIABLE pero obtuviste INVÁLIDO porque una regla demasiado estricta bloquea una respuesta correcta.

Modelo mental: el sistema entendió perfectamente la pregunta pero aplicó la lógica equivocada. Necesitas arreglar las reglas.

Modo de error 2: traducción ambigua (el idioma es incorrecto)

Cuando una prueba devuelve TRANSLATION_AMBIGUOUS, el motor de validación se ejecuta y produce diferentes resultados según la interpretación que siga. En algunos casos, los modelos de traducción no estaban de acuerdo sobre cómo asignar la entrada del lenguaje natural a las variables de su política, y cada interpretación en competencia condujo a un resultado de validación diferente. El hallazgo muestra dos o más opciones, cada una con su propia traducción y conclusión, además de escenarios diferentes que muestran dónde divergen las interpretaciones en la práctica. Las causas fundamentales comunes incluyen definiciones de variables superpuestas (“permanencia” en comparación con “años de servicio”), descripciones vagas y formatos de valores inconsistentes (5 en comparación con 0,05 para el “5%”).

Modo de coincidencia hasta el fallo

Esta tabla resume qué modo de refinamiento aborda qué tipo de falla:

Modo de falla Causa raíz Modo de refinamiento Qué hace Problemas de reglas La lógica es incorrecta Refinamiento iterativo Propone adiciones, ediciones o eliminaciones de reglas o variables Traducción ambigua El lenguaje es ambiguo Refinamiento de variables ambiguas Propone descripciones de variables más claras que colapsan múltiples interpretaciones en una sola

Utilice el refinamiento de variables ambiguas cuando el sistema no pueda determinar una única traducción. Las siguientes dos secciones analizan cada modo por turno: qué hace, cuándo usarlo, cómo funciona la puerta de revisión y cómo iniciarlo mediante programación. Comenzamos con el refinamiento iterativo porque las fallas en la emisión de reglas son el caso más común.

Refinamiento iterativo: arreglar las reglas

Cuando las pruebas fallan porque la lógica es incorrecta (la traducción es limpia pero el resultado de la validación no coincide con sus expectativas), el problema reside en sus reglas. El refinamiento iterativo (ITERATIVELY_REFINE_POLICY) automatiza el ciclo de diagnóstico y reparación para que no sea necesario rastrear manualmente cada regla, formular hipótesis sobre una corrección y editar manualmente la lógica formal.

Considere una política con entre 10 y 30 reglas. Anteriormente, una solución requeriría que un experto en la materia realizara varias rondas de diagnóstico manual y edición manual de la lógica formal SMT-LIB. Ese trabajo ahora se reduce a un solo paso de revisión y aprobación, sin una lógica formal escrita a mano.

como funciona

El refinamiento iterativo requiere tres entradas. La primera es su definición de política existente (las reglas, variables y tipos actuales). El segundo es un documento fuente que contiene el texto autorizado en lenguaje natural que describe cómo deberían funcionar las cosas. La tercera entrada es opcional: comentarios en lenguaje natural con instrucciones explícitas que describen el cambio que desea.

Por ejemplo, el campo de comentarios podría contener: "Actualizar el requisito de permanencia para la licencia parental de 12 meses a 6 meses, como se especifica en la sección 3 del documento revisado".

Teniendo en cuenta estos aportes, el motor de refinamiento analiza cómo las reglas actuales difieren del documento fuente y sus comentarios. Propone un conjunto de cambios candidatos (nuevas reglas, reglas editadas, variables agregadas) que alinean la política.

El bucle de convergencia

El refinamiento iterativo, como su nombre indica, itera. Detrás de escena, el motor genera un cambio candidato, simula su efecto en las pruebas guardadas, verifica si las pruebas que antes fallaban ahora pasan y se ajusta si no lo hacen. Esto puede implicar varios ciclos internos para una sola solicitud, especialmente cuando una corrección en una regla afecta a otras. Sin embargo, la iteración ocurre internamente: no se observa cada intento intermedio y no es necesario guiarlo. Lo que recibe es el resultado convergente: una diferencia propuesta que muestra exactamente qué reglas cambiaron, qué variables cambiaron y cómo el cambio afecta a cada prueba de su suite.

La puerta de revisión

Después de la convergencia, aparece la pantalla Revisar cambios de política.

Luego selecciona Aceptar cambios o Descartar cambios. Al aceptar se escriben los cambios en su BORRADOR de póliza. Descartar deja todo exactamente como estaba.

Requisitos previos y cuándo utilizar

El refinamiento iterativo requiere al menos una prueba adjunta a su póliza. Sin una señal de prueba fallida, no hay nada que impulse el refinamiento. Utilice este modo cuando la traducción sea correcta (variables correctas, valores correctos) pero el resultado de la validación sea inesperado. No lo utilices cuando el resultado sea TRANSLATION_AMBIGUOUS. Ese es un problema de lenguaje que se soluciona mejor mediante el refinamiento de variables ambiguas.

A través de la API

El refinamiento se ejecuta como un flujo de trabajo de compilación asincrónico. Al utilizar AWS SDK para Python (Boto3), el flujo tiene cuatro pasos: exportar la definición de política actual, iniciar el flujo de trabajo, sondear para completarlo y recuperar los cambios propuestos. Establezca buildWorkflowType en ITERATIVELY_REFINE_POLICY.

El bloque iterativeRefinementContent acepta de uno a cinco documentos fuente (obligatorio) y hasta 4000 caracteres de comentarios opcionales:

La llamada regresa inmediatamente con un buildWorkflowId, no con los cambios propuestos. El flujo de trabajo pasa de PROGRAMADO a EDIFICIO hasta llegar a COMPLETADO, FALLADO o CANCELADO. La convergencia suele tardar entre uno y varios minutos, según el tamaño de la política. Sondee get_automated_reasoning_policy_build_workflow hasta que el estado alcance un estado terminal. Luego recupere la propuesta convergente con get_automated_reasoning_policy_build_workflow_result_assets, solicitando el activo POLICY_DEFINITION para ver las reglas actualizadas (y BUILD_LOG para el registro de acciones):

La definición de política devuelta es el BORRADOR propuesto, la nueva definición completa. Para confirmarlo, llame a update_automated_reasoning_policy con esta definición. Para ver qué cambió, compárelo con la definición de política que exportó antes de iniciar el flujo de trabajo. La pantalla Revisar cambios de política de la consola envuelve esta misma secuencia de inicio, encuesta y recuperación, mostrando la diferencia detrás de los botones Aceptar cambios y Descartar cambios.

Refinamiento de variables ambiguas: arreglar el lenguaje

El refinamiento iterativo maneja problemas de reglas, pero no todas las pruebas fallidas son un problema de reglas. Cuando la traducción en sí es inestable, ninguna edición de reglas ayudará. Debe corregir el lenguaje que utiliza la política para describir sus variables. Eso es lo que hace el refinamiento de variables ambiguas. Sigue el mismo patrón asincrónico de inicio, encuesta y recuperación y llega a la misma pantalla de revisión y aceptación. La diferencia está en las propuestas. Se centran en fusiones y descripciones de variables, y se aplican actualizaciones de reglas y tipos según sea necesario para mantener la coherencia de la política.

Cuando las pruebas producen resultados TRANSLATION_AMBIGUOUS (consulte el modo de error 2 anteriormente en esta publicación), las traducciones en competencia conducen a diferentes resultados de validación. La ambigüedad también puede provenir de cómo se expresa el contenido validado. Esta sección se centra en la ambigüedad de las variables de política.

como funciona

La ambigüedad en la traducción, debido a cuestiones variables en materia de políticas, suele deberse a un puñado de causas fundamentales. Las variables superpuestas ocurren cuando dos variables describen el mismo concepto. Por ejemplo, tenureMonths (“Cuánto tiempo ha trabajado el empleado en meses”) y MonthsOfService (“Los meses de servicio del empleado”) capturan la duración del empleo. Como resultado, los modelos de traducción no están de acuerdo sobre cuál usar. Las descripciones incompletas surgen cuando la descripción de una variable es demasiado vaga para guiar la traducción. El formato de valor inconsistente crea ambigüedad cuando el sistema no puede determinar si "5%" debe convertirse en tasa de interés = 5 o tasa de interés = 0,05. La lógica integrada en los nombres de las variables crea confusión. Un nombre como timelyReportingNotFeasible ya contiene una negación, por lo que expresar el caso positivo requiere negar un negativo. Los modelos de traducción suelen dejar de lado uno de los dos.

Estos son sólo los patrones más comunes. Debido a que la detección funciona ejerciendo las variables de la política en la traducción en lugar de compararlas con una lista fija de problemas conocidos, pueden surgir problemas a nivel de variables que causan que las traducciones no estén de acuerdo.

Cuando ejecuta el Refinamiento de variables ambiguas, señala qué descripciones de variables o definiciones superpuestas causan el desacuerdo y luego propone descripciones refinadas que combinan múltiples interpretaciones en una definición precisa.

Estas descripciones refinadas incorporan reglas de conversión de unidades, sinónimos, frases alternativas y orientación de formato explícita. Este ejemplo de antes/después ilustra una propuesta típica:

Antes Después de la tenencia (propuesta) Meses: "Cuánto tiempo ha trabajado el empleado en meses". tenureMonths: "El número de meses completos que el empleado ha estado empleado continuamente. Cuando los usuarios mencionan años de servicio, conviértalos a meses (por ejemplo, 2 años = 24 meses). Esta variable captura referencias a la duración del empleo, la duración del servicio, el tiempo en la empresa o la antigüedad".

Si se detectan variables superpuestas, también se puede proponer una combinación: se elimina una variable y las reglas que hacen referencia a ella se actualizan para utilizar la variable superviviente.

La puerta de revisión

Al igual que el refinamiento iterativo, usted revisa los cambios propuestos antes de aplicar algo.

También muestra los resultados de las pruebas, donde las pruebas que anteriormente arrojaban TRANSLATION_AMBIGUOUS ahora producen un resultado VÁLIDO, NO VÁLIDO o SATISFIABLE definitivo. Seleccionas Aceptar cambios o Descartar cambios. Ningún cambio afectará su BORRADOR de política hasta que usted lo apruebe.

Cuando usarlo

Utilice el refinamiento de variables ambiguas cuando las pruebas produzcan resultados TRANSLATION_AMBIGUOUS o cuando inspeccione un hallazgo VÁLIDO/INVÁLIDO y descubra que la traducción asignó valores a las variables incorrectas. No lo utilices cuando la traducción sea correcta pero el resultado de la validación sea inesperado. Ese es un problema de reglas para el refinamiento iterativo.

A través de la API

El refinamiento de variables ambiguas utiliza el mismo patrón asincrónico de inicio, encuesta y recuperación. Establezca buildWorkflowType en RESOLVE_POLICY_AMBIGUITIES. Este modo analiza las variables de su política directamente y no necesita un documento fuente ni pruebas adjuntas, por lo que se puede omitir el contenido del flujo de trabajo. La definición de política actual todavía es necesaria en sourceContent. Exportarlo primero con export_automated_reasoning_policy_version como se mostró anteriormente para el Refinamiento iterativo:

Al igual que con el refinamiento iterativo, la respuesta es un buildWorkflowId. Sondee get_automated_reasoning_policy_build_workflow hasta que el estado alcance un estado terminal. Luego llame a get_automated_reasoning_policy_build_workflow_result_assets con activeType="POLICY_DEFINITION" para recuperar las descripciones y fusiones de variables propuestas:

Los cambios siguen siendo una propuesta hasta que los aceptes.

Usted aprueba cada cambio: la puerta del ser humano en el circuito

Ambos modos de refinamiento comparten una propiedad no negociable: ningún cambio surtirá efecto hasta que usted lo indique. El motor de refinamiento tiene autoridad de sugerencia. Puede analizar, diagnosticar y proponer. Tienes autoridad para comprometerte. Tú decides lo que llega a tu BORRADOR de póliza y, en definitiva, a la producción.

El bucle de cinco pasos

Independientemente del modo de refinamiento que utilice, el flujo de trabajo sigue el mismo patrón de cinco pasos. Primero, pruebe: ejecute sus pruebas guardadas con la política actual. En segundo lugar, verifique: identifique qué pruebas no coinciden con el resultado esperado. En tercer lugar, proponer: el sistema genera correcciones candidatas para reglas o descripciones de variables. Cuarto, revisión: inspeccionas la diferencia propuesta y su impacto en las pruebas. Quinto, aplica: aceptas los cambios en BORRADOR, o los rechazas y nada cambia.

Después de aceptar, vuelva a realizar la prueba para confirmar que la solución resolvió el problema sin interrumpir otras pruebas. Esto crea un trinquete: cada ciclo lo acerca a una política de aprobación o le brinda nueva información de diagnóstico.

Lo que te muestra la pantalla de revisión

La pantalla de revisión le permite comprender las ramificaciones de un cambio, no sólo el cambio en sí. Responde a dos preguntas a la vez: ¿qué propuso el motor y cómo afecta esa propuesta a todas las pruebas que te interesan?

La propuesta se divide en tres secciones. Cambios en reglas enumera las reglas agregadas, editadas o eliminadas, con la expresión de lógica formal para cada una. Los cambios en las variables muestran descripciones de variables actualizadas y variables agregadas o eliminadas, con el texto anterior junto al texto propuesto para que pueda comparar los dos directamente. Los cambios en los tipos de variables personalizados cubren los cambios en los tipos enumerados de la política.

Además de esos cambios, la pantalla muestra una sección de Resultados de la prueba que enumera la prueba guardada con su resultado anterior y nuevo. Cada fila proporciona el resultado esperado y si la prueba pasó antes y después. Elija Ver resultados en una fila para ver el hallazgo en sí. Esta vista es el indicador más importante de la pantalla. Si sus exámenes reprobados ahora pasan y sus exámenes aprobados aún pasan, puede aceptar con confianza.

Validar con el Informe de Fidelidad

Después de aplicar los cambios, genere un Informe de fidelidad (GENERATE_FIDELITY_REPORT) para validar que su política actualizada aún representa fielmente su documento fuente. El informe proporciona tres medidas. La puntuación de cobertura (0,0–1,0) indica qué parte de su documento fuente está representado en la póliza. La puntuación de precisión (0,0–1,0) indica qué tan fielmente coinciden las reglas con la intención del documento original. La fundamentación por regla vincula cada regla con las declaraciones específicas del documento fuente que la respaldan, con justificaciones.

Compare los informes de Fidelity antes y después del refinamiento. Si su puntuación de precisión disminuye, es posible que la solución propuesta se haya desviado del material original, lo que es una señal para rechazar o iterar más.

El principio

El refinamiento automático acelera la labor de diagnosticar fallas y generar soluciones candidatas. No acelera la autoridad para cambiar lo que impone su barrera de seguridad. Cada solución sigue siendo una sugerencia hasta que usted decide aceptarla.

Dirigiendo el motor: documentos fuente y comentarios personalizados

Puede dirigir ambos modos proporcionando un contexto que guíe al sistema hacia la solución correcta más rápidamente.

Documentos fuente

Cuando inicia el refinamiento iterativo, proporciona un documento fuente que representa la verdad fundamental que su política debe codificar. La consola ofrece tres modos para proporcionarlo: Usado recientemente vuelve a seleccionar un documento cargado anteriormente, Cargar toma un nuevo archivo PDF o de texto e Ingresar texto acepta el contenido pegado directamente. Cuanto más claro y centrado sea el documento, más precisas serán las propuestas.

Comentarios personalizados: orientación explícita si y entonces

También puede proporcionar comentarios en lenguaje natural que le indiquen al sistema exactamente qué corregir. La retroalimentación efectiva es específica y comprobable. Comentarios vagos como "arreglar la regla de permanencia" le dan al motor demasiada libertad. Compárelo con una alternativa específica y comprobable: "Si un empleado trabaja a tiempo completo y ha trabajado durante más de 6 meses (no 12), debería tener derecho a la licencia parental".

Sus comentarios actúan como una limitación: el sistema genera cambios que satisfacen tanto el documento fuente como sus orientaciones. Si los dos entran en conflicto, el conflicto se marca para su revisión.

Puede proporcionar un documento fuente y comentarios juntos. Cuando su documento es denso, la retroalimentación enfoca al sistema en la sección específica que importa.

Tutoriales de un extremo a otro

Esta sección proporciona dos tutoriales, uno para cada modo de refinamiento. Juntos le brindan un flujo de trabajo repetible para ambos tipos de fallas.

Requisitos previos

Para utilizar el refinamiento automático de políticas con comprobaciones de razonamiento automatizado en Amazon Bedrock, asegúrese de cumplir con los siguientes requisitos previos:

Una cuenta de AWS activa. Confirmación de las regiones de AWS donde las comprobaciones de razonamiento automatizado están disponibles y acceso a Amazon Bedrock en una de ellas. Permisos de IAM para crear, ver y perfeccionar políticas de razonamiento automatizado y trabajar con Amazon Bedrock Guardrails. Una política de razonamiento automatizado en su cuenta, creada a partir de un documento fuente que captura las reglas que desea aplicar. Para obtener instrucciones paso a paso, consulte Crear su política de razonamiento automatizado. Necesita que esta política tenga al menos una prueba adjunta: el refinamiento iterativo requiere una señal de prueba fallida para impulsar su diagnóstico. Para agregar pruebas, consulte Probar una política de razonamiento automatizado.

Tutorial A: Solucionar un problema de regla con refinamiento iterativo

Su política de elegibilidad para licencia de recursos humanos tiene una prueba fallida. El asistente informa que un empleado a tiempo parcial con 8 meses de antigüedad tiene derecho a la licencia parental. La prueba espera NO VÁLIDO, pero la política devuelve VÁLIDO.

Paso 1: Validar las pruebas

En la consola de Amazon Bedrock, navegue hasta Razonamiento automatizado y abra su política. Elija la pestaña Pruebas y luego elija Validar todas las pruebas. La Figura 2 muestra los resultados. Tres de las cuatro pruebas pasan y la prueba de licencia parental falla con un resultado VÁLIDO inesperado.

Figura 2: La pestaña Pruebas después de la validación, con tres de cuatro pruebas aprobadas (75%)

Paso 2: inspeccionar el hallazgo defectuoso

Abra el hallazgo de la prueba fallida e inspeccione la traducción, que se muestra en la Figura 3. Las variables se capturan correctamente: meses de servicio continuo = 8. Estado de empleo = TIEMPO_PARTE.

Figura 3: Hallazgo de la prueba fallida, con la traducción que muestra las variables capturadas correctamente

El hallazgo es VÁLIDO porque la única regla de respaldo otorga la elegibilidad después de 6 meses de servicio continuo, y ninguna regla excluye a los empleados a tiempo parcial. La traducción es limpia y la lógica es incorrecta, por lo que se trata de una cuestión de reglas.

Paso 3: refinar la política

Elija Refinar política y luego elija Refinar política automáticamente. Establezca el tipo de refinamiento en Refinamiento iterativo. Proporcionar un documento fuente utilizando cualquiera de los tres modos: Usado recientemente. Subir (una nueva versión). Ingrese el texto (pegue el párrafo correspondiente). Opcionalmente, agregue comentarios personalizados para enfocar la solución, por ejemplo: "Agregue una regla que explícitamente haga que los empleados a tiempo parcial no sean elegibles para la licencia parental". Cuando sus entradas estén listas, elija Iniciar.

La Figura 4 muestra la configuración completa, con el tipo de refinamiento seleccionado, el documento fuente adjunto y los comentarios personalizados ingresados.

Figura 4: Configuración de refinamiento iterativo con un documento fuente y comentarios personalizados

Paso 4: Revisa y acepta los cambios.

Cuando se completa la convergencia, aparece la pantalla Revisar cambios de política. En Cambios en las reglas, enumera dos cambios: una regla eliminada y una regla agregada. El motor eliminó la regla que otorgaba elegibilidad solo para el servicio continuo: si MonthsOfContinuousService es al menos 6, entonces isEligibleForParentalLeave es verdadero.

Y agregó una regla que excluye a los empleados a tiempo parcial:

si el estado de empleo es igual a PART_TIME, entonces isEligibleForParentalLeave es falso

En Resultados de la prueba, la prueba a tiempo parcial pasa de Fallida a Aprobada, y las otras tres pruebas permanecen Aprobadas. La Figura 5 muestra la pantalla antes de aceptar.

Figura 5: La pantalla Revisar cambios de política. Los cambios en las reglas enumeran la regla de elegibilidad de solo permanencia eliminada y la exclusión agregada de tiempo parcial, y los resultados de la prueba muestran que la prueba de tiempo parcial pasa de No aprobado a Aprobado sin regresiones.

Paso 5: confirma la solución

Regrese a la pestaña Pruebas y elija Validar todas las pruebas nuevamente. La Figura 6 muestra el resultado esperado. La prueba que anteriormente reprobaba ahora pasa y la tasa de aprobación alcanza el 100%.

Figura 6: La pestaña Pruebas después del refinamiento, con las cuatro pruebas aprobadas (100%)

Si las pruebas aún fallan o aparecen regresiones

No hay garantía de que un único ciclo de refinamiento resuelva todas las fallas o evite regresiones. Si la prueba que anteriormente había fallado aún falla, o si otras pruebas que previamente pasaron ahora están fallando:

Elija Descartar cambios en la pantalla de revisión. Agregue comentarios personalizados más específicos que describan lo que el motor debería solucionar de manera diferente. Por ejemplo, "La norma debería excluir por completo a los empleados a tiempo parcial, no sólo reducir su ventana de elegibilidad". Limite el documento fuente a la sección exacta que cubre la regla fallida. Ejecute el refinamiento iterativo nuevamente con estas entradas más estrictas.

Si la prueba aún no pasa después de dos o tres rondas, recurra a la edición manual. Utilice la traducción del hallazgo erróneo y el seguimiento de la regla como guía para editar manualmente la regla específica en el editor de políticas.

Paso 6: informar e implementar

Seleccione Generar informe de fidelidad y compare puntuaciones con el informe anterior. Cuando esté satisfecho, cree una versión numerada para implementar.

Tutorial B: Solución de un problema de idioma con refinamiento de variables ambiguas

Tiene la misma política de recursos humanos, pero esta vez una prueba arroja TRANSLATION_AMBIGUOUS. El hallazgo muestra dos opciones:

Uno interpretó “2 años de servicio” como tenureMonths = 24. El otro como mesesDeServicio = 24.

Las dos opciones revelan variables superpuestas. Tanto tenureMonths como MonthOfService describen la duración del empleo y los modelos de traducción no pueden ponerse de acuerdo sobre cuál usar. Esta superposición es la causa fundamental de la ambigüedad.

Paso 1: refinar la política

Elija Refinar política y luego Refinamiento de variable ambigua. Como muestra la Figura 7, no se requiere ningún documento fuente para este modo, por lo que la configuración es una única selección.

Figura 7: Configuración de refinamiento variable ambiguo, sin necesidad de documento fuente

Elija Inicio.

Paso 2: Revisa y acepta los cambios

En la pantalla Revisar cambios de política, revise la combinación de variables propuesta: se elimina MonthOfService. Las reglas se actualizan para hacer referencia a tenureMonths. La descripción de tenureMonths se amplió a: "El número de meses completos que el empleado ha estado empleado continuamente. Cuando los usuarios mencionan años de servicio, conviértalos a meses (por ejemplo, 2 años = 24 meses). Esta variable captura todas las referencias a la duración del empleo, la duración del servicio, el tiempo en la empresa o la antigüedad". En Resultados de la prueba, la prueba que antes era ambigua ahora produce un resultado VÁLIDO definitivo. Seleccione Aceptar cambios.

Paso 3: confirma la solución

Regrese a la pestaña Pruebas y elija Validar todas las pruebas nuevamente. La figura 8 muestra la confirmación. La prueba que anteriormente arrojaba TRANSLATION_AMBIGUOUS ahora produce un resultado VÁLIDO definitivo y pasa.

Figura 8: Pestaña Pruebas después de aplicar el refinamiento de ambigüedad

Paso 4: informar e implementar

Elija Generar informe de fidelidad y compare las puntuaciones con el informe anterior. Cuando esté satisfecho con los resultados, cree una versión numerada para implementar.

Nota

En ambos modos de refinamiento, no hay garantía de que la prueba pase o que los cambios propuestos no introduzcan regresiones. Si la prueba no pasa o si otras pruebas aprobadas ahora fallan, puede descartar los cambios e intentarlo nuevamente.

Mejores prácticas y casos de uso del mundo real

El motor de refinamiento funciona mejor cuando le das una señal clara y un cambio acotado. Las siguientes prácticas muestran cómo y los casos de uso muestran dónde dan sus frutos.

Mejores prácticas

Las siguientes prácticas provienen de las dos formas más comunes en que el refinamiento se desvía. O lo conduces con una señal de falla ambigua o dejas que cambie más la política de lo que pretendías.

Lea la traducción antes de elegir un modo. Abra el hallazgo fallido y observe primero las asignaciones de variables. Si las variables correctas tienen los valores correctos pero el resultado es incorrecto, ese es un problema de reglas para el refinamiento iterativo. Si las asignaciones son incorrectas o el resultado es TRANSLATION_AMBIGUOUS, se trata de un problema de idioma para el refinamiento de variables ambiguas. Elegir el modo por síntoma en lugar de inspeccionar la traducción es la causa más frecuente de un refinamiento que “arregla” lo incorrecto. Alcance las entradas para limitar el cambio. Refinar con un documento fuente con alcance a una sola parte de su política (por ejemplo, elegibilidad para la licencia parental). Combínelo con comentarios específicos si-entonces cuando solo necesite que se corrija una regla. Los aportes enfocados producen propuestas más estrictas y revisables que apuntar el motor a un manual de 40 páginas con pautas vagas como “arreglar la regla de tenencia”. Resultados de la prueba de confianza sobre la diferencia. La pantalla de revisión muestra tanto las reglas modificadas como su efecto en cada prueba guardada. El panel de resultados de pruebas es quien toma las decisiones: acepte cuando sus pruebas reprobadas pasen a ser aprobatorias y sus pruebas aprobatorias permanezcan en verde. Una diferencia de aspecto limpio que retrocede una prueba que pasó anteriormente no es una solución. Compare Fidelity Reports antes de versionar. El refinamiento optimiza para hacer pasar las pruebas. Esa optimización puede desviar una regla de lo que realmente dice su documento fuente. Después de aceptar, compare la puntuación de precisión con la ejecución previa al refinamiento. Una caída indica una deriva y es una razón para rechazar e iterar en lugar de volver a ejecutar a ciegas. Una vez que se pasan las pruebas y el informe se mantiene, cree una versión numerada para promover el cambio a producción.

Casos de uso del mundo real

Estos patrones se aplican en todas las industrias reguladas. En escenarios de elegibilidad de RR.HH., el manual del empleado se actualiza anualmente y Iterative Refinement ingiere el nuevo documento y propone cambios en las reglas para que el equipo de RR.HH. pueda revisarlo sin tocar la lógica formal. En los servicios financieros, las variables superpuestas, como el ratio deuda-ingresos y DTI, provocan ambigüedad en la traducción de las frases de los clientes, y el refinamiento de variables ambiguas las consolida para respaldar la validación determinista. Cuando se revisan los protocolos clínicos, los equipos de cumplimiento sanitario cargan la nueva directriz. Iterative Refinement propone actualizaciones de reglas y el equipo valida la propuesta antes de pasar a producción. En el control de calidad de fabricación, las tolerancias se ajustan con el tiempo y el equipo refina las políticas de forma iterativa mientras mantiene un seguimiento de auditoría a través de instantáneas versionadas e informes de Fidelity.

Conclusión

Los equipos que envían IA generativa a dominios regulados han pagado un impuesto oculto: el mantenimiento de políticas.

El refinamiento automático de las políticas cambia la ecuación laboral sin cambiar la ecuación de autoridad.

La dicotomía reglas versus lenguaje. Cuando la lógica es incorrecta (reglas demasiado permisivas, demasiado estrictas o faltantes), Iterative Refinement propone correcciones de lógica formal basadas en su documento fuente y sus comentarios. Cuando el lenguaje es incorrecto (variables superpuestas, descripciones vagas, formatos inconsistentes), Ambiguous Variable Refinement propone definiciones de variables precisas que fusionan interpretaciones en competencia en una sola.

La puerta de aprobación. En ambos casos, el sistema sugiere y tú decides. Cada cambio propuesto aparece en una pantalla de revisión que muestra la diferencia y su impacto en las pruebas guardadas. Ningún cambio llega a su BORRADOR de política, y mucho menos a producción, sin su aprobación explícita. Automático en el parto. Guiado en autoridad.

Tu próximo paso

Si aún no tiene una política de razonamiento automatizado con pruebas adjuntas, comience creando una política a partir de un documento fuente y agregando pruebas que cubran sus escenarios clave. Consulte la sección Requisitos previos para obtener enlaces. Con una política y al menos una prueba fallida en la mano, elija una prueba fallida hoy e inspeccione el hallazgo. Si la traducción es correcta pero el resultado es incorrecto, ejecute el Refinamiento iterativo con un documento fuente enfocado. Si el resultado es TRANSLATION_AMBIGUOUS, ejecute el Refinamiento de variables ambiguas.

Acepte la propuesta, vuelva a probar y compare los informes de Fidelity antes y después. Tendrá una política más estricta, verificada con hasta un 99% de precisión en traducciones inequívocas (consulte el anuncio de GA), sin tener que escribir a mano una sola línea de lógica formal.

Recursos

Acerca de la cifra de precisión del 99%

La cifra del 99% citada en la introducción y la conclusión se refiere a la precisión de la verificación que mide la tasa de hallazgos correctos (VÁLIDOS, NO VÁLIDOS o SATISFIABLES) dada una traducción inequívoca del lenguaje natural a la lógica formal. Se publicó por primera vez en el anuncio de GA, Minimice las alucinaciones de IA y ofrezca hasta un 99 % de precisión de verificación con comprobaciones de razonamiento automatizado: ahora disponible (Blog de noticias de AWS, 6 de agosto de 2025).

Sobre los autores