Sua aplicação de LLM retornou 200 OK. Mesmo assim, estava errada. — Marina Petzel, Datadog

Autoria: AI Engineer · 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: Your LLM App Returned 200 OK. It Was Still Wrong. — Marina Petzel, Datadog · Canal: AI Engineer · 17:57 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Inferência e otimização de modelos, RAG, busca e recuperação de informação, Segurança de IA

Resumo

Marina Petzel explica por que as métricas tradicionais — latência, erros, tráfego e saturação — não bastam para monitorar aplicações de IA generativa. Ela recomenda acompanhar custos variáveis, segurança e qualidade, com métricas específicas para cada dimensão. Entre as práticas sugeridas estão atribuir custos por funcionalidade, usuário, modelo e endpoint; detectar riscos de segurança; e avaliar relevância, alucinações, satisfação e qualidade do RAG. A palestra conclui que essas métricas devem complementar os sinais tradicionais para oferecer uma visão mais completa da saúde da aplicação.

Pontos-chave

A mesma entrada pode produzir respostas diferentes em aplicações de IA generativa, então testes de regressão tradicionais não bastam; é preciso avaliar a qualidade continuamente em produção.
O custo varia conforme o número de tokens, o modelo utilizado e o tamanho do context window.
Acompanhe o crescimento do uso de tokens, mudanças de modelo e chamadas repetidas sem cache, que podem elevar os custos.
Atribua custos por funcionalidade, usuário, modelo e endpoint para identificar onde o orçamento está sendo consumido.
Monitore riscos de segurança como prompt injection, exposição de informações pessoais, conteúdo tóxico e tentativas de jailbreak.
Um retorno 200 OK não garante que a resposta seja correta ou útil; monitore alucinações, relevância, satisfação e completude.
Para aplicações com RAG, avalie se os documentos recuperados são relevantes para a consulta.
Mantenha as métricas tradicionais de latência, erros, tráfego e saturação, acrescentando métricas de custo, segurança e qualidade.

Capítulos

Início	Capítulo	Resumo
00:01	Por que as métricas tradicionais não bastam	A palestra apresenta as diferenças entre aplicações tradicionais e generativas, destacando a necessidade de avaliar qualidade, custo e segurança.
03:42	Monitoramento de custos	A palestrante explica como o crescimento do uso de tokens, as mudanças de modelo e a falta de cache podem aumentar os gastos.
06:55	Atribuição granular de custos	Atribuir gastos a funcionalidades, usuários, modelos e endpoints ajuda a identificar onde o orçamento está sendo consumido.
09:34	Métricas de segurança	A palestra recomenda monitorar prompt injection, exposição de PII, conteúdo nocivo e tentativas de jailbreak.
12:10	Métricas de qualidade	A palestrante aborda a avaliação de alucinações, relevância, satisfação, completude e qualidade da recuperação no RAG.
15:47	Resumo e observabilidade para aplicações de IA	As métricas de custo, segurança e qualidade devem complementar os sinais tradicionais, e a palestrante apresenta o Agent Observability da Datadog.

Citações

Uma resposta 200 OK do seu servidor não significa necessariamente que a resposta foi útil ou correta para o usuário final. — 03:09

Às vezes, 70% dos gastos são redundantes porque o sistema paga repetidamente pela mesma resposta cara do modelo. — 06:22

Idealmente, devemos bloquear 100% dessas tentativas. — 11:39

Não estamos dizendo que devemos abandonar o entendimento tradicional. — 15:47

Conceitos e entidades

