Phoenix
~2 min read
Concept & How It Works
Why Does It Exist?
RAG agents fail silently when retrieval is bad. Phoenix links traces to retrieval quality, embedding drift, and hallucination patterns in one OSS tool.
Real-World Analogy
Phoenix is an X-ray for RAG — it shows whether your agent's answers come from the right documents or imaginary sources.
Visual Workflows
What is Phoenix?
Example
Scenario
Phoenix trace shows retrieved chunks are about refunds when user asked about login — you fix the embedding model mismatch.
Solution
In Agent Evaluation & Observability, apply Phoenix to this scenario: Phoenix trace shows retrieved chunks are about refunds when user asked about login — you fix the embedding model mismatch. Identify the inputs, run the technique, validate the output, and note one thing you would monitor in production.
Practice Task
Do this before moving to the next module — reading alone is not enough.
Open the Code Walkthrough below and run it locally. Change one parameter related to Phoenix (e.g. model, temperature, top_k, or tool name), observe the difference in output, and write 2–3 sentences explaining what changed.
Code Walkthrough
Highlighted lines show where Phoenix happens in the code.
1import phoenix as px # import dependencies2from phoenix.otel import register # import dependencies3from openinference.instrumentation.openai import OpenAIInstrumentor # import dependencies4
5px.launch_app()6register()7OpenAIInstrumentor().instrument()Commands to Remember
Commands to Remember
pip install langsmith # trace and evaluate LLM runspip install arize-phoenix # open-source LLM observabilitypip install opentelemetry-api opentelemetry-sdk # distributed tracing
Common Mistakes
- Treating Phoenix as a black box without evaluation
- Ignoring cost and latency in production
- Skipping error handling for phoenix
Cheat Sheet
Quick recap — the most important points from this module.
Cheat Sheet
quick ref- •Phoenix
- •OpenInference
- •RAG Relevance
- •Embedding Visualization