Criando agentes de IA prontos para produção no Databricks | Demonstração do Agent Bricks

Autoria: Databricks · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Building Production-ready AI Agents on Databricks | Agent Bricks Demo · Canal: Databricks · 06:49 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Dados, bancos de dados e embeddings

Resumo

A demonstração apresenta o ciclo de vida de um agente no Databricks: criar um índice de busca vetorial, construir o agente em código, rastreá-lo, registrá-lo, avaliá-lo e implantá-lo. O MLflow tracing permite inspecionar cada solicitação, incluindo recuperação de informações, chamadas ao modelo, latência, tokens e custo. A avaliação em lote mede aspectos distintos, como relevância, segurança e aderência ao catálogo de produtos. A apresentadora mostra como essas avaliações ajudam a identificar comportamentos fora do escopo e podem ser usadas tanto no desenvolvimento quanto em produção.

Pontos-chave

Um índice de busca vetorial com embeddings gerenciados dispensa configurar um serviço de embedding separado e acompanha as alterações na Delta table.
Manter o agente em código facilita a revisão, o controle de versões e a implantação.
O MLflow tracing registra etapas e métricas de cada solicitação, facilitando a investigação de problemas.
Registrar o agente no Unity Catalog cria um artefato versionado e governado como fonte única para o que está implantado.
As avaliações em lote medem separadamente relevância, segurança e aderência ao catálogo.
Uma resposta pode ser relevante e segura, mas ainda assim estar fora do escopo esperado.
As mesmas avaliações podem ser executadas no desenvolvimento e em produção para acompanhar mudanças de qualidade.

Capítulos

Início	Capítulo	Resumo
00:00	Ciclo de vida do agente	A demonstração percorre as etapas de indexação, construção em código, rastreamento, registro, avaliação e implantação.
02:06	Inspeção de traces	A apresentadora examina uma solicitação e mostra como o trace revela as etapas, métricas e respostas do agente.
04:09	Avaliação em lote	Uma avaliação compara relevância, segurança e aderência ao catálogo em várias perguntas.
06:18	Monitoramento em produção	As mesmas avaliações usadas no desenvolvimento podem acompanhar o comportamento do agente em produção.

Citações

Manter o agente em código, em vez de montá-lo clicando, é o que o torna revisável, versionável e implantável depois. — 00:33

Assim você vê o que o agente fez, etapa por etapa, em vez de tentar decifrar logs e adivinhar. — 02:37

Relevância verifica se a resposta corresponde à pergunta. E corresponde: Paris é a resposta perfeitamente correta. — 05:45

Essa diferença não é um bug; é a avaliação mostrando seu valor. — 06:18

Essa é a diferença entre esperar que o agente se comporte bem e saber que ele se comporta. — 06:18

Conceitos e entidades

Databricks (empresa): Plataforma usada na demonstração para criar, avaliar e implantar agentes.
Agent Bricks (ferramenta): Nome da demonstração sobre a construção de agentes prontos para produção no Databricks.
Unity Catalog (ferramenta): Sistema de governança usado para controlar o índice e registrar o agente como um artefato versionado.
Delta table (conceito): Tabela sobre a qual é criado um índice de busca vetorial que acompanha as alterações nos dados.
MLflow (ferramenta): Ferramenta usada para rastrear solicitações e executar avaliações do agente.
mlflow.genai.evaluate (ferramenta): Função usada para executar avaliações em um conjunto de perguntas.
índice de busca vetorial (conceito): Índice criado sobre uma Delta table com embeddings gerenciados para recuperar informações.
agent as code (conceito): Padrão de manter a implementação do agente em código para facilitar revisão, versionamento e implantação.

Tradução completa (pt-BR)

00:00 [música] >> Então, na etapa um, criamos um índice de busca vetorial sobre uma tabela Delta com embeddings gerenciados. E “gerenciados” é a palavra-chave aqui, porque você não precisa configurar um serviço de embedding separado, e o próprio índice se mantém sincronizado com a tabela conforme os dados mudam. E, como todo o resto, ele é governado pelo Unity Catalog.

