Chrome に AI が埋め込まれた音声制御のウェブサイト

導入

Chrome Prompt API の早期プレビュー。

最近、 Chrome 組み込み AI (Prompt API) の早期プレビュー プログラムに招待されました。組み込み AI は、組み込み AI のクロスブラウザ標準となる可能性のあるもののための調査作業です。デバイス上の Gemini Nano を活用するため、Web ブラウザにバンドルされ、LLM 生成はローカル ブラウザ環境で行われます。

利点

良いもの、簡単なもの、速いもの、そして無料なもの。

ブラウザに AI を組み込む必要がある主な理由は 3 つあります。速度、コスト、使いやすさです。ネイティブ ブラウザ API なので、簡単に使用できます。Prompt API へのアクセスは、次の 2 行のコードで簡単に行えます。

 const session = await window.ai.createTextSession(); const result = await session.prompt( "Tyingshoelaces.com are writing a really cool blog about you. What do you think about that then?" );

ブラウザー内で必要な場所に Generative AI の結果を取得するのは、これ以上ないほど簡単になりました。実行時間を確認するために、いくつかのテストを実行しました。単一セッションに制限されていた (同時実行なし) のは残念でしたが、複雑で長いテキスト生成のパフォーマンスは良好でした。

覚えておいてください、遅延もありません。したがって、実行時間は文字通り、ブラウザでリクエストを行ったミリ秒から、コードで結果が使用されるまでの時間です。

 VM975:32 Execution Time 1: 0h 0m 3s 47ms VM975:32 Execution Time 2: 0h 0m 3s 870ms VM975:32 Execution Time 3: 0h 0m 2s 355ms VM975:32 Execution Time 4: 0h 0m 3s 176ms VM975:32 Execution Time 5: 0h 0m 7s 103ms VM975:44 Average Session Execution Time: 0h 0m 3s 910.1999999999998ms );

組み込み AI への 5 つの連鎖リクエストの平均実行時間は、長いテキスト生成プロンプトの完全なリクエストごとに 3 ～ 4 秒です。これを数回実行しました (スクリプトは GitHub リポジトリに含まれています)。デバイスによって異なりますが、API が最適化されると改善されることも期待できます。短い JSON 生成タスクの方がはるかに高速であることがわかりました (200 ～ 400 ミリ秒)。

これは、ほとんどのユースケースで十分受け入れられます。また、LLM のスケールの問題もクラウドソーシングしました。産業規模の API の使用はコストが高いことで有名ですが、すべての LLM リクエストは実験的なブラウザ API を介して処理されます。これは非常に快適で、可能性の世界が広がります。

Chrome ユーザーがモデルをブラウザに埋め込むことで、大規模なサーバーを必要とせずに、使用時に生成 AI モデルがプリロードされた配布メカニズムが実現します。これはWebLLMに似ていますが、モデルがプリロードされ、ブラウザにバンドルされているという大きな利点があります。

つまり、ベンダー固有のモデルを強制的にダウンロードするのではなく、単一のモデルをダウンロードして「インターネット」全体で使用できるということです。

この実験的なブラウザ API の大きな利点は、採用する強力な根拠となることです。高速で、無料 (または消費者が支払う) であり、非常に使いやすいです。

しかし、トレードオフは何でしょうか?

費用

高速かつ無料。でもコストはいくらですか?

API は実験用にのみ用意されており、実稼働での使用には適していません。その結果、出力の多くは、より成熟したホスト型モデルに期待されるほど洗練されていません。サイズの制限とモデルの汎用性により、出力は洗練されていません。

これは、Generative AI API の初期の頃を思い出させるフラストレーションにつながります。信頼性の高い JSON 応答を取得するために、多くのプロンプト エンジニアリングと検証ロジックを使用していることに気付きました。数回のリクエストごとに、API が応答しなくなるようで、応答を混乱させるのは非常に簡単で、その場合、モデルは失敗します。

また、このモデルはブラウザに埋め込まれているため、「プライベート」モデルとしての価値が生まれるという話もあります。一般向けの Web サイトは依然としてサーバーとやり取りしており、平均的なユーザーにとっては、データがローカル環境から出ないことを確信するのは難しいため、これがほとんどのユースケースに関係するかどうかはわかりません。とはいえ、社内での使用やブラウザ経由で動作する非公開システム (企業環境など) の場合、これはボーナス ポイントになる可能性があります。

