# IRIS Issues and Improvement Proposals (懸念点と改善提案)

IRIS (Intelligent Retrieval and Indexing System) の運用において発生している懸念点と、それに対する改善方法の提案を以下にまとめます。

---

## 1. ソースファイルの品質問題 (Source Quality Issues)

### 課題の詳細

現状の IRIS では、論文や体系的な技術記事のような構造化された文書だけでなく、個人のブログ記事、雑多なノート、断片的な備忘録といった、非構造化で整理されていない情報（低品質・断片的なソース）も多く投入されています。
これにより以下の問題が生じています。

*   **ノイズの増加**: 不正確な記述や文脈の足りないメモから AI が無理にコンセプトを抽出しようとすることで、内容の薄いページや一時的なページが乱立し、ナレッジベース全体の品質が低下する。
*   **ハルシネーションの誘発**: 前提条件や文脈が欠落したソースをコンパイルする際、AI が誤った補完や解釈を行ってしまうリスクが高まる。

### 改善提案

*   **A. ソースクラス（信頼度クラス）による二分化判定**
    *   `raw_inbox/` に投入されたファイルを Ingest する際、AIがソースの性質に応じて以下の2つの「ソースクラス」に自動分類する仕組みを導入します。
        *   **Class-A (Verified Sources / 公式・学術ソース)**: 論文、査読済みドキュメント、公式仕様書、マニュアル、体系的な技術記事など（客観的・公式・構造化された情報）。
        *   **Class-B (Informal Sources / カジュアル・主観ソース)**: 個人のブログ、学習ノート、備忘録、SNSのクリッピング、スレッドの書き起こしなど（主観的・断片的・非構造化された情報）。
*   **B. 処理パイプラインの二分化（Dual Ingestion Pipelines）**
    *   分類されたクラスに応じて、Ingest 時の処理方法を完全に切り分けます。
        *   **Class-A に対する処理**:
            *   通常通り、高精度な概念抽出を行い、直接 `wiki/concepts/` 配下のメインラインに統合、または独立した高信頼度コンセプトファイルを作成します（原則としてマーカーなし、または `[H]` などの学術的マーカーを適用）。
        *   **Class-B に対する処理**:
            *   独立したコンセプトファイルは新規作成せず、既存のコンセプトページの「関連する言及（Mentions）」や「ブログ・メモからの追記（Informal Notes）」といったサブセクション（Heading）にのみ情報を追記・マージします。
            *   記述には `[O]` (Opinion) や `[Note: 出典名]` を強制付与し、客観的情報と完全に切り離します。また、マージ先の既存コンセプトが存在しない場合は、一時的に「`wiki/scraps/`（スクラップブック）」などの隔離ディレクトリに単一ファイルとして溜め込み、既存コンセプトが成長した段階で統合を検討します。
*   **C. 検索（Query）および目次（Index）時のフィルタリング**
    *   ユーザーが `Query` を実行する際、回答の生成ソースとして「Class-A の信頼性の高い公式情報のみ（信頼度優先）」か「Class-B のカジュアルな知見や個人のメモも含む（網羅性・アイデア優先）」かをオプションで選択・フィルタリングできるようにします。
    *   `index.md` や `log.md` においても、各コンセプトがどのソースクラスから派生したかをフラグ表示し、ナレッジベース全体の「事実（Fact）の割合」を監査しやすくします。

---

## 2. コンセプトの粒度 (Concept Granularity)

### 課題の詳細

ソースファイルからコンセプトファイル（`wiki/` 内の個別ページ）を作成・分割する基準が曖昧であり、現状は「1つのソースファイルに対して1つのコンセプトファイルを作成する」という「1対1」の対応が基本になってしまっています。
これにより以下の問題が生じています。

*   **知識の分断化 (RAGへの逆戻り)**: LLM Wiki パラダイムの本来の強みは、複数のソースを横断して「1つの概念」を1ページに統合・集約し、複利的に知識を成長させる点にあります。1対1の対応になると、単なる「ソースファイルの要約コレクション」になってしまい、情報の有機的なつながりが失われます。
*   **概念の乱立**: 似たような概念が異なるソースから別々にページ化され、重複や分散が発生します。

### 改善提案

*   **A. 「既存ページへのマージ」を優先するプロンプトの厳格化**
    *   `Ingest` / `ReIngest` スキルの実行手順において、新規コンセプトの作成よりも「既存のコンセプトページ（`index.md` 等で管理されているもの）に情報を追記・統合できるか？」を第一に探索させるルールを徹底します。