00:33 Na etapa dois, carregamos o agent de um arquivo usando o padrão agent as code e fazemos uma consulta. Manter o agent no código, em vez de montá-lo clicando, é o que permite revisá-lo, versioná-lo e implantá-lo mais tarde. A etapa três é o rastreamento do MLflow, que registra exatamente o que aconteceu em cada solicitação. Isso inclui a recuperação, as chamadas às ferramentas

01:04 a latência e os tokens. Na etapa quatro, registramos o agent no Unity Catalog como um único artefato de versão governado, que é uma única fonte de verdade sobre o que está implantado. Na etapa cinco, avaliamos com o MLflow. E, na etapa seis, implantamos em um endpoint em tempo real com um app de revisão, para que as pessoas possam dar feedback.

01:35 Então, indexamos, criamos, rastreamos, registramos, avaliamos e implantamos. É fácil de falar, né? Esse é o ciclo de vida inteiro, e ele segue o mesmo formato, quer você esteja criando um protótipo para o fim de semana, quer algo que atenda tráfego real. Vou mostrar dois momentos do ciclo que são muito importantes. Vamos até aqui: este é um dos nossos experimentos, e estamos olhando para os

02:06 rastros do nosso agent. Este seria o rastro de uma única solicitação. À esquerda, dá para ver a execução do agent organizada passo a passo. Temos a etapa de recuperação e, depois, a chamada ao modelo de linguagem. Aqui, temos a latência, a contagem de tokens e até o custo por solicitação. E é assim que você consegue ver o que

02:37 seu agent fez, trecho por trecho, em vez de apertar os olhos para os logs e ficar tentando adivinhar. Escolhi este exemplo de propósito. No exemplo do laboratório, vamos usar um banco de dados do catálogo de produtos da Databricks. Mas a pergunta aqui é: qual é a capital da França? O que, sem dúvida, não tem nada a ver com o catálogo de produtos da Databricks.

03:08 Mas, se você observar o que o agent fez, ele respondeu com honestidade: a capital da França é Paris. Depois, porém, voltou ao assunto para o qual foi realmente criado. O rastro mostra a recuperação que foi executada e como o modelo respondeu. E podemos ver que tudo levou cerca de 5 segundos. Isso vai ser muito útil quando algo der errado.

03:39 E, quando algo quebrar em produção — prometo que vai acontecer —, este é o primeiro lugar onde você deve olhar. Houve inúmeras vezes em que o agent de um cliente quebrou, e o rastro conseguiu mostrar em menos de 10 segundos que a recuperação estava correta e que o problema era o prompt, ou o contrário. Mas, sabe, não é

04:09 tudo conseguir ver um único rastro. Você precisa saber que o agent é bom, não apenas que foi executado sem gerar um erro em uma instância. É aqui que usamos mlflow.genai.evaluate. É onde executamos um conjunto de avaliações em várias perguntas de uma só vez. Esta é uma execução de avaliação para um conjunto

04:42 de perguntas, e temos três tipos de avaliações. Temos relevância para a consulta do usuário e segurança, e ambas estão em 100%. Até aqui, tudo bem. Mas temos esta terceira métrica aqui, chamada “permanece no catálogo”. Basicamente, criei essa métrica em linguagem simples, e tudo o que pergunto é: o agent

05:15 permanece no nosso catálogo de produtos ou se desvia do assunto? Essa métrica está em 80%. Ela falhou em uma pergunta: a que pede a capital da França. Então, talvez você esteja pensando: como ela pode estar marcada como relevante, mas o guardrail diz que ela se desviou do assunto? É porque estão medindo

05:45 duas coisas diferentes. A relevância verifica se a resposta corresponde à pergunta. E corresponde. Paris é a resposta perfeitamente correta. E quanto à segurança: foi prejudicial? Não. Não contém nenhuma linguagem problemática. Mas, se formos até a métrica do catálogo, podemos ver que ela sinaliza corretamente

06:18 que a pergunta está fora do catálogo. Então, embora a resposta tenha sido perfeitamente segura e perfeitamente relevante, essa diferença não é um bug: é a avaliação mostrando seu valor. Essa é a diferença entre torcer para que seu agent se comporte bem e saber que ele se comporta bem. E o melhor é que exatamente as mesmas

