Reference · Cheatsheet
Pick an eval or observability tool
Last updated
Match the job to the tool before wiring one in — most teams end up using two or three together, not one for everything.
Match the job to the tool before wiring one in — most teams end up using two or three together, not one for everything.
#Quick picker
| Need | Start here | Why |
|------|------------|-----|
| Score RAG answer quality (faithfulness, relevance) | RAGAS | Built specifically for retrieve-then-generate metrics |
| LLM checks inside your normal test suite | DeepEval | Feels like pytest; runs in CI |
| Compare prompts/models side by side, quick red-team checks | promptfoo | Config-driven, no code required to start |
| See exactly what happened in a multi-step chain/agent | LangSmith or Langfuse | Full trace tree per request |
| Keep observability data in your own infra | Langfuse | Open-source, self-hostable |
| Custom scoring logic no tool covers | Hand-rolled eval gate | See `eval-in-code` lesson pattern |
#Decision flow
1. **Do you have a RAG pipeline specifically?** → add RAGAS metrics first
2. **Do you want evals living next to unit tests in CI?** → DeepEval
3. **Do you just need a quick prompt A/B before shipping?** → promptfoo
4. **Is debugging "what actually happened in this run" the pain?** → tracing (LangSmith/Langfuse), not an eval score
5. **Need it self-hosted for data residency?** → Langfuse over LangSmith
#Cost tip
Tracing tools bill by trace volume — sample production traffic (e.g. 10%) once volume is high, and keep 100% tracing only for staging/canary.