JSONL 根拠マッチングプロンプト観察

作成日: 2026年6月27日

目的

今日は Source Flow Debuggerで実際の DB 検索を組み込む前に、GPT にデモ用の Godot コードチャンクと JSONL 候補を作成させ、LLM がその JSONL を根拠に適切に関連/無関係を判定できるか確認した。

最初の考えはシンプルだった。

SOURCE_CODE + JSONL 候補
  -> この JSONL が source code に該当する内容を含んでいるか？
  -> はい / いいえ

しかし実際にはこの質問だけでは不十分だった。LLMがJSONL内の直接文字列根拠ではなく、Godotに関する自己知識や広いテーマの類似性を利用して「はい」と判断する現象があった。

デモデータ生成

まずGPTに任意のGodotチャンクと関連JSONL、無関係JSONLを作成させた。

要求の意図は次のとおりだった。

任意の Godot チャンクと任意の JSONL を作成する。  
Godot チャンクはわざわざ Godot 3 のコードで作成する。  
JSONL は Godot 4 変換の根拠が含まれたものと全く無関係なものの両方を作成する。  
LLM に投げたとき、関連する JSONL と無関係な JSONL の違いが現れるかテストする。

キャプチャ:

初期プロンプトの問題

最初は次のように尋ねました。

これには jsonl がソースコードに該当する内容が含まれていますか？回答ははい / いいえだけでお願いします。

この方式では、関連する JSONL を入れた場合でも 例 が出て、無関係な JSONL を入れた場合でも 例 が出ました。

関連 JSONL の結果:

無関係 JSONL の結果:

問題は質問があまりにも広すぎた点です。「ソースコードに該当する内容が含まれているか」だけを尋ねると、LLM は Godot、Godot3、Godot4、migration、2D、physics といった広い単語だけを見て関連があると判断できてしまいます。

このようにすると、Retriever が的外れの JSONL を取得した場合でも、LLM が自分の知識で埋めて「例」と答えてしまう可能性があります。これは私たちが求めている検証ではありません。

修正したプロンプト

そこでプロンプトを根拠マッチング判定器に変更しました。

## 日本語訳

あなたは JSONL 根拠マッチング判定器です。

以下の **SOURCE_CODE** に対して、下記の JSONL が直接的な変換根拠を含んでいるか判定してください。

### 判定基準
- JSONL の `source_api`、`source_pattern`、`match_terms`、`required_when_seen_in_code`、`before_code` のいずれかが **SOURCE_CODE** 内の実際の文字列または API 呼び出しと **完全に一致** している場合のみ「**例**」です。
- 単に `Godot`、`Godot3`、`Godot4`、`migration`、`2D`、`physics` などの広い語句が同じであっても、関連性はありません。
- JSONL に「does not describe」「not related」「unrelated」「does not apply」などと **否定的に記載** されている内容は根拠として認めません。
- JSONL が別の API、別のノード、別のシステムに関する内容であれば「**いいえ**」です。
- あなたが持っている Godot の知識は使用せず、JSONL に記載された文字列根拠だけを使用してください。
- 回答は必ず「**例**」または「**いいえ**」のいずれか **一つだけ** 出力してください。

このプロンプトでは、判断基準を「直接文字列根拠」に絞った。

特に、次のフィールドのいずれかが SOURCE_CODE の実際の文字列/API 呼び出しと直接一致しなければならないと制限した。

source_api
source_pattern
match_terms
required_when_seen_in_code
before_code

また LLM が広いトピックと自身の Godot 知識で推論できないようにした。

修正後の結果

関連 JSONL は 例 と出ました。

無関係 JSONL は いいえ と出ました。

この結果から、DB 検索後の LLM 検証段階は単なる意味類似度判定ではなく「検索された JSONL の中に現在のチャンクと直接合致する文字列根拠があるか」をまず確認すべきだという点を再確認した。

本日得た基準

DB 検索結果検証プロンプトは次の基準を持つべきである。

• 広いトピック類似性は根拠として認めない。
• LLM の事前 Godot 知識で不足する根拠を埋めさせてはならない。
• JSONL 内の明示フィールドが現在のチャンクの実際の文字列／API 呼び出しと直接合致している必要がある。
• 否定的に言及された JSONL 内容は関連根拠として認めない。
• 関連／無関係の一次判定は短く強く 例 または いいえ に限定した方が良い。

この基準は明日 DB 検索を組み込む際に重要になる。

docs_chunks, api_mapping, label_prototypes から候補 JSONL を取得した後、Qwen 検証段階は次のように動作すべきである。

chunkText
  -> DB検索でJSONL候補を収集
  -> prompt + chunkText + 取得したJSONL
  -> JSONLに直接文字列根拠があるか判定
  -> 関連のないJSONLは破棄
  -> 関連のあるJSONLのみ、以降の説明/マイグレーション判断の根拠として使用

今日の実験の核心は「LLMが正しく知っているか」ではなく「LLMがJSONLに書かれた根拠だけを見て判定できるようにできるか」だった。これができなければRetrieverが持ってきた無関係な候補もLLMがそれっぽくつなげてしまう。したがって検索品質だけでなく、検索結果検証プロンプト自体も別途設計する必要がある。