LLM Observability: Trace, Cost and Debug a RAG Assistant
Instrument a real RAG assistant with traces from scratch: nested spans around retrieval and generation, token usage and cost attributed to every call, a latency and cost report, a triage tool that finds retrieval misses from trace evidence, PII redaction before anything is written, sampling that keeps every error and slow request, a cost budget alarm, and a CI gate that blocks a prompt change that makes the assistant slower or dearer.
Hands-on labs require Pro · $29.99/mo · cancel anytime
What you'll learn
- 1Stand up the assistant and feel the blind spotYou inherit the Northwind Cloud support assistant. It is a small but real
- 2Instrument the request with nested spansA trace is one request end to end. A span is one timed unit of work
- 3Attribute tokens and cost to every callThe invoice arrives once a month as one number. The question that matters
- 4Report where the time and the money goIndividual traces answer "what happened to this request". Operations questions
- 5Find the wrong answer from the trace, before the customer doesMost wrong answers from a RAG assistant have the same anatomy. The question
- 6Redact personal data before it touches diskTraces record the request. The request is what the customer typed, and
- 7Keep every bad request, a tenth of the boring ones, and a budget alarmAt six requests a run, keep everything. At a million requests a day,
- 8Gate a prompt change on latency and costSomeone proposes a friendlier system prompt: restate the question, list every
Prerequisites
- Comfortable reading and editing Python
- Have called a chat completions API at least once
- Know what a percentile is
Exam domains covered
Skills & technologies you'll practice
This intermediate-level ai/ml lab gives you real-world reps across:
What you'll do in this lab
This is a hands-on LLM observability lab on a real Retrieval-Augmented Generation (RAG) service: a Milvus vector store, NVIDIA embeddings and a chat model behind an OpenAI-compatible endpoint. You start with a working assistant that is completely opaque, then build the tracing layer yourself: a trace per request, nested spans for retrieval and generation with parent and child ids, status and error capture, and token usage read from the API's usage block and turned into cost per call and per answer from a price table you control. Every span is written as JSON you can query, and a small viewer prints each trace as a tree.
Then you use the traces the way an on-call engineer does. A report gives p50 and p95 latency per span and the share of time retrieval and generation each take, plus mean cost per answer. A triage tool finds the answers that were wrong because retrieval missed, from the cosine score the trace recorded rather than from reading transcripts. You redact emails and account numbers before anything touches disk, add sampling that keeps every error and every slow or expensive request while dropping most of the ordinary ones, wire a daily budget alarm, and finish with a CI gate that replays a fixed question set against a candidate prompt and fails the build when p95 latency or cost per answer regresses past an allowance.