Agentes de inteligencia artificial que unifica datos estructurados y no estructurados: transformando el análisis de soporte y más allá con los complementos de Amazon Q

A medida que las organizaciones buscan obtener un mayor valor de sus datos de apoyo de AWS, los equipos operativos están buscando formas de transformar casos de apoyo en bruto y eventos de salud en ideas procesables. Si bien las herramientas de análisis tradicionales pueden proporcionar capacidades básicas de informes, los equipos necesitan soluciones más sofisticadas que puedan comprender y procesar consultas de lenguaje natural sobre sus datos operativos. La arquitectura de generación de recuperación acuática (RAG) forma la base para optimizar grandes resultados del modelo de idioma haciendo referencia a bases de conocimiento autorizadas fuera de sus datos de capacitación antes de generar respuestas. Esta arquitectura utiliza el poder de la búsqueda semántica y las capacidades de recuperación de información para mejorar la precisión.

En nuestra publicación de blog anterior, Derive ideas operativas significativas y procesables de AWS utilizando Amazon Q Businesspresentamos una solución a base de trapo utilizando Amazon Q Business. Sin embargo, si bien este enfoque sobresale en la búsqueda semántica, puede enfrentar desafíos con análisis numéricos y agregaciones precisas. En esta publicación, abordamos estas limitaciones mostrando cómo puede mejorar Amazon Q con complementos personalizados para mejorar el análisis de soporte y la respuesta de incidentes. Nuestra solución combina las fortalezas de RAG con consultas de datos estructurados, lo que permite respuestas más precisas a preguntas analíticas sobre sus datos de soporte de AWS. Las instrucciones de implementación detalladas para la solución en esta publicación están disponibles en nuestro AWS muestras repositorio de github.

Comprender el diseño de Rag para Analytics

La arquitectura de RAG sobresale para encontrar información relevante a través de la coincidencia basada en el contexto, lo que permite las interacciones del lenguaje natural con datos externos. Sin embargo, la arquitectura fundamental de la búsqueda de similitud vectorial, que prioriza la relevancia semántica sobre las capacidades de agregación analítica, puede introducir inexactitudes significativas. Examinemos esta limitación con una consulta simple:

Give me total count of support cases in Feb 2025

La siguiente es una respuesta de solo trapo que indica que el sistema intenta juntar información de varios documentos, informando 190 casos a través de agregaciones potencialmente alucinadas.

Based on the provided JSON files, there were 190 AWS support cases documented in 
February 2025, calculated from the following case counts: 17 cases from Feb 1-3, 
12 cases from Feb 4-5, 21 cases from Feb 7-8, 21 cases from Feb 8-10, 16 cases from 
Feb 10-11, 10 cases from Feb 11-12, 23 cases from Feb 19-20, 22 cases from Feb 20-21,
27 cases from Feb 23-24, and 21 cases from Feb 25-26.

Sin embargo, cuando se mejora con capacidades de consulta de datos estructuradas, la misma consulta produce 958 casos de soporte, el recuento preciso verificado contra el conjunto de datos real:

Based on the query results, there were a total of 958 support cases in February 2025.

Esta limitación se vuelve aún más evidente con consultas moderadamente complejas que requieren un análisis categórico:

Give me OpenSearch Support cases, distribution based on severity, opened in Jan 2025?

La siguiente es una respuesta solo en trapo que muestra un desglose categórico limitado o inexacto:

Based on the support cases data from January 2025, here is the severity distribution 
for OpenSearch cases: 

Urgent: One case was opened regarding cluster health degradation and production system 
downtime

Normal: Two cases were identified:
1. A case about OpenSearch RI Exchange
2. A case concerning blue/green deployment upgrade from version 1.3 to 2.17

The cases demonstrate varying levels of urgency, with one critical production issue 
and two normal severity cases requiring standard response times.

Con la consulta de datos estructuradas, obtenemos distribuciones de gravedad precisas:

Based on the query results for OpenSearch Support cases opened in January 2025,
here's the distribution by severity:
1. Normal severity: 4 cases
2. Critical severity: 4 cases
3. High severity: 3 cases
4. Low severity: 2 cases
5. Urgent severity: 1 case

In total, there were 14 OpenSearch Support cases opened in January 2025. 
The distribution shows that Normal and Critical severity cases were the most common, 
followed by High severity cases. There were fever Low and Urgent severity cases 
during this period.

