ブロックチェーン技術を活用したスケーラブルなセマンティックグラフデータベースである Fluree の共同 CEO。
大規模言語モデル (LLM) は素晴らしいものですが、企業はそのメリットをフルに活用できていません。最も一般的なユースケース (カスタマー サービス チャットボット、マーケティング ライティング、Copilot によるコード支援) でさえ、信頼性がありません。2024 年 2 月、エア カナダは、チャットボットが遺族運賃に関するポリシーをでっち上げたことで、顧客に損害賠償金を支払わざるを得なくなりました。法的幻覚は継続的な問題です。2024 年 2 月には、ChatGPT が英語のプロンプトにスパングリッシュで応答したこともありました。
LLM は、3 つの制約されたユースケースの枠を超え、信頼性と精度を高めるにはどうすればよいのでしょうか。その答えは、LLM がトレーニング対象以外のデータに安全かつ保護されたアクセスを提供することにあります。LLM がモデル中心の AI からデータ中心の AI に拡張されて初めて、幅広い企業で使用できるほど信頼性が高まります。
LLM は、そのままでは、トレーニングに使用した知識のみを使用します。モデルを更新しない限り、最新のデータはありません。微調整とは、新しいデータを使用してモデルを継続的にトレーニングするプロセスです。モデルを毎日トレーニングしない限り (これはコストのかかる継続的なプロセスです)、回答にリアルタイムの情報を使用することはできません。代わりに、古い情報を使用します。これに、LLM の回答を幻覚的に解釈する傾向を加えると、LLM がエンタープライズでの使用には不十分であることが明らかになります。
微調整はコストと時間がかかるため、ほとんどの組織ではそれを行うことによる ROI は見込めません。ただし、LLM がトレーニング データを超えて、信頼性が高く確実な回答を生成する別の方法があります。このプロセスは、データ中心の AI として知られています。
データ中心の AI (ランタイム AI とも呼ばれる) により、LLM はモデル外部の有効なリアルタイム データを取得して回答を通知できます。LLM は API を使用して、SQL データベースなどの外部ソースにクエリを発行します。回答を受け取った後、LLM はそれを応答に組み込みます。
このアプローチには、いくつかの利点があります。まず、組織はモデルの調整にかかる労力と費用を回避できます。次に、LLM により、ユーザーは SQL などのコードでクエリを記述する必要がなくなります。代わりに、ユーザーは「パイプラインには何がありますか?」などの一般的な質問をすることができます。その後、LLM は質問を CRM に基づいた営業回答を生成するクエリに変換します。モデルは、独自の回答を生成するのではなく、データベース クエリに応答するように事前にプログラムされているため、幻覚を起こす可能性が低くなります。
このプロセスは、微調整よりもはるかにコスト効率が高く、簡単です。これは、トレーニングと実行のコストが安くなっている AI モデルのコモディティ化を考慮すると特に当てはまります。使用事例が医薬品研究であろうと、カスタマー サービス チャットボットであろうと、AI イノベーションの波が大きくなるにつれて、選択肢の範囲が広がっています。ChatGPT のような派手なモデルの上にすべてを接続しようとする代わりに、よりシンプルな使用事例には低ビット モデルを選択できます。
LLM が API を使用して現在のデータを取得すると、より正確な応答が得られる可能性がありますが、データが安全でプライベートであることが保証されるわけではありません。たとえば、Microsoft Copilot は、従業員に公開されているすべての Microsoft 365 データにアクセスできます。従業員が Copilot を使用して新しい独自のコードを生成すると、問題はさらに複雑になります。
LLM にデータが送られたり、LLM を通過したりする際に、データを保護するための安全策を構築する必要があります。たとえば、LLM が SQL クエリを利用する場合、組織はモデルの応答を自動的にインターセプトする必要があります。これにより、SQL クエリを実行するのは LLM ではなく組織であることが保証されます。LLM は、データベースを参照できるクエリを作成することしかできません。
ユーザーに代わってクエリを実行する組織の仲介者を挿入することで、LLM が組織のデータでトレーニングされることも、サードパーティのデータベースにデータが漏洩することもないことが保証されます。
また、データ自体にプライバシーと許可を追加して、すべてのデータを保護する必要があります。各ユーザーがデータを誰と共有するか、どのような状況で、どのくらいの期間共有するかを制御できれば、HIPAA などの最も厳格なコンプライアンスも可能になります。
データベース内の各データを暗号で署名して封印すると、ユーザーはデータを信頼して検証できます。データが LLM に到達すると、アクセス制御メカニズムと暗号検証が装備されます。そのような可能性から保護されたデータから LLM が漏洩したりトレーニングしたりすることはできません。
イノベーターたちは、データ中心の AI の 3 つのレイヤーの研究と構築に忙しく取り組んでいます。先ほど説明したレイヤーは、データ配信と呼ばれています。これは、LLM がデータベース クエリを取得して応答を拡張するのを支援することを含み、一般に検索拡張生成 (RAG) として知られています。RAG は現在行われており、来年には一般的になるでしょう。
より実験的な段階にあるのが、データ中心のデータ管理です。これは、フライト、ホテル、旅行のアクティビティの予約など、複数のステップを必要とする作業を実行するために、複数の LLM を連携させるにはどうすればよいかという疑問に答えます。各 AI モデルは単一のタスクに焦点を絞ってうまく機能しますが、多面的なワークフローを実現するには、モデルをリンクして相互に通信する必要があります。Microsoft AutoGen は、開発者がそのようなワークフローを構築できるようにするために最近登場したプラットフォームの一例です。
さらに、新しいデータを取得する必要なく AI がインテリジェントになり、既存のデータセットを調べて独自の考え、洞察、予測を提供する能力も進歩しています。
こうした AI の進化はすべて、LLM が使用するデータを人間が保護し、管理できることを要求します。そうしないと、データ漏洩や幻覚が蔓延したままとなり、特に企業では AI モデルの潜在能力が制限されます。モデルをモデル中心の枠から解き放ち、より広範囲にわたる管理対象データへと移行する時が来ています。
Forbes Technology Council は、世界クラスの CIO、CTO、テクノロジー エグゼクティブ向けの招待制コミュニティです。私は参加資格がありますか?

元記事: https://www.forbes.com/sites/forbestechcouncil/2024/04/29/how-data-centric-ai-can-solve-enterprise-mistrust/