Vector DB
読み: ベクター・ディービー
ベクターDBとは非構造化データ検索
テキストや画像、音声といった非構造化データを多次元の数値配列に変換して保存し、AIが意味の類似性に基づいて高速に検索できるようにする次世代のデータベース技術。従来のキーワード一致ではなく、文脈やニュアンスを捉えたデータ抽出を実現する。
かんたんに言うと
図書館の本をタイトルや著者名ではなく、読んだ後に感じる「切なさ」や「ワクワク感」といった意味合いの近さで本棚に並べる仕組み。
RDBでは不可能な契約書の類似検索をVector DBが実現する
RDBで過去の取引基本契約書の類似検索をやろうとしたことはあるだろうか。
完全な徒労に終わる。
テキストや画像、音声といった非構造化データは、従来の行と列の概念には到底収まらない。そこでEmbeddingの出番になる。文章や画像を数百から数千次元の数値配列に変換し、多次元空間上の座標として配置する。意味が近ければ距離も近くなるという単純な理屈である。
ただ、次元の呪いという言葉を知っているだろうか。次元数が増えると計算量が爆発し、単純な距離計算ではシステムがフリーズする。これを近似最近傍探索などのアルゴリズムでどう捌くかが、Vector DBの腕の見せ所である。
自社のビジネス要件を満たす主な活用シーンと代表的なツール
法務部門で過去の類似契約を引っ張り出すとき、キーワード検索でヒットせずにイライラした経験はないか。あるいは製造現場で、過去の金型不良レポートを探すのに半日潰したことは。
RAGを組んでLLMに社内文書を読み込ませるなら、Vector DBは避けて通れない。フルマネージドで手軽に始めたいならPineconeを選ぶのが無難である。オンプレミスで機密性の高い製造ラインの不良品画像データを扱うなら、Milvusを自前で立てる選択肢もある。手元のPCでサクッと試すだけならChromaで十分である。
ツール選びは要件次第だが、どれを選んでもインデックスの設計で必ず一度はつまずく。判断が分かれるところである。
導入によって得られる恩恵と事前に知るべき技術的限界
LLMに社内の就業規則を答えさせると、平気で存在しない手当をでっち上げる。このハルシネーションを抑え込むためにVector DBを導入するのは理にかなっている。
しかし、魔法の杖ではない。
検索精度を上げようとチャンクサイズやオーバーラップの数値をいじり始めると、あっという間に泥沼にハマる。計算コストも馬鹿にならない。ベクトル検索は総当たりに近い計算を行うため、データ量に比例してインフラ代が跳ね上がる。精度とコストのバランスをどこで取るか、現場のエンジニアは常に頭を抱えている。本当に悩ましい問題である。
自社に必要かを見極めるための導入判断基準
とりあえずPoCを回してみよう、という安易な号令は現場を疲弊させるだけである。
クラウドサービスを使えば環境構築は一瞬で終わる。だが、運用フェーズに乗った後のROIをどう評価するのか。検索が少し賢くなった程度で、莫大なAPI費用とインフラ維持費を回収できるビジネスモデルを描けているか。
データ規模が数万件程度なら、PostgreSQLのpgvector拡張で事足りるケースも多い。専用のVector DBをわざわざ導入する意味があるのか、既存のインフラで耐えられないのか。技術の流行りに乗る前に、自社のデータ基盤の現実と向き合うべきである。
当社の見解
当社はAI長期記憶システムを自社開発・運用している。開発のきっかけは、AIと経営戦略の壁打ちで出した結論がセッション切れで消えたことで絶望を感じた。1日かけて議論してきたことを振り返り、では事業計画書に落とし込むように指示を出したところ、「そのような記録はありません」と言われたことで、強烈な危機感を覚えこれは何としても解決しなければならない問題だと感じた。記憶がないAIは毎朝記憶喪失になる新入社員と同じだ。記憶があるAIは、前提条件を理解した上で本題に入れる。短いプロンプトで済むようになり、「前に言ったように実行して」と曖昧で短いプロンプトでも業務を遂行してくれる。同じことを繰り返し伝える回数も減り、開発業務でも同じミスを繰り返しにくくなり、人間の手戻りが減り、ストレスも減る。AIで本当に業務の質を上げるならば、記憶はマストである。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。