Marina Petzel (pessoa): Palestrante que apresenta métricas para monitorar aplicações de IA generativa.
Datadog (empresa): Empresa em que Marina Petzel trabalha como defensora de IA generativa e que oferece observabilidade para aplicações de IA.
Agent Observability (ferramenta): Produto da Datadog apresentado como recurso para monitorar a saúde de aplicações de IA.
golden signals (conceito): Conjunto de métricas tradicionais de latência, erros, tráfego e saturação usado para acompanhar a saúde de aplicações.
atribuição de custos (conceito): Prática de associar gastos a funcionalidades, usuários, modelos e endpoints para identificar sua origem.
prompt injection (conceito): Tentativa de manipular o comportamento de uma aplicação por meio de instruções maliciosas em prompts.
PII (conceito): Informações pessoais identificáveis que devem ser detectadas e protegidas nas saídas do modelo.
alucinação (conceito): Resposta que apresenta afirmações não sustentadas pelos dados usados como referência.
RAG (conceito): Abordagem que recupera documentos para apoiar a geração de respostas e cuja qualidade de recuperação deve ser monitorada.
LLM as a judge (conceito): Uso de um LLM para avaliar se uma resposta atende de forma completa à intenção do usuário.

Tradução completa (pt-BR)

00:01 [música] >> Olá a todos. Obrigada por se juntarem a mim hoje. Está na hora de começar. Durante anos, muitos de nós monitoramos nossas aplicações com os sinais de ouro: latência, erros, tráfego e saturação. E, em pouco tempo, passamos a chamá-los de

00:31 LADs. Eles eram, ainda são e continuarão sendo suficientes e essenciais para determinar a saúde das nossas aplicações. No entanto, agora que entramos na nova era da IA generativa, eles já não são suficientes. Hoje vamos falar sobre quais são as novas métricas que precisamos observar se quisermos criar uma aplicação de IA generativa saudável. Para me apresentar brevemente, meu nome é Marina Petzel. Sou defensora da IA generativa aqui na DataDog.

01:03 E hoje vou apresentar as métricas que precisamos observar. Quando falamos de aplicações tradicionais, a principal característica delas é que a mesma entrada sempre produz a mesma saída, certo? É previsível. Mas, como todos sabemos, com aplicações de IA generativa, o mesmo prompt pode gerar respostas diferentes sempre que o executamos. Isso significa que não podemos depender apenas dos testes de regressão padrão.

01:33 E é preciso avaliar constantemente a qualidade no ambiente de produção. A segunda diferença entre aplicações tradicionais e aplicações de IA generativa é a estrutura de custos variável. Os custos de computação tradicionais são previsíveis, certo? Pagamos pela máquina que executa nosso código. Mas, para IA generativa, isso varia dinamicamente. Os custos podem variar de acordo com o número de tokens, o modelo que estamos usando ou o tamanho da context window que você

02:05 tem. Tornou-se essencial fazer um acompanhamento granular dos custos em tempo real para evitar que os gastos saiam do controle. O terceiro problema é que enfrentamos novos vetores de ataque. Antes, nos preocupávamos com injeção de SQL ou cross-site scripting, mas hoje precisamos nos defender contra prompt injection, jailbreaks ou vazamento de PII nas nossas saídas. Isso está se tornando um grande problema, e são questões de segurança,

02:38 não um simples código de erro 500, que nunca vai detectar isso, e exigem formas inteiramente novas de monitoramento de segurança. E, por fim, a qualidade é muito subjetiva em aplicações de IA generativa. Os sistemas tradicionais funcionam ou não funcionam, certo? Mas as saídas de IA generativa são avaliadas em um espectro. São relevantes? São precisas? Estão completas ou não? E o problema é que uma resposta 200 OK do

03:09 seu servidor não significa necessariamente que a resposta foi útil ou correta para o usuário final. Agora precisamos integrar a avaliação contínua da qualidade diretamente à nossa pilha de monitoramento. No início, todos achávamos que esses sinais de ouro seriam suficientes para nossos sistemas, mas, infelizmente, não são. As métricas tradicionais vão dizer se o sistema está funcionando, mas não vão dizer quão bem ele está

03:42 funcionando. E as métricas já estabelecidas continuarão sendo essenciais, mas vamos falar sobre o que mais precisamos implementar nos nossos sistemas, além delas. Primeiro, quero começar pelo monitoramento de custos. Como podemos acompanhar os gastos antes que eles saiam do controle? Acho que todos conhecemos as implicações financeiras da IA generativa, e muitas empresas estão enfrentando um enorme aumento nos

