How do you find the source of a slow or wrong AI answer?
Answer out loud or in your head first, then compare.
Answer
I break the whole path into stages and measure each separately: waiting in the queue, retrieving documents, calling the model and the tools. I give one job a shared identifier, so I can connect the recorded events from different parts of the app.
That lets me tell whether no source was found, the model used it badly, or we simply waited a long time for the database. I record the model and prompt versions, but I don't needlessly copy all the confidential content into general logs. An HTTP 200 status says the request was handled — it doesn't confirm a good answer. I check quality and the real effect of the action separately.
Why it matters: Owning the product includes diagnosing problems after deployment.
Possible follow-ups: How do you investigate a problem without giving everyone the full document contents?
How did it go? Be honest — “Not yet” puts the question on your review list.
Start with
- D-P01 · What is HTTP, and what do a request and a response look like? — Backend, data and system design
- D-P10 · What is a database transaction? — Backend, data and system design
- D-P13 · What is a message queue, and why do we use one? — Backend, data and system design
Further reading
- Microsoft Foundry: Observability in generative AI(opens in a new tab)Docs; accessed 22.10.2026. Evaluation, monitoring and tracing across the solution's lifecycle.