06:49 avaliações que estou executando aqui no desenvolvimento também são executadas em produção. Então, ao configurar qualquer monitoramento, você pode definir o padrão desde o primeiro dia e acompanhar se ele não cai silenciosamente assim que você faz o deploy. >> [música]

Transcrição original

[00:00] [music] >> So step one, we create a vector search index over a Delta table with managed embeddings. And managed is the keyword here because you don’t have to set up a separate embedding service and the index itself keeps in sync with the table as the data as the data changes. And like everything else, it’s governed by Unity Catalog.

[00:33] Step two, we load the agent from a file using the agent as code pattern and we query it. Keeping the agent in code rather than clicking it together is what makes it reviewable, versionable, and deployable later. Step three is MLflow tracing, which captures exactly what happened on every request. So this includes the retrieval, the tool

[01:04] calls, the latency, and the tokens. Step four, we register the agent to Unity Catalog as one governed version artifact, which is a single source of truth for what’s deployed. Step five, we evaluate it with MLflow. And step six, we deploy it to a real-time endpoint with a review app so humans can give it feedback.

[01:35] So we index, build, trace, register, evaluate, deploy. Rolls off the tongue, right? That’s the whole life cycle and it’s the same shape whether you’re building a weekend prototype or something that serves real traffic. So I’ll show you two moments in the loop that are super important. So, going over here, this is one of our experiments and we are looking at the

[02:06] traces of our agent. So, this would be the trace of a single request. On the left, you can see the agent’s execution laid out step-by-step. So, we have the retrieval step and then the call to the language model. Here, we have the latency, the token count, and even the cost per request. And then, this is how you can see what

[02:37] your agent did span by span instead of squinting at logs and guessing. So, I chose this example on purpose. So, with the lab example, we’ll be um using a database of the Databricks product catalog. Um but the question over here is what is the capital of France? Which arguably has no nothing to do with Databricks product product catalog.

[03:08] But if you see what the agent did, it answered honestly, so saying capital of France is Paris. But then, it steers back to what it’s actually for. And the trace shows you the retrieval that ran and how the model responded. Um and we can see that the whole thing took about 5 seconds. So, this is what is going to be super helpful for when something goes wrong.

[03:39] Um and when something breaks in production, I promise you it will. This is the first place that you want to look. Um you know, there have been countless times where um a customer’s agent has broken and then the trace can show you in less than 10 seconds, um, that the retrieval was fine and it was a problem with the prompt or the other way around. But, you know, it’s not

[04:09] uh, everything to be able to see a single trace. Um, you need to know that the agent was good and not that it ran without throwing an error for one instance. Um, so this is where we go to mlflow.genai.evaluate. Um, and this is where we are running a set of scores across a whole bunch of questions at once. So, this is one evaluation run for a set

[04:42] of questions and we are having three types of assessments. So, we have relevance to the user’s query, safety, and both of these come at 100%. So, so far that’s healthy. But then, we have this third metric over here, which is, uh, called stays on catalog. Um, and basically this is one that I created in plain English and all I’m asking is, does the agent

[05:15] stay on our product catalog or does it wander off topic? And this one is coming back at 80%. Um, and it failed at one question. Um, so this would be the one that’s asking for the capital of France. Um, so you might be thinking, uh, you know, how can we have, uh, this checked as relevance, um, but then saying that the guardrail wondered off? Um, and it’s because they’re measuring

[05:45] two different things. So, relevance is checking for whether the answer matches the question. Um and it does. Paris is the perfectly correct answer. Um and safety, was it harmful? Um no. Uh this is not containing any um problematic language. Uh but then if we go on say some catalog, uh we can um see that it correctly flags

[06:18] that the question is going off catalog. Um so, even though that the answer was perfectly safe and perfectly relevant. So, this gap over here is not a bug um and that’s the evaluation earning its keep. So, this is the difference between hoping your agent behaves and then knowing it does. And the best part is that the exact same

[06:49] scores I’m running here in development uh also run in production. So, um when you’re doing any monitoring, you can set the bar on day one and be able to track that it doesn’t quietly drop the moment you ship. >> [music]