VPSでAIエージェントの記憶用ベクトルデータベースをホストする

記憶のないAIエージェントは、会話ごとに自己紹介をやり直すことに足止めされます。解決策はベクトルデータベースです — あなたの文書、メモ、過去のチャットの埋め込みを保存し、エージェントが必要に応じて関連部分を思い出せるようにします（それがRAGの「R」）。それをマネージドサービスとして借りることも、VPSで自分で動かしてデータ — それはしばしばあなたの私的データです — をあなたが制御する箱に保つこともできます。ここに、その方法と、RAMで実際にいくらかかるかを記します。

二つの良い選択肢

風変わりなものは要りません。二つの道でほぼ全員をカバーします：

pgvector — Postgres拡張。すでにPostgresを動かしている（あるいは喜んで）なら、これはすでに持っているデータベースにベクトル検索を足します。一つのサービス、一つのバックアップ、知っているSQL。大差で最も手間の少ない出発点。

Qdrant — 専用のベクトルエンジン。ベクトルが多いとき（低い数百万＋）、あるいは高速なメタデータフィルタリングと専用APIが欲しいときに手を伸ばします。動かすには別サービスですが、まさにこの仕事のために作られています。

足場を固めているほとんどのエージェントには、pgvectorが正しい最初の答えです。それを超えて成長したときにQdrantへ、その前ではなく。

RAMの現実（ここが人々が過小評価する部分）

ベクトル検索が速いのはインデックスがメモリに住むから — だからディスクではなくRAMが本当の制約です。おおよその案内：

• 数十万の埋め込み — 2 GBで快適。
• 低い数百万 — 4 GB以上を計画しインデックスを調整。
• ディスクは楽な部分：100万の埋め込みはわずか数GBなので、25〜45 GBが本格的なストアをカバーします。

だからファイルではなくインデックスに合わせてサイズを。（一般的なサイジングガイドと同じ論理 — 重いものは測るまで明白でない。）

クイックスタート：pgvector

Postgresのある箱で（Dockerが一番簡単 — n8nの自ホストと同じパターン）：

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- あなたの埋め込みモデルの次元に合わせる
);

-- データができたら、高速検索のためインデックスを作る：
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

エージェントは content ＋その埋め込みを挿入し、最も近い記憶を引くために ORDER BY embedding <=> $query_embedding LIMIT 5 でクエリします。それが全体のループです。

Qdrantが好み？HTTP/gRPC APIを公開する単一のDockerコンテナで、ベクトルサイズでコレクションを作りポイントをupsertします。同じ発想、専用エンジン。

エージェントと箱を共有できるか

はい — 小〜中の記憶ストアには、ベクトルDBをエージェントと同じVPSで動かしましょう。より簡単で、遅延は基本ゼロ。一方が他方をRAMから押し出し始めたときだけ別サーバーに分けます。それは後の、あって嬉しい問題の判断であって、初日のものではありません。

正直な注意点

• RAMが壁で、静かです。 検索はインデックスがメモリに収まる間は速いままで、その後は劣化します。メモリを見て、噛みつく前にサイズを上げましょう — 遅いクエリが告げるのを待たないこと。
• 埋め込みは作るのにトークンがかかる。 埋め込む文書はどれも埋め込みモデルへのAPI呼び出しです。ストアはホストするのに安い；ベクトルを生成することが繰り返しのコストです — エージェントを動かすのに実際いくらかかるかに関連します。
• バックアップを。 エージェントの記憶は他と同じデータです。大事なら、スナップショットを。

その範囲で、自ホストのベクトルストアは、私的データを第三者に渡さずにエージェントへ耐久性のある記憶を与えるきれいな方法です。2 GBの箱のpgvectorから始め、RAMに目を配り、数字が言うときだけQdrantやより大きなプランへ育てましょう。