Your LLM App Returned 200 OK. It Was Still Wrong. — Marina Petzel, Datadog
Read the talk
Your LLM App Returned 200 OK. It Was Still Wrong.
Marina Petzel explains why latency, errors, traffic and saturation need company: cost attribution, safety checks and continuous quality evaluation reveal failures that a successful HTTP response cannot.
From a talk by Marina Petzel
At a glance
Ideas worth remembering
LATS remains essential for operational health, but successful requests also need live evaluation for cost, safety and answer quality.
Context growth, more expensive model choices and repeated uncached completions can raise spending without an increase in user traffic.
Tag interactions by feature, user or organization, model and provider, and deployment location or environment so costs can be traced to useful decisions.
Safety monitoring distinguishes manipulation attempts from unsafe outputs. Zero PII leakage and blocking every jailbreak are objectives, not evidence that detectors achieve perfect coverage.
Evaluate factual support, relevance, user satisfaction, completeness and RAG retrieval quality separately; each identifies a different way an answer can fail.
A healthy server can deliver an unhealthy answer
A generative AI application can return 200 OK while giving its user an irrelevant, incomplete or incorrect answer. The request succeeded at the server level; the response failed at the task level. Marina Petzel, introducing herself as a GenAI advocate at Datadog, starts with the familiar golden signals—latency, errors, traffic and saturation, or LATS—and asks what else production monitoring must measure to catch that difference.
The first change is variability. The same prompt can produce different responses across runs, so a successful regression test does not establish how every live response will behave. Regression testing still matters, but quality also needs continuous evaluation in the production environment. The system must be observed while it answers real questions, rather than treated as correct once a fixed set of examples passes.
Three other changes widen the monitoring problem:
- Variable cost: Token counts, model selection and context size affect spending. Request volume alone cannot explain the bill.
- New attack vectors: Prompt injection, jailbreaks and exposure of personally identifiable information can occur without producing a server error.
- Graded quality: Relevance, accuracy and completeness lie on a spectrum. A response can be technically delivered yet only partly useful.
These changes do not retire LATS. They add questions that LATS was never meant to answer: Is this response affordable? Is it safe? Does it help the user? Petzel develops those questions in that order, beginning with costs that can grow even when traffic looks ordinary.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Three ways spending grows without more users
In the simplified traditional-compute picture, more traffic requires more resources, and spending rises with resource use. LLM spending has additional moving parts inside each request. A product change can increase the amount of context, select a more expensive model or repeat work that could have been reused. Monitoring the total bill reveals the consequence; monitoring these drivers helps explain it.
Token creep begins with an apparently helpful quality change. Engineers or product managers expand the context supplied to the model without a financial review. Petzel’s example grows from 4,000 tokens to 32,000—eight times as much context—and warns of a potential eightfold cost increase, accumulating to thousands of dollars over a month. The useful comparison is between context actually sent and its cost: a larger permitted context window does not, by itself, establish that every request uses all of it.
Model drift, as used here, means a team switches from a cheaper, faster model to a more powerful, more expensive one. The motivation is better output quality, but the financial effect persists even at unchanged usage volume. Petzel illustrates this with a model that could cost fifteen times more per request. That multiplier is an example of the risk, not a verified price comparison: the decision to upgrade needs visibility into both the added expense and the quality benefit it is supposed to buy.
Uncached calls pay for the same expensive completion repeatedly. The same query reaches the API again because an effective caching layer is missing, so repeated demand becomes repeated model work. Petzel reports that, in Datadog’s own research, redundant work sometimes accounted for 70% of spending; the recording does not specify the workloads or measurement method, so that figure should not be read as an expected saving for every application. The mechanism to investigate is concrete: which repeated calls are generating a fresh bill instead of reusing an appropriate result?
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Tag requests so the bill can answer a question
A stream of undifferentiated agent interactions does not tell a team where its money went. Cost attribution adds identifying dimensions to those interactions so spending can be grouped by the product behavior, customer, model or deployment that produced it. Petzel’s deliberately broad instruction is to “tag absolutely everything”; the practical substance is four complementary views of the same spending.
- Feature level: Identify the intention of the interaction, such as chat or summarization. This assigns costs to product areas and gives roadmap discussions a financial basis: which features consume the budget?
- User or organization level: Attach a user ID or organization identifier. This supports chargebacks and accurate billing, while making unusually expensive or abusive usage easier to locate before it drains the budget.
- Model and provider level: Record which model and provider handled the work. This makes actual spending across alternatives comparable and helps locate expensive model choices.
- Endpoint and deployment level: Attribute costs to regions and environments such as production or staging. This reveals how deployment choices and nonproduction activity contribute to total spend.
Making tagging mandatory turns cost monitoring into a way to investigate decisions, rather than merely notice an overrun. Feature tags serve product planning; user tags serve billing and abuse investigation; model tags serve comparison; deployment tags serve infrastructure planning. But an inexpensive application can still expose sensitive information. Getting the finance team comfortable leaves the next problem untouched.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Measure attacks and unsafe output separately
Safety monitoring has to inspect the content and behavior that ordinary status codes miss. Good laboratory scores do not tell a team whether a live prompt is trying to manipulate the application or whether a delivered answer contains personal information. Petzel separates four signals, with different detection methods and different desired outcomes.
- Prompt injection rate: Detect manipulation attempts in user prompts. Pattern matching and specialized classifier models are suggested ways to recognize suspicious inputs. The monitoring question concerns attempted manipulation; guardrails must determine what the application does with a detected attempt.
- PII detection rate: Scan model outputs for sensitive information, including Social Security numbers, credit-card information and other personal data. Regular expressions can detect recognizable patterns, while named entity recognition can identify entities in text. Petzel sets a zero-tolerance objective: sensitive-data leakage should occur in 0% of production outputs.
- Content moderation score: Run outputs through a toxicity classifier to score the risk of toxic, harmful or biased content. A score allows the application to apply a threshold rather than rely on a binary server-success signal. The recommendation is to minimize unsafe content; the talk does not prescribe a single numerical cutoff for every application.
- Jailbreak attempts: Track persistent efforts to bypass safety guardrails, including elaborate scenarios intended to overwrite the system prompt. The intended response is blocking, with an ideal target of stopping 100% of attempts.
The zero-leakage and complete-blocking figures are safety objectives, not demonstrated detector performance. That distinction matters operationally: recognizing a suspicious prompt, finding sensitive text in an output and preventing its delivery are different jobs. A detected problem needs an enforcement response; merely counting it does not make the interaction safe.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Five questions a successful response still has to pass
Now suppose the service is running, spending is controlled and safety checks are in place. The user still needs a good answer. A confident hallucination can satisfy the server’s success conditions while failing the user completely. Quality monitoring therefore needs several measurements that distinguish factual support, relevance, satisfaction, completeness and the quality of retrieved context.
- Hallucination rate: Are the claims supported? Measure the percentage of responses containing claims unsupported by the grounding data. Petzel recommends combining manual review with automated fact checks. This evaluates the relationship between an answer and its evidence, rather than treating fluent or confident wording as a sign of correctness.
- Relevance score: Does the answer address the question? BERT-based similarity or embedding similarity can score the relationship between the user’s question and the response. This asks a different question from factual support: an answer may discuss the right subject yet contain unsupported claims, so a relevance score does not replace the hallucination check.
- User satisfaction: Did the user find it useful? Thumbs-up and thumbs-down controls, star ratings and NPS provide direct feedback on the experience. Petzel suggests aiming for more than 80–85% positive feedback. That is a recommended target for positive responses, not a measured result or an interchangeable interpretation of the NPS scale. User feedback supplies subjective information that content-based evaluation alone cannot capture.
- Answer completeness: Did it cover the full intent? An LLM-as-a-judge can assess whether the response fully addresses what the user wanted. Relevance checks whether the answer addresses the question; completeness asks whether it leaves important parts unanswered. Separating them makes a partially helpful answer easier to diagnose.
- RAG retrieval quality: Did the system fetch useful evidence? In retrieval-augmented generation, evaluation must also examine the documents fetched for the user’s query. Petzel names top-K accuracy and normalized discounted gain measures as options. These evaluate the retrieval side of the system, rather than only the final response. As the pool of context grows, selecting the most relevant material becomes harder; checking retrieved documents helps distinguish a context-selection problem from a problem in the answer produced from that context.
Together, these measurements make quality more diagnosable. Unsupported claims call for examining grounding; a poorly matched answer calls for examining relevance; missing coverage calls for examining completeness; unhelpful retrieved documents call for examining retrieval. User satisfaction adds the final user’s judgment. No one score answers all five questions.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep LATS and add the missing dimensions
The closing recommendation is additive: retain latency, errors, traffic and saturation, then monitor cost, safety and quality alongside them. These dimensions are complementary, not successive gates that can be checked once and forgotten. A running service can become too expensive; an affordable service can leak information; a safe service can still answer badly.
Petzel ends by presenting Datadog Agent Observability as a product for investigating AI application health and identifying problems to fix, with an invitation to try it. The LLM Observability documentation offers a practical next step for instrumenting that approach. The engineering responsibility established by the talk remains the same whichever tool carries it: production monitoring must evaluate what the application delivered, not stop at whether it delivered something.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Explains instrumentation, request traces and spans, operational monitoring, and evaluations for quality, privacy and safety—the implementation counterpart to the talk’s monitoring dimensions.
The product introduced at the end of the recording; provides an overview of tracing, evaluations and production monitoring, with options to explore or try it.
Related talks
- Build a Platform and Watch It Burn — Michael Forrester, Accenture & Whitney Lee, Datadog
Develops the safety discussion through concrete prompt-injection, input-blocking and output-redaction demonstrations, including failed protections and the difference between detection and enforcement.
- Is a Faster Model Actually Faster? Test the Whole Job — Morgan Suo, MiniMax
Extends the cost–quality tradeoff into model-switch evaluation: measure the time and total expense of producing an acceptable result, including failed attempts and human repair.
Read the complete timestamped transcript
- 0:12
Hello, everyone. Thank you for joining me today. Uh, it's time to begin. And, uh, for years, uh, many of us, uh, monitored our applications, uh, with the golden signals, which is, was latency, error, traffic, and saturation, and shortly we called them LATS. And they were, and still, uh, they are and will be remain sufficient and critical for determine the health of our applications. However,
- 0:42
today when we enter the new era, era of generative AI, it's becoming not enough. And today, we're gonna talk about what are the new metrics we need to look if we wanna build the healthy GenAI application. Very shortly, my name is Marina Petzel. I am GenAI advocate here in Datadog, and today I will walk you through the metrics that we need to look for. So, uh, when we talk about traditional applications, um, the
- 1:12
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, um, different responses every time we run it, and which means we cannot rely on the standard regression testing alone. And, uh, you must constantly evaluate quality in the live environment. The second difference between traditional applications and
- 1:42
GenAI applications is variable cost structure. Traditional compute costs are predictable, right? Um, we pay for machine that is running our code, but for GenAI, this, this is dynamic variable here. They might, uh, they vary from the number of tokens, the model that we are using, or the size of your context window that you have. And it's become essential to do the real-time, uh, granular cores, uh,
- 2:12
cost, um, 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, uh, outage in our output. And that's becoming a big problem. And these are security issue, not a simple 500 error code can--
- 2:42
you'll never catch, and demand an entirely new forms of security monitoring. And finally, quality is very subjective for GenAI applications. The traditional systems, uh, 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 OK response from your server doesn't necessarily mean
- 3:12
that the answer was helpful or correct for your final user. And we must now integrate the continuous, uh, quality evaluation, uh, 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
- 3:42
running. And established metrics LATS will be still essential, but we're gonna talk about what else on addition to that we need to implement into our systems. And first, I wanna 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
- 4:12
huge outage of the, uh, cost for their monthly usage. And while the same is true as for traditional applications, there are more linear scale between the throughput and the, uh, 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
- 4:42
have this visibility, and we need to really pay 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 the token creep. Uh, this happens when engineers or product managers trying to improve the quality,
- 5:12
quietly increasing the context window. And let's say the context window was four thousand tokens, and then it's, like, blow to thirty-two 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 8x cost increased. And in a month, it might cost you thousands of dollars. Second is the model drift. Uh, that is
- 5:42
also the pretty typical problem when the team switches from cheaper and faster model, like let's say Haiku 4.5, to 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, fifteen times higher, uh, per the cost request. And this change in model, even with the same usage volume,
- 6:13
might blow your cost significantly within a month, too. And finally, it's uncached calls. In generative AI, the same query can hit the API repeatedly if, uh, you haven't implemented the effective caching layer. And what we've been seeing from, um, our, uh, own research that 70% of the spend sometimes are redundant because the system is paying for exact the same expensive model
- 6:43
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 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
- 7:13
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, interactions are undifferentiated. You don't know what's below 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
- 7:42
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 roadmap decisions, like knowing which features are actually the budget costs. The second level is the use-user level. Using the tags like the user ID or your org, um, name is essential for chargebacks, accurate billing, but also quickly identify the patterns of abusive
- 8:12
usage before they drain your budget. Third is the model level. Uh, also tag your models like GPT-5.5 or the provider, OpenAI, Anthropic. They'll give you visibility into the higher level areas, uh, of cost optimization. And you can benchmark the true expenses, uh, of using one model versus another. And finally, uh, endpoint-level tagging.
- 8:42
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 tagging mandatory practice, you gain an esse- an essential visibility to understand exactly where your money is going and how important,
- 9:13
uh, 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 tea-team is obviously get very happy. Uh, but the next one, uh, problem is the safety. And your AI can be cheap, but s-still leak some of the sensitive or personal information, which is not great. And even though, like, your
- 9:42
lab scores can be perfect, uh, it cannot tell you if there are some, um, metrics went wrong. So what we can track here in the safety metrics to, um-- First is the prompt injection rate, which has become the very crucial problem. This metrics detects the manipulation attempts, uh, into your user prompts. There are if infrastructure-- if, uh, the infrastructure design doesn't have any guardrails. And
- 10:13
this can be, um, prevent by using some advanced techniques like, uh, 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, uh, so leakage is a crucial and zero-tolerance issue here. We can scan all the model outputs, uh, for sensitive data
- 10:42
like Social Security, like credit cards or personal information. And you can use some, um, um, methods like regex or, uh, named entity recognition here, and only acceptable target should be zero percent of, uh, your production outputs. The third is the content moderation score, how you can determine if your content is toxic, harmful, or biased, uh, towards
- 11:12
some of the topics. And by running all outputs through toxicity classifier can gi-give you a scores, uh, how-- what is the risk of your output for being exposed to this, um, toxic, uh, um, output. And this allows you to set some clear thresholds, and we always target to, um, minimize that as much as we can. And finally, um, the jailbreak attempts, and there are
- 11:42
persistent attempts by users to bypass the safety guardrails, and often, um, through the elaborate scenarios. And tracking p- uh, tracking patterns to indicate the system prompt overwrites, uh, you should design and become-- so it become the absolute blocker for you. So ideally, we should block all the hundred percent of the attempts of that.
- 12:10
Now let's imagine that cost is checked, security is checked, uh, but now you arrive to arguably the most crucial, um, dimension and the quality monitor that at least the most crucial for our final users. And even though your LATS metrics, um, showing that your service is up and around, uh, and running, your cost and safety tells you that your service is budget-fri-
- 12:39
compliant and also secure, but ultimately, for any application, but more for generative application, it's whenever output is good. But we all know that 200 OK response from your server sometimes can be a lie, uh, 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 can confidently by lie-- but lie to you.
- 13:10
And now let's understand what type of metrics you can imple- implement to your application right now to prevent it from being, uh, unsafe for your final user. We recommend to focus on these five metrics. Uh, one of them is hallucination rate. Um, this measures the percentage of response that contain claims unsupported by the grounded data. Um, we need to mix that with the manual review as well as with, uh,
- 13:40
automated fact checks to achieve the aggressive targets here, too. The final-- uh, the next one is the relevance scores, which helps you to understand if, uh, the response actually address the user question. Um, te- techniques like y- that you can use here is similarity using BERT or embedding similarity that can score you, um, how relevant is the final answer was to the user.
- 14:10
The next one is user satisfaction, which directly pulse into your end user. Uh, you must implement-- You can implement some mechanism 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 got more than 80 or 85% of the positive feedback at least. Next one is the
- 14:40
answer completeness, and this, uh, metric is often evaluated by LLM-as-a-judge, uh, 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, uh, generation system, you should always track the quality of your RAG. What-- If all the documents that were fetched were relevant to the user
- 15:10
query, and here you have a lot of metrics and mechanism how you can calculate that. For example, top-K accuracy or normalized discounted gains. And that is, uh, essential to track because, uh, whenever, like, your context is exploded, it's getting harder and harder to pick the most relevant one. And by implementing these, uh, metrics, uh, you can gain some understanding of, like, more dimensional view of the quality that necessary you, you need
- 15:40
to optimize to improve your GenAI application. Well, and now let's summarize, um, what we need, uh, to implement to make sure that our GenAI 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, LA- or LATS, latency, error, uh, traffic, and saturation. But also on top of that, we need to put another layer, layer of
- 16:10
which is more relevant to generative applications, and in this case, we talked about the cost, safety, and also quality. And I know that for us as an engineer, it's 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 centrally, Datadog has you back here since we are working
- 16:40
in observability and monitoring space for, for really long time. So we do have our Agent Observability, uh, product, which allows you to quickly and easily understand if your AI application is healthy, if it's running, or there, there is any problem that you need to fix. And we do have a lot of different way, um, uh, things that you can track inside of that. And, um, if you wanna hear more about that, please feel free
- 17:10
to see me afterwards. We also do have the booth here, uh, which you can check it out. We do have a really, uh, good, um, offers for you if you wanna just try it out and see how Agent Observability can help your application. We have some QR codes for the free trials. And, uh, with that, I wanna thank everyone. Again, my name is Marina Petzel. If you wanna contact me, please feel free to, um, use this QR code. And yeah, thank you for
- 17:40
being here today.