概要
本セッションでは、生成 AI の特徴と、エンタープライズでの利用時に検討すべきポイントについて、主にシステム構成の観点で説明します。
生成 AI はその強力なケイパビリティにより、多くのユースケースが検討されていますが、エンタープライズ利用においては、生成 AI がもたらすリスクを理解して、ビジネス / 組織 / システムといった観点での対応を検討する必要があります。必要な対応を、本セッションで学ぶことができます。
Google Cloud 遠山 雄二
カスタマー エンジニア
所感
このセッションでは、主にどのようなステップで生成AIを作成すべきなのか、ざっくりと知ることができた。
開発上で考えるべきこともさることながら、
それ以前の段階で、例えば現状のビジネスがどのように運用されていてどこに改善の余地があるのか、
現状データはどのように蓄積されているのか、
AIを用いることによる法律的な観点でのリスクがないのか、
そしてAIを用いることでどれぐらいの改善インパクトが見込めるのか、または改善したと言えるための基準値（KPI）の定義など、
必要な検討ポイントが述べられている。
そしてこれらの検討ポイントは必ずしもAIだけに当てはまるものではなく、
どんなものでも、開発する上で重要なポイントとなるのではないか、と思う。
内容メモ
インパクトとリスク
インパクト
生成AIの登場で、7%のGDP成長
リスク
- ハルシネーション
- AI倫理を考慮した開発が必要
- PaLM2には有毒性検出機能がある
エンタプラーズでの検討ステップ
- ビジネスドメインとユースケースの特定
- ビジネスインパクトの観点
- 繰り返し作業
- ドキュメントに基づく対応
- データの検索などの範囲は？
- フィージビリティの観点
- 十分なデータがあるか？
- リスクを許容できるか？
- ミッションクリティカル
- ビジネスインパクトの観点
- テータソース
- なんのデータが必要か？
- 関連するデータは？
- どこにあるデータが必要か？
- データの保存場所は？
- どのようガバナンスが必要か？
- アクセス件の管理
- 機密情報や個人情報は？
- なんのデータが必要か？
- タスクフォース
- ビジネス、技術面からなるチームを構成
- ビジネス担当者
- エンジニア
- プロンプト
- 実装
- リーガル担当
- MLリード
- ビジネス、技術面からなるチームを構成
- 成功基準の定義
- ビジネス、技術のKPIの定義
- 精度
- 生産性
- 魔族ど
- コスト削減
- エラー
- ビジネス、技術のKPIの定義
- 自社データと統合したアプリの開発
- LLMと自社データを統合したアプリケーション
- パフォーマンスの考慮
- LLM
- グラウンディング
- 指定した情報に基づいてMMLに回答させる手法
- セキュリティ
- LLMと自社データを統合したアプリケーション
- 利用者拡大
- トライアルし、フィードバックを得る
- 更なる改善ポイントを探る
- 運用βプランの整理
- 評価指標を測定し、継続的に改善する
- おブザーばビリティ
- LLMのアウトトット品質
- アプリ全体の品質
- 監査情報の取得
- 事前に決めたKPIが指標
- 同じドメインへ追加ユースケースに取り組む
- ゆーすけーすの横展開
- 今後の全社展開、社外公開も見据えて
システム構成面での考慮点
- パフォーマンス
- テキスト→ベクトル変換API
- Embeddings API
- 非構造データからのデータ抽出
- ベクトルDB
- Cloud Sql
- Alloy DB
- Bigquery
- VertexAI Vector searc
- LLMの選択とチューニング
- ユースケースを踏まえて選択
- ROIを考慮
- セキュリティ
- 機密データの処理
- アタックプロンプトの検出
- データのアクセス制御
- 機密データの処理
- オブザーバビリティ
- LLMの評価
- アプリケーションの評価
- 監査
## VertexAI Search
- グランディングからの言語検索
- 情報ソースの提示
- 社内ポータルからAPIで繋ぎ、バックエンドとして使用できる
- 社内文書の検索
- WEBサイトのナビ
- リサーチ業務の効率化
- プロダクトカタログの検索性向上