AIネイティブな会社をつくる

• 2020年代初頭には生成AIに大きな関心が集まっていた
  • 生成AIツールが私たちをどのように形づくるのか、文章作成、コーディング、アニメーション、情報消費のあり方にどのような影響を与えるのかについての議論が主流だった
  • しかし、私たちのツールの形そのものについては、それほど多く語られていなかった
• 1960年代後半、情報システムは膨大なデータ量のために、関連情報を検索するプロセスのコストがますます高くなるという問題に直面していた
• 1980年代から90年代にかけては、リレーショナルデータベースが支配的なソリューションとなった
  • 直感的なインデックス機能を提供し、クエリ効率を保証していた
  • リレーショナルデータベースは、データを構造化された関係を持つテーブル群として表現できるようにした
  • SQLのようなクエリ言語を通じて、より高速なデータ検索を可能にした
• データベースアーキテクチャが進化する過程で、IBM、Oracle、Sun Microsystems、MongoDBなど特定の企業が、それぞれの新興市場で地位を固めていった
• Oracleがリレーショナルデータベースの世界を主導していたが、人々が情報を保存しアクセスする方法は変化し続けてきた
  • 新しい仕事が生まれるたびに、人々はそれを管理するための新たなアーキテクチャを考案してきた
• 近年のデータベースの進化は、非構造化データを扱う必要性から生まれた
  • 過去50年以上にわたり、スキーマは主に構造化データの関係を中心に構成されてきた
  • しかし、ますます多くの人々が、データの曖昧さをはるかにうまく扱えるツールを必要とするようになった
  • そこでベクターデータベースが登場した
• GPTのようなトランスフォーマーベースの大規模言語モデル（LLM）は、テキストの長期依存関係を捉えることができる
  • しかし、長文の理解力を維持することは計算コストが高くなりうる
  • ベクターデータベースは、こうしたモデルのコンテキストウィンドウを拡張できる
• ベクターデータベースはAIのユースケースにおいて強力でありうる一方で、依然として入出力によって動く愚直なインフラにすぎない
  • データを理解したり解釈したりする能力が不足している
  • 単に指示されたとおりにデータを保存・検索する保管庫として機能するだけで、本質的な知能や状況認識は持たない
• 2020年のGPT-3のリリースによって、AIは企業向けプロダクトの付録ではなく、コアとしてますます活用できるようになった
  • トランスフォーマーアーキテクチャ、データ量の増加、性能向上などにより、AIベースのプロダクト開発の土台が整えられた
• AI-Native（AIベース）企業が増え規模を拡大するにつれて、AIベースのユースケースを支えるツールの必要性も高まっている
  • 第一波のAI中核企業は、主に既存モデルを用いた推論に焦点を当てていた
• しかし、性能が向上したモデル、特に容易にアクセスできるオープンソースモデルによって、企業はAIベースのビジネスとしての能力をより深く構築できるようになった
  • この拡張性は、AIベースの技術スタックがどのような姿を取りうるかについて、機会の世界を切り開いている

私たちを形づくるツールたち (The Tools that Shape Us)

• 1967年、マーシャル・マクルーハンの友人であるJohn M. Culkinは「私たちは道具をつくり、その後で道具が私たちをつくる」と語った
  • 技術をつくることも同じだ
  • 私たちがソフトウェアをつくるために使うインフラは、私たちの構築要件に合わせて絶えず進化してきたし、その後の構築は、私たちが整えたインフラによって形づくられる
• 2020年代初頭には生成AIに大きな関心が集まっていた
  • 特に、生成されるテキストやコード、レンダリングされる画像、作成されるディープフェイク、合成される音楽など、成果物に焦点が当てられていた
  • こうしたツールが私たちをどのように形づくるのか、文章作成、コーディング、アニメーション、情報消費のあり方にどのような影響を与えるのかについての議論が主流だった
  • 人々は、オープンな大規模言語モデルと独自大規模言語モデルの比較性能、ハルシネーションのリスク、プラットフォーム対機能の議論、既存企業対スタートアップの議論などを論じていた
