View a markdown version of this page

Prueba de una política de razonamiento automatizado - Amazon Bedrock
Estrategia de pruebas: escenarios frente a pruebas de QnAGenere escenarios de prueba automáticamente en la consolaGenera escenarios de prueba automáticamente mediante la APICree una prueba de QnA manualmente en la consolaCree una prueba de QnA mediante la APIEjecute las pruebasComprenda los resultados de las pruebas

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.

Prueba de una política de razonamiento automatizado

Las pruebas validan que las reglas de su política son correctas y que las comprobaciones de razonamiento automatizadas pueden traducir con precisión el lenguaje natural en lógica formal. Para probar una política, se envían declaraciones en lenguaje natural para su validación y, a continuación, se inspeccionan los comentarios para garantizar que la traducción utilice las variables correctas y que las reglas produzcan los resultados esperados.

Existen dos enfoques de prueba complementarios: escenarios generados y pruebas question-and-answer (QnA). Cada uno se dirige a una parte diferente del proceso de validación. El flujo de trabajo recomendado consiste en empezar con escenarios para validar la exactitud de las reglas y, a continuación, añadir pruebas de QnA para validar la precisión de la traducción.

Estrategia de pruebas: escenarios frente a pruebas de QnA

Las comprobaciones de razonamiento automatizadas validan el contenido en dos pasos: primero, los modelos básicos traducen el lenguaje natural a una lógica formal; después, las técnicas matemáticas comprueban la lógica según las normas de su política. Cada enfoque de prueba apunta a un paso diferente de este proceso.

Escenarios generados (comprobar la exactitud de las reglas)

Los escenarios generados prueban directamente la semántica codificada en las reglas de su política. Eliminan la incertidumbre de la traducción al lenguaje natural de la ecuación y aíslan si las reglas en sí mismas son correctas.

Los escenarios se generan a partir de las reglas de su política y representan situaciones que son lógicamente posibles con arreglo a esas reglas. Se ordenan para mostrar primero la mayoría de los likely-to-be-wrong escenarios. Para cada escenario, usted revisa las asignaciones de variables y decide:

  • Pulgar hacia arriba: el escenario es realista y, de hecho, debería ser posible. Guárdalo como SATISFIABLE prueba.

  • Pulgares hacia abajo: algo anda mal. Este escenario no debería ser posible dado el conocimiento de tu dominio. Proporciona comentarios en lenguaje natural que expliquen por qué, y las comprobaciones de razonamiento automatizadas intentarán deducir los cambios necesarios en las reglas.

Ejemplo: tu política establece que los empleados a tiempo completo con más de 12 meses de antigüedad tienen derecho a la licencia parental. Es posible que aparezca un escenario generado. isFullTime = true, tenureMonths = 3, eligibleForParentalLeave = true Si este escenario no fuera posible (porque 3 meses son menos de 12), lo rechazarías y explicarías que los empleados necesitan al menos 12 meses de antigüedad. Esto indica que falta una regla o que es incorrecta.

Utilice los escenarios como primer paso de la prueba. Le ayudan a detectar problemas con las reglas antes de invertir tiempo en escribir pruebas de QnA.

Pruebas de QnA (prueban la precisión de la traducción)

Las pruebas de QnA validan todo el proceso end-to-end: la traducción al lenguaje natural y la validación de reglas juntas. Imitan las interacciones reales de los usuarios y detectan problemas de traducción que los escenarios no pueden detectar.

Cada prueba de QnA consiste en:

  • Una entrada (opcional): la pregunta que un usuario podría hacerle a su aplicación.

  • Un resultado: la respuesta que podría generar su modelo básico.

  • Un resultado esperado: el resultado de validación que espera (por ejemplo, VALID oINVALID).

Ejemplo: para la misma política de licencia parental, una prueba de QnA podría ser: input = «Llevo dos años trabajando aquí a tiempo completo. ¿Puedo solicitar un permiso parental?» , output = «Sí, tiene derecho a la licencia parental. «, resultado esperado =VALID. Esto comprueba si las comprobaciones de razonamiento automático traducen correctamente «2 años» a tenureMonths = 24 y «tiempo completo» aisFullTime = true.

sugerencia

Cree pruebas que cubran escenarios válidos e inválidos. Por ejemplo, si tu política establece que «los empleados necesitan 1 año de servicio para obtener la licencia por paternidad», crea pruebas para las respuestas que indiquen correctamente esta regla y para las respuestas que indiquen incorrectamente un requisito diferente.

  1. Genere y revise escenarios. Comience aquí para validar que sus reglas son correctas. Corrija cualquier problema con las reglas antes de continuar.

  2. Escribe pruebas de QnA para los casos de uso clave. Céntrate en las preguntas que es más probable que hagan tus usuarios y en las respuestas que es más probable que genere tu LLM. Incluya los casos límite y las condiciones límite.

  3. Ejecute todas las pruebas. Compruebe que se aprueban tanto los escenarios como las pruebas de QnA.

  4. Itera. Si las pruebas fallan, determine si el problema está en las reglas (corrija la política) o en la traducción (mejore las descripciones de las variables). Para obtener más información, consulte Solucione problemas y perfeccione su política de razonamiento automatizado.

