AIナレッジシステム (RAG) 開発レポート：Ver2の技術的課題とVer3アーキテクチャ改革の必要性¶

1. エグゼクティブサマリー¶

本プロジェクトは、社内規程類を対象としたAI検索システムの構築を進めている。初期検証（Ver1）では「速さ」を、現行版（Ver2）では「根拠の明示」を実現したが、Ver2において「UI表示とデータ構造の深刻なトレードオフ」および「検索精度の限界」という構造的な技術課題に直面した。これらは既存の延長線上での改修では解決不可能であり、次期フェーズ（Ver3）において、データの持ち方（ETL）から検索アルゴリズムまでを含めた抜本的なアーキテクチャ刷新が必要である。

2. 開発フェーズの変遷と技術的評価¶

2.1 Ver1: 技術検証 (PoC)¶

目的: 低スペックPC（メモリ8GB）でも動作するレスポンス速度と堅牢性の確保。
構成: Docker, Azure OpenAI (GPT-3.5), テキストベース回答。
評価:
- 【成功】非常に高速で、動作も安定していた。
- 【課題】回答の根拠（Citation）が示されないため、業務利用における信頼性が担保できなかった。

2.2 Ver2: 現行システム (Current)¶

目的: 「回答の根拠」を明確にし、クリックで原文へ飛べるリッチなUIの実現。
構成: Azure Functions, GPT-4o (JSON Structured Output), クライアントサイドレンダリング。
変更点:
- AIモデルを GPT-4o へ変更。これは、複雑なJSON形式での出力を安定させ、かつ増大した処理負荷による遅延を最小限に抑えるための必須措置であった。
評価:
- 【成功】引用機能の実装により、情報の信頼性は向上した。
- 【失敗】「構造化の罠」に陥り、以下の解決困難な課題を抱えることとなった。

3. Ver2が直面している「構造的な行き詰まり」¶

Ver2では、非構造化データ（テキスト）を無理やりUI側で構造化して表示しようとした結果、システム全体が複雑化し、パフォーマンスと品質が著しく低下している。

3.1 UIレンダリングのジレンマ (The Formatting Dilemma)¶

規程類には「文章」と「表（テーブル）」が混在しているが、現在のJSON方式ではこれらを両立できない。 * 改行を優先すると: 文章は読みやすくなるが、表組みが崩れて意味不明な文字列になる。 * 表組みを優先すると: 表は綺麗になるが、文章の改行が消滅し、巨大なテキストの塊となって可読性が損なわれる。 * 結論: クライアントサイド（UI）での小手先の調整では、この二律背反を解決できない。

別表（数値データ）の検索漏れ:
- 現在のキーワード検索（BM25）は単語の一致に依存しているため、単語数が少なく数値が中心となる「別表」や「様式」が検索結果の上位に現れない。
- 結果として、ユーザーが最も必要とする具体的な数値基準（例：手当の金額表）が見つからないという致命的な欠陥がある。
類義語への弱さ:
- JSON構造化にプロンプトのリソース（トークン）を割きすぎた弊害で、AI本来の「言葉の揺らぎを吸収する能力」が低下している。

3.3 パフォーマンスの悪化¶

厳密なJSON形式を出力させる処理はAIにとって負荷が高く、Ver1と比較して応答時間が大幅に劣化（数秒〜十数秒の待機）している。GPT-4oの採用で辛うじて実用範囲に留めているのが現状である。

4. Ver3: アーキテクチャ改革案 (Solution)¶

Ver2の課題は「データの持ち方」と「検索の仕組み」に起因するため、以下の3点による抜本的な再構築を行う。

4.1 ETL改革: "PDF to Markdown"¶

施策: PDF解析ツール（Marker等）を導入し、ドキュメントを単なるテキストではなく「構造化されたMarkdown」として取り込む。
効果:
- 「見出し」「段落」「表」がタグ付けされた状態で保持されるため、UI側での複雑な整形処理が不要になる。
- Markdownの標準機能により、文章の改行と表組みが自然に両立され、Ver2の「表示崩れ」問題が根絶される。

4.2 検索改革: "Hybrid Search + Semantic Reranking"¶

施策:
- ハイブリッド検索: 従来のキーワード検索に加え、意味を理解する「ベクトル検索」を併用する。
- セマンティック・リランキング (L2): 検索結果に対して、AIが「質問との関連度」で再順位付けを行う。
効果:
- キーワードが一致しなくても、意味が近いドキュメントをヒットさせる。
- 特に「別表」のような単語の少ないデータも、文脈（Context）に基づいて正しく上位に表示できるようになる。

4.3 責務の分離 (Separation of Concerns)¶

施策: UI（フロントエンド）は「表示」に専念し、データ整形ロジックを持たない。サーバーサイド（バックエンド）が、Markdownという「完成された表示形式」でデータを渡す。
効果: システムの複雑性が下がり、保守性とパフォーマンスが劇的に向上する。

5. 結論¶

Ver2のアプローチ（JSON構造化）は、引用機能の実現には寄与したが、実用的なパフォーマンスと表示品質の両立において限界に達した。業務に耐えうる品質（正しい表示、漏れのない検索）を実現するためには、Ver3（MarkdownベースのETLとハイブリッド検索）へのアーキテクチャ移行が不可欠である。