Protótipo da Databricks Vai para Produção, mas Alto QPS Ainda Exige Planejamento

A Databricks transformou sua lacuna entre protótipo e produção em uma única configuração, permitindo que endpoints padrão do AI Search atendam a milhares de consultas por segundo. O novo recurso de alto QPS tornou-se disponível de forma geral em 28 de julho de 2026. Ele muda a maneira como as equipes podem promover um protótipo da Databricks sem reconstruir a infraestrutura de busca em torno do índice original.

Essa promessa traz uma qualificação importante. As equipes ainda escolhem a meta, se preparam para picos de tráfego, testam a qualidade da recuperação e monitoram a latência. A Databricks provisiona capacidade, mas não elimina as decisões de engenharia que definem uma experiência de busca confiável.

A mudança também coloca a Databricks em uma concorrência mais direta com plataformas de busca dedicadas e serviços de vetores gerenciados em nuvem. O Google já promove o Vertex AI Vector Search para cargas de trabalho grandes e de baixa latência. Bancos de dados especializados também competem em throughput, filtragem e simplicidade operacional.

A Databricks aposta que a continuidade da plataforma importa mais. Os mesmos dados governados, índice e fluxo de sincronização podem permanecer no lugar à medida que o tráfego aumenta. Isso pode encurtar o trabalho de implantação para equipes que já desenvolvem em seu ambiente lakehouse.

Não se trata apenas de um anúncio de busca mais rápida. É uma tentativa de fazer com que uma infraestrutura de dados empresariais governada atenda aplicações interativas sem uma pilha de recuperação separada. O verdadeiro teste começa quando essas aplicações enfrentam tráfego de produção imprevisível.

O Protótipo da Databricks Agora Tem uma Configuração de Produção

A Databricks reduziu um exercício complexo de capacidade a uma meta declarada de QPS, mantendo o índice existente e o modelo de governança.

QPS significa consultas por segundo, o número de solicitações de busca que um endpoint processa durante um segundo. Essa medida se torna crítica quando cada visualização de página, tecla digitada ou painel de recomendações gera uma solicitação.

A Databricks afirma que um endpoint padrão do AI Search agora pode escalar para milhares de QPS. Um desenvolvedor define target_qps ao criar um endpoint ou atualiza um endpoint existente pela interface, SDK ou API REST.

O serviço então calcula e provisiona a infraestrutura necessária. Segundo o anúncio de alto QPS da empresa, os desenvolvedores não gerenciam contagens de réplicas, tamanhos de nós ou um balanceador de carga externo.

Essa é a mudança central. Antes desse lançamento, um protótipo bem-sucedido da Databricks podia apresentar um novo problema quando mais usuários chegavam. A experiência de busca funcionava, mas a arquitetura de atendimento exigia planejamento adicional de capacidade e distribuição de tráfego.

Algumas equipes lidaram com essa transição criando endpoints duplicados. Outras adicionaram roteamento no lado do cliente ou construíram uma camada de atendimento separada. Essas soluções alternativas aumentaram o trabalho operacional e introduziram mais pontos nos quais as configurações poderiam divergir.

A nova configuração mira exatamente essa fronteira. Ela permite que um endpoint padrão existente receba capacidade adicional quando seu índice for criado ou sincronizado pela próxima vez. A governança do Unity Catalog e o Delta Sync permanecem como parte da implantação.

O Unity Catalog é a camada de governança da Databricks para dados e ativos de IA. O Delta Sync mantém um índice do AI Search alinhado à sua tabela de origem. Preservar ambos importa porque a migração frequentemente cria um segundo problema de governança ao lado do problema de desempenho.

O endpoint também expõe o progresso do escalonamento por meio de seu campo scaling_info. Uma equipe pode ver o estado passar de SCALING_CHANGE_IN_PROGRESS para SCALING_CHANGE_APPLIED.

A Databricks adicionou visibilidade no nível do endpoint sobre taxa de solicitações, latência e integridade. Esses sinais estão disponíveis na interface do AI Search e ajudam operadores a comparar a capacidade planejada com o comportamento real.

O anúncio abrange endpoints padrão e está disponível de forma geral sem um processo de adesão. As equipes podem aplicar uma meta a um novo endpoint ou atualizar um que já atende uma aplicação.

Isso torna a história do protótipo da Databricks incomumente direta. Um varejista pode desenvolver descoberta de produtos com base em dados de catálogo governados e, depois, aumentar a capacidade de atendimento sem copiar esse catálogo para outro sistema de busca.

