El razonamiento automatizado comprueba la reescritura de la implementación de referencia del chatbot

Hoy publicamos un nuevo chatbot de muestra de código abierto que muestra cómo utilizar los comentarios de las comprobaciones de razonamiento automatizado para iterar sobre el contenido generado, hacer preguntas aclaratorias y demostrar la exactitud de una respuesta.

La implementación del chatbot también produce un registro de auditoría que incluye explicaciones matemáticamente verificables para la validez de la respuesta y una interfaz de usuario que muestra a los desarrolladores el proceso iterativo de reescritura que ocurre detrás de escena. Las comprobaciones de razonamiento automatizado utilizan la deducción lógica para demostrar automáticamente que una afirmación es correcta. A diferencia de los grandes modelos de lenguaje, las herramientas de razonamiento automatizado no adivinan ni predicen la precisión. En cambio, se basan en pruebas matemáticas para verificar el cumplimiento de las políticas. Esta publicación de blog profundiza en la arquitectura de implementación del chatbot de reescritura de comprobaciones de razonamiento automatizado.

Mejore la precisión y la transparencia con comprobaciones de razonamiento automatizado

Los LLM a veces pueden generar respuestas que suenan convincentes pero que contienen errores fácticos, un fenómeno conocido como alucinación. Las comprobaciones de razonamiento automatizado validan la pregunta de un usuario y una respuesta generada por el LLM, brindando comentarios de reescritura que señalan afirmaciones ambiguas, afirmaciones que son demasiado amplias y afirmaciones objetivamente incorrectas basadas en conocimientos reales codificados en políticas de razonamiento automatizado.

Un chatbot que utiliza comprobaciones de razonamiento automatizado para repetir sus respuestas antes de presentarlas a los usuarios ayuda a mejorar la precisión porque puede hacer declaraciones precisas que responden explícitamente a las preguntas de sí/no de los usuarios sin dejar lugar a la ambigüedad; y ayuda a mejorar la transparencia porque puede proporcionar pruebas matemáticamente verificables de por qué sus afirmaciones son correctas, lo que hace que las aplicaciones de IA generativa sean auditables y explicables incluso en entornos regulados.

Ahora que comprende los beneficios, exploremos cómo puede implementar esto en sus propias aplicaciones.

Implementación de referencia de chatbot

El chatbot es una aplicación de Flask que expone API para enviar preguntas y verificar el estado de una respuesta. Para mostrar el funcionamiento interno del sistema, las API también le permiten recuperar información sobre el estado de cada iteración, los comentarios de las comprobaciones de razonamiento automatizado y el mensaje de reescritura enviado al LLM.

Puede utilizar la aplicación frontend NodeJS para configurar un LLM de Amazon Bedrock para generar respuestas, seleccionar una política de razonamiento automatizado para su validación y establecer el número máximo de iteraciones para corregir una respuesta. Al seleccionar un hilo de chat en la interfaz de usuario, se abre un panel de depuración a la derecha que muestra cada iteración del contenido y el resultado de la validación.

Figura 1: Interfaz de chat con panel de depuración

Una vez que las comprobaciones de razonamiento automatizado indican que una respuesta es válida, se muestra la explicación verificable de la validez.

Figura 2: Prueba de validez de comprobaciones de razonamiento automatizado

Figura 2 – Prueba de validez de comprobaciones de razonamiento automatizado

Cómo funciona el ciclo de reescritura iterativa

La implementación de referencia de código abierto ayuda automáticamente a mejorar las respuestas del chatbot al iterar sobre los comentarios de las comprobaciones de razonamiento automatizado y reescribir la respuesta. Cuando se le pide que valide una pregunta y respuesta de un chatbot (Preguntas y respuestas), las comprobaciones de razonamiento automatizado devuelven una lista de hallazgos. Cada hallazgo representa una declaración lógica independiente identificada en las preguntas y respuestas de entrada. Por ejem ap-sureste-2.

Al analizar un hallazgo para una sesión de preguntas y respuestas, las verificaciones de razonamiento automatizado separan la entrada en una lista de premisas fácticas y afirmaciones formuladas contra esas premisas. Una premisa puede ser una declaración objetiva en la pregunta del usuario, como “Soy un usuario de S3 en Virginia”, o una suposición expuesta en la respuesta, como “Para solicitudes enviadas a us-east-1…”. Una afirmación representa una declaración que se está verificando. En nuestro ejemplo de precios de S3 del párrafo anterior, la región sería una premisa y el precio sería un reclamo.

