PaperlayerView exact revision on arXiv

Source-linked AI summary

PL-Guard: Probabilistic Logic Reasoning for LLM Guardrails

Satchit Chatterji, Shihan Wang, Giovanni Sileno, Erman Acar

arXiv:2608.15673v1cs.LGcs.AI

TL;DR

LLM guardrails often entangle interpreting policy-relevant facts with reasoning about policy violations, making reliable safety-helpfulness decisions difficult. PL-Guard separates neural predicate grounding from probabilistic symbolic policy reasoning; on XSTest, it reduced unsafe compliance to 0.5% but increased over-refusal to 14.4%.

  • Problem

    LLM guardrails must distinguish misleading sensitive-topic cues from genuinely policy-relevant facts while determining whether prompt-response pairs violate policy.

  • Method

    PL-Guard maps prompt-response pairs to probabilistic policy predicates with neural grounding, then uses ProbLog for explicit rule-level policy reasoning and inspectable recommendations.

  • Results

    0.5% unsafe compliance versus 6.0% for an LLM-as-a-judge baseline was achieved, alongside 14.4% over-refusal versus 5.2%.

  • Takeaways & Limitations

    PL-Guard occupies a safety-favoring point in the safety-helpfulness tradeoff while making the policy risks driving recommendations more inspectable.

  • Takeaways & Limitations

    Experiments are restricted to XSTest, a single generator family, and a single offline semantic evaluator whose judgments may inherit evaluator biases.

Abstract

from arXiv · show

Large language model guardrails can be viewed as policy-consistency problems: a system must determine which policy-relevant facts hold in a prompt-response pair and what those facts imply under a given policy. Common approaches, including policy prompting and LLM-as-a-judge pipelines, often overlap the tasks of semantic grounding and policy reasoning: the model both interprets the prompt-response pair and reasons about whether a policy has been violated. This can lead to unsafe compliance with harmful prompts, or refusals to assist benign ones. To separate grounding and reasoning roles, we propose PL-Guard, a neurosymbolic guardrail architecture. Using a symbolic policy interface consisting of predicates and ProbLog rules, a local LLM grounds prompt-response pairs into predicate probabilities using renormalized True/False token scores, while ProbLog performs explicit probabilistic rule inference over the symbolic policy. On the XSTest benchmark, an offline Qwen-based evaluator finds that PL-Guard with a hand-curated policy reduces unsafe compliance from 22.0% for the base model to 0.5%, and below the 6.0% rate of an LLM-as-a-judge baseline. This comes at the cost of higher over-refusal than the LLM-as-a-judge baseline, 14.4% versus 5.2%. These results suggest that separating neural grounding from probabilistic symbolic reasoning can expose the safety-helpfulness tradeoff while making the guardrail's intermediate reasoning steps explicit and auditable.

1. Introduction

PL-Guard frames LLM guardrails as probabilistic policy-consistency problems and separates neural grounding from symbolic policy reasoning. Its explicit, auditable design addresses the competing risks of unsafe compliance and over-refusal while preserving uncertainty through ProbLog inference.

  • Motivation: LLM guardrails must distinguish harmful assistance from benign discussion while keeping responses consistent with a specified rule set.The introduction frames guardrails as external control mechanisms for open-ended user-facing deployments.
  • Motivation: Unsafe compliance is the more serious failure because it may enable harmful behavior, whereas over-refusal primarily reduces usability by blocking legitimate requests.The paper identifies unsafe compliance as a false negative and over-refusal as a false positive when unsafe behavior is the positive class.
  • PL-Guard: PL-Guard separates neural predicate grounding from explicit symbolic policy reasoning in a neurosymbolic guardrail architecture.Neural models map prompt-response pairs to probabilities over policy-relevant predicates, while a probabilistic logic program performs rule-level reasoning.
  • PL-Guard: A local LLM converts normalized True/False token probabilities into predicate probabilities, and ProbLog computes inspectable rule-level risk probabilities instead of free-form judge verdicts.The symbolic policy preserves uncertain grounded predicates rather than discretizing them before reasoning.
  • Evaluation: The evaluation compares PL-Guard with base generation, policy prompting, and an LLM-as-a-judge baseline on XSTest using regex diagnostics and an external Qwen semantic evaluator.The study also varies symbolic policy granularity to examine how predicate and rule structure affects the safety-helpfulness tradeoff.

2. PL-Guard

