「LLMとGUIの協力：チャットボットを超えて」
『LLMとGUIの融合：チャットボットを超えて』
OpenAI GPT関数の呼び出しを使用してモバイルアプリを操作する
はじめに
私たちは、自然言語バーの形で対話型AIとグラフィカルユーザーインターフェース（GUI）の相互作用を最適に組み合わせた画期的なユーザーエクスペリエンス（UX）アプローチを紹介します。この自然言語バーは、画面の下部に配置され、ユーザーが単一のエントリーポイントからアプリ全体と対話できるようにします。ユーザーは常に言語と直接操作の選択肢を持ちます。ユーザーはタスクを実行する場所や方法を探す必要がなく、自分の言語で意図を表現できます。同時に、GUIの速度、コンパクトさ、操作性も維持されます。GUIの各画面の定義は、ユーザーのリクエストとともにLarge Language Model（LLM）に送信され、LLMが画面をユーザーの意図に沿ってナビゲートすることができます。このコンセプトを最適化した以前の記事に基づき、Flutterのサンプルアプリを実装しましたので、自分自身で試すことができます。全体のFlutterコードはGitHubで入手できますので、自分のコンテキストでコンセプトを探索することができます。この記事は、製品オーナー、UXデザイナー、モバイル開発者を対象としています。
バックグラウンド
自然言語インターフェースとグラフィカルユーザーインターフェース（GUI）は、ヒューマンユーザーとコンピューターシステムの機能を結びつけます。自然言語は、ヒューマン同士が直接触れないことについてコミュニケーションを取ることを可能にします。一方、指し示しは物理的なアイテムについてのコミュニケーションを可能にします。指し示しは、自然言語の生成と処理よりも、コミュニケーション相手にとって認知的な努力が少なく、混乱の余地も少なくなります。しかし、自然言語は具体的なものから抽象的なもの、過去・現在・未来、メタワールドまであらゆる情報を伝えることができ、すべてにランダムなアクセスを提供します。
ChatGPTの台頭により、NLPの解釈の品質は高いレベルに達し、関数呼び出しを使用することで、誤解釈の少ない自然言語インターフェースをコンピューターシステムに実装することが現実的になりました。LLMコミュニティの現在のトレンドは、チャットインターフェースを主要な対話型ユーザーインターフェースとすることです。このアプローチは、チャットが主要な書かれたヒューマン対ヒューマンの相互作用形式であり、チャット履歴をスクロールするウィンドウに保存することから派生しています。多くの種類の情報は、グラフィカルな表現に適しています。一般的なアプローチとしては、GUI要素をチャット会話に組み込むことです。ただし、これにはチャット履歴が膨大になり、チャット履歴内のGUI要素の状態管理が複雑になるというコストがかかります。また、完全にチャットパラダイムを採用することで、ユーザーに対してメニューベースのインタラクションパスを提供するオプションを失ってしまいます。これに対して、ここで取られたアプローチは、バンキング、ショッピング、旅行など、さまざまな種類のアプリに適用できます。モバイルアプリはフロント画面で最も重要な機能を持っていますが、他のタブやメニューに隠された機能は、ユーザーにとって非常に見つけにくい場合があります。ユーザーが自分の言語でリクエストをすることができる場合、彼らのニーズに最も適した画面に自然に連れて行くことができます。最も重要な機能がフロント画面にある場合、このコア機能のためのオプションの数は、GUI要素の形で提示されることにより、非常に圧倒的になる場合があります。自然言語は、逆にユーザーが主体的に何を望んでいるかを明確に表現できます。両方を組み合わせることで、両アプローチが相互補完され、ユーザーは自分のタスクやサブタスクに最適なオプションを選ぶことができます。
自然言語バー
自然言語バー（NLB）では、ユーザーはアプリから求める内容を入力または音声で記述できます。そのリクエストは、OpenAIによって「関数呼び出し」と呼ばれる技術を使用して、アプリのすべての画面の定義とともにLLMに送信されます。このコンセプトでは、GUI画面をアプリ内の呼び出し可能な関数と見なし、画面上のユーザー入力用のウィジェットをその関数のパラメータと見なします。
銀行アプリを例に、コンセプトを説明します。ユーザーが自然言語でリクエストを発行すると、LLMはアプリのナビゲーションコンポーネントに対して、開くべき画面と設定する値を伝えます。以下の図で説明されています:
以下の画像は、いくつかの対話例を示しています:
LLMによる推測結果を示す次の画像では、ユーザーを助けるために近くの銀行の支店を表示するのが最良の方法であると結論づけられています:
以下の例は、非常に短い表現でもユーザーの要求に繋がることを示しています:
従って、自由なタイピングは非常に迅速な対話モードにもなり得ます。このような短縮表現の正しい解釈は、その意図の曖昧さに依存します。この場合、このリクエストが移動しか意味しないため、アプリにはそれ以外のスクリーンがないため、LLMは曖昧さのない決定を下すことができます。
もう一つの特徴として、対話が履歴を持つため、以前の意図を修正するために入力を続けることができます:
したがって、LLMは複数のメッセージを組み合わせて、目的の機能呼び出しを生成することができます。これは、最初に出発地と目的地のみを指定し、後続のメッセージで日付、時刻、直行便のみ、一等車のみなどの追加要件を絞り込んでいく旅行計画アプリに非常に便利です。
ここをクリックして、サンプルアプリを試してみてください。音声入力はChromeブラウザとAndroidおよびiOSネイティブで動作します。プラットフォームの提供される音声認識が使用されるため、品質がご要求に十分でない場合は改善の余地があります。
仕組み
ユーザーが自然言語バーで質問すると、LLMへのプロンプトにJSONスキーマが追加され、すべての画面とその入力要素の構造と目的を定義します。LLMはユーザーの自然言語表現をこれらの画面定義の1つにマップし、JSONオブジェクトを返します。このため、コードは適用可能な画面をアクティブ化するための「関数呼び出し」を行うことができます。
関数と画面の対応関係は以下の図で説明されています:
完全な関数仕様については、こちらでご確認いただけます。
自然言語バーのFlutter実装は、LangChainエコシステムのDartバージョンであるLangChain Dartに基づいています。すべてのプロンプトエンジニアリングはクライアント側で行われます。画面、ナビゲーションロジック、および関数テンプレートを一緒に保持することが合理的であることが分かりました。実際には、関数テンプレートはナビゲーション構造に組み込まれているため、1対1の関係があります。以下は、クレジットカードの画面をアクティブ化し、移動するためのコードの例です:
DocumentedGoRoute( name: 'creditcard', description: 'Show your credit card and maybe perform an action on it', parameters: [ UIParameter( name: 'limit', description: 'New limit for the card', type: 'integer', ), UIParameter( name: 'action', description: 'Action to perform on the card', enumeration: ['replace', 'cancel'], ), ], pageBuilder: (context, state) { return MaterialPage( fullscreenDialog: true, child: LangBarWrapper( body: CreditCardScreen( label: 'Credit Card', action: ActionOnCard.fromString( state.uri.queryParameters['action']), limit: int.tryParse(state.uri.queryParameters['limit'] ?? '')))); }),トップには、これがアプリのルーティングシステム内の宛先であることが示されています。ハイパーリンクを介してアクティブ化できるルートです。説明部分は、LLMがスクリーンとユーザーの意図を一致させるために使用する部分です。以下のパラメータ（クレジットカードの限度額および実行するアクション）は、スクリーンのフィールドを自然言語で定義しているため、LLMはユーザーの質問からそれらを抽出することができます。次に、pageBuilder-itemがスクリーンのアクティベーション方法を定義し、ディープリンクのクエリパラメータを使用します。これらは、https://langbar-1d3b9.web.app/homeで認識できます。 NLBで’type: ‘credit card limit to 10000”を入力すると、ブラウザのアドレスバーにはhttps://langbar-1d3b9.web.app/creditcard?limit=10000と表示されます。
このアプローチではLangChainエージェントが使用されており、GPTに依存しないため、Llama、Gemini、Falconなどの他のLLMでも利用することができます。さらに、LLMベースのアシスタンスを追加することも簡単です。
履歴パネル
自然言語バーでは、折りたたみ可能な対話履歴パネルを提供しており、ユーザーは前のステートメントを簡単に繰り返すことができます。これにより、チャットインターフェースと同様に、対話履歴が保持されますが、コンパクトで折りたたむことができる形式で表示されるため、画面のスペースを節約し、整理することができます。ユーザーの以前の言語ステートメントは、ユーザーが使用した言語で表示されます。システムの応答は、そのユーザーのステートメント上のハイパーリンクとして組み込まれているため、クリックして対応するスクリーンを再度アクティブ化することができます。
LLMが画面を完全に決定できない場合、システムの応答が明示的に表示されます。この場合、履歴パネルが自動的に展開されます。これは、ユーザーが十分な情報を提供しなかった場合、ユーザーのリクエストがアプリの範囲外の場合、またはエラーが発生した場合に起こる可能性があります。
将来
履歴パネルは、チャットボット形式で顧客サポートやコンテキストに敏感なヘルプを提供するのに適しています。執筆時点では、自社組織が提供する自身のテキストコンテンツに基づいて、チャットボットがユーザーの質問に答えるためのRAG（Retrieval Augmented Generation）技術の活発な議論と進化が行われています。また、ナチュラルランゲージバーは、自然言語を使用したアプリケーションにさらなるパワーと便利さをもたらすための良い出発点です。ご意見をコメントに残してください。私は本当に興味があります。
顧客サポート
あなたのアプリの他に、あなたの組織にはユーザー向けの多くの情報を提供するウェブサイトもあります。おそらくこのウェブサイトには既にチャットボットがあります。おそらくあなたのアプリにもすでにチャットボットがあります。対話履歴パネルは、そのような顧客サポートの会話を行うのにも適しています。
コンテキストに敏感なヘルプ
上記の文脈では、アプリとの言語的対話の履歴を維持しています。将来的には、この履歴シーケンスにGUIとの直接的なユーザーインタラクションのトレースを（見えない形で）追加することができます。その場合、コンテキストに敏感なヘルプは、アプリのヘルプドキュメントのRAG上のユーザーインタラクションの履歴トレースを組み合わせて提供されることになります。ユーザーの質問は、アプリの現在の状態の文脈の中でより具体的に答えられるようになります。
モバイルアプリ向けの静的アシスタンスを超えて
現在の提案はMVPです。これは、アプリの文脈でユーザーの言語的リクエストを解釈するための静的テンプレートを提供しています。この技術により、次のような幅広い改善が可能になります：
- ユーザーが特定の画面上にいるときに質問をする場合、その画面の状態に依存するより具体的な解釈テンプレート（関数）をプロンプトに動的に追加できるかもしれません。例えば、「なぜ送信ボタンがグレーアウト/無効化されているのか？」などです。
- 自然言語バーを使用した関数呼び出しは、クリエイティブなアプリケーションのアシスタントとして使用することができます。例えば、「同じサイズにする」や「再利用可能なコンポーネントにする」といった選択肢に対して手順を実行するためにです。Microsoft Copolit 365はすでに類似の機能を使用しています。本記事で取り上げたアプローチは、このような機能を組織が活用することも可能にします。
システムのあらゆる側面に自然言語でのインタラクションが急速にUIの主要な要素となるでしょう。関数呼び出しを使用する場合、プロンプトにシステムの機能を含める必要がありますが、まもなく市場にはより経済的かつ強力な方法が登場するでしょう。たとえば、OpenAIは最近、関数呼び出しを利用したモデルのファインチューニングを公開し、システムの機能を組み込んだLLMバージョンを作成することができます。これらの機能が非常に広範であっても、プロンプトへの負荷は限定されます。
結論
LLMはGUIベースのアプリと自然言語での対話において素晴らしいエンジンとして使用することができます。ユーザーは意図を入力または発話することで、システムが適切な画面に移動し、適切な値を予め入力することができます。サンプルアプリでは、その感覚を実際に体験することが可能であり、利用可能なソースコードを使用すれば、自分のアプリにこれを迅速に適用することができます（Flutterを使用している場合）。ナチュラルランゲージバーは、Flutterやモバイルアプリに限定されるものではなく、GUIを持つどのアプリにも適用することができます。その最大の強みは、ユーザーが何をするか、それをどこで見つけるか、あるいはアプリの専門用語を知らなくても、ユーザーにアプリの機能全体を単一のアクセスポイントから提供できることです。アプリ開発の観点からは、単に画面の目的とそれらの上の入力ウィジェットの目的を文書化するだけで、ユーザーにこれらすべてを提供することができます。
LinkedInでフォローしてください：LinkedIn
David Miguel Lozanoさんには特別な感謝を申し上げます。彼はLangChain Dartを手伝ってくれました
いくつかの興味深い記事：マルチモーダルダイアログ、GUIとLLMに関するGoogleのブログ、GUIの対話を言語として解釈すること、LLMを活用したアシスタント、言語とGUI、チャットボットとGUI
この記事のすべての画像は、特記がない限り、著者によるものです
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
