データ 3.0 時代では、大規模なモデルとデータを通じて、企業や開発者が使用するコードを減らしたり、アプリケーションを構築したり、自然言語を通じてサービスを提供したりすることは避けられない傾向となっています。大規模な言語モデルの対話機能を通じて、データの価値を直接採掘して解放できるため、データ ユーザーの敷居が大幅に下がり、より多くの可能性が開かれます。
11 月には、「ビッグ モデル時代におけるデータの新たな地平」をテーマとしたオフライン コミュニティ ミートアップを開催し、産業界、学界、研究の専門家を招待し、ビッグ モデルとデータから導き出されるいくつかの主要な探索方向に焦点を当てました。データベース、LLM+ データ、LLM+SQL、および LLM+Tools は、それぞれの技術的探求と実際の経験を共有し、主要な問題と開発傾向について共同で議論します。今後の数号の内容は、DB-GPT コミュニティの学生とテキスト版で共有され、共同学習やディスカッションが行われます。
この記事では主に大規模モデル時代のデータベース Milvus について説明します。Milvus プロジェクトは 2019 年からオープンソースになっています。4 年かかり、2 つのフェーズに分かれていました。2021年からはCloud Nativeというレーベルができ 、2022年からはAI Nativeという新しいレーベルもできました。
ベクトル データベースの誕生は、実際には、非構造化データの処理が困難であるという問題を解決するために生まれました。非構造化データには、今日話している長いテキスト情報だけでなく、動画、写真、音声などのマルチモーダルな情報も含まれるため、マルチモーダル大規模モデルも今非常に注目されています。
2019年頃からベクトルデータベースが最初に参入したシーンは画像検索や文字画像相互検索のシーンでしたので、当初の目標は「非構造化データをどうやって取得するか、意味検索をどうするか」という問題を解決することでした。もちろん、実際にはモデル側やインフラ側も含めて多くの問題があります。
大規模モデルの開発を含む動的モデルの開発では、実際には問題に対するいくつかの暫定的な解決策があることがわかります。しかし、インフラ側では、非常に大量のデータを扱っている場合、大規模モデルにより優れた機能を提供するために、10 億レベルまたは数百億レベルの画像やテキストから必要なデータをどのようにして迅速に呼び出すことができるでしょうか。RAG や Agent のいわゆる 長期記憶 でも、大規模モデルの学習や推論のプロセスでも、実は同様の要求があり、これがベクトルデータベース誕生の本来の意図でもあります。
ベクトル検索をデータベースと組み合わせるのはなぜですか? データをどのように処理するかを考えると、OB、ODPS、さまざまなデータベースを使用して処理することを必ず考えるでしょう。しかし、非構造化データの分野では、AI が普及して以来、あるいはニュース ネットワークで AI が普及して以来、誰もが行ってきたことは煙突型アプリケーションに似ています。つまり、AI チームは上のモデルのトレーニングと下のデータの洗浄を担当し、すべてのデータ ガバナンス、すべてのインフラ側、さらにはポーチさえもアルゴリズム チーム自身によって維持されます。もちろん大手メーカーの方が良いのかもしれませんが、今後5年、10年でAIが発展していくと、確実に階層化が進むと思いますので、AIに関する非常に良いインフラを提供できればと思っています。データ面です。
ベクトルデータベースとは何ですか? 簡単に理解すると、ベクトル データベースは高次元ベクトルを管理およびクエリするためのシステムであり、いくつかの注目すべき機能があります。
まず、データベースであるため、追加、削除、変更、およびクエリを実行する基本的な機能が必要です。現在の多くのベクトル データベース、または前世代のベクトル検索システムは、更新機能や削除機能が非常に弱いです。従来の検索と同様のオフライン インポート モードであり、データのバッチが毎日生成され、トレーニング後にインポートされます。この観点から見ると、ベクトルデータベースではありません。データベースなので、基本的な CRUD が十分にサポートされている必要があります。基本的なスキーマ定義とサポートされるデータ型が明確でなければなりません。もちろん、動的スキームでも構いませんが、データベースとして、データベースのいくつかの基本要件を満たしている必要があります。
第 2 に、ベクトル データベースには強力なベクトル検索機能が必要であることは明らかです。
最後に、ベクトル データベースのセマンティクスは十分に充実していなければなりませんが、ベクトル データベースは ANN だけを行うためのものでしょうか? 確かに、ベクトル データベースの最も基本的な操作は最近傍ゼロ一致です。しかし実際には、開発の過程で、ベクトル データベースは多くの新しいセマンティクスを進化させてきました。これは実際には非常に興味深いトピックです。join、groupby、count など、従来のデータベースで実装できるすべての操作は、ベクトル データベースで対応する実装を持っています。
ベクトル データベースを使用するプロセス全体は 3 つの段階に分けることができます。最初の段階でベクトルを取得するにはどうすればよいですか? もちろん、ベクトルの取得は埋め込みモデルに依存します。OpenAI の Adaや、BGE や Alibaba の GTE など、中国には非常に優れたオープンソース モデルもありますが、実際には非常に優れた埋め込みモデルです。埋め込みが生成された後、ベクトル データベースに挿入されます。真ん中には、従来の検索で誰もが行っている、インデックス構築の第 2 段階があります。インデックス作成はオフラインで行われ、多くの計算能力を消費するため、ベクトル データベースの中心的な課題は、インデックス作成のコストをいかに削減するかということです。もう 1 つの重要なコストは、オンライン サービス中のクエリ負荷を軽減するために、インデックス作成プロセス中にデータ内の一部の接続とセマンティクスを可能な限りマイニングする方法です。3 番目の段階は、インデックス作成後にクエリを構築することですが、クエリには多くの主要な課題もあります。たとえば、ストリーミング バージョンをどのように扱うか、削除をどのように扱うか、さまざまな複雑なセマンティクスをどのように扱うか、パフォーマンスも非常に重要な課題です。
上の図は Milvus 1.0 のアーキテクチャ図で、もともと 2019 年にベクトル データベースのあるべき姿として定義されました。簡単に理解すると、先行書き込みログ、ファイルを保存するファイル システム、ベクトル インデックス Faiss/Annoy/HNSW などのエンジン、いくつかのメタ定義とスキーマ定義、および単純な Deleted をサポートできるいくつかの基本的なフィルタリング操作があるということです。パフォーマンスは良くありませんが、複数の SDK をサポートできます。これはベクトルデータベースの最も初期の定義であり、世界初のベクトルデータベースの定義とも言えます。私たちはかつて、ベクトル データベースとは何かについて説明した記事 SIGMOD 21を公開しました。
浅いものから深いものまで、ベクトル データベースの核心は何でしょうか? 実際には、これはベクトル インデックスであり、ベクトル インデックスは、ベクトル データベースがデータのインデックス作成とクエリを高いパフォーマンスで実行できるようにするための鍵でもあります。
ベクトル インデックスの実装にはさまざまな種類があり、上の図には、数値ベース、最も典型的なものは Annoy、ハッシュ ベースなど、より主流のもののうち 4 つがリストされています。パフォーマンスと精度の問題により、業界ではあまり主流のクエリ モードではなくなりましたが、最も主流となっているのは量子化に基づく FAISS です。FAISS は優れた実装ですが、Quanttation のこのリンクには、より競争力の高い競合他社である Google の scanが存在します。これも、オープンソースでより優れたパフォーマンスを備えたフレームワークです。最後のスプライト チャートは、スプライト チャートの分野で最もよく知られているのは HNSW で、実際にはジャンプ テーブルに似たデザインです。最下層は完全な画像であり、いくつかのインデックス画像が上層に構築されます。このように、検索するときはスキップ リストのようなもので、最初に上からいくつかの隣接ノードを見つけ、次にレイヤーごとに下に検索して、一番下にある最終的なクエリ結果を見つけます。Yahoo のオープンソース NGT や Microsoft のオープンソースのディスクベースのグラフ ソリューションなど、グラフにはさまざまなバリエーションがあります。興味があれば、関連する論文を読むことができます。基本的に、すべてのプロジェクトの背後に対応する論文があります。ベクトル検索へのリンクもチェックできます。
データベースとベクター検索が必要なので、PGvector や Elasticsearch を使用しないのはなぜでしょうか? これはテスラとクラシックカーの関係ですが、この類似点の主な理由は次の点です。
まず、ベクトル データと標準データの間には、データの分布に大きな違いがあります。たとえば、従来のすべてのデータベースは基本的にルーティングのためのハッシュ、または範囲ベースのシャーディングに基づいているため、クエリ中に主キー インデックスとセカンダリ インデックスをより効率的に使用できます。しかし、ベクトル データベースでは、ベクトルをシャーディングに使用することはできません。これが最も基本的なロジックです。したがって、ほとんどのベクトル データベースでは、検索ではすべてのシャードをチェックする必要があり、これは OLAP に似ています。これは MPP アーキテクチャに似ていますが、正確には MPP アーキテクチャではないため、多くの OLTP データベースは当然ながらベクトル検索には適していません。
第二に、100パーセント正確な問題ではありません。完全に正しくないとはどういう意味ですか? これは、大規模モデル自体があまり安定したシステムではなく、決定的な答えを与えることができないためです。大規模なモデルの検索には 100% の正しい答えは必要ありませんが、一致に似た答えが必要です。これがセマンティクスと呼ばれるものです。では、このセマンティクスの影響は何でしょうか? OB システムがトランザクション使用シナリオに適用できることは誰もが知っています。OB システムは安定性と正確性に依存しており、間違ったトランザクションは存在しません。ベクトル検索の分野では、制約を取り除くことができますが、それはまったく重要ではなく、比較的合理的な答えが得られれば問題ありません。したがって、その背後には最適化のための非常に大きなスペースが存在します。すべてのデータベースが 100% 正確である必要がない場合、データベースは 10 回または 100 回最適化することができ、スペースが非常に大きくなることが想像できます。過去に述べた DB 用 AI の概念は、従来のデータベースに適用するのは非常に困難ですが、ベクトル データベースでは機能し、非常にうまく機能します。モデルを使用して Auto Tune を実行すると、効果は非常に優れており、損失は非常に低くなります。
第三に、計算能力要件。従来のデータベースのボトルネックは IO またはネットワークにある場合があります。一部のデータベースは CPU にある場合があります。ほとんどのデータベース、特に OLTP データベースでは、通常、ボトルネックは CPU にありません。しかし、ベクトル データベースの場合、ボトルネックは CPU、より正確にはメモリ帯域幅にあり、直面する課題は従来のデータベースとはまったく異なります。したがって、帯域幅の最適化、キャッシュの最適化、ヘテロジニアスな計算能力など、多くの方法を試す必要がありますが、これがベクトル データベースと GPU をうまく組み合わせることができる理由の 1 つでもあります。
最後のポイントは、意味論的な複雑さがますます高くなるということです。以前はベクター データベースが ANN に使用され、Elasticsearch/PG も ANN に使用できましたが、ベクター データベースはそれだけではありません。
クラスタリングに基づくフィルタリングなど、多くのクエリ パターンがあることがわかります。たとえば、犬の写真を検索するが、その表現が「猫の写真は必要ありません」である場合、このタイプのクエリが高速 ?に置かれたらどうすればよいでしょうか。それを行うのは難しいと思いますが、猫にラベルを付けることしかできず、従来のデータベースの古い道に戻ります。しかし、猫のクラスタリングを完全に除外することはできるのでしょうか、それとも KNN 結合と呼ばれるより興味深いシナリオを実行できるでしょうか。テーブルを 2 つ用意して、1 つのテーブルに男性ゲスト、1 つのテーブルに女性ゲストを配置し、ベクトル近似によって男性ゲストと女性ゲストをマッチングするという、非常に興味深いシーンがいくつかあります。言い換えれば、ベクトル データベースは、従来のデータベースが実行できる多くのことを実行できます。重要なのは、それをどのように実行するかです。
なぜ 2.0 製品を作るのか? 上で説明した Milvus 1.0 の製品アーキテクチャは、非常に単純なデータベース実装です。2021 年から、データベースをやり直すことにしました。ラベルの 1 つはクラウド ネイティブ と スケーラビリティです。
もちろん、クラウドネイティブを目指すなら、無視できない重要なポイントがいくつかあるはずです。まず、クラウド インフラストラクチャとどのように統合するか? ストレージと計算を分離した後、ストリーミング データは分散 WL に保存されます。2 番目の非常に重要な点は、データ量が増加するとユーザー データを収容できなくなるということであり、これも分散システムを構築しなければならない重要な理由です。3つ目は、パブリッククラウドとの統合方法です。2021 年、K8S は非常に成熟したシステムになっているため、チームは K8S を使用してステートレス データベースをより適切に実行する方法を考えてきました。最後に 4 つ目のポイントは、AIGC の利用シナリオにおいてサーバーレスが非常に重要なポイントであるということです。大規模なモデルのほとんどは API サービスであるため、大多数の開発者は、基礎となるインフラストラクチャを自分で保守することを望んでいません。最後に感想です。商業的な要因はさておき、Zilliz は一流のデータベース製品を作りたいと考え、分散ベクトル データベースを作りたいと考えており、その結果は実際に達成されました。
上に示したように、これらは Milvus2.0 によってユーザーに提供されるいくつかのコア機能です。
まず、クラウドネイティブのディストリビューション、数百億のベクトル拡張をサポートし、ストレージとコンピューティングを分離するのに十分な弾力性を備えたいと考えています。すべてのデータは、オブジェクト ストレージ、メッセージ キューなどの基盤となるストレージに保存されます。
第二，流批一体，这并不是所谓的这种传统的 lambda 里面的流式，而是希望真正在一套系统里面能够很好的去解决用户的流式插入，并且能够实时查询的这种能力。
第三，引擎可插拔。大家可以看到整个 record index 有非常多的选择，不同的选择之间是有不同 trade-off。有的性能更好，有的内存占用更低，没有办法说出一个完美的索引，满足所有人的需求。现在来看，可能对于大公司来讲，性能是一个很重要的 concern。但对小公司来讲，可能成本或者内存的占用，这些其实变成非常重要的指标，因此希望引擎本身是可以可插拔的。
最后，云端一体，大家可以非常容易的在自己的笔记本上去做部署，也可以在自己公司的 K8S 里面去跑，更为重要的是可以在云上去跑。
未来在大模型的生态中，API 会成为最重要的一个武器。大家已经看到了OpenAI 的 assistant，包括它的 GPTS，本质上其实就是 functional call。虽然也提供了很多 retrieve 的能力，但至少 function calling 是最重要的。它可以把所有很多东西串在一起，能够帮助开发者最快速的去构建。因此API可能会变成未来数据库产品的一个飞轮。有 SQL 的支持固然很好，但如果没有 SQL 支持，API 足够的 popular，大模型学会了如何去写 API 的话，开发者的门槛一样是很低的。
如上图，这是 Milvus2.0 的最终架构，整个的设计理念其实就两点，第一存算分离，第二所有的计算节点微服务化。所有索引节点，所有的 query 节点，所有的数据节点，包括前面的代理全部都是 K8S 的 pod，全部都是微服务化。所有的数据全部都存在中间这一层，基于 Kafka 和 S3 去存，系统可以跟着 K8S 非常快的去做 scale，只需要去做一些内存的变化，一旦 scale 以后，数据直接从 S3 里面拉起来。
Milvus 还提供了面向 AIGC 场景的一些丰富能力。这些是在上一代的向量检索中所缺失的。
Sparse embedding，就是大家非常熟悉的 TF-IDF（Term Frequency-Inverse Document Frequency）和 BM25（Best Match 25）。但今天的稀疏向量有基于 AI 的提取方式，它可以更好地去帮大家做关键词的匹配，标量和向量的混合查询能力以及丰富的 API 支持。
支持多租户，如果今天要构建一个 knowledge base，可能有 100万个用户，在数据库里面它的 schema 到底应该如何设计？如果使用传统的一个表一个用户的方式，可能的表的数目会爆炸。如何能在一个向量数据库里面很好的去支持多租户是一个挑战，不过 Milvus 已经具备了这种能力。
海量数据离线导入的能力，类似于 hbase 里面的 Bulk Insert、Bulk Load。有这种非常快速可以把亿级甚至 10亿级别的数据导入到向量数据库里面并立即提供查询的一个能力。
另外，Dynamic Schema；Range search；磁盘索引，基于 MMAP 的把数据放在磁盘上的能力，这是绝大多数向量数据库不具备的能力。
除此之外还有很多其他能力，比如说 CDC、多向量的支持、标量索引的倒排等，这些都是在的设计的计划里，预计会在今年陆续上线。
最后说一下性能。提起向量数据库，用户最关心的一定就是性能。如果大家感兴趣或者是做向量数据库，可以跑一下的 VectorDB Benchmark，它是完全开源的，有比较丰富的测试集，包括过滤的测试集、各种各样不同参数的搜索、不同大小的数据集。
那么如何去优化数据集呢？其实主要就三件事情。第一是算力，如何找到最便宜最高效的算力，除了 GPU 以外，ARM 是可以去深度挖的一个点，包括所有 Intel CPU 新的指令集，现在用 AVX-512 VNNI 以及最新一代的 amx 指令集，其实对性能有非常好的提升。目前，支持的 ARM SVE 的厂商比较少，我们是在 amx 上面去做的。另外，支持NVIDIA 最新的 GPU 图索引，我们也把它贡献给了社区，性能比传统的 GPU index 要好很多。
第二个其实是算法侧，算法包括怎么去优化图，怎么去提升图的质量，怎么在搜索的过程中尽可能去剪枝，是优化性能一个很重要的方式。
最后，是查询的调度，包括 dynamic batching，如何做请求的合并，如何让集群的负载变得更加的均衡，回到传统数据库的领域。所以向量检索事情本质上是一个高性能计算加数据库，这是大家要去做的一个事情。
这些传统的场景大家可以看下，不再过多去展开了，大家如果是做这些相关业务的话，可以具体去聊。
第一个应用比较多的场景是 RAG ，主要解决了四个问题。第一个是大模型的幻觉问题，第二个是数据的新鲜度问题，第三个是数据的安全问题，最后一个是用大模型去输出结果如何验证的一个问题。因为 RAG 是会给一个 reference link，无论大家用图数据库来做，还是向量数据库来做，两者之间并不冲突，是一个很好的补充。
第二个有意思的场景叫 Semantic Cache。在 github 上面有一个蛮火项目叫 GPT Cache。最简单的一个思路是用 redis 去缓存 mysql 的数数据，有没有可能去缓存一下大模型的输出的结果，所以就做了这么一个项目。
其实整个的思路没有很复杂，用向量数据库做了语义的检索，如果问题语义匹配的话，就认为答案可能是相似的。目前可能还不完全是一个非常 production ready 的场景。但是确实给了很好的思路，并且在大模型的推理阶段，大家也会用这种类似的思路，基于召回，再去给大模型做加工，可以省掉很多 token，也是蛮常见的一个思路。
最后给大家分享一个比较新的话题，对于 openapi dev day 怎么看？大家也都知道 11月6日新开的发布会，推了几个比较重要的功能。第一个就是构建自己的 GPT，第二个就是关于 GPT-4 turbo支持非常长的 token，第三就是支持召回，支持function call。比较关注的是多模态 API，我们做了很多测试，结果可以给大家简单分享一下。我觉得 openapi 做召回还是在处于非常简单的一个阶段，大家解决不好的事情，它也没有解决的很好，比如说长文本的 summarize，就是给一本书，告诉书是做什么的，其实用 RAG 来解决是非常难的，包括很具体的问题，比如说有 100个 document，每个 document 有个 ID，问 document 的 ID50 讲什么事情？ChatGPT 会告诉搜不出来。我觉得搜索和大模型之间的深度结合，是一个非常好的 topic，本质上基于概率，因此搜索和和生成这两个问题一定是要一起去解决的。但是现在其实无论对谁来讲，都是非常早期的一个阶段。自己更希望大模型的公司，能去构建更好的一个生态，通过这种 function calling，以 agent 作为一个中心，所有的周边厂商提供更好的 API。比如说的图数据库可以提供一套 API，向量数据库提供一套 API，以 agent 为中心去把业务逻辑给串起来，是对未来的一个期望。
https://github.com/eosphoros-ai/DB-GPT
https://github.com/eosphoros-ai/DB-GPT-Hub
https://github.com/eosphoros-ai/DB-GPT-Web
本文分享自微信公众号 - ZILLIZ（Zilliztech）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。