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.
Integre las comprobaciones de razonamiento automatizadas en su aplicación
Después de implementar tu política de razonamiento automatizado en una barrera (consulteImplementación de la política de razonamiento automatizado en su aplicación), puedes usarla en tiempo de ejecución para validar las respuestas de la LLM y tomar medidas en función de los comentarios. En esta página, se explica cómo utilizar la API de validación, interpretar los resultados mediante programación e implementar patrones de integración comunes, como reescribir las respuestas no válidas y formular preguntas aclaratorias.
Las comprobaciones de razonamiento automatizadas solo funcionan en modo de detección: devuelven resultados y comentarios en lugar de bloquear el contenido. Tu aplicación es responsable de decidir qué hacer con los resultados: entregar la respuesta, reescribirla, pedir aclaraciones o volver a un comportamiento predeterminado.
Información general de la integración
En tiempo de ejecución, la integración sigue este flujo:
User question ──► LLM generates response ──► ApplyGuardrail validates response │ ┌─────────┴─────────┐ │ │ VALID Not VALID │ │ ▼ ▼ Serve response Inspect findings to user │ ┌────────┴────────┐ │ │ OTHER FINDING TRANSLATION_ TYPES AMBIGUOUS / SATISFIABLE │ │ ▼ ▼ Rewrite using Ask user for AR feedback clarification │ │ ▼ ▼ Validate again Validate with clarified input
Los resultados de Automated Reasoning se devuelven a través de cualquier API que admita una configuración de Amazon Bedrock Guardrails:
-
ApplyGuardrail— API de validación independiente. Utilícela cuando desee validar el contenido independientemente de la invocación al LLM. Este es el enfoque recomendado para las comprobaciones de razonamiento automatizadas porque te da un control total sobre qué contenido se valida y cuándo. -
ConverseyInvokeModel: invocación de LLM APIs con configuración de barandilla. Los resultados del razonamiento automatizado se devuelven en eltracecampo de la respuesta. -
InvokeAgentyRetrieveAndGenerate: agente y base de conocimientos APIs con configuración de barandilla.
Esta página se centra en la ApplyGuardrail API porque proporciona la mayor flexibilidad para implementar los patrones de reescritura y aclaración que se describen a continuación. Para obtener información sobre el uso de barandillas con las otras APIs, consulte Uso de una barandilla.
Ejemplo de chatbot de reescritura de código abierto
Para obtener una implementación completa y al estilo de producción de los patrones descritos en esta página, consulta las comprobaciones de razonamiento automático sobre cómo reescribir el chatbot
-
Un ciclo de reescritura iterativo en el que las respuestas no válidas se corrigen automáticamente en función de la retroalimentación de la realidad aumentada.
-
Haga un seguimiento de las preguntas cuando el LLM necesite más contexto por parte del usuario para reescribirlo con precisión.
-
Un mecanismo de tiempo de espera que reanuda automáticamente el procesamiento cuando los usuarios no responden a las preguntas aclaratorias.
-
Inyectar el contexto de las políticas en las solicitudes del LLM para que el LLM pueda consultar todas las reglas de la política durante la reescritura.
-
Registro de auditoría en JSON de cada iteración de validación para comprobar su conformidad y depuración.
El ejemplo utiliza un Python/Flask backend con una interfaz de React y se comunica con Amazon Bedrock para la inferencia LLM y con Amazon Bedrock Guardrails para la validación a través de la API. ApplyGuardrail
nota
La aplicación de muestra incluye el contenido de la política directamente en las instrucciones de generación del LLM para respaldar cualquier política de razonamiento automatizado sin necesidad de cargar documentos. En una implementación de producción, normalmente utilizarías contenido RAG o enviarías al LLM el documento original en lenguaje natural en lugar del código fuente de la política de razonamiento automatizado.
Llame ApplyGuardrail con comprobaciones de razonamiento automatizadas
Usa la ApplyGuardrail API para validar el contenido comparándolo con tus barreras. La API acepta uno o más bloques de contenido y devuelve una evaluación que incluye los resultados del razonamiento automatizado.
Estructura de la solicitud
guardrailIdentifier(obligatorio)-
El ID o ARN de la barandilla. Utilice la barandilla que tiene adjunta su política de razonamiento automático.
guardrailVersion(obligatorio)-
El número de versión de la barandilla (por ejemplo,).
1Utilice una versión numerada para las cargas de trabajo de producción, no.DRAFT source(obligatorio)-
Configúrelo
OUTPUTal validar las respuestas de LLM. Se establece enINPUTCuando se validan las solicitudes de los usuarios. En el caso de las comprobaciones de razonamiento automatizadas, normalmente se valida el resultado del LLM. content(obligatorio)-
Un conjunto de bloques de contenido para validar. Cada bloque contiene un
textcampo con el contenido que se debe comprobar. Puede pasar la pregunta del usuario y la respuesta de LLM como bloques de contenido separados o combinarlos en un solo bloque.
Ejemplo: valide una respuesta de LLM mediante el AWS CLI
aws bedrock-runtime apply-guardrail \ --guardrail-identifier "your-guardrail-id" \ --guardrail-version "1" \ --source OUTPUT \ --content '[ { "text": { "text": "User: Am I eligible for parental leave if I have been working here for 2 years full-time?\nAssistant: Yes, you are eligible for parental leave." } } ]'
Ejemplo: validar una respuesta LLM con Python (boto3)
import boto3 import json bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") response = bedrock_runtime.apply_guardrail( guardrailIdentifier="your-guardrail-id", guardrailVersion="1", source="OUTPUT", content=[ { "text": { "text": ( "User: Am I eligible for parental leave if I have been " "working here for 2 years full-time?\n" "Assistant: Yes, you are eligible for parental leave." ) } } ], ) # The AR findings are in the assessments for assessment in response.get("assessments", []): ar_assessment = assessment.get("automatedReasoningPolicy", {}) findings = ar_assessment.get("findings", []) for finding in findings: # Each finding is a union — exactly one key is present # Possible keys: valid, invalid, satisfiable, impossible, # translationAmbiguous, tooComplex, noTranslations print(json.dumps(finding, indent=2, default=str))
Estructura de una respuesta
La ApplyGuardrail respuesta incluye una matriz. assessments Cada evaluación contiene un automatedReasoningPolicy objeto con una findings matriz. Cada hallazgo es de un tipo de unión; está presente exactamente una de las siguientes claves:
validinvalidsatisfiableimpossibletranslationAmbiguoustooComplexnoTranslations
Para obtener una descripción detallada de cada tipo de hallazgo y sus campos, consulteHallazgos y resultados de la validación.
Interprete los hallazgos de AR en tiempo de ejecución
Para actuar de forma programática sobre los hallazgos del Razonamiento Automatizado, tu aplicación debe extraer el tipo de hallazgo, los detalles de la traducción y las reglas que las respaldan o contradicen. En las siguientes secciones se explica cómo analizar cada parte de un hallazgo.
Determine el tipo de hallazgo
Cada hallazgo es una unión: existe exactamente una clave. Compruebe qué clave existe para determinar el tipo de hallazgo:
def get_finding_type(finding): """Return the finding type and its data from an AR finding union.""" for finding_type in [ "valid", "invalid", "satisfiable", "impossible", "translationAmbiguous", "tooComplex", "noTranslations" ]: if finding_type in finding: return finding_type, finding[finding_type] return None, None
Lea la traducción
La mayoría de los tipos de búsqueda incluyen un translation objeto que muestra cómo las comprobaciones de razonamiento automatizadas tradujeron la entrada del lenguaje natural en lógica formal. La traducción contiene:
-
premises— Las condiciones extraídas de la entrada (por ejemplo,isFullTime = true,tenureMonths = 24). -
claims— Las afirmaciones que se van a validar (por ejemplo,eligibleForParentalLeave = true). -
untranslatedPremises— Partes de la entrada que no se pudieron asignar a variables de política. Estas partes no están validadas. -
untranslatedClaims— Afirmaciones que no se pudieron asignar a variables de política.
Compruebe untranslatedPremises y untranslatedClaims comprenda el alcance de la validación. VALIDEl resultado solo cubre las afirmaciones traducidas; el contenido no traducido no se verifica.
Lee las reglas que respaldan o contradicen
Según el tipo de hallazgo, el hallazgo incluye reglas que explican el resultado:
-
validlos resultados incluyensupportingRules: las reglas de la póliza que prueban que las afirmaciones son correctas. -
invalidlos hallazgos incluyencontradictingRules: las reglas de la política que infringen las reclamaciones. -
satisfiablelos resultados incluyenclaimsTrueScenariotanto a como aclaimsFalseScenario, que muestran las condiciones en las que las afirmaciones son verdaderas y falsas.
Estas reglas y escenarios son las entradas clave para el patrón de reescritura descrito enReescribe las respuestas no válidas con comentarios de realidad aumentada.
Determine el resultado agregado
Una sola solicitud de validación puede arrojar varios resultados. Para determinar el resultado general, clasifique los hallazgos por gravedad y seleccione los peores. El orden de gravedad de peor a mejor es:TRANSLATION_AMBIGUOUS,IMPOSSIBLE,INVALID,SATISFIABLE,VALID.
SEVERITY_ORDER = { "tooComplex": 0, "translationAmbiguous": 0, "impossible": 1, "invalid": 2, "satisfiable": 3, "valid": 4, "noTranslations": 5, } def get_aggregate_result(findings): """Return the worst finding type from a list of findings.""" worst = None worst_severity = float("inf") for finding in findings: finding_type, _ = get_finding_type(finding) severity = SEVERITY_ORDER.get(finding_type, 0) if severity < worst_severity: worst_severity = severity worst = finding_type return worst
Gestione los resultados de la validación en su aplicación
Utilice el resultado agregado para decidir qué hará su aplicación a continuación. En la siguiente tabla se resume la acción recomendada para cada tipo de resultado.
| Resultado | Qué significa | Acción recomendada |
|---|---|---|
valid |
Se ha demostrado matemáticamente que la respuesta es correcta teniendo en cuenta las premisas y las normas de su política. | Entregue la respuesta al usuario. Registre el resultado con fines de auditoría (consulteCree un registro de auditoría). |
invalid |
La respuesta contradice las normas de su política. El contradictingRules campo identifica qué reglas se infringieron. |
Reescriba la respuesta utilizando los comentarios de AR (consulteReescribe las respuestas no válidas con comentarios de realidad aumentada). Si la reescritura falla después de varios intentos, bloquea la respuesta y devuelve un mensaje alternativo. |
satisfiable |
La respuesta es correcta en algunas condiciones, pero no en todas. No está mal, pero está incompleta: no menciona todos los requisitos. | Vuelva a escribir la respuesta para incluir las condiciones que faltan. Usa el claimsFalseScenario para identificar lo que falta. Alternativamente, puede dejar que su LLM haga preguntas aclaratorias al usuario. |
impossible |
Las premisas son contradictorias o la política contiene reglas contradictorias. | Pida al usuario que aclare lo que ha introducido (consulteHaga preguntas aclaratorias). Si el problema persiste, puede indicar un problema de política: revise el informe de calidad. |
translationAmbiguous |
La entrada tiene varias interpretaciones válidas. Los modelos de traducción no estuvieron de acuerdo sobre cómo asignar el lenguaje natural a las variables políticas. | Pide al usuario una aclaración para resolver la ambigüedad. Utilice los differenceScenarios campos options y para generar preguntas aclaratorias específicas. |
tooComplex |
La entrada supera los límites de procesamiento para el análisis lógico. | Simplifique la entrada dividiéndola en partes más pequeñas o devuelva un mensaje alternativo que explique que no se pudo verificar la respuesta. |
noTranslations |
La entrada no es relevante para el ámbito de su política. No se pudo mapear ninguna variable de política. | El contenido no está relacionado con el tema de esta política. Publica la respuesta sin necesidad de validar la realidad aumentada o utiliza otros componentes de protección (como las políticas temáticas) para gestionar el contenido no relacionado con el tema. |
Reescribe las respuestas no válidas con comentarios de realidad aumentada
El patrón de integración más eficaz para las comprobaciones de razonamiento automatizadas es el ciclo de reescritura: cuando una respuesta es invalid osatisfiable, la aplicación crea un mensaje que incluye la respuesta original, los hallazgos específicos y las reglas de la política, y luego pide al LLM que reescriba la respuesta para que sea coherente con la política. La respuesta reescrita se valida de nuevo y el ciclo continúa hasta que la respuesta se alcanza valid o se alcanza un número máximo de iteraciones.
Flujo del bucle de reescritura
LLM generates initial response │ ▼ Validate with ApplyGuardrail ◄──────────────────┐ │ │ ▼ │ ┌─────┴─────┐ │ │ │ │ VALID Not VALID │ │ │ │ ▼ ▼ │ Done Construct rewriting prompt │ with findings + rules │ │ │ ▼ │ LLM rewrites response │ │ │ ▼ │ Max iterations? ──── No ────────────────┘ │ Yes │ ▼ Return best response with warning
Construye el mensaje de reescritura
El mensaje de reescritura debe incluir tres datos extraídos de los hallazgos de la AR:
-
La respuesta original que no pasó la validación.
-
La conclusión específica, incluidas las premisas traducidas, las afirmaciones y las normas contradictorias o que las respaldan.
-
Una instrucción para reescribir la respuesta para que sea coherente con las normas de la política.
Ejemplo de plantilla de mensaje de reescritura:
The following response was checked against our policy and found to be {finding_type}. Original response: {original_response} The validation found the following issue: - Premises (what was understood from the input): {premises} - Claims (what was asserted): {claims} - Contradicting rules: {contradicting_rules} Please rewrite the response so that it is consistent with the policy document. Keep the same helpful tone and answer the user's question accurately based on the rules. If you cannot provide an accurate answer without more information, explain what additional information is needed.
sugerencia
Incluya siempre el contenido de la generación aumentada de recuperación (RAG) en sus solicitudes de reescritura o en las reglas de política para que el LLM tenga todo el contexto que necesita al reescribirlo. La plantilla de solicitud de reescritura proporciona los detalles de búsqueda específicos, mientras que la solicitud del sistema proporciona un contexto político más amplio. Este enfoque de doble contexto se demuestra en el ejemplo de chatbot de reescritura de código abierto
Mejores prácticas de reescritura
-
Establece un recuento máximo de iteraciones. El bucle de reescritura debe tener un límite estricto (normalmente de 2 a 5 iteraciones) para evitar bucles infinitos. Si la respuesta sigue siendo inferior al máximo
validde iteraciones, devuelve la mejor respuesta con una advertencia o recurre a un mensaje predeterminado. -
Procese los hallazgos en orden de prioridad. Cuando se obtengan varios resultados, aborde primero el más grave. El orden de gravedad es:
translationAmbiguous,impossible,invalid,satisfiable,valid. -
Incluya el contexto de la política en el indicador del sistema. El LLM necesita acceder al documento fuente o a todas las reglas de política para reescribirse con precisión. Puede utilizar una base de conocimientos para incluir sus documentos en la solicitud de generación o utilizar la
ExportAutomatedReasoningPolicyVersionAPI para recuperar la definición de la política y darle formato para el LLM. -
Registra cada iteración. Registre la respuesta original, los resultados, la solicitud de reescritura y la respuesta reescrita para cada iteración. Esta pista de auditoría es valiosa para la depuración y el cumplimiento (consulte). Cree un registro de auditoría
Haga preguntas aclaratorias
Cuando las comprobaciones de razonamiento automatizado translationAmbiguous satisfiable arrojen impossible resultados o resulten, es posible que el LLM no tenga suficiente información para reescribir la respuesta con precisión. En estos casos, la aplicación puede solicitar una aclaración al usuario y, a continuación, incorporar las respuestas en el siguiente intento de validación.
¿Cuándo pedir una aclaración
-
translationAmbiguous— La entrada tiene múltiples interpretaciones válidas. Eloptionscampo muestra las interpretaciones contrapuestas y eldifferenceScenarioscampo muestra en qué se diferencian en la práctica. Úselos para generar preguntas específicas sobre la ambigüedad específica. -
satisfiable— La respuesta es correcta en algunas condiciones, pero no en todas.claimsFalseScenarioMuestra las condiciones en las que la respuesta sería incorrecta. Pregúntele al usuario acerca de esas condiciones específicas. -
impossible— La entrada contiene afirmaciones contradictorias. Pide al usuario que aclare la contradicción. -
La reescritura falla: si el LLM no puede reescribir la respuesta
validdespués de varios intentos, es posible que necesite más contexto por parte del usuario. Pídale al LLM que genere preguntas aclaratorias basadas en los hallazgos.
Patrón de aclaración
El flujo de clarificación funciona de la siguiente manera:
-
Extraiga las variables ambiguas o las condiciones faltantes de los hallazgos de la AR.
-
Genere preguntas aclaratorias, ya sea mediante programación a partir de los campos de búsqueda o solicitando al LLM que formule preguntas en función de los hallazgos.
-
Presente las preguntas al usuario y recopile las respuestas.
-
Incorpora las respuestas al contexto y genera una nueva respuesta.
-
Valide la nueva respuesta con
ApplyGuardrail.
Ejemplo: generar preguntas aclaratorias a partir de un hallazgo satisfiable
def generate_clarifying_questions(finding_data, user_question): """Ask the LLM to generate clarifying questions from a SATISFIABLE finding.""" claims_true = json.dumps( finding_data.get("claimsTrueScenario", {}), indent=2, default=str ) claims_false = json.dumps( finding_data.get("claimsFalseScenario", {}), indent=2, default=str ) prompt = ( f"A user asked: {user_question}\n\n" f"The answer is correct when these conditions hold:\n{claims_true}\n\n" f"But incorrect when these conditions hold:\n{claims_false}\n\n" f"Generate 1-3 short, specific questions to ask the user to determine " f"which conditions apply to their situation. Format each question on " f"its own line." ) return generate_response(prompt, "You are a helpful assistant.")
Cree un registro de auditoría
Los resultados del razonamiento automatizado proporcionan una prueba de validez matemáticamente verificable. En el caso de los sectores regulados y los escenarios de cumplimiento, esta prueba es un elemento diferenciador clave: se puede demostrar que la respuesta de la IA se verificó con arreglo a normas políticas específicas con asignaciones de variables específicas, y no solo se comparó con patrones o se evaluó probabilísticamente.
Para crear un registro de auditoría eficaz, registre la siguiente información para cada solicitud de validación:
-
Marca de tiempo e ID de solicitud. Cuándo se produjo la validación y un identificador único para la solicitud.
-
Contenido de entrada. La pregunta del usuario y la respuesta de LLM que se validaron.
-
Buscar el tipo y los detalles. El resultado de la validación (
valid,invalid, etc.), las premisas y afirmaciones traducidas y las normas que las respaldan o contradicen. -
Acción emprendida. Qué hizo su solicitud con la conclusión: presentó la respuesta, la reescribió, pidió aclaraciones o la bloqueó.
-
Reescribir el historial. Si la respuesta se reescribió, registre cada iteración: la respuesta original, la solicitud de reescritura, la respuesta reescrita y el resultado de la validación de cada iteración.
-
Versión de la política. La versión de barandilla y la versión de la política utilizadas para la validación. Esto garantiza que pueda reproducir el resultado de la validación más adelante.
Ejemplo: estructura de entradas del registro de auditoría
{ "timestamp": "2025-07-21T14:30:00Z", "request_id": "req-abc123", "guardrail_id": "your-guardrail-id", "guardrail_version": "1", "user_question": "Am I eligible for parental leave?", "llm_response": "Yes, you are eligible for parental leave.", "validation_result": "valid", "findings": [ { "type": "valid", "premises": "isFullTime = true, tenureMonths = 24", "claims": "eligibleForParentalLeave = true", "supporting_rules": ["A1B2C3D4E5F6"] } ], "action_taken": "served_response", "rewrite_iterations": 0 }
sugerencia
Guarde los registros de auditoría en un almacén duradero y a prueba de manipulaciones, como Amazon CloudWatch Logs o Amazon S3, con el bloqueo de objetos activado. Para situaciones de conformidad, considere la posibilidad de utilizar Lake para consultar los registros de auditoría de toda su organización.