Evaluating Legal Reasoning Traces with Legal Issue Tree Rubrics

選定理由

Paper: https://arxiv.org/abs/2512.01020
Code: N/A

概要(データセット論文)

【社会課題】
法的推論タスクにおける信頼性評価において、最終的な判決の正誤だけを見ていては不十分。途中の推論プロセスの妥当性を測る手段が必要。

【データの設計と従来技術の限界】
裁判所判決文をIssue Tree（法的論点ツリー）に変換し、葉ノードに対しルーブリック基準を適用可能にした。原告・被告・裁判所の主張をツリー構造で整理した約24,000インスタンスのデータセットを構築。評価軸は「論点カバレッジ」と「正確さ」の2次元。以下がサンプルである：

【原告の主張】被告は540万円を支払え
  └─【原告】保険金の支払い義務がある
      ├─【原告】死亡は突発的・偶発的な事故だった
      │   └─【原告】餅を食べて窒息死＝外因による傷害
      │   └─【被告】死因は既往症の可能性が高い
      └─【裁判所の結論】突発的事故と認定
                        ただし窒息死は証明不十分

このような本質的に tree / DAG 構造であるタスクを従来の基準リストであったRubricで解決するのは不適である。例えば、基準に依存関係があったり、粒度の違いから部分的に正しいといった問題を解決できない。

【品質】
法律専門家によるアノテーションと比較し、Issue Treeベースのルーブリックが単純な正誤判定より人間評価との一致度が高いことを示した

【発見】

• LLMはカバレッジ(論点に対する情報の網羅性)と正確さの両方に弱点を持つ
• RAGはカバレッジを、RLは正確さを改善
• 両者は補完的であり組み合わせが有効

1.Rubricとは？

[Sharma2025]によるとRubricは複雑なタスクに対してタスクを分解した採点基準を定義したものであり、各採点基準は明確な基準、期待値とスコア値（プラス/マイナス）という形式で定義される。以下に簡単な例を示す。

Rubricのスコア計算の具体例

上記タスクのもう少し具体的な基準の例を挙げると

• 社会の主要な領域を少なくとも5つ挙げているか。例えば精神衛生、対人関係、政治/市民参加、情報エコシステム、経済など → +5（各１点で、満点５）
• 政策や規制への言及があるか。例えばSection 230（米国通信品位法）、COPPA、子どものデータ保護法 等 → +3（同様）
• 証拠となる引用なしに一方的・断定的な表現をしていないか。例えば「SNSは精神健康に悪影響を与える」という断定表現のみ → –4（ペナルティ）

各基準に対する評価法も以下がある。

Rubric の利点

従来の単純な自動評価指標（例：BLEU、ROUGE、単一スコア評価）とは違い、次の特徴を持つ。

• 多面的評価項目：具体的な観点（例：事実性・網羅性・根拠の引用・明瞭性など）ごとに細かく評価項目を設計
• 明示的な正解・誤りの指標：間違った断定や引用なし回答などはペナルティ基準として評価できる
• 正確な定量性：1つ1つの基準に重みがあり、合算することで定量評価ができる。又、LLMが苦手とする定量評価を公正にできる。
• ドメインエキスパートの知識活用：Rubrics は専門家が手作業で作成・レビューすることでビジネスドメイン知識を入れ込むことができる。

Rubric設計上の注意点

同じルーブリックをベースにして次の2つの施策を比較した。

1. 具体例の追加(Example Detail)：各評価基準に「良い例」「悪い例」を付ける
2. LLMによる拡張(LLM Augmentation)：LLMを使って評価基準そのものを増やす・書き換える

評価は、LLMの判定と人間評価の一致度（Macro F1）で計測。

結果の表7によると具体例の追加は一貫して評価精度を改善するが、LLMによる拡張は悪化する場合もあった。
これは具体例の追加は意思決定境界を例示することで評価の曖昧さを減少させることができるためと考えられる。一方で、LLMによる拡張は基準の数は増えても有効な情報が増えず、追加される基準は抽象的だったり既存と重複していることが多く、評価の解像度は上がらないことが原因だと思われる。基準が増えることで判定回数が増え、小さな誤差が積み重なって評価が不安定になる。さらに似た観点が重複すると、同じ要素が過剰に評価され、全体のスコアが歪んでしまう。

2.LEGITデータセット

約 24,000件 の事例を含む法律ドメインの LEGIT (LEGal Issue Trees) という新しいデータセットを構築した。各事例は裁判判決を階層的な「イシュー・ツリー（問題ツリー）」 に変換したもので、各ノードは当事者の主張や裁判所の結論を表し、ツリー構造が論理的な流れと法的判断の構造を表現する。

データセットの変換

Korean LBoxデータセットの中から判決が裁判官の裁量を含むもの(non-deterministic by law)を除いた24406サンプルのうち24106サンプルを学習に、300サンプルをテストに使用する。判決文は通常のテキスト文であるが、これをツリー構造に変換する。判決文が持つ情報は大体以下の通り：

事件
├─ 争点1
│  ├─ 原告の主張
│  ├─ 被告の主張
│  └─ 裁判所の判断
├─ 争点2
│  ├─ ...
└─ 結論

これを構築するためにfact extraction, issue structure extraction, issue-to-rubric conversionという3つのステップを踏む。

fact extraction

LLMを用いて判決文から「事実」というエンティティを抽出する。(1)事実リストの抽出(2)事実リストを説明する記述を生成　という2つのステップを踏む。fact はIssue Treeとは別に判決文を説明する文章として活用される。

issue structure extraction

著者が手動で用意した3つの例（3-shot）を使い、Gemini-2.0-Flashに判決文からをIssue Treeを生成する。品質を高めてエラーを減らすため、処理は2段階で行う。まず1回目で生の判決文からIssue Treeを生成し、その後もう一度別のプロンプトを使って修正し、1回目でよく見られる誤りを除去する。
また、論点が多いケースほど事実関係や関連法規も複雑になるため、データセットは論点数に応じて3つの難易度(easy, medium, hard)に分けている。最終的なテストデータは300件で、それぞれの難易度から100件ずつ選ばれており、これらは著者が手動で確認し修正している。

issue-to-rubric conversion

LLM as a judge を行うために、まず論点（issue）ルーブリック基準に変換する。評価時は、LLMはそれぞれの論点を個別に評価する。
具体的には、各論点についてLLMは次の2つを同時に判断する：

• その論点が回答の中で言及されているか（カバレッジ）
• その論点について正しい結論が述べられているか（正確性）

さらに、その判断理由をChain-of-Thoughtとして出力する。最終的なLEGITスコアは10点満点で、最終判決の正しさ、論点の網羅性、論点ごとの正しさの3つで評価される。最終判決が一致すれば5点、不一致なら0点となり最も重要。残りは、論点をどれだけ拾えているかで最大2点、各論点について正しい結論を述べているかで最大3点が加算され、網羅性よりも各論点の正しさがやや重視される設計になっている。