2026-07-03 振り返り

本日やったこと

今日は簡単に YouTube の 24 時間ストリームを流しながら収集を回し、翻訳テストを行い、6 月 30 日に作成した検証ツールをクリックしながら検証を進めました。

Markdown -> JSONL Converter 側は公式ドキュメントの JSONL 変換収集量が 737 件から 850 件に増えました。今日も大きな実装を新たに押し進めるよりは、RunPod をオンにできる間に収集を進め、その間に検証と翻訳のフローを少しずつ確認するという形でした。

翻訳側は NVIDIA 無料モデル API を使用するパイプラインを別途実験中です。GitHub workflow secrets を通じてある程度成功する様子を見て、日本語/中国語 README が生成される画面も確認しました。まだ完全に導入したと言える段階ではありませんが、文書が増えるほど自動翻訳フローが必要だという考えはますます強くなりました。

検証ツールを作った価値

今日最も大きく感じたのは、6 月 30 日に検証ツールを作っておいて本当に良かったという点です。実際にそのツールがなければ大変なことになっていたでしょう。

以前のやり方だと Qwen にコードと JSONL を別々に作らせ、それを再びプロンプトに貼り付け、期待する応答を頭の中で比較しなければなりませんでした。今は項目をクリックし、コードと JSONL を生成し、Godot 3 コードと Godot 4 コードそれぞれに検証を掛け、raw prompt と raw response までを一画面で見ることができます。手間は依然としてありますが、最低限何が間違っているかを見逃さずに確認できるようになりました。

今日は 50 件のテスト項目のうち 10 件までクリックして確認しました。その過程で LLM が誤って出力したケースが実際に存在しました。

• 1 番では docs_chunks の候補が同じ _ready() や viewport 系列の手がかりを持っているという理由で、実際には別のコード説明なのに 例 が出ました。
• 3 番、4 番、7 番では Godot 3 基準のマイグレーション JSONL をすでに Godot 4 形式のコードに貼り付けているにもかかわらず 例 が出るケースがありました。
• 8 番では docs_chunks が同じ追跡/移動テーマや似た API を扱っているという理由で、現在の SOURCE_CODE の実際の動作と異なっていても 例 と判定されたケースがありました。
• 6 番、9 番、10 番のように期待通りすべて通過した項目もあり、改善方向自体が全く間違っているわけではないと見ました。

これらの問題は JSONL が一つ異常であることが原因というより、後でハイブリッドサーチで似た候補が上がってきたときに Qwen がそれを直接根拠として見るか、検索候補にすぎないと除外するかという問題に近いです。したがって特定のトークンをブロックする方式ではなく、検証プロンプトが現在のコードと JSONL 候補の関係をより正確に判定できるように調整する必要があると考えました。

感想

今日は特に華やかな実装をした日ではありませんでした。自動収集を回し、手動で検証をクリックし、JSONL と検証結果を見るのに思ったより時間がかかりました。それでも何かやった感があり、満足しています。

検証は思った以上に時間がかかります。コード一つと JSONL 一つを見るだけでも、docs_chunks、api_mapping、label_prototypes の性質が異なり、Godot 3 基準コードと Godot 4 基準コードがまた分かれます。それを 10 件だけでもかなり多くのケースが出ます。

それでも今日のように事前に間違えるポイントを捕まえておけば、後で実際の DB 検索や Retriever 検証フローで事故的に問題が起きることを減らせると思います。次回もテストしながら事前に捕まえられる問題は継続して捕まえていきたいです。

改善するとすれば RunPod だけに頼るよりも無料 API を併用する方法もあり得ます。NVIDIA 無料モデル API や他の無料エンドポイントが翻訳、補助検証、文書同期といった作業に安定して利用できれば、RunPod への依存度を少し下げられるかもしれません。