Os modelos Kumo da NVIDIA deixam agentes prever a partir das suas tabelas. A ontologia ainda precisa de dono

Pergunte a um agente enterprise típico quais clientes deste trimestre têm mais chance de parar de comprar, e ele fará o que foi construído para fazer: buscar. Vai achar documentos que falam de churn, uma exportação de dashboard, talvez a apresentação do conselho do ano passado, e escrever um parágrafo fluente. O que ele não consegue é olhar para as relações entre clientes, pedidos, produtos e chamados de suporte e estimar, cliente a cliente, o que vai acontecer.

Foi essa lacuna que a NVIDIA atacou em 21 de outubro com o Agent Knowledge Foundation, uma ampliação do seu Agent Toolkit open source. As peças:

• Auto-Ontology, uma biblioteca nova que traduz dados brutos da empresa em conceitos de negócio, como clientes, produtos e pedidos, e mapeia como eles se relacionam.
• Kumo, uma família nova de modelos abertos para dados estruturados: Kumo Tabular, Kumo Relational, Kumo Time Series e Kumo Forecast, além de um modelo de anomalias que a Databricks combina com a sua Genie Ontology.
• Modelos Nemotron Retriever para busca, e bibliotecas CUDA-X como o cuGraph, para grafos, e o cuOpt, para otimização.

A própria área de supply chain da NVIDIA usa a stack via Foundry e AIP, da Palantir. Clientes da Snowflake podem rodar o Kumo Engine e o Kumo Relational dentro de notebooks da Snowflake, em pools de GPU, de modo que dados, treino e previsões ficam na conta; a Snowflake cita Affirm, NOV, VideoAmp e Yieldmo como usuários. Vários outros fornecedores dizem estar construindo sobre ela.

Quatro perguntas que um agente pode ter de responder

O jeito útil de ler o anúncio é como uma lista de perguntas diferentes. A busca responde só a primeira.

O que perguntam ao agente, e o que deveria responder

	Componente na stack da NVIDIA	Quem precisa validar
O que dizem os nossos documentos?	Busca: Nemotron Retriever, rerankers	Donos do conteúdo; evals de busca
O que significam os nossos termos, e como se relacionam?	Auto-Ontology	O dono de negócio de cada definição
O que deve acontecer com este cliente, pedido ou máquina?	Modelos preditivos Kumo	Ciência de dados, com backtests no seu histórico
Qual a melhor ação dadas estas restrições?	Otimização com cuOpt	Operações, contra restrições reais

A segunda e a terceira linhas são a novidade. Um modelo relacional que aprende com tabelas, chaves e o momento dos eventos consegue estimar churn, fraude, demanda ou a próxima compra sem que alguém antes achate os dados numa única tabela larga, que é como boa parte da modelagem preditiva ainda funciona nas empresas. O exemplo da Snowflake prevê quais clientes ativos vão comprar de novo nos próximos 90 dias a partir de quatro tabelas e poucas linhas de Python.

Uma previsão é uma ferramenta a chamar, não um pensamento a ter

A lição de arquitetura é que um agente não deveria estimar a probabilidade de churn raciocinando sobre ela em texto. Deveria chamar um modelo treinado para estimá-la, receber um número com acurácia conhecida e raciocinar sobre o que fazer com esse número. Dissemos o mesmo quando o Google colocou um modelo de previsão dentro do BigQuery: nem todo problema de IA enterprise precisa de um modelo de linguagem pensando.

Essa divisão também torna o sistema testável. Um modelo Kumo pode passar por backtest com os dados do ano passado, ter o erro medido e o drift monitorado, como qualquer modelo preditivo que o seu time de risco já revisa. A estimativa improvisada de um modelo de linguagem, não.

A ontologia é o novo ponto fraco

O Auto-Ontology é a peça mais importante e a mais frágil. Mapear tabelas brutas para conceitos de negócio de forma automática é atraente porque construir ontologias à mão é lento. É arriscado pelo mesmo motivo. Uma ontologia gerada vai decidir que “cliente” é uma linha de uma tabela, que “receita” é uma certa coluna, que duas entidades se relacionam porque uma chave diz isso. São decisões de negócio, e na maioria das empresas elas são disputadas.

Já escrevemos que as definições de negócio estão virando infraestrutura compartilhada dos agentes, e que em finanças reguladas a ontologia pode importar mais que o chatbot. Uma ontologia gerada automaticamente não elimina esse trabalho; produz um primeiro rascunho dele. Trate o resultado como uma proposta que o dono de cada definição aprova, versiona e pode mudar, e não como configuração que o time de plataforma aceita por padrão.

Cuidados antes de adotar

• Resultado de fornecedor é resultado de fornecedor. Os exemplos da NVIDIA de rerank mais rápido e relevância melhor vêm de parceiros e não foram medidos de forma independente.
• Previsão não é causalidade. Um modelo que prevê bem o churn não explica por que os clientes saem, e um agente que age sobre uma previsão pode mudar o comportamento que ela previu.
• Confira o que é aberto e com que licença antes de planejar em cima: o Agent Knowledge Foundation combina componentes novos com outros que a NVIDIA já tinha lançado, e a disponibilidade varia por peça.
• Mantenha a decisão no sistema que é dono dela. Um agente que prevê que um cliente vai sair e oferece um desconto está assumindo um compromisso comercial. Isso deveria passar pela mesma aprovação de qualquer outro desconto.

A direção está certa. Agentes enterprise que só sabem buscar documentos vão continuar produzindo parágrafos confiantes sobre perguntas que pedem números. O trabalho que vem junto também está claro: alguém precisa ser dono do que as palavras da ontologia significam.