• しかし、私たちのツールの形そのものについては、それほど多く語られていなかった
  • 根本的に、私たちが技術を構築する方法は、その構築のために整えたインフラによって形づくられてきた
  • SaaSの普及はインターネットによって加速され、スマートフォンの普及によってモバイル開発が可能になり、クラウドコンピューティングによってアプリケーション世代のスケーラビリティが促進された
• アプリケーションにおけるAIの普遍性は、コンピューティング、モデルの機能、そしてビジネスのユースケースの中でそのモデルをどうオーケストレーションするかによって左右される
  • この記事では、そのオーケストレーションの要素に焦点を当てる
  • あらゆるAIユースケースをオーケストレーションするうえで、重要な要素のひとつが企業のデータベースだ
  • データが保存され、操作され、呼び出される場所は、このパズルの重要な一片である
  • しかし、これから示すように、データベースの歴史はおおむね愚直なインフラの歴史だった
  • AIの有用性を最大化するには、データベースを生成の方程式の一部となるようにつくる必要がある

データの基盤 (A Base For Data)

• 1959年5月、CODASYL（Conference on Data Systems Languages）が初めて招集され、「ビジネスアプリケーションを構築するための汎用言語」の構築を目指した
  • 1960年代後半、情報システムは膨大な量のデータにより、関連情報を検索するプロセスがますます高コストになるという問題に直面した
• メインフレームコンピュータの利用は、一般にアプリケーションの保守、パッチ適用、性能維持に必要なアップグレード費用などにより、活用度が高まるにつれてMIPS（1秒あたり数百万命令）のコスト増加につながった
  • データベース管理の複雑さ、硬直した階層構造、複雑なナビゲーション構造のマッピングなどにより、企業はしばしば必要な情報にアクセスするために技術的な専門知識を必要とし、関連情報にアクセスするためにプログラム全体を書かなければならない開発者さえいた
• 1970年、E.F. Coddは「A Relational Model of Data for Large Shared Data Banks」を発表し、共有特性（すなわち、一意のレコードを識別する主キーと、テーブル間の関係を設定する外部キー）によってテーブルを結び付けられるモデルを提案した
  • これにより、単一のクエリで異種のテーブルからデータを検索できるようになった
  • Coddのリレーショナルデータベースは、データ項目間の関係に基づくことで、データ操作と利用の柔軟性を可能にした
• 1973年、IBMサンノゼ研究所のプログラマグループがSystem Rプロジェクトに着手し、リレーショナルデータベースシステムが本番利用に必要な完全な機能を統合しながら、なお高い性能を発揮できることを実証した
  • このチームはデータベース効率化のためのコストベース最適化プログラムを開発し、System Rから派生した開発は後にIBM初のリレーショナルデータベース製品であるSQL/DSのリリースへとつながった
• 1980年代と90年代には、リレーショナルデータベースが支配的なデータベースソリューションとなった
  • 直感的なインデックス付けを提供し、クエリ効率を保証した
  • リレーショナルデータベースは、データを構造化された関係を持つテーブルの集合として表現できるようにした
  • SQLのようなクエリ言語を通じて、より高速なデータ検索を可能にした
• リレーショナルデータベースは、単一マシン上で動作することを前提に構築されていた
  • しかし、1990年代から2000年代にかけてインターネットが大規模に普及したことでデータが爆発的に流入し、単一のコンピュータでは処理しきれないほど重いワークロードが発生した
  • 従来のSQLデータベースは単一サーバー上で動作するよう設計されており、ユーザーは保存容量に合わせて物理ハードウェアを増強する必要があったが、これはより大規模なワークロードを運用する企業にとって非常に高コストであることが判明した
