Inteligência Artificial: A/B testing prático em Microsoft Fabric

Experimentar é a única forma de saber se um modelo melhora decisões reais; sem um A/B test bem desenhado está apenas a adivinhar.

Por que fazer A/B testing para modelos de IA?

Num contexto empresarial, um modelo de IA não é apenas um artefacto técnico — é um componente de decisão que impacta receitas, custos e experiência do utilizador. Um novo modelo que promete maior acerto pode, na prática, alterar o comportamento dos utilizadores, aumentar custos operacionais ou introduzir efeitos secundários indesejados. Os A/B tests trazem a evidência necessária: com um desenho experimental adequado consegue avaliar o efeito causal do modelo sobre métricas de negócio reais e evitar decisões baseadas apenas em métricas offline (ROC, AUC, loss).

As métricas offline dizem-lhe quão bem um modelo prevê um rótulo em dados etiquetados; os A/B tests dizem-lhe qual o impacto económico dessa previsão quando integrado numa aplicação. Por exemplo, um modelo de detecção de fraude com AUC melhorada pode também aumentar os falsos positivos em produção e, como consequência, bloquear carteiras legítimas — traduzindo‑se em perda de receitas e desgaste de clientes. Um A/B test bem planeado quantifica esse trade‑off em termos de churn, receita, custo por aquisição (CPA) ou redução de fraude.

Para organizações que usam Microsoft Fabric, integrar os A/B tests nos pipelines traz vantagens operacionais: controlo de versões, persistência de atribuições, telemetria centralizada e capacidade de automatizar análises em ambiente de produção. Em vez de confiar em scripts ad‑hoc, consegue criar fluxos reprodutíveis que registam quem foi exposto a que versão, quando e com que features — reduzindo o risco de regressão quando faz deploy de novos modelos.

Arquitectura prática no Microsoft Fabric

Uma arquitectura pragmática para A/B testing no Fabric combina componentes já familiares: Lakehouse (Delta) para dados brutos, metadados e resultados de scoring; Spark Notebooks ou Jobs para preparação e scoring em batch; pipelines para orquestração; e Power BI para monitorização dos resultados experimentais. A ideia central é tratar o experimento como um primeiro‑classe cidadão na plataforma.

Componentes e responsabilidades típicas:

• OneLake / Delta Lake: armazenamento de eventos, atribuições experimentais e resultados de scoring. Estruture tabelas por experiment_id e por data para facilidade de partição e limpeza (por exemplo: experimental_assignments(partition: experiment_id, dt), experiment_results(partition: experiment_id, dt)).
• Spark Jobs / Notebooks: preparação de features, hashing/atribuição determinística e scoring em batch para grandes volumes. Utilize tasks agendadas para re‑scoring quando há retraining ou novas features.
• Pipelines de orquestração (Data Factory/Sync-like): sequência de passos com pontos de verificação — ingestão → atribuição → scoring → agregação de métricas → publicação de dashboards.
• Streaming (quando necessário): ingestão de eventos em near real‑time para métricas de click / conversão usando connectors; consolide em micro‑batches para evitar latências excessivas.
• Power BI / Dashboards: relatórios com evolução temporal, comparação por grupo e alerting integrado com Azure Monitor/Teams para rollback automático.

Um fluxo típico implementado no Fabric:

1. Ingestão de eventos (telemetria da aplicação, transacções) para a Lakehouse.
2. Cálculo da unidade experimental (utilizador/conta/sessão) e execução da função de atribuição determinística para obter o grupo (A/B) — persistindo a atribuição com timestamp e versão do experimento.
3. Scoring em batch ou streaming que lê a tabela de atribuições e aplica a versão do modelo apropriada, escrevendo resultados para uma tabela de experiment_results.
4. Consolidação de eventos de negócio e telemetria técnica para calcular métricas agregadas por grupo e período.
5. Publicação de dashboards Power BI com refreshs automáticos e alertas configurados para thresholds críticos.

No desenho da Lakehouse, inclua colunas de metadados: experiment_id, experiment_version, model_version, assignment_hash, assignment_ts, feature_hash. Otimize com Z‑ORDER por id_utilizador para acelerar joins entre atribuições e eventos. Retenha dados de atribuição para auditoria (pelo menos 90 dias ou conforme requisitos regulatórios) e guarde artefactos de modelos (binary, metadata) no catálogo com referência na tabela de experimentos.

Desenho do experimento e métricas chave

Desenho experimental é onde a maior parte dos projectos falha — não por falta de tecnologia, mas por falta de rigor. Comece por documentar a unidade de randomização, hipótese primária, métricas secundárias, critérios de elegibilidade, duração proposta e regras de stopping. Sem isto, corre o risco de analisar depois e cair em viés de múltiplas comparações.

