【ITニュース解説】Building a Personal AI Brain: Qdrant, Embeddings, and the Illusion of Memory

最近、AI技術を利用して個人が持つ情報をまるで「AIの脳」のように管理し、必要な時にすぐに引き出せるシステムを構築する試みが注目されている。この記事では、ある開発者がQdrantというベクトルデータベースと、埋め込みという技術を使ってそのようなシステムを自作した際の経験と、そこで直面した予想外の課題について語られている。その課題とは、「プロジェクトの進捗状況」を問い合わせたところ、無関係な「食料品の買い物リスト」が返ってきたというものだった。この一見奇妙な出来事は、AIの「記憶」の仕組みとその限界、そして私たちがAIシステムを設計する上で見落としがちな重要な点を示している。

AIが「記憶」しているという表現は、実は正確ではない。AIシステムは情報をそのまま記憶するのではなく、入力されたテキストデータを「埋め込み」という技術を使って数値のリスト、すなわち「ベクトル」に変換している。このベクトルは、元のテキストの意味的な特徴を高次元の空間に数値として表現したものだ。意味的に似たテキストであれば、このベクトルも空間上で互いに近い位置に配置される。Qdrantのような「ベクトルデータベース」は、このように数値化された膨大なベクトルデータを効率的に保存し、高速に検索するためのシステムである。システムエンジニアがデータベースを扱うように、AIの世界ではこのベクトルデータベースが情報の貯蔵庫となる。ユーザーが何かを尋ねると、その質問文も同様にベクトルに変換される。その後、ベクトルデータベースに保存されている他のベクトルの中で、この質問のベクトルに最も近いものを探し出す。これを「ベクトル検索」と呼ぶ。最も近いベクトルを持つテキストが、質問への「回答」として取り出される。これは「最近傍探索」という数学的な問題であり、AIが内容を「理解」しているわけではなく、純粋に数値的な類似性に基づいて情報を取得しているに過ぎない。

開発者は自身の「AIの脳」に「最近のプロジェクトのフォローアップ状況はどうなっているか？」と尋ねた。すると返ってきたのは「卵、ギリシャヨーグルト、特定のオーツミルクを買う必要がある」という食料品の買い物リストだった。この結果は、AIの幻覚やバグではなく、数学的に「コサイン類似度」という指標において完璧な一致であったと筆者は述べている。コサイン類似度とは、二つのベクトルのなす角度を測ることで、それらのベクトルの方向、つまり意味的な類似性を判断する指標である。なぜ無関係な買い物リストが返されたのか。それは、買い物リストに「項目（items）」「保留中（pending）」「確認が必要（need to check）」「フォローアップ（follow up）」といった、プロジェクトのタスク管理に頻繁に登場する語彙と共通する言葉が含まれていたためであった。埋め込みモデルはこれらの語彙のパターンを捉え、両者が同じような「語彙の指紋」を持っていると判断し、ベクトル空間上で非常に近い位置にあるとみなした。この事例は、「類似性」と「関連性」が必ずしも一致しないという「コサイン類似度の罠」を浮き彫りにした。AIは「似ている」と判断したが、人間にとっては全く「関連性」のない情報だったのだ。

ベクトル検索のためにドキュメントをデータベースに登録する際、まず長いテキストを小さな断片（「チャンク」と呼ぶ）に分割する。このチャンクのサイズをどう設定するかは、検索品質に大きな影響を与える。チャンクが小さすぎると、例えば「プロジェクトは保留中です」という一文だけでは、何が保留で、誰が決定し、なぜそうなったのかといった文脈が失われ、検索結果として取得されても情報としての価値が低いものとなる。逆にチャンクが大きすぎると、一つのチャンクの中に複数の異なるトピックが詰め込まれることになり、埋め込みベクトルがそれら全てのトピックを代表しようとするため、結果としてどのトピックも的確に表現できず、検索の精度が低下してしまう。筆者は自身の経験から、事実情報やプロジェクトの要約では256～512トークン、会話内容では512～1024トークンが「最適な範囲」だと結論付けている。また、チャンク間に10～15%程度の「オーバーラップ（重複）」を持たせることも重要である。これは、文脈がチャンクの境界で分断されてしまうのを防ぎ、より連続的な情報を埋め込むための工夫である。最適なチャンクサイズはコンテンツの種類によって異なるため、自分のデータで実際にテストし、検索結果の品質を測定することが不可欠だと筆者は強調している。