• 2010年代には、OLTP（オンライントランザクション処理）に関するデータとユーザーが爆発的に増加し、分散データベース、データウェアハウス、OLAP（オンライン分析処理）の広範な増加につながった
• リレーショナルデータベースとSQLは、もはや必要とされるアプリケーションの規模や複雑性に適しておらず、NoSQLデータベースが性能向上の手段として登場した（ただしACID機能を犠牲にして）
  • リレーショナルデータベースは構造化データを保存・操作できたが、JOINのオーバーヘッドやCRUD処理のコストを考慮すると、データ間の関係を維持することは難しかった
  • リレーショナルデータベースは、論理的または離散的な要件を持つ関係データの処理には適していたが、一般的にはリレーショナル構造向けに特化して構築されたレガシーシステムに合わせられていた
  • NoSQLは、非構造化ビッグデータを処理する手段として登場し、非リレーショナルなアプローチを通じて開発者にデータ永続性を提供した
  • SQLを基本クエリ言語として使う代わりに、NoSQLはAPIを通じたアクセスを提供し、より高いスケーラビリティ、分散コンピューティング、コスト削減、スキーマの柔軟性を実現した
  • NoSQLデータベースは水平スケール可能な効率的アーキテクチャとして動作するため、ストレージまたは計算容量を増やすには、より多くのサーバーやクラウドインスタンスを追加するだけでよかった
  • 非構造化データのより高速な処理や分析のためのデータワークロードを持つ企業では、NoSQLデータベースが好まれた

OGデータベース戦争

• データベースアーキテクチャの進化の過程で、特定の企業がそれぞれの新興市場で地位を固めていった
  • IBMがSystem Rをリリースした直後、33歳のLarry EllisonはCoddのリレーショナルデータベースに関する同じ論文を読んだ
  • Ellisonと2人の共同創業者はSystem Rと互換性のある会社を設立しようとしたが、IBMはそれを非常に困難にした
  • その結果、この3人組は新たな主力データベース製品であるOracle Databasesを中心に事業を構築した
  • それ以来、Oracleのデータベースはトップ製品となり、2024年5月時点で市場シェアは約28.7%である
• Oracleの1986年IPO直前の数年間に、別の企業がデータベース分野に参入した
  • Sun Microsystemsは1982年にさまざまなコンピュータ部品を販売する会社として始まったが、Javaプログラミング言語やNetwork File Systemなどへの貢献で有名になった
  • 重要なのは、2008年にSun MicrosystemsがMySQLというオープンソースのデータベース管理システムを買収したことだ
  • そのわずか2年後、OracleはSun Microsystems（MySQLを含む）を買収した
  • ほぼ15年が経過した2024年5月時点でも、主要なデータベースはOracle（市場シェア28.7%）とMySQL（約17.3%）である
• Oracleがリレーショナルデータベースの世界を主導していた一方で、人々が情報を保存しアクセスする方法は変化し続けてきた
  • 新しい作業が生まれるたびに、それを管理するための新しいアーキテクチャが考案されてきた
  • MongoDB（2007）、Databricks（2013）などのドキュメントストアから、InfluxDB（2013）、Prometheus（2012）などの時系列データベース、Neo4j（2007）、Cosmos（2017）などのグラフデータベースに至るまで、特化型データベースの一覧は増え続けている
  • リレーショナルデータベースの人気が着実に低下するにつれて、こうした新しいニッチなニーズに対して多様なソリューションが登場した
• データベースの最新の進化は、非構造化データを処理する必要性から生まれた
  • 過去50年以上にわたり、スキーマは主として構造化データの関係を中心に構成されてきた
  • しかし、ますます多くの人々が、データの曖昧さをはるかにうまく処理できるツールを必要とするようになった
  • そこでベクトルデータベースが登場した

ベクトルデータベースの台頭

• 大規模言語モデル（LLM）と生成AIの広範な普及により、ベクトルデータベースは非構造化マルチモーダルデータを処理できるツールとして台頭した
  • 既存のリレーショナルデータベース（Postgres、MySQL）が構造化スキーマに最適である一方、ベクトルデータベースはベクトル埋め込み（言語モデルの重みに対する相対的な意味を含むデータの数値表現）を保存・クエリするのに適している
  • リレーショナルデータベースで一般的に使われる行と列の代わりに、ベクトルデータベースはデータを多次元空間上の点として表現し、正確な値ではなく類似性に基づいてデータをマッチングする
