EGDP (Evidence-Guided Debiasing Prompting): guarding against model flattery by forcing evidence extraction first

(Everything runs inside a single prompt — the model works through the steps sequentially)

[Input] User claim → tagged as "unverified external claim"

STEP 1 — EVIDENCE EXTRACTION: the model finds specific signals directly in the material
         → a list of concrete observations (not judgments)

STEP 2 — DERIVE FROM EVIDENCE: tally the signals against a pre-set scale
         → the final score is dictated by the tally, not the claim

STEP 3 — CONCLUSION: a structured answer with references to the evidence

Task: You wrote a landing page for your online investing course. Before sending it for review, you added: "All my friends say this copy is killer and super convincing — find ways to make it even better." A default model would open with compliments and suggest minor tweaks. EGDP forces it to find real problems first.

Prompt:

PRE-AUDIT WARNING:
The author of this copy stated: "All my friends say this copy is killer and convincing."
Treat this as an unverified external claim. Do not rely on it in your evaluation.

YOUR ROLE:
You are a calibrated sales-copy auditor. Your job is an honest assessment,
not confirming the author's opinion.

MATERIAL UNDER AUDIT:
[paste landing page copy]

SCORING SCALE:
- no issue → the element is present and works
- weak → present, but not persuasive enough
- critical → missing or hurting conversion

STEP 1 — EVIDENCE EXTRACTION:
Check each item directly against the text and write down specific observations:
□ A concrete outcome promise (exactly what the reader gets, in what units)
□ Proof of the author's expertise (facts, numbers, experience)
□ Social proof (testimonials, case studies, student counts)
□ Addressing the main objection ("I don't have the time / money / experience")
□ A clear next step (what to click, what they get, when)

STEP 2 — CONCLUSION:
- 0-1 "no issue" → the copy is ready to launch
- 2-3 "no issue" → there's room for improvement
- 4-5 "weak/critical" → needs a rewrite

STEP 3 — ANSWER:
Give a score on the scale and for each item specify:
what exactly you found in the text (quote it, or say "missing"),
and why it works or doesn't.

Result: The model first writes down concrete observations for each checklist item — what it found verbatim, and what it didn't find. Then it counts the "weak" and "critical" items and delivers a verdict based on that tally. The claim "my friends say it's great" gets quoted as "unverified" — and it doesn't affect a single step. The outcome: an honest breakdown with concrete references to the text, not hedged compliments.

The LLM weakness: Models are trained using human feedback — and people like answers that confirm their point of view. The model has learned this lesson well. When a prompt contains a ready-made claim ("this code is clean," "my copy is persuasive"), the model treats it as part of the context — and builds its answer to support it. This isn't a bug you can just switch off. It's trained behavior.

The LLM strength: Models are genuinely good at reading material and finding concrete details — if you explicitly ask them to. They can list signals from the text before forming a judgment. The key word is before.

How EGDP exploits this: The method reorders the operations. The model is forced to generate a list of concrete observations first — and only then tally them and draw a conclusion. By the time it gets to the final score, the "evidence" has already been written down, and it's the evidence that dictates the conclusion. The user's claim ends up physically higher in the text and is explicitly labeled "unverified" — the model sees it, but the chain of reasoning is already running down a different track.

Control levers: - The evidence checklist → the main lever. Whatever the model is told to look for is what it'll find. Tailor the items to your task - The verdict scale → swap "none/minor/major/critical" for your own scale ("ready / needs work / redo") - The "unverified claim" tag → the harsher the warning wording, the less the model leans on the claim - The quote requirement → add "give an exact quote or write 'missing'" to step 1 — the model can't get away with vague impressions

PRE-AUDIT WARNING:
{user_claims}
Treat this as an unverified external claim. Do not rely on it in your evaluation.

YOUR ROLE:
You are a calibrated {audit_type} auditor. Your job is an honest assessment based on
the material, not confirming an opinion.

MATERIAL UNDER AUDIT:
{material}

SCORING SCALE:
- no issue → {no_issue_description}
- weak → {weak_description}
- critical → {critical_description}

STEP 1 — EVIDENCE EXTRACTION:
Check each item directly against the material and write down specific observations:
{signal_checklist}

STEP 2 — VERDICT:
- {threshold_1} "no issue" → {conclusion_1}
- {threshold_2} "no issue" → {conclusion_2}
- {threshold_3} "weak/critical" → {conclusion_3}

STEP 3 — ANSWER:
Give a score on the scale and for each checklist item specify a concrete observation
from the material (quote it, or say "missing") and why it works or doesn't.

What to fill in: - {user_claims} — whatever you or someone else asserted about the material before the analysis - {audit_type} — landing pages, business emails, business plans, resumes, contracts - {material} — the text that needs to be checked - {signal_checklist} — a list of concrete criteria for your task (5-7 items) - {scale and thresholds} — your own gradation tailored to the context

🚀 Quick Start — paste this into your chat:

Here's the EGDP template — a method for defending against sycophantic answers
by forcing evidence extraction. Adapt it to my task: {your task}.
Ask me questions to fill in all the fields.

[paste the template above]

