第8章復元したKnowledgeを、根拠を確認できるQAへつなぐ

資料を検索できるだけでは、問い合わせに使えない

RAGの初期状態では、必要な情報へ到達しない、不要な情報が混ざる、同じ質問への回答がぶれる、UI操作と結び付かないという問題があった。知識を蓄積するだけでは、利用者の問いと検索対象が合わなかった。

そこで、文書の分割単位をクラス単位から機能・意味単位へ見直し、1トピック1ファイルへ整理した。長い文書へ複数の意味を混在させず、必要な根拠を取り出しやすくした。

回答には対象システムのKnowledgeを使い、範囲外の内容は回答せず、不明なものは不明とする制約を置いた。外部知識や推測が混ざると、説明が自然でも現行システムの根拠にはならないからである。

AIはコードの説明生成、Markdownの要約、フローとの整合確認に利用した。生成した内容は人間が検証し、確認できない情報を確定した仕様として残さない分担とした。

文書へ「操作内容（UI）・実行処理（内部）・結果（出力）」の対応を追加した。

例えば、UIから印刷を実行し、印刷処理モジュールが呼び出され、印刷ジョブが生成される、という説明である。これは対応付けの例であり、内部名称を知らない利用者の問いを処理へつなぐために使う。

メールや手順のような文脈依存の情報は、「何をしたいときか」というQA形式へ整理し、原因と対処を組み合わせてFAQにした。操作や意図を起点に探せるようにすることで、コードから作った説明を実務上の問い合わせへ接続した。

仕様、背景事情、判断軸、制約もAIへ渡せる情報として整理した。

ただし、過去の判断を検索できることは、今回も同じ方針を採ることを意味しない。その時点の利用状況や制約によって、変更の採否は変わる。

AIは判断材料を整理・提示し、人間が現在の状況を踏まえて最終決定する。条件を完全に事前定義して自動承認する構成にはしなかった。次章では、回答内容、根拠、不明時の挙動を確認し、QAを利用できる範囲を評価する。