Laboratório de Coinovação da Microsoft: prototipagem rápida no SoTA da IA

No ano passado, a velocidade vertiginosa do avanço da IA nos forçou a aceitar uma realidade um tanto desconfortável: a solução técnica que consideramos ideal hoje provavelmente será descontinuada em seis meses. Na Marvik, trabalhamos com a Microsoft no Laboratório de Coinovação no Uruguai desde 2023, desenvolvendo protótipos rápidos para projetos em uma ampla variedade de setores, da agricultura à saúde. Com o tempo, deixamos de projetar arquiteturas modulares complexas e passamos a ver como novas ferramentas, modelos e plataformas integrados simplificam as soluções em um piscar de olhos. Essa dinâmica exige não apenas agilidade técnica, mas uma mudança fundamental na mentalidade..

No Microsoft Co-Innovation Lab, nossa dinâmica se baseia na experimentação constante. Nosso objetivo é acelerar o desenvolvimento de produtos de IA, com foco nos estágios iniciais críticos da modelagem de soluções. Essa posição nos concede uma perspectiva privilegiada e às vezes estonteante de como os avanços tecnológicos podem mudar completamente a forma como abordamos um problema.

Neste blog, analisamos três casos de uso que abordamos em diferentes estágios no ano passado. Exploraremos como as soluções que inicialmente exigiam arquiteturas complexas foram redesenhadas meses depois usando ferramentas, modelos ou plataformas de última geração. Além da mudança técnica, compartilhamos nossa avaliação do equilíbrio entre eficiência, controle e custo.

Por que isso é importante?

Documentar essa evolução não é apenas um exercício de nostalgia técnica; é uma necessidade estratégica por três razões:

1. Gerenciamento de expectativas: Compreender que a solução mais recente nem sempre é a mais robusta para um ambiente de produção.
2. Arquiteturas com data de validade: Aceitar que o design que implementamos hoje, por mais otimizado que seja, pode se tornar obsoleto em meses. Isso força uma mudança em nossa abordagem: projetar soluções flexíveis que podem ser substituídas por ferramentas mais eficientes sem quebrar todo o ecossistema.‍
3. Redefinindo funções: Adaptar as capacidades da nossa equipe a um mundo em que o design da solução tem mais peso do que escrever código.

Estudo de caso 1: contraste automatizado de documentos

Uma empresa farmacêutica precisou comparar dois documentos para cada medicamento lançado: um PDF com o design do rótulo impresso, incluindo instruções de layout e formatação, e um arquivo do Word com as informações médicas oficiais que deveriam aparecer nele. Qualquer discrepância entre os dois era um risco regulatório. O processo foi feito inteiramente à mão.

O desafio não era apenas a comparação em si. O PDF era um arquivo de design visual, não um texto simples, o que significava que o conteúdo poderia aparecer em uma ordem diferente do documento do Word. Antes que qualquer comparação pudesse acontecer, os dois arquivos precisavam ser extraídos, normalizados e tornados compatíveis.

Construímos um gasoduto modular. O Azure Document Intelligence gerenciou a extração de ambos os arquivos, convertendo o PDF em conteúdo estruturado que pode ser comparado com o texto normalizado do Word. Em seguida, dividimos os dois documentos semanticamente e os indexamos com o Azure AI Search, o que nos permite recuperar somente as seções mais relevantes antes de enviá-las a um modelo de idioma para comparação. Isso reduziu o risco de erros em cadeia causados por fragmentação automática ou leituras incorretas de PDF..

O resultado foi uma lista estruturada de discrepâncias, cada uma mapeada de volta à sua localização exata no PDF original com as coordenadas da caixa delimitadora, para que a equipe regulatória pudesse ver as seções sinalizadas destacadas diretamente no design da etiqueta. O oleoduto funcionou bem. Também exigiu a orquestração de vários serviços e uma quantidade significativa de código personalizado.

O Azure Content Understanding chegou prometendo reunir grande parte disso em um único serviço integrado. Nós o testamos. Ele lidou bem com alguns casos, mas introduziu erros em outros que o pipeline modular detectou de forma confiável. Para um contexto regulatório, em que uma discrepância perdida não é apenas um bug, mas uma falha de conformidade, isso não era uma troca que pudéssemos aceitar.

Este caso não terminou com a mudança para a ferramenta mais simples. Acabou com a gente ficando no complexo, e esse é o ponto. A promessa de soluções integradas é real, mas nem todo problema pode se dar ao luxo de trocar precisão por conveniência. Quando o custo de um erro perdido é alto o suficiente, a visibilidade que um pipeline modular oferece, a capacidade de inspecionar texto extraído, fragmentos recuperados e modelar saídas como artefatos separados, não é sobrecarga. É o produto.