Um serviço de streaming poderia seguir o mesmo caminho para recomendações de conteúdo. Uma aplicação empresarial poderia usá-lo para correspondência de entidades, na qual cada registro de entrada precisa ser comparado com um catálogo existente.

A mudança não transforma um experimento em notebook em uma aplicação de consumo concluída. Ela remove uma transição de infraestrutura que frequentemente aparece entre o experimento e essa aplicação.

Portanto, a Databricks vende continuidade, não apenas velocidade. O endpoint que respondeu a consultas de teste pode continuar sendo o endpoint por trás do tráfego de produção. O valor cresce quando governança, sincronização e atendimento, de outra forma, pertenceriam a sistemas diferentes.

Essa continuidade também eleva as expectativas. Quando o escalonamento de infraestrutura se torna uma configuração, as equipes de aplicação perdem uma explicação fácil para buscas lentas ou pouco confiáveis. O design das consultas e os testes de carga passam a ocupar uma posição mais central.

Alto QPS Coloca a Busca no Caminho da Receita

O recurso importa porque o tráfego de busca interativa é irregular, voltado ao usuário e frequentemente ligado diretamente a uma transação ou recomendação.

Uma consulta analítica convencional às vezes pode esperar. Uma caixa de busca de produtos não. Os usuários percebem resultados de preenchimento automático atrasados, recomendações incompletas e páginas que travam enquanto a recuperação é concluída.

A busca com preenchimento automático cria uma pressão incomum porque uma ação do usuário produz várias solicitações. Cada novo caractere pode disparar outra consulta, a menos que a aplicação aplique debounce ou agrupe a entrada.

Sistemas de recomendação criam um padrão semelhante. Uma página inicial pode solicitar vários conjuntos de resultados personalizados durante uma única visita. O tráfego se concentra em torno de lançamentos, promoções, eventos ao vivo e horários regionais de visualização.

A resolução de entidades tem uma experiência de usuário diferente, mas a mesma demanda operacional. O sistema precisa relacionar registros, contas, produtos ou identidades enquanto outro processo de negócios aguarda a resposta.

Essas aplicações colocam a recuperação no caminho crítico, o que significa que o trabalho posterior não pode continuar até que a busca responda. Portanto, um endpoint sobrecarregado pode desacelerar todo um fluxo de trabalho voltado ao cliente.

A Databricks identifica três sinais de alerta: erros HTTP 429, aumento da latência P95 e soluções alternativas envolvendo endpoints duplicados. A latência P95 é o tempo de resposta que 95 por cento das solicitações atingem ou superam.

A cauda importa porque uma média pode esconder uma experiência ruim. A maioria das consultas pode retornar rapidamente, enquanto uma minoria significativa se torna lenta durante picos de tráfego.

Uma equipe também pode encontrar problemas quando a utilização média parece moderada. Picos curtos podem esgotar a capacidade disponível antes que uma média horária ou diária revele o problema.

É aqui que uma meta declarada ajuda. As equipes podem dimensionar para uma taxa de solicitações esperada e adicionar margem para picos conhecidos. A observabilidade então mostra se a premissa corresponde à realidade.

No entanto, uma meta só é tão útil quanto o modelo de tráfego por trás dela. Uma média semanal não descreve um pico no dia do lançamento. Um teste com um único usuário não reproduz milhares de sessões simultâneas.

As barras de busca também ilustram por que a recuperação vetorial agora compete com a busca por palavras-chave estabelecida. A busca baseada em embeddings representa itens como vetores numéricos, permitindo que o sistema recupere conteúdo semanticamente relacionado.

Essa abordagem pode encontrar produtos ou documentos relevantes mesmo quando os usuários usam palavras diferentes. Ainda assim, nomes exatos, códigos de produtos e termos incomuns muitas vezes continuam favorecendo a correspondência por palavras-chave.

A busca híbrida combina recuperação semântica e por palavras-chave. A Databricks a recomenda como um ponto de partida geral útil, mas sua orientação de desempenho diz que solicitações híbridas normalmente consomem cerca de duas vezes os recursos das consultas de vizinhos mais próximos aproximados.

A busca de vizinhos mais próximos aproximados, ou ANN, encontra vetores próximos sem comparar exaustivamente cada item. Ela melhora a eficiência do atendimento ao aceitar uma aproximação controlada.

