Ernie.SG 
2023年8月、私は A.I. で取り組みたい 3 つの主要テーマ、つまりマルチモダリティ、オープンソース、生成型エージェントを整理した。“The Sound of Stories” デモは、双方向的で、物語構造に縛られながらもユーザーに適応する、二言語対応のストーリーテリング体験をどう提供したかを示す一例だ。ユーザーの音声入力をドラム音に変換したり、カバー画像を生成したりする実験もしたが、まだライブ環境には出していない。インターフェースは、あまりにも馴染みのある WhatsApp。これは Meta AI 以前の話で、インターフェースの変遷（Streamlit -> Chainlit -> WhatsApp）を見ると、最終的な選択は、一方では人々が他の選択肢で苦労しているのを見たこと、もう一方では私自身のただの怠け心によってほぼ決まった。
念頭に置いていた設計上の制約は次の通り。
-
物語は “The Boy and the Drum” であるべきなので、道中で出会う人々がいて、各場面で物の交換がある。全体の語りはこれに従う必要がある
-
市場名、交換される食べ物などをローカライズしながら
-
関連する場面ではユーザー入力を促し、常にユーザーを参加させようとする
-
ちゃんと始まり、ちゃんと終わる
-
突飛なユーザー応答も論理的に処理する（Ray-ban Meta glasses を売ろうというユーザーの提案にどう返したか、など）
Demo: The Sound of Stories
Performing Arts x Tech Lab は 2023 年 8 月に始まった。当初は、各ターンで適切な物語の断片だけが生成されるように、かなりのプロンプトエンジニアリングとハックを実装した。そのうえで、ユーザーの応答を次の物語断片の生成に組み込み、一定回数以内に物語を終えるようにしていた。意味不明なユーザー入力に対してあまり堅牢ではないので、最適とは言えない。幸い、必要なのはより多くの知能だけである。
A.I. の進歩をめぐる物語は、モデルがより賢く、より安く、より速くなるのだから、未来の側から逆算して作る必要がある、というものだった。実際、すでにそうなっている。このプロジェクトでは GPT-4 と Kimi を “解雇” し、3 月 19 日に Hugh の推薦を聞いて少し試したあと、そのまま Claude 3 Opus を使った。最終的な公開デモは 4 月 5 日だった。
注：音声生成は最適化されていないので、デモでは生成が終わって再生されるまで約 15 秒かかる。この遅延は、後述の電話版では解決されている。
なぜこのプロジェクトは重要なのか？
ストーリーテリングの観点から見れば、これは現代版の choose-your-own-adventure であり、いつだってかなり楽しい。ここでの学びは、ロールプレイングゲームの再想像にも応用できる。二言語対応（そして多言語対応にできない理由はない）であることは、アクセスと新しい観客への到達範囲を広げる。The Esplanade の公開発表で、「もっと多くの物語を扱うにはどれくらい時間がかかるのか」と聞かれて、私は混乱した。作り手である私は、これにまったく初めて触れる人の視点から見られておらず、その質問をちゃんと理解できていなかったのだと気づいた。短い答えは、望むだけ多くの物語へ、数秒、場合によっては数ミリ秒で拡張できる、ということだ。人々が見落としている文脈は、大規模言語モデル (LLM) が非常に強力になり、事前学習データを通して取り込まれた文化の知識を少なくとも相当量、内部に抱え込んでいるということだ。つまり、物語はユーザーのプロフィールに合わせて場所や品物を更新できる。たとえば韓国出身だと主張したユーザーのデモでは、母親が Dongdaemun Market に行く。A.I. があなた固有の文脈や語彙を理解できないというのは MYTH だ。実際にはできる。よくある言い方に直すなら、多くの組織ではそうしたデータがデジタル化されていないか、自分たちのデータセットで最適化する能力がない、ということだ。
私はこれをアーキテクチャの観点からも見ている。あるコーパスに範囲を絞り、ユーザー入力を受け取り、その入力にもとづいて応答を生成するという基本形は、面接準備ボットからカスタマーサポートエージェントまで、幅広いユースケースに適用できる「設計パターン」にかなり近い。
ライブデモと展示期間中、観客は私が設定した電話番号（そう、本物の電話番号）に電話して、A.I. Kamini と話し、電話越しに物語を聞くこともできた。テキストチャットと似た体験だが、完全に音声の領域にいる。最適化のおかげで、音声出力のストリーミングは実際にはずっと良かった。システムの知能は Claude 3 Opus より低いが、本物の電話会話のように感じられる。
次は？
中国にいる間にこれを GCP にデプロイしたが、全体としては意図通り仕事をしてくれたように見えた。バグ修正は必要なく、問題や制限は既知のもので、私が取り組まなかった理由は、ええと、時間？という感じだ。なので Lab 後に直す可能性がある領域は、WebSockets を使って音声応答をストリーミングし、速度を上げること。そして文字列 1 つのユーザー応答を期待するのではなく、複数のユーザー入力を扱うことだ。これはバックログに入る。加えて、Elevenlabs より良いものを提供できる人がいるなら、もっと良い中国語音声クローニング技術を切実に待っている。
動くコードベースができたので、次は生成型エージェントをデプロイして提供したい。適切な節目で LLM を使ってワークフローを自動化し、このパイプラインの出力が行動、つまり世界の状態変化につながるようにしたい。それは、自分の動画を自動で文字起こしし、翻訳し、字幕を生成し、そのままアップロードにつなげるような単純なものでもよい。あるいは、与えられた任意の非構造化データから適切なスキーマを判断し、非構造化データから構造化データを出力するエージェントのように、より高度なものでもよい。後者のエージェントは、フィールド録音からデータを抽出したい研究者、所蔵品データを豊かにして全部を自動化したい GLAM 機関（つまり画像に豊かな埋め込みを生成するだけでなく、動画や手紙などに対して文字起こし、テキスト、関連メタデータを生成すること）、さらには私が取り組むはずの試験・面接準備ボットにも関係すると思う。
ソフトウェアがどう作られるのか、A.I. ネイティブな体験がどれほど強力になり得るのかを考え直すという点で、私たちはまだ本当に初期段階にいる。それらがどれほど生産的になるのか。どれほど拡張可能で、積み重ね可能になるのか。API を介して他のソフトウェアとうまく接続できないソリューションと仕事をすることは、犯罪であるべきだ（本当に、本当にそうせざるを得ない場合を除いて）。
今後の更新をお楽しみに！
PubPub の erniesg.pubpub.org/pub/xlkdc79p で初出。