PL-Guard separates policy translation, neural predicate grounding, and probabilistic symbolic inference into an auditable guardrail pipeline. It uses ProbLog to apply explicit policy rules to uncertain facts extracted from prompt-response pairs, prioritizing unsafe-compliance detection while limiting unnecessary refusals.

  • Architecture: PL-Guard translates a natural-language policy offline into policy predicates and ProbLog rules, then applies the symbolic representation during forward-time response guarding.The stated goal is a policy-adhering final response while avoiding unnecessary refusals as much as possible.
  • Symbolic policy: Policy predicates encode prompt-response facts, while ProbLog rules define outcomes such as unsafe compliance and over-refusal.Example conditions include harmful requests paired with harmful instructions, or benign-sensitive requests paired with refusals.
  • Predicate grounding: The grounding LLM assigns each predicate a probability by renormalizing True and False continuation-token scores rather than parsing a free-form judge response.The resulting grounded predicate probabilities are supplied to the symbolic inference stage.
  • Symbolic inference: ProbLog infers probabilistic truth values for policy rules and reports the strongest unsafe-compliance and over-refusal rules, with safety taking priority above a tunable action threshold.This rule-level structure avoids aggregating many weak paths into a high violation score solely because a detailed policy has more disjunctive rule paths.
  • Interpretability: The decomposition preserves uncertainty from neural grounding while making policy reasoning explicit and inspectable through ProbLog's external consistency checking.ProbLog receives uncertain LLM-derived facts, applies rule-like constraints, and returns inferred probabilities for policy conclusions.

3. Experiments

The experiments evaluate PL-Guard and three baselines on the full XSTest benchmark using shared Phi-3 generations and separate offline scoring. They measure over-refusal and unsafe compliance, with semantic evaluation provided by an independent Qwen model.

  • Benchmark and methods: XSTest contains 450 examples: 250 safe prompts and 200 unsafe prompts, and compares PL-Guard with an unguarded base LLM, policy prompting, and LLM-as-a-judge.Policy prompting adds the natural-language policy before the user request, while LLM-as-a-judge evaluates and repairs the base response.
  • Metrics and evaluation: Over-refusal measures unnecessary limitations on benign requests, while unsafe compliance measures actionable harmful guidance on unsafe prompts.All four methods generate saved responses with the same Phi-3 backbone before separate offline evaluation.
  • Implementation: All methods use deterministic Phi-3 14B decoding at temperature 0.0, with XSTest generations capped at 512 new tokens.The LLM-as-a-judge baseline also uses Phi-3-medium as its in-loop judge, reducing sampling variance in comparisons.
  • Evaluation: The study reports both deterministic regex-based refusal detection and semantic Qwen-based evaluation, treating Qwen’s labels as estimates rather than ground truth.Qwen evaluates saved outputs only and is distinct from the Phi-3 generator and guardrail inference model.
  • Evaluation: Qwen returns structured judgments covering response class, over-refusal, unsafe compliance, and rationale for each original prompt, gold label, and assistant response.Evaluation uses temperature 0.0, batch size 8, and a maximum of 192 new tokens.

4. Results and Analysis

PL-Guard reduces unsafe compliance more than the LLM-as-a-judge baseline under Qwen evaluation, but with higher over-refusal and comparable runtime. Policy-granularity ablations and qualitative traces show that explicit symbolic structure makes decisions auditable, while excessive detail and grounding failures can limit performance.

  • Main evaluation: 0.5% unsafe compliance and 14.4% over-refusal characterize PL-Guard, compared with 6.0% and 5.2%, respectively, for the LLM-as-a-judge baseline.Unsafe compliance is the more serious safety failure, but PL-Guard incurs greater over-refusal.
  • Main evaluation: 30.43±4.23 seconds per example is PL-Guard’s full forward-phase time, comparable to and slightly faster than LLM-as-a-judge in this configuration.Timing varies with batching, sequence length, and GPU utilization, so the measurement is indicative rather than hardware-independent.
  • Policy granularity ablation: Detailed policies improve both safety metrics, whereas very detailed policies add runtime without further improvement.Runtime rises from 25.92 ± 4.56 seconds for minimal and 25.74 ± 5.11 for moderate policies to 30.43 ± 4.23 for detailed and 32.48 ± 4.86 for very detailed policies.
  • Interpretability: PL-Guard exposes grounded predicate probabilities and ProbLog rule probabilities, allowing errors to be localized to grounding, policy coverage, thresholds, or response repair.The architecture is intended to expose rather than conceal the safety-helpfulness tradeoff behind a single opaque verdict.

5. Limitations and Future Work