モデルが小さいために応答が洗練されていないということは、このモデルを使用するタスクについて非常に注意する必要があることを意味します。将来のアーキテクチャでは、生成 AI 実装を最適化して、適切なタスクに適切な重み (したがって、コスト) を使用するようになります。私は、それぞれが特定の出力に使用される、複数の小さく高度に調整されたタスク指向の LLM を想定しています。

そうは言っても、API は本番環境での使用ではなく実験用に明示的に設計されているため、すべては許容されます。

いいもの
-料金
-規模
-スピード
-使いやすさ
-プライベート

悪い人
-品質を犠牲にする
-導入コスト

たとえば、時事問題を詳細に分析したい場合、出力を通知するための大きなコンテキスト ウィンドウと洗練された RAG フローが必要になります。組み込み AI は、ほぼ間違いなく適切なアプローチではありません。Googleはリソースでこのことをほのめかしています。

しかし、私には試してみたい理論がありました。それは突飛で、突飛で、そして非常に楽しい理論でした。そして、マイクロブラウザでホストされる LLM はそれを試すのに最適な場所でした。

新しい考え方

脳ではなくニューロン

しばらく前から、ちょっとかゆいところを掻きたいと思っていました。LLM の使い方が間違っていたらどうなるでしょうか。実際、概念モデルが間違っていたらどうなるでしょうか。

トレーニング データを拡大して、これまで以上に大きなコンテキスト ウィンドウを求めて競争する中で、私たちは生成 AI を垂直方向に拡張しようとしています。より大きく、より強く、より速く、より良く。インターネット全体を差し込むのに十分な大きさのコンテキスト ウィンドウを親切に要求し、その中間のアルゴリズムに、この巨大な湖から必要な情報と出力を正確に選択するよう要求する人々を見ると、私はあごが落ちます。しかもより速く。

私たちは LLM へのすべての入力を API として扱います。テキストが入力されると、魔法が起こり、テキストが出力されます。この中間の魔法を私たちはインテリジェンスと呼んでいます。入力されるテキストが増えるほど、魔法は大きくなり、結果はより良くなります。これが私たちの現在の方向性です。

私たちは間違ったスケールやズームに焦点を当てているのではないか、つまり、認識の誤った解釈をしているのではないかと思わずにはいられません。

思考全般、特に創造的な出力（テキスト生成とはまさにこのことです）は、それほど単純なプロセスではありません。単一のスレッドではありません。これは、新しいモデルですでに確認されています。たとえば、 Claude 3.5 Sonnet システム プロンプトの分析では、LLM 出力の最近の進歩の多くは、アルゴリズム自体ではなく、出力を文脈的に導くインフラストラクチャ、システム、およびチューニングによるものであることがわかります。

私は、小さくて高速な接続を組み合わせてより大きなものを作るというコンセプトを試してみたかったのです。結局、100k のコンテキスト ウィンドウは、1k の 100 倍と同じです。私たちは壮大なものに焦点を当てていますが、鍵となるのは、小さくて正確な詳細を組み合わせてより大きなものを作ることにあるのではないかと思います。これは、知覚力のある機械の「脳」よりも、私の知性の精神的パラダイムによく当てはまります。

これは、モデル全般の相対的な非効率性と法外なコストのため、これまでは不可能でした。メッシュ アーキテクチャでのマイクロトランザクションによって AI システムの品質が向上するという理論に基づき、ChatGPT へのリクエスト数を 100 倍に増やすつもりだとボブに告げる様子を想像してみてください。ボブは OpenAI で働いているとは思いませんが、私たち以外の人間にとっては、それは実現不可能なのです。

ブラウザに埋め込まれた小さくて効率的なモデルでさえ、私の理論を実際に処理できる状態ではありません。十分に高速ではなく、同時リクエスト (同時思考!) もできませんが、正しい方向への一歩であり、クラウド ホスト API がリクエストごとに莫大な料金を請求する時代からは程遠いところまで来ています。機能的なアーキテクチャはわかりませんが、そこに向かう道筋はわかります。

この理論をテストするために、私はプログラミングのグローブをはがし、ブラウザを開いて、1000 のマルチスレッド リクエストを持つメッシュ アーキテクチャへの壮大な旅を始めました。

結果は魔法のようでした。

彼らの脳ではなく、あなたの脳

脳はローカルなので、API もローカルであるべきです。

