オンデバイス基盤モデルのためのプロンプトの設計と安全性の詳細

こんにちは Mary Bethです 人間を中心に据えたAIの研究者です Spriteです AIセーフティエンジニアを務めています 新しいFoundation Modelフレームワークで アプリ向けの生成AI体験をこれまで以上に 簡単に設計できるようになりました 生成AIは素晴らしいテクノロジーです 重要な課題として 現実世界の様々な状況でアプリを使用する あらゆるユーザーに対応できる 堅牢な体験を提供することが挙げられます 本日はMary Bethと一緒に 課題への対応方法をご紹介します はい このセッションはデザイナーにも エンジニアにも有益な内容です まず始める前に プロンプトとLLMについて 簡単におさらいしましょう ご存知のように プロンプトは 生成AIモデルに入力して 応答を導くためのテキストです 同僚にメッセージを送るような 人間が使う自然な言葉で記述できます

ここに示すプロンプトには 文字列変数として キツネが出てくる寝る前の物語を 生成するよう英語で 記述しています Apple Intelligenceがサポートしていれば 任意の言語でプロンプトを記述できます 次に LanguageModelSessionに対して プロンプト実行するための コードを見てみましょう コードを実行すると モデルは 想像力に富んだ 詳細な寝る前の物語を返して応答します 素晴らしい このときの処理を 詳しく見ていきましょう 新しいFoundation Modelフレームワークでは プロンプトがオンデバイスの 大規模言語モデル（LLM）に送られます LLMは推論してテキストを生成します この汎用モデルはiOS iPadOS macOS VisionOSに 組み込まれています Apple Intelligenceでも 同じ言語モデルが 作文ツールなどに使用されています 内部でも Apple Intelligenceは プロンプトを使ってモデルに命令します プロンプトとLLMについて わかったところで このセッションで取り上げる内容を 見ていきましょう まず 使用する オンデバイス言語モデルに固有の いくつかのデザイン戦略について説明し プロンプトのベストプラクティスを 紹介します その後 SpriteがAIの安全性を考慮した デザイン方法と プロンプトの品質と安全性を 評価し テストするための 戦略について説明します では始めましょう まず オンデバイスLLMのデザインについて 詳しく説明します このモデルはデバイス上に存在し 多くの共通言語タスクに使用されます その一例として 要約 分類 マルチターンの会話 テキスト構成 テキストの修正 テキストを使ったタグの生成が挙げられます 重要なポイントは この大規模言語モデルが ポケットに収まるように最適化され 圧縮されている点です オンデバイスモデルには約30億個の パラメータが含まれています 現在 30億のパラメータを含むとなると 依然として巨大な機械学習モデルとなります これを大局的に見てみましょう この円をChatGPTのような人気の高い LLMであると想像してみてください 現在 このようなLLMは 大規模なサーバで実行される 数千億個のパラメータで構成されます 今日 このサイズの違いにより 大規模なサーバベースのLLMで対応できる 一部の処理にオンデバイスLLMでは 対応できない場合もあります 小さいモデルでは 大規模なLLMで動作するタスクが そのままでは機能しない場合があります システムモデルを使った 複雑な推論タスクで よい結果が得られない場合 タスクプロンプトをシンプルな手順に 分割してみてください 演算関連のタスクでは 小さなモデルを計算ツールとして 使うのは避けましょう AI以外のコードのほうが 演算の信頼性はずっと高くなります システムモデルはコード向けに 最適化されたものではないため コード生成タスクも避けましょう

システムモデルは サイズが小さいため 世界に関する知識も限られています 例えば モデルは トレーニング日付後に起きた 最近のイベントは把握していません ベーグルなどの特定のトピックをモデルが 把握していることを確実に検証した場合以外 事実の確認にシステムモデルは 利用しないようにしましょう モデルにベーグルの人気フレーバーを 10個リストアップしてもらうと