PL-Guard’s evaluation is limited by narrow benchmark and evaluator coverage, uncalibrated neural predicate grounding, and a policy interface whose detail can add grounding noise. Future work should broaden evaluation, calibrate grounding, systematize policy construction, and assess response repair.

  • Evaluation limitations: Evaluation is restricted to XSTest, one generator family, and one offline semantic evaluator, while the regex diagnostic is brittle and the Qwen judge may inherit LLM-evaluator biases.Future work should test broader safety benchmarks, generator families, and human or multi-evaluator annotations.
  • Grounding limitations: Neural predicate grounding is not calibrated, so renormalized True/False token probabilities can misrepresent policy-relevant facts that determine all subsequent symbolic reasoning.Proposed remedies include temperature scaling, learned affine calibration, validation-set threshold tuning, and category-specific calibration.
  • Policy interface and future work: The symbolic policy interface is a design choice: richer predicates and rules may improve performance, but excessive detail can plateau and introduce grounding noise.Future work should systematize predicate-set construction, validation, and revision, using diagnostic traces to identify missing factors such as authorization, privacy, and procedural enablement.

6. Conclusion

PL-Guard separates neural predicate grounding from probabilistic symbolic policy reasoning in a neurosymbolic guardrail architecture. On XSTest, it reduced unsafe compliance while making guardrail decisions more inspectable than a single free-form judge verdict.

  • Conclusion: PL-Guard separates neural predicate grounding from probabilistic symbolic policy reasoning.It maps prompt-response pairs to uncertain policy predicates and uses ProbLog for rule-level safety inference.
  • Conclusion: PL-Guard makes guardrail decisions more inspectable than a single free-form judge verdict.Its intermediate representation consists of uncertain policy predicates and inferred rule-level safety outcomes.
  • Conclusion: On XSTest, PL-Guard substantially reduced unsafe compliance compared with the base model and LLM-as-a-judge baseline.The conclusion reports this reduction as a central empirical result of the architecture.

Appendix A. Policy Granularity Artifacts · Supplementary Material

Appendix A shows that PL-Guard’s policy artifacts are generated offline and kept fixed during inference. The example policy combines natural-language guidance with granular ProbLog subrules that separately diagnose unsafe compliance and over-refusal.

  • Appendix A. Policy Granularity Artifacts: Policy variants, predicates, and ProbLog artifacts are produced once per policy and remain fixed during per-example inference.Inference grounds the fixed predicate set and evaluates the fixed ProbLog program; supplementary material contains complete templates and the full policy artifacts.
  • Appendix A. Policy Granularity Artifacts: The policy directly answers benign requests while refusing actionable instructions for harm, crime, abuse, evasion, and dangerous wrongdoing.It also specifies brief refusals that state the limitation and redirect users to safe alternatives.
  • Appendix A. Policy Granularity Artifacts: Educational, definitional, explanatory, risk-awareness, fictional, hypothetical, historical, journalistic, and analytical discussions are allowed when they omit actionable wrongdoing guidance.Figurative or idiomatic language is treated as benign unless real-world harm is clearly requested.
  • Appendix A. Policy Granularity Artifacts: The policy additionally guards against over-refusal in benign discussions involving protected classes, discrimination, privacy, violence, or illegal topics.These conditions preserve assistance in benign analysis and explanation contexts.
  • Appendix A. Policy Granularity Artifacts: Unsafe-compliance subrules combine prompt categories with response details, steps, or evasion, covering wrongdoing, weapons, chemical/biological/medical, cyber, fraud, and abuse scenarios.Examples include unsafe_wrongdoing_steps, unsafe_weapon_details, unsafe_cyber_evasion, and unsafe_abuse_steps.
  • Appendix A. Policy Granularity Artifacts: Over-refusal subrules detect refusals for benign education, fiction/history/news, policy or ethics, figurative language, and sensitive-class contexts.Each subrule pairs a benign or contextual prompt predicate with response_refuses.
  • Supplementary Material: The complete symbolic artifact includes aggregate over_refusal rules and defines safe_response as the absence of unsafe_compliance and over_refusal.The appendix presents abbreviated predicate names while preserving the detailed policy’s structure.

Appendix A. Overview … C.1.2. Predicate Inventory

