金融LLMの「幻覚」問題にどう向き合う？── 精度と信頼性のジレンマ

大規模言語モデルを金融業務へ適用するとき、避けて通れないのが事実に基づかない出力の問題です。要約に原文にない数値が現れる、存在しない条項を引用する、根拠として挙げた資料が実在しない。こうした挙動は確率的にテキストを生成するという仕組みに由来するもので、モデルの規模を大きくしても完全には消えません。

重要なのは、この性質を欠陥として排除しようとするのではなく、業務のどこに置けば許容できるかを設計することです。本稿では、金融文書を扱う際に生じやすい誤りの類型と、それぞれに対する実務的な抑制手段を整理します。

金融文書で起きやすい誤りの類型

一般的な文章生成と比べて、金融文書では誤りの現れ方に特徴があります。第一に数値の取り違えです。決算資料には前期比、通期予想、セグメント別といった似た数値が並び、モデルはそれらを混同します。桁の脱落や単位の取り違えも起こります。

第二に、時点の混同です。過去の実績と将来の見通しが同じ文書に含まれるため、予想値を確定値として提示する誤りが生じます。金融の文脈では、この区別を誤ると情報の意味が変わります。

第三に、固有名詞の取り違えです。金融機関やファンドの名称は類似したものが多く、同じグループ内の複数法人が同じ資料に登場します。どの法人に関する記述かを誤ると、内容そのものは正しくても帰属が変わり、判断を誤らせます。

第四に、条件の脱落です。「一定の前提のもとで」「特定の顧客区分に限り」といった限定が要約の過程で落ち、断定的な記述になります。原文の情報は正しく使われているのに、条件が消えることで誤った内容になる点が厄介です。

検索拡張生成は前提であって解決ではない

根拠となる文書を検索して与える構成は、無関係な情報の生成を減らす効果があります。ただし、これで問題が解決するわけではありません。検索が適切な箇所を取れなければ、モデルは与えられた不適切な文脈をもとに、もっともらしい誤りを生成します。

金融文書の検索では、表形式のデータをどう扱うかが実装上の難所になります。表をそのまま埋め込みへ変換すると、行と列の対応が失われます。表は構造を保った形で保持し、検索の対象と生成へ渡す形式を分けて扱う必要があります。

もう一つの落とし穴が、資料の版です。過去の資料と最新の資料が同じ検索対象に含まれていると、古い数値を根拠にした回答が生成されます。資料の有効期間を検索条件に含める設計にしておかないと、正しい引用の形をした古い情報が返ります。

出力を検証可能な形に制約する

実務でもっとも効果があるのは、自由なテキストを生成させないことです。抽出すべき項目を定義し、その形式で出力させたうえで、原文と機械的に照合します。数値については、生成された値が原文中に文字列として存在するかを確認するだけで、取り違えの多くを検出できます。

import re

def verify_numeric_claims(answer: str, sources: list[str]) -> list[str]:
    """回答中の数値が出典に存在するかを機械的に確認する。
    存在しない数値は、要約の過程で生成された可能性が高い。"""
    joined = " ".join(sources)
    normalize = lambda s: s.replace(",", "").replace("，", "")
    unverified = []
    for token in re.findall(r"[0-9][0-9,，]*(?:\.[0-9]+)?", answer):
        if normalize(token) not in normalize(joined):
            unverified.append(token)
    return unverified

この照合は完全ではありません。原文の値を組み合わせて計算した結果は照合に失敗しますし、逆に偶然一致する場合もあります。それでも、検出された項目を人が確認する運用にすれば、見逃しは大きく減ります。

あわせて、根拠箇所の提示を必須にします。回答と同時に出典の位置を返させ、利用者がその場で原文を確認できるようにすると、誤りが業務判断へ流れ込む前に止まります。

評価データセットをどう作るか

抑制策の効果を測るには、自社の業務に即した評価用データが要ります。一般的なベンチマークで良い成績を示しても、扱う文書の種類が違えば挙動は変わります。ここを外部の指標に頼ると、導入後に想定と異なる結果に直面します。

