AIプラットフォームでは機微なデータを扱うこともあるため、使いやすさとセキュリティのバランスは重要です。DataRobotではマネージドサービス(いわゆる「クラウド版」)とセルフマネージド型(いわゆる「オンプレミス版」)に加え、近年では専有環境のマネージドサービスであるシングルテナント版も提供しており、セキュリティ要件に応じて選ぶことができます。
[参考] DataRobot AI Platform のデプロイインフラストラクチャ

セルフマネージド型(「オンプレミス版」)をお使いで、なかなかバージョンアップの時間が取れない！という場合、二世代前のバージョン8(あるいはそれ以前)を使っているユーザーの方もいらっしゃるのではないでしょうか。

このブログではそうしたユーザーの方向けに最新世代のDataRobotをご紹介します。

「自分が使っているDataRobotのバージョンがわからない」という方は、ログイン画面などで確認することができます：

なおマネージドサービス(「クラウド版」)にはこうしたバージョン番号はなく、ほぼ毎週アップデートされています。

DataRobot AI Platform バージョン9、そして10へ

DataRobotバージョン9は2023年3月にリリースされました。AutoMLの「ツール」から、組織のAIニーズをトータルで支える「プラットフォーム」へと進化すべく、機能の大幅な拡充に加え製品アーキテクチャも大きく進化しました。バージョン10は2024年4月にリリースされ、生成AI関連開発機能のほか、それを支えるGPU対応、エコシステム連携の深化など、最新の変化を取り入れています。

[参考] バージョン10.0.xリリースノート

DataRobotの生成AIと予測AI

DataRobotは2012年の創業以来、機械学習の自動化を通じた予測型AIの開発、運用プラットフォームのリーダーであり続けていますが、近年では生成AIを利用したモデルの開発・運用機能も統合し、単一プラットフォームで生成AIと予測AIの両方に対応することができるようになっています。

[参考] RAG(Retrieval-Augumented Generation)構築と応用|生成AI×DataRobot活用術

コーディングベースの開発と運用

DataRobotは従来から、マウス操作だけで数多くの予測モデルを自動開発できる使いやすいGUIを提供してきました。しかしDataRobotの操作自体やDataRobot以外のエコシステムとの連携をAPIを使ってもっと自動化したい、といったニーズも高まっていました。そこでDataRobotにはノートブック機能が追加され、コーディングを通じた自動化ニーズにも対応できるプラットフォームとなっています。またDataRobot外でコーディングベースで開発されたモデル(カスタムモデル)の運用管理にも対応しています。

[参考] DataRobot Notebooks, デプロイ用のカスタムモデルの準備

新世代のUI

このように「生成AIと予測AI」、「GUI操作とコーディング」といった新たなAI開発・運用ニーズに対応するため、UIも一新されました。

これまでのUIは個人作業、1つのデータ、1つのプロジェクト(予測AI)を中心に設計されたものでしたが、新世代のUI「NextGen」では、チーム作業を通じたより大規模な開発、複数のデータやモデリング設定を使った試行錯誤の一元管理、生成AI開発と予測AI開発の統合、GUI開発とコーディングの統合、などを実現しています。

[参考] NextGenエクスペリエンス

モデルガバナンス

DataRobotはモデルの開発プラットフォームであるだけでなく、モデル運用プラットフォームでもあります。デプロイ、モニタリング、チャレンジャーモデルの分析、再トレーニングとモデル置換、といったライフサイクル管理のほか、DataRobot以外で開発したカスタムモデルの運用や、外部予測環境にホストされているモデルのリモート監視にも対応しています。カスタムモデルの開発自体はDataRobotのノートブック機能でも可能です。加えて生成AIの文脈では、ガードモデルを簡単に利用できるようにするなど、モデルガバナンスに力を入れています。

エコシステムインテグレーション

学習・予測データはどこに保存されていますか？SnowflakeやDatabricks、あるいはAWS、Azure、GCPなどのデータウェアハウスやデータレイクをご活用でしょうか？また、AWSやAzure、GCPにモデルをデプロイしていますか？DataRobotはこうしたデータやAIに関するクラウドのプレイヤーとの連携を深めており、データ準備やモデルデプロイ、運用などをシームレスに行えるようになっています。

(例：Snowflake連携の概要)

新しい利用形態 – 専有型のマネージドサービス

冒頭にも述べた通り、DataRobotはマネージドサービス(「クラウド」)とセルフマネージド型(「オンプレミス」)の両方を提供しており、今この記事をお読みの方はセキュリティ上の理由から自社の専用ネットワークにインストールできるセルフマネージド型をお使いなのではないでしょうか。

しかしセキュリティを確保したいからといって、必ずしもすべて自社で管理したいとは限りません。運用管理にはコストと時間がかかり、バージョンアップを通じて新機能を利用可能になるサイクルもどうしても遅くなりがちです。

DataRobotでは新しい利用形態として「DataRobotシングルテナント」という専有型のマネージドサービスを展開しています。お客様はプライベートなネットワークに自社専用のDataRobot環境を持つというセキュリティ上の特徴を維持しつつ、マネージドサービスによりインフラの運用管理から完全に解放されることができ、新機能もタイムリーに利用することができるようになります。

DataRobotシングルテナントの詳細については当社または各代理店様までお問い合わせください。

新アーキテクチャ – 進化し続けるAIワークロードをコスト効率よく実行

自社固有のDataRobot構成が必要、といった場合は引き続きDataRobotのセルフマネージド型を使い自社管理で運用することができます。この時やはり気になるのは運用に伴うコストでしょう。

AIは一般に計算量の大きいワークロードであるため、AI製品の進化にともないコンピュートリソースの使用量は増していきます。これは、従量課金が一般的であるクラウドサービス(AWS、Azure、GCPなど)でワークロードを実行する際には特に気をつけるべき点です。

DataRobotは2012年の創業時点でコンテナを利用したマイクロサービスアークテクチャを採用した先進的なプラットフォームでしたが、進化し続けるAIワークロードを支える上で限界を迎えていました。コンテナの動的配置にまでは対応しておらず、また使いたい機能を支えるための最大限のコンピュートリソースを起動し続けておく必要があったのです。コスト削減のために、特定の機能の使用をあきらめて構成を意図的に小さくしているケースもありました。

バージョン8.xまでのアーキテクチャーの主な課題

そこでDataRobotはバージョン9からアーキテクチャを変更し、 Kubernetesアプリケーション化されました。Kubernetesはコンテナの自動オーケストレーションのフレームワークです。これによりすべてのコンテナをどのサーバーにでも動的配置できるようになってコスト効率が上がり、さらにオートスケール機能を活用してワークロードに応じたスケールアップ、スケールダウンを自動化できるようになりました。「AI機能を使わなくてもコンピュートにコストがかかる」アーキテクチャから「AI機能を使ったぶんのみコンピュートリソースを使う」アーキテクチャになったのです。

Kubernetesアプリケーション化によるリソース自動制御

新アーキテクチャによるコスト最適化により、新たに利用が可能になったり、利用しやすくなった機能をいくつかご紹介します。

GPU利用の拡大

機械学習モデルにおけるディープラーニングアルゴリズムの活用のほか、生成AIの文脈ではGPUの利用がますます欠かせないものとなっています。DataRobotではGPUを利用して生成AI関連機能を加速しているほか、NVIDIA社との協業によりLLMのローカルホスティング、ガードレールモデルの利用など、生成AIを企業で本格的に利用するための能力を拡大しています(参考：DataRobot Spring ‘24 Launch Event)。DataRobotの新アーキテクチャは、プレミアムなハードウェアであるGPUをコスト効率よく利用することを可能にしています。

カスタムモデルの運用管理

DataRobotでは、カスタムPython環境で開発したモデルや他社製品で開発したモデルをデプロイし運用管理することも可能です。これにより開発環境に関わらずモデル運用の統合的なビューを持つことができます。これはインフラ観点ではモデルごとにランタイム環境とそれを動かすコンピュートリソースを用意することを意味します。

カスタムアプリケーション(ノーコード、ローコード)

DataRobotでは生成AIや予測AIを利用したアプリケーションを実行することもでき、GUI操作だけで利用可能なノーコードアプリや、Streamlitなどのローコードフレームワークを使ってモデルを利用するインターフェースをユーザーに提供できます。このような機能にも一時的なコンピュートリソースが必要であり、新世代のDataRobotではこうしたAI用アプリケーションを簡単にかつコスト効率よく提供することができます。

DataRobot Notebooks

ノートブック機能は、そのインスタンスごとに一時的なコンピュートリソースを必要とします。こうした機能は、動的なリソース割り当てができるインフラなしには極めてコストが高いものになります。バージョン9以降のアーキテクチャでは、DataRobot内でノートブック/コーディングのニーズにも応えつつ、そのリソース使用を最適化することができます。

学習に利用可能なデータサイズ

モデルの学習に大きなデータを使おうとするほど、それに対応したメモリを確保するためより大きなコンピュートインスタンスが必要になります。バージョン8までのアーキテクチャでもモデル作成用のコンテナ、ノードはオートスケールの構成が可能でしたが、それを選択しない場合は小さいインスタンスを選択してコスト削減するかわりに利用可能なデータサイズを制限(5GBなど)するケースがありました。

