Cómo Couchbase construyó una arquitectura de IA multimodelo para Capella iQ con Amazon Bedrock

Esta publicación está coescrita con Tushar Madaan de Couchbase.

Crear un asistente de desarrollador con tecnología de inteligencia artificial que pueda generar consultas de bases de datos, recomendar índices y admitir flujos de trabajo conversacionales de varios turnos requiere más de un único modelo de lenguaje grande (LLM). Exige una arquitectura de inferencia que sea flexible, escalable y resistente. A medida que crecía la adopción empresarial de Capella iQ, Couchbase amplió su aplicación de IA para admitir múltiples proveedores de modelos básicos (FM) para lograr una mayor flexibilidad, una mejor resiliencia operativa y una alineación con las diversas preferencias de implementación de los clientes. Couchbase requería una arquitectura de inferencia independiente del modelo que pudiera escalar a través de ráfagas de tráfico y mantener una alta disponibilidad en todas las regiones de AWS sin capacidad preaprovisionada.

Esta publicación describe cómo Couchbase adoptó Amazon Bedrock para impulsar Capella iQ con la familia de modelos Claude de Anthropic, las decisiones arquitectónicas detrás de su enfoque multimodelo y los beneficios operativos obtenidos en la producción.

Descripción general de la solución

El siguiente diagrama ilustra la arquitectura de producción para la integración de Capella iQ con Amazon Bedrock.

Figura 1: Arquitectura del plano de control de Couchbase Capella iQ y Amazon Bedrock

La arquitectura está alojada en AWS Control Plane y abarca dos regiones de AWS (us-east-1 y us-west-2) para lograr alta disponibilidad. Dentro de us-east-1, un clúster de Amazon Elastic Kubernetes Service (Amazon EKS) ejecuta los microservicios Capella iQ:

cp-api pod: el servicio API principal que recibe solicitudes de desarrolladores y organiza llamadas de inferencia. Este pod reenvía las invocaciones de Amazon Bedrock a través de un punto final de interfaz de nube privada virtual (VPC). cp-internal-api pod: maneja la comunicación interna de servicio a servicio y la lógica de enrutamiento del modelo. cp-ns pod: administra la configuración a nivel de espacio de nombres, incluida la configuración del proveedor del modelo, anulaciones a nivel de inquilino y preferencias de organización.

Un punto de enlace de interfaz de Amazon Virtual Private Cloud (Amazon VPC) proporciona conectividad privada desde el clúster de EKS al tiempo de ejecución de Amazon Bedrock. Este punto final enruta el tráfico de inferencia a la infraestructura administrada por AWS para Bedrock y admite la inferencia entre regiones (CRIS) dentro de la geografía de EE. UU. en us-east-1, us-east-2 y us-west-2 para conmutación por error automática, distribución de carga y disponibilidad mejorada durante picos de demanda.

como funciona

Cuando un desarrollador interactúa con Capella iQ, ya sea solicitando una consulta SQL++, solicitando una recomendación de índice o continuando una conversación de varios turnos, la solicitud atraviesa esta canalización de un extremo a otro:

Ingestión de solicitudes: la solicitud en lenguaje natural del desarrollador llega al pod cp-api. Maneja la autenticación, recupera el contexto de la sesión y determina la plantilla de solicitud adecuada para el tipo de solicitud. Orquestación de inferencia: el pod cp-api ensambla la carga útil de inferencia, construye el mensaje, inyecta el historial de conversaciones para el contexto de varios turnos y aplica configuraciones de modelo específicas del inquilino desde el pod cp-ns. El pod cp-internal-api resuelve la selección de proveedores de modelos y las anulaciones de enrutamiento a nivel de organización. Invocación de modelo privado: el pod cp-api reenvía la solicitud a través del punto de enlace de la interfaz de VPC al tiempo de ejecución de Amazon Bedrock. La carga útil completa de avisos y respuestas permanece dentro de la infraestructura de AWS y nunca atraviesa la Internet pública. Este diseño cumple con los requisitos de seguridad empresarial y residencia de datos. Inferencia entre regiones: Amazon Bedrock enruta automáticamente las solicitudes de inferencia a la región óptima de EE. UU. (us-east-1, us-east-2 o us-west-2) mediante la inferencia entre regiones, manteniendo las solicitudes dentro de los límites geográficos de EE. UU. Durante picos de demanda o degradación regional, las solicitudes se dirigen a regiones disponibles sin lógica a nivel de aplicación ni intervención manual. Entrega de respuesta: la respuesta del modelo (SQL++ generado, recomendación de índice o respuesta conversacional) se transmite a través de la misma ruta privada. El pod cp-api aplica la normalización y el formato de respuesta antes de entregar el resultado al desarrollador dentro de la interfaz Capella iQ. El estado de la conversación persiste para la continuidad de varios turnos.