Genere escenarios de prueba automáticamente en la consola

  1. Vaya a la política de razonamiento automatizado que desee probar (por ejemplo, MyHrPolicy).

  2. Elija Ver pruebas y, a continuación, seleccione Generar.

  3. En el cuadro de diálogo Generar escenarios, revise el escenario generado y las reglas relacionadas. Cada escenario muestra un conjunto de asignaciones de variables que son lógicamente posibles según las reglas de su política. Evalúe si el escenario es realista en su dominio:

    • Si la situación pudiera ocurrir en tu dominio (es aceptable), selecciona el icono con el pulgar hacia arriba. Esto guarda el escenario como una prueba en la que se espera un SATISFIABLE resultado.

    • Si el escenario no fuera posible, selecciona el icono con el pulgar hacia abajo. Incluye una anotación que explique por qué, por ejemplo, «Los empleados necesitan al menos 12 meses en el cargo para poder disfrutar de la licencia parental, pero en este escenario se muestran tres meses si cumplen los requisitos». Las comprobaciones de razonamiento automatizadas utilizan tus comentarios para deducir los cambios en las reglas que evitarían esta situación.

    • Si quieres un escenario diferente, elige Regenerar el escenario.

    sugerencia

    Para inspeccionar la versión lógica formal del escenario, habilite Mostrar SMT-LIB. Esto es útil para entender exactamente qué reglas y asignaciones de variables están involucradas.

  4. Seleccione Guardar y cerrar para guardar la prueba o Guardar y añadir otra para seguir revisando los escenarios.

  5. Si has proporcionado anotaciones (comentarios con el visto bueno) a algún escenario, selecciona Aplicar anotaciones. Las comprobaciones de razonamiento automatizadas iniciarán un flujo de trabajo de creación para aplicar los cambios a tu política en función de tus comentarios.

  6. En la pantalla Revisar los cambios de política, revisa los cambios propuestos a las reglas, variables y tipos de variables de tu política. A continuación, seleccione Aceptar cambios.

Genera escenarios de prueba automáticamente mediante la API

Usa la GetAutomatedReasoningPolicyNextScenario API para buscar los escenarios de prueba generados en función de las reglas de tu política.

policyArn (obligatorio)

El ARN de la política de razonamiento automatizado.

buildWorkflowId (obligatorio)

El identificador del flujo de trabajo de compilación para los escenarios generados. Recupera el último flujo de trabajo de compilación mediante la ListAutomatedReasoningPolicyBuildWorkflows API.

Ejemplo:

aws bedrock get-automated-reasoning-policy-next-scenario \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690

La respuesta incluye un escenario generado con asignaciones de variables y las reglas de política relacionadas. Revisa el escenario y usa la CreateAutomatedReasoningPolicyTestCase API para guardarlo como una prueba, o usa la anotación APIs para enviar comentarios si el escenario revela un problema con la regla.

Cree una prueba de QnA manualmente en la consola

  1. Vaya a la política de razonamiento automatizado que desee probar (por ejemplo, MyHrPolicy).

  2. Elija Ver pruebas y, a continuación, seleccione Agregar.

  3. En el cuadro de diálogo Agregar pruebas, haga lo siguiente:

    1. En Entrada (opcional), introduce la pregunta que pueda hacer un usuario. En Salida, introduzca la respuesta que pueda proporcionar su modelo base. En conjunto, forman un par QnA que comprueba cómo su política valida las interacciones reales de los usuarios.

    2. Elija el resultado que espera de la prueba (por ejemplo, Válidoo No válido).

    3. (Opcional) Seleccione un umbral de confianza, que es el nivel de confianza mínimo para la validación lógica. Las comprobaciones de razonamiento automatizadas utilizan varios LLMs para traducir el lenguaje natural en hallazgos. Solo devuelve los hallazgos respaldados por un porcentaje significativo de las traducciones de LLM. El umbral de confianza define el porcentaje mínimo de respaldo necesario para que una traducción se convierta en una conclusión con un resultado válido. Los hallazgos por debajo del umbral aparecen como. TRANSLATION_AMBIGUOUS

  4. Seleccione Guardar para crear la prueba.

Cree una prueba de QnA mediante la API

Utilice la CreateAutomatedReasoningPolicyTestCase API para crear una prueba mediante programación.

policyArn (obligatorio)

El ARN de la política de razonamiento automatizado.

