WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Explore prompt design & safety for on-device foundation models

Explore prompt design & safety for on-device foundation models

Design機械学習
元の動画を見る

Highlight

本セッションは HCI リサーチャーの Mary Beth と AI セーフティエンジニアの Sprite による共同講演です。前半ではオンデバイスの約 30 億パラメータモデルに対する prompt 設計のテクニック、後半では「スイスチーズモデル」を用いた多層的な AI セーフティ戦略について解説しています。

主な内容

Foundation Models フレームワークに初めて触れる開発者の多くは、これをミニ版の ChatGPT のような感覚で使ってしまいがちです。すると不思議な現象に次々と遭遇します。電卓代わりに計算させると間違える、ソートアルゴリズムを書かせるとなんとか動くレベルのコードしか出ない、最近のニュースを尋ねると堂々と嘘をつく。prompt を変えても症状は変わりません。これは prompt の書き方が悪いのではなく、このモデルが持つ能力の境界そのものが異なるためです。

Apple は本セッションでこの点を明確に整理しています。オンデバイスモデルは約 30 億パラメータで、iOS、iPadOS、macOS、visionOS にビルトインされており、Apple Intelligence の Writing Tools もこのモデルを利用しています（01:48）。数千億パラメータ級のサーバーモデルと比べると、ポケットに収まるサイズに圧縮された専用モデルです。得意なのは要約、分類、マルチターン対話、テキスト生成、リライト、タグ付けなど。一方、複雑な推論、数学計算、コード生成、事実知識の提供は苦手です。世界知識は限定的で hallucination も起こり得るため、「事実データベースとして使う」という発想は最初から成立しません。

セッションの後半、つまりセーフティのパートこそ本題です。Foundation Models フレームワークは Apple が訓練した guardrail を内蔵しており、これは入力と出力の両側で機能します。仮に prompt が入力フィルタを巧みにすり抜けたとしても、出力側で有害コンテンツがブロックされる仕組みです（12:30）。ただし、フレームワークが提供する安全性はあくまで「土台」であり、その上に開発者自身が安全層を重ねる必要があると Apple は繰り返し強調しています。Sprite はこれをスイスチーズに例えて説明しています。各層には穴が空いているものの、すべての穴が同時に揃う確率は極めて低い、というモデルです（17:53）。具体的なテクニックよりも、このメンタルモデルこそが重要です。

詳細

モデル能力の境界

オンデバイスモデルのトレードオフは、いくつかのハードルールに集約できます（03:32）。

  • 複雑な推論タスクは苦手なので、よりシンプルなステップに分解して与える。
  • 数学的なタスクは AI ではなく通常のコードに任せたほうが確実。
  • コード生成は得意分野ではないので、Copilot 的な使い方は避ける。
  • 事実ベースの問いは、そのトピックを確実に知っていると検証済みでない限り依存しない。

Mary Beth は「人気の bagel フレーバーを 10 個挙げる」という例を用いています（04:25）。モデルは bagel そのものは知っているのに、plain bagel を「いろいろなトッピングがのっている」と説明してしまう。これがまさに hallucination です。ただし彼女はここで興味深い反転を示します。ベーカリーのミニゲームの中で、お客の注文セリフを生成する際にたまに出るおかしな表現が、むしろ笑いどころになるのです。hallucination を許容できるかどうかは、ユースケース次第ということです。

Prompt 設計のテクニック

最もシンプルな Swift コードからスタートします（01:11）。

let session = LanguageModelSession()
let prompt = "Generate a bedtime story about a fox."
let response = try await session.respond(to: prompt)

ポイント:

  • LanguageModelSession() でセッションを 1 つ作成し、これが連続する対話コンテキストに対応します。
  • prompt はモデルへの自然言語の指示で、Apple Intelligence がサポートする任意の言語で記述できます。
  • respond(to:) は async throws なメソッドで、モデルが生成したテキストを返します。

