用提示工程讓大模型自己檢查自己：CoVe方法有效減少幻覺

LLM幻覺問題至今沒有根治方案。RAG能緩解一部分，但成本高、架構復雜，而且只適用于有外部知識源的場景。而對于模型"應該知道但經常搞錯"的那類問題，比如歷史事件的時間線、人物履歷的細節，RAG幫不上什么忙。

Chain-of-Verification（CoVe）的思路是既然模型會在生成時犯錯，那就讓它生成完之后再檢查一遍自己的輸出，把能發現的錯誤糾正掉，然后再給用戶看。

聽起來像是廢話？關鍵在于"怎么檢查"。

直接讓模型審視自己剛寫的東西，它大概率會堅持原有立場，這是確認偏差在作祟。CoVe的核心貢獻是發現了一個繞過這個陷阱的方法：驗證時必須把原始輸出藏起來，讓模型在"失憶"狀態下重新回答事實性問題，然后用這些獨立驗證的答案去校對初稿。

某種意義上，這是給LLM裝上了"系統2"思維：快思考先出初稿，慢思考再做驗證。

工作流程：起草、規劃、驗證、修復

CoVe不是什么新的模型架構，它是一種提示編排模式，它把生成過程拆成四步：先讓模型寫初稿（這時候幻覺隨便來），然后讓它針對自己的初稿生成一組事實核查問題，接著獨立回答這些問題，最后用驗證過的事實重寫原文。

Factored：真正的關鍵

前面說的四步里，第一、二、四步都是常規提示工程，用思維鏈就能搞定，而第三步才是核心。

讓LLM一邊看著自己寫的東西一邊驗證，會有一個問題，這個在學術上管這叫"sycophancy"，也就是說模型會順著自己的話往下說。草稿就在上下文窗口里擺著，概率分布會被帶偏，模型傾向于認同自己剛編出來的東西。

所以最簡單的解決辦法是把上下文剝掉。

CoVe論文里發現，回答驗證問題時必須把原始草稿藏起來。舉個例子：如果你問"根據這個草稿，X是不是在1998年發生的？"模型八成會點頭同意自己。但如果你只問"X是什么時候發生的？"它就得老老實實從訓練權重里檢索答案，沒有偏差可言。

隔離驗證問題就是逼模型去查自己的知識庫，而不是復讀自己剛說過的話。

代碼實現

下面是CoVe流程的Python實現，封裝成一個類。注意第三步里的CRITICAL注釋，那就是Factored驗證的精髓。

class ChainOfVerification:
def __init__(self, llm):
self.llm = llm
def run(self, query):
# Step 1: Baseline Generation
# Let the model hallucinate freely here.
draft_prompt = f"Question: {query}\nAnswer:"
draft = self.llm.generate(draft_prompt)
print(f"--- DRAFT ---\n{draft}\n")
# Step 2: Plan Verifications
# Ask the model to identify what needs checking.
plan_prompt = f"""
Context: {query}
Draft: {draft}
Task: Create a list of 3-5 verification questions to check the facts
in the draft. Output ONLY the questions.
"""
plan_text = self.llm.generate(plan_prompt)
questions = self.parse_questions(plan_text)
print(f"--- QUESTIONS ---\n{questions}\n")
# Step 3: Factored Verification (The Key Step)
verification_results = []
for q in questions:
# CRITICAL: Do NOT include 'draft' in this prompt context.
# We want the raw model weights to answer this, uninfluenced by the previous lie.
verify_prompt = f"Question: {q}\nAnswer:"
# Low temperature is crucial here for factual retrieval
answer = self.llm.generate(verify_prompt, temperature=0)
verification_results.append((q, answer))
# Step 4: Final Synthesis
# Now we bring it all together.
verification_context = self.format_pairs(verification_results)
synthesis_prompt = f"""
Original Query: {query}
Draft Response: {draft}
Verification Data:
{verification_context}
Task: Rewrite the Draft Response to be fully accurate.
Remove any details contradicted by the Verification Data.
"""
final_response = self.llm.generate(synthesis_prompt)
return final_response
def parse_questions(self, text):
return [line.strip() for line in text.split('\n') if '?' in line]
def format_pairs(self, pairs):
return "\n".join([f"Q: {q}\nA: {a}" for q, a in pairs])

CoVe和RAG該怎么選？

每次聊到CoVe，總有人問：為什么不直接用RAG？

兩者解決的是不同問題。

RAG適用于模型根本不可能知道答案的場景，比如你公司Q3的銷售數據。CoVe適用于模型理論上應該知道、但可能搞混或偷懶的場景，比如按時間順序列出紐約市歷任市長。

而且研究表明兩者可以混用：先用CoVe驗證RAG檢索回來的文檔是否真的相關，再決定要不要用。代價是成本翻倍，但在醫療、法律這種高風險場景下，還是可行的。

從Vibe Coding到系統2代理

關注2026年初Agentic爆發的人，大概都聽過"Ralph Wiggum"技術這個梗。

名字來自《辛普森一家》里那個喊著"我在幫忙！"卻啥也沒干成的角色。這技術的核心就是把LLM塞進一個while循環，讓它反復嘗試直到單元測試通過。暴力驗證，Token消耗會爆表但最后確實能撞出正確答案。雖然聽起來很好笑，實際上還挺管用。

工具增強版CoVe

opencode、OpenDevin、Windsurf這些現代自主代理已經在用"工具增強"版本的CoVe了。

它們不再只是問自己"這代碼對不對"，而是直接動手：先寫代碼，然后在沙盒里跑npm test或linter，讀stderr輸出，根據真實報錯來修。

這就把CoVe的驗證環節從概率猜測變成了確定性判斷。

2026年的新拓撲：分支驗證

最前沿的做法已經不是簡單的線性循環了。是分支。

分支拓撲下，代理不是失敗了就重試一次。它會同時提出三個修復方案，在三個隔離容器里并行跑，哪個能讓構建變綠就提交哪個。

驗證的消耗

這是2026年工程實踐必須面對問題

Vibe Coding走系統1路線：快、便宜、但有20%左右的幻覺率，做原型夠用。系統2代理反過來：慢、Token成本翻10倍、但可靠性過硬，生產環境離不開。

也就是說是拿計算資源換安心，當業務從聊天機器人升級到自主工程師，這筆成本不是能不能接受的問題，而是必須付的保險費——除非你想承擔"Ralph Wiggum式"的風險，比如AI自己把數據庫刪了。

總結

CoVe的代價很明確：延遲。

生成初稿、生成問題、并行驗證、綜合重寫，整套流程跑下來，Token消耗和響應時間基本翻四倍。對于實時聊天場景，這個延遲可能難以接受。但換個角度看，異步報告生成、代碼審查、自動郵件起草這類任務，多等幾秒換來輸出可信度的大幅提升，這筆賬怎么算都劃算。

更值得關注的是CoVe帶來的轉變：過去幾年，行業把大量精力投入到"如何讓模型生成得更好"上——更大的參數、更多的數據、更精細的對齊。CoVe指向了另一個方向：與其追求一次生成就完美，不如承認模型會犯錯，然后在架構層面把糾錯機制build進去。

這和軟件工程的演進路徑很像。早期寫代碼追求一次寫對，后來發現測試驅動開發、持續集成、灰度發布這些"驗證優先"的實踐才是規模化的正確姿勢。

CoVe不會是終點，我們未來大概率會看到更多CoVe與RAG、外部工具、多模型交叉驗證的組合方案。

https://avoid.overfit.cn/post/1f3da2d8396d44c6bab8bfea80405cb6

作者：Digvijay Mahapatra