Esta publicación está coescrita con David Kim y Premjit Singh de Ring.
Ampliar el soporte de autoservicio a nivel mundial presenta desafíos más allá de la traducción. En esta publicación, le mostramos cómo Ring, la subsidiaria de seguridad para el hogar de Amazon, creó un chatbot de soporte basado en generación aumentada de recuperación (RAG) multilocal listo para producción utilizando las bases de conocimiento de Amazon Bedrock. Al eliminar las implementaciones de infraestructura por región, Ring redujo el costo de escalar a cada ubicación adicional en un 21 %. Al mismo tiempo, Ring mantuvo experiencias de clientes consistentes en 10 regiones internacionales.
En esta publicación, aprenderá cómo Ring implementó el filtrado basado en metadatos para contenido específico de una región, separó la administración de contenido en flujos de trabajo de ingesta, evaluación y promoción, y logró ahorros de costos mientras ampliaba. La arquitectura descrita en esta publicación utiliza Amazon Bedrock Knowledge Bases, Amazon Bedrock, AWS Lambda, AWS Step Functions y Amazon Simple Storage Service (Amazon S3). Ya sea que esté ampliando las operaciones de soporte a nivel internacional o buscando optimizar su arquitectura RAG existente, esta implementación proporciona patrones prácticos que puede aplicar a sus propios sistemas de soporte multilocal.
El viaje de evolución del soporte para Ring
La atención al cliente de Ring inicialmente se basó en un chatbot basado en reglas creado con Amazon Lex. Si bien era funcional, el sistema tenía limitaciones con patrones de conversación predefinidos que no podían manejar la diversa gama de consultas de los clientes. Durante los períodos pico, el 16 % de las interacciones escalaron a agentes humanos y los ingenieros de soporte dedicaron el 10 % de su tiempo a mantener el sistema basado en reglas. A medida que Ring se expandió a nivel internacional, este enfoque se volvió insostenible.
Requisitos para un sistema de soporte basado en RAG
Ring enfrentó un desafío: cómo brindar soporte preciso y contextualmente relevante en múltiples ubicaciones internacionales sin crear una infraestructura separada para cada región. El equipo identificó cuatro requisitos que informarían su enfoque arquitectónico.
Localización de contenidos globales
La presencia internacional de Ring requirió más que traducción. Cada territorio necesitaba información de producto específica de la región, desde especificaciones de voltaje hasta detalles de cumplimiento normativo, proporcionada a través de un sistema unificado. En el Reino Unido, Alemania y otras ocho regiones, Ring necesitaba manejar distintas configuraciones de productos y escenarios de soporte para cada región.
Arquitectura administrada y sin servidor
Ring quería que su equipo de ingeniería se centrara en mejorar la experiencia del cliente, no en gestionar la infraestructura. El equipo necesitaba una solución sin servidor y totalmente administrada.
Gestión del conocimiento escalable
Con cientos de guías de productos, documentos de solución de problemas y artículos de soporte que se actualizan constantemente, Ring necesitaba una tecnología de búsqueda vectorial que pudiera recuperar información precisa de un repositorio unificado. El sistema tenía que admitir canalizaciones automatizadas de ingesta de contenido para que el equipo de contenido de Ring pudiera publicar actualizaciones que estuvieran disponibles en múltiples ubicaciones sin intervención manual.
Optimización del rendimiento y los costes
El requisito promedio de latencia de extremo a extremo para Ring fue de 7 a 8 segundos y el análisis de rendimiento reveló que la latencia entre regiones representó menos del 10 % del tiempo total de respuesta. Este hallazgo permitió a Ring adoptar una arquitectura centralizada en lugar de implementar una infraestructura separada en cada región, lo que redujo la complejidad operativa y los costos.
Para abordar estos requisitos, Ring implementó un filtrado basado en metadatos con etiquetas de configuración regional de contenido. Este enfoque ofrece contenido específico de la región desde un único sistema centralizado. Para sus requisitos sin servidor, Ring eligió Amazon Bedrock Knowledge Bases y Lambda, que eliminaron la necesidad de administración de infraestructura y al mismo tiempo proporcionaron escalamiento automático.
Descripción general de la solución
Ring diseñó su arquitectura de chatbot basada en RAG para separar la gestión de contenidos en dos procesos centrales: ingesta, evaluación y promoción. Este enfoque de dos fases permite a Ring mantener una mejora continua del contenido mientras mantiene estables los sistemas de producción.
Flujo de trabajo de ingesta y evaluación
Figura 1: Diagrama de arquitectura que muestra el flujo de trabajo de evaluación e ingesta de Ring con Step Functions que organiza la creación, evaluación y validación de calidad de la base de conocimientos diaria mediante bases de conocimiento y almacenamiento S3.
Carga de contenido: el equipo de contenido de Ring carga documentación de soporte, guías de solución de problemas e información del producto en Amazon S3. El equipo estructuró los objetos de S3 con contenido en formato codificado y atributos de metadatos. Por ejemplo, un archivo con el contenido "Pasos para reemplazar la batería del timbre" tiene la siguiente estructura:
Procesamiento de contenido: Ring configuró notificaciones de eventos de depósitos de Amazon S3 con Lambda como objetivo para procesar automáticamente el contenido cargado. Almacenamiento de contenido sin procesar y procesado
La función Lambda realiza dos operaciones clave: Copia los datos sin procesar en el depósito de archivo de la base de conocimiento. Extrae metadatos y contenido de los datos sin procesar, almacenándolos como archivos separados en el depósito de origen de la base de conocimiento con clasificación contentLocale (por ejemplo, {locale}/Service.Ring.{Upsert/Delete}.{unique_identifier}.json).
Para el ejemplo de la batería del timbre, los archivos de contenido y metadatos de Ring tienen la siguiente estructura:
{locale}/Service.Ring.{Upsert/Delete}.{unique_identifier}.metadata.json
{locale}/Service.Ring.{Upsert/Delete}.{unique_identifier}.json
Copia de datos diaria y creación de base de conocimientos
Ring utiliza AWS Step Functions para organizar su flujo de trabajo diario que:
Copia contenido y metadatos del depósito de fuentes de la base de conocimientos a la fuente de datos (versión). Crea una nueva base de conocimientos (versión) indexando el depósito diario como fuente de datos para la incrustación de vectores.
Cada versión mantiene una base de conocimientos separada, lo que brinda a Ring capacidades de evaluación independientes y opciones sencillas de reversión.
Proceso de evaluación diaria
El flujo de trabajo de AWS Step Functions continúa utilizando conjuntos de datos de evaluación para:
Ejecute consultas en todas las versiones de la base de conocimientos Pruebe la precisión de la recuperación y la calidad de la respuesta para comparar el rendimiento entre versiones. Publique métricas de rendimiento en paneles de Tableau con resultados organizados por contentLocale Quality Validation y Golden Dataset Creation.
Ring utiliza el modelo de lenguaje grande (LLM) Anthropic Claude Sonnet 4 como juez para:
Evalúe las métricas en las versiones de la base de conocimientos para identificar la versión con mejor rendimiento. Compare la precisión de la recuperación, la calidad de la respuesta y las métricas de rendimiento organizadas por contentLocale. Promocione la versión de mayor rendimiento a Data Source (Golden) para su uso en producción.
Esta arquitectura admite reversiones a versiones anteriores por hasta 30 días. Debido a que el contenido se actualiza aproximadamente 200 veces por semana, Ring decidió no mantener las versiones más allá de los 30 días.
Flujo de trabajo de promoción: cara al cliente
Figura 2: Diagrama de arquitectura que muestra el sistema de chatbot de producción de Ring donde las consultas de los clientes fluyen a través de AWS Lambda para recuperar el contexto de las bases de conocimiento y generar respuestas utilizando modelos básicos.
Interacción con el cliente: los clientes inician consultas de soporte a través de la interfaz del chatbot. Por ejemplo, la consulta de un cliente sobre el escenario de reemplazo de batería se ve así:
Orquestación de consultas y recuperación de conocimientos.
Ring configuró Lambda para procesar consultas de clientes y recuperar contenido relevante de las bases de conocimiento de Amazon Bedrock. La función:
Transforma las consultas entrantes para el sistema RAG Aplica filtrado de metadatos con etiquetas contentLocale utilizando el operador igual para una orientación precisa del contenido regional Consulta la fuente de datos dorada validada para recuperar contenido contextualmente relevante
Aquí está el código de muestra que Ring usa en AWS Lambda:
Generación de respuesta
En la función Lambda, el sistema:
Ordena el contenido recuperado según la puntuación de relevancia y selecciona el contexto con la puntuación más alta Combina el contexto mejor clasificado con la consulta original del cliente para crear un mensaje aumentado Envía el mensaje aumentado a LLM en Amazon Bedrock Configura mensajes específicos de la configuración regional para cada contentLocale Genera respuestas contextualmente relevantes devueltas a través de la interfaz del chatbot
Otras consideraciones para su implementación
Al crear su propio sistema basado en RAG a escala, considere estos enfoques arquitectónicos y requisitos operativos más allá de la implementación principal:
Selección de tienda de vectores
La implementación de Ring utiliza Amazon OpenSearch Serverless como almacén de vectores para sus bases de conocimiento. Sin embargo, Amazon Bedrock Knowledge Bases también admite Amazon S3 Vectors como opción de almacenamiento de vectores. Al elegir entre estas opciones, considere:
Amazon OpenSearch Serverless: proporciona capacidades de búsqueda avanzadas, indexación en tiempo real y opciones de consulta flexibles. Ideal para aplicaciones que requieren patrones de búsqueda complejos o cuando necesita funciones adicionales de OpenSearch más allá de la búsqueda vectorial. Vectores de Amazon S3: ofrece una opción más rentable para casos de uso sencillos de búsqueda de vectores. Los almacenes de vectores S3 proporcionan escalamiento automático, durabilidad integrada y pueden ser más económicos para implementaciones a gran escala con patrones de acceso predecibles.
Además de estas dos opciones, AWS admite integraciones con otras opciones de almacenamiento de datos, incluidos Amazon Kendra, Amazon Neptune Analytics y Amazon Aurora PostgreSQL. Evalúe sus requisitos específicos en torno a la complejidad de las consultas, la optimización de costos y las necesidades operativas al seleccionar su tienda de vectores. La guía prescriptiva proporciona un buen punto de partida para evaluar los almacenes de vectores para su caso de uso de RAG.
Consideraciones sobre la arquitectura de control de versiones
Si bien Ring implementó bases de conocimiento separadas para cada versión, podría considerar un enfoque alternativo que involucre fuentes de datos separadas para cada versión dentro de una única base de conocimiento. Este método aprovecha el parámetro de filtro x-amz-bedrock-kb-data-source-id para apuntar a fuentes de datos específicas durante la recuperación:
Al elegir entre estos enfoques, sopese estas compensaciones específicas:
Bases de conocimientos separadas por versión (el enfoque que utiliza Ring): proporciona administración de fuentes de datos y capacidades de reversión más limpias, pero requiere administrar más instancias de bases de conocimientos. Base de conocimiento única con múltiples fuentes de datos: reduce la cantidad de instancias de base de conocimiento que se deben mantener, pero introduce complejidad en la lógica de enrutamiento de la fuente de datos y los mecanismos de filtrado, además requiere mantener almacenes de datos separados para cada ID de fuente de datos.
Recuperación ante desastres: implementación en varias regiones
Considere sus requisitos de recuperación ante desastres al diseñar su arquitectura RAG. Las bases de conocimiento de Amazon Bedrock son recursos regionales. Para lograr una recuperación ante desastres sólida, implemente su arquitectura completa en varias regiones:
Bases de conocimientos: cree instancias de la base de conocimientos en varias regiones. Buckets de Amazon S3: mantenga copias entre regiones de sus funciones Golden Data Source Lambda y flujos de trabajo de Step Functions: implemente su lógica de orquestación en cada región. Sincronización de datos: implemente procesos para mantener el contenido sincronizado en todas las regiones.
La arquitectura centralizada atiende su tráfico desde una única región, priorizando la optimización de costos sobre la implementación en varias regiones. Evalúe sus propios requisitos de objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO) para determinar si es necesaria una implementación de varias regiones para su caso de uso.
Rendimiento del modelo básico: inferencia entre regiones
Los modelos de fundación de Amazon Bedrock son recursos regionales con cuotas regionales. Para manejar las ráfagas de tráfico y escalar más allá de las cuotas de una sola región, Amazon Bedrock admite la inferencia entre regiones (CRIS). CRIS enruta automáticamente las solicitudes de inferencia a través de múltiples regiones de AWS para aumentar el rendimiento:
CRIS: enruta solicitudes solo dentro de límites geográficos específicos (como dentro de EE. UU. o dentro de la UE) para cumplir con los requisitos de residencia de datos. Esto puede proporcionar hasta el doble de las cuotas regionales predeterminadas.
CRIS global: enruta solicitudes a través de múltiples regiones comerciales en todo el mundo, optimizando los recursos disponibles y proporcionando un mayor rendimiento del modelo más allá de las capacidades geográficas de CRIS. Global CRIS selecciona automáticamente la Región óptima para procesar cada solicitud.
CRIS opera independientemente de su estrategia de implementación de la base de conocimientos. Incluso con una implementación de la base de conocimientos de una sola región, puede configurar CRIS para escalar el rendimiento de su modelo básico durante las ráfagas de tráfico. Tenga en cuenta que CRIS se aplica solo a la capa de inferencia: sus bases de conocimiento, depósitos de S3 y lógica de orquestación siguen siendo recursos regionales que requieren una implementación independiente en varias regiones para la recuperación ante desastres.
Incrustación de selección de modelos y estrategia de fragmentación.
Seleccionar el modelo de incrustación y la estrategia de fragmentación adecuados es importante para el rendimiento del sistema RAG porque afecta directamente la precisión de la recuperación y la calidad de la respuesta. Ring utiliza el modelo Amazon Titan Embeddings con la estrategia de fragmentación predeterminada, que resultó eficaz para su documentación de soporte.
Amazon Bedrock ofrece flexibilidad con múltiples opciones:
Modelos de incrustación:
Incorporaciones de Amazon Titan: optimizadas para contenido basado en texto Incorporaciones multimodales de Amazon Nova: admite las modalidades “Texto”, “Imagen”, “Audio” y “Video”
Estrategias de fragmentación:
Al incorporar datos, Amazon Bedrock divide los documentos en partes manejables para una recuperación eficiente mediante cuatro estrategias:
Fragmentación estándar: fragmentos de tamaño fijo para documentos uniformes Fragmentación jerárquica: para documentos estructurados con jerarquías de secciones claras Fragmentación semántica: divide el contenido según los límites del tema Fragmentación de contenido multimodal: para documentos con tipos de contenido mixtos (texto, imágenes, tablas)
Evalúe las características de su contenido para seleccionar la combinación óptima para su caso de uso específico.
Conclusión
En esta publicación, mostramos cómo Ring creó un chatbot de soporte basado en RAG multilocal listo para producción utilizando las bases de conocimiento de Amazon Bedrock. La arquitectura combina la ingesta automatizada de contenido, una evaluación diaria sistemática utilizando un enfoque de LLM como juez y una orientación de contenido basada en metadatos para lograr una reducción del 21 % en la infraestructura y el costo operativo por ubicación adicional, manteniendo al mismo tiempo experiencias consistentes para los clientes en 10 regiones internacionales.
Más allá de la arquitectura central de RAG, cubrimos consideraciones de diseño clave para las implementaciones de producción: selección de almacén de vectores, estrategias de control de versiones, implementación en varias regiones para la recuperación ante desastres, inferencia entre regiones para escalar el rendimiento del modelo básico, selección de modelos de integración y estrategias de fragmentación. Estos patrones se aplican ampliamente a cualquier equipo que cree sistemas RAG multilocales o de alta disponibilidad en AWS. Ring continúa evolucionando su arquitectura de chatbot hacia un modelo agente con selección dinámica de agentes e integración de múltiples agentes especializados. Este enfoque de agencia permitirá a Ring dirigir las consultas de los clientes a agentes especializados para la resolución de problemas de los dispositivos, la gestión de pedidos y las recomendaciones de productos, lo que demuestra la extensibilidad de los sistemas de soporte basados en RAG creados en Amazon Bedrock.
Para obtener más información sobre las bases de conocimientos de Amazon Bedrock, visite la documentación de Amazon Bedrock.
Sobre los autores
Gopinath Jagadesan
Gopinath Jagadesan es arquitecto senior de soluciones en AWS, donde trabaja con Amazon para diseñar, construir e implementar soluciones bien diseñadas en AWS. Tiene una maestría en ingeniería eléctrica e informática de la Universidad de Illinois en Chicago. A Gopinath le apasiona la IA generativa y sus aplicaciones del mundo real, y ayuda a los clientes a aprovechar su potencial para impulsar la innovación y la eficiencia. Fuera del trabajo, le gusta jugar fútbol y pasar tiempo con su familia y amigos.
David Kim
David Kim es ingeniero de desarrollo de software en Ring, donde diseña y construye agentes de inteligencia artificial para automatizar las experiencias de servicio al cliente. Le apasiona la IA conversacional y los sistemas multiagente, y aprovecha AWS Bedrock para crear soluciones inteligentes y escalables. David también tiene un profundo interés en la mecánica cuántica y explora sus posibles intersecciones con la informática. Fuera del trabajo, le gustan los juegos, el búlder, ver programas de televisión y viajar con su familia.
Premjit Singh
Premjit Singh es gerente de desarrollo de software en la plataforma de comercio electrónico Ring en Ring. Se centra en permitir que los clientes de Ring descubran y compren productos Ring en ring.com. Le apasiona aprovechar las ofertas de servicios de inteligencia artificial de AWS, incluido Amazon Bedrock, para crear agentes y explorar el paradigma de desarrollo basado en especificaciones de Kiro. En su tiempo libre le gusta ver programas de televisión.