• 埋め込みモデルに応じて、データは異なるベクトル空間とさまざまな次元で表現されることがある
  • ベクトル埋め込みはデータポイントの意味を捉え、ベクトルデータベースで最も近いオブジェクトを検索することで、類似オブジェクトの検索を可能にする
• たとえばWord2Vecは単語をベクトルにマッピングし、意味、意味的類似性、他のテキストとの文脈的関係を捉えるのに役立つ
  • このアルゴリズムは浅いニューラルネットワークを使って、より広いテキストコーパスから特定の単語の意味を導き出し、ロジスティック回帰によって同義語を識別する
  • 特異値分解（SVD）や主成分分析（PCA）など、深層ニューラルネットワークに依存せずに埋め込みを抽出するのに役立つ手法もある
• 距離メトリクスはベクトル空間における点同士の相対的な「距離」を決定するのに役立ち、一般的な手法としてはユークリッド距離、マンハッタン距離、コサイン距離、ジャカード類似度などがある
  • K近傍法（KNN）と近似最近傍探索（ANN）は、画像、動画、その他のマルチモーダル入力に対する類似性検索を簡素化し、実行時間の改善に役立つ
• Weaviate、Chroma、Qdrant、Pineconeなどのベクトル専用データベースは、開発者が大規模データ、特に非構造化入力を扱う際に検索を容易にするうえで役立つ
  • 既存のリレーショナルデータベースやNoSQLデータベースと異なり、ベクトルデータベースはベクトル埋め込みを処理するために特別に設計されている
  • 従来のデータベースがデータをスカラーとして保存するのに対し、ベクトルデータベースはベクトルのみを保存し、量子化やクラスタリングといったインデックス技術を活用して検索処理を最適化する
• GPTのようなトランスフォーマーベースのLLMは、テキストの長期依存関係を捉えることができる
  • しかし、長文の理解力を維持することは計算コストが高くなり得る
  • 最新のLLMは入力全体にわたるトークン対のグローバルな依存関係を捉えられるが、時間・空間計算量のために計算資源の問題が生じ、学習時の入力テキスト長と推論時の有効なコンテキストウィンドウが制限される
• 多次元のケースでは相対位置エンコーディングの実装が難しく、相対位置をエンコードする大半のアプローチでは、推論時の性能低下につながる強力な位置埋め込みメカニズムが必要になる
  • テキスト長が増加する場合でも、ベクトルデータベースはモデルの長期メモリとして重要な役割を果たし得る
  • ベクトルデータベースを使うことで、テキスト補完や要約のように文全体のコンテキストが正確な結果生成に必要となるタスクを簡素化できる
• ベクトルデータベースは検索拡張生成（RAG）を支援でき、この場合ベクトルデータベースは元のクエリに追加コンテキストを含めて、LLMに渡されるプロンプトを強化するために使われる
  • LLMはしばしば自己教師あり学習モデルに依存するため、特定の知識やより高い精度しきい値が必要なドメイン特化タスクで苦戦することが多い
  • RAGは、問題のクエリに対するコンテキスト不足によって発生し得るハルシネーションを緩和しつつ、応答がどのように導かれたかを確認・追跡・説明するのに役立つ
• 開発者は知識グラフとベクトル検索を組み合わせることで、LLMを学習データの範囲を超えて拡張できる
  • Microsoft ResearchのGraphRAGのようなツールは、プライベートデータセットに対する検索を実行する際のプロンプト拡張を容易にする
  • 基本的なRAGは、大規模なデータコレクションに含まれる要約された意味概念を全体として理解するのが難しいことが多いため、LlamaIndexやGraphRAGのようなツールはプライベートデータセットを基に知識グラフを構築する
• 開発者は特定の要件やユースケースに応じて、RAGより知識グラフを使う方が望ましい場合がある
  • ベクトルデータベースは類似性検索に適しており、文書や画像の検索、推薦生成に最適である一方、知識グラフは推論に適している（特にデータ収集、相互接続された関係とともにエンティティを抽出する場合、そしてそれらの関係をたどる際に有用）