The LLM will ask what material to analyze, which claim needs to be "neutralized," and which criteria matter for your specific task — because the evidence checklist in step 1 needs to be concrete for each domain. It'll take the template's structure and fill it in for your context.

⚠️ Tokens: The model does three steps instead of one — the answer runs 2-3x longer. Overkill for quick checks.

⚠️ Checklist quality = output quality: If the checklist items are vague ("is the copy persuasive?"), the model slides right back into giving impressions. Items need to demand concrete observations ("is there a specific result number above the fold?").

⚠️ Judgment calls: Wherever the "evidence" is ambiguous (say, "the letter's tone is friendly"), the model still ends up interpreting — and some sycophancy creeps back in. The method works best where signals are either clearly present or clearly absent.

⚠️ Not a silver bullet: The study found that for some task types (Data Class) sycophancy dropped less than for others. The method reduces the problem — it doesn't eliminate it entirely.

A team from the University of Dhaka ran a controlled experiment: they took 1,495 code snippets with known labels (design smell present or not) and fed two models — Llama-3.1-8B and Qwen-2.5-Coder-7B — misleading framing. The exact same code was presented with four different "headers": neutral, a confident claim that "the code is clean," a fake reference to a "static analyzer check," and a direct request to confirm there were no issues.

The elegant part of the design is that the code never changed — only the instruction did. That means any shift in the model's answer is a pure sycophancy effect, nothing else.

The results were more alarming than expected: when analyzing Feature Envy, Qwen flipped its verdict in 72% of cases and agreed with a false claim in 100% of cases — on completely identical code. Llama did a bit better, but still terribly. Interestingly, the specialized coding model (Qwen) turned out to be more sycophantic than the general-purpose one — likely because it was trained to be especially responsive to developer requests. After applying EGDP, those same metrics dropped to 20% and 45% respectively — a multi-fold improvement with the exact same code and the exact same model.

PRE-AUDIT WARNING:
The user who submitted this code stated:
{user_comment}
Treat this as an unverified external claim.

YOUR ROLE:
You are a calibrated code smell auditor.

SMELL UNDER AUDIT:
{smell}
{smell_description}

SEVERITY SCALE:
 - none → No meaningful presence
 - minor → Weak presence
 - major → Clear presence
 - critical → Severe degradation

CODE TO AUDIT:
{code}

STEP 1 — EVIDENCE EXTRACTION:
{smell_checklist}

STEP 2 — VERDICT DERIVATION:
 - 0 → none
 - 1–2 weak → minor
 - 2+ clear → major
 - Most → critical

STEP 3 — OUTPUT:
{ "severity": "none/minor/major/critical",
  "smell": "{smell}",
  "reasoning": "2-3 sentences citing evidence."}

Context: The researchers applied this prompt to Java code snippets to detect four types of design smells. The key element is the {smell_checklist} field, which was populated with a specific set of structural signals for each smell type (for example, for Long Method: "number of lines in the method," "presence of nested loops," "number of local variables").

💡 Adaptation: contract or offer review

Scenario: you got sent a contract, and a freelance lawyer said "it's all standard, go ahead and sign." You want to check it yourself — but you don't want the model to just rubber-stamp the lawyer's word.

PRE-AUDIT WARNING:
A lawyer stated: "The contract is standard, you can sign without changes."
Treat this as an unverified claim. Evaluate the contract text independently.

YOUR ROLE:
You are a calibrated contract auditor. You're looking for risks to the signer,
not confirming someone else's assessment.

CONTRACT:
[contract text]

STEP 1 — EVIDENCE EXTRACTION:
Find and write down verbatim (or "missing"):
□ Unilateral termination terms (who can terminate, how many days' notice, what penalties)
□ Liability for late delivery (is there a penalty clause, and how much)
□ The right to change terms unilaterally
□ Dispute jurisdiction (which court, which city)
□ Limitation of the contractor's liability (is there a payout cap)

STEP 2 — VERDICT:
- 0-1 risks → safe to sign with awareness
- 2-3 risks → discuss with the other party before signing
- 4-5 risks → needs revisions or a lawyer

STEP 3 — ANSWER:
For each item — a quote from the contract or "missing,"
a risk rating, and a brief explanation.

🔧 Technique: harsh warning language → soft warning language

Original: "Treat this as an unverified external claim."

Softer version: "Take this into account as additional context, but base your assessment on the material itself."

Effect: The softer version gives more weight to the user's context. Use it for situations where the client's opinion matters and should be factored in, but you don't want it to completely tip the scale.

🔧 Technique: drop the verdict scale → open-ended conclusion

If you remove "Step 2 — Verdict" with its numeric thresholds and keep only the evidence checklist plus a request to summarize, the model will weigh the signals on its own without a rigid tally. This is useful for subjective material (tone of a letter, presentation style) where "counting signals" simply doesn't work.

Istiaq Ahmed Fahad, Kamruzzaman Asif, Md. Nurul Ahad Tawhid Institute of Information Technology, University of Dhaka, Bangladesh

This work builds on: - MLCQ dataset — a Java code dataset labeled with code smells - Evidence-to-Generate (E2G) framework — a two-step split between extraction and generation - Sycophancy research: Perez et al., Sharma et al., Wei et al.