AI Chatbot Evaluation and Observability with Promptfoo and Langfuse

Contents
A chatbot that passes demo questions can still fail the moment real users take over. Here's how to evaluate chatbots before release and monitor them after, using Promptfoo for testing and Langfuse for observability.
A chatbot can look flawless in a demo and still fall apart in production. It handles the expected questions, the team approves the prompt, and the bot ships. Then real users show up with messy, unscripted questions, and the bot starts giving confident answers that are simply wrong.
That gap between demo and production is why teams need a real way to evaluate chatbots, not just review a handful of sample conversations before launch. A demo script tells you the bot can perform. It doesn't tell you whether the bot stays accurate, grounded, and safe once thousands of real conversations start hitting it.
This is where AI chatbot testing has become its own discipline, separate from traditional QA. Two tools now anchor most production evaluation setups: Promptfoo, which tests chatbot behavior before deployment, and Langfuse, which traces and monitors that same behavior once the bot is live.
This article breaks down where each one fits, how they work together, and what to actually measure once you put them to work.
Why traditional QA breaks down for AI chatbots
Traditional software testing assumes determinism: same input, same output, pass or fail. Large language models don't work that way. The same question can produce different, still-acceptable answers depending on the model, the prompt, the retrieved context, and the conversation history.
That breaks a few assumptions QA teams normally rely on.
- Non-deterministic outputs. Exact-match testing doesn't hold up when wording and structure vary between runs.
- Prompt sensitivity. A system prompt change that fixes one use case can silently break another.
- Multi-turn context. A response can be correct in isolation and wrong given the last five messages.
- Retrieval dependency. In retrieval-augmented generation (RAG) systems, a bad answer often starts with a bad retrieval, not a bad model.
- Model and provider drift. A model version update or routing change can shift behavior with no code change on your side.
None of this makes traditional QA useless. It means QA needs to be extended with a dedicated LLM evaluation framework and ongoing AI monitoring, because pass/fail scripts alone won't catch these failure modes.
LLM evaluation metrics: what to actually evaluate
Before picking a tool, define what quality means for this specific chatbot. A support bot, a shopping assistant, and an internal knowledge tool fail in different ways, so their evaluation criteria differ too.
Most production chatbot programs end up covering the same core dimensions:
|
Dimension |
What it checks |
|
Factual accuracy |
Is the information correct? |
|
Groundedness |
Is the answer supported by retrieved context, not invented? |
|
Retrieval quality |
Did the system find the right source before generating a response? |
|
Relevance |
Does the answer address what the user actually asked? |
|
Safety |
Does the bot avoid unsafe, unauthorized, or non-compliant behavior, including prompt injection and data leakage? |
|
Latency |
How long does the full pipeline take, not just the model call? |
|
Task success |
Did the bot complete the job: resolve the issue, create the ticket, recommend the product? |
|
User satisfaction |
Do real users rate the interaction as helpful? |
No single score covers all of this. A chatbot can be fast and wrong, grounded and unhelpful, or safe and too cautious to be useful. Treat these as a basket of metrics, not one benchmark.
Common AI chatbot failure modes
Many of these problems stay invisible in a demo and surface once the chatbot is handling real, unpredictable traffic.
- Hallucinations: the bot invents a policy, price, or feature.
- Retrieval misses: the right document exists but never gets retrieved.
- Prompt regressions: a fix for one scenario quietly breaks another.
- Stale knowledge: the bot answers from an outdated document or embedding.
- Context window failures: earlier instructions or facts fall out of scope in long conversations.
- Tool-calling errors: the bot calls the wrong tool or misreads the result.
- Latency spikes: retrieval, tool calls, or model load make the bot too slow to be useful.
Best practices for reliable AI chatbot testing and monitoring
- Start with the highest-risk, highest-value conversations, not full coverage on day one.
- Build a golden dataset from real questions where possible, and keep growing it.
- Treat prompt changes like code changes: version them, test them, review them.
- Evaluate retrieval separately from generation in RAG systems, so a failure isn't automatically blamed on the model.
- Add observability before launch, not after the first incident.
- Combine automated scoring for scale with human review for tone and nuance.
- Turn every production incident into a regression test.
Evaluation and observability are not the same thing
Evaluation tests whether a chatbot is good enough to ship. Observability shows what it's actually doing once it has shipped.
|
Evaluation |
Observability |
|
|
Question |
Is this ready to ship? |
What's happening right now? |
|
Timing |
Pre-production, part of CI/CD |
Post-deployment, continuous |
|
Data |
Test datasets, golden sets |
Real conversations, traces, feedback |
|
Output |
Scores, pass/fail results |
Traces, dashboards, alerts |
|
Typical tool |
Promptfoo |
Langfuse |
The strongest teams run both, then close the loop: observability surfaces a production failure, the team inspects the trace, and the failure becomes a new regression test in the evaluation suite.
Promptfoo: testing before deployment
Promptfoo is an open-source framework for testing LLM applications before release.
It's built for teams who want to move prompt changes out of "looks better to me" territory and into something testable. Typical use cases:
- Prompt testing. Compare prompt versions against the same dataset to see which one performs better across the full range of cases, not just the one example that motivated the change.
- Regression testing. Rerun the test suite whenever a prompt, model, or retrieval configuration changes, to catch what broke.
- Model comparison. Run the same test cases across different models or providers to support model selection and cost decisions with evidence instead of intuition.
- Hallucination and adversarial testing. Define cases where the bot must refuse, say "I don't know," or resist prompt injection, then check whether it actually does.
Promptfoo answers one question well: if we change this prompt, model, or retrieval setup, what breaks?