私は音声が大好きです。キーボードとマウスは私たちの猿の脳の延長になっていると思いますが、それらは人間の装置であるため、より総合的にインターフェイスとしては限界があります。テクノロジーが進歩するにつれて、インターフェイスも進歩し、ある時点で、キーボード、マウス、さらには画面さえも、石油ランプや伝書鳩が私たちにとって時代遅れであるのと同じように、私たちの祖先にとって時代遅れになるでしょう。

したがって、私が構築したいものはすべて音声制御である必要がありました。幸いなことに、そのためのブラウザ API があります。

1. 音声認識 API (音声テキスト変換機能付き)
2. STT API
3. プロンプトAPI
4. インターネット（ブラウザ経由でアクセス）

私が作りたかったのは、ブラウザ制御の音声インタラクション デモでした。ブラウザのコンテキストと入力に基づいてナビゲート、応答、変更を行うインテリジェントな Web サイトです。私の声だけを使用します。キーボードもマウスもありません。「私、私の声、ブラウザ、プロンプト API」。今まで聞いた中で最悪の子供向けストーリーのようです。おそらく、もっとひどいものを書いたことがあるでしょう。

概念的には、 RabbitデバイスやHumane AI ピンに非常に似ています。これらはどちらも野心的なベンチャーですが、共通する問題は、「AI OS」を構築しようとしていることです。ソフトウェアに AI を搭載した新しいインターフェイスを構築することです。この目標は壮大すぎると思います。本質的には、AI を少し加えた新しいインターフェイスをインターネットに構築しようとしているのです。

イノベーションとは反復であり、2024 年のインターネットは遍在し、根本的にブラウザと絡み合っています。人間に優しい AI OS インターフェースを発明しようとすることは、インターネットを再発明しようとすることに似ています。人々はすでに、「携帯電話ではできないが、より優れたことは何か」と尋ねています...

イノベーションには、新しくて未検証の要素と、確固とした実証済みの基盤を融合することが必要です。不安定すぎると、結果は狂気の科学者の領域になってしまいますが、実証済みのものと実験的なものとのバランスをうまく取れば、時には、ほんのたまに、何か特別なことが起こるのです。

ほとんどの LLM 使用例で私たちが間違っていた認知パラダイムは、エンゲージメントを握手として扱うことです。入力 ← LLM → 出力。入力すると、出力されます。しかし、実際の人間のやりとりでは、さまざまな考えや行動に分解できる多次元のプロセスがあります。

「
店員が顧客を迎える ->

【感想】

彼らは何を着ているのか、彼らのスタイルは彼らの購買パターンにどのような影響を与えるのか

彼らの人口統計はどのようなもので、年齢は彼らの購買パターンにどのような影響を与えているのか

性別は購買パターンにどのような影響を与えるか

彼らはどのような気分や社会的シグナルを発しているのか

彼らの選択に影響を与えるような発言は実際にあったのか

[アクション]

おはようございます。お元気ですか

「
顧客が係員に挨拶する ->

【感想】

急いでください、忙しいんです

彼らが私の欲しいものを持っていることを願っています（私の心を読んで！）

返品は受け付けてもらえますか？

[アクション]

おはようございます。靴を探しています。

私たちはコンピューター サイエンスに深く入り込んでしまったため、この分野に関する思考プロセスは二元論的になっています。私たちは入力と出力、真と偽について考えます。真実は、人間のやりとりや思考は複雑で微妙なものであり、二元論に還元したり単純化したりすることはできません。

しかし、私たちにできるのは、この素晴らしい技術を新しい創造的な方法で組み合わせ、出力を均質化し、インターネットをスラリーに変えている障壁を打ち破ることです。インターネットをスラリーに変えること

一つの中の多数、一つの中の多数

Gen AIのインタラクションをマルチスレッドでニュアンス豊かにしましょう

私の実験提案では、組み込み AI を使用して社会的および人間的なやりとりを反映させます。私が筋肉の記憶に持っている例、つまり電子商取引の推奨アルゴリズムの構築を使用しましょう。

 Thread 1: Social Cues, sentiment analysis – How long has it taken for user to interact? – Is their browsing behavior aggressive, slow, calm, controlled – Have they arrived from particular source, or looking for something specific? Thread 2: Behavior Cues, interpretation user input – How have they begun the conversation? A greeting? – What tone are they using? Thread 3: User context, data we have about similar demographics and their preferences – What age group do they belong to? How does this influence preferences? – How do they identify? How does this influence preferences? Thread 4: Site context, data we have how other users are using the site and trends – What are the trending products?