作成にあたっては、実際の業務で扱う文書から標本を取り、正解を人手で付与します。労力はかかりますが、数十件規模でも傾向は把握できます。重要なのは件数より、誤りやすい事例を意図的に含めることです。数値が似た項目が並ぶ資料、条件付きの記述が多い資料、そして年度をまたいで数値が改定された資料を優先的に選びます。

評価は一度きりにしません。モデルの更新、プロンプトの変更、検索対象の追加といった変更のたびに回し、以前は正しく答えられていた問いが崩れていないかを確認します。この回帰検査がないと、改善のつもりの変更が別の項目を悪化させたことに気づけません。

不確かさを表明させる設計

モデルは、情報が不足している場合でも回答を生成します。これを抑えるには、答えられない場合の振る舞いを明示的に指示し、その選択肢を評価にも含める必要があります。

実務的な指標として、正答率だけでなく誤答率と棄権率を分けて測ります。誤った回答を返すコストが高い業務では、棄権が増えても誤答が減るほうが望ましい場合があります。単一の正答率で評価すると、この望ましい振る舞いが評価を下げる方向に働きます。

評価用のデータセットには、答えが資料に存在しない問いを一定割合含めます。これがないと、棄権すべき場面での振る舞いを測れません。

業務のどこに置くかを決める

最終的な抑制手段は、責任を伴う判断をモデルに委ねないことです。誤りをゼロにできない以上、誤ったときの影響が小さい工程に配置するのが合理的です。

相性が良いのは、下読みと絞り込みです。大量の資料から確認すべき箇所を提示する用途であれば、見落としがあっても従来の作業に戻るだけで済みます。逆に、生成された内容がそのまま顧客へ提示される用途や、取引の判断に直結する用途では、人の確認を挟む工程を省けません。

この線引きを考えるうえで有効なのが、誤りが発見されるまでの時間です。すぐに誰かが気づく工程であれば、誤りの影響は限定されます。逆に、誤った内容が記録として蓄積され、後から別の判断の前提として使われる工程では、発見が遅れるほど影響が広がります。誤りの検出可能性を用途選定の基準に加えると、判断がしやすくなります。

社内の期待値を揃えることも実務では重要です。試験的な導入で良い結果が出ると、適用範囲を広げたいという要望が自然に出てきます。そのときに拠り所となる基準を先に文書化しておかないと、個別の判断の積み重ねで気づかないうちに線を越えます。

組織としては、用途ごとに許容できる誤りの水準を定め、それを満たさない用途には適用しないという線引きを持つことが要ります。この線引きがないまま適用範囲が広がると、どこかで事故が起きます。

利用者への提示方法も設計の一部です。生成された内容を断定的な文章として見せると、確認を促す意図が働きません。根拠が確認できた項目とできなかった項目を視覚的に区別し、後者には確認を求める表示を出すだけで、利用者の扱い方が変わります。

運用開始後は、誤りが見つかったときにそれを記録して蓄積する仕組みを用意します。誤り事例の蓄積が、評価データセットの拡充と抑制策の改善の両方に直結します。現場が気づいた誤りを報告する経路がないと、同じ種類の誤りが繰り返されます。

まとめ

金融領域での言語モデル活用は、幻覚をなくす方向ではなく、誤りが業務判断へ流れ込まない構造を作る方向で設計します。検索拡張は前提として整えたうえで、出力を検証可能な形に制約し、数値と根拠を機械的に照合し、答えられない場合の振る舞いを評価に含める。そして、誤りの影響が小さい工程から適用する。この積み重ねが、実用に耐える運用につながります。

金融テクノロジー総合研究所では、金融特化 LLM の適用設計、検索拡張基盤の構築、出力検証の仕組みづくりを受託しています。用途の切り分けからご相談いただけます。お問い合わせよりご連絡ください。

FTL の技術スタックと受託開発の進め方は FTLの技術とは？にまとめています。