Prompt のチューニングについて、すぐに使える具体的なテクニックがいくつか紹介されています（06:18）。

  • “in three sentences”、“in a few words” で出力を短く、“in detail” で長くする。
  • role を使ってスタイルを制御する。例: “You are a fox who speaks Shakespearean English”。
  • prompt は明確なコマンド形式で書き、単一タスクかつ十分に具体的にする。
  • prompt 内に 5 つ以下の例を埋め込むと、タスクのパフォーマンスが大きく向上する。
  • 特定の出力を抑制したい場合、すべて大文字の “DO NOT” を使うと効果が高い。「強い口調で言い聞かせる」のに近い感覚です（08:01）。

デバッグ環境としては Xcode の #Playground が第一候補です。prompt を 1 行書き換えれば右側のキャンバスに即座に結果が表示されます（08:11）。

Instructions と Prompt の違い

Instructions も prompt の一種ですが、session 作成時に渡すことで「以降のすべての prompt をこのルールに従って応答せよ」とモデルに伝えます（08:51）。

let session = LanguageModelSession(
    instructions: """
    You are a helpful assistant who generates scary stories \
    appropriate for teenagers.
    """
)
let response = try await session.respond(to: "Write a poem about bagels.")

ポイント:

  • instructions はすべてのユーザー prompt よりも先に効力を持ち、モデルの「人格」と振る舞いの境界を定義します。
  • モデルは instructions を優先的に守るように訓練されているため、セーフティ系のポリシーはここに書くのが最も安定します。
  • 後続のユーザー prompt が「bagel についての詩を書いて」であっても、全体は指定されたトーン（この例ではホラー風）を維持します。
  • ユーザー入力を instructions に決して入れないこと。instructions は開発者だけが書くものです。

Guardrail のエラーハンドリング

モデル呼び出し時には、guardrail が投げるセーフティエラーを必ずキャッチしましょう（12:56）。

do {
    let response = try await session.respond(to: prompt)
    // 応答を使用
} catch LanguageModelSession.GenerationError.guardrailViolation {
    // 入力または出力が guardrail によってブロックされた
} catch {
    // その他のエラー
}

ポイント:

  • guardrail は入力側と出力側の両方で動作するため、入力をすり抜けても出力で再度ブロックされます。
  • 「proactive（App が自動的にコンテンツを生成する）」シーンでは、エラーをサイレントに無視して UI を中断しない選択肢があります。
  • 「user-initiated（ユーザーが明示的にトリガーする）」シーンでは、明確なフィードバックが必須です。alert を出す、あるいは Image Playground のように「直前の prompt を取り消す」といった代替アクションを提供します（13:43）。

ユーザー入力の 3 つの取り扱いモード

ユーザー入力をモデルにつなぐ際には、3 段階のセーフティレベルがあります（15:26）。

  1. 完全自由: ユーザー入力をそのまま prompt として渡す。最も柔軟だが、セーフティリスクは最大。
  2. ハイブリッド: 開発者が用意した prompt テンプレートの所定スロットにユーザー入力を埋め込む。
  3. 完全制御: App 側が用意した prompt セットからユーザーが選ぶ。最も安全だが柔軟性は最小。

制御の強さと柔軟性は反比例します。ユースケースに応じて段階を選び、モード 3 で済むならモード 1 を選ばないという判断が望ましいでしょう。

ユースケース固有の mitigation

Guardrail がカバーできるのは「一般的に有害」と判断される内容だけで、自分のビジネス文脈までは理解できません。Sprite は具体例を 2 つ挙げています（16:39）。

  • bagel フレーバーの生成では、ナッツやガーリックといったアレルゲンを含むフレーバーが提示される可能性がある。対策は UI 上にアレルギー警告を出す、設定画面で食事制限を収集してフィルタする、など。
  • trivia ジェネレータでは政治的・センシティブな話題を避ける必要がある。instructions にルールを追加する、キーワードのブラックリストを用意する、より堅牢にしたい場合は分類器を別途学習させてフィルタする、といった選択肢があります。

評価とテスト