The appendices provide reproducible XSTest prompts and policy artifacts across four granularity variants. They specify baseline, judge, repair, grounding, evaluation, and symbolic-policy components, including the minimal policy’s predicates.

  • Appendix A. Overview: The supplementary material supplies exact prompt templates and policy files for reproducibility across minimal, moderate, detailed, and very detailed variants.
  • Appendix B. Prompt Templates: Appendix B defines runtime-substituted templates for direct base generation and policy-prompted generation using the safety policy and user request.
  • B.3. LLM-as-a-Judge Baseline: Judgment Prompt: The LLM-as-a-judge baseline evaluates the policy, user request, and assistant response, returning a JSON verdict, rationale, and violated-policy text.
  • B.4. LLM-as-a-Judge Baseline: Repair Prompt: The judge repair prompt combines the policy, request, earlier response, and safety judgment to produce a helpful answer, brief refusal, or safe alternative.
  • B.5. PL-Guard Predicate Grounding: PL-Guard grounds each selected-policy predicate by scoring the next-token probabilities of exactly True and False for the request-response pair.
  • B.6. PL-Guard Symbolic Repair: PL-Guard’s symbolic repair prompt supplies ProbLog rule probabilities and action labels, distinguishing refusal or rewriting from helpful or direct answers.
  • B.7. Qwen Offline Evaluator: The offline Qwen evaluator uses XSTest gold labels to classify responses and flag over-refusal or unsafe compliance according to explicit definitions.
  • Appendix C. Policy Artifacts / C.1. Minimal Policy / C.1.1. Natural-language Policy / C.1.2. Predicate Inventory: Each policy variant contains natural-language rules, grounding predicates, and a ProbLog program; the minimal policy covers helpful safe answers, harmful-request refusals, and benign sensitive contexts.Its predicate inventory includes request_is_harmful, response_provides_harmful_instructions, response_refuses, and request_is_benign_sensitive_context.

C.1.3. ProbLog Policy … C.2.2. Predicate Inventory

The policy uses a coarse ProbLog interface with separate rules for unsafe compliance and over-refusal, grounded in predicates describing harmful, refusal, redirect, and benign-context properties. Its natural-language policy directs helpful responses to safe requests, refusals for harmful instructions, and non-refusal of benign sensitive requests.

  • C.1.3. ProbLog Policy: The hand-authored XSTest policy is intentionally coarse, containing one unsafe-compliance rule and one over-refusal rule.The policy is identified as GPT-5.5 hand-authored and minimal.
  • C.1.3. ProbLog Policy: The unsafe-compliance rule derives from a response that provides harmful instructions, while the over-refusal rule combines benign sensitive context with refusal behavior.The rules define unsafe_compliance_actionable_harm and over_refusal_benign_sensitive as policy-level outcomes.
  • C.1.3. ProbLog Policy: The ProbLog interface queries unsafe_compliance_actionable_harm, over_refusal_benign_sensitive, and unsafe_compliance.These queries expose the policy’s target outcomes for inference.
  • C.2.1. Natural-language Policy: The natural-language policy instructs the assistant to answer safe requests directly and refuse harmful, illegal, abusive, or dangerous instructions.Refusals should briefly explain the limitation and offer a safe alternative when appropriate.
  • C.2.1. Natural-language Policy: The policy prohibits refusing harmless requests solely because they mention sensitive topics in benign, fictional, historical, educational, definitional, or figurative contexts.This clause targets over-refusal of requests whose context is non-actionable.
  • C.2.2. Predicate Inventory: The predicate inventory distinguishes actionable wrongdoing, physical or chemical harm, illegal fraud or evasion, and harmful assistant responses.These predicates cover requests for practical wrongdoing, dangerous activity, evasion, and responses containing concrete harmful steps or operational details.
  • C.2.2. Predicate Inventory: Additional predicates identify refusals, safe redirects, benign educational or definitional requests, and benign sensitive fictional or analytical contexts.Safe redirects may provide prevention advice, high-level context, or protective guidance without harmful details.
  • C.2.2. Predicate Inventory: The benign-context predicates cover factual, educational, explanatory, safety, prevention, ethical, risk-awareness, fictional, hypothetical, historical, journalistic, analytical, policy, and figurative requests without actionable harm.They encode contexts that should not by themselves trigger refusal.

C.2.3. ProbLog Policy … C.3.2. Predicate Inventory

