Precisión de respuestas en alrededor de 1.200 preguntas de prueba
Dominio de OpenSearch en lugar de aproximadamente 9.000 colecciones planificadas
Proveedores compatibles, frente a 3.000, sin cambios en la arquitectura
Halo AI Inc.
Novato, CA
Tecnología / Inteligencia de proveedores impulsada por IA
Amazon Bedrock, Amazon OpenSearch Service, AWS Fargate, AWS Lambda, Amazon API Gateway, Amazon CloudWatch, AWS CloudFormation, Amazon VPC
Halo AI, una empresa tecnológica que atiende a clientes empresariales con inteligencia de proveedores impulsada por IA, necesitaba escalar su sistema de recuperación de conocimiento “Universal Ask Halo” desde un alcance de prueba de 10 proveedores para dar soporte a miles de proveedores en múltiples niveles de suscripción. La arquitectura original, que utilizaba colecciones separadas de Amazon OpenSearch Serverless para cada combinación de proveedor y nivel, habría requerido aproximadamente 9.000 colecciones a escala completa, superando los límites del servicio de AWS. Avahi rediseñó la solución utilizando un único dominio aprovisionado de Amazon OpenSearch Service con aislamiento de inquilinos basado en metadatos, capacidades de búsqueda híbrida que combinan recuperación semántica y por palabras clave, y una puerta de enlace de autorización basada en Fargate. El nuevo diseño escala con el volumen de datos en lugar de la cantidad de colecciones, elimina el límite máximo de la base de conocimiento y mejora la calidad de recuperación para consultas de términos exactos.
Halo AI Inc., con sede en Novato, California, ofrece soluciones de inteligencia de proveedores impulsadas por IA a clientes empresariales. Su plataforma permite a las organizaciones monitorear y analizar información en amplios portafolios de proveedores y vendedores, con clientes que actualmente realizan seguimiento de hasta 3.000 proveedores y proyectan crecer hasta aproximadamente 10.000 proveedores. Halo AI ofrece niveles de suscripción escalonados que brindan distintas profundidades de inteligencia de proveedores, lo que exige un estricto aislamiento de datos entre clientes y niveles de acceso.
El sistema inicial “Universal Ask Halo” de Halo AI se construyó sobre Amazon Bedrock con una arquitectura de base de conocimiento que aprovisionaba una colección vectorial de Amazon OpenSearch Serverless por proveedor y por nivel de suscripción. Este diseño proporcionaba un sólido aislamiento de inquilinos, pero solo se validó para un alcance de prueba de 5 a 10 proveedores.
A medida que Halo AI se preparaba para dar soporte a los portafolios completos de proveedores monitoreados de sus clientes, surgió una limitación crítica de escalabilidad. Con aproximadamente 3.000 proveedores en 3 niveles de suscripción, la arquitectura requeriría cerca de 9.000 colecciones individuales de base de conocimiento. Esto superaba ampliamente el límite de Amazon Bedrock de 100 bases de conocimiento por cuenta de AWS. Si bien una solución alternativa de múltiples cuentas mediante AWS Control Tower era técnicamente posible, agregaría una complejidad de ingeniería sustancial y una mayor carga operativa.
Además, la facturación de OpenSearch Serverless se cobra contra mínimos de capacidad a nivel de cuenta, en lugar del volumen real de datos, lo que vuelve desfavorable la estructura de costos a medida que crecía la cantidad de colecciones. Sin un rediseño, Halo AI no podría escalar su producto para satisfacer la demanda de los clientes, y el modelo de costos por colección se volvería cada vez más ineficiente.
Durante las pruebas de aceptación de usuarios, el equipo de QA de Halo AI también identificó una regresión en la calidad de recuperación que debía investigarse y resolverse antes de que el sistema pudiera pasar a producción.
AWS proporcionó la base del sistema de recuperación impulsado por IA de Halo AI mediante las capacidades administradas de IA generativa de Amazon Bedrock y la funcionalidad de búsqueda vectorial de Amazon OpenSearch Service. La combinación de Bedrock para inferencia y OpenSearch para recuperación híbrida (búsqueda semántica más búsqueda por palabras clave) entregó la calidad de búsqueda que Halo AI requería. Los servicios administrados de AWS redujeron la carga operativa y aportaron la escalabilidad necesaria para dar soporte a miles de proveedores, y las integraciones nativas entre servicios simplificaron la arquitectura.
Avahi ya había diseñado y construido el sistema inicial Universal Ask Halo de Halo AI, lo que le dio al equipo un profundo conocimiento de la arquitectura existente, la base de código y los requisitos del negocio. Cuando se identificó la limitación de escalabilidad durante una revisión de costos de AWS, Avahi trabajó de forma proactiva con Halo AI para diagnosticar la causa raíz y proponer un enfoque de rediseño. La experiencia de Avahi en Amazon Bedrock y OpenSearch, combinada con su comprensión de los requisitos de aislamiento multiinquilino de Halo AI, los posicionó para entregar una solución que preservara las garantías de seguridad y, al mismo tiempo, eliminara el límite de escalabilidad.
Avahi rediseñó el sistema de recuperación de conocimiento de Halo AI para que escalara con el volumen de datos en lugar de la cantidad de colecciones, manteniendo un estricto aislamiento por inquilino y por nivel.
Almacenamiento vectorial consolidado
El equipo reemplazó las colecciones de OpenSearch Serverless por proveedor y por nivel por un único dominio aprovisionado de Amazon OpenSearch Service. Este dominio almacena vectores de todos los proveedores y niveles, con el ID del proveedor, el nivel y el ID del inquilino como metadatos en cada fragmento indexado. El dominio aprovisionado se dimensionó según el corpus medido utilizando nodos de datos optimizados para memoria con almacenamiento EBS, configurado con ubicación en VPC, control de acceso de granularidad fina y cifrado en reposo y en tránsito. Se preconfiguró una alarma de utilización de almacenamiento en CloudWatch para anticipar los disparadores de escalamiento antes de alcanzar los límites de capacidad.
Implementación de búsqueda híbrida
La solución implementó recuperación híbrida combinando búsqueda vectorial k-NN con búsqueda por palabras clave BM25, fusionadas mediante Reciprocal Rank Fusion (RRF). El mapeo del índice incluyó un campo knn_vector configurado con el motor FAISS, el método HNSW y el tipo de espacio de producto interno, junto con un campo chunk_text para la indexación BM25. Este enfoque híbrido mejoró la calidad de recuperación, en particular para consultas de términos exactos que la búsqueda semántica pura puede pasar por alto.
Puerta de enlace de autorización
Avahi amplió el servicio existente de AWS Fargate, siempre activo, para convertirlo en una puerta de enlace de recuperación y autorización. Cada solicitud de recuperación se valida contra los derechos del inquilino solicitante utilizando la identidad del inquilino establecida por el autorizador de solicitudes de API Gateway, combinada con los metadatos de los fragmentos. La puerta de enlace verifica que el inquilino solicitante tenga derecho a la combinación específica de proveedor y nivel antes de que continúe la recuperación, garantizando que los clientes no puedan acceder a datos fuera de su nivel de suscripción.
Actualizaciones de canalización e integración
Se actualizaron las funciones de recuperación existentes en Lambda para enrutar a través de la capa de autorización en Fargate y emitir consultas híbridas con fusión RRF. La canalización diaria de ingesta se modificó para escribir fragmentos en el nuevo dominio aprovisionado con el etiquetado correcto de metadatos. El flujo de extremo a extremo (de Lambda a la verificación de autorización en Fargate, a la recuperación híbrida en OpenSearch, a la inferencia en Bedrock) mantuvo intacto el contrato de API del back-end existente en todo momento.
Migración y validación de datos
Todos los datos vectoriales y de texto existentes se migraron desde la estructura de múltiples colecciones de OpenSearch Serverless al nuevo índice aprovisionado con el etiquetado correcto de metadatos. Se registraron los conteos de fragmentos por proveedor y nivel antes de la migración y se validaron después, con verificaciones puntuales de integridad de vectores antes de desmantelar las colecciones Serverless.
Aseguramiento de calidad
El equipo investigó y resolvió la regresión en la calidad de recuperación identificada durante UAT, volviendo a ejecutar el conjunto de pruebas de evaluación de LLM acordado, incluidos subconjuntos de consultas de términos exactos, contra la canalización de recuperación híbrida para validar los resultados antes de la aprobación final.
Un único dominio aprovisionado de Amazon OpenSearch Service con mapeo de índice híbrido que admite búsqueda k-NN y BM25 con fusión RRF
Puerta de enlace de recuperación y autorización basada en Fargate que aplica verificaciones de derechos por solicitud, por inquilino y por nivel
Datos vectoriales y de texto migrados con conteos de fragmentos e integridad validados
Funciones de recuperación en Lambda actualizadas, enrutadas a través de la puerta de enlace de autorización
Canalización diaria de ingesta modificada para escribir en el nuevo dominio con etiquetado de metadatos
Regresión en la calidad de recuperación resuelta con resultados de evaluación validados
Plantillas de CloudFormation actualizadas para el dominio aprovisionado, el servicio de Fargate y la configuración de la alarma de CloudWatch
Diagrama de arquitectura, diagrama de flujo de datos y manual operativo actualizados
Configuración del controlador de consultas híbridas y parámetros de RRF documentados
La solución rediseñada eliminó el límite de escalabilidad que habría bloqueado el crecimiento de Halo AI. El sistema ahora escala con el volumen de datos en lugar de la cantidad de bases de conocimiento, respaldando el camino de Halo AI desde aproximadamente 3.000 proveedores hasta una proyección de 10.000 proveedores sin cambios en la arquitectura.
La implementación de búsqueda híbrida mejoró la calidad de recuperación para consultas de términos exactos, manteniendo las capacidades de búsqueda semántica. El enfoque de aislamiento basado en metadatos preservó la estricta separación por inquilino y por nivel requerida por el modelo de negocio multiinquilino de Halo AI, con cada solicitud validada contra los derechos antes de devolver datos.
La arquitectura consolidada también mejoró la eficiencia de costos al pasar de la facturación de OpenSearch Serverless por OCU (cobrada contra mínimos de capacidad a nivel de cuenta) a la facturación por instancias aprovisionadas, que escala con el volumen real de datos en lugar de la cantidad de colecciones.
El modelo RAG desarrollado entregó una precisión del 98,5%, muy por encima de lo que puede ofrecer un RAG empresarial. Lo probamos con aproximadamente 1.200 preguntas.
Halo AI Inc.
Novato, CA
Tecnología / Inteligencia de proveedores impulsada por IA
Amazon Bedrock, Amazon OpenSearch Service, AWS Fargate, AWS Lambda, Amazon API Gateway, Amazon CloudWatch, AWS CloudFormation, Amazon VPC
Halo AI, una empresa tecnológica que atiende a clientes empresariales con inteligencia de proveedores impulsada por IA, necesitaba escalar su sistema de recuperación de conocimiento “Universal Ask Halo” desde un alcance de prueba de 10 proveedores para dar soporte a miles de proveedores en múltiples niveles de suscripción. La arquitectura original, que utilizaba colecciones separadas de Amazon OpenSearch Serverless para cada combinación de proveedor y nivel, habría requerido aproximadamente 9.000 colecciones a escala completa, superando los límites del servicio de AWS. Avahi rediseñó la solución utilizando un único dominio aprovisionado de Amazon OpenSearch Service con aislamiento de inquilinos basado en metadatos, capacidades de búsqueda híbrida que combinan recuperación semántica y por palabras clave, y una puerta de enlace de autorización basada en Fargate. El nuevo diseño escala con el volumen de datos en lugar de la cantidad de colecciones, elimina el límite máximo de la base de conocimiento y mejora la calidad de recuperación para consultas de términos exactos.
Halo AI Inc., con sede en Novato, California, ofrece soluciones de inteligencia de proveedores impulsadas por IA a clientes empresariales. Su plataforma permite a las organizaciones monitorear y analizar información en amplios portafolios de proveedores y vendedores, con clientes que actualmente realizan seguimiento de hasta 3.000 proveedores y proyectan crecer hasta aproximadamente 10.000 proveedores. Halo AI ofrece niveles de suscripción escalonados que brindan distintas profundidades de inteligencia de proveedores, lo que exige un estricto aislamiento de datos entre clientes y niveles de acceso.
El sistema inicial “Universal Ask Halo” de Halo AI se construyó sobre Amazon Bedrock con una arquitectura de base de conocimiento que aprovisionaba una colección vectorial de Amazon OpenSearch Serverless por proveedor y por nivel de suscripción. Este diseño proporcionaba un sólido aislamiento de inquilinos, pero solo se validó para un alcance de prueba de 5 a 10 proveedores.
A medida que Halo AI se preparaba para dar soporte a los portafolios completos de proveedores monitoreados de sus clientes, surgió una limitación crítica de escalabilidad. Con aproximadamente 3.000 proveedores en 3 niveles de suscripción, la arquitectura requeriría cerca de 9.000 colecciones individuales de base de conocimiento. Esto superaba ampliamente el límite de Amazon Bedrock de 100 bases de conocimiento por cuenta de AWS. Si bien una solución alternativa de múltiples cuentas mediante AWS Control Tower era técnicamente posible, agregaría una complejidad de ingeniería sustancial y una mayor carga operativa.
Además, la facturación de OpenSearch Serverless se cobra contra mínimos de capacidad a nivel de cuenta, en lugar del volumen real de datos, lo que vuelve desfavorable la estructura de costos a medida que crecía la cantidad de colecciones. Sin un rediseño, Halo AI no podría escalar su producto para satisfacer la demanda de los clientes, y el modelo de costos por colección se volvería cada vez más ineficiente.
Durante las pruebas de aceptación de usuarios, el equipo de QA de Halo AI también identificó una regresión en la calidad de recuperación que debía investigarse y resolverse antes de que el sistema pudiera pasar a producción.
AWS proporcionó la base del sistema de recuperación impulsado por IA de Halo AI mediante las capacidades administradas de IA generativa de Amazon Bedrock y la funcionalidad de búsqueda vectorial de Amazon OpenSearch Service. La combinación de Bedrock para inferencia y OpenSearch para recuperación híbrida (búsqueda semántica más búsqueda por palabras clave) entregó la calidad de búsqueda que Halo AI requería. Los servicios administrados de AWS redujeron la carga operativa y aportaron la escalabilidad necesaria para dar soporte a miles de proveedores, y las integraciones nativas entre servicios simplificaron la arquitectura.
Avahi ya había diseñado y construido el sistema inicial Universal Ask Halo de Halo AI, lo que le dio al equipo un profundo conocimiento de la arquitectura existente, la base de código y los requisitos del negocio. Cuando se identificó la limitación de escalabilidad durante una revisión de costos de AWS, Avahi trabajó de forma proactiva con Halo AI para diagnosticar la causa raíz y proponer un enfoque de rediseño. La experiencia de Avahi en Amazon Bedrock y OpenSearch, combinada con su comprensión de los requisitos de aislamiento multiinquilino de Halo AI, los posicionó para entregar una solución que preservara las garantías de seguridad y, al mismo tiempo, eliminara el límite de escalabilidad.
Avahi rediseñó el sistema de recuperación de conocimiento de Halo AI para que escalara con el volumen de datos en lugar de la cantidad de colecciones, manteniendo un estricto aislamiento por inquilino y por nivel.
Almacenamiento vectorial consolidado
El equipo reemplazó las colecciones de OpenSearch Serverless por proveedor y por nivel por un único dominio aprovisionado de Amazon OpenSearch Service. Este dominio almacena vectores de todos los proveedores y niveles, con el ID del proveedor, el nivel y el ID del inquilino como metadatos en cada fragmento indexado. El dominio aprovisionado se dimensionó según el corpus medido utilizando nodos de datos optimizados para memoria con almacenamiento EBS, configurado con ubicación en VPC, control de acceso de granularidad fina y cifrado en reposo y en tránsito. Se preconfiguró una alarma de utilización de almacenamiento en CloudWatch para anticipar los disparadores de escalamiento antes de alcanzar los límites de capacidad.
Implementación de búsqueda híbrida
La solución implementó recuperación híbrida combinando búsqueda vectorial k-NN con búsqueda por palabras clave BM25, fusionadas mediante Reciprocal Rank Fusion (RRF). El mapeo del índice incluyó un campo knn_vector configurado con el motor FAISS, el método HNSW y el tipo de espacio de producto interno, junto con un campo chunk_text para la indexación BM25. Este enfoque híbrido mejoró la calidad de recuperación, en particular para consultas de términos exactos que la búsqueda semántica pura puede pasar por alto.
Puerta de enlace de autorización
Avahi amplió el servicio existente de AWS Fargate, siempre activo, para convertirlo en una puerta de enlace de recuperación y autorización. Cada solicitud de recuperación se valida contra los derechos del inquilino solicitante utilizando la identidad del inquilino establecida por el autorizador de solicitudes de API Gateway, combinada con los metadatos de los fragmentos. La puerta de enlace verifica que el inquilino solicitante tenga derecho a la combinación específica de proveedor y nivel antes de que continúe la recuperación, garantizando que los clientes no puedan acceder a datos fuera de su nivel de suscripción.
Actualizaciones de canalización e integración
Se actualizaron las funciones de recuperación existentes en Lambda para enrutar a través de la capa de autorización en Fargate y emitir consultas híbridas con fusión RRF. La canalización diaria de ingesta se modificó para escribir fragmentos en el nuevo dominio aprovisionado con el etiquetado correcto de metadatos. El flujo de extremo a extremo (de Lambda a la verificación de autorización en Fargate, a la recuperación híbrida en OpenSearch, a la inferencia en Bedrock) mantuvo intacto el contrato de API del back-end existente en todo momento.
Migración y validación de datos
Todos los datos vectoriales y de texto existentes se migraron desde la estructura de múltiples colecciones de OpenSearch Serverless al nuevo índice aprovisionado con el etiquetado correcto de metadatos. Se registraron los conteos de fragmentos por proveedor y nivel antes de la migración y se validaron después, con verificaciones puntuales de integridad de vectores antes de desmantelar las colecciones Serverless.
Aseguramiento de calidad
El equipo investigó y resolvió la regresión en la calidad de recuperación identificada durante UAT, volviendo a ejecutar el conjunto de pruebas de evaluación de LLM acordado, incluidos subconjuntos de consultas de términos exactos, contra la canalización de recuperación híbrida para validar los resultados antes de la aprobación final.
Un único dominio aprovisionado de Amazon OpenSearch Service con mapeo de índice híbrido que admite búsqueda k-NN y BM25 con fusión RRF
Puerta de enlace de recuperación y autorización basada en Fargate que aplica verificaciones de derechos por solicitud, por inquilino y por nivel
Datos vectoriales y de texto migrados con conteos de fragmentos e integridad validados
Funciones de recuperación en Lambda actualizadas, enrutadas a través de la puerta de enlace de autorización
Canalización diaria de ingesta modificada para escribir en el nuevo dominio con etiquetado de metadatos
Regresión en la calidad de recuperación resuelta con resultados de evaluación validados
Plantillas de CloudFormation actualizadas para el dominio aprovisionado, el servicio de Fargate y la configuración de la alarma de CloudWatch
Diagrama de arquitectura, diagrama de flujo de datos y manual operativo actualizados
Configuración del controlador de consultas híbridas y parámetros de RRF documentados
La solución rediseñada eliminó el límite de escalabilidad que habría bloqueado el crecimiento de Halo AI. El sistema ahora escala con el volumen de datos en lugar de la cantidad de bases de conocimiento, respaldando el camino de Halo AI desde aproximadamente 3.000 proveedores hasta una proyección de 10.000 proveedores sin cambios en la arquitectura.
La implementación de búsqueda híbrida mejoró la calidad de recuperación para consultas de términos exactos, manteniendo las capacidades de búsqueda semántica. El enfoque de aislamiento basado en metadatos preservó la estricta separación por inquilino y por nivel requerida por el modelo de negocio multiinquilino de Halo AI, con cada solicitud validada contra los derechos antes de devolver datos.
La arquitectura consolidada también mejoró la eficiencia de costos al pasar de la facturación de OpenSearch Serverless por OCU (cobrada contra mínimos de capacidad a nivel de cuenta) a la facturación por instancias aprovisionadas, que escala con el volumen real de datos en lugar de la cantidad de colecciones.
El modelo RAG desarrollado entregó una precisión del 98,5%, muy por encima de lo que puede ofrecer un RAG empresarial. Lo probamos con aproximadamente 1.200 preguntas.
Exploremos juntos sus oportunidades de IA de alto impacto en una sesión gratuita