A escolha afeta tanto a relevância quanto a capacidade. Uma carga de trabalho dimensionada com solicitações ANN simples pode se comportar de modo diferente depois que uma equipe ativa recuperação híbrida, filtragem ou reranqueamento.

O reranqueamento aplica outro modelo após a recuperação para reordenar candidatos. Ele pode melhorar a precisão, mas a Databricks afirma que seu reranqueador cross-encoder pode acrescentar latência, normalmente inferior a um segundo adicional por consulta.

Esse atraso pode ser aceitável para uma ferramenta interna de pesquisa. Ele pode parecer muito maior dentro de uma caixa de busca de produtos que é atualizada a cada tecla digitada.

Portanto, a questão de produção não é apenas: “O endpoint consegue processar milhares de solicitações?” É: “Ele consegue processar esta combinação exata de consultas dentro da latência exigida?”

Essa distinção pressiona simultaneamente proprietários de aplicações, engenheiros de plataforma e equipes de dados. Os proprietários de aplicações definem a experiência. As equipes de plataforma gerenciam a capacidade, enquanto as equipes de dados protegem a atualização e a qualidade da recuperação.

Para equipes que trabalham com documentos internos, o comportamento da busca também depende de quão consistentemente as informações são capturadas e organizadas. Uma base de conhecimento pesquisável pode melhorar o acesso, mas a velocidade de atendimento não pode corrigir contexto ausente.

Alto QPS amplia o número de usuários que podem acessar um índice. Ele não garante que o índice contenha o material certo ou retorne o resultado correto.

O Protótipo da Databricks Desafia a Pilha de Busca Separada

A Databricks está desafiando a suposição de que a recuperação em produção precisa deixar a plataforma de dados e migrar para uma infraestrutura de atendimento dedicada.

Uma arquitetura comum separa a preparação de dados da busca de aplicações. As equipes transformam e governam dados em uma plataforma e, depois, exportam registros ou embeddings para outro sistema desenvolvido para recuperação online.

Essa separação tem vantagens. Produtos de busca dedicados podem oferecer controles especializados de indexação, ferramentas de relevância familiares ou desempenho comprovado para uma carga de trabalho específica.

Ela também cria trabalho de sincronização e governança. As equipes precisam decidir com que rapidez as atualizações são movidas, quais permissões são transferidas e como as falhas são reconciliadas entre sistemas.

A Databricks quer que os clientes evitem essa transferência. O AI Search mantém os dados de origem, o processo de sincronização, os controles de governança e o endpoint de consulta dentro da mesma plataforma mais ampla.

O escalonamento de alto QPS torna essa proposta mais crível para aplicações interativas. Sem throughput suficiente, a unidade da plataforma permanece atraente apenas até a chegada de usuários reais.

Portanto, o principal oponente não é um banco de dados específico. É a pilha de atendimento separada, incluindo as camadas de replicação, roteamento e operação construídas em torno dela.

O Google oferece uma comparação útil porque o Vertex AI Vector Search também trata a capacidade como uma preocupação de serviço gerenciado. O Google documenta escalonamento automático, múltiplas réplicas e controles de ajuste para recall e latência.

O Google relatou benchmarks de busca vetorial que alcançam milhares de QPS em conjuntos de dados públicos. Esses números usam conjuntos de dados, dimensões, réplicas e metas de recall específicos, portanto não são comparações diretas com a Databricks.

Essa ressalva é essencial. Os números de throughput dos fornecedores descrevem configurações testadas, não desempenho universal. O tamanho do índice, as dimensões dos vetores, os filtros, as contagens de resultados, os tipos de consulta e a simultaneidade podem alterar o resultado.

A Databricks publica faixas de referência, em vez de um único benchmark de destaque. Seu guia de desempenho lista latência de endpoint padrão em torno de 20 a 50 milissegundos e throughput base de 30 a mais de 200 QPS.

Esses números descrevem configurações comuns, não a capacidade recém-provisionada para alto QPS. A empresa afirma que a nova configuração pode levar endpoints padrão à casa dos milhares ao adicionar infraestrutura por trás do destino.

O tamanho do índice continua relevante. A Databricks afirma que uma unidade padrão de pesquisa vetorial comporta cerca de dois milhões de vetores, enquanto um endpoint padrão suporta até 320 milhões.