La brecha se amplía aún más cuando se trata de análisis multidimensional. Considere la siguiente consulta multidimensional esperando un análisis detallado con combinaciones de servicios y patrones temporales.

Consulta:

Find accounts with frequent high-priority support cases since January 2024, 
excluding limit increase requests. For each account and AWS service combination, 
show the total number of cases and how many different days had issues. 
Only include results where there were more than 3 cases, and sort results by the 
highest number of cases first.

Respuesta:

Based on the analysis of high-priority support cases since January 2024, excluding
limit increase requests, here are the key findings:

1. The account with the most frequent high-priority cases is 111111111111, with 
60 cases for the Connect service.
2. The top 5 account and service combinations with the highest number of cases are:
* Account 111111111111 (Connect): 60 cases
* Account 222222222222 (RDS Oracle): 52 cases
* Account 333333333333 (OpenSearch Service): 38 cases
* Account 444444444444 (Aurora PostgreSQL): 25 cases
* Account 555555555555 (EMR): 23 cases

The services that appear most frequently in the top results are:
* Aurora PostgreSQL
* OpenSearch Service
* RDS Oracle
* EMR
* DynamoDB

Interestingly, the number of total cases matches the number of unique days with 
cases for each account-service combination. This suggests that these accounts 
are experiencing issues on different days rather than multiple issues on the 
same day.

There are 89 account-service combinations that have more than 3 high-priority 
cases since January 2024.

Some accounts appear multiple times with different services, indicating they 
may be experiencing issues across various AWS offerings. For example:
* Account 222222222222 appears with RDS Oracle (52 cases), DynamoDB (18 cases), 
and Aurora PostgreSQL (6 cases)
* Account 111111111111 appears with Connect (60 cases) and other services

This information can be useful for identifying accounts that may need additional 
support or proactive engagement to address recurring issues. Would you like to 
focus on a specific aspect of this data or explore further details about 
particular accounts or services?

La siguiente es una respuesta de solo trapo que muestra incapacidad para procesar la misma consulta compleja:

Based on the provided data source, I cannot provide a complete analysis of 
high-priory support cases and their frequency patterns. While there are support 
cases mentioned in the data from January 2024, the data does not contain 
sufficient information about case priorities or enough cases per account 
to identity patterns meeting the threshold of more than 3 cases. 
Additionally, while some technical and customer service cases are shown, 
the data is fragmented across different dates without providing a comprehensive 
view of case volumes or frequencies per account and service.

Estos ejemplos demuestran cómo RAG solo lucha con consultas analíticas de aumento de la complejidad, mientras que nuestra solución mejorada por complementos ofrece un análisis preciso y estructurado en cada nivel. Cuando trabajamos con escenarios que requieren un análisis numérico preciso, podemos mejorar las capacidades de RAG a través de enfoques estructurados:

• Análisis de agregación y patrones: Cuando las indicaciones del usuario incluyen consultas de agregación (como recuentos, totales o distribuciones), requieren un cálculo numérico exacto a través de consultas estructuradas para proporcionar resultados precisos. La búsqueda de similitud vectorial por sí sola no puede garantizar agregaciones numéricas precisas, lo que hace que la consulta de metadatos estructurados sea esencial para estos casos de uso analítico.
• Contexto y análisis de correlación: Los datos externos no estructurados requieren ingeniería de datos reflexiva para extraer y mantener metadatos estructurados (como fechas de creación, categorías, niveles de gravedad y tipos de servicio). Mientras que el trapo se destaca en encontrar contenido semánticamente similar, tener metadatos bien definidos permite capacidades precisas de filtrado y consulta. Por ejemplo, al analizar los problemas de rendimiento del sistema, los metadatos estructurados sobre el tiempo de incidentes, los servicios afectados y sus dependencias permiten un análisis de impacto integral a través de la consulta exacta en lugar de depender únicamente de la coincidencia semántica.

Mejora de la inscectiva de soporte de Q con AI agente

Construir sobre el Q SOLUCIÓN DE ASIGNOS DE SOPORTE (QSI) introducido en Derive ideas operativas significativas y procesables de AWS utilizando Amazon Q Businessdemostraremos cómo mejorar las capacidades analíticas a través de AI de Agentic creando complementos personalizados. Esta mejora preserva la implementación base de QSI al tiempo que agrega un procesamiento analítico preciso a través de consultas de metadatos estructurados.