プロンプトに対してモデルは このような結果を生成しました ベーグルを把握していることは明らかですが プレーンベーグルにトッピングが たくさん乗っている記述があり 不正確です 必ずしも正確とは言えないため このモデルをベーグル百科事典として 使わないほうがよさそうです ただし この程度の知識があれば パン屋ゲームのような 別の用途に使うことができます 例えば このモデルを使って ベーグルを注文する お客様の会話を生成できます 間違っておかしなフレーバーのベーグルを 提案しても ゲームでは誤解を招くというより 面白い要素になるかもしれません 次に ハルシネーションの影響を 理解することが重要です モデルは知らない知識について ハルシネーションを起こす可能性があります ハルシネーションとは事実に基づかない情報を 生成する現象を指す専門用語です 事実が重要な手順などでは ハルシネーションによって 誤解を招くリスクは 避けるべきです システム言語モデル使って 事実を生成するのは避けましょう 事実を生成する必要がある場合は 確認済みの情報をプロンプトに記述して モデルに提供することを 検討してください そして新しく記述したプロンプトについて モデルの出力で徹底的に事実確認しましょう 現時点では このモデルの 新しい機能によって多くの状況で 信頼性を向上させることができます それがガイド付き生成です Foundation Modelフレームワークでは ガイド付き生成が 文字列 数値 配列 定義したカスタムデータ構造など モデルの生成結果を 制御できます ガイド付き生成の仕組みについては 「Meet Foundation Models Framework」 セッションをご覧ください 次にプロンプトの ベストプラクティスについて説明します プロンプトエンジニアリングは 重要なトピックですので このセッション以外でも 勉強されることをおすすめします 始めるにあたって ベストプラクティスを いくつか紹介します まず モデルに命令するだけで システムモデルで生成される コンテンツの量を 制御できます キツネが出てくる寝る前の物語を 生成するプロンプトに

1段落でという 条件を追加します

うまくいきました はるかに短い寝る前の物語ができました 「3文で」や「数語で」などの フレーズを使えば出力を短縮できます 「詳しく」などのフレーズを使えば 長めの出力を生成できます プロンプトで役柄を指定することで モデルで生成されるテキストの 文体や話し方を制御できます シェイクスピア調の英語を話すキツネだと モデルに命令します

これもうまくいきました モデルはシェイクスピア調の英語を話す キツネの役柄をうまく表現し そのキャラクター自身が書いた かわいらしい日記を返しました このモデルはプロンプトに基づいて 様々な役柄を演じられます モデルのトレーニング方法について ほかのヒントを 紹介します まず プロンプトを 明確なコマンドとして伝えます このモデルは具体的で詳細なタスクを 1つ命令した場合に 優れたパフォーマンスを発揮します 4つ以下の望ましい出力例を プロンプトに直接記述して モデルに提供することで タスクのパフォーマンスを 向上させることができます 望ましくない出力を 見つけた場合は 「DO NOT」とすべて大文字のコマンドを 記述することで モデルは適切に応答します 厳しい声で命令するような ニュアンスになります

実際にプロンプトを試してみるなら Xcodeにはプロンプトを試すのに最適な Playgroundという機能があります プロジェクト内の任意のコードファイルに #Playgroundと追加して LanguageModelSessionを使って プロンプトを記述するだけです すぐにモデルの応答が 右側のキャンバスに表示されます Swift UIのプレビューのようなもので アプリにとって最適なプロンプトを 試してみるのに うってつけの方法です プロンプトエンジニアリングの ベストプラクティスは プロンプトと 命令の両方に適用できます 命令はFoundation Modelフレームワークの 2つ目の種類のプロンプトで 使う目的が少し異なります LanguageModelSessionを 作成する際 引数として命令を 含めることができます 命令は後続のすべてのプロンプトに対する 動作と応答を モデルに指示するための 特殊なプロンプトです ここでこのような命令を記述してみます 「あなたはティーン向けの怖い話を生成する 優秀なアシスタントです」と 効果を見てみましょう

ここに示しているのが 寝る前の物語を生成するための 元の簡単なプロンプトです 命令を追加すると モデルはほかのどのプロンプトよりも 先に命令を受け取ります 寝る前の物語を生成する プロンプトを送信すると 寝る前の物語の口調が 劇的に変化し 怖い話にするという命令に 即したものに変わります