*   **B. 新規コンセプト作成の「閾値（クライテリア）」の定義**
    *   新しいコンセプトページを作成する際の明確な基準をスキーマに定義します。
        *   （例）「既存のどの概念とも意味的な重複が50%未満であり、かつ単独で定義・説明する価値のある独自の専門用語であること」
        *   （例）単なる「〜のやり方」といった手順は個別ページにせず、親概念やツールページの一セクション（Heading）として埋め込む。
*   **C. コンセプトのリファクタリング（Refactoring / Consolidation）プロセスの導入**
    *   乱立したコンセプトを整理するための定期的な「Refactor」プロセスを定義します。
    *   `Sweep` スキルなどの枠組み、または専用の自動プロセスを用いて、類似性の高い複数のコンセプトページを検出し、それらを統合した「Synthesis（統合）」ページへとマージします。

---

## 3. バンドルの成長に伴う整理とコスト抑制のための改善案 (Dynamic Reorganization & Cost-effective Management)

ナレッジバンドルの規模拡大（成長）に合わせて、カテゴリの再編やコンセプトの粒度調整を定期的に行う必要があります。しかし、物理的なファイルの移動や大規模な再構築は、AIのトークン消費（コスト）とリンク切れリスクを増大させます。これを抑制するための「理想的なフォルダ構成」と「管理方法」を提案します。

### 理想的なフォルダ構成：物理フラット ＋ 仮想カテゴリ構成
物理的なディレクトリ階層と、論理的なカテゴリ分類を切り離す「仮想化」を行います。

* **物理フラット配置（不変のID）**
  * すべてのコンセプトファイルは、カテゴリごとにディレクトリを作って格納するのではなく、`wiki/concepts/` 配下にフラットに配置します。ファイル名は不変のID（またはハッシュ）に基づきます。
  * **メリット**: カテゴリ再編によってフォルダを移動しても物理パスが変わらないため、すべてのコンセプトファイル内の**相互リンク（相対パス）が絶対に破壊されません**。リンクの再構築にかかる膨大なAIの編集コストがゼロになります。
* **メタデータによる仮想カテゴリ管理**
  * 各ファイルの Frontmatter 内の `categories` タグや、`.bundle/CATEGORIES.md`、`index.md` でディレクトリ階層（論理構造）を定義・表現します。
  * Obsidian などのツールで閲覧する際は、Dataview やフォルダの仮想表現プラグインを用いて論理階層を再現します。

### コストを抑えた定期整理（リファクタリング）の管理方法
巨大化したナレッジベースをAIに丸ごと読み込ませて整理させるのはコスト的・処理能力的に不可能なため、以下のステップで「局所的かつ段階的」に整理を行います。

* **A. 2層コンパイル（軽量検出 ＋ 局所LLMマージ）**
  1. **第1層（ローカル処理・低コスト）**:
     * プログラム（Pythonスクリプト等）で、カテゴリタグの重複率や、BM25意味検索、ファイルの最終更新日時をもとに「類似性が高く、統合すべき候補（クラスター）」をあらかじめ自動検出します。
  2. **第2層（LLM処理・局所コンテキスト）**:
     * 検出された特定の少数の候補ファイル（例：3〜5ファイル程度）のみをAIに提示し、マージすべきか否かの判断と、実際の統合処理（局所的な書き換え）を実行させます。
     * これにより、一度のLLMリクエストにおけるコンテキストサイズを最小化し、APIコストを大幅に削減します。
* **B. 差分整理（Delta Reorganization）**
  * `log.md` の記録を活用し、前回の定期整理以降に新規作成または更新されたファイルのみを対象として、既存概念への組み込みやカテゴリ再編を評価します。過去の静的なファイルは再処理の対象外とし、トークンを節約します。
* **C. 「統合（Synthesis）」による非破壊的な整理**
  * 細分化された複数の子ページを無理に1つの物理ファイルにマージするのではなく、共通の親概念をまとめた「Synthesis（統合）ページ」を新規作成し、子ページ群へのリンクを整理します。
  * これにより、既存ファイルを書き換えて古い情報や個別の論理コンテキストを失うリスク（マージに伴うコンテキストの破綻）を防ぎ、低コストで全体像を整理できます。
