アップルジャパンで開かれた Foundation Models のワークショップに参加してきた。結果から言うと、知りたいこと、気になっていたことはすべて明快にでき、お話もコーディングもたくさんできて、とても充実した時間となった。
参加者が少なかったおかげで、心置きなくテクノロジーエヴァンジェリスト武石さんとお話しできたのが良かった。Foundation Models に限らず、何をお尋ねしても的確な回答をくださったのがとても心強く、今後の取り組み方にも自信を持つことができた。自学自習だけだとこうはいかない。
ワークショップ：新しいFoundation Modelフレームワークのアプリへの導入
ワークショップとはいうものの、中身は事前に告知されていた通りにもくもく会で、冒頭5〜10分 Foundation Models framework に関するイントロがあったのち、3時間ほぼほぼ質問と作業時間に費やすことができた。
このブログで長々したためている通り、筆者は「日記を Spotlight にインデクスし Foundation Models に検索させ、対話に使う」ことをテーマに取り組んでおり、そのプロジェクトを持ち込んだ。課題が山積していて、相談はおおきく以下があった。
- Core Spotlight のセマンティック検索が効かない（部分一致でしかない）件
- Foundation Models が指示通りにツール呼び出しを行ってくれない
- ツール呼び出しの制限の有無（タイムアウトなど）
- Core Spotlight を諦めるとしたら、RAG の実装方法
参考：メインで対応くださった武石さんのツイート
冒頭、いくつか tips の紹介があった。（メモしている範囲で）
- Languages
- デフォルトのレスポンス言語は、入力（プロンプト）の言語によって決定される
- tool calling に英語が混ざっていたら英語になる可能性があるので、instruction で言語を指示すると良い
- プロンプトには
LocalizedString か Locale.current を instruction 指定に使うのを推奨（ユーザーの言語環境に応じられる）
- Tool calling
- ツールを強制的に呼び出す際は、instruction に強い表現を使うこと（プロンプトテクニック）
ALWAYS USE *** tool to find…You MUST USE *** tool
- Handling limited token
- 4096 token というトークン上限
- 日本語は、CJK は1文字1token（英語は3-4文字1token）
- トークン消費を見るためのAPIはない
- やりとりの他にも、生成された結果もセッション内でトークンに含めて管理しているのでややこしい
exeededContextWindowSize エラーを捕捉して新しいセッションを作るGenerationOptions.maximumResponseTokens でコントロールする- 長い文章を扱う場合、NLTokenizer でチャンクを作る（Natural Language framework）、パラグラフベースで文章を切ることが可能
質疑で新たに知ることができたことのメモ。事前に実験したこと、考えていたことをもとにディスカッションくださった。
- Core Spotlight のセマンティック検索挙動について
- 部分一致的な挙動になるのが現状の性能限界
- Siri の改善が追いついていない
- WWDC24 セッションで言及されたサンプルコードも現状存在しない
- ツール呼び出しをしてくれないケースがある
- 指示文に
“must use the tool (“SearchDiaryTool”)” と書いていたところを、よりシンプルに “must use the SearchDiaryTool” とするだけで変わるかも
- 肌感としてツールの名称定義を、動詞-名詞 (SearchDiary, GetXXX) のようにするなどすると結果が変わったりする
- ↑ など、指示文の細かい書き方のチューニングが効果ある
- （ツール呼び出しに限らず）日本語よりも英語の方がパフォーマンスが良い
- ツール呼び出しの制限
- タイムアウトは特に明言されていなく、ない認識
- だが、ツール呼び出し周りの情報がトークンウィンドウを溢れさせて終了することはある
- セッション自体の指示文やプロンプトだけでなく、ツール定義（指示文など）もウィンドウを占有する。複数ツールを与えるとその分オーバーヘッドが増大する
- ツール呼び出しでツールから取得した情報もすべて、最終的なレスポンスに関わらずトークンウィンドウを占有する
- Foundation Models にツール呼び出しをさせるよりも、Foundation Models 外で情報を事前に取得し、プロンプトとして与える方が良い（ツール呼び出しの不確実性 ＜ プロンプトで与えた情報が使われる確実性）
- Foundation Models は自然言語的に回答を整形するのに使うという割り切りも検討
- RAG 実装
- ↑ 武石さんツイートの技術的な噛み砕きや、サンプルコードをもとにした解説
- チャンク化→ベクトル化したものを、メタデータ付きの構造体としてラップしてあげ照合することで、より豊かな検索体験が作れそう
- ベクトル化した情報は必ずしも SQL や CoreData に永続化する必要はない（規模によってはオンメモリでも十分）
- そのほか
- Foundation Models の得意分野として、結局、サマリや抽出が得意
- Writing Tools も内部的に同じモデルを使っている
- Writing Tools では、RAGの自前実装で行わなければいけないチャンク化など内部的に勝手にやってくれるのでラク
前半は上記の質疑を中心に、後半は RAG の実装にチャレンジしていて、つまりどころはその都度質問させていただいた。その際、Apple 社内で流通しているサンプルコードを参考に見せてくださったのは、実現方法が一目瞭然でとても嬉しかった。
ということで今日いただいた情報をもとに、Core Spotlight にはいったん見切りをつけて RAG を自前実装する方向に舵きりしたいと思う。