À medida que um índice abrange unidades adicionais, o QPS base pode diminuir e, eventualmente, se estabilizar perto de 30 QPS para consultas ANN. A capacidade de alto QPS atende à demanda de serving, mas as equipes ainda precisam compreender a estrutura do índice.

Endpoints otimizados para armazenamento seguem outro perfil. A Databricks documenta capacidade de até um bilhão de vetores, com maior latência e menor throughput base do que endpoints padrão.

Esses endpoints tornaram-se amplamente disponíveis em maio de 2026. A Databricks afirmou que eles podem indexar dados de 10 a 20 vezes mais rápido que endpoints padrão e suportar coleções muito maiores.

No entanto, o lançamento de alto QPS de julho ainda não se estende aos endpoints otimizados para armazenamento. A Databricks afirma que o suporte está planejado para mais tarde em 2026.

Essa limitação define a fronteira competitiva atual. Equipes que escolhem entre serving padrão de baixa latência e índices otimizados para armazenamento muito grandes não podem presumir que o novo modelo de escalabilidade se aplique igualmente.

O serviço do Google apresenta um conjunto diferente de controles. Desenvolvedores podem ajustar réplicas, tipos de máquina, frações de busca e contagens de vizinhos. Essa flexibilidade pode ajudar equipes experientes a ajustar o desempenho com precisão.

A Databricks está adotando uma abordagem mais declarativa para esse recurso. O desenvolvedor define uma taxa de solicitações desejada, e a plataforma calcula a capacidade.

A troca é familiar em infraestrutura gerenciada. Mais abstração reduz o trabalho rotineiro, mas também pode ocultar os mecanismos necessários para otimizações incomuns ou investigações de custo.

A Databricks expõe o estado de escalabilidade aplicado e as métricas do endpoint. Ainda assim, a API do serviço descreve target_qps como uma meta de melhor esforço, e não como uma garantia absoluta.

Isso é importante durante a seleção da plataforma. Uma meta simplifica o provisionamento, mas um objetivo de nível de serviço de produção ainda é responsabilidade da equipe de aplicação.

O argumento mais forte para permanecer dentro da Databricks surge quando governança de dados e atualização têm tanto peso quanto a velocidade bruta de recuperação. Evitar outra cópia pode reduzir a complexidade operacional e de segurança.

O argumento mais forte para uma pilha separada continua sendo a especialização da carga de trabalho. Uma equipe pode precisar de um recurso de busca, linguagem de consulta, topologia regional ou controle de ajuste que sua plataforma de dados não oferece.

Alto QPS reduz essa decisão. Não a elimina.

Um Parâmetro de Configuração Não Pode Substituir Testes de Carga

A Databricks automatiza o provisionamento de capacidade, mas a confiabilidade em produção ainda depende de testes representativos e de um projeto disciplinado de consultas.

A própria empresa recomenda que clientes realizem testes de carga nos endpoints. Um teste útil simula volume de tráfego real, simultaneidade, filtros, tipos de consulta e tamanhos de resultado.

Testar apenas uma consulta ANN limpa pode gerar falsa confiança. Aplicações de produção frequentemente adicionam filtros de metadados, recuperação híbrida e reranqueamento depois que o primeiro protótipo é bem-sucedido.

Cada escolha consome recursos diferentes. A Databricks afirma que a busca híbrida pode usar aproximadamente o dobro dos recursos de ANN, enquanto retornar mais resultados também aumenta o trabalho de varredura.

Suas orientações afirmam que aumentar em dez vezes a contagem de resultados solicitados pode dobrar a latência e reduzir a capacidade de QPS em três vezes. O efeito exato depende do índice e da configuração.

As dimensões vetoriais adicionam outra variável. Uma dimensão de embedding é o número de características numéricas usadas para representar um item.

Embeddings maiores podem preservar mais informações, mas exigem mais computação. A Databricks afirma que reduzir dimensões de 768 para 384 normalmente melhora o QPS em cerca de 1,5 vez e reduz a latência em aproximadamente 20%.

Isso não é um motivo para reduzir todos os embeddings. A qualidade da recuperação pode cair se a representação perder informações relevantes para a aplicação.

As equipes precisam medir a relevância junto com a velocidade. Um endpoint rápido que retorna candidatos fracos não está pronto para produção, mesmo que seu gráfico de throughput pareça saudável.

A autenticação também pode se tornar um gargalo. A Databricks recomenda service principals com OAuth para aplicações de produção, em vez de tokens de acesso pessoal.