「買い物リスト事件」の根本的な原因は、開発者のナレッジベースが「単一のフラットな名前空間」であったことだと筆者は指摘している。つまり、個人的なメモ、食料品のリスト、ITインフラの決定、プロジェクトの進捗ノートなど、あらゆる種類の情報が区別なく同じベクトル空間に格納されていたため、同じ「類似性の尺度」で競合してしまっていた。結果として、プロジェクトのタスク管理と似た語彙を持つ買い物リストが、無関係であるにも関わらず上位に表示されてしまったのである。この問題を解決するために導入されたのが、「ドメインフィルタリング」という手法である。これは、システムに情報を保存する際、各データポイントに「jobs（仕事）」「infra（インフラ）」「personal（個人）」「research（研究）」といった「ドメイン」を示すメタデータフィールドを追加するというものだ。そして、ユーザーからのクエリを受け取った際、ベクトル検索を実行する前に、まずこのドメインメタデータを使って検索対象を絞り込む。例えば、「プロジェクトのタスク」に関するクエリであれば、事前にドメインが「jobs」であるデータのみにフィルタリングし、その限られたサブセットの中でベクトル検索を実行する。この「ハイブリッド検索」によって、食料品の買い物リストのような無関係なデータは最初から検索候補から除外され、誤った結果が返されることはほぼなくなった。この教訓は、ベクトル検索自体が欠陥を抱えているのではなく、関連性のないドメイン間で意味的な類似性を比較しようとすること自体が誤った問題設定である、という点にある。データを「名前空間」で適切に区切り、ベクトル検索の前にフィルタリングを行うことで、ベクトル検索はその真価を発揮し、高い精度で関連性の高い情報を取得できるようになる。

この一連の経験から、筆者はAIを活用した「記憶」システムを構築する上で、特にシステムエンジニアが心に留めておくべきいくつかの重要な教訓を挙げている。まず、異なる種類の情報、例えば食料品のリストと仕事のタスクが、同じクエリで競合しないよう、それぞれのデータコレクションに「ドメイン」や「名前空間」の境界を明確に定義することが不可欠である。次に、インデックス化する前に、実際のコンテンツタイプを用いてチャンクサイズをテストし、検索品質を評価することが重要である。理論上の数値ではなく、実際のデータに基づいて最適な設定を見つけるべきだ。また、ドメイン、日付、情報源といった「メタデータフィールド」を積極的に追加し、ベクトル検索を実行する前にこれらのメタデータでフィルタリングできるように設計することが、関連性の高い情報取得の鍵となる。最後に、このようなシステムが「記憶」ではなく、あくまで「検索インデックス」であることを常に理解し、情報を具体的かつ構造化された形式で保存するよう設計する必要がある。これにより、人間が期待するような「記憶の錯覚」が、実際に有用なレベルで機能するようになる。

Qdrantのようなベクトルデータベースや埋め込み技術は、個人の情報を効率的に管理し、AIの力を借りて必要な時に素早く引き出すための強力なツールである。筆者の自己ホスト型システムは、作業のコンテキストを迅速に確立することで、生産性を大幅に向上させた。しかし、食料品の買い物リストがプロジェクトの進捗として返された「買い物リスト事件」は、「ベクトル類似性」が必ずしも「関連性」を意味しないという、システム設計における根本的な誤解を明らかにする貴重な教訓となった。この経験を通じて、ドメインごとのデータの明確な分離、検索前のメタデータフィルタリング、そして構造化された情報の保存がいかに重要であるかが示された。これらの原則を遵守することで、AIによる「記憶」システムは単なる検索ツールを超え、私たちの仕事や生活を本当にサポートする有用な存在となり得る。