Unidade de randomização: escolha entre utilizador, conta ou sessão. A unidade por utilizador é a mais conservadora (controla aprendizagem e comportamento ao longo do tempo) mas exige amostras maiores; sessão dá sinais mais rápidos mas aumenta risco de contaminação.

Métricas típicas e como as operacionalizar:

• Taxa de conversão (primária) — número de conversões / número de visitas elegíveis.
• Valor médio do carrinho (AOV) — soma do valor transaccionado / número de ordens.
• Receita por utilizador exposto — combinação de taxa de conversão e AOV, útil para comparações directas por 1000 utilizadores expostos.
• Métricas técnicas — latência média, taxa de erros, taxa de fallback (quando o sistema recorre ao modelo anterior).
• Métricas de segurança — falsos positivos/negativos em fraude, impacto em churn, indicadores de confiança do utilizador.

Tamanho da amostra: calcule com base no baseline e no efeito mínimo detectável (MDE). Exemplo prático: se a taxa de conversão actual é 4,0% e pretende detectar um aumento absoluto de 0,4 p.p. (isto é, para 4,4% — um ganho relativo de 10%), com power de 80% e alfa 5%, o cálculo aproximado usando a fórmula para duas proporções dá cerca de 39.500 utilizadores por grupo (≈79k no total). Ou seja, se está a randomizar por sessão em vez de utilizador, conte sessões; se pelo utilizador, conte utilizadores únicos expostos.

Documente também as regras de paragem: por exemplo, não analisar antes do mínimo de 14 dias e do N mínimo por grupo; em análise sequencial use correções (alpha spending) ou um enquadramento Bayesiano com thresholds de probabilidade pré‑especificados para diminuir o risco de paragens prematuras.

Implementação passo a passo

1) Identificar unidade experimental e registos: decida se a unidade é o utilizador (mais conservador) ou a sessão (mais responsivo). Para cenários de retalho e scoring de ofertas, a unidade por conta/cliente é frequentemente a escolha correcta para evitar que o mesmo utilizador receba versões diferentes no mesmo período de compra.

2) Implementar atribuição determinística: gere uma função de hash ou HMAC (ex.: HMAC‑SHA256(id_cliente ∥ experiment_id ∥ salt)) e converta o hash para um inteiro que mapeia para buckets percentuais. Exemplo prático: bucket = int(hex_digest[:8], 16) % 10000 → se bucket < 5000 então grupo A, senão grupo B; assim garante reprodutibilidade mesmo se o serviço for reiniciado. Persista essa atribuição numa tabela na Lakehouse (por exemplo experimental_assignments) com colunas: id_cliente (string), experiment_id (string), grupo (char), assigned_at (timestamp), model_version (string), salt_version (string).

3) Pipeline de scoring: crie um Spark Job que leia experimental_assignments e aplique o modelo correspondente. Estruture a tabela experiment_results com colunas: id_cliente, experiment_id, model_version, score, action_recommended, scored_at. Versione artefactos de modelo (model_v1, model_v2) e guarde o feature_hash para garantir que pode reproduzir scoring exato no futuro.

4) Telemetria e métricas de negócio: instrumente a aplicação para emitir eventos de conversão/ação para uma tabela de eventos (event_type, id_cliente, value, ts). Consolide estas fontes com os resultados de scoring para calcular métricas agregadas por grupo e janela temporal usando jobs schedulados (por exemplo, agregações horárias para dashboards near real‑time).

5) Dashboards e análises: crie relatórios Power BI que mostrem evolução diária das métricas por grupo, estimativas de uplift (diferença absoluta e relativa), intervalos de confiança e tabelas de segmentação. Para grandes experiências configure refresh a cadência horária ou diária consoante o volume — para experimentos com dezenas de milhares de utilizadores, o reporting diário é o mais estável para evitar ruído.

Mini-caso prático: retalho omnicanal

Numa empresa de retalho omnicanal com 80 colaboradores na equipa de analytics e 1,2 milhões de clientes activos, a equipa da bConcepts implementou um A/B test para um novo modelo de recomendação que prioriza margens em vez de mera probabilidade de clique. Hipótese: aumentar o valor médio do carrinho (AOV) sem reduzir a taxa de conversão.

Parâmetros chave do experimento:

• Unidade: cliente (persistente por 30 dias).
• População elegível: 400.000 clientes com activity > 3 compras no último ano.
• Alocação: 50% controlo (modelo actual), 50% tratamento (novo modelo).
• Duração planeada: 28 dias.

Resultados após 28 dias (dados consolidados):