Um service principal é uma identidade não humana usada por software. Ele permite permissões gerenciadas sem vincular o acesso da aplicação às credenciais de um único funcionário.

A Databricks afirma que o tráfego de service principals usa caminhos de rede otimizados para desempenho. Sua documentação de consulta afirma que essa abordagem pode economizar até 100 milissegundos por solicitação em comparação com outros roteamentos.

A empresa também afirma que o tráfego com tokens de acesso pessoal é limitado a algumas dezenas de QPS. Portanto, um protótipo que usa esse caminho de autenticação pode falhar antes que o endpoint alcance sua capacidade planejada.

As equipes devem testar a partir do ambiente real da aplicação. Um notebook no mesmo workspace não reproduz caminhos de rede pública, geração de tokens, tentativas da aplicação ou distância regional.

O comportamento de repetição merece atenção especial. Quando uma aplicação recebe uma resposta 429, tentativas imediatas podem amplificar o pico de tráfego original.

Backoff e jitter distribuem as tentativas ao longo do tempo. Sem eles, um problema temporário de capacidade pode se tornar uma tempestade de solicitações autossustentada.

A própria meta precisa de margem. Defini-la igual ao tráfego médio deixa pouca proteção contra picos, clientes sincronizados ou eventos especiais.

Defini-la muito acima da demanda esperada traz outra preocupação. A Databricks observa que a capacidade adicional gera custo adicional quando uma meta é configurada.

O anúncio não fornece uma comparação universal de custos. As necessidades de capacidade variam conforme o índice, a carga de trabalho de consulta e o objetivo de desempenho, portanto os compradores precisam de suas próprias medições.

A escalabilidade automática não faz parte da versão atual. As equipes declaram a capacidade antes da chegada do tráfego, em vez de deixar o sistema reagir continuamente sem dimensionamento manual.

Isso cria uma distinção operacional entre escala planejada e escala elástica. Uma meta planejada pode atender a um lançamento conhecido, mas uma alta inesperada pode exceder a estimativa original.

A Databricks afirma que a resposta automática a picos de tráfego está planejada para mais tarde em 2026. Até lá, observabilidade e atualizações da meta continuam fazendo parte da operação do serviço.

A API também classifica a meta como de melhor esforço. Essa formulação significa que desenvolvedores não devem interpretar target_qps como uma garantia contratual para toda combinação de consultas.

Índices grandes introduzem outro risco. Os endpoints otimizados para armazenamento da Databricks oferecem maior capacidade, mas a definição de alto QPS atualmente se aplica apenas a endpoints padrão.

Uma equipe que se aproxima dos limites de endpoints padrão pode enfrentar uma escolha arquitetural. Ela pode particionar dados, replicar índices ou aguardar suporte a alto QPS para a opção otimizada para armazenamento.

A Databricks recomenda endpoints paralelos quando um endpoint não consegue atender a throughput extremo. As equipes podem dividir índices separados entre endpoints ou replicar um índice popular e distribuir o tráfego.

Essas recomendações soam muito como o trabalho de infraestrutura que este lançamento busca reduzir. Elas mostram que o modelo de configuração tem um limite prático.

O recurso elimina o dimensionamento rotineiro de réplicas para cargas de trabalho compatíveis. Não elimina as restrições de sistemas distribuídos.

Um plano de implantação confiável deve testar três condições: tráfego normal, um pico esperado e uma alta de tentativas motivada por falha. Ele deve registrar tanto a latência quanto a relevância em cada condição.

As equipes também devem avaliar a sincronização do índice durante a carga. Dados atualizados são parte da qualidade da busca, e um endpoint que responde rapidamente com informações desatualizadas ainda pode prejudicar usuários.

Um protótipo da Databricks torna-se pronto para produção somente depois que esses testes são aprovados. A nova configuração encurta o caminho, mas as evidências precisam vir da carga de trabalho.

Três Sinais Mostrarão se Alto QPS Muda a Busca em Produção

A próxima fase depende de escalabilidade elástica, suporte otimizado para armazenamento e evidências independentes de cargas de trabalho de clientes.

O primeiro sinal é a escalabilidade automática para picos de tráfego. A Databricks afirma que essa capacidade está planejada para mais tarde em 2026, sem exigir planejamento ou dimensionamento manual de capacidade.

