Scientific Knowledge-driven Decoding Constraints Improving the Reliability of LLMs
Organizations: Nanjing University · Tsinghua University · Northeastern University
Abstract
Large language models (LLMs) have shown strong knowledge reserves and task-solving capabilities, but still face the challenge of severe hallucination, hindering their practical application. Though scientific theories and rules can efficiently direct the behaviors of human manipulators, LLMs still do not utilize these highly-condensed knowledge sufficiently through training or prompting. To address this issue, we propose SciDC, an LLM generation method that integrate subject-specific knowledge with strong constraints. By adopting strong LLMs to automatically convert flexible knowledge into multi-layered, standardized rules, we build an extensible framework to effectively constrain the model generation on domain tasks. Experiments on scientific tasks including industrial formulation design, clinical tumor diagnosis and retrosynthesis planning, consistently demonstrate the effectiveness of our method, achieving a 12% accuracy improvement on average compared with vanilla generation. We further discuss the potential of LLMs in automatically inductively summarizing highly-condensed knowledge, looking ahead to practical solutions for accelerating the overall scientific research process. All the code of this paper can be obtained (https://github.com/Maotian-Ma/SciDC).
Figures & tables
| Model | Correctness | Integrity | Efficiency |
|---|---|---|---|
| GPT-5 | 4.6 | 4.0 | 3.0 |
| Claude | 4.6 | 4.6 | 2.6 |
| SciDC | 5.0 | 4.8 | 3.2 |
| Method | Formulation design | Tumor diagnosis | Retrosynthesis | Overall | |||
| validity | success rate | validity | exact match | validity | hit@1 | ||
| GPT-5 | 92.3 | 92.2 | 98.5 | 94.5 | 64.7 | 31.8 | 72.8 |
| Claude-3.5 | 88.6 | 82.6 | 100.0 | 88.5 | 92.8 | 47.3 | 72.8 |
| Qwen3-4B | 43.4 | 43.0 | 97.3 | 59.2 | 84.6 | 25.4 | 42.5 |
| w/o | 56.8 | 56.8 | 94.3 | 4.0 | 63.5 | 0 | 20.3 |
| w SciDC | 71.0 | 43.4 | 100.0 | 66.7 | 100.0 | 52.2 | 54.1 |
| Method | validity | hit@1 |
|---|---|---|
| Template-based | 100 | 31.8 |
| ChemDFM-8B | 88.5 | 6.0 |
| w/o | 51.5 | 0 |
| w SciDC | 100 | 54.4 |
| +11.5 | +22.6 |
| Method | validity | accuracy | Step |
|---|---|---|---|
| Ours | 75.5 | 68.3 | 18 |
| w/o | 63.8 | 24.0 | 13 |
| w/o | 76.0 | 38.6 | 15 |
| w/o | 36.9 | 25.3 | 8 |
| w/o all | 50.9 | 50.4 | - |
Appendix figures & tables4 assets
Supplementary material from the paper’s appendix.
Appendix
| Model | Accuracy(%) |
|---|---|
| Claude Sonnet 3.5 | 86.17 |
| GPT-4 | 85.11 |
| Qwen3-8B | 54.84 |
| Qwen3-14B | 78.26 |
| SciDC (Qwen3-8B) | 78.72 |
| SciDC (Qwen3-14B) | 86.46 |
| Method | Token | Standard | OOD | Average |
|---|---|---|---|---|
| Original | 0 | 43.3 | 39.4 | 41.4 |
| vanilla RAG | 512*3 | 56.7 | 35.6 | 46.1 |
| w wiki | 800*5 | 47.3 | 36.1 | 41.7 |
| w summary | 30*5 | 58.7 | 33.33 | 46.0 |
| w GPT-5 | 50*3 | 52.7 | 38.3 | 45.5 |
| Ours | 30*5 | 56.7 | 38.3 | 47.5 |
| Prompt 1: Task Decomposition |
| # Role Definition You are an expert in reasoning framework design. Your task is: Given a knowledge document [DOC] and a description of a problem class [Q], design a general-purpose Chain-of-Thought Framework (CoT Framework) that describes the standard reasoning path for solving this class of problems. This framework does not target any specific case. It is a reusable solution blueprint that: - Defines WHAT variables need to be extracted from any concrete problem instance - Defines WHAT intermediate conclusions need to be derived and WHICH prior variables they depend on - Defines HOW the final answer is inferred from the above variables and intermediate conclusions # Input Format [DOC] : A knowledge document defining the rules, constraints, standards, or background knowledge required to solve the problem. [Q] : A description of a CLASS of problems (not a specific case), outlining the typical structure and objective of such problems. # Framework Step Specification Every step you design must belong to exactly one of the following three types: Type 1 · Information Extraction Step (Extract) - Goal: Define the variables that must be identified and extracted from any concrete instance of this problem class. - Requirements: - Assign a named variable to each item to be extracted (e.g., VAR_Amount, VAR_ApprovalStatus). - Describe the meaning of the variable and its possible value domain or data type. - Specify the extraction source: from [DOC] (fixed values / thresholds defined by the document) or from the problem instance (values that vary across cases). - Format: [Extract] Variable: <VAR_xxx> Meaning: <what this variable represents> Source: <Document / Problem Instance> Domain/Type: <enumeration | numeric range | boolean | text | etc.> Type 2 · Intermediate Judgment Step (Judge) - Goal: Define an intermediate conclusion or intermediate value that must be derived, and describe its inference logic. - Requirements: - Assign a named variable to the intermediate conclusion (e.g., MID_AmountCompliant). - Explicitly state the derivation logic (conditional expression / rule mapping / comparison). - Explicitly list all variables this step depends on — must be VAR_ or MID_ variables already defined in prior steps. - Format: [Judge] Intermediate Conclusion: <MID_xxx> Inference Logic: <if VAR_xx meets condition → Outcome A; otherwise → Outcome B> Depends On: <VAR_xxx, MID_xxx, ...> Type 3 · Final Conclusion Step (Conclude) - Goal: Define how the final answer is derived. - Requirements: - Explicitly list all variables depended upon (both VAR_ and MID_). - Describe the synthesis logic — how these variables jointly produce the final answer. - Describe the form of the final answer (e.g., yes/no judgment | numeric value | classification label | textual explanation). - If edge cases exist that are not covered by the document, specify a fallback handling rule. - Format: [Conclude] Final Answer: <ANS_xxx> Synthesis Logic: <description of how MID_xx and VAR_xx are combined to reach the answer> Depends On: <VAR_xxx, MID_xxx, ...> Answer Form: <output type and format of the answer> Fallback Rule: <how to handle cases where information is insufficient or not covered> # Output Format ## Problem Class Understanding Summarize in 2–3 sentences the core structure of the problem class described by [Q]: what the input is, what the goal is, and where the key difficulty lies. ## Reasoning Framework Step 1: [Extract] … Step 2: [Extract] … Step 3: [Judge] … Step 4: [Judge] … … Step N: [Conclude] … Knowledge Document [DOC]: {domain_doc} Problem Class [Q]: {_user_prompt} |
| Prompt 2: Code Generation |
| # Role Definition You are a code generation expert specializing in guidance-syntax Python for Small Language Models (SLMs). Your task is: Given a domain knowledge specification [DOMAIN], a domain question [Q], and an ordered Chain-of-Thought [CoT], produce executable Python guidance code that drives an SLM through structured, step-by-step reasoning. The generated code must be deterministic, constraint-respecting, and self-validating. It is a reusable generation blueprint that: - Converts each CoT step into a templated lm += / lm.gen() / lm.select() block - Enforces finite-domain constraints via lm.select() and numeric constraints via lm.gen(regex=...) - Propagates upstream answers into downstream option sets via dynamic dependency logic - Detects and repairs multi-variable constraint violations via cyclic validation loops # Input Format [DOMAIN] : A knowledge specification defining allowed enumerations, numeric ranges, and inter-variable dependency rules. [Q] : The domain question or problem instance to be solved. [CoT] : An ordered list of reasoning steps describing how to reach the final answer. # Code Block Specification Every step in [CoT] must be translated into exactly one of the following three block types: Block Type 1 · Reasoning Step (Step Block) - Format: # --- Step {i}: {step_description} --- lm += f"<|im_start|>user\nStep {i} Question: {question}? Candidates: {candidates}<|im_end|>\n" lm += f"<|im_start|>assistant\nStep {i} Analysis: " lm += f"<think>Now I need to answer the question: {question}" lm.gen(name="analysis_{i}", stop="</think>", temperature=0, max_tokens=256) lm += f"</think>" lm += f"Step {i} Answer: " lm.select([...], name="answer_{i}") #OR lm.gen(regex=r"...", name="answer_{i}") lm += f"<|im_end|>\n" Block Type 2 · Dynamic Dependency Block - Format: prior = lm["answer_{j}"] if prior == "X": options = ["A", "B"] elif prior == "Y": options = ["C", "D"] else: options = ["E"] lm.select(options, name="answer_{i}") Block Type 3 · Cyclic Validation Block - Format: MAX_RETRIES = 5; retry = 0 while retry < MAX_RETRIES: if retry > 0: lm += f"[Retry {retry}] Previous attempt failed: answer{i}={lm[’answer{i}’]} violated {constraint_desc} " lm += f"(upstream: answer{a}={lm[’answer{a}’]}, answer_{b}={lm[’answer_{b}’]}). Adjustment needed.\n" lm += "<think>" lm.gen(name=f"adjustment_analysis_retry_{retry}", stop="</think>", temperature=0, max_tokens=256) lm += "</think>" lm += f"Step {a} Answer: " lm.select([{valid_options_of_a}], name="answer{a}") lm += f"Step {b} Answer: " lm.select([{valid_options_of_b}], name="answer_{b}") lm += "<|im_end|>\n" lm += f"<|im_start|>assistant\nStep {i} Answer: " lm.select([{valid_options_of_global}], name="answer_{i}") lm += "<|im_end|>\n" if {combined_constraint(lm["answer_{i}"], lm["answer_{a}"], lm["answer_{b}"])}: break retry += 1 else: lm["answer{a}"] = {first_valid_option_of_a} lm["answer_{b}"] = {first_valid_option_of_b} lm["answer_{i}"] = {first_valid_option_of_global_given_fallbacks} Domain Knowledge [DOMAIN]: {domain_knowledge} Domain Question [Q]: {domain_question} Chain of Thought [CoT]: {chain_of_thought} |
LLM Hallucination Mitigation
Large language model hallucination mitigation develops ways to detect and reduce unsupported, fabricated, or inconsistent outputs.
See all 175 papers