バージョン9以降ではこうしたことを検討する必要はなく、各DataRobot環境で利用可能な最大サイズを利用することができるようになります。

おわりに：DataRobot AI Platformとそれを支えるアーキテクチャ

DataRobotは「AutoMLツール」から「AIプラットフォーム」へと進化しました。つまり、生成AIと予測AI、GUI操作とコーディング、モデル開発とモデル運用、など組織のAIニーズをトータルで提供する共通基盤となっています。モデル開発をカスタムPythonコードや他社のMLツールで行っていたとしても、DataRobotはそれらと連携し、モデル運用などその先のニーズを幅広くカバーしていきます。

そして、そのようなプラットフォーム機能を実際にコスト効率よく実現するためのアーキテクチャを導入し、継続的に革新しています。これからの発展にもどうぞご注目ください。

5/15(水) 15:00〜開催！【オンプレミス版ご利用の方必見】DataRobot 最新バージョンで実現する生成AIほか最新機能とそれを支える新たなアーキテクチャ

本ウェビナーではDataRobotセルフマネージド版(“オンプレミス版”)をご利用中のユーザー様、運用管理している管理者様向けに、DataRobot最新バージョンのv9、そして発表されたばかりのv10のハイライトをご紹介するとともに、GPUなどを含む多様なAIニーズをコスト効率よく実行できる新たなアーキテクチャや、新しい利用形態である専有型のマネージドサービスなどを解説します。

参考

バージョン10.0.xリリースノート

RAG(Retrieval-Augumented Generation)構築と応用|生成AI×DataRobot活用術

DataRobot Notebooks

デプロイ用のカスタムモデルの準備

NextGenエクスペリエンス

DataRobot Spring ‘24 Launch Event

投稿 DataRobot 最新バージョンで実現する生成AIほか最新機能とそれを支える新たなアーキテクチャ は DataRobot に最初に表示されました。

取締役会を満足させ、ビジネス競争に勝ち残るためには、いち早く生成AIから価値を創出しなければなりません。しかし、新たなソリューションやエコシステムが市場に登場し、混迷を深めている現状を把握する必要もあります。

また、新しい生成AIのプロジェクト、ユースケース、組織全体の熱狂的なユーザーをこなさなければなりません。そして、データセキュリティも忘れてはいけません。あなたの素晴らしいリーダーシップを、ビジネスにとって有用なはずのAIが、良くない方向に働いてしまったという教訓にはしたくありません。

そして、生成AIのROIを証明するよう求められており、まるでモグラたたきをしているような気分になっているとしたら、それはあなただけが感じていることではありません。

Deloitteによると、AIのビジネス価値を証明することは、AIリーダーにとって最も重要な課題です。世界中の企業が、試作から本番への移行に苦戦しています。ここではその方法と注意すべき点について説明します。

生成AIからビジネス価値を実現するための６つの障害（および解決策）

第１の障害：ベンダーロックイン

生成AIは驚くほど速く進化しています。LLM、ベクトルデータベース、埋め込みモデルなど、新しいイノベーションが毎日生み出されています。そのため、現時点で特定のベンダーにロックインされることは、1年後のAI活用におけるROIを危険にさらすだけでなく、文字通り来週のあなたにとって足枷となりうる可能性があります。 例えば、現在LLMの特定プロバイダーに完全に依存しているとしましょう。もし、コストが上昇したため、新しいプロバイダーに切り替えたり、特定のユースケースに応じて異なるLLMを使用したい場合はどうなるでしょうか。 ロックインされている場合、そのベンダーから離脱することがコスト削減の利益を失くし、それ以上の損失を被る可能性があります。

解決策：柔軟性と多機能性を持つプラットフォームを選択する

予防は最良の治療法です。自由度と適応性を最大限に活用するためには、AIライフサイクル全体、パイプライン、データ、ベクトルデータベース、埋め込みモデルなどを、簡単に他のプロバイダーに移行できるソリューションを選択してください。例えば、DataRobotは今後も将来も、AI戦略をコントロールすることができます。

当社のオープンなAIプラットフォームは、完全な柔軟性を維持できるため、どのようなLLM、ベクトルデータベース、エンベディングモデルでも使用することができ、ニーズの変化や市場の進化に応じて、運用を中断することなく、基盤となるコンポーネントを交換することができます。さらに、一般的なLLMの構築も可能です。

第２の障害：オフ・ザ・グリッドの生成 AI が混乱を生み出す

予測AIはコントロールが難しいと考えているなら、生成AIを試してみてください。あなたの組織のデータサイエンスチームは予測AIのゲートキーパーの役割を担っていると思われますが、生成AIには誰でも手を出すことができます。あなたの会社には、15から50の予測モデルがあるかもしれませんが、規模が大きくなれば、いつでも200以上の生成AIモデルが組織内に存在する可能性があります。

さらに悪いことに、あなたはそのうちのいくつかを知らないかもしれない。「オフ・ザ・グリッド」の生成AIプロジェクトは、リーダーシップの権限から逃れがちで、組織を重大なリスクにさらすことになります。

このような熱心なAIの利用は、より大きなビジネス価値のレシピとなり得ますが、実際には逆のことが多いです。統一された戦略がなければ、生成AIは意味のある結果をもたらすことなく、高騰するコストを生み出す可能性があるのです。

解決策：すべてのAI資産を統一されたプラットフォームで管理する

AIの乱立を防止するためには、誰が作ったか、どこで作られたかにかかわらず、すべてのAI資産を単一の管理しやすいプラットフォーム上に統合するべきです。例えば、顧客データと同じように、AI 資産に関する単一の信頼できる情報源と記録システムを作成します。

AI資産を同じ場所に配置したら、以下にようにLLMOpsの考え方を適用する必要があります。

• すべての生成AIモデルに適用される標準化されたガバナンスとセキュリティポリシーを作成する。
• モデルに関する主要なメトリクスをモニタリングし、必要な場合に介入するプロセスを確立する。
• フィードバックループを構築して、ユーザーからのフィードバックを活用し、生成AIアプリケーションを継続的に改善する。

DataRobotであれば、これらすべてを実現できます。私たちのAIレジストリを使用すると、すべてのAI資産を同じ場所で整理、展開、管理することができます。これは、Salesforceが顧客とのコミュニケーションのために行っていたことを、AI向けに行ったものです。

第３の障害：生成AIと予測AIの取り組みが同じ傘の下にない

生成AIと予測AIモデルを統合していない場合、重要なチャンスを逃しています。これら2つのテクノロジーを組み合わせたパワーは膨大な価値を生み出し、これらを成功裏に統合したビジネスは、ROIを効率的に実現し証明することができるでしょう。

ここでは、AIの成果物を単一の統合システムに配置した場合の例をいくつかご紹介します。

• 組織内の誰もが自然な言語で予測分析モデルをクエリできるように、SlackでGenAIベースのチャットボットを作成します（例：「この顧客が離反する可能性はどのくらいですか？」）。このように、2種類のAI技術を組み合わせることで、予測分析を引き出し、日常の業務フローに組み込み、ビジネスにとってはるかに価値が高く、アクセスしやすくなります。

• 予測モデルを使用して、ユーザーが生成AIアプリケーションとやり取りする方法を制御し、リスクを軽減します。たとえば、予測モデルを使用すると、ユーザーが高い確率でエラーを返すプロンプトを生成AIツールに送信した場合に応答を停止させたり、アプリケーションを意図しない方法で使用しているかどうかを検知したりすることができます。

• 予測AIモデルをセットアップして生成AIの対応に情報を提供し、誰でも使える強力な予測アプリを作成しましょう。例えば、技術者でない従業員が、来年の住宅価格の販売予測について自然言語で問い合わせをし、予測分析モデルが正確なデータを入力することができます。

• 予測モデルの結果から生成AIのアクションをトリガーします。たとえば、予測モデルが顧客の離脱の可能性が高いと予測した場合、その顧客に送信されるメールのドラフトを生成AIツールにトリガーしたり、セールス担当者が次回のアウトリーチ時にアカウントを救済するためにフォローする通話スクリプトを設定することができます。

しかし、多くの企業では、予測AIモデルと生成AIモデルが異なるプラットフォームにサイロ化されているため、AIからこのレベルのビジネス価値を得ることは困難になっています。

解決策： 生成AIと予測モデルを組み合わせる

DataRobotのようなソリューションを活用すれば、生成AIと予測AIのすべてのモデルを一元管理することができ、両方のテクノロジーを組み合わせた独自のAIアプリケーションを作成することができます。

それだけでなく、プラットフォームの内部から、ビジネスクリティカルなメトリクスを設定して追跡し、DataRobot AI Platformの外部で実行されているモデルであっても、その価値を保証するために各デプロイのROIを監視することができます。

第４の障害：知らず知らずのうちにガバナンスを妥協してしまう