04:13 custos mensais de uso. Embora o mesmo também aconteça com aplicações tradicionais, havia uma relação mais linear entre a capacidade de processamento e o custo. Se a carga de usuários aumenta, o uso dos nossos recursos aumenta e, consequentemente, o custo também. Mas a estrutura de custos de um LLM é altamente dinâmica e imprevisível, o que significa que não temos essa visibilidade e precisamos prestar

04:47 atenção a como acompanhamos isso. E quais problemas de custo vocês podem encontrar? Aqui, falamos das três principais formas de acompanhar os custos, para que vocês possam monitorá-los e evitar que eles saiam do controle. A primeira é o aumento gradual do uso de tokens. Isso acontece quando engenheiros ou gerentes de produto tentam melhorar a qualidade aumentando discretamente a context window. Digamos que a context window fosse

05:18 de 4.000 tokens e depois aumentasse de repente para 132, sem nenhuma análise financeira. E o custo depende muito da quantidade de tokens no contexto, o que pode resultar em um aumento de até oito vezes. Em um mês, isso pode custar milhares de dólares. O segundo problema é a mudança de modelo. Esse também é um problema bastante comum: a equipe troca um modelo mais barato e rápido, como o Hi Cool 4.5, por

05:50 um modelo mais poderoso e caro, como o Opus 4.8. E, é claro, isso promete uma qualidade melhor. Mas, ao mesmo tempo, por exemplo, o Opus pode custar 15 vezes mais por solicitação. Essa mudança de modelo, mesmo com o mesmo volume de uso, também pode elevar significativamente seus custos em um mês. E, por fim, há o código hash. Em IA generativa, a mesma consulta pode chamar

06:22 a API repetidamente se você não tiver implementado uma camada de cache eficaz. E o que vocês verão na nossa própria pesquisa é que, às vezes, 70% dos gastos são redundantes, porque o sistema paga exatamente pela mesma resposta gerada por um modelo caro repetidas vezes. Com essa visibilidade granular dessas três camadas, vocês conseguiriam identificar rapidamente aumentos nos custos. E agora,

06:55 vamos falar sobre como evitar isso e obter dados mais granulares. Quando falamos disso, tentamos pensar na implementação de uma estratégia de atribuição de custos, na qual é preciso marcar absolutamente tudo. Por exemplo, as marcações podem ajudar vocês a entender por que isso é importante, certo? Vocês recebem muitas interações com seus agents, mas todas essas

07:26 interações não são diferenciadas. Vocês não sabem o que está elevando seus custos. Por isso, a primeira camada que podem implementar é a camada de funcionalidades. Ao marcar a intenção da funcionalidade, como chat ou resumo, vocês podem atribuir o custo às áreas específicas do produto. Esses dados são essenciais não só para os engenheiros gerenciarem os custos, mas também para decisões sobre o roadmap do produto, como saber quais funcionalidades são as que mais consomem o orçamento.

07:58 O segundo nível é o nível do usuário. Usar marcações como o ID do usuário ou o nome da organização é essencial para repasses de custos e cobranças precisas, mas também para identificar rapidamente padrões de uso abusivo antes que esgotem seu orçamento. O terceiro é o nível do modelo. Marquem também seus modelos, como GPT-5.5, ou o provedor, OpenAI ou Tropic. Isso dará visibilidade às

08:29 principais áreas de otimização de custos. E vocês podem comparar os custos reais de usar um modelo em vez de outro. Por fim, há a marcação no nível do endpoint. Atribuir custos a regiões ou a ambientes, como produção ou homologação, ajuda no planejamento da infraestrutura. Vocês podem ver como a distribuição regional ou o ambiente de homologação em comparação com o de produção afetam os gastos totais. E, ao tornar essa

09:01 marcação uma prática obrigatória, vocês obtêm a visibilidade essencial para entender exatamente para onde seu dinheiro está indo e como é importante controlá-lo. Agora, vamos falar sobre o que acontece se, digamos, imaginarmos que resolvemos todos os problemas de custo, certo? Colocamos os custos sob controle. A equipe financeira fica, obviamente, muito feliz, mas o próximo problema é a segurança. E sua IA pode

