KiwiQA's LLM testing practice validates large language model integrations across the dimensions traditional QA cannot reach — hallucination rate, OWASP LLM security, RAG accuracy, and EU AI Act conformity — with structured evaluation datasets and LLM-as-judge scoring.
Standard Selenium/Playwright test automation passes every test while your LLM hallucinates confidently, leaks system prompts through indirect injection, or returns documents outside a user's access scope. Enterprise LLM deployment requires purpose-built validation.
Purpose-built LLM validation covering evaluation methodology, security, RAG architecture, performance, and regulatory compliance evidence.
Every LLM testing engagement begins with a domain-specific evaluation dataset of 200–500 question-answer pairs with verified correct responses. The dataset covers the full scope of topics the LLM is expected to handle, including edge cases, boundary questions, and adversarial variants designed to surface hallucination pathways.
Dataset construction includes manual expert review and automated consistency checking to ensure ground truth labels are unambiguous and reproducible across evaluation runs.
We use a separate, independent LLM (configured as an evaluator with a structured scoring rubric) to assess each response for groundedness, factual accuracy, and relevance. Our LLM-as-judge configurations achieve 0.8–0.9 inter-rater agreement with human expert reviewers — sufficient for enterprise quality gates.
All judge scores are validated against a human-labelled calibration set on each engagement to confirm correlation holds for the specific domain.
| Evaluation KPI | Target |
|---|---|
| Hallucination Rate (high-risk) | ≤1% |
| Hallucination Rate (medium-risk) | ≤5% |
| LLM-as-Judge Correlation | 0.8–0.9 |
| RAG Recall@k | ≥0.85 |
| Groundedness Score | ≥0.90 |
| OWASP LLM Coverage | LLM01–LLM10 |
| LLM p95 Latency | ≤2 000ms |
| Token Cost Variance | ±15% of budget |
"We deployed a Claude-powered contract review platform. KiwiQA found that our RAG layer had no access controls — a crafted query could return contracts from other client accounts. They also found our system prompt was extractable via prompt injection. Neither was in our functional test plan."
Everything you need to know — answered.
LLM testing validates non-deterministic, probabilistic outputs that cannot be evaluated with binary pass/fail assertions. It requires statistical evaluation across many calls, LLM-as-judge scoring, adversarial prompt libraries, and domain-specific evaluation datasets — none of which standard Selenium or Playwright frameworks provide.
We build an evaluation dataset of 200–500 questions with verified correct answers, then run the LLM across the full set multiple times. Each response is scored by an independent LLM judge for groundedness and factual accuracy, correlated against human review. We report hallucination rate per risk tier: high-risk applications target ≤1%, medium-risk ≤5%.
The OWASP LLM Top 10 is the authoritative list of security vulnerabilities specific to large language model applications. The highest-risk items include LLM01 (prompt injection — overriding system instructions), LLM02 (insecure output handling — LLM output used unsafely downstream), and LLM06 (sensitive information disclosure — leaking training data or system prompts).
RAG testing covers three layers: retrieval (does the vector search return the right chunks at recall@k ≥0.85?), grounding (does the LLM response stay within the retrieved context?), and access control (does a user query only retrieve documents they are authorised to access?). Access control failures in RAG are the leading enterprise security risk we find.
High-risk AI systems under the EU AI Act require documented accuracy and robustness testing (Article 15), data governance evidence (Article 10), and transparency documentation (Article 13). For LLM applications this means evaluation dataset construction, hallucination rate reporting, and bias measurement — all as auditable test artefacts.
LLM endpoints have variable response times driven by token generation, not fixed compute paths. Performance testing must capture full latency distributions (p50/p95/p99), token cost per query, and the interaction between concurrent users and context window limits — patterns standard HTTP load testing tools do not model by default.
Evaluation dataset construction, hallucination measurement, OWASP LLM security, RAG validation — KiwiQA's LLM testing practice covers every dimension traditional QA cannot reach.