多くの企業にとって、生成AIの主な目的は時間を節約することにあります。チャットボットで顧客からの問い合わせに費やす時間を短縮したり、チームミーティングの自動要約を作成したりすることもそうです。

しかし、スピードを重視するあまり、ガバナンスやモニタリングが手抜きになることも多くなっています。それは、風評リスクや将来的なコスト（例えば、データ漏えいの結果、ブランドが大きな打撃を受けた場合など）につながることになりかねません。また、AIモデルから今得ている価値のコストを測定したり、最適化したりすることができないということでもあります。

解決策：データを保護し、強固なガバナンス・フレームワークを維持するソリューションの導入

この問題を解決するためには、早急に確立されたAIガバナンスツールを導入して、生成AIと予測AIの資産を監視および制御する必要があります。

堅実なAIガバナンスソリューションとフレームワークには、以下が含まれる必要があります。

• 明確な役割分担：AI構築に関与するすべてのチームメンバーが、誰が何に責任を持つかを把握します。
• アクセス制御：個人または役割レベルでのデータアクセスとモデルの変更権限を制限し、企業データを保護します。
• 変更および監査ログ：法的および規制の遵守を確保し、リスクを回避します。
• モデルの文書化：モデルが機能し、目的に適していることを示すための文書を作成します。
• モデルインベントリ：展開または起源に関係なく、AI資産を管理し、監視するためのインベントリを作成します。

現在のベストプラクティス： LLMを企業データで拡張することで、データや情報の漏えいを防ぐことができるAIガバナンスソリューションを見つけましょう。

DataRobotのAI プラットフォームには、このようなセーフガードが組み込まれており、ベクトルデータベースビルダーを使用すると、従業員のアクセスをより適切に制御し、機密情報を漏らすことなく、各ユースケースに関連性の高い回答を行うために、ユースケースごとに特定のベクトルデータベースを作成することができます。

第５の障害：AIモデルを長期間維持するのは難しい

前述のDelloiteのレポートによると、メンテナンスの欠如は、生成AIからビジネス成果を得るための最大の阻害要因の一つです。優れた保守がなければ、モデルが意図した通りに機能しているかどうか、またユーザーが正確な応答を得て、データに基づいたビジネス上の適切な意思決定を行うのに役立つかどうかを確信する方法はありません。

要するに、素晴らしい生成アプリケーションを構築することは素晴らしいスタート地点ですが、メトリクスを追跡したり、使用データやベクトルデータベースの品質に基づいて継続的に改善するための中央集権的なワークフローがない場合、次のいずれかを行います。

1. インフラ管理に膨大な時間を費やす。
2. 時間の経過とともに生成AIモデルを劣化させる。

どちらも長期的に持続可能な（あるいは安全な）選択肢ではありません。悪意ある行動や生成AIソリューションの誤用に対する防御を怠ることは、ほぼ即座にAIへの投資の将来の価値を制限します。

解決策： AIモデルの監視を容易にする

生成AIの価値を高めるには、ガードレールと安定したモニタリングが必要です。AIツールを活用して、以下を追跡することが必要です。

• 従業員や顧客が生成したプロンプトやクエリを時間の経過とともに追跡し、ベクトルデータベースが完全かつ最新であることを確認します。
• 現在のLLMが（まだ）AIアプリケーションにとって最適なソリューションであるかどうかを確認します。
• GenAIのコストを追跡し、依然としてプラスのROIが得られているかどうかを確認します。
• モデルを再トレーニングする必要があるかどうかを把握します。

DataRobotはそのような制御レベルを提供します。すべての生成AIおよび予測AIアプリケーションやモデルを同じ安全なレジストリに統合し、次のことができます。

• 特定のユースケースに関連するカスタムパフォーマンスメトリクスを設定する
• サービスの健全性、データドリフト、および精度統計などの標準メトリクスを理解する監視ジョブをスケジュールする
• カスタムルール、通知、および再トレーニング設定を設定する。チームがAIのメンテナンスを容易に行えるようにすると、経時的にメンテナンスを怠ることはありません。

第６の障害：コストが高すぎる – あるいは追跡が難しい

生成AIには、深刻なコスト・ショックが伴うことがある。当然ながら、ビジネスリーダーは、意味のある結果を見るのに十分な規模でそれを展開したり、ビジネス価値という点であまり回収できないまま多額の費用をかけたりすることに抵抗を感じます。

特に、誰がAIアプリケーションを使用しているのか、なぜ使用しているのかを実際に監視していない場合、生成AIのコストをコントロールし続けることは大きな課題となります。

解決策： 生成AIのコストを追跡し、ROIを最適化する

各AI導入のコストと使用状況を監視できるテクノロジーが必要です。DataRobotを使用すれば、エラーのコストからLLMの有害度スコア、全体的なLLMのコストまで、すべてを追跡できます。アプリケーションに応じてLLMを選択し、コスト効率を最適化できます。

そのようにすることで、生成AIでお金を無駄にしていないか心配する必要がありません。AIをどのように使用しているかと、各アプリケーションから得られるビジネス価値を正確に証明できます。

DataRobotで測定可能なAI価値を提供する

適切なテクノロジーがあれば、生成AIからのビジネス価値を証明することは不可能ではありません。エンタープライズ・ストラテジー・グループによる最近の経済分析によると、DataRobotを使用することで、既存のリソースを使用する場合に比べて75％から80％のコスト削減が可能であり、投資対効果は3.5倍から4.6倍になり、AIによる初期価値の実現までの時間を最大で83％短縮することができます。

• DataRobotは、生成AI資産からのROIを最大化するお手伝いをします。
• GenAIのデータ漏洩やセキュリティ侵害のリスクを軽減する 
• コストの抑制
• 組織全体のAIプロジェクトを同じ場所に集める
• 柔軟性を維持し、ベンダーの囲い込みを回避します。
• オリジンやデプロイメントに関係なく、AIモデルの管理とメンテナンスを容易にする 

投稿 生成AIの取り組みが失敗する6つの理由とその解決策 は DataRobot に最初に表示されました。

今回は数ある機械学習のモデル精度の評価指標の中でも私のお気に入りであるにも関わらず前回の最適化指標ブログでは取り扱うことができなかったFVE  Binominalについて紹介したいと思います。分類モデルの精度を単一の指標で測る上ではトータルバランスで現時点最強の評価指標だと考えています。これまで分類問題ではとりあえずAUCを使っていた人もこのブログをきっかけにFVE  Binominalを利用いただければ幸いです。

機械学習モデル評価指標の重要性

機械学習モデルを構築する際にはモデルをどのようにフィッティングさせるかを基準に最適化指標および損失関数を決めていきます。多くの場合、その最適化指標を最も小さくしたモデルを選択することによって一番精度の良いモデルを選ぶというアプローチを行います。ただ、コンペティションのように争う指標が決まっているのであれば、その指標を基に判断するだけですが（実際には共通の目的で争うため、コンペは全く違う血肉を争う戦いがあります）、実務で機械学習を行う場合にはどの評価軸でモデルを比較するかの決定を下すことも重要となります。

評価軸が決まった後には、精度が最終的に合格かを判定する上では、きちんとした検証基準を置く必要があります。ただし、厳密な検証は手間もかかるので、実務者はとりあえず作成したモデルが「大体どれくらい精度がいいものか」知りたいということは多々あります。二値分類問題においては、多くの方がAUCをこの用途で利用しているかと思います。「AUCが0.5であれば完全にランダムなモデルと変わらない。AUCが0.8を超えていたら相当いいモデルとなっている。0.9を超えると精度が良すぎるのでリーケージを疑いたい」こういった話を聞いてモデルの評価基準にしている方は少なくありません。ただAUCには向いていないケースもあり、その評価指標の本質を理解していないとよもやの事故に遭う可能性もあります。

機械学習モデル評価指標「AUC(Area Under the Curve)」とは

AUCはArea Under the Curveを略したもので、一般的にはROC（Receiver  Operating Characteristic）曲線の下の面積（別のパターンとしてPR曲線の下の面積をとったものも存在しますが、本ブログではROC-AUCを以降AUCとして表記します）を表したものとなっています。

AUC(Area Under the Curve)の性質

ROC曲線はy軸をリコール、x軸を偽陽性率（フォールアウト）としたときに、モデルが取れる組み合わせをプロットしたときに描かれる曲線となっています。AUCの定義から完璧なモデルの場合にはリコールが1で偽陽性率が0となり、面積は1×1=1となります。逆にランダムなモデルを作るとROC曲線はリコール、偽陽性率（0,0）とリコール、偽陽性率（1,1）を結ぶ直線となり、AUCは三角形の面積の通り、1x1x0.5=0.5となります。この性質からAUCはプロジェクトが違ってもモデル精度をざっくりと比較でき、多くのプロジェクトにおいてモデルの精度を簡易的に測る上で頻繁に利用される指標となっています。ちなみに金融業界の与信モデルの評価指標としてよく使用されるAR値は2AUC-1と同義のため、AR値もAUCと同じ性質を持っています。

機械学習モデル評価指標「AUC(Area Under the Curve)」の欠点