The policy separates unsafe-compliance and over-refusal outcomes into ProbLog rules over grounded predicates, with distinct routes for harmful requests and benign contexts. Its natural-language policy and predicate inventory operationalize these distinctions across request context, response behavior, and harmful-content categories.

  • C.2.3. ProbLog Policy: The ProbLog policy adds distinct unsafe and benign-context routes for action selection.It queries unsafe-compliance and over-refusal outcomes separately, alongside an aggregate unsafe_compliance query.
  • C.2.3. ProbLog Policy: Over-refusal rules target benign educational or definitional requests and benign sensitive fictional or analytical requests.These outcomes are represented as separate ProbLog predicates for educational or definitional and fictional or analytical contexts.
  • C.3.1. Natural-language Policy: The natural-language policy directs the assistant to answer benign requests helpfully and refuse actionable instructions for harm or dangerous wrongdoing.Refusals should be brief, state that harmful instructions cannot be provided, and redirect to a safe alternative.
  • C.3.1. Natural-language Policy: The policy allows benign educational, fictional, historical, journalistic, and analytical discussion when responses do not provide actionable wrongdoing guidance.It also treats figurative or idiomatic violent language as benign unless real-world harm is clearly requested.
  • C.3.2. Predicate Inventory: The predicate inventory distinguishes actionable harmful requests involving wrongdoing, violence, chemical or biological harm, cyber abuse, fraud, and exploitation.Request predicates cover practical steps or operational plans across these harmful domains.
  • C.3.2. Predicate Inventory: Response predicates capture harmful operational assistance, refusals, and safe alternatives or prevention.They include steps or tactics, material details, evasion or optimization, refusal behavior, and safety-oriented redirection.
  • C.3.2. Predicate Inventory: Additional request predicates identify benign educational, fictional or historical, policy-analytical, figurative, and protected or sensitive-class contexts.These predicates encode non-actionable context so sensitive topics can be analyzed or explained without automatically implying harmful intent.

C.3.3. ProbLog Policy … C.4.2. Predicate Inventory

The policy separates unsafe-compliance and over-refusal decisions into granular ProbLog queries, using a hand-authored policy and a predicate inventory that distinguishes harmful requests, harmful response content, and benign contexts. Its natural-language counterpart specifies when to allow helpful answers, when to refuse actionable wrongdoing, and how refusals should redirect safely.

  • C.3.3. ProbLog Policy: GPT-5.5 hand-authored a detailed XSTest policy with granular unsafe-compliance and over-refusal rules queried directly for action selection.The ProbLog policy exposes unsafe_compliance and safe_response as final queries.
  • C.3.3. ProbLog Policy: The policy defines over-refusal categories for benign educational, fictional, historical, journalistic, analytical, figurative, idiomatic, protected-class, and sensitive-topic requests.These categories are represented as explicit over_refusal predicates and queried alongside unsafe-compliance predicates.
  • C.4.1. Natural-language Policy: The natural-language policy allows helpful answers for benign explanatory, historical, analytical, fictional, figurative, and protective discussions without actionable real-world harm instructions.It specifically permits benign mentions of sensitive topics when users seek understanding, prevention, ethics, or context.
  • C.4.1. Natural-language Policy: The policy refuses actionable assistance for wrongdoing, including step-by-step harm instructions, illegal exploitation, fraud, evasion, abuse, coercion, and dangerous tactical guidance.Refusals should be brief, safe, and paired with a safe alternative.
  • C.4.2. Predicate Inventory: Response predicates identify step-by-step instructions, specific materials or parameters, evasion guidance, harmful-effectiveness optimization, refusals, and safe redirects or crisis support.These predicates cover procedural, tactical, concealment, refusal, and mitigation characteristics of assistant responses.

C.4.3. ProbLog Policy

The ProbLog policy is a GPT-5.5 hand-authored, very-detailed XSTest policy whose fine-grained subrules are queried directly. It encodes unsafe-compliance and over-refusal predicates across multiple request-response categories, alongside aggregate policy queries.

  • Policy design: The policy is a GPT-5.5 hand-authored, very-detailed XSTest policy.Its policy interface is explicitly authored for the XSTest setting.
  • Policy design: Fine-grained subrules are queried directly so action selection is not confounded by policy size.Direct querying separates subrule evaluation from the number of rules in the overall policy.
  • Unsafe compliance: Unsafe-compliance rules combine harmful request predicates with response predicates for step-by-step instructions, specific parameters, evasion guidance, or harmful-effectiveness optimization.The rules cover weapons, explosives, poisons or chemicals, biological harm, self-harm, cyber intrusion, phishing, fraud, harassment, evasion, and general harm optimization.
  • Policy queries: The implementation queries each fine-grained unsafe-compliance and over-refusal predicate, plus aggregate unsafe_compliance and safe_response outcomes.The query list includes category-specific predicates and final aggregate outcomes.
Loading 2608.15673v1…