引き続きモデルにプロンプトを追加しても 命令は保持されたままです 今度は「ベーグルについての詩を書いて」 というプロンプトを送信してみます 予想通り モデルはベーグルに関する 不気味で怖い詩を生成します プロンプトの説明の締めくくりとして インタラクティブ性について触れましょう プロンプトはアプリデザイナー以外が 送信することもできます 命令とプロンプトを一緒に使用することで アプリのユーザーが プロンプトを送信できる インタラクティブな モデルセッションを作成できます 詳しく見てみましょう 日記アプリを作成しているとします まず 言語モデルに 次のように命令します 「あなたはその日の出来事について質問して 日記を書くのをサポートする 優秀なアシスタントです」と 今度はアプリのユーザーが モデルに対して直接 プロンプトとして 日記エントリを開始するとします 「今日は大変だった」と ユーザーが言うと モデルは日記のプロンプトで 「何が大変でしたか？」と 応答します この場合 モデルへのプロンプトとして ユーザーからの入力を受け取るとなると ユーザーの入力内容がわからないため 安全性に影響します 誰かが偶然または意図的に 入力した内容によって モデルが役に立たない あるいは有害な 反応を返してしまう恐れがあります AIの安全性について詳しくは Spriteから説明します Mary Beth ありがとう オンデバイスモデルを 最大限に活用するための 優れたプロンプトの記述方法について Mary Bethが説明してくれました プロンプトのデザインは 安全性ツールボックスの最初のツールです 安全性を念頭に置いてアプリを デザインする方法を詳しく学びましょう 当社はコアバリューを反映するため Apple Intelligenceの機能向けに 一連の原則を作成しました 皆さまのアプリに魔法のような 安全な体験を提供できるよう Foundation Modelフレームワークも 同じ原則に従ってデザインされています 子ども向けの寝る前の物語を生成する場合も 次の憧れの休暇を計画する場合も 多くのことをできるアプリを 作成できる環境を提供したいと 当社は考えています 生成AIは誤用されたり 潜在的な危害につながる恐れもあります Foundation Modelフレームワークにも 安全なアプリ体験のため ガードレールを設けていますが アプリのユースケースに基づいて 発生する可能性のある問題を 検討しておくことをおすすめします 当社はプライバシーを念頭に置いて モデルとフレームワークをデザインしており 固定観念や系統的バイアスを 永続させないため 継続的にモデルの改善に 努めています ではガードレールについて説明します Foundation Modelフレームワークには Appleのトレーニングを受けた ガードレールがあるため 最悪の事態の心配は不要です ガードレールはモデルの 入出力の両方に適用されます 命令 プロンプト ツール呼び出しはすべて モデルへの入力とみなされます ガードレールは有害コンテンツを含む入力を ブロックするようにデザインしています モデルの出力もガードレールによって 保護されます これにより プロンプトが 入力ガードレールを回避するように 作成されていたとしても 有害なモデル出力が確実にブロックされます

Swiftでは安全性に関するエラーが このような方法で検出されています エラーが発生した場合 エラーの発生について アプリユーザーに伝える方法を 検討しておく必要があります 予防的な機能が 検出したエラーであり ユーザーの操作によって 発生したものでなければ エラーは無視して構わず 予期しない情報でUIに割り込みません

誰かを待たせるような ユーザー主導の機能である場合は アプリがリクエストを 処理できないことを説明する 適切なUIフィードバックを 提供してください 単純なアラートでもよいですし この機会にユーザーに 代替的な操作を提示して 選択してもらう方法もあります 例えば Image Playgroundには 安全性に関するエラーの原因になった プロンプトをユーザーが簡単に 取り消せる方法が用意されています Foundation Modelフレームワークは プロンプト生成の出発点として最適ですが アプリの体験に対する責任は 依然として皆さんにあり 期待通りの適切なコンテンツを 提供するアプリとして ユーザーの信頼を得ることが重要です

ここでは ユーザーと信頼関係を築くための 3つの要素を紹介します アプリで不適切なコンテンツが 生成されないように注意してください Foundation Modelフレームワークの ガードレールによって ブロックされます ユーザー入力の処理にも 注意を払う必要があります これは命令やプロンプトを 慎重に記述することで実現できます

アプリからの応答に対してユーザーが 行動するとどうなるか その影響についても 検討しておきましょう どのような対策が取れるか あとでいくつか例を挙げて紹介します 先ほどMary Bethが示した 日記の例に戻りましょう 当社のモデルはプロンプトよりも 命令に従うようにトレーニングされています そのため 命令は応答の安全性を 向上させるのに最適です

ここでは 否定的なプロンプトに対して 共感を示しながら 健全な方法で応答するようモデルに 指示する文章を追加しています 新しい命令によって モデル出力が 変わったのがわかります これで万全というわけではありませんが 安全性に関する命令を 注意深く記述することで アプリの応答の質が向上します 命令はデベロッパ側が行い 命令に信頼できないコンテンツや ユーザー入力は絶対に 含めないようにしてください ユーザー入力はプロンプトに 含めることができます 詳しく見てみましょう よく使われるパターンは ユーザー入力を プロンプトとして直接取得する方法です アプリユーザーの入力内容を受け取る チャットボットを思い浮かべてください このパターンは柔軟性が高いものの 安全上のリスクも伴います このパターンを使用する場合 幅広いユーザー入力の処理に 注意を払うよう モデルに命令してください 柔軟性を損なうことなく リスクを軽減するおすすめの方法は 独自のプロンプトとユーザー入力を 組み合わせることです さらにおすすめなのが アプリに 組み込みプロンプトのリストを提供して ユーザーに選択してもらうことで プロンプトを完全に制御する方法です ほかのパターンほど 柔軟性は高くないものの アプリにとって最適であり モデルが優れた応答を生成できる 一連のプロンプトを 厳選できます 適切な命令を行い ユーザー入力の処理に 注意を払ったとしても アプリの安全性に リスクが残る場合があります ユーザーがアプリでコンテンツ生成操作を 実行するのに伴う影響と結果を 予測しておく必要があります 例をいくつか見てみましょう