では、機械学習モデル評価指標であるAUCの欠点について解説します。

AUCはリコールと偽陽性率（１）のみを見ていることから、結果として予測値順に並べた時の精度だけを見ていることになり、予測値と実測値の乖離をみていません。そしてターゲット比率が0.1%を切るようなプロジェクトにおいては、AUCが簡単に0.8を超えるなど高くなる傾向があります。AUCが高いのに実際に運用すると、思った以上にパフォーマンスが出ない（ビジネス指標における効果が出ない）ということがあります。

AUC(Area Under the Curve)活用時の失敗事例 

AUCが予測の順位しか見ないという特性を知らずに使用すると、思わぬ事故に遭遇する可能性があります。例えば、「正例が少ないためダウンサンプリングしたデータセットでモデリングを行い、高いAUCが得られた。しかし、本番での運用では予測値と実際の値に大きな乖離が生じた。予測の乖離があるにもかかわらず、AUCは悪化していなかったため、問題に気付くのに時間がかかった」という事例が挙げられます。

AUC(Area Under the Curve)失敗事例の検証

このような現象は簡単に試せるため、元のデータにダウンサンプリングを施し、AUCスコアの変化を観察してみましょう。

AUCがホールドアウトでも変化しないのがわかるかと思います。 ここで予測値と実測値の乖離も見れるリフトチャートを同じモデルで見て行きましょう。

学習データ（交差検定）では予測の青のラインと実測のオレンジのラインがうまくフィットしているのが分かります。ただ、ホールドアウトでは、予測の青のラインは正しく右肩上がりになっていることから傾向は捉えているように見えますが、予測値が大きく乖離しています。AUCはホールドアウトでも下がっていませんでしたが、これはAUCが順列を見ているという性質から説明でき、実はリフトチャートでも右肩上がりになっていたことからこのモデルは順列としては正しいものでした。

予測値は大幅に乖離しても順列だけはあっていれば問題ないAUCは、マーケティングのターゲティング分析のように上位1万件にDMを送付するという予測値そのものに注目しない分析では問題ありません。ただ、一件当たりのDMのコストを考えて予測CV率がx以上に送りたいなどを考えている、予測値に対して金利を設定するなどの場合には、全く役に立たないモデルになっているリスクを内包しています。

※ちなみにDataRobot内で実施するスマートダウンサンプリングは名前にスマートがついているように、ダウンサンプリングした比率のウェイトを入れることによって、上記の事象が発生するのを防ぐ仕組みが実装されております。

機械学習モデル評価指標「FVE (Fraction of variance) Binominal」とは

AUCの欠点についてここまで記載していきましたが、ここからはFVE  Binominalについて紹介していきます。

「FVE (Fraction of variance) Binominal」の特徴

以前のブログでも二値分類においては最適化指標はLoglossが最強と書かせていただきましたが、評価指標で使う上ではターゲットの比率によって値が変わることからモデルのざっくりとした当てはまりの良さを考える上では不向きでした。Loglossが1を下回っているから必ずしも当てはまりの良いモデルができたとは限りません。このLoglossの評価関数としての欠点を解消したのがFVE  Binominalとなります。

「FVE (Fraction of variance) Binominal」考え方と機械学習モデル指標として優れている点

FVE Binominalは以下の式で表現することができます。

FVE Binominal = 1 – Logloss(Model X)/Logloss(Majority Class Classifier)

考え方はシンプルで、ひたすらターゲットのクラス比率に合わせて予測値を出すモデル(Majority Class Classifier)と比較してどれだけそのモデルが改善できているかを表現しています。FVEは説明されたdeviance（尤離度）の割合と考えることができます。

仮に作成したモデルが単純にターゲット比率に合わせた予測値を出すだけのモデルと同様であれば、Logloss(Model X)/Logloss(Majority Class Classifier) = 1となり、FVE  Binominalは0となります。仮に完璧なモデルができた場合には、Loglossは0となるため、FVE  Binominalは1となります。よくAUCで完全ランダムなら0.5で完璧なモデルなら1という表現がありますが、FVE  Binominalでも同じようにランダムなら0で完璧なら1と考えることができます。また、Loglossをベースにすることによって、より予測値の期待値的にうまくいっているのかという部分にフォーカスした評価指標となっていますので、順列だけでなく予測値そのものにも注目するケース（貸し倒れ確率と合わせて金利テーブルを作成する場合など）ではとても有用な指標となります。

先ほどAUCではホールドアウトでも交差検定と比較してそこまで値の変化がしなかったものをFVE Binominalでみていくとホールドアウト部分がマイナス(-0.4361)になっているのが確認できます。ここから予測値と実測値がランダム以上に大きな乖離を持っていることがわかります。

機械学習モデル評価指標「FVE (Fraction of variance) Binominal」の精度

AUCだとみなさまの感覚として、0.75超えてきたならいいモデルで0.9超えたら怪しいという感覚（ここまでのブログからこの感覚が危険だということを理解した人も多いかと思いますが）を聞いたことがある人もいると思いますが、DataRobotのグローバルのデータサイエンティストの中で、FVE Binominalは以下のような基準で使われています。

———

プロジェクトが終了したら、最適なモデルをFVE Binomialで見てみましょう。

– FVE Binominal が0に近い＝機械学習には不向きなユースケース

– FVE Binominal > 0.25 = 良いユースケース

– FVE Binominal が1に近い = ターゲットリーケージを疑うべき状態

———

これは、DataRobotのグローバルで活躍するデータサイエンティストの経験則ですが、FVE Binominalが0.15など0から0.25の間の時はいくつかの解釈ができ、まだモデルの説明力をあげられる段階であり、チューニングやデータを追加すれば精度をあげられる可能性もありますし、ランダムよりは良いので、用途によっては問題ない精度ということもありえます。あくまでFVE Binominalもざっくりと当てはまり具合を見るものであって、犬と猫の分類のように簡単な問題であれば1に近づきますし、金融市場分析などで0.1を超えることも難しいということは覚えておいてください。

機械学習モデル評価指標「FVE (Fraction of variance) Binominal」の注意点

FVE Binominalの注意点をいくつかあげるとすると算出ロジックのベースがLoglossのため、Loglossと同じように誤ラベルの影響を大きく受けます。実際にはTrueのものがFalseとなっていた時にモデルが99%Trueと予測できていたにも関わらずデータ上はFalseのためLoglossが大きくなります。そのため、誤ラベルがある程度紛れてしまうような分析では、過小にモデルが評価される可能性があることには注意が必要です。またAUCでは順列を見ていて、FVE Binominalではスコアを見ているという性質からですが、仮にモデルの活用が予測値の上位x件を抽出した上でアクションを実行するという順列のみを見るケースではAUCを利用する場合もあります。FVE Binominalでは上位x件に含まれないデータに対するスコアのつき方も評価しているので、ビジネスアクションと関係ない部分が評価に含まれているためです。そして1番の欠点が知名度だと思います。このFVE Binominalは知名度がまだまだ低いため、初見の人には通じない可能性があります。ただAUC 0.8というのがデータサイエンティスト以外に正しく伝わるかというとそこに疑問は残りますので、みなさんがFVE Binominalの良さを広めて知名度拡充に努めていただけると助かります。

別のFVEシリーズ

今回、分類問題の鉄板損失関数Loglossを正規化したFVE Binominalを紹介させていただきましたが、連続値問題（回帰問題）においてはよいモデルを作るにはターゲット分布によって損失関数を選択する必要があります。そして損失関数でpoissonやganmaやtweedieを選んだ際にはLoglossと同じようにモデルの当てはまり具合がわからず、結局リフトチャートや残差チャートを見て視覚的に判断する必要があった経験をされた方も多いかと思います。実はFVEの考えは、poissonやganmaやtweedieにも応用でき、DataRobotではそれぞれFVE poisson、FVE ganma、FVE tweedieとして評価指標が用意されています。定義はいずれも、

1 – (error / baseline model error)となり、0だとベースラインモデルと同じで1だと完璧なモデルを意味します。0.25を超えれば良いモデルという感覚もそのまま利用できます。連続値問題ではR^2を利用する方が多いかと思いますが、FVEはR^2と非常に似た性質を持っています。ただ、logリンク関数を利用したモデル（DataRobotでは最適化指標にpoissonやganmaやtweedieが選択された際のモデル）にも対応できる点でも便利な評価指標となっています。

AUCより優れた機械学習モデル評価指標「FVE (Fraction of variance) Binominal」を有効活用するコツ

予測値へのアクションにおいて、予測確率が重要なウェイトを占めるテーマにおいては、ARスコアやAUCよりもはるかに有用なFVE Binominalをぜひ有効活用してみてください。

慣れてくるとFVE Binominalで大体の予測分布の形が想像できるようになり、AUCよりも鮮明にモデルの当てはまり度を単一の数字で想像できるようになります。またモデル運用において、AUCは変わってないが、FVE Binominalが悪化しているというケースに当たった際には、それぞれの性質を加味し、ターゲットの比率が変わっている可能性があるという部分に気づくきっかけにもなります。

出典