Descripción general de QSI

El Solución de Insights (QSI) de Amazon Q consta de dos componentes principales:

1. Recopilación de datos Tubería
   • Soporte del módulo de colección utilizando AWS Lambda funciones
   • Los datos de soporte consisten en casos de apoyo de AWS, eventos de salud y controles de asesores de confianza
   • Amazon Eventbridge para la recopilación de datos automatizado. La tubería de datos permite dos mecanismos de sincronización:
     • Actualizaciones de casos en tiempo real: Procesa los casos de soporte de AWS a través de desencadenantes basados en eventos (CreateCase, AddCommunicationToCase, ResolveCase, ReopenCase).
     • Sincronización histórica y diaria: Realiza la sincronización de datos históricas iniciales y actualiza diariamente los datos del asesor de confianza AWS.
   • Almacena datos en formato JSON en centralizado Amazon Simple Storage Service (Amazon S3) balde
   • Admite la agregación de datos de múltiples cuenta a través de organizaciones de AWS
2. Amazon Q Business Application Entorno
   • Implementación de aplicaciones comerciales de Amazon Q
   • Conector de Amazon S3 para la integración de la fuente de datos
   • Configuración de la experiencia web para la interacción del usuario
   • Autenticación a través de Centro de identidad de AWS IAM

Habilitar la agregación de consultas con complementos personalizados para Amazon Q Business

Los complementos personalizados extienden el negocio de Amazon Q para combinar la búsqueda semántica con capacidades de análisis precisos. Los siguientes detalles de implementación describen cómo hemos aumentado la solución QSI base:

• Aumenta el procesamiento del lenguaje natural de QSI con capacidades de consulta estructurada
• Convierte las solicitudes analíticas en precisos Amazon Athena SQL usando un Roca madre de Amazon Modelo de lenguaje grande (LLM)
• Ejecuta consultas contra tablas de metadatos estructuradas
• Proporciona resultados numéricos exactos junto con respuestas de búsqueda semántica

Procesamiento de metadatos

Para habilitar capacidades de consulta precisas, hemos implementado un marco de procesamiento de metadatos robusto que estructura e indexa los datos de soporte:

• Uso de la recopilación de datos existente de QSI en Amazon S3
• Extrae metadatos estructurados de casos de soporte en dos tablas consultables
• Mantiene campos críticos como fechas, categorías, niveles de gravedad
• Habilita las capacidades precisas de filtrado y agregación

Análisis de fuente cruzada

La solución permite un análisis integral en múltiples fuentes de datos a través de capacidades de correlación inteligente:

• Correlaciona los casos de apoyo con eventos de salud
• Habilita una evaluación operativa integral
• Admite la detección de patrones en múltiples fuentes de datos

Descripción general de la arquitectura

La siguiente ilustración muestra cómo la solución comercial mejorada de Amazon Q integra complementos personalizados con la arquitectura QSI existente. El diagrama demuestra el flujo de la consulta del usuario a través del procesamiento analítico hasta la generación de respuesta, destacando cómo la consulta de datos estructurados complementa las capacidades de búsqueda semántica basadas en RAG.

Cuando un usuario envía una consulta analítica como Show me OpenSearch case distribution based on severityocurre el siguiente proceso:

1. El complemento personalizado detecta la intención analítica y desencadena una función lambda
2. La función Lambda utiliza un Bedrock LLM de Amazon para transformar la consulta del lenguaje natural en Athena SQL preciso de Athena
3. La consulta se ejecuta contra metadatos estructurados en Athena
4. Los resultados se sintetizan nuevamente en el lenguaje natural y se presentan junto con las respuestas tradicionales del trapo

Este enfoque permite un análisis preciso mientras se mantiene la interfaz de conversación que los usuarios esperan.

Ejemplo de implementación

Aquí hay una interacción de muestra que demuestra las capacidades mejoradas. Comencemos con una consulta básica para comprender el volumen general del caso OpenSearch, utilizando consultas de datos estructuradas:

Consulta:

Give me OpenSearch cases in Jan 2025

Respuesta:

Based on the query results for OpenSearch cases in January 2025, here's a summary:
1. Total cases: 15
2. Severity breakdown:
Critical: 4 cases
High: 3 cases
Urgent: 1 case
Normal: 3 cases
Low: 2 cases
3. Status: All cases are resolved
4. Most common issues:
Cluster health problems (yellow status)
Blue/Green deployment issues
Performance concerns (high CPU utilization)
5. Services involved:
OpenSearch Service Managed Cluster: 13 cases
OpenSearch Service Ingestion: 2 cases

The cases span various topics including cluster health, deployments, performance, 
and configuration issues. Is there a specific aspect of these cases you'd like 
more information on?

Ahora, utilizando capacidades de RAG para analizar el contenido de casos no estructurado para ideas arquitectónicas:

Consulta:

Out of these, what are the OpenSearch issues that are related to architecture 
deficiencies? 

Respuesta:

Based on the available data, several architectural issues have been identified in OpenSearch deployments:

* The shard count per node exceeding recommended limits is a significant 
architectural concern, with validation errors occurring when scaling up 
node counts. The recommended limit is 1,000 shards per node and exceeding 
this requires careful architectural planning. 

* Master node scaling is another architectural challenge, where insufficient 
master node capacity can limit cluster expansion. This requires proper 
configuration of master node instance types according to the number of nodes 
and shards in the domain. 

* Resource utilization issues, particularly around JVM Memory Pressure and 
CPU utilization, indicate potential architectural shortcomings. 
The system architecture should be designed to maintain JVM Memory Pressure 
below 80% and CPU Utilization below 85% for optimal performance. 

* The system's handling of blue/green deployments shows architectural limitations, 
as these operations cause performance impacts and increased latency during data 
migration to new nodes. 

Continuar con el análisis basado en el trapo de los detalles del caso para evaluar los patrones de implementación:

Consulta:

Given the high shard count, JVM, or other data can we make inferences about whether 
they are using this correctly?

Respuesta:

Based on the data discussed, there are strong indicators that the OpenSearch system 
is not being used optimally:

JVM Memory Management Issues:
1. Memory pressure consistently exceeded recommended thresholds (above 78% and 
eventually over 90%)
2. The 64GB initial heap size configuration proved inadequate for the workload
3. Circuit breaking exceptions and cluster blocks occurred due to memory issues

Shard Management Problems:
1. The system appears to have exceeded the recommended limit of 1,000 shards 
per node
2. Too many small shards created unnecessary system strain
Large shards complicated failure recovery processes

Resource Utilization:
1. Failed to maintain recommended thresholds:
2. JVM Memory Pressure should be below 80%
3. CPU Utilization should be below 85%
4. Continuous memory pressure issues

Failed snapshots
These indicators strongly suggest improper sizing and resource allocation for 
the workload, pointing to incorrect implementation or configuration of the 
OpenSearch system. Better capacity planning and adherence to best practices 
would be necessary for optimal performance.

Finalmente, aquí hay otro ejemplo de análisis de datos estructurados con una consulta compleja que demuestra capacidades de agregación multidimensional:

Consulta:

For high-severity support cases since January 1, 2024, show the number of 
total cases and after-hours cases for each account and service combination. 
Define after-hours as before 1 PM UTC, after 1 AM UTC, or times falling within 
the weekend. Only include results with more than 3 after-hours cases. Sort by 
the highest number of after-hours cases. Exclude limit increase requests.

Respuesta:

Based on the analysis of high-severity support cases since January 1, 2024, 
here's a summary of the results, focusing on accounts and services with more 
than 3 after-hours cases:

1. The account with the highest number of after-hours cases (48) is 111111111111, 
for the Connect service. They have a total of 66 high-severity cases.
2. The second highest is account 333333333333 with 40 after-hours cases for the 
OpenSearch Service Managed Cluster, out of 49 total cases.
3. Account 222222222222 has 38 after-hours cases for RDS Oracle, out of 64 
total cases.
4. EMR service for account 555555555555 has 19 after-hours cases out of 23 
total cases.
5. Bedrock service for account 666666666666 has 17 after-hours cases out of 
24 total cases.

The results are sorted by the highest number of after-hours cases, and limit 
increase requests have been excluded as requested. After-hours cases are 
defined as those created before 1 PM UTC, after 1 AM UTC, or times falling 
within the weekend.