Cada hallazgo incluye un resultado de validación (VÁLIDO, NO VÁLIDO, SATISFIABLE, TRADUCCIÓN_AMBIGUA, IMPOSIBLE), así como la retroalimentación necesaria para reescribir la respuesta para que sea VÁLIDA. La retroalimentación cambia según el resultado de la validación. Por ejemplo, los hallazgos ambiguos incluyen dos interpretaciones del texto de entrada, los hallazgos satisfactorios incluyen dos escenarios que muestran cómo las afirmaciones podrían ser verdaderas en algunos casos y falsas en otros. Puede ver los posibles tipos de hallazgos en nuestra documentación API.

Una vez aclarado este contexto, podemos profundizar en cómo funciona la implementación de referencia:

Respuesta inicial y validación.

Cuando el usuario envía una pregunta a través de la interfaz de usuario, la aplicación primero llama al Bedrock LLM configurado para generar una respuesta y luego llama a la API ApplyGuardrail para validar las preguntas y respuestas.

Al utilizar el resultado de las comprobaciones de razonamiento automatizado en la respuesta de ApplyGuardrail, la aplicación ingresa a un bucle donde cada iteración verifica los comentarios de las comprobaciones de razonamiento automatizado, realiza una acción como pedirle al LLM que reescriba una respuesta basada en los comentarios y luego llama a ApplyGuardrail para validar el contenido actualizado nuevamente.

El bucle de reescritura (El corazón del sistema)

Después de la validación inicial, el sistema utiliza el resultado de las comprobaciones de razonamiento automatizado para decidir el siguiente paso. Primero, clasifica los hallazgos según su prioridad, abordando primero los más importantes: TRADUCCIÓN_AMBIGUA, IMPOSIBLE, NO VÁLIDO, SATISFIABLE, VÁLIDO. Luego, selecciona el hallazgo de mayor prioridad y lo aborda con la lógica siguiente. Dado que VÁLIDO es el último en la lista de prioridades, el sistema solo aceptará algo como VÁLIDO después de abordar los demás hallazgos.

Para los resultados de TRANSLATION_AMBIGUOUS, las comprobaciones de razonamiento automatizado devuelven dos interpretaciones del texto de entrada. Para los resultados SATISFIABLES, las comprobaciones de razonamiento automatizado arrojan dos escenarios que prueban y refutan las afirmaciones. Utilizando los comentarios, la aplicación le pide al LLM que decida si quiere intentar reescribir la respuesta para aclarar ambigüedades o hacer preguntas de seguimiento al usuario para recopilar información adicional. Por ejemplo, la respuesta SATISFIABLE puede decir que el precio de $0,023 es válido solo si la región es EE. UU. Este (Norte de Virginia). El LLM puede utilizar esta información para preguntar sobre la región de la solicitud. Cuando el LLM decide hacer preguntas de seguimiento, el ciclo se detiene y espera a que el usuario responda las preguntas, luego el LLM regenera la respuesta en función de las aclaraciones y el ciclo se reinicia. Para hallazgos IMPOSIBLES, las comprobaciones de razonamiento automatizado devuelven una lista de las reglas que contradicen las premisas (hechos aceptados en el contenido de entrada). Utilizando los comentarios, la aplicación le pide al LLM que reescriba la respuesta para evitar inconsistencias lógicas. Para los resultados NO VÁLIDOS, las comprobaciones de razonamiento automatizado devuelven las reglas de la política de razonamiento automatizado que invalidan las reclamaciones según las premisas y las reglas de la política. Utilizando los comentarios, la aplicación le pide al LLM que reescriba su respuesta para que sea consistente con las reglas. Para resultados VÁLIDOS, la aplicación sale del bucle y devuelve la respuesta al usuario.

Después de reescribir cada respuesta, el sistema envía las preguntas y respuestas a la API de ApplyGuardrail para su validación; la siguiente iteración del bucle comienza con la retroalimentación de esta llamada. Cada iteración almacena los hallazgos y las indicaciones con contexto completo en la estructura de datos del hilo, creando un seguimiento de auditoría de cómo el sistema llegó a la respuesta definitiva.