• Taxa de conversão: 4,05% (controlo) vs 3,98% (tratamento) — diferença estatisticamente não significativa (p=0,18). Com 200k clientes em cada grupo, as conversões estimadas foram 8.100 vs 7.960.
• Valor médio do carrinho (AOV) entre conversões: €58,20 (controlo) vs €63,10 (tratamento) — uplift absoluto €4,90, relativo +8,4%, p<0,01.
• Receita por 1000 utilizadores expostos: €2.358 (controlo) vs €2.520 (tratamento) — uplift €162 por 1000 utilizadores.

Interpretação e decisão: apesar de uma pequena redução na taxa de conversão, o aumento do AOV compensou e produziu um ganho de receita material. Traduzindo para escala, se aplicar o modelo a 30% dos 1,2M clientes activos (360k), o uplift esperado por 1000 utilizadores traduz‑se em ~€58k adicionais por mês (360 × €162). A decisão foi um rollout gradual a 30% do tráfego com monitorização apertada de conversão e impacto em segmentos críticos como clientes novos e clientes VIP.

Sem testes controlados está a optimizar para métricas offline; com testes controlados está a optimizar para impacto real no negócio.

Monitorização, análise estatística e rollout

Durante o experimento monitorize métricas primárias, métricas secundárias e métricas técnicas (latência, erros, taxa de fallback). Recomendamos painéis com três vistas: visão global (KPIs por grupo), alerting (thresholds configuráveis) e diagnóstico (segmentações e evoluções por coortes).

Para análise estatística, calcule diferenças pontuais com intervalos de confiança. O bootstrap é particularmente útil quando as distribuições são assimétricas (por exemplo AOV com cauda longa). Abordagens práticas:

• Análise frequentista clássica para a hipótese primária com p‑values e ICs — boa para decisões binárias pré‑especificadas.
• Análise Bayesiana para actualizações contínuas de probabilidade de uplift — útil quando precisa de uma interpretação probabilística (ex.: 92% de probabilidade de que o tratamento aumente a receita).
• Correções para testes sequenciais: se pretende olhar frequentemente aos dados, use métodos de spending alpha (O'Brien‑Fleming, Pocock) ou um enquadramento Bayesiano para evitar inflar a taxa de falso positivo.

Rollout controlado: não promova imediatamente para 100% dos utilizadores. Estratégia típica: canary 10% → 30% → 60% → 100% com períodos de observação entre passos (ex.: mínimo 7 dias e N mínimo por grupo). Configure rollback automático se métricas de segurança ultrapassarem thresholds (ex.: queda na taxa de conversão >0,5 p.p. ou aumento de latência média >200 ms). Integre alertas com Teams/Slack e pipelines de orquestração para executar ações de rollback se necessário.

Riscos, mitigação e operações

Riscos comuns incluem contaminação de grupos (utilizadores expostos a múltiplas versões), eventos externos que afectam comportamento (campanhas de marketing, sazonalidade) e problemas de infra‑estrutura. Mitigações práticas:

• Atribuições persistentes e idempotentes — nunca reatribuir um utilizador durante o período do experimento.
• Registar eventos externos (promoções, campanhas) como covariáveis para controlar na análise ou estratificar amostras.
• Testes de integração da infra‑estrutura — validação automática de latência e taxa de erros antes de aumentar o tráfego.

Operacionalmente, defina responsabilidades claras: Experiment Owner (product/PO), Data Engineer (criação e encerramento de experimentos), Analista Estatístico (validação e reporte) e Engenheiro de Produção (rollback/monitorização). Institua um catálogo de experimentos na Lakehouse com metadados: experiment_id, objectivo, hipótese, start/end, owner, model_version, salt_version, estado (draft/running/closed) — isto facilita auditorias e reprodutibilidade.

Em resumo

• Defina unidade, hipótese e métricas antes de qualquer código: experimento mal definido gera decisões erradas.
• Implemente atribuição persistente na Lakehouse e versionamento explícito do modelo no Fabric para auditabilidade.
• Calcule amostras e regras de stopping; use análises frequentistas e/ou Bayesiana conforme necessidade operativa.
• Automatize scoring e colheita de métricas com Spark Jobs e alimente dashboards Power BI para monitorização contínua.
• Planeie rollout gradual com thresholds de rollback e responsabilidades claras na equipa.

Conclusão — próximos passos: comece por um piloto com um experimento de baixo risco (por exemplo, diferenças na priorização de ofertas), documente todo o processo na Lakehouse e construa um dashboard de monitorização que combine métricas de negócio e telemetria técnica. Se já usa Microsoft Fabric, revise como são persistidas as atribuições e versões de modelo: pequenas melhorias aqui reduzem muito o risco de regressão. Um piloto com 50k utilizadores por grupo pode ser suficiente para detectar mudanças económicas relevantes em muitos contextos — e fornece a experiência operacional para escalar a governação experimental na organização.

Pronto para transformar modelos prometedores em ganhos mensuráveis? Que experimento controlado poderia a sua organização lançar nas próximas 8 semanas?