Vanguard constrói Virtual Analyst na AWS e mostra que IA conversacional é problema de dados, não de modelo

A Vanguard publicou no blog da AWS o relato de como construiu o Virtual Analyst, ferramenta interna de IA conversacional que deixa analistas financeiros e stakeholders de negócio consultar datasets complexos sem precisar escrever SQL nem esperar dias pelo time de dados.

O ponto central do post não é o modelo. É a infraestrutura de dados que precisa existir antes do modelo fazer sentido.

O problema real

Antes do Virtual Analyst, pergunta básica de analista virava query SQL complicada ou ticket pro time de dados que demorava vários dias pra responder. A Vanguard percebeu cedo que IA conversacional resolveria isso, só que com uma pegadinha: o gargalo não estava no foundation model, estava no dado.

Construir IA conversacional eficaz não era um desafio de machine learning, era um desafio de arquitetura de dados.

Essa é a frase que vale o post inteiro. Quem tá tentando colar RAG (Retrieval-Augmented Generation) ou text-to-SQL em cima de data warehouse sem governança vai bater nessa parede.

A stack AWS

O Virtual Analyst roda em cima de:

• Amazon Bedrock pros foundation models que fazem o entendimento de linguagem natural
• Amazon Bedrock Guardrails pra proteger inputs e outputs com dado financeiro sensível
• Amazon ECS (Elastic Container Service) pra compute escalável
• Amazon DynamoDB pra persistir conversas com baixa latência
• Amazon S3 pra storage
• Amazon SageMaker pra experimentação
• Amazon Redshift como data warehouse central
• AWS Glue pra catalogação de dados e jobs de ETL

Os oito princípios de dados prontos pra IA

A equipe destilou a experiência em oito princípios. Vale o detalhe porque é onde o post foge do marketing puro.

1. Modelos claros de produto de dados e operação. Cada ativo crítico precisa de dono de negócio E dono técnico, com SLAs (Service Level Agreements) de freshness e tolerância de reconciliação documentados.

2. Governança e segurança definidas cedo. Identity management corporativo, controle de acesso por role, autorização em nível de query, políticas de retenção. A Vanguard implementou logging de eventos de autorização pra atender exigências regulatórias.

3. Catálogo de metadados que une contexto técnico e de negócio. É comum ter metadado técnico completo (tipos, lineage, relações) e zero metadado de negócio (definições, ontologia de domínio, regras). Sem os dois juntos, o modelo gera SQL tecnicamente correto mas semanticamente errado.

4. Camada semântica pra operacionalizar o metadado de negócio. Traduz definições e regras em lógica executável. Exemplo citado: a definição de customer lifetime value se mantém igual entre departamentos porque a camada semântica força isso.

5. Exemplos de ground truth. Biblioteca de pares pergunta-SQL. A Vanguard montou mais de 50 exemplares que servem pra três coisas: few-shot prompt, benchmark de avaliação e teste de regressão. Recomendação: começar com 20 a 30 cobrindo os padrões mais comuns.

6. Checagens automáticas de qualidade. Distribuição (anomalia em padrões), referencial (relações entre tabelas válidas), reconciliação (consistência entre sistemas) e freshness (atualização no horário).

7. Controle de mudança como código. Definições semânticas, exemplares e configurações de pipeline ficam em version control com CI/CD, revisão por par e aprovação por stakeholder pra mudanças que afetam KPI ou SLA.

8. Avaliação contínua. Métricas de negócio (horas de analista economizadas, time-to-insight, satisfação, impacto em receita), suíte de regressão contínua e alerta automático pra degradação de modelo.

Resultados

O post lista os ganhos sem dar números absolutos:

• Time-to-insight de dias pra minutos em queries financeiras complexas
• Usuário de negócio acessa dado direto, sem saber SQL
• Alta acurácia no SQL gerado (sem percentual)
• Carga do time de dados reduzida pra pedidos de rotina
• Framework reutilizável adotado em outras unidades de negócio da Vanguard

Vale o filtro de sempre em case study patrocinado: "alta acurácia" sem número é marketing. O que importa pra quem vai replicar é a estrutura dos oito princípios, que esses sim são acionáveis.

Próximos passos

A Vanguard tá avaliando knowledge graphs pra resolver entidade canônica e inferência de join, e RAG via Amazon Bedrock Knowledge Bases pra usar a biblioteca de exemplares como base de recuperação.

Por que importa

O recado prático pra quem tá construindo text-to-SQL ou agente analítico em ambiente corporativo: parar de gastar ciclo trocando de modelo e começar a investir em catálogo de metadado, camada semântica e ground truth. Foundation model é commodity, dado pronto pra IA não é.