（１）The Relationship Between Precision-Recall and ROC Curves（Jesse Davis/Mark Goadrich）

投稿 分類プロジェクトの評価でAUCよりも便利なFVE Binominal｜DataRobot機械学習モデル評価指標解説 は DataRobot に最初に表示されました。

DataRobotで製造業/ヘルスケア業界のお客様を担当しているデータサイエンティストの長野です。技術的には生成AI領域を担当し、日本市場での生成AIプロダクトの導入と顧客支援を担当しています。

本記事では、生成AIの中でも特に注目を集めている技術領域の一つである「RAG（Retrieval-Augmented Generation）」に焦点を当てつつ、DataRobotで実現できる内容について解説させていただきます。

なお、本記事と関連するウェビナー「生成AI最前線：DataRobotを用いた実践RAG構築」では、実際のデモンストレーションを交えながらRAGに関して解説していますので、合わせてご確認いただければ幸いです。

LLMの活用パターンとRAG(Retrieval-Augumented Generation)の立ち位置

RAGについて踏み込む前に、ビジネスにおける大規模言語モデル（Large Language Model、以下LLM）の活用パターンを整理すると、大きく以下の3つに分けることができます。

活用パターン1. 事前学習済みLLM

このパターンでは、ChatGPTなどの既存の生成AIサービスやGPT3.5などのLLMをそのまま利用することを指します。導入コストが低いことがメリットとして挙げられます。執筆時点で多くの企業ではこのパターンでのLLM活用は進んでいると感じます。

活用パターン2. 検索拡張型LLM

検索拡張型LLMは、ユーザーからの入力に対して関連する情報を元に検索し、その結果をもとに回答を生成します。本記事の題材であるRAGがこのパターンに該当します。執筆時点でOpenAI社のgpt-4-turbo-previewは2023年12月、gpt-3.5 turboは2021年9月までの学習であり、最新の情報や社内文書も学習していません。そのため検索拡張型LLMが、社内文書や最新の情報を踏まえたLLMを構築する手法として注目を集めています。

活用パターン3. 追加学習/自作LLM

最後に、独自のニーズに合わせてLLMを追加学習させたり、オリジナルのLLMを開発するアプローチがあります。個々のユースケースに柔軟に対応させたLLMの開発ができる一方で、多くの企業にとってはまだまだ技術的ハードルの高い手段です。

この3パターンの中で、RAGが導入コストとユースケースとのマッチ度の観点で多くのユーザーが取り組まれている技術となります。

RAG(Retrieval-Augumented Generation)の課題

前章で解説したようにRAGの構築は比較的簡単に導入できる手法であると認識されていますが、弊社が実際にRAG開発に取り組まれている企業にヒアリングすると成果が出ていないケースも見受けられます。以下はその理由をまとめたものです。

課題1: テーマに対して技術的な課題を適切に捉えられていなかった

• 社内の文章を入れたら簡単にRAGが構築できると考え、あまり調査せずに中身がブラックボックスなツールを選定してしまう。
• Pythonライブラリを用いたRAG開発を試みるが、開発できるメンバーの不足や運用監視に苦労している。

課題2: RAGを構築できる人材が少なくスケールしない

• ユースケース毎に多くのRAGを開発する必要があるが、RAGの開発と運用監視の観点でプロジェクトが進んでいない。

課題3: 本番環境を想定した検証ができていなかった

• PoCを実施した結果、良さそうな結果は得られたが、本番導入を想定したハルシネーション対策や運用時の死活監視や精度監視までは確認できていない。

DataRobot生成AI機能を使うメリット

それでは、DataRobotの生成AI機能がこの問題に対してどのようにアプローチしているのかを以下の3つの視点からご紹介します。

DataRobot生成AI機能のメリット 1: RAGの開発

まず初めに、RAGが開発できないことには始まりません。DataRobotでは迅速なRAGの開発を実現できますが、この開発パートに関しては、後ほど詳しく解説します。

DataRobot生成AI機能のメリット2: API化/Webアプリ化

AIモデルを使って予測分析を行うユースケースでは予測結果のインサイトの取得も価値に繋がることが多く、実際に筆者が担当している製造業のお客様では要因分析のテーマでDataRobotをご活用されているケースも多くあります。要因分析のテーマでDataRobotをご活用されているお客様が非常に多くいます。一方で、生成AIのテーマでは、想定していた回答を返すだけではなく、実際にシステムへの組み込みやアプリケーションの開発まで求められるケースが非常に多いです。DataRobotではAPIによるシステム連携やStreamlitのDataRobotへのホスティング機能が充実しており、生成AI特有の課題に対しても十分にカバーできます。

DataRobot生成AI機能のメリット3: 運用監視とガードレール

予測AI/生成AIを問わず、あらゆるAIモデルはそのモデルを構築した時点から時間が経過すると精度パフォーマンスが劣化します。したがって、RAGを構築し生成AI機能を利用したアプリケーションを稼働させる際には、その精度パフォーマンスをはじめとする様々な品質指標を監視する仕組みも併せて稼働させることが必須です（予測AIモデルの運用を監視する仕組みはMLOpsと呼ばれていますが、生成AIシステムではLLMOpsと呼ばれています）。特に生成AIシステムでは、消費トークン数をトラッキングする、毒性のある単語/文章をガードレールにより弾くなど、様々な品質指標を設定してパフォーマンスを監視しながら、入力プロンプトの単位で適宜アクションをとる必要があります。DataRobotはこれらの要件に答えることができるAIライフサイクル・マネジメントプラットフォームです。

DataRobotを用いたRAG(Retrieval-Augumented Generation)構築

それでは、実際にDataRobotの画面を用いてRAGを構築してみます。NextGenインターフェイスでは予測AIと生成AIを同一のインターフェースから開発することができます。本ケースのようにRAGを構築する際は「データ」、「ベクターデータベース」、「プレイグラウンド」のタブを活用します。

データタブ：データの投入

RAGを構築する際に必要となるデータを投入します。2023年3月現在はtxtファイルとPDFファイルに対応しており、これらのファイルをZIPファイルにまとめて投入します。今回は、GPT3.5をそのまま使うと回答できないDataRobotの製品マニュアルをアップロードしてみました。

ベクターデータベースの構築

次にベクターデータベースを構築します。ベクターデータベースと聞くと構築が非常に困難に感じるかもしれませんが、DataRobotでは一つの画面上で簡単に設定することができます。主要なオプションを以下で解説します。

①埋め込みモデル

RAGに使用するデータを選択した後、「埋め込みモデル」タブをクリックし、今回使用する埋め込み（Embedding）モデルを選択します。Embeddingとは、後述するチャンクをベクトル情報に変換するモデルのことを指します。執筆時点では日本語も含む多言語対応モデルであるinfloat/multilingual-e5-baseなど、5種類のEmbeddingモデルから自由に選択することができます。埋め込み（Embedding）モデルの選択は回答の精度や出力のレスポンスに影響しますので、RAG開発フェーズで様々なモデルを試せることが重要です。infloat/multilingual-e5-baseのケースではチャンクを768次元のベクトル情報に展開します。これがベクターデータベースと呼ばれる理由です。

②チャンキング

チャンキングはテキストを分割する方法を指しており、一つ一つの固まりをチャンクと呼びます。一つ一つのチャンクをどのように分割するかによって同じデータでも得られる情報が変わります。極端な例ですが、文章を文単位の小さなチャンクに分割すると文脈の情報が欠落してしまいますし、反対に長文を一つのチャンクにすると本当に取得したい情報が得られないリスクがあります。チャンクを区切った際に、前後の文章も含める度合いをチャンクオーバーラップのパラメータで制御します。値を小さくしすぎると文脈が途切れてしまうリスクがありますが、大きくしすぎると、ベクターデータベースの容量が大きくなり、レスポンスタイムに影響します。

プレイグラウンドによる検証

ベクターデータベースの構築が完了したら、RAG構築の最後にプレイグラウンドを用いた実験を行います。プレイグラウンドは名前の通り、試行錯誤が非常にしやすい検証環境となっています。ここでは設定可能な主要パラメータについて解説します。

①LLM

LLMでは、DataRobotにプリセットされている多様なLLMの中から、自由に選択することができます。現在、選択肢としてGPT-3.5系、GPT-4系、AmazonTitan、Google Bisonの6種類が用意されています。さらに、皆様の会社で独自に契約されているLLMを、この選択肢に追加することも可能です（Bring-Your-Own LLM、以下BYOLLM）。

セキュリティポリシーの観点から、社内契約のLLMのみを使用可能な場合でも、BYOLLMのみをプレイグラウンド環境で利用する設定により、柔軟に対応することができます。これにより、各社のセキュリティ要件を満たしつつ、LLMの性能や特性を比較検討し、最適なモデルを選択することが可能になります。

②システムプロンプト

システムプロンプトは、通常のプロンプトとは異なる機能であり、RAGやLLMに対して、特定の役割や振る舞いを設定することができます。これにより、APIコストの最適化やエンドユーザーのニーズに合った回答の生成が可能になります。