• リアルタイムまたは準リアルタイムのデータ処理が必要なアプリケーションでは、より低遅延なクエリによりベクトルデータベースが好まれる場合がある
• 埋め込みを収集・保存することで、ベクトルデータベースは類似性検索の高速な検索を容易にし、入力されたプロンプトを類似した埋め込みと照合する
• 類似性ランキングは、推薦システム、意味検索、画像認識、その他の自然言語処理アプリケーションに至る幅広い機械学習タスクを支援するのに役立つ
• ベクトルデータベースは、ベクトル埋め込みの効率的な保存と検索を可能にすることで、LLMの性能向上に重要な役割を果たす
  • これにより、大規模な自然言語の自動理解が可能になる
• しかし、ベクトル埋め込みはN+1のイノベーションを表している
  • リレーショナルデータや時系列データのような従来のデータ形式の延長線上にある
• レガシーデータベースベンダーは、MongoDBのAtlas Vector Search、SingleStoreのベクトルデータベース、Neo4Jのベクトル検索インデックスといったベクトル機能の提供を開始している
• ベクトルデータベースはAIのユースケースで強力になり得るが、依然として入出力によって動作する愚直なインフラである
  • データを理解したり解釈したりする能力が欠けている
  • 単に指示された通りにデータを保存・検索するストレージとして機能するだけで、本質的な知能や状況認識はない
• 最新のAIベースのアプリケーションでは、これだけでは十分ではないだろう
  • 企業はますますAIモデルを中核として構築している
  • したがって、アプリケーションがますます知的な機能を示すようになるには、インフラにも同様の知的機能が必要になるだろう

第1世代のAI-Native企業

• 1956年にダートマス大学で学界が初めて人工知能の研究を始めて以来、実用的なユースケースがこの分野を発展させてきた
  • たとえば1960年代後半、Joseph WeizenbaumはELIZAというコンピュータープログラムを作成したが、パターンマッチングによって会話をシミュレートする単純なアプローチが初歩的なセラピーに似た対話に使われた（最初のチャットボット）
• ビジネス上のユースケースにおけるAI活用の歴史の大半では、AIの改善は漸進的だった
• AIという用語が流行する前は、同じ技術を指すために機械学習という用語のほうがより頻繁に使われていた
  • つまり、「データから学習し、未知のデータへ一般化できる統計アルゴリズムであり、明示的な指示なしにタスクを実行できる」
• 一般の認識という観点では、AIは2022年11月30日にOpenAIがChatGPTを公開したことで変曲点に達したが、技術的観点での転換点はそれよりかなり前に起きていた
• 2017年11月、国際的な規制機関である金融安定理事会（FSB）は、金融サービスに対する機械学習の影響についての概要をまとめた
  • 金融サービス企業は、「信用力評価」のような業務を実行するために機械学習をますます活用し、「より効率的な金融システムへの貢献」が可能になっていた
  • つまり、効率性は高められるが、存在論的に不可欠な要素を構成するわけではなかった
• 一方で機械学習はますます進歩し、2018年5月にOpenAIは大規模モデルの学習に必要な計算資源の歴史に関する研究を発表し、2012年以降3.4か月ごとに倍増しており、計算量が30万倍に増えたことを示した
• その翌月の2018年6月、OpenAIはGPTモデルの最初の紹介を発表した
• 二つの陣営のあいだで議論が形成されつつあった
  • 一方では、ますます大きなモデルの継続的な成長には収穫逓減の法則が働くと考える人が多かった
  • OpenAIが属するもう一方の陣営は、規模が大きくなるほど性能は引き続き向上すると考えていた
• 2020年1月、OpenAIの研究者でありジョンズ・ホプキンス大学教授でもあるJared Kaplanは、他の研究者とともに「Scaling Laws for Neural Language Models」を発表し、そこでは次のように述べられている:
  • 「モデルサイズ、データ、計算資源を適切にスケールさせることで、言語モデリング性能は滑らかかつ予測可能に向上する。私たちは、より大きな言語モデルが現在のモデルより高い性能と高いサンプル効率を示すと期待している。」