09:34 ser barata, mas ainda assim vazar informações confidenciais ou pessoais, o que não é bom. E, mesmo que as pontuações do seu LLM como juiz sejam perfeitas, isso não pode dizer se alguma métrica deu errado. Então, o que podemos acompanhar nas métricas de segurança? Primeiro, a taxa de prompt injection, que se tornou um problema muito importante. Essa métrica detecta tentativas de manipular os prompts dos usuários.

10:04 Isso é um problema de infraestrutura se o projeto da infraestrutura não tiver nenhuma proteção. Isso pode ser evitado com técnicas avançadas, como correspondência de padrões ou modelos classificadores especializados. Para isso, geralmente precisamos definir limites bastante rigorosos. A segunda é a taxa de detecção de PII. PII é uma questão crucial e de tolerância zero aqui.

10:37 Podemos verificar todas as saídas do modelo em busca de dados confidenciais, como números de previdência social, números de cartão de crédito ou informações pessoais. Vocês podem usar métodos como expressões regulares ou reconhecimento de entidades nomeadas. E a única meta aceitável deve ser 0% das saídas em produção. A terceira é a pontuação de moderação de conteúdo. Como vocês podem determinar se o conteúdo é

11:08 tóxicos, nocivos ou tendenciosos em relação a alguns dos tópicos. E, ao passar todas as saídas por um classificador de toxicidade, você pode obter pontuações que indicam o risco de a sua saída expor conteúdo tóxico. Isso permite definir limites claros, e nosso objetivo é sempre minimizar esse risco tanto quanto possível. E, por fim,

11:39 as tentativas de jailbreak. Os usuários tentam persistentemente contornar as barreiras de segurança, muitas vezes por meio de cenários elaborados. E o acompanhamento de padrões que indiquem tentativas de substituir o system prompt deve ser projetado para se tornar um bloqueio absoluto. Idealmente, deveríamos bloquear 100% dessas tentativas.

12:10 Agora, vamos imaginar que o custo foi verificado, a segurança foi verificada, mas então chegamos à dimensão possivelmente mais crucial — e a mais crucial para os nossos usuários finais: o monitoramento da qualidade. E, embora suas métricas mostrem que o serviço está ativo e funcionando, e que os custos e a segurança indicam que ele está dentro do orçamento e

12:40 também é seguro, no fim das contas, para qualquer aplicação — mas ainda mais para uma aplicação generativa — o que importa é se a saída é boa. Mas todos sabemos que uma resposta 200 OK do seu servidor às vezes pode ser uma mentira, se a resposta for uma alucinação. Tenho certeza de que muitos de vocês já receberam respostas de aplicações modernas de IA, certo? Mas, como sabemos, elas podem responder com confiança e mentir para vocês.

13:10 Agora, vamos entender que tipo de métricas vocês podem aplicar à sua aplicação neste momento para evitar que ela seja insegura para o usuário final. Recomendamos focar nestas cinco métricas. Uma delas é a taxa de alucinação. Ela mede a porcentagem de respostas que contêm afirmações não sustentadas pelos dados usados como base. Precisamos combinar isso com a revisão manual e também com verificações automatizadas de fatos

13:41 para alcançar metas ambiciosas também nesse aspecto. A próxima métrica são as pontuações de relevância, que ajudam a entender se a resposta realmente aborda a pergunta do usuário. Uma técnica que vocês podem usar aqui é a similaridade, usando BERT ou a similaridade de embeddings, que pode pontuar o quanto a resposta final foi relevante para o usuário. A próxima métrica é a satisfação do usuário,

14:13 que depende diretamente do usuário final. Vocês podem implementar mecanismos como os botões de gostei e não gostei ou uma classificação por estrelas, além de pontuações de NPS, para coletar dados subjetivos. Mas também devem buscar obter pelo menos mais de 80% a 85% de feedback positivo. A próxima métrica é a completude da resposta, e ela costuma ser avaliada por um LLM as a judge,

14:45 que determina se a resposta abordou por completo, ou de forma abrangente, a intenção do usuário. E a última, a quinta métrica: se vocês usam RAG, ou geração aumentada por recuperação, devem sempre acompanhar a qualidade do RAG. Todos os documentos recuperados eram relevantes para a consulta do usuário? Há muitas métricas e mecanismos para calcular isso. Por exemplo, a acurácia no top K ou

