意見抽出の忠実性（pipeline step1）
pipeline の最初の段 extraction は、生コメントから「意見」を LLM で切り出す。ここでは翻訳・要約・分割が同時に起き、原文の意味が静かに書き換わっても出力は流暢な日本語のままになる。抽出の誤りはそのまま embedding → クラスタ → ラベルへ流れ込むので、地図全体が誤った前提に立つ。このページは「抽出が忠実か」を判断するための durable な枠組みをまとめ、dated な実測は 2 枚の analysis に送る（local-llm-extraction-faithfulness-2026-10-05 / extraction-faithfulness-public-models-2026-10-08）。
広聴AI は 構造把握スタンス のツールで、読み手に原文へ戻らせて構造を読ませる。抽出が意味を変えると、その「読み」の土台が崩れる。
完走 ≠ 意味保持
抽出には性質の違う 2 つの失敗がある。混同しない。
- 抽出が失敗して回答が欠落する — 通信失敗・タイムアウト・不正 JSON・キー欠落など。これは 検出できる ようにしてある。
extract_batch()は失敗を回答 ID と理由に対応づけてExtractionBatchErrorで分析を中断し（#905、PR #910、ラベル段の追跡は #915）、原文付きの診断を公開出力と分けた非公開ファイルに書く。正常な空リスト（その入力に対象の意見が無い）と失敗を取り違えないことが要点。issues-response-plan-2026-09-07 - 抽出は成功したように見えるのに意味が書き換わっている — こちらが本ページの主題。出力は文法的に正しく流暢なので、原文を読める人がいないと誰も気づけない。パイプラインが最後まで動いて地図が出ても、ここが崩れていれば全体が誤る。「完走したから成功」とは判定しない。
モデルサイズ別の典型的な書き換え
型は モデルの大きさより系統で分かれる。小型ほど頻度と深刻さが増し、流暢さが誤りを隠す。以下は 2 枚の analysis で実測した型で、具体モデル・件数は各 analysis を見る。
| 型 | 中身 | 主に出た規模 |
|---|---|---|
| 主体の逆転 | 他人の主張・噂・発表を投稿者の主張にする。疑い・保留を断定にする | 小型（数B）で顕著。中〜大型では元の形は出にくいが、英語の条件文の前件が主張に化ける型は残る |
| 否定・条件の取りこぼし | 「知らない」→「事実ではない」、条件文の条件を落として主張化 | 全規模 |
| 皮肉の額面受け（極性の逆転） | 表面の褒め言葉をそのまま肯定意見にする | 中〜大型でも起きる。大きさに依らない |
| 「〜すべき」への強め | 可能性・提案（「〜てもいい」）を義務に強める | 全規模。一部は既定プロンプトが教えていた（下記） |
| 事実文の意見化 | 事実の記述を無理に意見へ | 全規模 |
| 感情の評価語化 | 「ありがたい」→「有益」など感情を評価語に置換 | 全規模 |
| 短い命令の脱落 / 反復の水増し | 「帰れ」を空にする、同語反復を複数意見に割る | 小〜中型 |
最も危ないのは 主体の逆転と皮肉の極性逆転。意見の向きが逆になり、下流で賛否を取り違える（後述）。
既定プロンプトの few-shot が出力に漏れる
抽出プロンプトの入出力例（few-shot）は、モデルに「何を抽出するか」だけでなく「どう書き換えるか・どんな語調にするか」まで伝播させる。
- 既定の入出力例が入力の「〜する必要がある」を出力で「〜すべき」に言い直しており、義務の強めを教えていた。これは #964 / PR #965 で入力どおりに戻し済み（現行 main の既定例は言い直さない）。例文は忠実性の観点で監査する。
- 小型モデルは、短文・挨拶で 入出力例の文そのものを返す ことがある（「帰れ。」に例文の AI の文が返る等）。形式は正しいのでパースを通り、意見として数えられてしまう。
- 既定の入出力例は同梱データ
example-polisのコメントから作られている。example-polisで抽出を評価すると、一部はモデルが答えを例で見ている。評価データとプロンプト例は分ける。
規則＋「先に真意を確かめる」プロンプトとその副作用
主体・様相・条件・感情・皮肉・疑問・短い命令・空の境界を守らせる規則群に、「意見を書く前に、原文が皮肉・反語かを先に判定し、真意を確かめてから書く」1 行 を足すと、多くの型が止まる（皮肉の読み違いにはこの 1 行が最もよく効く）。調整例と実測は docs/development/extraction-prompts.md（PR #967）と extraction-faithfulness-public-models-2026-10-08 にある。
ただし忠実性を上げる代わりにトレードオフが出る。
- 原文の写しに寄る — 書き換えは減るが、文末表現まで残り、意見として痩せない
- 事実だけの文を空にすることがある
- 常識の要る皮肉は半分ほど残る — 規則の細部を変えると、直っていた皮肉が戻ることもある
したがって規則つきプロンプトは「忠実性を重視する利用者向けの選択肢」であって、万能の置き換えではない。採用時は副作用を説明に添える。
小型モデルは JSON 文法制約が実質必須
抽出は response_format に ExtractionResponse（extractedOpinionList の JSON schema）を渡して呼ぶ。小型モデルを この schema を文法制約として効かせない配信 で動かすと、短文・挨拶・疑問文で解説を書き始めて JSON にならず、抽出段で止まる。Ollama の format、llama.cpp の response_format のように 文法制約として効かせる配信を必須 にする。文法制約を入れても、小型では例文の写しや「原文の前半だけ写して止まる」読みが残るので、小型モデルの採用は別途忠実性で確かめる。
下流で効くのは極性
抽出の書き換えのうち、クラスタリングの結論を変えるのは 極性の逆転。皮肉を額面受けすると、不満の声が感謝・賛成側のクラスタに数えられる。「べき」化・事実化は同じ話題のクラスタ内に留まり、影響は報告に引用される本文の強さに出る。だから忠実性の優先順位は「向き（主体・極性）＞ 語調」。
受け入れ条件に忠実性を入れる
- 完走を成功条件にしない。 地図が出たことではなく、少量の原文照合を通ったことを受け入れ条件にする。
- ローカル完結ルートの品質保証。 API 契約なしでローカル LLM を使うルート（llm-providers / hardware-procurement-local-ai-route-2026-05-31）では、「動くか」だけでなく「意味を保つか」と「JSON 文法制約が効くか」を受け入れ条件に入れる。既定モデル（ELYZA 8B）での日本語入力の挙動は未検証。
- 原文照合の導線。 抽出意見から原文へ戻れる画面と、原文付き診断（公開出力と分離・非公開・実行後に削除）を使い、少量照合 → 全件へ広げる。
- 自動検査は「要確認」の印であって合否の門にしない。 空・入出力例との一致・原文との重なりの機械検査と、LLM judge（judge にも「先に原文の真意を書かせる」形）で、まれな書き換えを人の確認に回す。judge 自体の較正が要る。
- 言語をまたぐ抽出は条件が厳しい。 他言語の原文 → 日本語の意見では俗語・固有名詞・文脈不足が重なる。翻訳を別段に分けるより、規則つきプロンプトで書き換えを減らす方が副作用が小さい場合がある（実測は extraction-faithfulness-public-models-2026-10-08）。
機能要望由来の実装（分類・翻訳・粒度切替など）の記録は interview-feature-requests-2026-10-08 に分かれている。実験の完了・実装・PR 提出・main 反映・利用者提供はそれぞれ別の到達点として読む。
Open Questions
- 既定の ELYZA 8B など、日本語入力の小型モデルで主体の逆転はどの程度起きるか
- 常識の要る皮肉（規則で半分しか直らない）を、別系統モデルの判定で補えるか
- 実際の公聴データ（崩れた短文が多い）での書き換え発生率。公開データは整った文が多く発生率が低い
- UMAP を通す本体のクラスタリングで、極性の逆転がどこまで反対側に数えられるか
- 抽出直後の自動忠実性検査を製品の段として入れる価値（judge の較正コストを含む）