ビジネスシーンにおいて、システムプロンプトを効果的に活用することで、例えば以下のようなメリットが期待できます。

トークン数の節約：「100文字以内で回答してください」といったプロンプトを設定することで、回答の文字数を制限し、トークン数を抑えることができます。

エンドユーザーのニーズに合った回答の提供：「箇条書きで答えてください」などのプロンプトを用いることで、情報を簡潔にまとめ、読みやすく構造化された回答を生成できます。

③ベクターデータベースを選択

こちらのタブを使用することで、RAGに用いるベクターデータベースを選択することができます。構築済みのベクターデータベースを選択することで、LLMに対して追加の文脈情報を提供し、より正確で関連性の高い回答を生成することが可能になります。もちろん、ベクターデータベースを選択しない場合は、素のLLMやシステムプロンプトのみを付与したLLMとして検証することも可能です。

RAGは一見すると複雑な技術に思えるかもしれませんが、DataRobotを使えば、実際の構築のプロセスは非常にシンプルになります。必要なデータを用意し、ボタンを数回クリックするだけで簡単にRAG用のベクターデータベースを作成することができますので、専門的な知識がなくても、誰でも手軽にRAGを活用することが可能となります。

RAGの設定が完了したので、実際の性能を確認してみましょう。画面の左側にはRAG（GPT3.5-Turbo + ベクターデータベース）の結果が、右側にはGPT-3.5 Turboのみの結果が表示されています。この比較機能を使うことで、データベースの有無による回答の違いを簡単に確認することができます。

DataRobotでは、最大3種類のブループリントを同時に比較することが可能です。これにより、異なるLLMやデータベースの組み合わせによる性能の違いを一目で把握することができます。

今回、「オートパイロットについて教えてください」というプロンプトを使って、素のGPT-3.5とRAGとの性能を比較してみました。その結果、両者の回答には明確な違いが見られました。

素のGPT-3.5では、ベクターデータベースを使用していないため、一般的な「オートパイロット」の概念について説明しています。つまり、自動運転技術や航空機の自動操縦システムなど、辞書的な定義に基づいた回答が生成されています。一方、RAGを構築したケースでは、DataRobotの文脈に基づいた回答が得られました(オートパイロットモードはDataRobotのモデリングモードの一つです)。

この比較結果から、RAGがタスクに関連する情報を適切に取り込み、文脈に沿った回答を生成できることが確認できました。データベースの選択と構築が適切に行われれば、RAGはビジネスにおける様々な場面で、より正確で有用な情報を提供できる可能性があります。

更に、RAGの場合は回答の生成に使った引用文を確認することができます。狙いたいドキュメントが正しく引用されているかなど、この画面を見ながらチェックします。

発展：RAG(Retrieval-Augumented Generation)のチューニングTips

最後に発展トピックスとしてRAGのチューニングのTipsについてご紹介します。RAGはデータの前処理やチャンキング戦略、プロンプトエンジニアリングと様々な改善ポイントがあるため、最初はどこから手をつけて良いのか分からないかもしれません。RAGは引用文を取得するまでの「検索パート」と引用文に含まれる情報から回答を生成する「生成パート」に分けることができます。大きな方針として、ドキュメントで狙いたい文章が引用文にない場合は、「生成パート」をいくら工夫しても精度を改善することは難しいので、まずは「検索パート」の工夫から考えてみるのが良いと思います。

「生成AI最前線：DataRobotを用いた実践RAG構築」Webinar無料視聴のご案内

本記事では、近年注目を集めているRetrieval-Augmented Generation（RAG）について、その基礎知識から実践的な活用方法までをDataRobotの生成AI機能にも触れながら包括的に解説いたしました。本記事が、RAGに関する理解を深め、皆様の生成AIプロジェクトの推進にお役立ていただければ幸いです。本記事と関連するウェビナー「生成AI最前線：DataRobotを用いた実践RAG構築」では、実際のデモンストレーションを交えながらRAGに関して解説しています。

投稿 RAG(Retrieval-Augumented Generation)構築と応用|生成AI×DataRobot活用術 は DataRobot に最初に表示されました。

ほとんどの企業は、最初に取り組むユースケースが予想以上に難しいことに気づきます。そして、疑問は山積みになっていきます。

ムーンショットプロジェクト（ハイリスク・ハイリターンのプロジェクト）を目指すべきか、それとも小さくとも着実に価値を創出できるように務めるべきか、あるいはその両方をミックスすべきか？どのように規模を拡大するのか？次に何をすべきなのか？悩みはつきないでしょう。

ChatGPTを筆頭とするGenerative modelsは、AIが活躍できるシチュエーションを完全に変え、組織にまったく新しい問いを投げかけました。予測AIから得られた価値を作るためのノウハウのうち、どのノウハウを生成AIに適用すればよいのでしょうか？

予測AIで価値を得るためにやるべきこと

予測AIから価値を生み出す企業は、最初のユースケースを積極的に提供する傾向があります。

彼らが実践している取り組むべきポイントは以下の通りです。 

・適切なプロジェクトを選択し、それらのプロジェクトを総合的に評価する

プロジェクトの技術的実現可能性に多くの時間を費やすという罠に陥りがちだが、成功しているチームは、組織の複数のレベルから適切なスポンサーシップと賛同を得ることも考えています。

・適切なステークホルダーをプロジェクトの早期から参加させる

最も成功しているチームは、結果に投資し、さらなるAIプロジェクトを依頼するビジネスユーザーを関係しています。

・成功の炎をあおる

プロジェクトの成功を祝い、鼓舞し、惰性を克服し、緊急性を生み出すことが大事です。ここでも、エグゼクティブ・スポンサーシップが大いに役立ちます。次なる野心的なプロジェクトの基盤を築くことに貢献します。

そして、私たちがお客様からよく言われる「やってはいけないこと」は以下の通りです。 

・最も困難で最も価値の高い問題から始めること

多くのリスクが生じるため、その問題から着手しないことをお勧めしています。

・データが完璧になるまでモデリングを延期すること

この考え方は、不必要に価値創出を先送りすることになりかねません。

・組織設計、オペレーティング・モデル、戦略を完璧にすることに集中すること

これによって、AIプロジェクトをスケールさせることが非常に困難になります。

生成AIの新たな技術的課題とは？

・計算要件の増加

生成AIのモデルを学習・実行するには、高性能の計算とハードウェアが必要になります。企業はこのハードウェアを所有するか、クラウドを利用する必要があります。

・モデルの評価

本来、生成AIモデルは新しいコンテンツを生み出します。予測モデルは、精度やAUCのような非常に明確な指標を使用します。生成AIでは、より主観的で複雑な評価指標が必要となり、実装が難しくなります。

人間が出力結果を評価するのではなく、体系的に評価することは、これらのモデルすべてに適用する公正な評価基準を決定することを意味しており、それは予測モデルを評価することに比べて難しい作業です。生成AIモデルを使い始めるのは簡単かもしれませんが、意味のある優れたモデルを生成させるのは難しいでしょう。

・倫理的なAI

企業は、生成AIのアウトプットが、成熟し、責任あるものであり、社会や組織にとって有害でないことを確認する必要があります。

生成AIの主な差別化要因と課題とは？

・正しい問題から始める

間違った問題を追及する組織は、価値を迅速に得ることに苦労します。例えば、費用対効果ではなく、生産性に焦点を当てる方が、はるかに成功しやすいと言えます。動きが遅すぎることも問題です。

・生成AIのユースケースのラストワンマイルは、予測的AIとは異なる

予測AIでは、ダッシュボードや利害関係者のフィードバックループといった消費メカニズムに多くの時間を費やします。生成AIのアウトプットは言語の形をとっているため、これらの価値提案に到達するのがより速くなります。人間の言語が持つ双方向性によって、より速く進むことが容易になるかもしれません。

・データは異なるものになるだろう

データに関連する課題の性質は異なるでしょう。生成AIモデルは、乱雑でマルチモーダルなデータを扱うのが得意なので、データの準備や変換に費やす時間が少し減るかもしれません。

生成AIでデータサイエンティスト（DS）は何が変わるのか？

・スキルセットの変化

生成的AIモデルがどのように機能するかを理解する必要があります。どのように出力を生成するのか？その欠点は何か？私たちが使う可能性のあるプロンプト戦略は何か？私たちデータサイエンティスト全員がもっと学ぶべき新しいパラダイムです。

・計算量の増加

これらのモデルを自分でホストしたい場合、より複雑なハードウェアを扱う必要があります。

・モデル出力の評価

さまざまな戦略を使ってさまざまなタイプのモデルを実験し、どの組み合わせが最も効果的かを学ばなければいけません。これは、異なるプロンプトやデータチャンキング戦略、モデルの埋め込みを試すことを意味します。異なる種類の実験を実行し、それらを効率的かつ体系的に評価したい。どの組み合わせが最良の結果をもたらすのか？

・モニタリング

このようなモデルは倫理的、法的な問題を引き起こす可能性があるため、より綿密なモニタリングが必要となる。より厳密に監視するシステムが必要である。

・新しいユーザー体験

