zhichao1208/reduce-hallucination

reduce-hallucination は何をしますか？

尋問科学が知識のある証人に真実を語らせるために用いる実証された手法を、LLMエージェント向けの標準監査に変換します。各LLMノードは証人です。ノード間の受け渡しは証言の筆記録です。ユーザーによる修正とタスク記録は物的証拠です。

理論とエビデンスは references/ にあります。各主張の引用については references/research-map.md をお読みください。

三つの鉄則

1. 証拠なくして非難なし（ウェルマンの規則）。すべての発見は、それが対象とする実際のプロンプト、スキーマ、または出力を引用しなければなりません。引用のない疑念は「検証待ち」リストに入れられ、発見には含まれません。
2. 表面のシグナルは真実を証明しない。流暢で自信に満ちた詳細なテキストは、簡潔なテキストよりも正確であるとは限りません。人は行動から欺瞞を読むのは偶然のレベルです。内容のみを判断してください：根拠付け、一貫性、引用されたスパンが存在するかどうか。
3. 自己修正には新たな外部シグナルが必要。「本当ですか？もう一度確認してください」という新しい証拠のない指示は精度を低下させます。すべての再チェックには、取得した結果またはバリデーターの出力を注入する必要があります。

良い引用の三本柱

引用の品質は、難易度と価値の昇順に、次の3つのチェックに分解できます。

柱	質問	現在の状況
忠実	引用は逐語的に実在し、主張は捏造されていないか？	ほぼ解決可能：逐語的文字列マッチング＋棄権。
関連	ソースは質問に関連するトピックか？	ほぼ解決可能：検索品質＋一貫性プロービング。
支持	ソースは主張を支持しているか、矛盾しているか、中立か？	フロンティア。困難であり、まれな「矛盾」クラスがシステムの最も弱い部分です。

実在のトピックに関連した箇所を引用しているが、実際には主張を支持していない（「ミスグラウンディング」）ことは、引用がないことよりも悪質です。なぜなら、誤った主張に対して信頼を偽造し、レビュアーの唯一の有効な防御策（内容の確認）を無効にするからです。バックエンドで検証せずに引用を表示することは、ハルシネーションをより危険にします。

監査プロトコル

フェーズ1 — 各証人を取り調べる（プロンプト + スキーマのレッドフラグ）

LLMノードごとに、レッドフラグリストを実行します。各フラグは1つの尋問違反です。

#	レッドフラグ（探すべきもの）	なぜ重要か	害
R1	null/unknown オプションのないenumフィールド、「Xの確認を出力する」という一方通行の指示。	回答を強制すると、コンプライアンス（虚偽の自白に類似）が生じます。	強制的な推測、自信に満ちた捏造。
R2	散文で棄権を認めている（「存在しない場合はnullを使用」）が、スキーマにnullがない。	スキーマが優先され、棄権は無効になります。	静かな捏造。
R3	プロンプトが証拠/引用を求めているが、それをチェックする下流の処理がない。	検証せずに伝えることは、モデルに説得力のある引用を捏造することを教えます。	偽のアンカー。
R4	方向性のある指示：「控えめに」「仮定する」「推測する」「デフォルトでは」。	一方通行の推定。R1と組み合わさると体系的なバイアスが生じます。	一方向に偏った出力。
R5	単位が定義されていない集計フィールド（「合計年数」「総合スコア」）。	測定値は、固定される前に単位を宣言する必要があります。	定義の不一致が抽出エラーとして読み取られる。
R6	タスクから外れた少数ショット例、または引用なしの推論をモデル化したもの。	例は「良い」回答の期待値を設定します。	間違った出力スタイルを教える。
R7	ノードがツールを持っていないことを実行できるとプロンプトが主張している。	誤った前提。	捏造されたプロセスナレーション。
R8	ユーザーまたは上流ノードから渡された「事実」が、ソースタグなしで真実として使用されている。	検証された証拠とのみ対峙すること。	前提の汚染。
R9	必須スロットがあり空の分岐がないテンプレート。	テンプレート版の回答強制。	空白が最も近い値で埋められる。
R10	新しい証拠なしに攻撃的に再チェック/再試行を書く（「あなたは間違っていた、直せ」）。	追従行動が正しい回答を覆します。	正しい回答が覆される。

各違反を記録：ノード | R# | 引用テキスト | 一行の結果

フェーズ2 — 筆記録を監査する（ノード境界 / データフロー）

ここでほとんどのパイプラインハルシネーションが発生します。データフローを描き、各エッジをチェックします。

1. 不確実性が境界を越えているか？ 上流の confidence / missing_fields / null / メモ — 下流でそれらを消費しているか、それともテンプレートがそれらを平坦化してアサーションにしているか？「死文」の不確実性を探す：生成されたが読み取られていないもの。
2. 出所は失われているか？ 上流の推論が「仮定/推測」と認めた値が、下流ではマークなしの事実になる。スキーマは stated | inferred | absent を伝達するべきです。
3. 事実カテゴリが混線しているか？ 設定や要件データが、ユーザー/文書が主張したかのようにレンダリングされている。
4. 集計値が単位を変更しているか？ 上流の「医療経験年数合計」が下流で「タイトルXとしての年数」になる。
5. LLMが決定論的計算を行っているか？ 日付計算、合計、プロンプト内のカウントはコードステップに移動すべきです。

