2026-06-28 振り返り
今日は Qwen で Markdown を JSONL に収集する作業を一時停止し、その JSONL を後で DB に投入したときにどう検索して取り出すかを考えた。
私たちが作った AST デバッグプログラムは Godot プロジェクトからコードチャンクを抽出する。そのチャンクを基に、DB に入っている docs_chunks、api_mapping、label_prototypes の JSONL をどのように検索して取得するかの戦略が必要だった。そこで A から F まで検索戦略を分けて文書化し、現在の基準では F 戦略を採用した。
現在はまだ Markdown を JSONL に収集している途中なので、実際に DB に入れてリトリーバーで検索するテストはすぐにはできない。そのため今日は 50 件のチェックリストを作り、Qwen に任意の Godot コードを書いてもらうよう依頼した。そのコードに合う任意の JSONL と合わない任意の JSONL も作成し、jsonl + prompt + chunk を一緒に投げたときに Qwen がどう判定するかを確認した。今日は 5 件ほど試しただけでも、この作業は思った以上に手間がかかることがすぐに分かった。
50 件テスト計画と現実
もともとは今日 Godot 機能 50 件すべてをテストするつもりだった。
しかし実際にやってみると理想と現実は違った。まず Godot 3 で関数単位や小さなコードブロックとして頻出しそうな機能 50 件のリストを作り、そのリストを文書にまとめた。そして jsonl + prompt + chunk を一緒に投げたときに Qwen が「はい」または「いいえ」で根拠マッチングを正しく判定するかを見るためのプロンプトテンプレートも用意した。
最初は一つずつ作って確認すれば良さそうだと思った。しかし機能一つをテストするには思った以上に多くの JSONL を作らなければならなかった。
docs_chunks、api_mapping、label_prototypes の三つのテーブルをすべて見なければならず、各テーブルごとに関連する JSONL と全く関係のない JSONL を別々に作成する必要があった。さらに Godot 3 と Godot 4 で文法が同じ場合と、バージョンごとに異なる場合も分けなければならなかった。
共通文法であれば同じコード一つを基準に三つのテーブルの成功 JSONL と失敗 JSONL を入れて検証できる。逆に共通文法でなければ Godot 3 のコードと Godot 4 のコードの両方を作らなければならない。そして Godot 3 基準で作った JSONL を Godot 3 のコードに入れたとき、Godot 4 のコードに入れたとき、Godot 4 基準の JSONL を逆に入れたときまで比較しなければならなかった。
結局今日は 50 件中 5 件程度だけテストした。最初の計画よりはずっと少ないが、むしろこの程度で止めたのが幸いだったと考えた。もし 50 件すべてを手作業で進めて基準が曖昧になることに気付かなければ、はるかに大きく行き詰まっていただろう。
共通文法とバージョン基準
今日のテストで最も大きく感じたのは、Godot 3 と Godot 4 を単純に二つに分けるのが難しいという点だった。
ある機能は Godot 3 と Godot 4 で文法がほぼ同じである。この場合、コード一つだけ見て Godot 3 専用か Godot 4 専用かを無理に判断するのはむしろ不自然だ。共通文法であれば共通文法として扱い、同じコードに対して docs_chunks、api_mapping、label_prototypes の関連 JSONL と無関係 JSONL が正しく分かれるかを見るのが正しい。
逆にバージョン差がある機能はもっと複雑だ。Godot 3 基準の JSONL を作ったときに Godot 4 のコードでも「はい」が出ることがあり、Godot 4 基準の JSONL を作ったときに Godot 3 のコードでも一部フィールドのために「はい」が出ることがあった。特に migration 関連の JSONL は source と target が同時に入るため、単純な文字列マッチングだけでは結果が揺らぐことがある。
そこで今後は JSONL をどのバージョン基準で作ったか と 検査するコードがどのバージョンか を分けて記録する必要があると感じた。同じ「はい」でも共通文法による自然な「はい」か、source/target の文字列が混ざって曖昧になった「はい」かを区別しなければならない。
F1-score 式の記録が必要
テスト結果を単に「成功」や「失敗」だけで書くと、後でパターンを見るのが難しい。
今日考えた方向性は、F1-score をすぐに計算するというより、後で precision と recall のように見られるように生の判定結果を残すことだ。例えば「はい」になるべきところで「いいえ」になったか、「いいえ」になるべきところで「はい」になったか、共通文法なら両側で「はい」になるのが正しいか、migration JSONL で曖昧に判定されたかを別々に記録する。
このように積み上げていけば、後でプロンプトが問題か、JSONL 作成基準が問題か、テーブルごとのフィールド設計が問題かをよりよく把握できるだろう。逆に今のように手作業でざっくり書いておくと、後でなぜその応答が出たのか追跡するのが困難になる。
今日 5 件だけでも曖昧な点がかなり見えた。だから 6 件目以降はテスト戦略をそのまま押し進めるより、記録方法とプロンプト戦略をまず少し変える必要があると思う。
手作業テストの限界
プロンプトをコピーし、コードチャンクを貼り付け、JSONL を一つずつ入れ、Qwen の応答を再度記録する方法はあまりにも非効率的だ。
最初の数件を手でやってみることは基準をつかむのに役立った。実際にやってみて、機能一つにも思った以上に多くの JSONL が必要であること、共通文法とバージョン専用文法を分けなければならないこと、「はい」と「いいえ」の意味が状況によって変わることが分かった。
しかしこの方法を 50 件すべてに繰り返すのは現実的ではない。自分で手作業で入れるとミスも起きやすく、後で結果を比較するのも難しい。
そこで次はデバッグツールを作る方向も考えた。コードチャンク、テーブル種別、JSONL 作成基準バージョン、検査コードバージョン、期待応答、実際の応答を一画面で入力し、Qwen 呼び出し結果が自動で記録される仕組みがあればずっと楽になる。今ウェブで AST と Retriever の流れを確認したように、JSONL マッチングテストも GUI やデバッグページで繰り返せれば良いと思う。
Qwen チャットボットテストデータ生成の検討
今日考えたのは Qwen チャットボットで任意のテストデータを作るプロセスだった。
私が作りたかったのは、検証方法自体を揺らすことができる小さなデモセットだった。例えば Qwen チャットボットに Godot 3 のコードチャンク一つ、Godot 4 のコードチャンク一つ、そして docs_chunks、api_mapping、label_prototypes の形式に合う関連 JSONL と無関係 JSONL を作ってほしいと依頼する方式だ。
問題はチャットボットに単に「正解 JSONL と誤答 JSONL を作って」と言うと、結果があまりにも自然に混ざってしまう点だ。特に共通文法か、Godot 3 専用か、Godot 4 専用か、migration の source と target が同時に入るかによって「はい」と「いいえ」が変わる。だから任意データを作るときも基準バージョン、検査コードバージョン、テーブル種別、期待応答を一緒に書く必要がある。
今日感じたのは、Qwen チャットボットで作る任意テストデータの生成方法とプロンプトをもっと精緻に設定しなければならないということだ。そうすればこのテストの中でも Qwen が自分の知識で大まかに答えているのか、JSONL 内の直接文字列根拠だけを見て判定しているのかを確認できる。
今日の結論
今日は大量にテストした日というより、Retriever検索戦略とQwenチャットボットベースのJSONLマッチング実験がそれぞれ思った以上に手間がかかることを確認した日でした。
最初は50件のテストをすべて実行できると思っていました。しかし実際には5件だけでも十分に多くの問題が見えてきました。Godot 3とGodot 4が完全に分かれるケースもありますが、共通の文法もあり、migration JSONLのようにsourceとtargetが一緒に入って判定が揺らぐケースもあります。
そこで今必要なのは、テスト数を無闇に増やすことではなく、テスト結果を正しく残す構造です。JSONL生成基準バージョン、検査コードバージョン、テーブル種別、期待応答、実際の応答、曖昧な理由を記録する必要があります。そうすれば50件すべてを実施したときに、単なる感想ではなくパターンとして捉えることができます。
今日は特に考えずに任意のデータを作ってテストすれば良いと思い始めましたが、結局Qwenチャットボットでテストデータを作成する方法、プロンプト戦略、そして自動呼び出しされるデバッグツールの必要性まで見えてきました。明日以降は6番目のテストから基準を少し変えて、手作業で繰り返すフローを減らす方法をまずは検討しなければなりません。