知識システムにおける「検索」と「表現」
検索は知識構造ではない
最新の知識システムのほとんどは検索（Retrieval）を最適化しています。それは理解できることです。検索は目に見えやすく、デモンストレーションも容易で、機能すると魔法のように感じられます。質問を入力すれば、答えが返ってきます。
しかし、検索は問題の半分しか解決しません。より深い問いは以下の通りです。
検索を試みる以前に、知識はどのような形を持っているのか？
それが「表現（Representation）」です。つまり、知識の背後にある構造のことです。
- ノート
- ページ
- スキーマ
- グラフ
- エンティティ（実体）
- 関係性
- サマリー（要約）
- 分類法
- ソースの境界
- 正典（Canonical）バージョン
検索（Retrieval）はこう問いかけます。
関連するものを発見できるか？
表現（Representation）はこう問いかけます。
知識は理にかなった方法で整理されているか？
これらは同じ問題ではありません。表現が不十分なRAG（検索拡張生成）システムは、ただ混乱したアーカイブへアクセスする高速インターフェースに過ぎません。断片を拾うことはできても、壊れた構造を修復することはできません。文書を引用することはできても、どれが正典であるかを決定することはできません。コンテキストを組み立てることはできても、基盤となる知識の一貫性を保証することはできません。
そのため、LLM Wiki スタイルのシステムが注目されています。これらは、労力をクエリ実行時（検索時）から取り込み時（Ingest time）へシフトします。ユーザーが質問した際にチャンク（断片）を単に検索するのではなく、知識をページ、概念、要約、リンクへと事前に構造化しようと試みます。これによってRAGが obsolete（時代遅れ）になるわけではありません。検索と表現は異なるレイヤーであり、優れた知識システムには両方が必要なのです。
核心的な違い
検索は「アクセス」に関するものであり、表現は「意味」に関するものです。
| レイヤー | 問い | 例 |
|---|---|---|
| 検索（Retrieval） | 正しい情報を見つけるには？ | 検索、埋め込み、BM25、リランキング、ベクトルストア |
| 表現（Representation） | 知識はどのように構造化されているか？ | ノート、ウィキ、グラフ、スキーマ、オントロジー |
| 推論（Reasoning） | 知識をどう活用するか？ | 統合、比較、推論、意思決定 |
弱いシステムは検索へ直接飛びつく傾向がありますが、強いシステムはまず以下を問います。
- 核心となる概念は何か？
- 正典となる情報源はどこか？
- どの関係性が重要か？
- 何が時間とともに変化するか？
- 何を検索すべきか？
- 何がすでに表現されてべきか？
これが、文書上での検索と、実際の知識システムとの違いです。
なぜ検索が主流になったのか
検索が主流になったのは、現代のAIスタックに適合しやすいからです。典型的なRAG パイプラインは以下のようになります。
- 文書の読み込み
- チャンクへの分割
- 埋め込み（Embeddings）の生成
- ベクトルの保存
- 関連チャンクの検索
- （オプション）リランキング
- LLMプロンプトへの投入
- 回答の生成
このパイプラインは実用的です。構築が比較的容易で、散らばった文書でも機能し、大規模なコーパスにスケーリングでき、モデルの再学習を避けつつ、LLMに最新の情報へのアクセスを提供できます。これがRAGが「ドキュメント上でのAI」におけるデフォルトのパターンとなった理由です。
しかし、そこに落とし穴があります。
RAGは知識へのアクセスを改善します。しかし、それは知識そのものを自動的に改善するわけではありません。
コンテンツが重複していたり、情報が古かったり、矛盾していたり、分割（チャンキング）が悪かったり、命名が不適切だったりする場合、検索はそれらの問題を表面的に引き起こします——しばしば高い確信を持って。
表現（Representation）とは何か
表現とは、検索が行われる以前に知識がどのように形作られるかという方法です。以下のような問いに答えるものです。
- この知識は、文書、ノート、エンティティ、あるいは事実として保存されているか？
- 関係性は明示的か、暗黙的か？
- 正典となるページが存在するか？
- 要約があるか？
- 概念はリンクされているか？
- システムはトピック、ワークフロー、時間、または所有者によって整理されているか？
- 人間が維持管理できるか？
- 機械が推論できるか？
表現は飾りではありません。それは、どのような操作が可能かを決定づけます。
表現の形態
文書（Documents）
文書は最も一般的な表現形態です。例としては以下があります。
- 記事
- マニュアル
- レポート
- READMEファイル
- サポートページ
- ブログ記事
文書は人間が書きやすいですが、事実、物語、コンテキスト、例、意見、古いセクション、繰り返しの説明を同じコンテナに混ぜてしまうため、機械が扱うには難しいことがよくあります。文書は良いコンテナですが、常に良い知識構造とは限りません。
ノート（Notes）
ノートは文書よりも柔軟です。以下のような性質を持ち得ます。
- 原子性（Atomic）
- リンク可能
- プライベート
- 未完成
- 概念中心
PKM や second brain（セカンダリーブレイン） などのノートシステムは、磨かれた文書リポジトリよりも、進化し続ける知識をより良く表現できます。良いノートは進行中の思考を捉えます。悪いノートは、検索不可能なゴミ箱になってしまいます。
ウィキ（Wikis）
ウィキは知識を維持管理されるページとして表現します。良いウィキには以下があります。
- 安定したページ
- 明確なトピック
- 内部リンク
- 所有者（Ownership）
- 正典となる回答
- 更新パターン
ウィキは、散らばった文書のダンプよりも強力です。なぜなら、知識に「居場所」を与えるからです。「デプロイチェックリスト」は一つの場所に。「インシデント対応」は一つの場所に。「RAGアーキテクチャ」は一つの場所に。これは重要です。なぜなら、知識に安定した構造があるときこそ、検索がより良く機能するからです。
知識グラフ（Knowledge graphs）
知識グラフは知識をエンティティと関係性として表現します。テキストのみを保存するのではなく、以下のようなものをモデル化します。
- Person works on Project（人物がプロジェクトに取り組む）
- Model supports ContextLength（モデルがコンテキスト長をサポートする）
- Page depends on Concept（ページが概念に依存する）
- Service connects to Database（サービスがデータベースに接続する）
- Tool implements Protocol（ツールがプロトコルを実装する）
グラフは強力です。関係性が明示的になることで、トラバーサル（巡回）、依存関係解析、エンティティ解決、系譜（Lineage）、推論、レコメンデーションに役立ちます。しかし、グラフは維持管理にコストがかかり、魔法ではありません。悪いグラフは、構造化された混乱に過ぎません。
スキーマとオントロジー（Schemas and ontologies）
スキーマは期待される構造を定義し、オントロジーはさらに進んで型、関係、制約を定義します。これらは以下に答えます。
- どのような種類のもの（エンティティ）が存在するか？
- それらにはどのようなプロパティがあるか？
- それらはどのように関係し得るか？
- どのようなルールが適用されるか？
これは、医療知識、法的知識、エンタープライズデータカタログ、プロダクト分類、コンプライアンスシステムなど、正確性が重要な場合に役立ちます。トレードオフは堅牢性です。表現が形式的であればあるほど、進化させるコストは高くなります。
LLM生成による表現（LLM-generated representations）
現代のシステムは、表現の作成にLLMをますます活用しています。例としては以下があります。
- 要約
- 抽出されたエンティティ
- トピックページ
- 概念マップ
- 合成FAQ
- 文書のアウトライン
- クロスリンク
- 用語集エントリ
ここがLLM Wikiスタイルのシステムの位置です。これらはモデルを用いて、クエリが行われる前に知識を前処理し、構造化します。RAGは「クエリ時に関連チャンクを検索せよ」と言いますが、LLM Wikiは「取り込み時に有用な知識構造をコンパイルせよ」と言います。これらの両方のパターンは同じアーキテクチャ内で共存し得ます。
検索（Retrieval）とは何か
検索とは、関連情報を見つけるプロセスです。一般的な検索方法には以下が含まれます。
- キーワード検索
- 全文検索
- ベクトル検索
- ハイブリッド検索
- メタデータフィルタリング
- グラフトラバーサル
- リランキング
- クエリ書き換え
- エージェント検索
検索は単一のものではありません。それは補完的な方法の層状スタックです。
キーワード検索
キーワード検索は用語を一致させます。予測可能で、デバッグ可能、高速であり、正確な用語、ID、エラーメッセージ、名前、コードには優れているため、今でも有用です。その弱点は意味的な不一致です。ユーザーが「繰り返しの回答を止める方法」と検索しても、文書に「presence penalty（存在ペナルティ）」と書かれている場合、キーワード検索は最適な結果を見逃すかもしれません。
ベクトル検索
ベクトル検索は意味的類似性に基づいて取得します。以下の場合に有用です。
- 用語が異なる場合
- 概念が曖昧な場合
- ユーザーが自然言語で質問する場合
- 文書が用語を使い分けていない場合
その弱点は精度です。ベクトル検索は、関連しているように感じられるが実際には正しくないものを取得してしまうことがあります。これは技術システムにおいて特に危険です。
ハイブリッド検索
ハイブリッド検索はキーワード検索とベクトル検索を組み合わせ、多くの場合、どちらか一方よりも優れています。キーワード検索は完全一致を捉え、ベクトル検索は概念的な一致を捉えます。技術的なナレッジベースにとって、ハイブリッド検索は通常、強力なデフォルトです。
リランキング（Reranking）
リランキング は、初期に取得された結果セットを、より強力なモデルを用いて再順序付けします。最初の検索ステップは広範なため、これにより品質が向上します。典型的なパターンでは、50個のチャンクを検索し、上位5または10個にリランキングを行い、LLMには最適なコンテキストのみを渡します。リランキングは、RAGの品質を向上させる最も実用的な方法の一つです。
エージェント検索（Agentic retrieval）
エージェント検索は検索をプロセスに変えます。単一のクエリではなく、エージェントは以下を行うかもしれません。
- 初期の質問を投げかける
- 検索する
- 結果を確認する
- クエリを再定式化する
- 再度検索する
- 情報を比較する
- 回答を統合する
これは検索よりも研究に近いものです。複雑な質問に有用ですが、遅く、制御が難しいです。
表現なしの検索は脆い
検索システムが存在するものしか検索できません。以下を確実に修復することはできません。
- 明確でない概念
- 重複したページ
- 一貫性のない用語
- 古いドキュメント
- ソースの所有者の欠如
- 矛盾する記述
- 弱い内部リンク
- 悪い文書境界
これがRAGプロジェクトで最も一般的なミスです。チームがベクトルデータベースを構築し、それが知識システムになると期待します。ベクトルデータベースは知識アーキテクチャではありません。それはアクセスレイヤーです。
検索なしの表現は孤立する
逆の失敗も存在します。誰も見つけられない、美しく構造化されたナレッジベースを持つことができます。以下の場合に起こります。
- 過剰に設計されたウィキ
- 深いフォルダツリー
- 硬直した分類法
- 適切に索引されていないドキュメント
- 発見機能のないプライベートノートシステム
- 使用可能なインターフェースのないグラフ
表現は知識に構造を与え、検索は知識に到達性を与えます。両方が必要です。
トレードオフマップ
速度 vs 一貫性（Coherence）
検索は構築が速く、表現には時間がかかります。プロトタイプが必要な場合は検索が勝ち、長期的な信頼が必要な場合は表現がより重要です。
| 優先度 | 更なるスタートポイント |
|---|---|
| 多数のドキュメントに対する高速Q&A | 検索 |
| 安定した技術知識 | 表現 |
| 探索的調査 | PKM + 検索 |
| エンタープライズアシスタント | 構造化コーパス + RAG |
| エージェントメモリ | 表現 + 選択的検索 |
純粋なRAGプロトタイプは迅速に構築できますが、信頼できる知識システムにはキュレーションが必要です。
柔軟性 vs 一貫性
散らばった文書は柔軟ですが、構造化された知識は一貫性があります。柔軟性は以下の場合に役立ちます。
- ドメインが急速に変化する
- 知識が不完全である
- ユーザーが探索している
- システムが個人的なものである
一貫性は以下の場合に役立ちます。
- 複数の人が依存している
- 回答が信頼できる必要がある
- ワークフローがそれに依存している
- AIシステムがそれを消費する
知識に依存する人々やエージェントが多いほど、表現は重要になります。
リコール vs 精度
検索システムはしばしば最初にリコール（再現率）を最適化します。つまり、関連する可能性があるものを何でも見つけることです。しかし、良い回答には精度が必要です。これは、単に関連する証拠ではなく、最良の証拠を見つけることを意味します。表現は、概念と境界を明確にすることで精度を向上させます。よく構造化されたページは、長い文書内に埋もれたランダムな段落よりも正確に検索しやすいです。
取り込みコスト vs クエリコスト
RAGは通常、作業をクエリ時に押し出します。クエリ時、システムは以下を行います。
- クエリを書き換える
- チャンクを検索する
- 結果をリランキングする
- コンテキストを組み合わせる
- モデルに断片の上で推論させる
LLM Wikiスタイルのシステムは、より多くの作業を取り込み時に押し出します。取り込み時、システムは以下を行います。
- ソースを読む
- 概念を抽出する
- 要約を書く
- ページを作成する
- 関連アイデアをリンクする
- 構造を維持する
| アーキテクチャ | コストの高いステップ | 利点 |
|---|---|---|
| RAG | クエリ時 | 柔軟な検索 |
| LLM Wiki | 取り込み時 | 事前コンパイルされた構造 |
| 知識グラフ | モデリング時 | 明示的な関係性 |
| ウィキ | 維持管理時 | 正典となる知識 |
これらに普遍的に優劣はありません。それぞれ異なるコストを最適化するものです。
なぜLLM Wikiが存在するのか
LLM Wikiが存在するのは、検索だけでは作業が繰り返されることが多いからです。通常のRAGシステムでは、各クエリがモデルに生な断片を再度解釈させます。
- トピックに関するチャンクを検索
- LLMに概念を推論させる
- 回答を生成
- 統合を忘れる
- 次回繰り返す
LLM Wikiは以下を説きます。
同じ統合を再導出するのをやめよ。コンパイルせよ。
生な文書のみを保存するのではなく、知識を要約し、接続する構造化されたページを作成します。これにより、一貫性、再利用性、トークンの効率、人間による読みやすさ、長期的な維持管理が向上する可能性があります。しかし、コストがあります。システムはウィキを維持管理しなければならず、ウィキが誤っていたり、古かったり、幻覚（ハルシネーション）を含んでいたりする場合、その構造は危険なものになります。
RAGの幻覚 vs 悪い表現
RAGシステムが悪い回答をしたとき、人々はしばしばLLMを責めます。そして、時にはそれは正しいです。しかし、多くの失敗は実際には検索または表現の失敗です。
失敗モード1. 正しいドキュメント、誤ったチャンク
答えは存在しますが、チャンキング が悪く分割します。モデルは以下を受けます。
- 段落の半分
- 欠落したコンテキスト
- 説明のないテーブル
- 制約のない定義
LLMはこれらの隙間を埋めます。これは幻覚のように見えますが、根本的な問題は壊れた表現です。
失敗モード2. 関連するチャンク、誤った答え
ベクトル検索は意味的に類似していますが、操作上誤っているものを取得します。クエリは本番環境のデプロイメントについて問いていますが、取得されたチャンクはローカル開発について議論しています。用語は重複しますが、意味は異なり、モデルは本番環境の問題に対してローカルセットアップの手順で回答します。これは検索の不精度です。
失敗モード3. 矛盾する情報源
2つの文書が矛盾しています——一つは古く、一つは新しい。検索システムは両方を返し、LLMはそれらを自信に満ちたが無効な回答に統合します。これは単なる検索の問題ではなく表現の問題です。なぜなら、ナレッジベースに正典の状態が欠如しているからです。
失敗モード4. 概念モデルの欠如
システムには多くの文書がありますが、ドメインのモデルがありません。以下を認識していません。
- 「エージェントメモリ」は「RAG」と異なる
- 「ウィキ」は「PKM」と異なる
- 「埋め込み検索」は「全文検索」と異なる
- 「デプロイメント」は「ホスティング」と異なる
概念的表現なしに、検索は曖昧な一致に成り下がります。
失敗モード5. 生成された構造が偽の権威となる
LLM Wikiシステムには独自の失敗モードがあります。LLMが悪い情報源からクリーンなページを生成する場合、その結果は元の素材よりも権威あるように見える可能性があります。これは危険です。磨かれた幻覚は、散らばったソース文書よりも悪いです。生成された表現には以下が必要です。
- ソースリンク
- レビュー
- 更新ルール
- 信頼度マーカー
- 所有者
デザインへの影響
コーパスが巨大で動的な場合は検索を最適化する
以下の場合は検索を優先すべきです。
- コーパスが巨大である
- 文書が頻繁に変わる
- ユーザーが予測不能な質問を多くする
- 広範なカバレッジが必要である
- 完璧な構造は現実的ではない
例：サポートナレッジベース、エンタープライズドキュメント検索、リサーチアシスタント、多数のファイル上での内部チャット、法的開示、カスタマーサービスボット。これらの場合、強力な検索に投資します。
- ハイブリッド検索
- メタデータフィルタ
- リランキング
- クエリ書き換え
- ソース引用
- 評価セット
一貫性（Coherence）が重要な場合は表現を最適化する
以下の場合は表現を優先すべきです。
- 知識が信頼できる必要がある
- 回答が一貫している必要がある
- 概念が頻繁に再利用される
- ドメインに明確な構造がある
- 複数のシステムがそれに依存している
例：アーキテクチャ知識、プロダクトドキュメント、コンプライアンスルール、APIリファレンス、運用ランブック、キュレートされた研究コレクション、技術ブログクラスター。これらの場合、以下に投資します。
- 正典となるページ
- 用語集の用語
- 図解
- 内部リンク
- 所有者
- バージョニング
- レビューのサイクル
AIシステムが知識に依存する場合は両方を最適化する
AIエージェントが知識に依存する場合、検索のみでは通常不十分です。エージェントには以下が必要です。
- 安定したコンテキスト
- 明確なタスクルール
- 持続的なメモリ
- 構造化された参照
- ソースの境界
- 更新動作
エージェントシステムにおいて、表現はシステム設計の一部となります。コーディングエージェントは「いくつかのドキュメント」を検索するだけでなく、以下を知る必要があります。
- プロジェクトの慣習
- アーキテクチャの決定
- コマンドパターン
- 禁止された依存関係
- テストワークフロー
- デプロイメントルール
その一部はRAGに属し、一部はメモリに属し、一部は構造化されたプロジェクトドキュメントに属します。
実践的な意思決定フレームワーク
問題が情報を見つけることである場合
検索を最適化します。例：
- 「関連するページを見つける。」
- 「ドキュメントに対して質問に答える。」
- 「多数のPDFを検索する。」
- 「類似のサポートチケットを特定する。」
使用：
- 全文検索
- ベクトル検索
- ハイブリッド検索
- リランキング
- メタデータフィルタリング
問題が知識を一貫させることである場合
表現を最適化します。例：
- 「正典となる説明を作成する。」
- 「重複したページを解決する。」
- 「ドメインモデルを定義する。」
- 「安定したナレッジベースを構築する。」
使用：
- ウィキページ
- 概念マップ
- 分類法
- 知識グラフ
- 要約
- スキーマ
問題が繰り返される統合である場合
コンパイルされた表現を使用します。例：
- 「同じ概念的な質問を繰り返し答えている。」
- 「システムが同じ情報源を再要約し続けている。」
- 「安定した統合レイヤーが必要だ。」
使用：
- LLM Wiki
- キュレートされた要約
- トピックページ
- 人間レビュー済みの生成ページ
問題が適応的な継続性である場合
メモリを使用します。例：
- 「エージェントはユーザーの好みを覚えておくべきだ。」
- 「コーディングエージェントはプロジェクトの慣習を覚えておくべきだ。」
- 「アシスタントはセッション間で作業を継続すべきだ。」
使用：
- エージェントメモリ
- 好みを保存するストア
- 出来事記憶（Episodic memory）
- 意味記憶（Semantic memory）
- プロジェクトメモリ
技術ブログへの適用
技術ブログは単なる投稿の連続以上のものになり得ます——それは表現された知識システムになり得ます。記事は文書であり、カテゴリは弱い分類法であり、内部リンクはグラフのエッジであり、中核ページ（Pillar pages）は正典となる要約であり、シリーズページはキュレートされたパスであり、検索は検索です。孤立した投稿のみを公開する場合、検索はより懸命に働く必要があります。強力な表現を構築する場合、検索は容易になります。
それは以下を意味します。
- 明確なクラスターの境界
- 安定したスラッグ
- 正典となるページ
- 比較ページ
- 用語集スタイルの解説
- 内部リンク
- 構造化されたメタデータ
これがサイトアーキテクチャが重要な理由です——SEOのためだけでなく、それが知識表現だからです。このサイトの Knowledge Management クラスター自体が、表現ファーストなパブリッシングの例です。
RAGへの適用
RAGの品質は表現に大きく依存します。適切に構造化されたソースコーパスは以下を改善します。
- チャンクの品質
- 検索の精度
- 引用の品質
- 回答の一貫性
- 評価の明確さ
複雑なRAGパイプラインを構築する前に、以下を問いかけます。
- ソース文書は最新か？
- 重複は削除されているか？
- 重要な概念は明確に命名されているか？
- ページのスコープは適切か？
- テーブルとコードブロックは検索可能か？
- 正典となる回答は明らかか？
- 文書境界は意味があるか？
答えが「いいえ」の場合、より良い埋め込みでもそれ以上は助けになりません。
LLM Wikiへの適用
LLM Wikiは表現ファーストのパターンです。以下の場合に有用です。
- コーパスが小〜中規模である
- 知識が要約するのに十分安定している
- 繰り返される統合がコストがかかる
- 人間が読みやすいページから利益を得る
- 検索の前に構造を望む
以下の場合にはあまり有用ではありません。
- コーパスが巨大である
- コンテンツが constantly 変化している
- 一貫性よりも最新性が重要である
- ガバナンスが弱い
- 生成された要約をレビューできない
LLM WikiはRAGの代替ではなく、異なるレイヤーです。強力なシステムは両方を使用できます。
- LLM Wikiが構造化された要約を作成する。
- RAGが生なソースとウィキページから検索する。
- 人間レビューが表現の信頼性を保つ。
推奨されるアーキテクチャパターン
パターン1. 検索ファースト
速度が重要な場合に使用します。
documents
-> chunks
-> embeddings
-> retrieval
-> LLM answer
良い用途：
- プロトタイプ
- 広範な検索
- 大規模コーパス
- 初期の実験
弱点：一貫性はソースの品質に依存する。
パターン2. 表現ファースト
信頼が重要な場合に使用します。
sources
-> curated pages
-> internal links
-> maintained knowledge base
-> search or RAG
良い用途：
- ドキュメント
- 技術知識
- 長期的なコンテンツ
- チーム知識
弱点：維持管理が必要。
パターン3. コンパイルされた知識
繰り返される統合が重要な場合に使用します。
raw sources
-> LLM extraction
-> generated summaries
-> topic pages
-> reviewed knowledge base
-> retrieval
良い用途：
- LLM Wikiシステム
- 研究コレクション
- 個人ナレッジベース
- 安定したドメイン
弱点：生成された構造は監査される必要がある。
パターン4. ハイブリッド知識アーキテクチャ
本格的なシステムを構築する場合に使用します。
raw documents
-> structured knowledge layer
-> search index
-> retrieval and reranking
-> AI answer
-> feedback and maintenance
良い用途：
- 本番環境のRAG
- 内部知識システム
- AIアシスタント
- 技術パブリッシングシステム
弱点：動く部品が多い。
評価のための問い
検索を評価するには、以下を問いかけます。
- システムは正しい情報源を見つけたか？
- 正しい情報源を上位にランク付けしたか？
- 十分なコンテキストを取得したか？
- 関連ないコンテキストを避けたか？
- 回答は正しい情報源を引用したか？
表現を評価するには、以下を問いかけます。
- 知識は明確に構造化されているか？
- 正典となるページがあるか？
- 概念は一貫して命名されているか？
- 関係性は明示的か？
- コンテンツは維持管理されているか？
- 人間と機械の両方が使用できるか？
知識システムを回答品質のみで評価しないでください。良い回答は、悪い構造を隠し得ます。
意見的なルール
システムが稀に失敗する場合、検索を改善します。同じ概念的領域で繰り返し失敗する場合、表現を改善します。
悪い検索は正しい情報を逃します。悪い表現は、正しい情報が使用可能な形では実際には存在しないことを意味します。
結論
検索と表現は異なる問題を解決します。検索はアクセスを与え、表現は構造を与えます。RAGは強力です。なぜなら、それはクエリ時にLLMに外部知識を利用可能にするからです。しかし、RAGは自動的に知識を一貫した、正典となる、維持管理されたものにするわけではありません。そのため、ウィキ、PKMシステム、知識グラフ、LLM Wikiスタイルのシステムが依然として重要なのです。
未来は検索対表現ではなく、層状の知識システムです。
- 構造のための表現
- アクセスのための検索
- 継続性のためのメモリ
- 統合のための推論
本格的な知識システムを構築している場合、ベクトルデータベースから始めないでください。知識の形から始め、それからどのように検索されるべきかを決めてください。
