AIの覇権争い
*この記事はThe Sequenceに掲載されたものです。
#LangChainとは
大規模言語モデル（LLM）は新しいテクノロジーの波だ。グーグルとマイクロソフトの両巨頭は、AIバトルで戦うためにコロッセオに足を踏み入れ、検索の王座を奪おうとしている。この巨大な戦いはLLMの躍進の始まりに過ぎず、LangChainはそれをさらに推し進めるためにここにいる。LLMだけでは、記憶力に乏しく、返答に幻覚を見る傾向があるが、会話能力は高い。例えば、ChatGPTに "Read Dead Redemptionの難易度は？"と聞くと、ChatGPTは "難易度設定はない "と答えます。RDRには3つの難易度が設定されているので、この答えは間違っています。LLMは重みを使って答えを生成するため、情報の検証やソースの提供は不可能です。
*LLM に質問に答えてもらったり、データを要約してもらったりしたい場合はどうすればいいでしょうか？
*回答ソースを提供する機能が欲しい場合はどうすればよいでしょうか？
*LLMにトークン制限外の過去の会話を記憶させたい場合はどうするか？
そこでLangChainの出番だ。LangChainは、LLMの有用性をさらに高めるために、LLMと異なる計算や知識を連鎖させることを可能にするフレームワークです。LangChainを使えば、ドメインに特化したチャットボットや、特定の計算のためのアクションエージェントなどを作ることができます。
ミルバスが果たす役割
では、Milvusはどこで活躍するのか？LLMは一度に処理できるトークンの量が決まっている（4文字程度）ので、LLMは大きな文書や文書のコレクションを分析することができない。これを回避するには、すべての文書をデータベースに保存し、入力された質問に関連する文書だけを検索し、それらの文書をLLMに入力して回答を生成します。Milvusはこれに最適で、セマンティック検索を活用することで、より関連性の高い文書をより速く検索することができる。私たちはまず、分析するすべての文書を取り出し、テキストを埋め込みに変換することから始める。重要な利点は、埋め込みデータを生成するためにオリジナルのLLMを使用できることで、最終的にLLMの「思考プロセス」を検索に残すことができます。すべてのデータを埋め込むと、（埋め込みと元のテキストを）Milvus内のあらゆるメタデータと一緒に保存することができる。そして、クエリが入ってきたら、クエリテキストを受け取り、同じモデルを使って埋め込み、関連するテキストを検索し、LLMに送り込んで答えを生成することができる。このパイプラインは単純に聞こえますが、作成にはかなりの労力を要します。幸運なことに、LangChainはこのようなパイプラインを簡単に作ることができ、vector databasesのためのVectorStoreラッパーを提供しています。
統合
MilvusとLangChainのインテグレーションを紹介します。
``python class VectorStore(ABC)： """ベクトルストアのインターフェース"""
抽象メソッド
def add_texts(
self、
text：Iterable[str]、
metadatas：Optional[List[dict]] = None、
**kwargs：任意の、
)-> List[str]：
"""エンベッディングを通してより多くのテキストを実行し、vectorstoreに追加します。"""
抽象メソッド
def similarity_search(
self, query: str, k: int = 4, **kwargs：任意の
)-> リスト[ドキュメント]：
"""クエリに最も似ているドキュメントを返す。"""
def max_marginal_relevance_search(
self, query: str, k: int = 4, fetch_k: int = 20
)-> リスト[ドキュメント]：
"""最大限界関連度を用いて選択されたドキュメントを返す。"""
raise NotImplementedError
クラスメソッド
抽象メソッド
def from_texts(
cls：型[VST]、
texts：List[str]、
embedding：エンベッディング、
metadatas：Optional[List[dict]] = なし、
**kwargs：任意の、
)-> VST：
"""テキストと埋め込みから初期化されたVectorStoreを返します。"""
前述したように、MilvusをLangChainに統合するにはVectorStoreクラスを拡張する必要があります。そのためにはいくつかの重要な関数を実装する必要がある：add_texts()`、`similarity_search()`、`max_marginal_relevance_search()`、`from_text()`である。Milvus VectorStoreはほとんどの場合、シンプルなパイプラインに従って動作する。まず最初にDocumentsのコレクションを受け取ります。ほとんどのLLMプロジェクトでは、Documentは元のテキストとそれに付随するすべてのメタデータを含むデータクラスである。Documentのメタデータは通常JSONベースであり、Milvus内でよりアクセスしやすい保存が可能です。Milvus VectorStoreがDocumentを消費すると、その中にあるテキストを、指定された埋め込み関数を使って埋め込みます。多くのプロダクションシステムでは、これらの埋め込み関数は通常OpenAIやCohereなどのサードパーティのLLMサービスです。しかし、テキスト入力を受け入れ、ベクトルを返す関数を提供する限り、あなたのモデルを使用することも可能です。パイプラインのこの段階で、LangChainはMilvus自身に制御を移します。Milvusは埋め込み、元のテキスト、メタデータを取り込み、コレクションに格納します。より多くのドキュメントがコレクションに入るにつれ、保存されたすべてのエンベッディングをより高速に検索するためのインデックスが作成されます。
このパイプラインの最後の段階は、関連するデータの検索を実行することである。ユーザーが質問を送ると、テキストとメタデータのフィルタがMilvus VectorStoreに送られる。先ほどと同じ埋め込み関数を使って、Milvusは質問を埋め込み、そのデータを横断して類似検索を実行する。MilvusはVectorStoreとして2種類の検索を提供します。1つはデフォルトの検索で、オブジェクトをそのままの順序で返すもの、もう1つは最大限界関連度順序を使用するものです。最大限界関連度順序は、入力とのコサイン類似度が最大となる埋め込みを持つ例を見つけ、既に選択された例との近さに対してペナルティを与えながら繰り返し追加することで機能します。
MilvusをLangChainに統合するにはいくつかの問題がありました。JSONがサポートされていないため、Milvusのコンフィギュレーションがどのように生成されるかという性質上、事態は難しくなった。現在のところ、Milvus VectorStoreを使用するためのルートは、すでに存在するMilvusコレクション上でVectorStoreを作成するか、Milvusに渡された最初のドキュメントに基づいてVectorStoreを作成するかの2つしかありません。コレクションが既に存在する場合、スキーマは決まっています。追加されるすべてのデータはスキーマに忠実である必要があり、データが欠けていたり、不正な形式であったりすると、システムはそのエントリをすべて無視します。
同様に、Collectionの作成後にDocumentに余分なメタデータが追加された場合、その余分なメタデータは無視されます。このため、適応性の高いシステムにはならず、入力のクリーンアップや、新しいコレクションの作成に余分な作業が必要になります。幸いなことに、Milvusはバージョン2.3でJSONを保存する機能を追加し、この統合とさらなる統合を簡素化する予定です。[Milvus 2.3](https://github.com/milvus-io/milvus/releases/tag/v2.3.0-beta)は現在ベータ版です！
## 結論
結果として、LLMのためのワーキングメモリと知識ベースができた。統合がマージされてから、LangChainは少し変化し、リトリーバという考え方を取り入れました。リトリーバは外部ストレージに接続するためのもので、LangChainが進む道です。このプロジェクトは動きが速いため、Milvus VectorStoreにあるコードはよりクリーンなものになる可能性があり、次のステップではそれをクリーンアップし、このリトリーバ機能を追加する予定です。先に述べたように、Milvusは動的スキーマを扱うことができないため、事前に作成されたコレクションやデータが欠落しているインサートを扱うことは非常に困難です。MilvusがJSONメタデータをサポートするようになれば、この統合をやり直す時が来るだろう。
全体的に、このプロジェクトでの作業は素晴らしい経験でした。コミュニティは友好的で、[Harrison](https://github.com/hwchase17)はとても積極的で親切です。LangChainプロジェクトが到達する高みを見るのが楽しみです。
Filip HaltmayerFilip Haltmayer is a Software Engineer at Zilliz working in both software and community development. His contributions mainly revolve around the Milvus and Towhee projects, helping develop both applications and helping grow their respective user bases through client interaction, integrations, and technical talks.
読み続けて
Will Amazon S3 Vectors Kill Vector Databases—or Save Them?
AWS S3 Vectors aims for 90% cost savings for vector storage. But will it kill vectordbs like Milvus? A deep dive into costs, limits, and the future of tiered storage.
VidTok: Rethinking Video Processing with Compact Tokenization
VidTok tokenizes videos to reduce redundancy while preserving spatial and temporal details for efficient processing.
Top 5 AI Search Engines to Know in 2025
Discover the top AI-powered search engines of 2025, including OpenAI, Google AI, Bing, Perplexity, and Arc Search. Compare features, strengths, and limitations.