Example of a side-by-side comparison of multiple prompts and inputs, source: Promptfoo
Langfuse: observability after deployment
Langfuse is an open-source observability platform for LLM applications, built around tracing, prompt logging, and production monitoring.
Production failures are hard to reproduce from the final answer alone. Tracing shows the full chain: the user's input, the system prompt, the retrieved context, any tool calls, the model's response, the latency at each step, and whatever feedback the user gave.
That visibility is what makes it possible to answer questions like:
- Which prompt version produced this answer?
- Where did the response slow down: retrieval, the model call, or a tool call?
- Which conversations got negative feedback, and what do they have in common?
Langfuse answers a different question than Promptfoo: what is this chatbot actually doing with real users right now?
Core data hierarchy diagram Langfuse, source: Langfuse
Scores Analytics view Langfuse, source: Langfuse
How they fit into one workflow
Promptfoo and Langfuse solve two ends of the same reliability problem, not competing versions of the same thing. A practical loop looks like this:
- Version prompts and track which version is live.
- Run Promptfoo evaluations against a dataset before deploying a prompt or model change.
- Deploy the version that improves results without introducing regressions.
- Trace production conversations with Langfuse: latency, cost, feedback, failures.
- Review low-rated or failed conversations.
- Turn each real failure into a new Promptfoo test case.
- Repeat.
Conclusion: reliable AI chatbots require continuous evaluation
A strong prompt may improve chatbot behavior, but it cannot guarantee factual accuracy, safety, retrieval quality, latency, or production reliability. For that, teams need a continuous evaluation and observability process.
Promptfoo helps teams test chatbot behavior before deployment through structured evaluations, assertions, regression testing, model comparison, and adversarial testing. Langfuse helps teams understand what happens after deployment through tracing, monitoring, prompt logging, feedback loops, and debugging.
Together, they support a modern AI chatbot testing lifecycle: evaluate before release, observe after release, learn from production, and convert every failure into a stronger test.
That is the foundation of reliable AI chatbot development.
FAQ
What's the difference between Promptfoo and Langfuse? Promptfoo evaluates chatbot behavior before deployment: prompt testing, regression testing, model comparison. Langfuse monitors chatbot behavior after deployment: tracing, latency, cost, feedback. They cover different stages of the same lifecycle.
What are the most important LLM evaluation metrics? It depends on the chatbot's job. Groundedness and retrieval precision matter most for RAG systems. Task success and escalation rate, meaning how often the bot hands off to a human, matter most for support bots. Safety and factual accuracy matter most for regulated use cases.
Why do AI chatbots behave inconsistently? Because LLMs are probabilistic and context-sensitive. Prompt wording, conversation history, retrieved context, and model updates can all shift the output, which is why testing has to be continuous rather than a one-time release gate.
