AI Chatbot Evaluation and Observability with Promptfoo and Langfuse

Evaluation

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?

Promptfoo 1Example of a side-by-side comparison of multiple prompts and inputs, source: Promptfoo

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?

Langfuse 1Core data hierarchy diagram Langfuse, source: Langfuse

Langfuse 2Scores 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:

  1. Version prompts and track which version is live.
  2. Run Promptfoo evaluations against a dataset before deploying a prompt or model change.
  3. Deploy the version that improves results without introducing regressions.
  4. Trace production conversations with Langfuse: latency, cost, feedback, failures.
  5. Review low-rated or failed conversations.
  6. Turn each real failure into a new Promptfoo test case.
  7. 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.

We're Netguru

At Netguru we specialize in designing, building, shipping and scaling beautiful, usable products with blazing-fast efficiency.

Let's talk business

Chat with Chatguru