Logo Ernie.SG

デモ:物語の音

2024年5月2日
約1分で読めます
利用できるタグはありません
Table of Contents

2023年8月、僕は A.I. 領域で取り組みたい3つの主要テーマとして、マルチモダリティ、オープンソース、生成エージェントを挙げた。「物語の音」デモは、その具体例だ。ユーザーに合わせて変化する、バイリンガルで、対話的で、物語上の制約を持つストーリーテリング体験を、あまりにも見慣れたインターフェースで提供した。つまり WhatsApp である。(ユーザーの音声入力をドラム音に変換したり、カバー画像を生成したりする実験もしたが、まだ本番環境には出していない。)これは Meta AI より前の話で、インターフェースの変遷(Streamlit -> Chainlit -> WhatsApp)を見れば、最後にそこを選んだ理由は、他の選択肢で人がつまずく様子を見たことが半分、もう半分は僕の単なる怠惰だったことがわかる。

念頭に置いていた設計上の制約はこうだ。

  • 物語は「太鼓を持った少年」であること。道中で出会う人たちがいて、そのたびに品物の交換が起きる。全体としてこの筋に従う必要がある。

  • ただし市場の名前や交換される食べ物などはローカライズする。

  • 必要な場面では、ユーザーに入力を促して、常に巻き込もうとする。

  • 始まり方と終わり方がちゃんとしていること。

  • そして、とんでもないユーザー応答にも筋を通して対応すること(Ray-ban Meta のメガネを売ろうというユーザーの提案に返した反応のように)。

デモ:物語の音

The Performing Arts x Tech Lab は2023年8月に始まった。最初のころは、各ターンで適切な場面だけが生成されるようにし、ユーザーの返答を次の展開の生成に組み込みつつ、一定のターン数以内に物語を終わらせるために、かなりのプロンプトエンジニアリングとハックを入れていた。無茶なユーザー入力に対してあまり堅牢ではないので、これは最適とは言いがたい。幸い、必要なのはより高い知能だけだ。

A.I. の進歩をめぐる話は、モデルがより賢く、安く、速くなるのだから、未来を前提に先回りして作る必要がある、という話だった。実際、もうそうなっている。このプロジェクトでは GPT-4 と Kimi を「解雇」し、3月19日に Hugh の推薦を耳にして少し試したあと、文字どおり Claude 3 Opus を使った。最終の一般公開デモは4月5日だった。

注:音声生成は最適化していないので、デモでは完了して再生されるまで約15秒かかる。この遅延は、下で読める電話版では対処している。

なぜこのプロジェクトに意味があるのか?

ストーリーテリングの観点では、これは現代版の「きみならどうする?」型アドベンチャーで、いつだってかなり楽しい。ここで得た学びは、ロールプレイングゲームを作り直す発想にも応用できる。バイリンガルであること(多言語化できない理由はない)は、新しい観客へのアクセスとリーチを広げる。The Esplanade での公開発表で、僕を少し混乱させた質問があった。「もっと多くの物語を扱うにはどれくらい時間がかかるのか」というものだ。今になって思うと、作った本人である僕には、この仕組みをまったく初めて見る人の視点が見えていなかったので、その質問の意味をきちんと理解できていなかった。ただ短く答えるなら、望むだけ多くの物語へ、秒単位、下手をすればミリ秒単位でスケールできる。多くの人が見落としている前提はこうだ。大規模言語モデル(LLM)はすでに非常に強力になっていて、事前学習データとして取り込まれた範囲だけでも、少なくとも相当数の文化に関する知識を内部に抱えている。つまり、ユーザーのプロフィールに合わせて、物語の場所や品物を変えられる。たとえばデモで韓国出身だと名乗ったユーザーには、母親が東大門市場へ行く、という具合だ。A.I. はあなた固有の文脈や語彙を理解できない、というのは神話である。実際にはできる。実務上の問題はたいてい、多くの組織でそうしたデータがデジタル化されていないか、自前のデータセットに合わせて最適化する能力が足りない、ということだ。

アーキテクチャの観点でも、このプロジェクトを見ている。あるコーパスに制約し、ユーザー入力を受け取り、その入力に基づいて応答を生成する、というこの一般的な考え方は、面接準備ボットからカスタマーサポートエージェントまで、かなり幅広い用途に当てはまる「デザインパターン」だ。

ライブデモと展示期間中、観客は僕が用意した電話番号(そう、文字どおり電話番号)にかけることもできた。A.I. Kamini と話すと、彼女が電話越しに物語を語ってくれる。テキストチャットに近い体験だが、領域は音声だけに絞られる。そして最適化のおかげで、音声出力のストリーミングは実はこちらのほうがずっと良い。システムの知能は Claude 3 Opus より低いものの、体験としては本物の電話会話に近い。

次は?

これは僕が中国にいるあいだに GCP 上へデプロイした。全体としては意図した仕事をしてくれたようで、バグ修正は不要だった。あった問題や制約は既知のもので、手をつけなかった理由は、ええと、時間? というわけで、Lab 後に直せそうな領域としては、音声応答を WebSockets でストリーミングして高速化すること、それからユーザーの返答を文字列1つだけだと期待するのではなく、複数の入力を扱えるようにすることがある。このあたりはバックログ行きだ。それとは別に、もし Elevenlabs より良いものを出せる人がいるなら、標準中国語の音声クローン技術がもっと良くなるのを心待ちにしている。

動くコードベースができたので、次は生成エージェントをデプロイして提供したい。適切な局面で LLM を使い、ワークフローを自動化したい。そのパイプラインの出力が、最終的に何らかの行動、つまり世界の状態変化につながるようにする。単純なものなら、自分の動画の文字起こし、翻訳、字幕生成を自動化し、そのままアップロードまで行うこと。もっと高度なものなら、与えられた任意の非構造化データから、使うべきスキーマを判断し、非構造化データから構造化データを出力するエージェントだ。後者は、フィールド録音からデータを抽出したい研究者、コレクションデータを充実させて一連の作業をまるごと自動化したい GLAM 機関(つまり画像に対して豊かな埋め込みを作るだけでなく、動画や手紙などについて文字起こし、テキスト、関連メタデータも生成する)、そして僕が取り組むことになっている試験対策や面接準備ボットにも関係してくると思う。

ソフトウェアの作り方を考え直すという意味でも、A.I. ネイティブな体験がどれほど強力になりうるかという意味でも、僕たちはまだ極端に初期段階にいる。それがどれほど生産性を上げるのか。どれほど拡張可能で、どれほど積み重ね可能になるのか。API 経由で他のソフトウェアとうまく接続できないソリューションを使って仕事をするのは、犯罪にしていいくらいだ(本当に、本当にそれしかない場合を除く)。

今後の更新もお楽しみに。


もともとは PubPub の erniesg.pubpub.org/pub/xlkdc79p で公開したものです。