フェーズ3 — 物的証拠と照合する（タスク記録が存在する場合）

1. サンプルのタスクについて中間ノード出力を取得します（ユーザー修正や失敗があるものを優先）。
2. 最終出力と各ノードの中間出力、生の入力をフィールドごとに比較し、どの境界で最初に真実が失われたかを特定します。
3. 以前の矛盾した発言を見つけます：同じフィールドがノード間で自分自身と矛盾している。
4. 修正に方向性がある場合（系統的に一方通行）、フェーズ1のR4方向性指示を再確認します。ランダムエラーは入力品質の問題を示します。
5. 正直に分類します：「決してソースになかった情報」（プロセスギャップであり、ハルシネーションではない） vs 「入力にはあったが誤って記述された情報」（真のハルシネーション）。

フェーズ4 — ランク付けされた修正（ROI順）

レイヤー1 — プロンプト/スキーマ（構造変更なし）

• R1/R2ごと → null/unknown enum + 汚名をそぐ1行（「Xは正しく、期待される回答です」）を追加。
• R9ごと → テンプレートに空の分岐を追加（アサーションが未解決の質問になる）。
• R5ごと → 単位を分割するか、範囲 {floor, ceiling} を出力。
• R3ごと → 重要なフィールドに {value, source, evidence_quote} のトリプルを追加。

レイヤー2 — 決定論的コードバリデーター（LLMコストゼロ）

バリデーター	チェック内容
Enumホワイトリスト	フィールド値が許可セットに含まれている。
引用文字列マッチング	evidence_quote が引用元に逐語的に存在する。存在しない場合は拒否または格下げ。
フィールド間一貫性	合計が整合する。missing_fields が入力された値と矛盾しない。
単位計算	日付差分/合計はコードで実行。LLMは意味抽出のみ行う。
出口契約	ユーザーが見えるすべての事実スロットが空でなく、許可されたソースフィールドから来ている。

ユーザーに見えるコンテンツを生成するノードの前に配置します。失敗した場合は、フォールバックフラグを書き込み、未解決の質問または人間にルーティングします。

レイヤー3 — LLM相互尋問ノード（LM vs LM）

• 対象の出力とソース文書のみ（汚染されたコンテキストは除く）を受け取る独立したノード。
• 反駁するようにタスクをフレーズする：「反論してみてください：この出力のすべての主張はソース文書に遡りますか？遡らない主張をリストしてください。」
• {verdict, offending_claims[]} を出力。重要度の高いフローでは、順序を変えて再質問し、一貫性投票を行います。
• コスト：タスクあたり+1回のLLM呼び出し — ユーザーに見える出口または重要度の高い判断にのみゲートします。

フェーズ5 — レポート

# ハルシネーション監査 — {エージェント}
## 一行の評決
## エビデンス概要（監査対象ノード / バージョン / タスクサンプル / 修正サンプル + 方向）
## 発見（各：場所 | R# | 引用テキスト | 結果 | 修正#）
## データフローマップと死文チャネル
## 修正推奨（レイヤー1/2/3、それぞれが排除する発見にタグ付け）
## 検証待ち（十分な証拠のない疑念とその取得方法）
## 正直な境界（どの修正がプロセスギャップでありハルシネーションでないか、この監査がカバーしなかったこと）

フロンティアとしての支持性（オプションの拡張）

忠実 + 関連は最低条件です。未解決の問題は支持性です：引用されたソースは主張を支持、矛盾、または中立ですか？研究からの2つのメモ：

• スタンス＋程度としてモデル化します。三者間スタンス（含意/矛盾/中立）は、部分的または条件付きの支持を見逃します。これが規制や法律テキストの大部分です。「部分的/条件付き」フラグを追加し、人間のレビューに回します。
• 支持性は意図に対して相対的です。 同じ箇所が「私たちは遵守しています」を支持し、「私たちにはギャップがあります」と矛盾するのは、ユーザーが何を主張しているかに依存します。スタンスや意図が不確定な場合は、支持するソースと矛盾するソースの両方を提示し、ユーザーに選択させます。方向性を評決ではなく、レビューを促すフラグとして提示します。

留意点

• プロンプトが「衝撃的に悪い」場合、まず自動生成された定型文かどうかを確認します（繰り返しのRole/Objective/Taskがその兆候です）。「このジェネレーターの体系的な問題」が、エージェントごとに同じ欠点をリストするよりも優れています。
• 1つのエージェント内で対比します：どのフィールドがクリーンでどのフィールドが失敗しているか。その違いが通常答えです（unknown オプションを持つフィールドはクリーンである傾向があります）。
• レポートを平易な言語で編集するパスを実行します：発見は理論を読んでいない人にも理解可能でなければなりません。

---

関連スキル

信頼性が高く明確なコミュニケーションのための、オープンエージェントスキルの小さなファミリーの一部です。

• reduce-hallucination — LLMエージェントの監査、根拠付け、引用、棄権。
• better-doc — クラシックスタイル＋Smart Brevity。
• numbers — 数字を意味のあるものにし、クリーンに表示します。