Giskard

Giskard implements a modular detector architecture that automatically scans LLM outputs for 10+ vulnerability classes including hallucinations, prompt injection, harmful content, sycophancy, and information disclosure. Each detector (e.g., llm_hallucination_detector, llm_prompt_injection_detector, llm_harmful_content_detector) inherits from a base scanner class and uses LLM-as-judge evaluation to assess whether model outputs violate safety constraints. The framework orchestrates these detectors across test datasets and aggregates findings into a ScanReport that can auto-generate test suites.

Giskard's RAG Evaluation Toolkit (RAGET) provides end-to-end evaluation of retrieval-augmented generation systems by decomposing RAG pipelines into evaluable components (Retriever, Rewriter, Generator, Router) and measuring performance with domain-specific metrics (correctness, faithfulness, relevancy, context precision). The framework automatically generates diverse test questions from a knowledge base using LLM-based generators, then evaluates both component outputs and end-to-end system behavior. Results are aggregated into comprehensive reports with pass/fail metrics and performance breakdowns.

Giskard's prompt injection detector identifies inputs that attempt to manipulate LLM behavior through prompt injection attacks (e.g., 'Ignore previous instructions and...'). The detector uses a combination of pattern matching against known injection techniques (loaded from a curated database) and LLM-as-judge evaluation to assess whether inputs contain injection attempts. This enables proactive detection of adversarial inputs before they reach production systems.

Giskard's harmful content detector identifies LLM outputs that contain toxic, hateful, violent, or otherwise harmful content. The detector uses LLM-as-judge evaluation with configurable harm criteria to assess outputs, enabling detection of context-dependent harms that are difficult to capture with keyword matching. The detector can be customized with domain-specific harm definitions (e.g., financial advice, medical misinformation).

Giskard's hallucination detector identifies when LLM outputs contain information not supported by the provided context or knowledge base. The detector uses LLM-as-judge evaluation to assess whether generated text is faithful to the source documents, enabling detection of both factual hallucinations (false facts) and semantic hallucinations (unsupported inferences). This is critical for RAG systems where hallucinations undermine trust.

Giskard's stereotype detector identifies when LLM outputs contain stereotypical or biased representations of groups (demographic, occupational, etc.). The detector uses LLM-as-judge evaluation with bias-specific prompts to assess whether outputs reinforce stereotypes or exhibit discriminatory language. This enables detection of subtle biases that are difficult to capture with keyword matching.

Giskard's information disclosure detector identifies when LLM outputs inadvertently reveal sensitive information (personal data, credentials, proprietary information). The detector uses LLM-as-judge evaluation to assess whether outputs contain information that should not be disclosed, enabling detection of privacy leaks that are difficult to capture with pattern matching. This is critical for applications handling sensitive data.

Giskard's output formatting detector validates that LLM outputs conform to expected formats (JSON, XML, structured text, etc.). The detector uses LLM-as-judge or parsing-based validation to assess whether outputs are parseable and match specified schemas. This is critical for applications that depend on structured outputs for downstream processing.

Giskard's sycophancy detector identifies when LLM outputs exhibit agreement bias, where the model agrees with user statements or premises even when they are incorrect or harmful. The detector uses LLM-as-judge evaluation to assess whether outputs appropriately disagree with false or problematic premises, enabling detection of models that are overly agreeable. This is important for applications requiring critical thinking and honest feedback.

Giskard's implausible output detector identifies LLM outputs that are semantically anomalous or implausible given the input context. The detector uses LLM-as-judge evaluation to assess whether outputs make sense in context, enabling detection of outputs that are grammatically correct but semantically nonsensical or contradictory. This helps catch models that generate plausible-sounding but meaningless text.

Giskard provides a declarative test framework where users define GiskardTest subclasses with test logic, then organize tests into Suite containers for batch execution. Tests operate on Dataset objects that support slicing and transformation (filtering by conditions, applying transformations) to create targeted test scenarios. The Suite executor runs tests against wrapped models, captures pass/fail results, and generates reports. This architecture enables both manual test authoring and auto-generated tests from vulnerability scans.

Giskard abstracts LLM provider differences (OpenAI, Azure OpenAI, Mistral, AWS Bedrock, Google Gemini) behind a unified client interface, allowing users to swap providers without changing application code. The LLM integration layer handles authentication, request formatting, response parsing, and error handling for each provider. This enables both detector implementations and user code to remain provider-agnostic while supporting provider-specific features (e.g., Azure's deployment IDs, Bedrock's model IDs).

Giskard uses LLMs as evaluators to assess model outputs against semantic criteria (e.g., 'Is this response factually correct?', 'Does this response contain harmful content?'). The LLM-as-judge pattern prompts an evaluator LLM with the model output and evaluation criteria, then parses the response to extract a pass/fail decision or numeric score. This enables evaluation of properties that are difficult to measure with traditional metrics (hallucination, faithfulness, relevancy) and supports custom evaluation logic by modifying judge prompts.

Giskard's performance bias detector identifies when model accuracy varies significantly across data slices (e.g., different demographic groups, input lengths, or domains). The detector slices the dataset by specified conditions, computes performance metrics (accuracy, F1, etc.) for each slice, and flags slices where performance drops below a threshold. This enables identification of fairness issues and performance degradation on underrepresented groups without manual slice definition.

Giskard detects spurious correlations in tabular ML models by identifying features that are highly correlated with model predictions but are not causally related to the target. The detector computes feature importance and correlation metrics, then flags features that have high importance but low causal relevance (detected via perturbation or other causal inference techniques). This helps identify models that rely on data artifacts or confounders rather than true predictive signals.

Giskard's data leakage detector identifies when training data information leaks into model predictions, a common source of overfitting and poor generalization. The detector checks for exact or near-duplicate samples between training and test sets, analyzes feature distributions for evidence of test data contamination, and flags models that achieve suspiciously high performance on test data. This helps catch data leakage before models are deployed.

Giskard analyzes whether model confidence scores (probabilities, softmax outputs) are well-calibrated with actual accuracy. The overconfidence detector identifies cases where the model assigns high confidence to incorrect predictions, while the underconfidence detector flags cases where the model is uncertain about correct predictions. These detectors help identify models that are unreliable for decision-making or require additional validation before deployment.

Giskard's stochasticity detector identifies non-deterministic behavior in models by running the same inputs multiple times and checking for output variance. This helps catch models with random seeds that are not properly controlled, models using stochastic algorithms (e.g., dropout at inference time), or models with floating-point precision issues that cause slight output variations. The detector flags models that should be deterministic but produce different outputs on repeated runs.