Mejore la precisión añadiendo comprobaciones de razonamiento automatizadas en Amazon Bedrock Guardrails - Amazon Bedrock

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.

Mejore la precisión añadiendo comprobaciones de razonamiento automatizadas en Amazon Bedrock Guardrails

Las comprobaciones de razonamiento automatizadas de Amazon Bedrock Guardrails verifican matemáticamente el contenido en lenguaje natural con respecto a las políticas definidas, lo que garantiza el cumplimiento estricto de las barandillas. Estas comprobaciones pueden ayudar a bloquear sistemáticamente el contenido dañino o que no cumple con 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 políticos complejos. Para los clientes que priorizan la precisión, las reglas de las políticas se pueden personalizar para mejorar la eficacia de las barreras mediante declaraciones 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 comprobaciones de razonamiento automatizadas en Amazon Bedrock Guardrails resuelven este problema mediante el uso de técnicas matemáticas para:

  • Detecta alucinaciones en las respuestas de LLM

  • Resalte las suposiciones no declaradas

  • Explique por qué las afirmaciones precisas son correctas

Esta función es especialmente valiosa cuando se necesita demostrar la base fáctica de la respuesta de un LLM en:

  • Industrias reguladas, como la sanidad y los recursos humanos

  • Solicitudes con normas complejas (aprobaciones de hipotecas, leyes de zonificación)

  • Escenarios de cumplimiento que requieren respuestas de IA auditables

Las comprobaciones de razonamiento automatizadas en Amazon Bedrock Guardrails no protegen contra los ataques de inyección inmediata. Estas comprobaciones 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 (basura que entra, basura que sale). Para detectar y bloquear los ataques de inyección rápida, utiliza filtros de contenido en combinación con comprobaciones de razonamiento automatizadas.

El razonamiento automatizado solo analiza y detecta el texto que es relevante para la política de razonamiento automatizado. Ignorará el resto del contenido y no podrá indicar a los desarrolladores si la respuesta está fuera de tema o no. Si necesitas detectar respuestas que no estén relacionadas con el tema, utiliza otros componentes de protección, como las políticas temáticas.

nota

Las comprobaciones de razonamiento automatizadas en Amazon Bedrock Guardrails generalmente están disponibles en las regiones de EE. UU. (Virginia del Norte, Oregón y Ohio) y de la UE (Fráncfort, París e Irlanda).

nota

Los controles de razonamiento automatizados de Amazon Bedrock Guardrails complementan otras funciones de Amazon Bedrock Guardrails, como los filtros de contenido y las políticas temáticas. Para obtener más información, consulte Componentes de Guardrail.

CloudFormation no es compatible actualmente. CloudFormation el soporte llegará pronto.

Actualmente, las comprobaciones de razonamiento automatizadas en Amazon Bedrock Guardrails solo admiten 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 comprobaciones de razonamiento automatizadas, tenga en cuenta estas importantes limitaciones:

  • Complejidad de los documentos: los documentos fuente deben estar bien estructurados con reglas claras e inequívocas. Es posible que los documentos muy complejos con condiciones anidadas o declaraciones contradictorias no se integren con claridad en la lógica formal.

  • Tiempo de procesamiento: la validación del razonamiento automatizado añade latencia a las respuestas de su solicitud. Planifique un tiempo de procesamiento adicional, especialmente para políticas complejas con muchas reglas.

  • Alcance de la política: cada política debe centrarse en un ámbito 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 arrojar resultados muy complejos.

  • Dependencia del lenguaje natural: la precisión de la validación depende en gran medida de qué tan bien se pueda traducir el lenguaje natural de las solicitudes de los usuarios y las respuestas del modelo a las variables lógicas formales de la política.

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.

  • Redacta descripciones completas de las variables: incluye la forma en que los usuarios podrían referirse de forma natural a los conceptos, no solo a las definiciones técnicas, del documento fuente.

  • Pruebe 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 a 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 comerciales o identifique las brechas mediante 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 comprobaciones de razonamiento automatizadas en Amazon Bedrock Guardrails se cobran en función del número de solicitudes de validación procesadas. Para obtener información sobre los precios actuales, consulta la página de precios de Amazon Bedrock.

Se incurre en cargos por cada solicitud de validación, independientemente del resultado (por ejemplo, VALID, INVALID, TRANSLATION_AMBIGUOUS). Para optimizar los costes:

  • 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 interregional para las operaciones de políticas