A compreensão do conteúdo ainda está em versão prévia. Vamos revisitá-lo.

Estudo de caso 2: Agentes de conversação por voz

Sem dúvida, os agentes de bate-papo explodiram em popularidade durante o segundo semestre de 2025. Naturalmente, a próxima etapa foi o agente de voz conversacional. No laboratório, abordamos nosso primeiro caso de agente conversacional em agosto de 2025. O objetivo do cliente era criar um agente capaz de entrevistar um usuário por telefone, reunindo dados para avaliar se ele era um potencial candidato a crédito.

O contexto de 2025

Quando abordamos esse caso, decidimos testar dois métodos diferentes: o primeiro e mais inovador usou a solução STS (Speech-to-Speech) do Azure por meio da API Voice Live; a segunda abordagem, mais clássica, usou um pipeline modular de STT → Reasoning LLM → TTS usando os Serviços de Fala do Azure.

A primeira abordagem prometia uma solução mais simples e uma implantação mais rápida, pois requer apenas algumas linhas de código para configurar uma sessão e fazer uma chamada para a API. No entanto, à medida que avançamos com a Prova de Conceito (PoC), percebemos rapidamente que a alta latência e a voz robótica do agente resultavam em uma experiência ruim para o usuário, a ponto de não conseguirmos manter uma conversa sem silêncios constrangedores entre os interlocutores ou mesmo durante a fala do agente. Do ponto de vista do desenvolvimento, o design da caixa preta da API tornou extremamente difícil rastrear onde estava o gargalo, pois não tínhamos acesso ao processo subjacente. Em nossa opinião, o produto ainda não estava em um estado em que pudesse ser escalado ou considerado confiável para produção.

Por isso, decidimos retornar ao design mais tradicional, dividindo a tarefa em seus blocos fundamentais, que são mostrados no diagrama a seguir.

Isso nos deu mais controle sobre latência, detalhes de desempenho e custos gerais da solução. Finalmente, conseguimos identificar que a alta latência na conversa não foi causada pelo modelo de transcrição que, na verdade, era muito preciso, mas estava enraizado no modelo de síntese.

Outra vantagem desse design é que os custos são transparentes e fáceis de projetar. Por exemplo, o modelo de transcrição custa USD USD por hora de áudio, enquanto o modelo de síntese de voz custa USD 15 por milhão de caracteres sintetizados. Em uma conversa padrão de uma hora entre duas pessoas, podemos calcular diretamente os custos desses blocos específicos:

• Entrada de áudio (transcrição): 1 hora = $1 USD
• Saída de áudio (síntese): 1 hora ≈ $0.15 USD

O salto para janeiro de 2026

Em janeiro de 2026, encontramos outro cliente com um caso de uso semelhante: um agente de conversação criado para entrevistar clientes por telefone e coletar seus dados para posteriormente preencher uma declaração juramentada. Dessa vez, enfrentamos um desafio extra: o agente precisava de uma ferramenta para atualizar dinamicamente o registro de um cliente à medida que a conversa progredia. Isso exigiu mais tempo de processamento entre as interações, o que naturalmente ameaçava aumentar a latência. Decidimos dar outra chance aos agentes de voz em tempo real do Azure e, para nossa surpresa, a melhoria na experiência do usuário foi notável.

A velocidade de resposta do agente garantiu uma interação fluida, mesmo quando a ferramenta estava ocupada atualizando os registros de dados. Além disso, o modelo de síntese ofereceu um tom muito mais natural, sem interrupções no diálogo do agente.

Em apenas alguns meses, a API Voice-Live do Azure conseguiu melhorar significativamente os resultados que pudemos alcançar, mantendo sua simplicidade de implementação característica. Como podemos ver no diagrama a seguir, a solução completa permaneceu um único componente.

No entanto, essa simplicidade tem o custo da visibilidade. Isso torna a depuração de erros ou a otimização de partes específicas do pipeline complicadas, se não impossíveis. Por exemplo, a API Voice Live oferece uma seleção limitada de modelos de transcrição, o que se torna um obstáculo significativo ao lidar com sotaques incomuns ou expressões locais.

Outra grande desvantagem é que os custos de uso são muito menos transparentes, dificultando a projeção do custo de escalabilidade até a produção. Diferentemente dos modelos autônomos de transcrição ou síntese, a API Voice Live tem um preço por milhão de tokens, mas não especifica a divisão entre a entrada, a saída ou os tokens de raciocínio do modelo. Em essência, o cálculo do custo real do produto continua sendo uma “área cinzenta” até chegarmos à fase de teste com um pequeno grupo de usuários. Como referência, o custo total de 4 horas de teste foi inferior a $5 USD. Embora isso forneça uma linha de base útil para a ordem de custo, é importante lembrar que o preço do PoC raramente se traduz linearmente em produção, em que a escala e os casos extremos podem alterar rapidamente os números.

Esse caso ilustra perfeitamente uma tensão recorrente que enfrentamos ao projetar uma solução: a escolha entre o rápido desenvolvimento de uma “caixa preta” integrada e o controle granular de uma tubulação personalizada. Embora a atualização de janeiro de 2026 prove que os serviços gerenciados eventualmente recuperam a qualidade, ela também serve como um lembrete de que se mover mais rápido geralmente significa sacrificar a capacidade de dar uma olhada nos bastidores. À medida que avançamos, nosso desafio não é mais apenas criar a tecnologia, mas decidir estrategicamente quanto controle estamos dispostos a negociar por uma questão de simplicidade.

Estudo de caso 3: Classificação de imagens

Contexto de fevereiro de 2025

A classificação de imagens é um problema clássico que enfrentamos em várias ocasiões no laboratório e tradicionalmente o abordamos ajustando modelos de visão. Uma de nossas histórias de sucesso envolveu uma empresa uruguaia dedicada a supervisionar e promover a indústria de carnes do país. O objetivo final era desenvolver uma solução para classificar os cortes de carne como “de boa qualidade” ou “de má qualidade”. A empresa forneceu um conjunto de dados de aproximadamente 2.500 imagens de matambre (carne de rosa) corta com seus rótulos correspondentes. Essas imagens eram muito consistentes em termos de iluminação, fundo e qualidade, mas um detalhe significativo era o substancial desequilíbrio de classes, já que cortes de “boa qualidade” representavam apenas cerca de 25% do total de imagens.

Com isso em mente, decidimos ajustar um modelo YOLO11, que naturalmente exigiu um esforço concentrado no pré-processamento de imagens para lidar com a baixa variabilidade do conjunto de dados e o desequilíbrio de classes. Também envolveu um custo associado à potência computacional necessária para treinar o modelo, que nesse caso era uma Máquina Virtual Azure equipada com uma GPU. Apresentamos o diagrama dessa solução na figura a seguir.

No geral, o processo desde o trabalho inicial de dados até a implantação de um modelo treinado levou uma semana e obtivemos resultados muito satisfatórios, atingindo 95% de precisão.

O salto para outubro de 2025

Vários meses depois, encontramos um caso de outra empresa uruguaia, desta vez especializada na manutenção de sistemas de supressão de incêndio para cozinhas profissionais. Uma parte fundamental do processo de manutenção envolveu técnicos tirando fotos de três componentes específicos: o nível de um agente líquido verde dentro de um tanque, a posição do medidor e o peso do tanque medido em uma balança analógica. Essas fotos serviram como registro oficial para determinar se uma cozinha estava liberada para operação.

Para o primeiro componente, o nível do líquido, o critério era simples: o sistema era “adequado” se o líquido verde estivesse visível pela janela de inspeção do tanque. Para o segundo, a posição da agulha do medidor indicava se o sistema de supressão de incêndio havia sido ativado (tornando-o “impróprio”). Finalmente, para o terceiro componente, o peso mostrado na balança analógica tinha que estar dentro de uma faixa numérica específica.

O cliente procurou o laboratório procurando desenvolver um modelo de classificação para cada um desses três componentes. Eles forneceram um conjunto de dados de mais de duas mil imagens por caso, mas havia um problema: eles estavam completamente sem rótulo. Além disso, como as fotos foram tiradas por técnicos usando telefones celulares em várias cozinhas, as imagens sofreram com a alta variabilidade na iluminação, posicionamento dos objetos e qualidade geral.

Essas condições nos levaram à pergunta: Treinar um modelo de visão é a melhor opção para esse caso? Em vez disso, decidimos testar a inferência usando um dos modelos multimodais oferecidos pelo Azure. Começamos com o então novíssimo GPT 5.1 para classificar o nível do líquido, assumindo que seria uma tarefa simples. Rotulamos manualmente um pequeno conjunto de teste de 10 imagens diversas e, como esperado, não foi um desafio para o modelo, pois alcançamos 100% de precisão. Repetimos o processo com 10 fotos dos medidores e, com um prompt bem elaborado, atingimos novamente 100% de precisão. E a melhor parte, esse PoC foi desenvolvido em uma sessão de duas horas. Aqui está um diagrama da solução final.

A história foi bem diferente com a escala. Embora um humano pudesse ler facilmente as medições com precisão, o modelo não conseguiu fornecer a precisão que o problema exigia. Essa é uma limitação bem documentada dos modelos multimodais, principalmente devido às restrições de resolução espacial causadas pela tokenização de imagens. Por mais refinado que fosse o prompt, esse problema específico não poderia ser resolvido com a mesma simplicidade dos dois anteriores.

Esse caso nos levou a ver um problema clássico e geralmente “resolvido” através de uma nova lente. Embora a classificação de imagens usando um modelo multimodal tenha um custo por inferência que pode exceder o de um modelo personalizado ajustado, ela reduz significativamente o tempo e o esforço gastos na preparação, rotulagem e treinamento de dados e resolve o problema de generalização que tendemos a ter ao treinar modelos de visão com baixa variação nas amostras.

No entanto, os modelos multimodais não são uma “solução mágica” para todos os casos de uso, pelo menos ainda não. O trade-off entre o velocidade de implantação e o precisão de modelos especializados continua sendo um ponto crítico de decisão. Em cenários com alta precisão espacial, a abordagem tradicional de construir um pipeline de visão dedicado ainda se mantém firme.

A compensação da opacidade

Um padrão percorre todos os três casos. Toda vez que adotamos uma solução integrada de ponta a ponta, ganhamos velocidade e perdemos visibilidade. Vale a pena examinar essa compensação em seus próprios termos, porque ela afeta não apenas a forma como construímos, mas também como depuramos, auditamos e mantemos.

Em uma tubulação modular, a falha é isolável. Quando o agente de voz baseado em STT → LLM → TTS produzia alta latência, pudemos rastrear o gargalo até um bloco específico. Quando o pipeline de contraste do documento perdia uma discrepância, podíamos inspecionar o texto extraído, os fragmentos recuperados e a saída de comparação do modelo como artefatos separados. A arquitetura em si possibilita o diagnóstico.

Soluções integradas derrubam essa estrutura. Com a API Voice Live, uma resposta degradada pode vir da qualidade da transcrição, do raciocínio, da síntese ou das condições da rede, e a superfície da API não oferece nenhuma maneira de distingui-las. Com a compreensão do conteúdo aplicada ao contraste do documento, uma discrepância perdida deixa a mesma questão sem solução em aberto: foi a extração, a recuperação ou a etapa de comparação do modelo?

Isso não é um argumento contra soluções integradas. O caso do agente de voz de janeiro de 2026 provou que os serviços gerenciados podem alcançar a qualidade de produção com simplicidade genuína. O caso de contraste de documentos com o Content Understanding foi criado em horas em vez de dias, mesmo na pré-visualização. À medida que essas ferramentas continuam melhorando, a decisão raramente será sobre a capacidade. Será sobre se a opacidade que vem com a simplicidade é aceitável para esse problema específico.

Nossa opinião

A maior mudança na forma como trabalhamos não está nas ferramentas. Está nas perguntas que fazemos antes de escolher uma.

Um novo modelo ou integração não é inerentemente melhor porque é a versão mais recente. A arquitetura certa depende do problema: quanto custa uma falha, quanta visibilidade a produção exige, com que rapidez a solução precisa ser enviada e se a versão simplificada amadureceu o suficiente para ser confiável.

O que esses três casos compartilham é que nenhum deles teve uma resposta permanente. O fluxo de documentos farmacêuticos permaneceu modular porque a precisão não era negociável. O agente de voz migrou para uma solução integrada porque a qualidade realmente havia melhorado. O classificador de imagens acabou dividindo o problema em dois, com abordagens diferentes para componentes diferentes.

Como resultado, nosso papel mudou. Não somos mais desenvolvedores principais de soluções analíticas. Passamos mais tempo na modelagem de soluções e no pensamento crítico do que na criação de código. A questão central não é mais “como podemos construir isso?” mas “o que esse problema realmente precisa e o que está disponível hoje para resolvê-lo?”

Essa mudança de pensamento também muda a forma como projetamos. Em um ambiente em que um novo modelo ou integração relevante pode aparecer a cada poucos meses, o objetivo não é construir a solução mais sofisticada, mas a mais substituível. Isso significa definir limites claros entre os componentes, manter a lógica de negócios dissociada de modelos ou fornecedores específicos e tratar solicitações e configurações como artefatos versionados em vez de cadeias de caracteres incorporadas. Não porque esperamos reconstruir constantemente, mas porque o custo da mudança deve ser uma escolha deliberada, não um acidente de como algo foi conectado.

A decisão entre modular e integrado não é tomada uma vez no início de um projeto. Ele é revisitado à medida que as ferramentas amadurecem, a qualidade se recupera e o custo da opacidade se torna mais claro. Não há uma resposta permanente. Projete a solução de que você precisa agora, com clareza suficiente em sua estrutura para que você possa substituir qualquer parte dela quando algo melhor chegar. Será.

‍

Se você quiser explorar as ferramentas e abordagens que discutimos, esses são bons pontos de partida:

• API Voice Live para agentes de voz em tempo real
• Classificação de imagens no Azure
• Crie projetos personalizados do Document Intelligence Studio