【要約】LLMが「本文の無い記事」の要約をでっち上げていた話 ─ プロンプト修正だけで安心しなかった理由 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
個人開発のニュース要約サービス「AgentPick」において、LLMが事実に基づかない要約を生成する問題に直面した。Hacker Newsの記事取得時に本文が欠落していたことが根本原因である。具体的には以下の問題が発生していた。
- ・LLMがタイトルのみから内容を推測し、虚偽の要約を生成。
- ・生成された誤情報が、UI表示、スコアリング、Webhook配信の各層へ波及。
- ・「推測せよ」というプロンプト指示が、情報の汚染を招いた。
// Approach
開発者は、プロンプトの修正という「お願い」に頼らず、システム的な「強制」による二重の防御策を講じた。情報の信頼性を最優先し、以下のステップで解決を図った。
- ・保存直前の層で、本文の有無を機械的に判定するバリデーションを実装。
- ・判定ロジックを個別フェッチャーではなく、全ソース共通のanalyzerに配置。
- ・Algolia APIの既存レスポンスから、追加コストなしで本文（story_text）を取得。
- ・既存の汚染データを削除するためのデータ移行処理を実施。
// Result
一連の対策により、情報の信頼性が大幅に向上し、誤情報の配信を完全に遮断することに成功した。単なるバグ修正に留まらず、以下の成果を得た。
- ・プロンプトの指示無視によるハルシネーションのリスクを最小化した。
- ・共通層での判定により、未知のデータソースに対しても防御が可能となった。
- ・既存の誤った要約をNULL化し、データベースの整合性を回復した。
Senior Engineer Insight
> LLMの出力を扱う際、プロンプトは「確率的な制御」に過ぎない。本件のように、出力が下流の意思決定（スコアリング等）に影響する場合、決定論的なバリデーション層を設ける設計が不可欠である。また、対策前に既存のAPIレスポンスを再確認し、追加のAPIコールを増やさずに実装量を抑えた判断は、極めて実戦的で優れたエンジニアリングである。