Mary Bethが先ほど示した ベーグルの フレーバーを生成するプロンプトです

ユーザーがアプリを使用する際に 考えられるリスクの1つが ベーグルのフレーバーにナッツやニンニクなど アレルゲンが含まれる場合があることです リスクを軽減する1つの方法が UIにアレルギー警告を 示すことです ユーザーがアプリに食事制限を設定して モデルでレシピをフィルタできるよう 設定を追加するという 方法もあります

別の例として トリビア生成アプリを 作成している場合 物議を醸すような話題や ユーザーにとって不適切な 他国の話題に関する質問を生成するのを 避ける必要があります 追加の命令を追加するか 拒否するキーワードのリストを 提案するよう検討してください MLプラクティショナーであれば より堅牢なソリューションにするため 分類器をトレーニングすることもできます ユースケースに合った 緩和策を講じる責任は 皆さんにあります ほかの多くの安全性システムの場合と同様に これまでお話ししたのは どのレイヤーでも 問題を検出できなかった場合にのみ 安全性の問題が発生する レイヤー化ベースの アプローチです レイヤーを積み重ねられたスイスチーズの スライスだと思ってください スライス1枚1枚に穴が開いていても 積み重ねられたスライスの穴が揃わない限り 下まで何かが落ちることはありません 今度は安全性ツールボックスの説明です スタックの基本レイヤーは Foundation Modelフレームワークに 組み込まれたガードレールです これにより モデルへの命令に 安全性が加わります これらの命令は プロンプトよりも優先されます また モデルのプロンプトに ユーザー入力を含める方法を制御できる アプリをデザインする必要もあります 最後のレイヤーでは ユースケースに合った 独自の緩和策を実装します 生成AIを使用するアプリを作成する際の 重要なステップが 評価とテストです

まずは品質と安全性の両方に対応した データセットを厳選します アプリの主要なすべての ユースケースに対応したプロンプトに加え 安全上の問題を 起こす可能性があるプロンプトを 必ず収集しましょう

データセットを使用し 機能全体でエンドツーエンドで これらを実行する 自動化処理を設計します 専用のコマンドラインツールと UIテスターアプリを 作成しておくことをおすすめします

小規模なデータセットであれば 問題がないか 各応答を手動で確認できます 大規模なデータセットに 拡張する場合は 別の大規模言語モデルを使用して 応答を自動採点する方法も 検討しましょう アプリの望ましくない状況も 忘れずテストし 安全性に関するエラーが発生しても 期待通り動作することを 確認しましょう

評価とテストに投資することで プロンプトやモデルの更新に伴う 改善や問題を 経時的に追跡するのに 役立ちます これにより アプリの インテリジェントな機能の 品質と安全性に 自信を持つことができます 今後も最新のベストプラクティスに従い 安全性に関する問題を解決できるよう モデルと安全性システムを 更新してまいります アプリの開発中に 安全性に関する問題が発生した場合 フィードバックアシスタントを使って 報告できます 独自のUIを作成してアプリの機能に対する ユーザーからのフィードバックを 収集することもできます その際 収集するデータと 使用目的について 必ずユーザーに説明してください アプリのデータ収集と プライバシーについて詳しくは Apple DeveloperのWebサイトをご覧ください このビデオでは 多くのことを取り上げました 検討すべきチェックリストを示し 安全性に関するトピックを締めくくります モデルにプロンプトを表示する際 アプリでガードレールエラーを処理すること 命令に安全性に関する 内容を含めていること プロンプトにユーザー入力を含める場合 柔軟性と安全性のバランスについて 検討すること ユーザーがインテリジェンス機能を 使用する際の影響を予測し ユースケースに固有の緩和策を適用すること アプリのインテリジェンス機能の 品質と安全性に 自信を持つことができるよう 評価とテストに投資すること 最後にフィードバックアシスタントを使って 安全性に関する問題を報告することです AIの安全性に関する説明は以上です 皆さんが生成AIを使ってどのようなアプリを 作るのか楽しみでなりません 役立つ他のリソースとツールを 紹介しましょう プロンプトエンジニアリングに 新しいXcodeのインラインPlayground機能を ぜひお試しください アプリの安全性に関する 多数の推奨事項を 紹介してきましたが Foundation Modelに組み込まれている 安全策を含む 責任あるAIに対する Appleのアプローチについて詳しくは machinelearning.apple.comをご覧ください 詳細な記事も 確認できます 最後に 生成AIに関する 新しいデザインガイドラインと ヒューマンインターフェイスガイドラインも ご確認ください 以上がプロンプトと安全性に関する セッションでした 安全第一にプロンプトを楽しんでください