15:17 o ganho descontado normalizado. É essencial acompanhar isso porque, quando o contexto explode, fica cada vez mais difícil selecionar os itens mais relevantes. Ao implementar essas métricas, vocês podem compreender a qualidade de forma mais multidimensional e identificar o que precisam otimizar para melhorar a jornada da sua aplicação. Bem, agora vamos resumir

15:47 o que precisamos implementar para garantir que nossa aplicação generativa esteja saudável, certo? Não estamos dizendo que devemos abandonar o entendimento tradicional. Sempre precisamos analisar nossas métricas de latência, erros, tráfego e saturação. Mas, além disso, precisamos acrescentar outra camada, mais relevante para aplicações generativas. Neste caso, falamos sobre custo, segurança e qualidade.

16:18 E sei que, para nós, engenheiros, está ficando cada vez mais importante acompanhar tudo isso. Já não basta apenas criar a aplicação e garantir que ela esteja funcionando em produção; agora também precisamos lidar com uma camada adicional de complexidade. Felizmente, a Datadog pode ajudar nisso, pois trabalhamos há muito tempo com observabilidade e monitoramento. Temos o produto de observabilidade de agents, que permite entender rapidamente

16:51 e com facilidade se a sua aplicação de IA está saudável, se está funcionando ou se há algum problema que vocês precisam corrigir. Também há muitas coisas diferentes que vocês podem acompanhar com ele. Se quiserem saber mais, fiquem à vontade para falar comigo depois. Também temos um estande aqui, que vocês podem visitar. Temos ótimas ofertas para vocês, caso queiram simplesmente experimentar

17:22 e ver como a observabilidade de agents pode ajudar a sua aplicação. Temos alguns QR codes para os testes gratuitos. Com isso, quero agradecer a todos. Mais uma vez, meu nome é Marina Betzel. Se quiserem entrar em contato comigo, fiquem à vontade para usar este QR code. E, sim, obrigada por estarem aqui hoje.

17:57 >> [música]

Transcrição original

[00:01] [music] >> Hello everyone. Thank you for joining me today. It’s time to begin. And for years, many of us monitored our applications with the golden signals, which is was latency, error, traffic, and saturation. And shortly we call them

[00:31] lads. And they were and still they are and will be remain sufficient and critical for determine the health of our applications. However, today when we enter the new era era of generative AI, it’s becoming not enough. And today we going to talk about what are the new metrics we need to look if we want to build the healthy gen AI application. Very shortly, my name is Marina Petzel. I am gen AI advocate here in DataDog.

[01:03] And today I will walk you through the metrics that we need to look for. So, when we talk about traditional applications, the main specific of them is that the same input always yield the same output, right? It’s predictable. But with generative AI applications, we all know that the same prompt can generate different responses every time we run it. And which means we cannot rely on the standard regression testing alone.

[01:33] And you must constantly evaluate quality in the live environment. The second difference between traditional applications and gen AI applications, it’s variable cost structure. Traditional compute cost are predictable, right? We pay for machine that is running our code. But for gen AI, this this is dynamic variable here. They might They vary from the number of tokens, the model that we are using, or the size of the context window that you

[02:05] have. And it’s become essential to do the real-time granular course cost to prevent the spending out of control. The third problem is that we face the new attack vectors. We used to worry about SQL injection or cross-site scripting before, but today we must defend against the prompt injection, jailbreaking, or PII outage in our output. And that’s becoming a big problem, and this are security issue,

[02:38] not a simple 500 error code can will never catch, and demanded entirely new forms of security monitoring. And finally, quality is very subjective for GenAI applications. The traditional systems either work or do not work, right? But generative AI output is judged on the spectrum. Is it relevant? Is it accurate? Is it complete or not? And the problem is that 200 okay response from

[03:09] your server doesn’t necessarily mean that the answer was helpful or correct for your final user. And we must now integrate the continuous quality evaluation directly in your monitoring stack. And at the beginning we all were thinking that these golden signals will be enough for our systems, but unfortunately they are not. Traditional metrics will tell you if your system is up and running, but it won’t tell you how well it’s