最後のステップは evaluation（評価）です。データセットを 2 種類用意します。1 つは通常のユースケースをカバーするもの、もう 1 つはセーフティ問題を引き起こしそうな prompt を集めたものです（18:44）。コマンドラインツールや UI テスト用の App を書いて E2E で検証します。データセットが小さければ手動でチェック、大きければ別の LLM を採点者として使う方法もあります。さらに「アンハッピーパス」、つまり guardrail がエラーを返したときに App が想定どおり振る舞うかどうかも忘れずにテストしましょう。

主な学び

1. App に「入力レベル分け」の仕組みを組み込む

なぜやる価値があるか: Foundation Models は無料・ローカル・プライバシー保護が効くオンデバイス能力で、軽量な自然言語インタラクションに最適です。ただし prompt injection のリスクは現実に存在するため、着手する前に入力レベルを決めるのが先決です。

始め方: インタラクションの入り口でレベルを選びましょう。プリセットボタン（完全制御）で済むなら自由入力欄は使わない。自由入力が必要なケースでは、ユーザーテキストを必ず自分の prompt テンプレートで包み、決して instructions に直接結合しないこと。

2. Guardrail エラーをファーストクラスとして扱う

なぜやる価値があるか: 多くの開発者は guardrail エラーを通常のエラーと同じくサラッと処理してしまい、結果としてユーザーは「どうしようもない alert」だけを目にすることになります。これは信頼を損なう最短ルートです。

始め方: proactive と user-initiated を区別する。proactive ならサイレントにスキップ、user-initiated なら次のアクションを具体的に提示する（入力を取り消す、別の例を試す、AI を使わない経路に切り替える、など）。Image Playground の「undo prompt」が良い参考になります。

3. Instructions に「ネガティブ感情へのフォールバック」を一段書く

なぜやる価値があるか: 日記、チャット、アイデア出しなどの App では、ユーザーがネガティブな内容を書くことが避けられません。デフォルトの応答は冷たく、あるいは火に油を注ぐようなものになりがちで、App への感情的な評価を直接下げてしまいます。

始め方: instructions に “Respond to negative prompts in an empathetic and wholesome way.” のような一文を追加し、App として扱わない話題のリスト（医療診断、法律相談、自傷など）を併記します。

4. Prompt 評価の MVP パイプラインを構築する

なぜやる価値があるか: モデルも guardrail も継続的にアップデートされるため、今日チューニングした prompt が明日にはドリフトしている可能性があります。評価パイプラインがないと、回帰はユーザーフィードバックでしか気付けません。

始め方: まずは 2 つの JSON データセット（正常ユースケース + 危険ユースケース）を作り、Swift のコマンドラインランナーを書いて全 prompt のレスポンスを出力します。小規模なら手動でラベル付け、大規模ならより大きな LLM を採点者にします。prompt の変更や SDK のアップグレードの前後では必ず実行する習慣にしましょう。

5. Guided Generation で「prompt によるフォーマット制約」を置き換える

なぜやる価値があるか: 「JSON 配列で出力して」とモデルにお願いするのはよくある手段ですが、hallucination やフォーマットエラーの確率は決して低くありません。Guided Generation は出力を指定の struct/enum/配列に直接制約するため、フォーマット問題そのものを根本から消せます。

始め方: 現在の prompt にある「以下の JSON フォーマットで出力してください」という指示を、すべて @Generable な Swift 型に置き換えます。まずは利用頻度の高いパスを 1 本だけ移行して信頼性を確認し、問題なければ順次展開していきましょう。

6. Xcode #Playground に prompt 実験室を作る

なぜやる価値があるか: prompt のチューニングは高頻度かつ疎結合な作業で、従来の unit test ではフィードバックが遅すぎます。#Playground なら 1 行書き換えるだけで結果が出るので、「観測しやすいが形式化しにくい」prompt のような対象に最適です。

始め方: プロジェクト内に PromptLab.swift を作り、本番で使っている prompt をすべてコピーしてパラメータ化した実験を行います。正常入力・長文入力・空入力・悪意ある入力の 4 系統をカバーすると良いでしょう。安定が確認できたら本コードへマージします。

関連セッション

コメント

GitHub Issues · utterances