Databricks ai_decide Leva Dados Governados da Análise à Ação
A Databricks lançou o Databricks ai_decide em 30 de setembro, adicionando uma função SQL em beta que transforma dados governados em probabilidades, escolhas e pontuações. O conflito é imediato. Empresas querem decisões assistidas por IA na velocidade dos dados, mas escolhas operacionais exigem mais responsabilidade do que a geração comum de texto.
A nova função avalia registros estruturados ou texto com base em uma rubrica fornecida pelo usuário. Ela pode estimar se um evento requer atenção, escolher entre resultados nomeados ou pontuar um caso em uma escala ordenada. Esses resultados podem então alimentar outra consulta SQL, fluxo de trabalho ou aplicação.
Isso torna o anúncio mais relevante do que mais um endpoint de modelo. A Databricks está levando o julgamento baseado em modelos para dentro do fluxo de trabalho de dados, onde as equipes já controlam tabelas, permissões, pipelines e lógica de negócios. O Google Cloud oferece funções generativas relacionadas no BigQuery, enquanto APIs gerais de modelos permitem que desenvolvedores construam sistemas semelhantes manualmente. A disputa agora diz respeito a quem consegue tornar decisões probabilísticas operacionais sem ocultar sua incerteza.
Databricks ai_decide Transforma Uma Chamada SQL em Várias Decisões
A mudança importante não é que a Databricks consegue chamar um modelo a partir do SQL. É que uma função governada pode retornar várias avaliações prontas para decisão sobre o mesmo registro.
Segundo a publicação de lançamento da empresa, o Databricks ai_decide foi concebido para decisões rápidas sobre dados empresariais governados. A função faz parte da família mais ampla de AI Functions específicas para tarefas da empresa.
Sua sintaxe tem três partes: um estado, uma coleção de perguntas e configurações opcionais de versão. O estado contém as evidências avaliadas. Ele pode ser texto comum, um objeto codificado em JSON, uma matriz JSON ou um VARIANT gerado por outra AI Function.
As perguntas são definidas uma vez para a chamada e aplicadas a cada linha de entrada. Cada pergunta inclui instruções e um tipo de resposta. Alguns tipos também exigem critérios que descrevem os resultados disponíveis.
A referência da função documenta três tipos de resposta:
noul estima a probabilidade de uma afirmação ser verdadeira, retornando um número entre 0 e 1.
choice seleciona um rótulo entre até 255 critérios nomeados e retorna probabilidades para cada rótulo.
score avalia a entrada em relação a uma escala ordenada contendo entre 2 e 10 critérios.
O termo incomum noul identifica uma avaliação probabilística de sim ou não. Em vez de impor uma resposta booleana, a função informa uma probabilidade estimada. Essa distinção importa quando sistemas posteriores precisam de limiares, e não de afirmações absolutas.
Uma organização de suporte, por exemplo, poderia perguntar se um ticket precisa de escalonamento imediato. Ela também poderia perguntar qual equipe deve assumir o caso e qual parece ser a urgência da situação. As três avaliações podem usar o mesmo ticket como evidência.
O resultado é um VARIANT contendo uma resposta, metadados e um campo de erro. Um VARIANT é um tipo de dado flexível para valores semiestruturados, como JSON aninhado. Chamadas bem-sucedidas identificam a versão da função, enquanto chamadas com falha podem retornar uma descrição do erro.
Para perguntas do tipo escolha, a saída inclui o rótulo selecionado, probabilidades para cada rótulo possível e um valor de confiança. Perguntas do tipo pontuação incluem uma pontuação numérica, as descrições originais da escala, probabilidades e confiança.
Esse design oferece aos analistas mais informações do que um único rótulo gerado. Um fluxo de trabalho pode aceitar automaticamente decisões de alta confiança, encaminhar casos incertos para pessoas e registrar a distribuição de probabilidades para análise posterior.
A Databricks também alerta que respostas geradas podem variar entre chamadas. Essa afirmação é fácil de ignorar, mas define o principal desafio operacional. A sintaxe SQL torna a função acessível e combinável. Ela não torna o julgamento subjacente determinístico.
Decisões de IA Governadas Colocam Pressão Sobre as Equipes de Dados
O Databricks ai_decide pressiona as equipes de dados a tratar o julgamento de modelos como lógica de produção, e não como uma saída experimental copiada de um chatbot.
Muitas decisões empresariais já começam em um warehouse ou lakehouse. Tickets de suporte, listagens de produtos, documentos de seguros, relatórios de incidentes, solicitações e registros de transações acabam se tornando linhas processadas por pipelines.
O SQL tradicional funciona bem quando a decisão pode ser escrita como uma regra exata. Uma transação acima de um valor fixo pode entrar em uma fila de revisão. Um ticket com um código de erro conhecido pode ser direcionado a uma equipe específica.
Os casos mais difíceis dependem de significado. Um cliente pode descrever uma interrupção de serviço sem usar o vocabulário oficial de incidentes da empresa. Uma listagem de produto pode sugerir adequação sem corresponder a uma taxonomia controlada. Um caso pode atender simultaneamente a várias prioridades concorrentes.
As organizações costumam lidar com essas situações por meio de filas manuais ou serviços externos de modelos. A revisão manual pode ser lenta. Serviços externos acrescentam código, movimentação de dados, credenciais, monitoramento e trabalho de governança.
O Databricks ai_decide encurta esse caminho. Uma equipe pode expressar uma rubrica qualitativa ao lado dos dados e receber avaliações estruturadas no SQL. Essas avaliações podem então participar de filtros, joins, dashboards, pipelines Lakeflow, Workflows ou lógica de aplicação.
A visão geral mais ampla de AI Functions descreve funções integradas para análise de documentos, extração, classificação, preparação para busca e outras transformações. O Databricks ai_decide acrescenta uma camada explícita de decisão após essas etapas de preparação.
Considere um fluxo de trabalho de documentos. ai_parse_document pode converter um documento enviado em conteúdo estruturado. ai_extract pode identificar campos especificados. O Databricks ai_decide pode então avaliar o VARIANT resultante com base em uma rubrica de negócios.
Essa sequência muda quem consegue criar o fluxo de trabalho. Um engenheiro de dados não precisa mais encapsular cada decisão em um serviço personalizado. Um analista pode inspecionar o estado, os critérios, as respostas, as probabilidades e os erros por meio de ferramentas de dados conhecidas.
Ela também muda quem se torna responsável. Quando uma pontuação gerada por IA controla o encaminhamento ou a priorização, a equipe de dados é responsável por mais do que o desempenho das consultas. Ela precisa ajudar a definir taxas de erro aceitáveis, limiares de escalonamento, regras de monitoramento e comportamento de contingência.
A governança passa a fazer parte do design do produto. A Databricks afirma que os dados dos documentos permanecem dentro de seu perímetro de segurança. A empresa diz que não armazena os parâmetros passados nas chamadas de AI Functions, embora retenha metadados de execução, como a versão do runtime.
O acesso não é automaticamente restrito. A documentação da Databricks afirma que os usuários recebem, por padrão, permissão EXECUTE no esquema system.ai quando a prévia relevante está habilitada. Os administradores precisam remover essa permissão no nível do esquema antes de conceder acesso a funções ou grupos selecionados.
Esses controles de acesso também estão em prévia pública e exigem habilitação. Eles se aplicam a funções específicas para tarefas sob system.ai, mas não governam a função de uso geral ai_query.
Esse limite importa. Uma empresa não pode presumir que habilitar um mecanismo de governança cobre todas as rotas para um modelo. Os administradores precisam de políticas separadas para AI Functions específicas para tarefas e chamadas diretas ao Model Serving.
O lançamento, portanto, cria pressão sobre proprietários de plataformas, equipes de segurança e líderes operacionais ao mesmo tempo. Proprietários de plataformas precisam tornar a função confiável. Equipes de segurança precisam configurar o acesso de forma intencional. Líderes de negócios precisam definir onde a automação probabilística é aceitável.
Rubricas Estruturadas São o Verdadeiro Mecanismo
O mecanismo central é uma mudança de prompts abertos para rubricas explícitas com incerteza estruturada.
Um prompt de modelo geral pode perguntar: “O que devemos fazer com este caso?” A resposta pode ser articulada, mas outro sistema precisará interpretá-la. O modelo também pode inventar uma categoria, alterar seu formato ou explicar uma decisão sem produzir um campo confiável.
O Databricks ai_decide restringe a interação. O desenvolvedor define perguntas nomeadas, instruções e critérios permitidos. A função retorna uma estrutura de resposta previsível que o SQL posterior pode acessar.
Essa restrição reduz o trabalho de integração. Ela também expõe o contrato de decisão aos revisores. Um especialista em conformidade pode examinar a definição de escalonamento. Um gerente de operações pode inspecionar as descrições das categorias. Um engenheiro de dados pode verificar como as probabilidades se tornam ações de fluxo de trabalho.
O tipo de escolha ilustra a abordagem. Suponha que uma organização de suporte defina entrega, cobrança e suporte técnico como os únicos rótulos de encaminhamento. A função deve selecionar entre esses nomes e retornar uma probabilidade para cada um.
O rótulo selecionado é útil, mas a distribuição pode ser mais informativa. Um resultado dividido de forma próxima entre cobrança e suporte técnico sinaliza ambiguidade. Um fluxo de trabalho pode enviar esse caso para uma fila geral em vez de fingir que o rótulo principal é certo.
O tipo de pontuação usa critérios ordenados em vez de um número livre. Uma equipe pode definir três níveis de urgência, de uma solicitação rotineira a um bloqueio crítico. A pontuação retornada é uma média ponderada pelas probabilidades dos índices dos critérios.
Esse método preserva informações sobre avaliações concorrentes. Se o modelo atribuir probabilidade entre vários níveis, o resultado pode ser fracionário. A saída também retém a legenda e as probabilidades por trás da pontuação.
Várias perguntas podem compartilhar um estado. Isso reduz a necessidade de passar as mesmas evidências por prompts separados para categoria, urgência, escalonamento e outros julgamentos. Também mantém as respostas relacionadas juntas.
No entanto, compartilhar a entrada não garante que cada pergunta represente uma avaliação independente. As equipes devem testar se as instruções interagem de maneiras inesperadas. Elas também devem verificar se combinar perguntas altera qualidade, latência ou custo para sua carga de trabalho.
A Databricks afirma que o modelo subjacente pode mudar se outro modelo tiver melhor desempenho em seus benchmarks internos. A documentação atual associa possíveis modelos à licença Apache 2.0 e direciona os clientes aos termos aplicáveis aos modelos.
Uma escolha de modelo gerenciada reduz a configuração. Ela também significa que o comportamento da função pode evoluir sob uma interface SQL estável. Os metadados de versão ajudam a identificar o contrato da função, mas as equipes ainda precisam de testes de regressão baseados em dados representativos.
É nesse ponto que o mecanismo se torna operacionalmente importante. Um procedimento armazenado construído com condições determinísticas pode ser testado com resultados esperados exatos. Uma função probabilística precisa de verificações de distribuição, verificações de limiar e avaliações repetidas.
As equipes devem manter conjuntos de avaliação rotulados para cada rubrica importante. Esses conjuntos devem incluir exemplos comuns, casos limítrofes, evidências ausentes, evidências conflitantes e entradas que sempre devem chegar a uma pessoa.
Elas também devem separar recomendação de execução. Uma função de decisão pode priorizar uma fila de suporte com impacto negativo limitado. A mesma confiança não deve autorizar automaticamente um reembolso, rejeitar um candidato, suspender uma conta ou iniciar uma resposta de segurança.
A interface SQL facilita a composição. Um bom design de sistema deve manter ações consequentes deliberadamente difíceis.
Databricks ai_decide Compete com Chamadas a Modelos Gerais e IA para Data Warehouses
A principal disputa é entre uma função gerenciada específica para a tarefa e a flexibilidade de construir lógica de decisão em torno de um endpoint de modelo geral.
A Databricks já oferece ai_query, uma função de uso geral que invoca um endpoint de Model Serving. Os desenvolvedores podem escolher um modelo compatível, escrever seus próprios prompts e controlar parâmetros e tipos de retorno.
A documentação do ai_query recomenda que as equipes comecem com uma AI Function específica para a tarefa quando houver uma que corresponda ao seu objetivo. Ela posiciona o ai_query para casos que exigem mais controle sobre o modelo, o prompt, os parâmetros ou a saída.
Essa distinção cria uma troca clara.
Uma função específica para a tarefa reduz a configuração e impõe um contrato estruturado. A Databricks gerencia o sistema por trás da operação e pode aprimorar sua implementação. As equipes podem se concentrar em suas evidências, perguntas e critérios.
Uma chamada a um modelo geral oferece flexibilidade. Os desenvolvedores podem usar um modelo personalizado, ajustar configurações de decodificação, definir um esquema diferente, implementar endpoints de fallback ou preservar uma versão fixa do modelo. Também assumem mais trabalho de engenharia e avaliação.
O Databricks ai_decide é mais forte quando uma decisão se encaixa em suas três formas disponíveis. Probabilidade, escolha nomeada e pontuação ordenada abrangem muitas tarefas de roteamento e priorização. Elas não cobrem todas as estruturas de decisão.
Uma empresa pode precisar de classificação multirrótulo, estimativas numéricas com restrições, citações de evidências, exclusões baseadas em regras ou uma cadeia de perguntas dependentes. Os desenvolvedores talvez ainda precisem de ai_query, funções personalizadas ou um aplicativo externo nesses casos.
O campo competitivo também vai além da Databricks. O Google Cloud documenta uma função AI.GENERATE_BOOL para o BigQuery que retorna um resultado booleano, detalhes da resposta e informações de status. Ela pode processar texto e conteúdo não estruturado referenciado por meio do Gemini.
A função booleana do Google oferece suporte a parâmetros de modelo e de solicitação. Sua documentação também alerta que o design do prompt afeta os resultados e que o planejamento de consultas pode fazer a inferência do modelo processar mais linhas do que o esperado.
O Google também oferece separadamente AI.IF, que sua documentação descreve como compatível com otimização de prompts e um modo otimizado. Esse modo pode treinar um modelo destilado para reduzir custo e latência em escala.
A Databricks adota uma abordagem mais ampla, orientada por rubricas, em uma única chamada. O Databricks ai_decide pode responder a múltiplas perguntas e retornar probabilidades para escolhas nomeadas ou pontuações ordenadas. A função booleana documentada pelo Google se concentra na geração de verdadeiro ou falso, embora o BigQuery ofereça funções escalares e generativas adicionais.
Nenhuma das abordagens elimina o design de aplicações. A IA nativa para data warehouses reduz a distância entre dados e inferência, mas as equipes ainda definem limites, materializam entradas, controlam permissões e avaliam saídas.
Assim, a concorrência dependerá de evidências operacionais, e não apenas de sintaxe. Os compradores precisam saber como as funções se comportam em seus registros, em suas regiões, sob seus requisitos de conformidade e em volume de produção.
Uma função que economiza trabalho de integração, mas cria custos imprevisíveis, terá dificuldades. O mesmo vale para um endpoint flexível que exige uma equipe especializada para cada tarefa rotineira de classificação.
A Databricks aposta que muitas decisões empresariais compartilham estrutura suficiente para merecer uma primitiva gerenciada. O resultado depende de essas primitivas continuarem compreensíveis quando as organizações as conectarem a ações reais.
Decisões Rápidas Ainda Exigem Validação Lenta
O rótulo beta é o alerta mais claro: a Databricks simplificou a implementação, mas não eliminou a incerteza, as limitações regionais nem a responsabilidade humana.
O Databricks ai_decide está disponível como um recurso beta. Os administradores do workspace controlam o acesso pela página Previews, e a função está disponível apenas em regiões compatíveis.
Ela não é executada no Databricks SQL Classic. A documentação exige o Databricks Runtime 15.4 LTS ou posterior e recomenda o Runtime 18.2 ou posterior para recursos e desempenho atuais.
Esses pré-requisitos limitam a adoção imediata. Organizações com runtimes mais antigos, warehouses Classic, regiões não compatíveis ou políticas rigorosas para prévias precisam alterar a infraestrutura ou esperar.
A camada de modelo introduz outra incerteza. A Databricks afirma que pode mudar o modelo subjacente quando seus benchmarks internos identificarem uma opção melhor. Essa evolução gerenciada pode melhorar os resultados, mas também cria deriva de modelo do ponto de vista do cliente.
Um pipeline de decisão não pode depender apenas de o nome da função permanecer estável. As equipes precisam de avaliações de referência, controles de lançamento, limites monitorados e capacidade de comparar resultados após mudanças na plataforma.
A própria rubrica também pode falhar. As instruções podem omitir uma exceção relevante. As categorias podem se sobrepor. Uma escala ordenada pode sugerir uma precisão que as evidências não sustentam.
A confiança exige interpretação cuidadosa. Um campo de alta confiança indica o quanto o estado sustenta a avaliação sob o processo da função. Isso não estabelece que a resposta seja factualmente correta ou justa.
As saídas de probabilidade trazem risco semelhante. Um valor de 0,9 parece preciso, mas os usuários não devem presumir que 90% das previsões comparáveis estarão corretas sem evidências de calibração. A calibração deve ser testada nos próprios casos rotulados da organização.
A qualidade dos dados continua decisiva. Se o estado contém registros desatualizados, incompletos ou enganosos, uma rubrica bem estruturada ainda pode produzir uma decisão ruim. Os controles de governança definem quem pode usar os dados; não garantem que toda entrada seja adequada.
O viés também pode entrar por meio de exemplos e critérios. A descrição de uma categoria pode codificar a prática histórica de uma equipe, incluindo seus pontos cegos. Uma pontuação pode reproduzir julgamentos humanos inconsistentes de um conjunto de avaliação.
Usos de alto impacto exigem salvaguardas mais fortes. Decisões sobre emprego, crédito, saúde, seguros, questões legais e segurança envolvem obrigações que vão além da saída de um modelo. As organizações devem envolver equipes de domínio, jurídicas, de segurança e de risco antes de automatizar ações.
Mesmo fluxos de trabalho de menor risco precisam de tratamento de falhas. A função pode retornar uma resposta nula e uma mensagem de erro. Os pipelines devem decidir se tentam novamente, pausam, usam lógica determinística de fallback ou encaminham o caso a uma pessoa.
As respostas geradas podem variar entre chamadas, segundo a documentação. Portanto, avaliações repetidas podem produzir rótulos ou pontuações diferentes para registros limítrofes. As equipes precisam de políticas de idempotência quando ações posteriores devem ocorrer apenas uma vez.
O custo merece escrutínio semelhante. Cada avaliação respaldada por modelo consome recursos de inferência. Executar várias perguntas em cada linha de uma tabela grande pode transformar uma consulta conveniente em uma operação cara.
Os desenvolvedores devem isolar as linhas relevantes antes de invocar a função. Devem materializar conjuntos de entrada estáveis, impedir reavaliações acidentais da tabela inteira e armazenar as saídas quando a inferência repetida não agrega valor.
Nenhuma dessas preocupações invalida a direção do produto. Elas explicam por que decisões de IA governadas exigem um padrão diferente de resumos gerados. Um resumo fraco incomoda um leitor. Uma decisão fraca de roteamento ou priorização muda o que acontece em seguida.
Três Sinais Mostrarão se a Aposta Funciona
O próximo teste é saber se a Databricks consegue transformar uma abstração SQL promissora em uma capacidade de produção mensurável e governável.
O primeiro sinal é o desempenho de avaliação documentado. A Databricks não apresentou benchmarks independentes que estabeleçam precisão, calibração, latência ou custo em tarefas de decisão representativas. Os clientes precisam de evidências específicas para suas cargas de trabalho, e não de uma promessa geral de velocidade.
Uma validação útil compararia o Databricks ai_decide com ai_query, regras determinísticas e revisão humana estabelecida. Ela deveria medir precisão de rótulos, calibração de probabilidades, estabilidade entre chamadas repetidas, tempo de processamento e o número de casos que exigem escalonamento.
Se as equipes conseguirem publicar ganhos reproduzíveis com taxas de erro controladas, a abordagem específica para a tarefa ganhará credibilidade. Se precisarem envolver cada chamada em ampla lógica corretiva, a abstração economizará menos trabalho do que a sintaxe sugere.
O segundo sinal é uma disponibilidade mais ampla em produção. Atualmente, o recurso tem rótulo beta, exige habilitação de prévia, exclui warehouses SQL Classic e oferece suporte apenas a determinadas regiões.
O avanço rumo a uma disponibilidade mais ampla indicaria que a Databricks confia na confiabilidade do serviço, na cobertura de governança e no suporte operacional. Restrições persistentes de prévia limitariam a função a experimentos e fluxos de trabalho de baixo risco.
A maturidade da governança pertence ao mesmo sinal. Os administradores precisam de controles claros para permissões de execução, acesso a modelos, trilhas de auditoria, processamento regional e alterações nos modelos subjacentes. Esses controles devem funcionar de forma consistente em plataformas de nuvem e configurações de workspace.
O terceiro sinal é o uso pelos clientes além das demonstrações. Categorização de produtos e roteamento de chamados de suporte são exemplos compreensíveis. A evidência mais forte virá de fluxos de trabalho de produção com limites de revisão publicados e resultados de negócio mensuráveis.
Observe casos em que as probabilidades mudam o fluxo de trabalho, e não apenas enfeitam um dashboard. Uma empresa pode automatizar decisões claras, enviar registros ambíguos a especialistas e usar as correções resultantes para testar sua rubrica.
Observe também os concorrentes. O Google Cloud já expõe funções generativas nativas para data warehouses, e outras plataformas de dados continuam adicionando acesso a modelos próximo de dados governados. Uma função concorrente com calibração mais clara, suporte mais amplo a entradas ou menor sobrecarga operacional enfraqueceria a vantagem da Databricks.
O Databricks ai_decide captura uma mudança importante. As empresas já não se satisfazem com modelos que apenas descrevem informações. Elas querem sistemas que ajudem a escolher, classificar, rotear e escalar, permanecendo dentro dos controles de dados estabelecidos.
O próximo passo prudente não é conectar a função diretamente a uma ação consequente. Selecione uma fila delimitada, defina uma rubrica explícita e crie um conjunto de avaliação rotulado. Compare as saídas da função com as decisões atuais e, então, escolha limites para automação e revisão humana. Acompanhe erros, incerteza, latência e deriva separadamente.
Qual decisão em sua organização é repetitiva o bastante para ser avaliada, mas reversível o bastante para ser testada com segurança? Esse é o ponto de partida correto para o Databricks ai_decide. O valor duradouro do produto virá de uma disciplina operacional transparente, não de tratar uma saída probabilística como certeza.