これほど多くのデータ ポイントを解釈する特効薬は存在せず、今後も存在しないでしょう。LLM は、感情分析、エンティティ分類、何でも屋といったプラグインではありません。LLM は、入力を創造的かつ論理的に解釈できる生成アルゴリズムです。スレッド内の各キューは出力ではなく、質問であることに注意してください。

思考と生成 AI に情報を提供するには、答えを提供するよりもはるかに多くの質問をする必要があります。すべてのデータ ポイントを取得する方法と、それを LLM に取り込む方法を構造化する方法に洗練されている必要があります。したがって、行動と社会的手がかりを例に挙げると、次のことを行う必要があります。

1. 感情分析
2. ブラウザの動作とサイトおよび世界平均のデータ分析
3. リクエストから紹介データを抽出する

このデータはすべて、LLM に送られるずっと前に準備され、処理されます。しかし、準備が整えば、次のようなプロンプトで通知することができます。

ユーザー A は、少し怒っている様子を見せる再訪問者です。このことを覚えておいて、返品システムがあることを必ず伝えて安心させてください。[アクション]: 返品ポリシーと人気商品へのリンクを貼ってください。

代替案としては、次のようになります。

「
ユーザー B は、イライラしている様子で、製品 X を直接探しに来ています。製品ページに誘導し、カートに追加することを提案します。[アクション]: ページ X に直接移動し、製品をカートに追加します。

この意味で、LLM は私たちのエージェントであり通訳者ですが、人々が犯している間違いは、「アルゴリズム」が質の高い出力の解決策であると想定していることです。実際のエージェントと同様に、私たちの判断は、私たちが彼らに伝えるデータと手がかりと同じくらい信頼できるだけです。答えを提供するよりも、質問をしてください。

これは不可侵の社会的真実であり、LLM に対する現在の期待があまりにも的外れで、エージェントが多くの人を幻滅の谷に導いている理由でもあります。ゴミを入れればゴミが出てくる。アルゴリズムがどれだけ優れていても関係ありません。

推奨アルゴリズム用の 2 つのグループの手がかりを取得するだけでも、地球上のいくつかのプラットフォームを除くすべてのプラットフォームの能力を超える一連の専門ツールと AI インフラストラクチャに頼る必要があります。しかし、LLM に情報を提供するインフラストラクチャにニュアンス、スレッド、洗練性を反復的に組み込むことで、そこに到達することができます。

そして今、それらはブラウザの中にあります。未来はこれほど近づいたことはありません。

私は、ソーシャル キューと入力を模倣した単純なプロトタイプを作成しました。ユーザー データを少し散りばめて、Prompt API に、考えと行動の組み合わせで私の声に応答するように依頼しました。これは、うまくいくかもしれないというビジョンにすぎません。しかし、Prompt API にきめ細かく詳細な制御された入力を提供することで、インテリジェントで思慮深く、制御されたフィードバックが得られます。これは、マイクロスレッドが動的に学習し、強化し、互いに情報を提供できるメッシュ インフラストラクチャのビジョンです。

まだ機能しません。しかし、いつか機能するかもしれませんし、音声入力による迅速なエンジニアリングは魔法のようです。車で向かう価値のある目的地です。

結論

未来はかつてないほど近づいています。

LLM はまだ初期段階にあり、進歩は予想よりも遅く、AGI (どんな合理的な定義でも) が実現するのは何世代も先になるだろうと私は予測しています。しかし、その道のりの各ステップで、無限のチャンスが生まれます。非常に効率的で、よく考え抜かれ、定義されたインフラストラクチャを構築することで、モデルのサイズやアルゴリズムの品質に関係なく、LLM からの出力の品質が大幅に向上します。

LLM をブラウザに移行することは、LLM をインターネットに移行することとも言えます。安価で、簡単にプレイでき、使用や実験も容易です。人々に、より小さく考え、より効率的に構築し、ソリューションに深みとニュアンスを加えることを強いることは良いことなので、私は「マイクロ」モデルについてあまり心配していません。洗練されているのはツール自体だけでなく、使用方法にあるため、これは大きな前進です。

デモを添付しました。これは、デモ目的にのみ適した探索的 AI に基づいて構築された、概念実証を検討する使い捨てコードです。

そして、それは時々しか機能しません。

しかし、それは素晴らしい未来のビジョンです。

リンク

より多くのリソース。

Githubリポジトリ

初版

送信するときは、この CTA を残してください: