Como a Databricks disponibiliza modelos de fronteira para 12.000 funcionários no Dia 1

Oferecer aos nossos funcionários acesso a recursos de IA de ponta é uma prioridade máxima na Databricks e, consequentemente, é importante para nós que eles usem novos modelos instantaneamente assim que estiverem disponíveis. Ao mesmo tempo, não é uma tarefa simples dar acesso rápido a um novo modelo para mais de 12.000 pessoas porque:

1. Modelos comercializados como de ponta geralmente não são. Por exemplo, o Opus 5.0 era mais caro e teve uma classificação inferior em pontuações de qualidade quantitativas e qualitativas entre nossos engenheiros em comparação com o Opus 4.8. Migrar para um modelo que retrocede em relação à fronteira pode prejudicar significativamente uma empresa, em vez de ajudá-la. Em nossa experiência, é necessário muito cuidado ao avaliar modelos antes de migrar cargas de trabalho em massa para novos modelos.
2. O uso ingênuo de um novo modelo pode fazer os custos explodirem. Quando lançamos o GPT Astra para um grupo de controle sem mitigações de custo associadas, o desenvolvedor médio gastou 60% a mais do que antes de obter acesso ao Astra. Um aumento repentino de 60% nos custos de um dia para o outro com uma população de usuários de mais de 10.000 é algo muito difícil de planejar para uma empresa. Assim que entendemos melhor em quais tarefas o Astra é excepcionalmente bom, conseguimos direcionar o uso para reduzir substancialmente os custos gerais.

Este post discute um conjunto de técnicas que empregamos para dar à maioria dos funcionários da Databricks acesso no "Dia 1" a novos modelos, permitindo-nos avaliar se os modelos são de fato boas soluções robustas de longo prazo. Essas técnicas dependem muito do Unity Gateway para lançar, avaliar e incorporar novos modelos de forma adaptativa. A semana de 21 de setembro foi um teste crítico dessas capacidades quando o Opus 5, o GPT-6 Sol e o GPT-Luna foram lançados em rápida sucessão. Durante a semana, a Databricks ofereceu a todos os funcionários acesso no Dia 1 e, no Dia 3, já tínhamos coletado dados suficientes para confirmar que esses modelos estavam na fronteira de eficiência, levando à sua incorporação em nossa infraestrutura mais ampla.

O ciclo de vida de lançamento de modelos

 Em linhas gerais, os lançamentos de novos modelos na Databricks passam por um pipeline que funciona da seguinte forma:

1. Disponibilizar imediatamente novos modelos para todos os funcionários, em caráter "experimental".
2. Limitar o uso de novos modelos com base em um orçamento por usuário.
3. Após coletar dados suficientes, decidir se o modelo deve ser promovido para produção (ou até mesmo torná-lo o padrão).

Etapa 1: Disponibilizar novos modelos imediatamente

Para facilitar o gerenciamento de modelos entre provedores de modelos abertos e fechados, aproveitamos nosso próprio Databricks Unity Gateway para todo o uso interno. Este é o nosso hub central para governança de IA, gerenciamento de custos e observabilidade, então é natural que comecemos por aqui.

O Gateway é onde permitimos que todos os funcionários acessem o modelo recém-lançado. No entanto, a configuração do lado do servidor não é suficiente. Nossos funcionários usam o Claude Code, o Codex e o meta-harness Omnigent em seus notebooks, e precisamos distribuir a nova configuração do modelo para eles.

É aí que entra a Unity Gateway CLI (UG CLI). A UG CLI já está rodando no notebook de todos, implantada por meio do nosso gerenciamento de dispositivos móveis. Sempre que alguém inicia o Claude Code, o Codex ou o Omnigent, a UG CLI é executada para verificar novos modelos, ferramentas e habilidades, e atualiza a configuração do harness local. A UG também nos permite designar centralmente modelos padrão versus experimentais, preparar modelos para roteamento inteligente e coletar traces para avaliar a implementação de cada modelo.

Configuramos o Unity Gateway para enviar configurações experimentais para o Opus 5.5 e o Sol 6. Esses modelos agora aparecem com essa tag, para que os funcionários possam selecioná-los, mas entendam que se trata de um novo modelo que pode ou não ser o melhor da categoria ou permanecer disponível para sempre:

A saída do modelo/Claude Code designa claramente o Opus 5.5 como Experimental

Etapa 2: Limitar o uso usando um orçamento por usuário

Já escrevemos anteriormente sobre como configuramos orçamentos por usuário para gastos com IA. Desde então, expandimos nossa arquitetura de orçamento total para incluir quatro orçamentos principais, cada um definido por usuário:

1. Máximo mensal: cada usuário tem um limite geral de gastos mensais em todos os modelos.
2. Limite diário de execução descontrolada: cada usuário tem um limite diário máximo, que pode ser aumentado diretamente no Slack para evitar gastos acidentais decorrentes de uma sessão descontrolada.
3. [Novo!] Orçamento de fronteira de qualidade: alocamos uma certa fração do orçamento mensal para os modelos mais premium na fronteira de qualidade, como o GPT Astra e o Claude Fable. (O Fable não está implementado internamente no momento devido às políticas de retenção de dados da Anthropic, mas estamos trabalhando em estreita colaboração para implementar a nova política deles.) Isso reflete a intenção de que esses modelos não devem ser usados no dia a dia, mas sim selecionados para tarefas especializadas nas quais são exclusivamente adequados, para justificar o aumento de custo de 2 a 3 vezes em relação ao próximo nível de qualidade.
4. [Novo!] Orçamento experimental: outra fração do orçamento mensal é alocada para o uso de modelos novos e não testados. Aqui, nosso objetivo é equilibrar a velocidade de adoção com o risco de expor amplamente um modelo que não está na fronteira de eficiência.

No primeiro dia do lançamento do modelo, disponibilizamos o Opus 5.5 e o Sol 6 para todos os funcionários via Unity Gateway e os marcamos para o orçamento experimental. Em seguida, usamos os dias seguintes para coletar dados e decidir o que fazer a seguir: remover a tag experimental ou remover o modelo do catálogo de modelos que nossos desenvolvedores visualizam.

Visão geral da configuração do orçamento, refletindo os quatro orçamentos

Etapa 3: Promover ou descartar o modelo

Para determinar se o modelo está na fronteira de eficiência, contamos com três sinais:

1. Dados de benchmark: temos um conjunto de benchmarks privados que testam uma série de tarefas, incluindo benchmarks offline, como raciocínio de documentos, busca no espaço de trabalho e nosso próprio produto Genie, bem como benchmarks online nos quais executamos dois modelos lado a lado e comparamos os resultados para a criação de pull requests. Continuamos a expandir e ajustar esses benchmarks; em um mundo ideal, nossos benchmarks são suficientes para determinar rapidamente o custo e a qualidade de qualquer lançamento de novo modelo.
    
2. Qualidade relatada pelo usuário: o lançamento do modelo experimental fornece uma riqueza de dados anedóticos sobre como as pessoas se sentem em relação ao novo modelo. Percebemos que um grupo de usuários avançados está ansioso para testar novos modelos e comparar suas experiências no Slack e em respostas de pesquisas.
    
3. Rastreamento de custos via traces do OpenTelemetry: o Unity Gateway registra todos os traces em um local central, junto com as informações de custo. Podemos comparar como os usuários-piloto gastaram dinheiro na geração anterior de modelos em relação aos modelos mais recentes por sessão.  Isso não nos diz necessariamente a qualidade, mas nos dá uma boa medida do custo.

Para o Opus 5.5 e o Sol 6, todas as três métricas nos mostram uma história bastante consistente.

Benchmarks, como o nosso OfficeQA Pro V2, mostram que o Opus 5.5 está claramente na fronteira de custo/qualidade, um grande avanço em ambos os eixos em relação ao Opus 5. O GPT-6 Sol pontua em algum lugar entre o GPT-5.6 Sol e o GPT-5.6 Terra em custo e qualidade.

Relatórios de usuários concordam amplamente que, para tarefas de engenharia e depuração (a grande maioria dos nossos primeiros usuários são engenheiros), o Opus 5.5 é um grande avanço em qualidade em relação ao Opus 5 e ao Opus 4.8, e seu estilo de escrita é amplamente preferido. Por outro lado, o GPT-6 Sol é ocasionalmente um retrocesso em qualidade em comparação com o GPT-5.6 Sol.

O acompanhamento de custos nos permitiu comparar o uso dos primeiros usuários com o uso do mesmo grupo uma semana antes. Manter a mesma coorte provou ser crucial porque os primeiros usuários tendem a ser usuários avançados de AI, em vez de usuários comuns.

Queríamos normalizar os custos em uma base de $/sessão, já que os usuários que estão testando um novo modelo às vezes aumentam seu uso em termos de número de sessões à medida que experimentam. Descobrimos que usar uma comparação básica de $/sessão ainda era enganoso porque a distribuição das sessões também estava mudando: os primeiros usuários estavam tentando resolver problemas mais difíceis com os novos modelos do que em sua sessão média.

Como resultado, estratificamos as sessões com base em se eram de turno único ou de múltiplos turnos e se faziam edições de arquivos, e então reponderamos a distribuição de acordo. A tabela abaixo mostra os resultados para Opus 5.5 vs. Opus 4.8 e GPT-6 Sol vs. GPT-5.6 Sol.

Os números do GPT não são muito surpreendentes, dado que o preço foi reduzido em 50%. Mas ficamos satisfeitos que o Opus 5.5 também representa uma redução significativa de preço para nossas cargas de trabalho reais, considerando nossa experiência anterior com o Opus 5.

O que decidimos

Conseguimos oferecer aos funcionários acesso experimental ao Opus 5 e ao GPT-6 Sol e Luna no primeiro dia de lançamento do modelo. Em três dias, coletamos dados suficientes para confirmar que esses modelos estavam na fronteira de eficiência e decidimos tirá-los do orçamento experimental e colocá-los em circulação padrão como modelos em disponibilidade geral.

Na próxima semana, daremos um passo adiante com o Opus 5.5 para torná-lo o padrão para o Claude Code, dada a sua posição clara de maior qualidade e menor custo do que seus predecessores.

Nossa experiência com o GPT-6 Sol sugere que ele não substituirá o GPT-5.6 Sol como o padrão para o Codex. No entanto, incluiremos o GPT-6 Sol no kit de ferramentas do nosso roteador inteligente, dada a sua vantagem de custo em relação ao 5.6 Sol. 

No geral, achamos essa abordagem eficaz para avaliar rapidamente a qualidade e o custo do modelo, permitindo-nos adotar rapidamente os modelos mais recentes que provam seu valor. Essa flexibilidade importa agora mais do que nunca, com novos modelos surgindo quase diariamente.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original