[03:42] running. And established metrics lets will be still essential, but we going to talk about what else on addition to that we need to implement into our systems? And first I want to start with the cost monitoring. How we can track the spending before it uh spirals out of control? And I think we all know the financial implications of GenAI, and a lot of companies are facing the huge outage of

[04:13] the uh cost per their monthly usage. And while the same is true as for traditional applications, there were more linear scale between the throughput and the uh the cost. If the user loads um load goes up, our resources uh usage goes up, and sequentially the cost goes up. But the cost structure for LLM is highly dynamic and unpredictable, which means we can we don’t have this visibility, and we need to really pay

[04:47] attention how we track that. And what are the problems you might encounter with the cost? And here we talk about the three major way for cost tracking, uh and so you can track them um to prevent the cost outage. So, the first is a token creep. Uh this happens when engineers or product managers trying to improve the quality quietly increasing the context window. And let’s say the context window was

[05:18] 4,000 tokens, and then it’s like blow to 132 without any financial review. And what it can cost like the the cost is depends very uh significantly to the context count, and that might result up to eight x cost increased. And and a month it might cost you thousands of dollars. Second is the model drift. Uh that is also the pretty typical problem when the team switches from cheaper and faster model, like let’s say Hi Cool 4.5, to

[05:50] the more powerful and more expensive model, like Opus 4.8. And which promise you obviously the better quality. But at the same time, Opus, for example, uh can be higher 15 times higher uh per the cost request. And this change in model, even with the same usage volume, might blow your cost significantly within a month, too. And finally, it’s on hash code. In generative AI, the same query can hit

[06:22] the API repeatedly if you haven’t implemented the effective caching layer. And what you will see from um our uh own research that 70% of the spend sometimes are redundant because the system is paying for exactly the same expensive model completion uh over and over again. And with this granular visibility into these three layers, you would be able to escalate your cost rapidly. And now,

[06:55] let’s talk about how you can prevent that and get more granular data. And when we um talk about that, we uh try to think about the implementation of cost attribution strategy, which is you must tag absolutely everything. For example, uh tagging uh can help you to uh Why it’s important, right? You receive a lot of uh interactions with your agents, and but all of these uh

[07:26] interactions are undifferentiated. You don’t know what’s blow your actual cost. That is why first layer what you can implement is the feature level level. By tagging the intention of the feature, like it was a chat or summarization, you can attribute the cost for the specific product areas. And this data is crucial not only for engineering your cost management, but also for the product road map decisions, like knowing which features are actually the budget hawks.

[07:58] The second level is the use user level. Using the tags like the user ID or your org name is essential for chargebacks, accurate billing, but also quickly identify by the patterns of abusive usage before they drain your budget. Third is the model level. Also tag your models like GPT-5.5 or the provider, OpenAI or Tropic. It will give you visibility into the

[08:29] high-level areas of cost optimization. And you can benchmark the true expenses of using one model versus another. And the finally, endpoint level tagging. Attributing cost to regions or to your production or like to your environment like production or staging helps your infrastructure planning. And you can see how regional distribution or staging versus production environment can impact your total spend. And by making this

[09:01] tagging mandatory practice, you gain the essential visibility to understand exactly where your money is going and how important to control it. Well, but now let’s talk if like let’s let’s imagine that we handle all the cost issues, right? We took that under control. And your finance team is obviously get very happy, but the next one problem is the safety. And your AI can

[09:34] be cheap, but still leak some of the sensitive or personal information, which is not great. And even though like your let scores can be perfect, it cannot tell you if there are some metrics went wrong. So, what we can track here in the safety metrics to First is the prompt injection rate, which has become the very crucial problem. This metrics detects the manipulation attempts into your user

[10:04] prompts. There are It’s infrastructure If the infrastructure design doesn’t have any guardrails. And this can be um prevent by using some advanced techniques like a pattern matching or specialized classifier models. And for this, we usually need to target for very aggressive thresholds. The second is PII detection rate. Um PII So, which is a crucial and zero

