KI als Tester: So funktioniert LLM-as-Judge - Anupam Krishnamurthy
Categories: Podcasts , Richard Seidl Software Testing
Testing AI systems, especially LLMs, requires new methodologies to handle their non-deterministic nature, focusing on behavioral consistency and component-specific evaluations like retrieval accuracy and generation quality. Key strategies include deterministic checks, LLM-based evaluations, adversarial testing, and continuous adaptation to ensure trust in AI applications.
Richard Seidl Software Testing
This is the other podcast on Software Testing by Richard Seidl, the episodes are in spoken German but the show notes and site are written in English. Our summaries are generated from AI transcript translations.
- https://www.richard-seidl.com/en/blog/tag/podcast-software-testing
- https://www.richard-seidl.com/en/
Episode Details
- Show Notes: https://www.richard-seidl.com/de/podcast/llm-tests-automatisierung
- Published: 2026-08-18T04:00:00Z
- Duration: 00:22:34
- Author: Richard Seidl - Experte fur Software-Entwicklung und Testautomatisierung
Overview
The podcast discusses the evolving challenges and methodologies in testing AI systems, particularly Large Language Models (LLMs), which differ fundamentally from traditional software due to their non-deterministic nature. Unlike deterministic systems where consistent outputs are expected, AI systems require testers to adapt by accepting variability and focusing on behavioral consistency rather than exact outcomes. This shift demands new testing approaches, especially for Retrieval-Augmented Generation (RAG) systems, where most errors originate in the retrieval component rather than the LLM itself. Testing must therefore isolate components - evaluating retrieval using semantic similarity metrics and generation based on relevance and coherence.
Key testing strategies include using deterministic checks for structured outputs, objective evaluations for factual accuracy, and subjective assessments for qualities like tone and helpfulness. The use of LLMs as evaluators (“LLM Judges”) is explored, with emphasis on mitigating shared blind spots through rubrics, multiple models, and domain expert alignment. Adversarial testing is highlighted as essential for uncovering unintended behaviors. As AI becomes embedded in more applications, ensuring trust requires guardrails, continuous evaluation, and a move away from expecting full system understanding. The discussion underscores that while traditional testing skills remain valuable, they must be adapted to accommodate the probabilistic reality of AI.
What If
-
What if you tested your AI feature like a forensic investigator isolating failure points?
- Move: Break down your RAG system into retrieval and generation components; write separate test suites that validate retrieval accuracy (e.g., cosine similarity thresholds) and generation coherence (e.g., prompt adherence) using real user queries.
- Why Now?: Most AI bugs originate in retrieval, not the LLM - but undiagnosed, they erode trust. With increasing deployment of custom RAG systems, isolating faults early reduces debugging time and customer-facing errors.
- Expected Upside: Faster root cause identification, reduced false attribution to the LLM, and more targeted data improvements - leading to higher-quality outputs and lower operational cost.
-
What if you used an LLM as your automated QA judge for subjective outputs?
- Move: Implement an LLM Judge pattern: define a rubric with scoring criteria (e.g., factual accuracy, tone, completeness), then run your AI’s responses through a separate, well-configured LLM evaluator using PyTest or a lightweight pipeline.
- Why Now?: Subjective testing at scale is unsustainable manually. LLM Judges enable repeatable, cost-efficient evaluation - especially critical as solo developers integrate AI into customer-facing features without a QA team.
- Expected Upside: Automated pass/fail signals for soft qualities (e.g., “helpfulness”), faster iteration on prompts, and objective tracking of model performance drift over time.
-
What if you treated non-determinism as a design constraint - not a defect - in your AI product?
- Move: Replace binary pass/fail tests with statistical acceptance criteria (e.g., 85% of outputs meet rubric standards over 100 runs); log variance and set alerts when results fall outside behavioral bounds.
- Why Now?: Users expect consistency, but LLMs inherently vary. Building tolerance into your testing now prevents wasted effort chasing false “bugs” and aligns your workflow with real-world AI behavior.
- Expected Upside: More realistic quality metrics, reduced maintenance overhead, and increased confidence in deploying AI features despite variability - accelerating time-to-market with responsible safeguards.
Takeaway
- Adapt test automation strategies to accept non-deterministic outputs by defining fuzzy success criteria (e.g., 80 - 85% accuracy thresholds) instead of strict pass/fail conditions.
- Isolate and independently test retrieval and generation components in RAG systems, focusing especially on retrieval quality using semantic similarity checks and vector database validation.
- Implement LLM judges with structured rubrics and example-based prompts to automate subjective evaluations like tone and helpfulness, while using diverse LLMs to reduce shared blind spots.
- Design deterministic smoke tests for AI systems by validating structured output formats (e.g., enforcing JSON schema compliance) to catch integration-breaking errors early.
- Take full ownership of QA when using custom Retrieval-Augmented Generation (RAG) systems by creating targeted test cases that distinguish between LLM failures and data/retrieval pipeline issues.
For a PDF of longer Software Testing Podcast Episode Summaries with Briefing Notes and more detailed summary notes, visit EvilTester Patreon Podcast Summaries.