Trace spans as plain data
A real tracing library stores the same fields. Here the clock advances only when work() is called.
When an answer is wrong, you need to know what retrieval did: which passages came back, with what scores, and how long each stage took. Structured log lines and trace spans record that, and a few metrics tell you when to look.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write parse_logfmt(line) that splits a line of key=value pairs separated by spaces into a dict (the value may contain =). Print the outcome of ts=2 event=answer req=r3 outcome=refused.
Write slowest(spans) taking a list of (name, start, end) tuples and returning the name of the one that took longest (the first, on a tie). Try it on three spans.
Explain it without notes
Why does a RAG system need more than error logs?
What would you log for each retrieval, and what would you be careful not to log?
What is a span, and what do the gaps in a trace tell you?
Name four metrics you would alert on for a RAG service and what each can reveal.
Expected output
ask 0-510 (510 ms) req=r7 index=8
embed 0-30 (30 ms) model=toy-v1 cache=miss
search 30-75 (45 ms) hits=3 top=0.71
rerank 80-200 (120 ms) candidates=20
generate 200-510 (310 ms) prompt_tokens=1750 finish=stop
slowest child: generate (310 ms)
time not covered by any child span: 5 ms