[10:37] tolerance issue here. We can scan all the model outputs for sensitive data like social security, like credit cards, or personal information. And you can use some um methods like regex or named entity recognition here. And only acceptable target should be 0% of your production outputs. The third is the content moderation score. How you can determine if your content is

[11:08] toxic, harmful, or biased uh towards some of the topics. And by running all outputs through toxicity classifier can give give you a scores uh how what is the risk of your output for being exposed to this uh toxic uh output. And this allows you to set some clear thresholds, and we always target to uh minimize that as much as we can. And then finally,

[11:39] the jailbreak attempts. And there are persistent attempts by users to bypass the safety guardrails and often um through the elaborate scenarios. And tracking tracking patterns to indicate the system prompt overrides, you should design and become so it become the absolute blocker for you. So, ideally, we should block all the 100% of the attempts of that.

[12:10] Now, let’s imagine that cost is checked, security is checked, but now you arrive to arguably the most crucial dimension and the quality monitor that at least the most crucial for our final users. And even though your let’s metrics showing that your service is up and running and running, your cost and safety tells you that your service is budget compliant and

[12:40] also secure, but ultimately for any application, but more for generative application, it’s whenever output is good. But we all know that 200 okay response from your server sometimes can be a lie if the answer is hallucination. And I’m sure many of you got some response from modern AI applications, right? But like we know that it’s can confidently by like but lie to you.

[13:10] And now let’s understand what type of metrics you can apply implement to your application right now to prevent it from being unsafe for your final user. We recommend to focus on these five metrics. One of them is hallucination rate. Um, this measures the percentage of respondent contain claims unsupported by the grounded data. Um, we need to mix that with the manual review as well as with automated fact

[13:41] checks to achieve the aggressive targets here, too. The final The next one is the relevance scores, which helps you to understand if the response actually address the user question. Um, that techniques like that you can use here is similarity using bird or embedding similarity that can score you um, how relevant is the final answer was to the user. The next one is user satisfaction,

[14:13] which directly falls into your end user. Uh, you must implement You can implement some mechanisms like thumbs up, thumbs down, or some of the stars ranking, and also NPS scores um, to capture the subjective data, but also you should target that you get more than 80 85% of the positive feedback, at least. Next one is the answer completeness, and this metric is often evaluated by LLM as

[14:45] a judge, answering whenever the response was fully or holistically addressed um, the user intent. Um, and final one, the fifth one, um, if you are using rag, retrieval augmented generation system, you should always track the quality of your rag. What’s if all the documents that were fetched were relevant to the user query? And here you have a lot of metrics and mechanisms how you can calculate that. For example, top K accuracy or

[15:17] normalized discounted gains, and that is uh, essential to track because whenever like you contacts is explode is getting harder and harder to pick the most relevant one. And by implementing this metrics, you can gain some understanding of like more dimensional view of the quality that necessary you need to optimize to improve your journey application. Well, and now let’s summarize um

[15:47] what we need to implement to make sure that our journey application is healthy, right? We are not saying that we need to get rid of traditional understanding. We always need to look into our metrics, lay let’s latency error traffic and saturation, but also on top of that, we need to put another layer. Layer of which is more relevant to generative applications. And in this case, we talked about the cost, safety, and also quality.

[16:18] And I know that for us as an engineer is becoming more and more critical right now to track it all not be don’t need just build application and make sure that it’s running in production, but now we also need to care about additional layer of complexity. And thankfully, Datadog has your back here since we are working in observability and monitoring space for for really long time. So, we do have our agent observability uh product which allows you to quickly

[16:51] and easy understand if your AI application is healthy, if it’s running, or there is any problem that you need to fix. And we do have a lot of different way things that you can track inside of that. And um if you want to hear more about that, please feel free to see me afterwards. We also do have the booth here uh which you can check it out. We do have a really good um offers for you if you want to just try

[17:22] it out and see how agent observability can help your application. We have some QR codes for the free trials. And with that, I want to thank everyone. Again, my name is Marina Betzel. If you want to contact me, please feel free to use this QR code. And yeah, thank you for being here today.

[17:57] >> [music]