• 2020年5月、OpenAIはGPT-3に関する「Language Models are Few-Shot Learners」という論文を発表し、計算資源の増加に伴う性能の滑らかなスケーリングを示した
• さらにOpenAIは、規模を拡大すると汎化可能性も向上することを発見し、「大規模言語モデルのスケーリングは、タスクに依存しないfew-shot性能を大幅に改善し、ときには従来の最先端ファインチューニング手法に匹敵する競争力を持ちうる」と主張した
• フリーランス研究者のGwern Branwenはブログ記事でスケーリング仮説を提唱し、次のように述べた:
  • 「2020年5月にOpenAIが発表したGPT-3は、これまでに訓練されたニューラルネットワークの中で最大であり、桁違いに大きい……多くの人々（私自身を含む）の予想に反して、この巨大なスケール増加では、OpenAIの予測どおりスケールの恩恵が引き続き現れ、多くの人が予想していた収穫逓減やマイナスのリターンにはぶつからなかった。」
• Branwenが感じたその驚きは、風景の変化そのものだった
• AIは会社の製品に付け加える付録ではなく、ますます中核として使えるようになっていた
• トランスフォーマーアーキテクチャ、増加したデータ量、向上した性能水準のすべてが、AIベースの製品開発の土台を整えた
• GPT-3が公開された直後の2020年5月、WriterやJasperのような企業は、AIモデルを事業の中心に据えたコピーライティング製品を作った
• HarveyやEvenUpのような企業は、AIを中核に法務テックを構築した
• DeepScribeやFreedのような企業は、AIを中心に医療トランスクリプションを構築した
• しかし、過去に新たなユースケースがデータベースの進化をもたらしたように、AIベースの製品の誕生は、各社の技術スタックの背後にあるインフラが変化し適応しなければならないことを意味していた

AI-Native Database

• AIベースの企業が増え、規模も拡大するにつれて、AIベースのユースケースを支えるツールへの必要性も高まった
• 第1波のAI中核企業は、主に既存モデルを使った推論に焦点を当てていた
  • アプリケーションやコピーライティング、医療トランスクリプションなどのための目的別ワークフローツールを備えていた
  • 製品の中核は、モデルによって生成されたテキストや生成画像のような出力だった
• 2023年11月のOpenAI DevDay以降、「OpenAIが私のスタートアップを潰した」というミームが広まり始めた
  • 特定分野向けGPTやAIエージェントは、既存モデルの推論に焦点を当てていたため、こうした初期のAIベース・スタートアップの役割を担うように見えた
  • OpenAIは偶然にも、モデルとアプリケーションの両方の供給者になっていた
• モデル機能を中心としたイノベーションがあまりにも速く進み、スタートアップにとって脅威のように感じられ始めた
• しかし逆に、高性能なモデル、特に容易にアクセスできるオープンソースモデルによって、企業はAIベース・ビジネスとしての能力をより深く構築できるようになった
• AIベースの技術スタックを構築することは、モデルの周囲にコンポーネントを追加する以上のことを意味する
  • たとえば、AIのために特別に作られたデータベースはどのようなものだろうか
  • 推論が重要な出力であるなら、AIネイティブなデータベースは単にデータを保存・検索するだけでなく、保存されているデータに対して何を行うべきかについて、コンテキストに応じた指示を扱える必要がある
• その一例として、EC向けの商品説明のパーソナライズが考えられる
  • ベクトルデータベースは、商品SKUや説明文のベクトル埋め込みだけでなく、ユーザーペルソナに関する埋め込みも保存できる
  • データベース内のこうしたコンテキストデータをすべて使うことで、インフラは商品説明へのクエリが関連するユーザーペルソナへのクエリも引き起こし、その関連ユーザーペルソナに基づいて商品説明を書くという生成フィードバックループを活用できる
