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.
Mejora de la precisión añadiendo verificaciones de razonamiento automatizado en Barreras de protección para Amazon Bedrock
Las verificaciones de razonamiento automatizado de Barreras de protección para Amazon Bedrock verifican matemáticamente el contenido en lenguaje natural con respecto a las políticas definidas, lo que garantiza el cumplimiento estricto de las barreras de protección. Estas verificaciones pueden ayudar a bloquear sistemáticamente el contenido dañino o que no cumple las normas antes de que llegue a los usuarios. A diferencia de los enfoques de coincidencia de patrones, el razonamiento automatizado ofrece una mayor precisión con menos falsos positivos, especialmente en el caso de requisitos de políticas complejos. Para los clientes para los que la precisión es una prioridad, las reglas de las políticas se pueden personalizar para mejorar la eficacia de las barreras de protección mediante instrucciones lógicas claras.
Un desafío clave con los modelos lingüísticos de gran tamaño (LLMs) es garantizar la precisión de sus respuestas. Sin validación, a veces LLMs pueden producir alucinaciones o información inexacta que socava la confianza.
Las verificaciones de razonamiento automatizado de Barreras de protección para Amazon Bedrock resuelven este problema mediante el uso de técnicas matemáticas para:
-
Detectar alucinaciones en las respuestas del LLM
-
Resaltar las suposiciones no declaradas
-
Explicar por qué las afirmaciones precisas son correctas
Esta característica es especialmente útil cuando se necesita demostrar la base fáctica de la respuesta de un LLM en:
-
Sectores regulados, como la sanidad y recursos humanos
-
Solicitudes con normas complejas (aprobaciones de hipotecas, leyes de zonificación)
-
Escenarios de cumplimiento que requieren respuestas de IA auditables
Las verificaciones de razonamiento automatizado de Barreras de protección para Amazon Bedrock no protegen contra los ataques de inyección de peticiones. Estas verificaciones validan exactamente lo que usted envía: si se introduce contenido malicioso o manipulado como entrada, la validación se realizará en ese contenido tal cual (“garbage-in, garbage-out”). Para detectar y bloquear los ataques de inyección de peticiones, utilice filtros de contenido en combinación con las verificaciones de razonamiento automatizado.
El razonamiento automatizado solo analiza y detecta el texto que es pertinente para la política de razonamiento automatizado. Ignorará el resto del contenido y no podrá indicar a los desarrolladores si la respuesta se desvía o no del tema. Si necesita detectar respuestas que no estén relacionadas con el tema, utilice otros componentes de barreras de protección, como las políticas de temas.
nota
Las verificaciones de razonamiento automatizado de Barreras de protección para Amazon Bedrock están disponibles con carácter general en las regiones de EE. UU. (Norte de Virginia, Oregón y Ohio) y de la UE (Fráncfort, París e Irlanda).
nota
Las verificaciones de razonamiento automatizado de Barreras de protección para Amazon Bedrock complementan otras características de Barreras de protección para Amazon Bedrock, como los filtros de contenido y las políticas de temas. Para obtener más información, consulte Componentes de barreras de protección.
Actualmente, las verificaciones de razonamiento automatizado de Barreras de protección para Amazon Bedrock solo admiten el inglés (EE. UU.).
Las comprobaciones de razonamiento automatizadas en Amazon Bedrock Guardrails no admiten la transmisión. APIs
Limitaciones y consideraciones
Antes de implementar las verificaciones de razonamiento automatizado, tenga en cuenta estas importantes limitaciones:
-
Complejidad de los documentos: los documentos de origen deben estar bien estructurados con reglas claras e inequívocas. Es posible que los documentos muy complejos con condiciones anidadas o afirmaciones contradictorias no se integren con claridad en la lógica formal. Los documentos de entrada están limitados a 5 MB de tamaño y 50 000 caracteres. Puede dividir documentos más grandes y combinar cada sección en su póliza. Las imágenes y las tablas de los documentos también afectan a la cantidad de caracteres introducidos.
-
Tiempo de procesamiento: la validación del razonamiento automatizado añade latencia a las respuestas de su solicitud. Prevea un tiempo de procesamiento adicional, especialmente en el caso de políticas complejas con muchas reglas.
-
Alcance de la política: cada política debe centrarse en un dominio específico (por ejemplo, recursos humanos, finanzas o asuntos legales) en lugar de tratar de abarcar múltiples áreas no relacionadas en una sola política.
-
Límites variables: las políticas con un número excesivo de variables o interacciones entre reglas demasiado complejas pueden alcanzar los límites de procesamiento o producir resultados TOO_COMPLEX.
-
Dependencia del lenguaje natural: la precisión de la validación depende en gran medida de la facilidad con la que se pueda traducir el lenguaje natural de las peticiones de los usuarios y las respuestas del modelo en variables lógicas formales de la política.
-
Aritmética no lineal: las comprobaciones de razonamiento automatizadas pueden agotar el tiempo de espera o devolver TOO_COMPLEX si las restricciones implican razonar con aritmética no lineal (por ejemplo, números o exponentes irracionales)
Prácticas recomendadas
Siga estas prácticas recomendadas para maximizar la eficacia de sus políticas de razonamiento automatizado:
-
Comience de forma sencilla: comience con una política específica que abarque las reglas básicas y, a continuación, añada complejidad gradualmente. Realice pruebas exhaustivas en cada etapa.
-
Cree descripciones completas de las variables: incluya la forma en que los usuarios podrían referirse de forma natural a los conceptos, no solo a las definiciones técnicas, del documento de origen.
-
Pruebe los casos límite: cree pruebas que se centren específicamente en las condiciones límite, las excepciones y los escenarios inusuales a los que puedan enfrentarse los usuarios.
-
Supervise los umbrales de confianza: comience con umbrales de confianza más altos (0,8-0,9) y ajústelos en función de su tolerancia a los falsos positivos frente a los falsos negativos.
-
Mantenimiento periódico de las políticas: revise y actualice sus políticas a medida que cambien las reglas del negocio o cuando identifique carencias durante las pruebas y el uso en producción.
-
Documente sus anotaciones: lleve un registro de las modificaciones de las políticas y del razonamiento que las sustenta para consultarlas en el futuro e intercambiar conocimientos con el equipo.
Precios
Las verificaciones de razonamiento automatizado de Barreras de protección para Amazon Bedrock se cobran en función del número de solicitudes de validación procesadas. Para obtener información actual acerca de los precios, consulte la página Precios de Amazon Bedrock
Se incurre en cargos por cada solicitud de validación, independientemente del resultado (por ejemplo, VALID, INVALID, TRANSLATION_AMBIGUOUS). Cómo optimizar los costos:
-
Utilice los umbrales de confianza adecuados para equilibrar la precisión con los requisitos de procesamiento.
-
Considere la posibilidad de almacenar en caché los resultados de la validación de consultas idénticas o similares cuando sea adecuado para su caso de uso.
-
Supervise los patrones de uso y ajuste las políticas para reducir las solicitudes de validación innecesarias.
Inferencia entre regiones para las operaciones de política
El razonamiento automatizado utiliza la inferencia entre regiones para optimizar el rendimiento y la disponibilidad de las operaciones de creación y prueba de políticas. Operaciones de API específicas distribuyen automáticamente el procesamiento entre las regiones de AWS dentro de sus límites geográficos para garantizar una prestación de servicios fiable.
Las siguientes operaciones de la API de razonamiento automatizado utilizan la inferencia entre regiones:
-
StartAutomatedReasoningPolicyBuildWorkflow: se invoca durante la creación y compilación de políticas desde los documentos de origen -
StartAutomatedReasoningPolicyTestWorkflow: se invoca durante los procedimientos de validación y prueba de políticas
Estas operaciones invocan modelos de lenguaje de gran tamaño para extraer reglas lógicas formales de los documentos de origen y traducir los constructos de lenguaje natural en representaciones lógicas estructuradas. Para garantizar un rendimiento y una disponibilidad óptimos, el procesamiento de las solicitudes se distribuye de acuerdo con la siguiente ruta geográfica:
-
Regiones de los Estados Unidos: las solicitudes de API originadas en Este de EE. UU. (Norte de Virginia), Oeste de EE. UU. (Oregón) o Este de EE. UU. (Ohio) se pueden procesar en cualquier región de EE. UU.
-
Regiones de la Unión Europea: las solicitudes de API que se originen en UE (Fráncfort), UE (París) o UE (Irlanda) se pueden procesar en cualquier región de la UE compatible.
importante
Los datos de los clientes permanecen dentro del límite geográfico de origen (Estados Unidos o Unión Europea) y se procesan de acuerdo con los compromisos de residencia de datos de AWS. La inferencia entre regiones enruta las solicitudes exclusivamente dentro de la misma región geográfica para optimizar el rendimiento y la disponibilidad del servicio.
La inferencia entre regiones funciona de forma transparente sin requerir la configuración del cliente. La funcionalidad de la API sigue siendo la misma independientemente de la región específica que procese la solicitud.
Para utilizar las verificaciones de razonamiento automatizado de Barreras de protección para Amazon Bedrock, siga estos pasos:
-
Cargue un documento de origen que contenga las reglas que quiere hacer cumplir.
-
Revise la política extraída con conceptos y reglas identificados automáticamente.
-
Pruebe y refine la política para asegurarse de que funciona correctamente.
-
Implemente la política para validar las respuestas de su modelo fundacional.
El flujo de trabajo se puede visualizar de la siguiente manera:
Source Document → Extracted Policy → Testing → Deployment → Runtime Validation (rules) (formal logic) (verify) (activate) (check responses)
Políticas
Las políticas de razonamiento automatizado son la base de la validación de la precisión, ya que contienen reglas y variables lógicas que se extraen automáticamente del documento de origen. Estas políticas sirven como representación matemática de sus reglas de negocio, lo que permite al sistema validar sistemáticamente si las respuestas del modelo fundacional cumplen las restricciones definidas. Para realizar verificaciones de razonamiento automatizado en su aplicación, debe configurar su barrera de protección para que utilice una política que se ajuste a sus requisitos específicos de dominio y validación.
Reglas
Las reglas son lógica que el razonamiento automatizado extrae del documento de origen. Estas pueden escribirse como si fueran instrucciones if-then. A continuación, se muestran algunos ejemplos del formato de regla:
<claim> is true if <premise>
nota
Importante: Las reglas que no tienen el formato if-then pueden tener consecuencias imprevistas al establecer axiomas sobre el mundo. Por ejemplo, si una regla simplemente establece accountBalance > 5, resulta imposible saber si el saldo de una cuenta es igual o inferior al 5 %, independientemente de lo que diga el contenido de la validación. La regla ha hecho que esta condición sea lógicamente imposible. Esto podría provocar resultados de validación inesperados si el contenido se marca incorrectamente como no conforme porque contradice el axioma establecido por la regla. Para evitarlo, estructure las reglas como instrucciones condicionales (con el formato if-then) que describan relaciones en lugar de restricciones absolutas.
Variables
Las variables representan conceptos de su política de razonamiento automatizado a las que se les pueden asignar valores al traducir el lenguaje natural a la lógica formal. Las reglas de su política definen restricciones sobre qué valores son válidos o no válidos para estas variables.
Las variables tienen un nombre, un tipo y una descripción. Por ejemplo, una política sobre las prestaciones a los empleados puede tener una variable con el nombre “employee_age», el tipo “integer” y la descripción “La edad del empleado en años”. A esta variable se le puede asignar un valor como 25 basado en lenguaje natural en una petición a una aplicación.
Por ejemplo, una variable is_full_time de una política de recursos humanos puede tener una descripción que diga “Empleados que trabajan más de 20 horas a la semana”, que es una cita directa del documento de origen. Al usar un chatbot, es más probable que los usuarios digan “Trabajo a tiempo completo” y no “Trabajo más de 20 horas a la semana”.
La precisión de la traducción del lenguaje natural a la lógica formal depende en gran medida de la calidad de las descripciones de las variables. Aunque el proceso de razonamiento es sólido una vez finalizada la traducción, las descripciones claras y completas de las variables garantizan que las peticiones del usuario se interpreten correctamente. Sin descripciones completas de las variables, es posible que el razonamiento automatizado devuelva NO_DATA porque no puede traducir el lenguaje natural de entrada a su representación lógica formal.
Es importante que la descripción de una variable tenga en cuenta escenarios como este. Una descripción completa de la variable podría indicar: “Los empleados que trabajan más de 20 horas a la semana lo hacen a tiempo completo. Los usuarios dirán a tiempo completo para establecer este valor en true o a tiempo parcial para establecerlo en false”.
Tipo de variables predefinidas
En la tabla siguiente se describen los tipos de variables predefinidas que puede tener su política.
| Tipo | Description (Descripción) |
|---|---|
|
BOOL |
Las variables booleanas pueden ser true o false. Por ejemplo, en una política de permisos, utilizaría una variable |
|
INT |
Las variables |
|
NUMBER |
|
|
enum |
Las variables de enumeración son tipos definidos por el usuario que pueden almacenar un único valor seleccionado de un conjunto de opciones fijas definidas en un tipo personalizado. Por ejemplo, en una política de excedencia, puede usar una variable de enumeración para almacenar |
Temas
Validación de los resultados de las pruebas de la política de razonamiento automatizado
Cómo abordar las pruebas de política de razonamiento automatizado no superadas
Utilice la CLI de Kiro con una política de razonamiento automatizado
Implementación de la política de razonamiento automatizado en su aplicación