queryContent (opcional)

La consulta o el mensaje de entrada que generó el contenido, como la pregunta del usuario. Esto proporciona el contexto para la validación.

guardContent (obligatorio)

El contenido de salida que se va a validar: la respuesta del modelo básico cuya precisión se comprobará.

expectedAggregatedFindingsResult (opcional)

El resultado de validación esperado (por ejemplo, VALID oINVALID). El resultado real se determina clasificando los resultados por orden de gravedad y seleccionando el peor resultado. El orden de gravedad de peor a mejor es:TRANSLATION_AMBIGUOUS,IMPOSSIBLE,INVALID,SATISFIABLE,VALID.

confidenceThreshold (opcional)

El nivel de confianza mínimo para la validación lógica.

Ejemplo:

aws bedrock create-automated-reasoning-policy-test-case \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --query-content "Can I take a leave of absence if I'm a part-time employee?" \
  --guard-content "No, only full-time employees are eligible for leave of absence." \
  --expected-aggregated-findings-result "VALID" \
  --confidence-threshold 0.8

Ejemplo de respuesta:

{
  "testCaseId": "test-12345abcde",
  "policyArn": "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk"
}

Ejecute las pruebas

Ejecución de pruebas en la consola

  1. Ve a la política de razonamiento automatizado que deseas validar (por ejemplo, MyHrPolicy).

  2. Elija Ver elementos.

  3. Realice una de las siguientes acciones:

    • Para ejecutar todas las pruebas, selecciona Validar todas las pruebas.

    • Para ejecutar una sola prueba, selecciona el botón Acción situado junto a la prueba y selecciona Validar.

Ejecución de las pruebas con la API

Usa la StartAutomatedReasoningPolicyTestWorkflow API para ejecutar las pruebas y la GetAutomatedReasoningPolicyTestResult API para recuperar los resultados.

policyArn (obligatorio)

El ARN de la política de razonamiento automatizado.

buildWorkflowId (obligatorio)

El identificador del flujo de trabajo de compilación con el que se van a ejecutar las pruebas. Recupera el último flujo de trabajo de compilación mediante la ListAutomatedReasoningPolicyBuildWorkflows API.

testCaseIds (opcional)

Una lista de identificadores de prueba para ejecutar. Si no se proporciona, se ejecutan todas las pruebas de la política.

Ejemplo:

# Run tests
aws bedrock start-automated-reasoning-policy-test-workflow \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690

# Get results for a specific test
aws bedrock get-automated-reasoning-policy-test-result \
  --policy-arn "arn:aws:bedrock:us-east-1:111122223333:automated-reasoning-policy/lnq5hhz70wgk" \
  --build-workflow-id d40fa7fc-351e-47d8-a338-53e4b3b1c690 \
  --test-case-id test-12345abcde

La respuesta incluye los resultados detallados de las pruebas con los resultados de la validación y el estado de ejecución. Para enumerar todos los resultados de las pruebas de un flujo de trabajo de compilación, usa la ListAutomatedReasoningPolicyTestResults API.

Comprenda los resultados de las pruebas

Cuando finaliza una prueba, recibirá un conjunto de resultados. Cada conclusión representa una afirmación fáctica extraída de los datos de la prueba, junto con el resultado de la validación, las asignaciones de variables utilizadas y las normas políticas que respaldan la conclusión. Para obtener una descripción detallada de la estructura de búsqueda y de todos los tipos de resultados de la validación, consulteHallazgos y resultados de la validación.

Anatomía del resultado de una prueba

El resultado de cada prueba incluye:

  • Resultado esperado: el resultado que estableció al crear la prueba.

  • Resultado real: el resultado agregado de la ejecución de la prueba. Esto se determina clasificando los resultados por orden de gravedad y seleccionando el peor resultado. El orden de gravedad de peor a mejor es:TRANSLATION_AMBIGUOUS,IMPOSSIBLE,INVALID,SATISFIABLE,VALID. Por ejemplo, una prueba con dos VALID resultados IMPOSSIBLE y un resultado agregado deIMPOSSIBLE.

  • Resultado de la ejecución: si la prueba se aprobó (los resultados esperados y reales coinciden) o no.

  • Hallazgos: los resultados de la validación individual. Cada conclusión contiene las premisas y afirmaciones traducidas, una puntuación de confianza, la asignación de variables y las normas políticas que respaldan la conclusión.

Interpretación práctica de los resultados

La siguiente tabla resume lo que significa cada resultado de la validación en la práctica y qué medidas se deben tomar cuando se ve en una prueba. Para obtener una referencia completa, incluidos los campos de búsqueda y las descripciones detalladas, consulteReferencia de los resultados de la validación.

