Order the spans in a typical instrumented RAG trace

Order steps·Easy·4.0 · 0·~1 min·Asked atBraintrust Comet Ml Mckinsey

Attempt it

1Post-process span applies citations, formatting, and PII redaction
2Retrieve span fetches top_k chunks from the vector store
3Generate span calls the LLM with assembled prompt + chunks
4Rerank span re-orders the candidates with a cross-encoder
5Embed span turns the user query into a vector
6HTTP root span captures the incoming request

A typical RAG (retrieval-augmented generation) request goes through six well-defined stages, and a good trace mirrors that pipeline one to one. **HTTP root** is the outermost span. Every other span hangs off this one as a descendant. The root carries the HTTP method, the path, the user id (opaque), and the overall request latency and outcome. **Embed** is the first child. It takes the user's question and runs it through an embedding model (text-embedding-3-large, Cohere embed-v4, Voyage v3, BGE-large, etc.) to produce a vector. The span records the model id and the input token count. **Retrieve** uses that vector to look up the top-k similar chunks from a vector database (Pinecone, Weaviate, Qdrant, pgvector). The span records the index, the k value, the chunk ids returned, and the similarity scores. **Rerank** takes the retrieved candidates and re-orders them with a cross-encoder reranker (Cohere rerank-3.5, Voyage rerank-2.5, BGE-reranker). This step typically improves precision at the top of the candidate list. **Generate** is the LLM call. The prompt template, the assembled context, the chosen reranked chunks, and the model id all become span attributes; the response is the output. **Post-process** is cleanup: citation extraction, formatting, PII redaction. It is often the last child before the root closes.

**The six-stage RAG trace tree** is the canonical shape every observability tutorial reaches for, and it survives because real production pipelines really do look like this. 1. **HTTP root span** wraps the incoming request. Carries user id, session id, request latency, status. 2. **Embed span** takes the question, calls the embedding model, emits a vector. Records `gen_ai.request.model`, `gen_ai.usage.input_tokens`. 3. **Retrieve span** queries the vector index for top-k similar chunks. Records the index name, the k value, chunk ids, similarity scores. Two-stage retrieval starts here; this is the recall stage. 4. **Rerank span** runs a cross-encoder over the retrieved candidates and re-orders them. Records the reranker model, the input candidate count, the output top-n, scores per pair. This is the precision stage. 5. **Generate span** calls the LLM with the assembled prompt (system + user question + reranked chunks). Records `gen_ai.request.model`, token usage, finish reason, cost. 6. **Post-process span** applies citation linkage (which chunks did the answer actually cite?), output formatting, and PII redaction before the response goes back. Why this order matters. Each stage depends on the previous one's output: embed feeds retrieve, retrieve feeds rerank, rerank feeds generate, generate feeds post-process. Confusing the order (rerank before retrieve, post-process before generate) signals not understanding the pipeline. The order in the question is the strict pipeline order, and a good trace mirrors it exactly.

TL;DR

HTTP root, then embed, then retrieve, then rerank, then generate, then post-process; six spans under one root, in pipeline order.

Memory aid

Easy to grasp

Picture a librarian helping a researcher. The researcher walks in (HTTP root). The librarian first decodes the question into search terms (embed). Then walks the stacks and pulls a shelf of likely books (retrieve). Skims the shelf and picks the most useful few (rerank). Reads aloud the relevant passages and writes a summary (generate). Finally cleans up the wording, adds citations to the books used, and removes anything sensitive before handing the answer back (post-process). The trace tree mirrors the librarian's workflow exactly.

Key concepts

RAG Observability and tracing Embeddings

Concept explanation~2 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

The six-stage RAG trace tree (HTTP root, embed, retrieve, rerank, generate, post-process) is the canonical shape every RAG observability tutorial reaches for. The order is not arbitrary; it is forced by the data dependencies between stages.

This question tests whether you have actually instrumented a RAG pipeline or just read about one. The signal is that you can defend the order from first principles (what feeds what) rather than memorize a list.

Mental model: trace order mirrors data-dependency order. Where the data flows is where the spans flow.

Why this exact order is forced

The data-dependency chain

Embed produces a query vector. Retrieve needs that vector to score against the index. Therefore embed must precede retrieve. Retrieve produces a candidate list. Rerank needs that candidate list to score (query, candidate) pairs. Therefore retrieve must precede rerank. Rerank produces a final top-n. Generate needs that top-n to build the prompt context. Therefore rerank must precede generate. Generate produces the model output. Post-process needs that output to redact, format, and link citations. Therefore generate must precede post-process.

What the HTTP root does

The HTTP root span wraps everything because the OTel trace context propagates from the incoming HTTP request. The root carries request-level attributes (user id opaque, session id, status code, total latency, total cost) and serves as the parent for every child span.

Why splitting embed and retrieve matters

A common shortcut is to combine embed and retrieve into one 'retrieval' span. Splitting them is worth the extra span because: embedding cost and latency belong to the embedding model and provider, retrieval cost and latency belong to the vector database, and degradations in either show up as separate spikes if you trace them separately.

Attributes that earn their keep on each span

Common variants that still respect the order

How the canonical order plugs into evaluators and SLOs

Situations where this technique stops working.

2–4 min · Everything important, quickly.

Real products, models, and research that use this idea.

Phoenix's RAG examples produce exactly this six-stage shape via OpenInference span kinds: HTTP root, EMBEDDING, RETRIEVER, RERANKER, LLM, and a post-process or chain span.
LlamaIndex and LangChain both emit this shape natively when their RAG chains run under tracing.

What an interviewer would ask next. Try answering before peeking at the approach.

QWhere does hybrid retrieval (BM25 plus dense) fit in this trace tree?

Two retrieve child spans (sometimes parallel siblings under a fanout parent), both before rerank. The rerank step merges and re-scores both candidate sets. Span attributes record the BM25 and dense recall separately, which lets you measure which retrieval source contributed to the final answer.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases that signal junior thinking. Click to expand.

Most common mistake

Putting rerank before retrieve. Rerank scores the retrieved candidates, so retrieval must run first or there is nothing to rerank.

60 second bullets to scan on the way to the call.

Six-stage RAG trace order
Why each stage's output feeds the next stage's input

Primary sources. Browse if you want the original framing.