El razonamiento automatizado utiliza la inferencia interregional para optimizar el rendimiento y la disponibilidad de las operaciones de creación y prueba de políticas. Las 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 a partir de los documentos fuente

  • StartAutomatedReasoningPolicyTestWorkflow- Se invoca durante los procedimientos de validación y prueba de políticas

Estas operaciones recurren a grandes modelos de lenguaje para extraer reglas lógicas formales de los documentos fuente y traducir las construcciones del 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 que se originen en EE. UU. Este (Virginia del Norte), EE. UU. Oeste (Oregón) o EE. UU. Este (Ohio) se pueden procesar en cualquier región de EE. UU. compatible.

  • Regiones de la Unión Europea: las solicitudes de API que se originen en la UE (Fráncfort), la UE (París) o la 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 interregional 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 permanece uniforme independientemente de la región específica que procese la solicitud.

Para utilizar las comprobaciones de razonamiento automatizadas en Amazon Bedrock Guardrails, siga estos pasos:

  1. Cargue un documento fuente que contenga las reglas que quiere hacer cumplir

  2. Revise la política extraída con conceptos y reglas identificados automáticamente

  3. Pruebe y perfeccione la política para asegurarse de que funciona correctamente

  4. Implemente la política para validar las respuestas de su modelo básico

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 fuente. Estas políticas sirven como representación matemática de las reglas de su negocio, lo que permite al sistema validar sistemáticamente si las respuestas del modelo básico cumplen con las restricciones definidas. Para realizar comprobaciones de razonamiento automatizadas 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ógicas que el razonamiento automatizado extrae del documento fuente. Estas pueden escribirse como si fueran declaraciones. Estos son algunos ejemplos del formato de la regla:

if <premise>, then <claim>

<premise> is true

nota

Importante: las reglas que no tienen el formato de «sí» pueden tener consecuencias imprevistas al establecer axiomas sobre el mundo. Por ejemplo, si una regla simplemente lo estableceaccountBalance > 5, resulta imposible que el saldo de una cuenta sea igual o inferior al 5%, independientemente de lo que diga el contenido de la validación. La regla ha hecho que sea lógicamente imposible que exista esa condición. 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 sentencias condicionales (formato «si, entonces») que describen relaciones en lugar de restricciones absolutas.

Variables

Las variables representan conceptos de su política de razonamiento automatizado a los que se les pueden asignar valores al traducir el lenguaje natural a la lógica formal. Las reglas de su política definen las 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 «empleadoe_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 en función del lenguaje natural en un mensaje dirigido a una solicitud.

Por ejemplo, una is_full_time variable 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 fuente. 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 variables. Si bien el proceso de razonamiento es sólido una vez que se completa la traducción, las descripciones claras y completas de las variables garantizan que las indicaciones del usuario se interpreten correctamente. Sin descripciones completas de las variables, es posible que el razonamiento automatizado vuelva NO_DATA a funcionar 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 trabajan a tiempo completo. Los usuarios dirán a tiempo completo para establecer este valor en verdadero, o a tiempo parcial para establecerlo en falso.

Tipos de variables predefinidos

En la siguiente tabla se describen los tipos de variables predefinidos que puede tener su política.

Tipo Descripción

bool

Las variables booleanas pueden ser verdaderas o falsas. Por ejemplo, en una política de excedencia, utilizaría una bool variable para identificar si la excedencia está permitida o no.

int

intLas variables numéricas pueden almacenar números enteros positivos o negativos. Por ejemplo, en una política de excedencia, se utilizaría una int variable para almacenar los días de vacaciones acumulados si no se permiten fracciones de días.

real

realLas variables numéricas pueden almacenar números positivos o negativos que requieren precisión decimal. Por ejemplo, en una política de excedencia, utilizaría una real variable para almacenar el importe del pago en dólares por los días de vacaciones no utilizados.

enum

Las variables de enumeración pueden almacenar un único valor seleccionado de un conjunto de opciones fijas. Por ejemplo, en una política de excedencia, puede usar una variable de enumeración para almacenar el tipo de licencia: (1) vacaciones pagadas; (2) tiempo personal; (3) licencia

También puede crear tipos de enumeración personalizados y definidos por el usuario que proporcionen un contexto adicional más allá de los tipos de variables predefinidos. Estos tipos personalizados le permiten definir conjuntos de valores específicos relevantes para el dominio de su política.