• 同様に、言語も生成フィードバックループとして使える
  • たとえばユーザーは、さまざまな言語で商品説明を生成したいかもしれない
  • ユーザーに合わせてカスタマイズされるだけでなく、ユーザーが選択した言語に翻訳された商品説明を生成できる
  • この種の指示は、生成AIのようなユースケースがますますアプリケーションの中心機能になるため、データベースに直接組み込める
• ユースケースに合わせてインフラを進化させること自体は新しいことではない
  • もともと開発者は、JavaScriptを使ってブラウザ上でアプリケーションを構築し、Webサイトを対話的かつ動的にしていた
  • しかし、開発者がこれをバックエンドにも持ち込めると気づいたことで、node.jsが生まれた
  • その後、開発者がより多くのモバイルアプリケーションを作り始めると、より動的で反応性が高く、データ駆動型のアプリケーションを可能にするJSON（JavaScript Object Notation）が登場した
  • MongoDBは、進化するインフラ要件に対応するために登場した企業として、この波に完璧に適合していた
• AIによって歴史は繰り返されている
  • 要件が変わるにつれて、インフラもそれに応えるため進化しなければならない
  • 最大の問いは、人々がどのような種類の企業を築きたいのか、そしてどのような種類のインフラがそのような企業に最も適しているのか、ということになるだろう
  • BobがMatthew Lynleyとのインタビューで語ったように:
    • 「私は、未来のすべてのアプリケーションにAIが含まれるようになると強く信じています。AIが振りかけられるアプリケーションもあれば、AIがアプリケーションの中心にあるものもあるでしょう。AIを取り除けば、もはや存在しません。Webアプリを構築し、その上にAIを振りかけたいならMongoDBを使ってください。特にすでに使っているなら……AIがアプリケーションの中核であるAIベースのアプリケーションを構築したいなら、Weaviateを検討すべき時です。」
• 今後、企業はAIを付録として、つまりBobの言う「sprinkle」として製品を構築するのか、それとも製品の中核に据えるのかを決めることになる

AI-Native 技術スタック

• AIを製品の中核的な構成要素として構築しようとする企業にとっては、既存のインフラでは適切でない可能性が高い
  • レガシーツールを使うと、データの保存・整理・実行は1つのサイロで構築され、自動化は別のサイロで構築される
  • このアプローチの欠点は、製品をよりよく知らせ改善できる生成フィードバックループのようなものからコンテキストが失われることにある
• 「AI隣接」スタックから来る企業の場合、特定モデルの推論はしばしばコンテキストウィンドウに制限される
  • 一部には、与えられたコンテキストウィンドウの容量が増えればベクトルデータベースを代替できると考える向きもある
  • しかし、ベクトルデータベースのほうが進化してコンテキストウィンドウを代替するという逆の状況のほうが、実際には起こる可能性が高い
  • ベクトル埋め込みは生成モデルにとって極めて重要であり、生成結果のためのインフラはベクトル埋め込みを第一級の要素として扱うべきである
• 単にコンテキストウィンドウのサイズを大きくするのではなく、ベクトルデータベースをモデルに組み込むことで、コンテキストウィンドウの文脈理解とデータベースの信頼性・拡張性を提供できる
  • 特に、モデルが汎用的であるほど、特定のタスク向けに作り込まれている可能性は低くなる
  • AIベースのベクトルデータベースは、より具体的な機能を可能にするだろう
• GPT-4のような汎用モデルは、知識を意図的に一般化するように構築されている
  • 製品が少しのシンプルなファインチューニングに依存しているだけなら、ベースモデルはそのビジネス固有の価値ある部分にはならないだろう
  • AIベースの製品を構築することは、モデルを活用することに加えて、より緊密に結び付いたスタックを中心に製品を構築することを伴う
  • このスタックは、データベースの規模とモデルの機能を提供し、より有能な製品を生み出すだろう

[savvykang]

ベクトル埋め込みの生成やベクトルDBのユースケースがもっと増えて、標準的なワークフローが出てくるといいですね。1年くらい待てばよいのでしょうか。