Este diseño garantiza que las actualizaciones de modelos o cambios de proveedores solo requieran actualizaciones de configuración en la capa de espacio de nombres, sin cambios de código, sin tiempo de inactividad y sin impacto en la experiencia del desarrollador.

Evaluación del modelo

Antes de seleccionar un modelo para producción, el equipo estableció un conjunto de pruebas comparativas que cubren todos los flujos de trabajo principales de Capella iQ: generación de SQL++, recomendaciones de índices, explicaciones de consultas, generación de iQ Insights y conversaciones de varios turnos. Se evaluaron múltiples modelos disponibles en Bedrock utilizando conjuntos de pruebas estandarizadas de indicaciones/respuestas, con la puntuación centrada en cuatro dimensiones: corrección funcional, determinismo, latencia y coherencia de formato.

Claude Sonnet 4.5 de Anthropic logró aproximadamente un 76 por ciento de precisión en una evaluación interna modelada según la metodología BIRD, cumpliendo con el estándar de calidad de producción en todos los flujos de trabajo evaluados sin regresiones críticas. Esto validó Claude Sonnet 4.5 como modelo de producción inicial para el diverso perfil de carga de trabajo de Capella iQ, que abarca la generación de código estructurado, explicación en lenguaje natural y razonamiento de múltiples turnos. Más importante aún, validó un marco de evaluación de modelos que ayuda a Couchbase a calificar y adoptar rápidamente modelos más nuevos a medida que estén disponibles en Amazon Bedrock.

La ventaja de Amazon Bedrock

Amazon Bedrock proporciona un entorno de inferencia sin servidor totalmente administrado que elimina la necesidad de administrar la infraestructura modelo. Ofrece un catálogo cada vez mayor de modelos básicos, por lo que Couchbase puede evaluar y adoptar generaciones de modelos más nuevas sin rediseñar su canal de inferencia. La inferencia entre regiones ofrece resiliencia y distribución geográfica integradas que, de otro modo, requerirían una importante ingeniería personalizada.

Para Couchbase, el acceso mediante API única a múltiples familias de modelos a través de Amazon Bedrock era una opción natural para su objetivo de crear una arquitectura independiente del proveedor, una en la que la selección del modelo sea una elección de configuración, no un cambio de código.

Los clientes empresariales requieren flexibilidad de implementación y la confianza de que el tráfico de inferencia se mantiene dentro de una huella de AWS bien gobernada. Al integrarse con Amazon Bedrock, Couchbase ofrece a los clientes el beneficio de la postura de seguridad de AWS, los controles de residencia de datos y las certificaciones de cumplimiento (SOC, HIPAA, ISO) para flujos de trabajo asistidos por IA dentro de Capella iQ.

Consideraciones de ingeniería

Si bien Amazon Bedrock simplificó gran parte de la complejidad de la infraestructura, la creación de una capa de inferencia multimodelo de nivel de producción a escala empresarial presentó su propio conjunto de desafíos:

Pruebas de conmutación por error entre regiones: el desafío más importante surgió durante la validación de escenarios de conmutación por error entre regiones. Probar que el tráfico de inferencia se enruta correctamente entre us-east-1 y us-west-2 bajo varios modos de falla, incluida la degradación parcial del punto final y la limitación regional, requirió construir arneses de prueba personalizados y simular condiciones que son difíciles de reproducir en entornos de desarrollo. El equipo trabajó estrechamente con AWS para validar que las solicitudes se redirigirían automáticamente a una región en buen estado sin afectar la calidad de la respuesta o la latencia, y para ajustar el tiempo de espera y las configuraciones de reintento para la preparación de la producción.

Evaluación comparativa de modelos a escala: la ejecución de evaluaciones comparativas integrales en múltiples modelos candidatos introdujo complejidad a la hora de comparar resultados de manera justa. Las diferencias en tokenización, manejo de ventanas de contexto y formato de respuesta requirieron una normalización cuidadosa antes de que las puntuaciones pudieran compararse de manera significativa. El equipo creó procesos de evaluación automatizados para facilitar la reproducibilidad y reducir la sobrecarga manual durante la selección del modelo.

Lecciones aprendidas

• La abstracción de proveedores rinde dividendos: la inversión temprana en una capa de abstracción de proveedores permitió la integración de Bedrock sin interrumpir la experiencia del usuario de Capella iQ y mantiene la flexibilidad a largo plazo para adoptar nuevos modelos o proveedores sin rediseñar la lógica de la aplicación central.

• La inferencia entre regiones simplifica las operaciones: CRIS manejó cargas de trabajo en ráfagas en todas las regiones sin capacidad preaprovisionada ni lógica de conmutación por error personalizada, lo que mejoró la disponibilidad del servicio y redujo la complejidad operativa.

• La preparación para múltiples modelos requiere una inversión dedicada: el soporte para múltiples modelos de grado de producción exige una inversión sostenida en infraestructura de evaluación comparativa, ingeniería rápida y observabilidad. Los equipos deben planificar esto como un flujo de trabajo continuo, no como una configuración única.

Planes futuros

Couchbase está explorando activamente la optimización de costos mediante la implementación de modelos más pequeños ajustados a través de la capacidad de importación de modelos personalizados de Amazon Bedrock. Al sintetizar conocimientos específicos de tareas en modelos livianos para cargas de trabajo bien delimitadas y de gran volumen (como recomendaciones de índices y explicaciones de consultas), el equipo busca reducir el costo por inferencia manteniendo al mismo tiempo la calidad. Comenzando con Claude Sonnet 4.5 y evolucionando hacia modelos más nuevos a medida que estén disponibles, este enfoque ejemplifica el valor de una arquitectura multimodelo: elegir el modelo correcto para la tarea correcta mientras se adoptan continuamente los últimos avances del modelo dentro de una única infraestructura administrada.

Conclusión

La adopción de Amazon Bedrock por parte de Couchbase para Capella iQ demuestra cómo construir una arquitectura de IA multimodelo resistente dentro de una aplicación de software como servicio (SaaS). En producción, Claude Sonnet 4.5 en Amazon Bedrock logró aproximadamente un 76 por ciento de precisión en los flujos de trabajo principales de Capella iQ. Los objetivos de latencia y rendimiento se cumplieron dentro de márgenes aceptables, y no se observaron regresiones de calidad que afecten al usuario durante las pruebas de tráfico controlado. Los usuarios finales experimentan la misma calidad y capacidad de respuesta que esperan de Capella iQ, ahora respaldada por la infraestructura administrada y la resiliencia entre regiones de Amazon Bedrock. Con una arquitectura independiente del proveedor y un marco de evaluación riguroso, Couchbase está bien posicionado para calificar y adoptar rápidamente modelos básicos más nuevos, incluido Claude Sonnet 5 y generaciones futuras, a medida que estén disponibles. Al invertir en la abstracción de proveedores, la implementación por fases y la evaluación comparativa estandarizada, Couchbase entregó una implementación de nivel de producción que trata la evolución del modelo como una elección de configuración, no como un cambio de código, sin interrumpir la experiencia del desarrollador.

Sobre los autores