Resultado Qué significa Solución
VALID Se ha demostrado matemáticamente que las afirmaciones de la respuesta son correctas, dadas las premisas y las normas de su póliza. La supportingRules conclusión incluye probar las afirmaciones y claimsTrueScenario demostrar su veracidad. Si este es el resultado esperado, la prueba pasa. Compruebe untranslatedPremises y untranslatedClaims busque las partes de la entrada que no se hayan validado; el VALID resultado solo incluye las afirmaciones traducidas.
INVALID Las afirmaciones contradicen las normas de su póliza. El hallazgo incluye contradictingRules mostrar qué reglas se infringieron. Si este es el resultado esperado, la prueba pasa. En caso de imprevisto, compruebe si las reglas son correctas o si la traducción asignó variables incorrectas. Revíselo contradictingRules para comprender qué reglas causaron el resultado.
SATISFIABLE Las reclamaciones son coherentes con tu póliza, pero no abordan todas las normas pertinentes. La respuesta es correcta en algunas condiciones, pero no en todas. La conclusión incluye tanto a claimsTrueScenario como a, claimsFalseScenario que muestran las condiciones en las que las afirmaciones son verdaderas y falsas. Compare los dos escenarios para identificar las condiciones que faltan. Por lo general, esto significa que la respuesta está incompleta; no está mal, pero no menciona todos los requisitos. Considera si la prueba debería ser más completa SATISFIABLE o si la respuesta debería ser más completa.
IMPOSSIBLE Las comprobaciones de razonamiento automatizadas no permiten evaluar las afirmaciones porque las premisas son contradictorias o porque la propia política contiene normas contradictorias. Compruebe si la entrada de la prueba contiene afirmaciones contradictorias (por ejemplo, «Trabajo a tiempo completo y también a tiempo parcial»). Si la entrada es válida, es probable que tu política esté en contradicción: consulta el informe de calidad para ver si hay normas contradictorias. Consulte Solucione problemas y perfeccione su política de razonamiento automatizado.
TRANSLATION_AMBIGUOUS La traducción del lenguaje natural a la lógica formal era ambigua. El múltiplo LLMs utilizado para la traducción no coincidía en la forma de interpretar la entrada. El hallazgo incluye las interpretaciones alternativas para ayudarle a entender el desacuerdo. Por lo general, se trata de un problema de descripción de variables. Revise las interpretaciones alternativas para comprender dónde está el desacuerdo y, a continuación, mejore las descripciones de las variables relevantes. Causas comunes: variables superpuestas, descripciones vagas o texto de entrada ambiguo. Consulte Solucione problemas y perfeccione su política de razonamiento automatizado.
TOO_COMPLEX La entrada contiene demasiada información como para que las comprobaciones de razonamiento automatizadas puedan procesarla dentro de sus límites de latencia. Simplifique la entrada de la prueba. Si el problema persiste, es posible que su política sea demasiado compleja; considere la posibilidad de dividirla en varias políticas específicas o de simplificar las reglas que impliquen aritmética no lineal.
NO_TRANSLATIONS La entrada no se pudo traducir a una lógica formal. Por lo general, esto significa que la entrada no es relevante para el dominio de la política o que la política no tiene variables para modelar los conceptos de la entrada. Si la entrada debe ser relevante para tu política, agrega las variables que faltan y actualiza las reglas. Si la entrada está realmente fuera de tema, este resultado es esperado: tu aplicación debería tratar el contenido no relacionado con el tema por separado (por ejemplo, utilizando las políticas temáticas).

Consejos de depuración para las pruebas fallidas

Si una prueba falla (el resultado real no coincide con el resultado esperado), utilice el siguiente enfoque para diagnosticar el problema:

  1. Comprueba primero la traducción. Observe las premisas y las afirmaciones del hallazgo. ¿Están asignadas las variables correctas? ¿Son correctos los valores? Si la traducción es incorrecta, el problema está en las descripciones de las variables, no en las reglas. Por ejemplo, si se tradujo «2 años» tenureMonths = 2 en lugar detenureMonths = 24, la descripción de la variable debe especificar la conversión de unidades.

  2. Consulta las reglas. Si la traducción parece correcta, el problema está en las reglas de tu póliza. Fíjese en el resultado supportingRules o contradictingRules en el resultado para identificar qué reglas están involucradas. Compárelas con su documento fuente.

  3. Comprueba si hay contenido sin traducir. Mira untranslatedPremises y. untranslatedClaims Si partes importantes de la entrada no se tradujeron, es posible que deba agregar variables para captar esos conceptos.

  4. Compruebe la puntuación de confianza. Una puntuación de confianza baja indica que los modelos de traducción no están de acuerdo. Esto sugiere que las descripciones de las variables son ambiguas para este tipo de entrada.

Para obtener una guía detallada de solución de problemas, consulteSolucione problemas y perfeccione su política de razonamiento automatizado.