souheil007/rag_full_version の最新コミット a9aeab5(2026-10-17) はコードではなく設計文書 1 件のみを追加する。plans/plan9.md に 100 行が追加され、削除はない。リポジトリの説明は、このプロジェクトを IBM Docling による AST パース、Pixtral ベースの VLM テーブル修復、デュアル表現のシリアライズ、ハイブリッド RRF 検索により 2 秒未満の応答時間を実現する文書 RAG と説明している。本文書は、その RAG の評価方式とテーブル修復手順を再設計する「Plan 9」のドラフトである。
計画書の第1の軸は評価の分離である。現在の構造では、正解文書 ID が空の音声クエリ（回答できない質問）も検索指標に含まれて 0 点として集計され、その結果、検索性能の数値が低くなる可能性がある。この計画は検索評価（Hit Rate@K、MRR、Precision、Recall）を回答可能なクエリにのみ適用し、音声クエリについては「わからない」という趣旨で回答したかどうかを数える abstention accuracy（回避精度）を別個に計算して、scorecard を分離する。
第2の軸は VLM の再検証である。破損したテーブルを Pixtral に渡してレイアウトを修正した後、その結果を再び TableSanityChecker に投入し、原文との対応および列計算が正しいかを確認し、合格しない場合は repaired=False と method='vlm_validation_failed' として拒否し、元のテーブルを AST に残す。ヘッダ正規化によって値がデータセルに前倒しされるのを防ぐセル不変条件の検証や、VLM 転換目標 5%（コスト SLA）と検出精度（Recall/Precision）を区別する文書の整理も併せて含まれている。
ただし今回のコミットには計画のみが含まれている。evaluator.py、table_repairer.py、テスト、文書の更新はチェックリストとしてのみ残っており、実際の実装や測定結果は含まれない。検索指標の分離と VLM 再検証が現在機能しているか、テーブル修復がどのくらいの頻度で拒否されるかは、このコミットだけでは分からない。ライセンスとスター数についても示されていない。