人間をループに入れ、モデリングのワークフローにどのような新しいユーザー・エクスペリエンスを取り入れたいかを考える必要があるかもしれません。生成AIソリューションの構築に関わる主なペルソナは誰になるのか。予測AIとの対比について考える必要があります。

組織が直面する人材ニーズは、生成AIであっても変わらないでしょう。依然としてモデルのニュアンスを理解し、新しいテクノロジーを研究できる人材は必要です。機械学習エンジニア、データエンジニア、ドメインの専門家、AI倫理の専門家など、すべてが生成AIを成功させるために必要であることに変わりはないのです。

生成AIに期待できること、どのユースケースから始めるべきかについて興味のある方はwebinar「予測AIと生成AIの融合で新たなバリューの創出 ~生成AIブームで浮かび上がる現場のニーズと課題」をご覧ください。

※本Blogは、Value-Driven AI: Applying Lessons Learned from Predictive AI to Generative AIの抄訳版です。詳細については、原文をご覧ください。

投稿 バリュー・ドリブンAI：予測AIから学んだ教訓を生成AIに応用する は DataRobot に最初に表示されました。

企業の技術戦略の舵取りをするCIO、大規模なデータセットを管理するCDO、または次の大きなものを創造するAIビルダーなど、どのような方にも最適です。当社の進化は、AIイニシアチブを変革し、データチームを新たな高みへと導く比類なき機会を提供します。AIへの投資から、これまでにない真の価値を引き出すことができます。

AI構築におけるDataRobot Summer Launchの主なハイライトを紹介します。

1.AI構築の変革

時間は私たちにとって最も貴重な財産です。しかし、残念なことに、私たちはより革新的な仕事にのみ集中できるわけではありません。ルーチンワークや単純作業の自動化に取り組むことで、より挑戦的で創造的な課題の解決に時間を割くことができます。

モデリングデータの準備：当社のプラットフォームは、データ準備プロセスを魔法のように簡素化します。自動化と高度な操作により、高品質なデータを迅速に発見、テスト、作成できます。みなさんは面倒なデータのクリーンアップ作業から解放されるのです。私たちのプラットフォームがデータと結果を最適化し、パフォーマンスを向上させる様子をご覧ください。

ディープラーニングでモデリングデータを補強：特徴量エンジニアリングを新たなレベルに引き上げました。私たちのモデルブループリントを使って、何千もの特徴量を容易に自動作成することができます。生成AIの登場により、RoBERTa、TinyBert、MiniLMのようなテキストやビジュアル埋め込み用の一般的なモデルも含まれるようになりました。

2.汎用的でカスタマイズ可能な生成・予測AIソリューション

多様な開発ニーズに対応できない、制限のあるツールの活用に閉塞感を感じたことはありませんか？「Build Your Way（思いのままに構築する）」は単なるモットーではありません。私たちからみなさまへの約束です。そしてそれは、予測的または生成的なAIのユースケースだけに限定されるものではありません。

Build Your Way（思いのままに構築する）：あらかじめ生成されたモデルやカスタマイズされたモデルから、先進的なホスト型ノートブックを使って自分自身で構築するモデルまで私たちがカバーします。当社のプラットフォームは、コードファーストのデータサイエンティストとローコードユーザーのコラボレーションを促進し、多様なビジネスニーズに対応します。

あらゆるAI課題に取り組む：当社のAIプラットフォームは、質問への対応から時系列予測まで、さまざまなデータタイプと課題をサポートしています。生成的または予測的なAIの課題に自由に取り組むことができます。

3.コードファースト・テンプレート、生成AI、ディープラーニングでAIビルダーを強化する

AIプロジェクトを開発するたびに、ツールやプラットフォームを渡り歩くのにうんざりしていませんか？複雑な統合やカスタマイズ可能なソリューションの不足によって、あなたのプロジェクト開発の妨げになっていませんか？私たちは、あなたが直面している課題に寄り添います。

あらゆるユースケースに対応：当社のノートブックは、生成AIやナレッジベースから予測モデルまで、エンドツーエンドのコードベースのソリューションを作成できるようにします。AIワークフローを構築から導入までシームレスに行えます。

包括的な開発者の実験場を探る：AIプロジェクトをスタートさせたいとお考えですか？DataRobotは、コードファーストのテンプレートと統合機能を提供しています。これには、AIアクセラレータ、カスタマイズされたStreamlitアプリにDataRobotが開発した機能をデプロイするためのテンプレート、DataRobotX 拡張機能、およびAzure OpenAI統合が含まれます。自動化されたコード生成、充実したデータ、インサイト、最適化の恩恵を受けて、次のプロジェクトを素早く着想しましょう。

ディープラーニングのパワーを活用：高度なディープラーニング機能で非構造化データの課題を克服します。ファンデーションモデルは、テキストベースのタスクの前処理に利用できます。さらに、当社のプラットフォームはPDFの取り込みをシームレスに行い、Hugging Faceモデルとの統合を提供します。また、OCR機能を活用することで、1クリックでスキャンしたドキュメントのモデル化も行います。

みなさんAI構築を強化する準備はできましたか？DataRobot Summer Launchオンデマンドを見て、DataRobotを使い始めてください。私たちは、みなさんがAIを活用し創造する新たな挑戦を楽しみにしています。

投稿 DataRobot Summer Launchから生成AIによるAI構築の最新動向を紹介 は DataRobot に最初に表示されました。

CIOやCDOであれば、組織を率いる上で極めて重要な役割を担っていることを十二分に理解しているはずです。あなたは、データ駆動型、AI搭載の未来に向けた旅路におけるマッピングに尽力してきました。イノベーションへの情熱、効率性を追求する目線、意思決定におけるリーダーシップは、まさにビジネスのさまざまな側面で成功をもたらしています。しかし、AI投資のROIを実証する方法は必ずしも明確ではありません。私たちは、より迅速に、より良い意思決定と社内プロセスの合理化を行い、データ駆動型カルチャーの構築を支援するために、お客様のユーザビリティを優先した全く新しい機能を構築しました。

そして、AIビルダーのみなさんの支援も我々は注力していきます。みなさんの技術、コミットメント、そしてコラボレーションは、組織の成功における心臓です。透明性がありパワフルなAIソリューションの構築という、みなさんが今取り組んでいる仕事は、かつてないほど重要なものです。テクノロジーを開発するだけではありません。未来を定義し、ビジネス・ステークホルダーと手を携えて仕事をしていくのです。今こそ、みなさんが輝くときです。

イノベーター、思想家、そしてあなたのようなAI愛好家のために開催されたDataRobot Summer Launchのハイライトを紹介します。

1.インタラクティブな生成・予測アプリの作成

私たちは、ビジネスユーザーがAIから価値を引き出すためのAIアプリを開発してきました。私たちは予測モデルの分野でこれを成功させてきましたが、さらに大きな飛躍を遂げようとしています。

あなたのアイデアと我々のAIプラットフォーム：DataRobot AI アプリでは、革新的なアイデアを実現するツールが見つかります。予測モデルはほんの始まりに過ぎません。今、私たちは生成AIを完全にインタラクティブな体験へと変えています。

容易なコラボレーション：DataRobotがホストするStreamlit上のアプリケーションサンドボックスを使用することで、プロトタイプ構築を容易にします。チームメイトと自由に遊び、プロトタイプを構築し、生成AIアプリケーションを完成させることができます。

2.AIを翻訳し、ビジネス言語にする

予測モデルの結果を解釈すると、まるで外国語を理解できた時のような気分になることを私たちは知っています。特に、あなたがビジネスサイドにいる場合はなおさらです。このような洞察は、技術に精通している人だけでなく、誰もがアクセスできることが重要です。だからこそ、私たちはAIアプリに新しい説明可能なレイヤーを追加しているのです。

直感的なインサイト

私たちの新しいモデルアプリを使えば、複雑な予測をインタラクティブで視覚的に直感的なインサイトに変えることができます。このツールは、AIの専門家でも、AIを使い始めたばかりの方でも、新しい方法でテクノロジーとつながることができます。

信頼を共に築く

透明性は信頼を育みます。私たちの新機能は、ビジネスユーザーとAIビルダーの間にあるギャップを埋めるためのものです。チームがコラボレーションし、成果を出し、明確な目的意識とビジョンを共有するカルチャーを構築するための単一のプラットフォームができました。

データリーダーやビジネスエグゼクティブの多くは、AIイニシアチブの価値を示すことに苦労していますが、あなたがその一人になる必要はありません。DataRobot Summer Launchのオンデマンドセッションをご覧ください。さらなる生成AIの価値をより深く理解できます。

生成AIへの旅路はここから始まります。

投稿 DataRobot Summer Launchから生成AIによるAI消費の進歩を紹介 は DataRobot に最初に表示されました。

生成AIはどのようにして具体的なビジネス価値を提供できるのか？この疑問は、予測AIを導入してきたチームにとっても変わらない課題です。

私たちDataRobotは、企業がAIで価値を実現する際に直面する多くの課題を目の当たりにする機会に恵まれてきました。私たちが知る3つの大きなハードルは以下の通りです：

