Every time your AI product generates text, code, or images, it's being judged.
Not against some complex scoring matrix or your internal metrics, but by a user who's tired, distracted, and one bad output away from a final verdict:
If you’re shipping anything LLM-powered in production, you need a simple way to answer: “Is this AI model doing what I want it to?”
That's what evaluations are for.
PostHog evaluations use LLM-as-a-judge to automatically score generative AI outputs against criteria like relevance, helpfulness, or toxicity.
How it works:
To prevent false negatives, N/A is used when the evaluation prompt is not relevant to the LLM generation. For example, a "mathematical accuracy" evaluation would apply the N/A label to responses that contain no math.
Running evals with AI enables you to batch test hundreds or thousands of traces, then apply human judgement to investigate pass/fail samples. To help you get started, we included five pre-built templates:
| Template | What it checks | Best for |
|---|---|---|
| Relevance | Whether the output addresses the user's input | Customer support bots, Q&A systems |
| Helpfulness | Whether the response is useful and actionable | Chat assistants, support bots, productivity tools |
| Jailbreak | Attempts to bypass safety guardrails | Security-sensitive applications, apps with PII |
| Hallucination | Made-up facts or unsupported claims | RAG systems, knowledge bases |
| Toxicity | Harmful, offensive, or inappropriate content | User-facing applications |
You can also create custom evals to suit the specific use cases of your AI features, and get a temperature check on user sentiment (more on that later).
Problem 1: Manual review doesn’t scale
LLM observability tools capture the inputs, outputs, latency, tokens, costs, and errors associated with AI workflows. This makes it simple for engineers to review generations and traces, and hunt for "AI slop".
Slop (a disguting yet accurate term) is any output from an LLM that feels generic, low quality, or just plain wrong.
The problem with manual review is that it doesn't scale. Suppose looking through one complex trace takes an engineer ~15 minutes:
Since the average AI product has tens or hundreds of thousands of generations occurring per day, there's no way to review them all and maintain sanity.
Problem 2: Margin of error affects your margins
In January 2024, a user convinced DPD's delivery chatbot to start swearing and criticizing the company. It wrote a poem calling itself "a useless chatbot" and DPD "a customer's worst nightmare." 1.3 million views later, the bot was disabled.
Around the same time, Air Canada's chatbot told a bereaved customer they could retroactively apply for bereavement fares (a policy that didn't actually exist). The airline argued the chatbot was "a separate legal entity." A tribunal disagreed and ordered them to pay $812 plus fees.
This might not sound like a math problem to a product engineer, but it definitely does to legal and finance.
Beyond monitoring for hallucinations and brand disasters, evals are a handy tool to define what "good AI" looks like for your product.
Good output or bad output? That depends on the task. An evaluation configured for a meme generator would pass content that an eval for a scientific research assistant would defintely fail.
Luckily, the best practices for writing evals are simple:
Here's a template you can use:
LLMs fail in unpredictable ways. Using one LLM to judge another will sometimes produce bizarre results. Keep humans in the loop to verify the judge isn't also hallucinating. Your evaluation criteria will drift as you discover new failure modes in production.
Examples of AI slop you can catch with evals:
Evals are primarily used to prevent negative outputs or regressions, but you can also use them to search for positive signals.
Examples of positive signals you can catch with evals:
Run multiple evals in parallel to spot-check different behaviors.
Evals are unit tests for your AI product. And like all product data, if you measure it, you can improve it.
But evals alone aren’t enough. A model can “work” and still fail to earn a habit.
This is important because AI-native products have a retention problem. Generous free tiers and easy cancellation attracts "AI tourists" – they extract value, then disappear.
When you connect eval results to real user behavior, you can see which AI behaviors actually affect retention, where users get stuck, and what’s worth fixing next.
The AI product improvement loop:
1. AI Observability shows what your AI is doing
2. Session Replay shows what users see when they interact with AI
3. Product Analytics connects AI quality to business metrics
If you're already using AI Observability in PostHog, you can start creating evaluations right away. Your first 100 evaluation runs are on us. After that, you'll need to use your LLM API key. Evals count as regular LLM events (100K events included on our free tier).
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。