2026年7月21日火曜日2026 年 7 月 21 日
- Markdown -> JSONL Converter で公式文書 JSONL 変換収集量を 1,550 件中 1,422 件まで進めた
Qwen Validation Debugger の 46 番から 50 番まで実行し生成コード、Godot 3/4 エンジン検査と JSONL 検証結果を確認した- 50 番デバッグログ出力項目は共通コードと JSONL 検証を完了し、48 番シーンリソース動的ロードはモデルが存在しない固定リソースパスを生成してエンジン検査で継続的に拒否された
- 再挑戦時に直前のエンジン診断を渡し、項目別の文法や正解を直接登録せずに生成ラウンドごとに異なる安定シードを使用するようデバッガを改善した
- 8501 収集器の現在の JSONL を
outputs/godot-rag-sqlite/godot-rag.sqlite3 に格納し、pages.zip の 1,570 件の原文 URL·ドメイン·SHA-256 とレコード出典を照合した
- SQLite に
docs_chunks、api_mapping、label_prototypes、原文 provenance と FTS5 検索インデックスを構成し、全収集が終わる前でも同じビルダーでスナップショットを再作成できるようにした
- 収集された JSONL を Git に上げる形式で SQLite とベクトル DB ダンプを比較した後、元のレコードと provenance をそのまま保存し別サーバーなしで再生成・共有できる SQLite を選択した
- 最初は SQLite を Git に上げる基準成果物としてだけ追加し Source Flow Debugger の F 戦略は PostgreSQL を見続けさせ、同じ JSONL を SQLite と PostgreSQL に別々に反映しなければならない整合性問題が生じた
- 二重管理をなくすために F 戦略の基準データと実行保存庫をコミットされた SQLite 一つに統合し、PostgreSQL 接続設定と移行パスを削除した
- BM25 候補は SQLite FTS5 で読んだ後 Node で Okapi BM25 計算し、embedding は同じ SQLite の
record_embeddings にモデル·次元·レコード内容 SHA-256 と Float32 ベクトルを共に保存し、変更されたレコードだけ再インデックスするよう変更した
- Source Flow Debugger が別 DB URL なしでコミットされた SQLite のリビジョン、レコード数と埋め込み数を直接確認し、保存されたベクトルは Node で cosine similarity で検索するよう接続した
- ベクトル DB ダンプは埋め込みモデル、次元とインデックス実装に依存するため別基準データとせず、必要なら同じ SQLite で再生成する派生インデックスとして区別する