Se ela chegar e mantiver a latência de cauda estável, o argumento da empresa para produção se tornará mais forte. As equipes não precisarão mais estimar cada pico antes de configurar a capacidade.

Se a escalabilidade automática responder lentamente demais, os clientes ainda poderão provisionar uma margem substancial. Isso enfraqueceria a alegação de que a plataforma eliminou a maior parte das operações de serving.

O cronograma também importa para ambientes regulados. A Databricks afirma que alto QPS deverá se tornar disponível por padrão para workspaces que usam seu perfil de segurança de conformidade no fim de agosto de 2026.

Essa expansão mostrará se a capacidade pode ir além de implantações comuns sem criar um caminho operacional separado. Compradores corporativos frequentemente precisam que desempenho e controles de conformidade coexistam.

O segundo sinal é o suporte a endpoints otimizados para armazenamento. Esses endpoints atendem índices muito maiores, mas atualmente apresentam maior latência e não têm a nova configuração de alto QPS.

Adicionar o recurso conectaria duas partes da narrativa do produto: capacidade em escala de bilhões e alto throughput de solicitações. Até lá, os clientes devem escolher cuidadosamente o perfil de endpoint.

O sucesso significaria que catálogos grandes poderiam adotar o mesmo modelo declarativo de serving. Atrasos ou limitações rigorosas preservariam espaço para bancos de dados vetoriais especializados e serviços de nuvem.

O terceiro sinal é a evidência dos clientes. A Databricks anunciou o mecanismo de capacidade, mas não publicou resultados independentes de produção suficientes para definir o desempenho em cargas de trabalho diversas.

Evidências úteis devem incluir tamanho do índice, dimensões vetoriais, combinação de consultas, filtros, resultados solicitados, simultaneidade, latência P95 e QPS alcançado. Um número de destaque sem esses detalhes oferece pouca orientação.

Relatos de clientes também devem descrever o trabalho operacional. A questão mais importante é se as equipes eliminaram infraestrutura, e não simplesmente se a Databricks adicionou capacidade.

Um varejista que desativa índices duplicados e roteamento no lado do cliente apoiaria a tese de continuidade da plataforma. Uma equipe que mantém essas camadas por segurança a qualificaria.

Os desenvolvedores também devem observar como o serviço se comporta durante a sincronização. A nova capacidade entra em vigor depois que um índice é criado ou sincronizado, o que pode afetar o momento de mudanças urgentes de escalabilidade.

Esse comportamento pode ser razoável para eventos planejados. É menos adequado para demanda súbita e imprevisível, a menos que o endpoint já tenha margem suficiente.

A resposta competitiva será reveladora. Serviços de vetores gerenciados já oferecem escalabilidade automática ou controles de réplicas, e sistemas dedicados continuam aprimorando a recuperação híbrida e a filtragem.

A Databricks não precisa vencer todos os benchmarks. Ela precisa tornar uma plataforma de serving separada desnecessária para clientes suficientes que já usam dados governados no lakehouse.

Essa proposta de valor vai além da busca de produtos. Assistentes de IA empresariais também dependem de recuperação rápida em documentos, registros e permissões.

Quando as equipes projetam esses sistemas, precisam tanto de capacidade de serving quanto de uma camada de informações confiável. Um sistema pessoal de conhecimento atende ao contexto individual, enquanto a recuperação empresarial adiciona exigências de governança e escala compartilhada.

O lançamento de julho estabelece um caminho de produção mais claro para esta última. Ele oferece às equipes de engenharia um controle simples para um problema que antes acionava infraestrutura adicional.

Ainda assim, o anúncio deve ser interpretado como uma mudança no modelo operacional, não como uma garantia universal de desempenho. O Databricks automatiza o cálculo de capacidade dentro dos limites definidos do endpoint.

O melhor próximo passo é concreto. Pegue o protótipo existente do Databricks, reproduza toda a sua combinação de consultas de produção e avalie-o em condições de tráfego normal e de pico.

Acompanhe a latência P95, as taxas de erro, a relevância, o comportamento de sincronização e o custo de capacidade. Teste a autenticação por service principal e o comportamento de repetição de tentativas a partir do ambiente real da aplicação.

Em seguida, faça a pergunta decisiva: target_qps eliminou uma camada de serving ou apenas transferiu seu planejamento para uma nova configuração? A resposta determinará se o Databricks AI Search superou a lacuna rumo à produção para a sua carga de trabalho.