Would you like more details on a specific account or service, or do you need 
a further analysis of this data?

La respuesta combina un análisis numérico preciso con una comprensión semántica, proporcionando información procesable para las revisiones operativas.

Beneficios e impacto

Esta arquitectura del complemento ofrece varias mejoras clave:

• Análisis preciso: Recuentos y distribuciones exactas reemplazan la coincidencia semántica aproximada
• Análisis contextual: Mantiene el contexto analítico en los hilos de conversación
• Comprensión arquitectónica: Mejor correlación de problemas relacionados a través de análisis estructurado

Implementar la aplicación comercial de Amazon Q

El siguiente es un proceso de implementación simplificado. Para obtener instrucciones detalladas, consulte el Módulo de creación de aplicaciones comerciales de Amazon Q.

Requisitos previos

1. AWS Cloudshell se recomienda desde entonces, viene preinstalado con las bibliotecas y herramientas requeridas. Alternativamente, puede usar una máquina local con el Interfaz de línea de comandos de AWS (AWS CLI) instalado y configurado con credenciales válidas.
2. Dos cubos S3:
   • Soporte de datos de datos para almacenar datos de casos de soporte de AWS
   • Bucket de recursos como almacenamiento temporal para recursos Lambda para la implementación (se puede eliminar después de la implementación)
3. Instancia de IAM Identity Center configurada
4. La solución necesita datos de soporte de AWS recopilados utilizando el Soporte de la tubería de datos. Puede implementar ahora y agregar datos más tarde, pero la funcionalidad depende de la disponibilidad de datos en su cubo S3.
5. Acceso al soneto Cloud 3-5 de Anthrope a través de Amazon Bedrock. Ver Agregue o retire el acceso a los modelos de Amazon Bedrock Foundation
6. El default La base de datos debe existir en Atenea. Si no, puede crear uno usando el editor de consultas de Athena para crear la base de datos.

Pasos de implementación

Puede nosotros el siguiente script para implementar la solución Q. No se necesitan pasos manuales: el script maneja la creación y configuración de la pila automáticamente.

# Clone the repository
git clone https://github.com/aws-samples/support-insights-with-amazon-q.git
cd q_application
chmod +x deploy_q_stacks.sh
./deploy_q_stacks.sh

Limpiar

Para eliminar los recursos, elimine los cubos S3 y las pilas de CloudFormation. Elimine las pilas de CloudFormation en el siguiente orden:

1. case-metadata-stack
2. amazon-q-stack
3. custom-plugin-stack

Tenga en cuenta que esto no eliminará los cubos S3 existentes, debe eliminar manualmente los cubos S3.

Conclusión

Al combinar la comprensión semántica de Rag con capacidades analíticas precisas a través de complementos, hemos transformado Amazon Q Business en una poderosa plataforma de análisis operativo. En los ejemplos de esta publicación, puede ver cómo las organizaciones pueden usar esta mejora para obtener ideas más precisas y procesables de sus datos de soporte de AWS, apoyando una mejor toma de decisiones operativas y una resolución de problemas proactivos. Si bien se demuestra a través del análisis de datos de soporte para mejoras operativas, estos patrones se aplican en todos los dominios que combinan fuentes de datos estructuradas y no estructuradas.

Obtenga más información

• Explorar el Documentación de Amazon Q Para comprender más sobre la construcción de complementos personalizados
• Consulte estos recursos relacionados:

Para preguntas y comentarios, visite el AWS Re: Post o contactar Soporte de AWS.

Sobre los autores

Chitresh Saxena es un especialista en AI/ML TAM especializado en soluciones generativas de IA y dedicada a ayudar a los clientes a adoptar con éxito AI/ML en AWS. Se destaca para comprender las necesidades del cliente y proporciona orientación técnica para construir, lanzar y escalar soluciones de IA que resuelven problemas comerciales complejos.

Kevin Morgan es un gerente de apoyo empresarial de Sr. en AWS que ayuda a los clientes a acelerar su viaje de adopción en la nube a través del liderazgo práctico y la orientación técnica. Como miembro de la experiencia de desarrollo de NextGen Developer TFC, se especializa en experiencia de constructor, cloudps y DevOps. Fuera del trabajo, Kevin disfruta ser un maestro de juegos para D&D y es un entusiasta de la computación retro.