Introducción a los controles de razonamiento automatizado que reescriben el chatbot

Para probar nuestra implementación de referencia, el primer paso es crear una política de razonamiento automatizado:

Navegue a Amazon Bedrock en la Consola de administración de AWS en una de las regiones admitidas en Estados Unidos o Europa. Desde la navegación izquierda, abra la página Razonamiento automatizado en la categoría Construir. Usando el menú desplegable del botón Crear política, elija Crear política de muestra. Ingrese un nombre para la política y luego elija Crear política en la parte inferior de la página.

Una vez que haya creado una política, puede proceder a descargar y ejecutar la implementación de referencia:

Clonar el repositorio de Amazon Bedrock Samples. Siga las instrucciones en el archivo README para instalar dependencias, crear la interfaz e iniciar la aplicación. Usando su navegador preferido, navegue hasta http://localhost8080 y comience a probar.

Detalles de implementación de backend

Si planea adaptar esta implementación para uso en producción, esta sección repasa los componentes clave de la arquitectura backend. Encontrará estos componentes en el directorio backend del repositorio.

ThreadManager: organiza la gestión del ciclo de vida de la conversación. Maneja la creación, recuperación y seguimiento del estado de los hilos de conversación, manteniendo el estado adecuado durante todo el proceso de reescritura. ThreadManager implementa operaciones seguras para subprocesos mediante un bloqueo para ayudar a prevenir condiciones de carrera cuando varias operaciones intentan modificar la misma conversación simultáneamente. También rastrea los subprocesos que esperan la entrada del usuario y puede identificar subprocesos obsoletos que han excedido un tiempo de espera configurable. ThreadProcessor: maneja el bucle de reescritura utilizando un patrón de máquina de estados para un flujo de control claro y fácil de mantener. El procesador gestiona las transiciones de estado entre fases como GENERATE_INITIAL, VALIDATE, CHECK_QUESTIONS, HANDLE_RESULT y REWRITING_LOOP, haciendo avanzar la conversación correctamente a través de cada etapa. Servicio de validación: se integra con Amazon Bedrock Guardrails. Este servicio toma cada respuesta generada por LLM y la envía para su validación mediante la API ApplyGuardrail. Maneja la comunicación con AWS, administra la lógica de reintento con retroceso exponencial para fallas transitorias y analiza los resultados de la validación en hallazgos estructurados. LLMResponseParser: interpreta las intenciones del LLM durante el ciclo de reescritura. Cuando el sistema le pide al LLM que corrija una respuesta no válida, el modelo debe decidir si intenta reescribir (REWRITE), hacer preguntas aclaratorias (ASK_QUESTIONS) o declarar la tarea imposible debido a premisas contradictorias (IMPOSSIBLE). El analizador examina la respuesta del LLM en busca de marcadores específicos como “DECISIÓN:”, “RESPUESTA:” y “PREGUNTA:”, extrayendo información estructurada de la salida del lenguaje natural. Maneja el formato de rebajas con elegancia y aplica límites en el número de preguntas (máximo 5). AuditLogger: escribe registros JSON estructurados en un archivo de registro de auditoría dedicado, registrando dos tipos de eventos clave: VALID_RESPONSE cuando una respuesta pasa la validación y MAX_ITERATION_REACHED cuando el sistema agota el número establecido de reintentos. Cada entrada de auditoría captura la marca de tiempo, el ID del subproceso, el mensaje, la respuesta, el ID del modelo y los resultados de la validación. El registrador también extrae y registra los intercambios de preguntas y respuestas de las iteraciones de aclaración, incluido si el usuario respondió u omitió las preguntas.

Juntos, estos componentes ayudan a crear una base sólida para crear aplicaciones de IA confiables que combinen la flexibilidad de grandes modelos de lenguaje con el rigor de la verificación matemática.

Para obtener orientación detallada sobre la implementación de comprobaciones de razonamiento automatizado en producción:

Sobre los autores

Stefano Buliano

Stefano es gerente de producto en el equipo de razonamiento automatizado de AWS. Con más de 10 años en AWS, ha trabajado en tecnologías sin servidor, incluidos proyectos de código abierto como Serverless Java Container y ha ayudado a los clientes a implementar cientos de aplicaciones en producción.