• 生成AIライフサイクルと予測AIライフサイクルにまたがるサイロ化。
• 急速に進化する新しい技術を探求し、正しく評価すること。
• 既存の企業エコシステムとデータおよびAI投資との統合が不十分で、価値創造が損なわれる。

同時に、AIチームには、AIで何が可能かに対する非常に高い期待を実現しなければならないというプレッシャーが高まっています。

DataRobot Launch Event ~2023 Summerでは、クラウドデータウェアハウス、データレイク、プラクティショナーツール、およびビジネスアプリケーション全体にわたって、生成および予測AIプロジェクトの開発と管理のための一貫したエクスペリエンスを提供することによって、今日これらの課題に対処することを目的としたイノベーションを発表します。

生成AIと予測AI：両方の長所

DataRobotでは、生成AIと予測AIの融合が将来の価値の主要な源泉の1つであると考えており、スケールの大きな差別化された価値の推進を支援するために両者の長所を組み合わせています。

この可能性を強調するため、DataRobot Launch Event ~2023 Summerの一環として、予測AIと生成AIを使用して、人々に信頼されるGenAIソリューションを作成する方法を紹介します。

DataRobotを使用することで、生成的・予測的AIは合理化された効果的なプロセスとなり、価値への道筋における最大の課題や障害を克服するように設計されています。

そしてその道はすべて、ユーザーと利害関係者から始まる……。

ユーザーが喜ぶインタラクティブな生成・予測AIアプリの構築

新しいリリースでは、消費、生産、実験の間のギャップを縮めました。結局のところ、ユーザーがそれを使えなかったり、使い方を理解できなかったりしては、AIソリューションの意味がありません。

新しく導入されたStreamlitアプリホスティングを使えば、わずか数行のコードで、オーダーメイドの生成AIアプリケーションを構築し、瞬時にデプロイして共有することができます。消費、実験、制作を緊密に統合することで、あなたとあなたのチームは、GenAIソリューションの構築とGenAIアプリ体験のプロトタイピングを迅速かつ簡単に行き来することができます。これにより、人々が使いたいと思うリッチなインタラクティブ・アプリケーションを簡単に作ることができます。しかし、GenAIをユーザーに提供するためにアプリを構築するだけではありません。わずか数行のコードで、組織のオペレーションやビジネスシステム（Slack、Salesforce、BIツールなど）に生成AIを簡単に統合することで、ユーザーがどこにいても簡単に対応することができます。

私たちはまた、コードを一切必要とせず、完全にインタラクティブで会議対応の予測AIインサイトアプリを容易に作成できるようにしました。これらの洞察アプリには、ビジネスとモデルのテンプレートが含まれており、ビジネスに適した言葉で結果を説明することができます。what-if分析、最適化、将来シナリオのシミュレーションなどの機能により、データサイエンスチームは予測をインタラクティブで視覚的に直感的な洞察に効果的に変換することができます。

モダンでライブなコードファースト・エクスペリエンスでAIを素早く作成

私たちは、AIの実験とプロトタイピングを合理化する必要性を認識しており、DataRobot Notebooksの機能にさらに投資して、予測AIと生成AIのユースケースの作成に集中できるようにしています。バックグラウンドでは、私たちがインフラストラクチャとプロジェクト編成を行います。

当社のAPIファーストの統合により、お客様は生成AIイニシアチブの運転席に座ったままで、LLMの選択を管理し、データプライバシーを保護し、生成プロジェクトの財務面を管理することができます。当社のプラットフォームの柔軟性とオープン性により、任意のLLMを使用し、お好みの埋め込み方法とベクターデータベースを使用し、特定の生成AIのユースケースに適した正確でユーザーフレンドリーなエクスペリエンスを提供するために、プロンプトを迅速に実験して最適化することができます。ボーナスとして、当社の組み込みノートブック・ソリューションにより、インフラストラクチャの設計、構成、管理、およびスケーリングが不要になります。

さらに、Hugging Faceモデルとのシームレスな統合、PDFのエンドツーエンドのサポート、前処理タスクのための組み込み基礎モデルのような、テキストベースのAIのための新しいディープラーニングとNLP機能は、生成AIのユースケースに必要な非構造化データの取り扱いをさらに簡素化します。

プロセスをさらに改善するために、DataRobot Notebooksでは、すぐに使えるさまざまなコードスニペットやライブラリ（Generative AIとPredictive AI Accelerators）、新しいタスク固有のAPIコマンド、Azure OpenAIを搭載したコードアシスタント（現在パブリックプレビューで利用可能）を使って、AIプロジェクトをジャンプスタートさせることができます。

エコシステム全体でAIの管理とガバナンスを統一する

DataRobotは、ハイブリッドな生成・予測AI環境の管理を簡素化した。DataRobotは、組織がモデルのパフォーマンスを追跡し、応答性を確保できるガバナンスとモニタリング機能を提供します。DataRobotのAI運用では、配置や起源に関係なく、すべての生成AIと予測AI資産の360度ビューを提供します。

ベクターデータベースとAPIベースのLLMを管理し、「デプロイ」し、生成AIプロジェクトのモニタリングSLAを作成し、生成AIと予測AIの両方の資産を単一のレジストリに整理することができます。また、生成AIのコストが制御不能に陥らないように、DataRobotはLLMの使用状況の監視を支援します。

生成AIへの信頼とパフォーマンスの保証

AIに対する信頼を築くことは、普及のために極めて重要です。生成AIの一般的な課題の1つは、自動化されたコンテンツに全面的に依存することをためらう可能性があることです。特に、誤った生成AIの出力やAIの幻覚に関するニュースを考慮すると、なおさらです。

DataRobotは、カスタムパフォーマンス指標と、予測AIと生成AIを組み合わせることで、これらの懸念に対処します。DataRobotでは、基本的なモニタリングにとどまらず、毒性モニタリングや、ビジネスの評判を守るためにLLMが「オントピック」を維持しているかどうかなど、カスタムパフォーマンス指標を定義することができます。

生成AI成功への確立された道

私たちが話をするお客様や見込み客の多くは、今まさに生成AIの戦略計画を実現しなければならないというプレッシャーに直面しています。

私たちのプラットフォームは、堅牢な生成AIワークフローから高度なモニタリングや再トレーニング機能まで、あなた自身がそれを行うことを支援するように構築されていますが、私たちはまた、この複雑で比較的新しい分野では手に入れることが難しい、応用AIの専門知識の重要性も認識しています。

DataRobotは、10年の経験、何千ものお客様、何万ものユースケースにより、これらの専門ノウハウを提供できる数少ない組織の一つです。

そのため、生成AIで価値を提供するのに役立つイネーブルメント製品をいくつかご紹介します。

生成AI戦略アドバイザリーおよび技術支援サービス

• 生成AIテーマ創出ワークショップ＆ロードマップワークショップにより、価値の高い機会を体系的に特定し、優先順位を付けます。
• 私たちのエグゼクティブ向けワークショップで、すべてのリーダーを素早くスピードアップさせましょう。

生成AIサービスパッケージ

• LiveワークショップとHands-On Labsで、大規模な生成AIアプリケーションの構築、最適化、モニタリングの方法を学びます。
• 私たちのGenAI実行サポートで、専任のサポートを受け、イニシアチブを迅速に進めましょう。

クラウドおよびハイブリッド環境全体にわたる統合インテリジェンス・レイヤーの構築

私たちは、お客様のAIプロジェクトが孤立して存在するものではないことを知っています。だからこそ私たちは、お客様の既存のデータや分析インフラとの統合を拡張し、強化し続けているのです。

GoogleおよびSnowflakeとのネイティブ統合を強化しました。データを移動することなく、SnowflakeとGoogle BigQueryで重複排除、テーブル結合、集計などのデータ処理を高速に実行できるようになりました。OAuth、Key-Pair認証、サービスアカウントを利用することで、GoogleとSnowflake環境に対する完全なコントロールとセキュリティを保持しながら、アクセスを許可することができます。

Airflowデータを取り込み、簡単なPythonコードでDatabricks Sparkクラスタ上で予測を実行し、ワンクリックでAzureMLにモデルをデプロイすることができます。

その他のアップデートには、AzureとAWSの両方で利用できるようになったシングルテナントSaaSが含まれ、AWS向けのHIPAA準拠オプションや、Azureユーザー向けのAzure Kubernetes Serviceのネイティブサポートなど、インフラストラクチャの完全なコントロールを維持するのに役立ちます。

これらは最新リリースのハイライトの一部に過ぎません。DataRobot Launch Event ~2023 Summer オンデマンドをチェックして、新機能の詳細をご確認ください。

すでにDataRobotで生成AIの旅に出たお客様2社、FordDirect、Baptist Health South Floridaの取り組みをぜひご覧ください。

これはDataRobotのこれからの始まりに過ぎません。秋に向けて取り組んでいることがたくさんありますので、ご期待ください。

投稿 DataRobot Launch Event ~2023 Summer の概要：「ビジョンからバリューへ」を支える生成 AIと予測 AI は DataRobot に最初に表示されました。