データはAIエンジンを動かしますまた、多くの企業は、そのタンクを埋める方法が分からないため、すぐに利用できる非構造化データの宝庫を最大限に活用していません。
だからこそ、非構造化データを処理するツールを備えた企業が投資家の注目を集めているのです。つい先月、SalesforceはAgentforceプラットフォームを強化するために大規模な買収を行ったが、これは非構造化データ管理プロバイダーに対する最近の投資のほんの一つに過ぎません。
「生成AIは、RAGやLLMのファインチューニング、従来の分析における非構造化データ、特にドキュメントの重要性を高めました」と、IBM watsonxのプロダクトマネジメント担当副社長でありIBMの常駐データ専門家の一人であるエドワード・カルブスバート氏は述べています。「毎日生成されるデータのほとんどは構造化されておらず、最大の新たな機会をもたらしています。」
AIに最適な非構造化データを詳しく知りたいと考えていました。そこで、3月にIBM、Nvidia、Databricksと4000万ドルの投資ラウンドを完了したデータサイエンス企業Unstructuredのストラテジー責任者であるCalyvesbert氏とDave Donahue氏と対談し、非構造化データの重要性と今後の方向性についての見解を聞きました。
Edward Calvesbert、IBM:言語、画像などの非構造化データは、基盤モデルが利用する「新しい」データであり、解釈に役立つため、現在注目されているものです。しかし、構造化データと同様に、非構造化データも、分類、品質評価、PIIや好ましくないコンテンツのフィルタリング、重複排除などの管理が必要であるため、成功するストラテジーでは、従来のデータ管理の機能の多くを非構造化データに適用することになる。
Dave Donahue、非構造化: 非構造化データは本質的に構造化データよりも価値が高いわけではありませんが、一般に言えば、大規模な組織は構造化データの4倍の非構造化データを生成します。AIを導入する際に問題は より多くのデータや特に人間が生成した非構造化データを使いたいと思うかという点ですその答えは「イエス」です。
Calvesbert氏:「十分良い」という目標は常に変化し、ユースケースによって異なります。RAGがセマンティック検索、Q&A、カスタマー・サポート・エージェント向けの要約を改善するためのナレッジ・ベースでは、ドキュメントのナレッジ・ベースが完全、正確、最新であることが必要です。モデルを微調整するためのデータには、人がキュレートしたプロンプトとレスポンスのペアの例のセットが必要です。分析ユースケースを推進するためにテーブルやグラフ・データベースに処理される文書には、エンティティーまたは値の効果的な抽出が必要です。ほとんどすべての場合、データはユースケースのライフサイクルのコンテキストで分類、フィルター処理、管理する必要があります。
ドナヒュー:企業や会社レベルでは、「良い」データとは、クリーンで構造化され、充実したデータです。この前処理パイプラインでは、元のコンテンツとLLM対応バージョンの間の情報損失を最小限に抑える必要があります。非構造化を使用すると、企業はファイルの種類に関係なく、非構造化データを標準化された形式に変換し、追加のメタデータでそれを強化できます。これにより、組織はLLMを使用する際に直面する3つの重要な課題を軽減できます。それは、時間に縛られないこと、で運営する傾向があること、特定の組織についてすぐに知ることができないことです。
Calvesbert:当社が提携した大手通信会社のクライアントは、カスタマー・サポート・エージェント向けの社内知識ベースを確立しました。これにより、顧客への回答を得るまでの時間が短縮され、その回答の精度も向上しました。それは山火事のように有機的にコールセンター内に広がり、その時点で同社は一歩下がって、ガバナンスとコストパフォーマンスの取り組みを開始する必要に迫られました。社内では、IBMのブランド・ガイドラインと例を取り込んで新しいマーケティング・コンテンツを生成し、一貫した品質とトーンを実現できるようにキュレートするマーケティング・オートメーションのユースケースを実施しました。
ドナヒュー:私たちは、世界的な消費財メーカーと協力して、新製品のアイデア開発を支援しています。「それと非構造化データとの関係は?」と尋ねるかもしれません。これまでは、マーケティング・チームや製品チームが大量の販売データ、製品のフィードバック情報、人口統計情報を分析し、特定市場のエンド・ユーザー向けにテストできる新しいアイデアやコンセプトを生成するのに何カ月もかかっていました。そのプロセスを数か月から数時間に短縮する支援ができたらどうでしょうかチームが迅速にテストできるデータに基づいた製品の新しいアイデアを生み出すことができたらどうでしょうか。
それが、非構造化データを活用してビジネス価値を生み出す力です。現在、このCPG企業は、いくつかのブランドでデータを活用し、新製品のアイデアを開発およびテストし、市場に投入しています。
Calvesbert:どの企業にも文書があり、新入社員の受け入れ用として何を提供しているかを考察してください。RAGやセマンティック検索を試すにはそれだけで十分です。
Donahue 企業のデータの80%は、Eメール、メモ、社内メッセージング・プラットフォーム(SlackやMicrosoft Teamsなど)、ビジネス・プレゼンテーションなど、構造化されていません。問題はそのデータをどう使いたいかという点です現在同様のデータ・クリーニング作業を行っているエンジニアの効率化を図りますか。販売およびマーケティング・データに基づいて新製品のアイデアを開発しますか?AIには無数の可能性と機会があります。目的を特定しましょう。必要なデータを特定しましょう。小規模から始めましょう。
Calvesbert:考察するレイクハウス・アーキテクチャーとオープン・テーブル形式、つまりIcebergは主流となり、新しいデータやワークロードの主流となったデータ管理アーキテクチャーとなった。ベクトル機能は多くの運用/分析データベースでネイティブに提供されているため、生成AIワークロードを既存のアプリケーションに導入することができます。自明の関係に基づく追加のコンテキスト化(GraphRAG)や、取引記録からの精度の向上(SQL-RAG)が必要な特定のエンタープライズ・ユースケースには、RAGだけでは不十分だと業界が認識し始めています。クライアントは、エンタープライズ・コンテンツ管理システムで実施されているアクセス制御を尊重するユーザー認証モデルを実装することが、企業全体に生成AIを拡張するために克服するためのクリティカルな課題であることも認識しています。
Donahue:データサイエンスと機械学習エンジニアリングチームがデータ・エンジニアリングチームとより緊密に連携するようになりつつありますデータエンジニアリングチームは、過去10年間にデータウェアハウジングとBusiness Intelligenceアプリケーションの台頭を中心に成長し、歴史的には、データアナリストや経営幹部向けに設計されたSQL、構造化データベース、分析プロセスの世界で運営されてきました。企業がLLMに参入するにつれて、前処理された大量のデータを求める需要が爆発的に高まっています。ただし、これらの消費者は、Python、ベクトル・データベース、高速で使い捨てのユーザー・インターフェイスの世界で運用する傾向があります。時間の経過とともに、成熟したデータ・エンジニアリング・チームが、生成AIチームにエンタープライズ対応のデータを提供する責任を負うようになると予想されます。
Calvesbert:お客様はデータ資産とそれに関連するコストとリスクを簡素化したいと考えています。そのため、クライアントが少数のデータ・プラットフォームに統合しようとするにつれて、マルチモデル・データベースとマルチエンジン・レイクハウス・アーキテクチャーは、サイロ化されたデータベースとのワークロードに対する競争に勝ち抜くことができます。TextからSQLへのモデルは非常に優れています。これにより、ビジネス・インテリジェンスを超えた幅広いユースケースでデータを操作する際の障壁が劇的に軽減されます。
同様に、エージェントの急増により、爆発的な量とさまざまな自動化されたワークフローにデータが導入されます。これらのエージェント的ワークフローの一部は、多くのナレッジ・ワーカーの活動に革命をもたらし、刺激的な新しい機会を生み出します。顧客との内部または外部の会話を処理し、カタログ内の製品やCRMシステムの機会記録に即座にマッピングすることを想像してみてください。これには進行状況や成約傾向のアセスメントも含まれます。
Donahue:Snowflake、BigQuery、Databricksがデータウェアハウス空間に「データ・グラビティー」を確立した現代のデータ・スタックとは対照的に、非構造化データではまだ同じことは行っていません。また、構造化データの4倍の膨大な量であり毎年指数関数的に増加しているため、LLM向けの次世代ストレージ・ソリューションへの投資はこれまで以上に高いものになっています。ベクトル、グラフ、オブジェクト、またはその他のタイプのストレージのどの組み合わせが主流になるか、各Categoriesでどのベンダーが普及するかについてはまだ結論が出ていませんが、今後18~24カ月以内に勝者が明らかになるでしょう。