2 このプロジェクトが作成された理由
2. このプロジェクトが作成された理由
❓ 解決すべき問題
現実に直面しなければなりません:かなりの期間、ユーザーとどのように対話するかは、エンドサイド開発者(または企業)によって決定されます。既存のビジネスモデルのほとんどでは、ユーザーの対話への参加が製品価値と収益性の基盤であり、アクティブユーザー数や広告収入などが含まれます。誰もエンドサイドに十分な権限を開くことを強制できず、人間の介入なしにAIが完全に操作を実行することを許可することはできません。
AIが十分に賢ければ、人間は実際に毎回ホームページから始める必要はありません。したがって、人間と機械の対話が次世代の主要な対話インターフェースになることは、ほぼコンセンサスになっていることがわかります。
しかし、自然言語の表現力の自然な欠陥は、元々はよく設計された対話によって補償されることを期待していましたが、今ではダイアログボックスに置き換えられています。ダイアログボックスの限界がすぐに明らかになります:
(1) カーソルの指示機能の喪失
対話形式は「画面+フォーカス操作」モードから自然言語モードへと移行しています。従来のフォーカス操作は、キーボード、マウス、タッチスクリーンを通じて実現され、正確な指示を提供します。自然言語対話は以下の影響をもたらします:
-
指示の精度の喪失:表現と理解の難しさが増し、曖昧さが増大します。これを「カーソル損失効果」と呼びます。
例えば、ユーザーが「これを削除」と言う場合、システムは「これ」がどの特定のオブジェクトを指しているかを判断するのが困難ですが、従来のインターフェースはマウスクリックで正確に位置を特定できます。
-
情報表現効率の制限:純粋な音声情報表現は非効率であり、音声入力の利点は主に逐語表現シナリオに反映されます。
例えば、サムネイルを拡大したい場合、「拡大」と言うか「拡大」と入力する必要があるかもしれませんが、従来の対話は1回のクリックだけで済みます。
-
言語表現能力への高い要求:自然言語対話は、ユーザーの言語表現能力に高い要求を課し、人間と機械の対話に困難をもたらします。
例えば、言語表現が苦手なユーザーは、自分のニーズを正確に説明できず、システムの理解にずれが生じる可能性がありますが、従来のインターフェースはボタンやメニューなどの視覚要素を通じて表現のハードルを下げています。
-
情報読み取り効率の低さ:テキストストリームの読み取りと音声の読み取りは、構造化された情報の読み取りほど効率的ではありません。
例えば、システムが音声で長いデータリストを放送する場合、ユーザーは目標情報を見つけるためにリスト全体を聞く必要がありますが、従来のインターフェースは、テーブルやカードなどの構造化された形式を通じて、ユーザーが迅速にスキャンして位置を特定できるようにします。
-
対話ターンに制約される:対話ターンに制約される対話は、迅速な連続操作には適していません。
例えば、ユーザーが複数の操作を連続して実行する必要がある場合、次のステップに進む前に各対話ターンの完了を待つ必要がありますが、従来のインターフェースは、複数のボタンを迅速に連続してクリックしてバッチ操作を完了できます。
(2) 情報フラグメンテーションのオーバーフロー
会話のストリーミング情報構造は組織化に欠けており、ページ単位で情報アーキテクチャを整理し、視覚的なグラフィカルインターフェースを通じて視覚的に親しみやすい情報提示階層を構築する従来のソフトウェアとは異なります。これは以下の派生問題につながります:
-
異なる情報の分離の困難:単一会話内の連続的な情報フローは、異なるトピック間の境界を区別することを困難にし、複数の完全に無関係なトピックが混在する可能性があります。
例えば、ユーザーが会話で最初に「明日の天気を確認して」と尋ね、次に「そのプロジェクトの進捗はどうですか」と尋ね、その後「いくつかの良い本を推薦してください」と尋ねます。これらの完全に無関係なトピックが混在し、迅速に位置を特定して確認することが困難になります。
-
ゾンビセッションの爆発:情報がセッションを通じて人為的に分離されると、セッション内の情報はセッションを単位とするブラックボックスに折りたたまれ、最終的に視認性の低さによりゾンビセッションになります。
例えば、ユーザーは「仕事関連」「学習ノート」「買い物リスト」などの複数のセッションを作成しますが、各セッションには散在するメッセージしかありません。時間が経つと、これらのセッションは忘れられ、効果的に利用できないゾンビセッションになります。
-
多次元的に管理できない:無数のセッションに散在する類似の情報は、特定の次元に沿って情報を管理できないため、整理できません。
例えば、ユーザーは異なるセッションで「Pythonチュートリアル」「JavaScriptチュートリアル」「Reactチュートリアル」などの学習リソースについて尋ねましたが、「学習リソース」次元に沿って統一して表示および管理することはできず、セッションごとに検索することしかできません。
-
指示可能なオブジェクトの欠如:情報はテキスト情報に溶解し、何かを参照する必要がある場合、参照する特定のオブジェクトがありません。
例えば、ユーザーが「その提案を再度最適化する」と言う場合、「その提案」は独立した識別と構造のないテキストストリーム内の段落にすぎず、システムが正確に位置を特定して操作することが困難になります。
(3) 異なる端末間の人間-機械インターフェースの大きな違い
将来、より多くの端末デバイスがエージェントによって駆動され、画面、カメラ、マイク、スピーカーなどのデバイスを通じて人間の知覚に対応し、人間と機械の対話を完了します。しかし、異なる端末は物理的特性に固有の違いがあり、同じ対話モードを強制的に使用することは不可能です。これはAI統合に困難をもたらします:
-
メディアの切断:AIによってフィードバックされた情報構造が端末に対して不親切な場合、情報表現の損失や混乱を必然的に引き起こします。逆に、端末によって提供される情報構造は必ずしもAIに親切ではありません。
例えば、元々大画面ダッシュボード用に設計された複雑なデータ可視化が、スマートスピーカーで音声によって直接「読み上げられる」と、ユーザーが全体的な認知を確立することがほぼ不可能になります。逆に、スマートウォッチ上の単一行のプロンプト情報は、AIが表現することを期待する複雑な意味論を完全に伝えることは困難です。
-
AIが端末特性を十分に掌握していない:表現力を高めるために、人間は複雑なコンテキストで、または複雑な論理を表現する際に、複数のソフトウェアと端末を使用してデモンストレーションを行うことがよくあります。AIは「話す」ことしか知らないようです。
例えば、製品マネージャーが提案を提示する際、スライドを表示し、ホワイトボードに構造図を描き、デモページでクリック操作を行います。一方、現在のAIは、長いテキストまたは音声の文字列で説明することしかできず、投影、注釈、アニメーションなどの端末機能を使用して表現を強化することが困難です。
-
仮想と現実の間のギャップ:現在AIが使用しているコンテキスト(またはコンテキスト)は、事前設定された記憶された知識に基づいており、実際のシナリオでのコンテキストはしばしば動的で、現実の環境に関連しています。
例えば、AIはユーザーの個人プロファイルと履歴会話を「覚える」ことができますが、ユーザーが会議室に座っている、紙の文書のどのページをめくっている、またはどの物理的な表示ボードを指しているかをリアルタイムで知覚することは困難であり、したがって、実際のアシスタントのように現場の状況に基づいて自然な指示や補足を行うことができません。
💡 改善のアイデアと目標
以前、製品マネージャーの主な仕事は、学習しやすく使いやすいインターフェースと操作フローを設計することでした。AIサポートにより、ユーザーはもはやソフトウェア対話インターフェースと操作ロジックを学習する必要がありません。AIは、ユーザーの質問と指示に基づいて、ユーザーに必要な情報のみを提供する能力を持ち、ユーザーは最小限の介入操作のみを必要とします。
しかし、ユーザー自身が介入する限り、対話の親しみやすさ、正確性、効率性に問題があります。Interactive Conversation Protocolは、人間と機械の接触点で正確に役割を果たします:
自然言語の表現力の向上(人間 → AI)
ここでの表現力の向上は、自然言語の向上を指します。上記で言及された問題(カーソル指示の喪失、情報フラグメンテーションのオーバーフロー、異なる端末間の人間-機械インターフェースの違い)を補償するため。少なくとも元の自然言語に対して以下の処理を行うことができます:
-
表現された情報のマーキング:特別な処理が必要な情報をマークします。ここで言及された特別な処理には、構造化情報の使用、インターフェースの組み立て、補助プログラムの実行などが含まれます。テキストの一部に点を囲んでメモを取ることを想像できます。マーキング形式に関しては、Markdownを参照し、特殊文字を使用して特定の意味を表し、補助機能の説明とトリガーはJava開発の注釈原理を参照します。この方法により、元の説明内容に話し方のトーンを補足し、何が重要か、何が特別な提示形式を必要とするか、何が前操作を必要とするか(認証が自分だけに見えるなど)を指摘できます。
例えば、ユーザーが「今週のTo-doを整理して」と言う場合、文内で日付、優先順位、責任者を軽くマークすると、AIは説明テキストを返すだけでなく、チェック可能なTo-doリストを直接生成できます。
-
コンテキスト情報の追加:話者の実際の状況を再現するために、必要な仮想情報と現実世界の環境を叙述情報に補足します。従来の対話インターフェースは、インターフェースにオプションのコンテキスト情報を事前設定して、ユーザーの簡単なクリックから正確な意図をキャプチャすることがよくありますが、自然言語はコンテキストを完全に記述するために長いテキストを整理する必要があります。プロトコルに時間、場所、デバイス状態、参加者IDなどのコンテキスト情報を補足することで、AIは「ここで今」の実際の意味をより正確に理解できます。
例えば、ユーザーが「近くでMarryが好きなレストランを予約する」とだけ言う場合、位置、予算の好み、履歴注文をコンテキスト情報として補足します。コンテキスト情報の応用は非常に広範囲にわたり、後でシナリオについて具体的に議論します。
-
標準中間言語への翻訳:元の情報を処理した後(注釈とコンテキスト情報を追加)、完全かつ正確な解釈を可能にするために、合意されたデータ識別システムが必要です。すべての端末の表現力に適応するために、この識別システムはJSON仕様に基づいて構築でき、合意されたパラメータテーブルと構造を提供します。このようにして、さまざまな受信端のAIは、利用可能なすべての端末を動員して最大の表現力を示し、表現者の完全な意味を再現できます。
例えば、「この文章をプロジェクトグループに送信し、今日の仕事終了前に全員に確認させる」という文は、最終的にメッセージ本文、受信者リスト、期限、確認ボタン設定を含む標準JSON構造に翻訳されます。チャットツール、Webバックエンド、またはモバイルアプリは、それぞれ適応したインターフェースをそれに応じてレンダリングできます。
オンデマンドカスタマイズインターフェース(AI → 人間)
私たちの前提は、人々が「話す」ことでAIと対話することを好むことです。これは人間のコミュニケーションに最も近い方法です。したがって、人々はクリックして必要な機能インターフェースを見つけることがますます面倒になると感じるでしょう。人々が必要とする情報もインターフェースも、ユーザーの「目」に直接プッシュされるべきです。この効果を達成するために、受信端は一定の解釈能力を持つ必要があります:
-
中間言語の解釈:中間言語がJSON形式であるため、すべての受信端は完全な意味を読み取ることができ、少なくとも情報受信での切断を回避できます。
例えば、「経費報告書レビューリクエスト」の同じ中間言語データは、デスクトップではテーブルと添付ファイルプレビュー付きの大画面インターフェースとしてレンダリングでき、モバイルでは主要情報と2つのボタン(承認/拒否)のみを表示でき、スマートスピーカーは要約を読み上げて音声確認を待つことができます。
-
メッセージインターフェースの動的構築:完全なコンテキストと注釈に基づいて、最も対話に親しみやすいソリューションを選択し、情報階層を持つ対話型インターフェースを動的に組み立てます(もちろん、端末と互換性のない注釈も無視できます)。このインターフェースは必ずしも読み取り専用のマルチモーダル情報ではなく、対話型のミニプログラム本体でもあります。
例えば、AIが「これは情報収集です」と理解すると、ユーザーにプレーンテキストで質問に1つずつ答えさせるのではなく、チャットインターフェースに自動的に記入可能な小さなフォームカードを挿入できます。
-
コンテキストの再現:コンテキスト内の一部の要素を示すまたは制御する能力を持ちます。これは通常、複数のアプリケーションまたは端末デバイスを動員する必要があります。一人称視点は眼鏡のカメラを通じて再現でき、三人称視点はコンパニオンドローンによって提供でき、投影またはVRアイコンは物理オブジェクト上の特定の位置を指すことができることがわかっています...など。
例えば、リモートデバイスメンテナンスシナリオでは、AIはエンジニアのAR視野で分解する必要があるネジの位置を強調表示しながら、大画面に回路図とステップ指示を同時に表示し、「コンテキスト」を複数の端末間で共同で再現できます。
❗️❗️ 特別な注意:中間言語は本当に必要ですか?
多くの人々は、中間言語が実際には必要ないと考えています。一般的に2つの理由があります:
(1) 長期的には、AGIには「行間を読む」能力があり、ユーザーの暗黙の意図を理解します。AIがよりよく理解するために、自然言語を人為的に不必要に処理する必要はありません。
(2) 人間に親しみやすい対話インターフェースの設計も、将来のAGIの義務であり、AIは各対話に対して実行可能な対話インターフェースを具体的に設計する可能性さえあります。したがって、AIの言葉を何らかの中間言語に翻訳することはさらに不要です。
それでも、最終的にiFayシステムでICPプロトコルを設計しました。以下の3つの懸念があり、短期的には解決が困難であると信じているため、注釈スタイルの中間言語を設計することを選択しました:
(1) AIの環境に対する制御力はそれほど大きくない
一般的に、人々は人間-AI対話を人とアシスタントの間のコミュニケーションに例えます。賢いアシスタントは、良いコミュニケーション効果を達成するために環境条件を積極的に調整する、たとえば光が不十分なときにライトをオンにする、文書の重要な部分にマークを付けると考えます。しかし、アシスタントの権限と能力は常にすべてを行うことを許可するわけではありません。たとえば、建物が突然停電し、プレゼンテーションスライドを再生できない場合などです。
したがって、より慎重なアプローチは、すべての必要な資料を準備し、プレゼンテーションを適応させる(または不動産管理者に任せる)ことです。これは、すべての資料を持参してクライアントに会うようなものです。クライアントが会議室を持っているか、プレゼンテーションスライドを再生できるか、または紙のレポートを閲覧する必要があるかは、相手が決定します。
(2) AIと人間はそれほど親密ではない可能性がある
AIの環境に対する制御が限られているため、AIは多くの場合、実際には人間の意味を本当に理解していません。スライド上のデータセットを指してAIに尋ねるようなものです:「このデータは何を意味しますか?」実際、AIはあなたがどこを指しているか知りません。理想的には、モーションキャプチャ機器が必要で、AIにこの情報を伝える必要があります。別のシナリオを想像することもできます:上司が非公開会議を開き、終了後、アシスタントに「会議決議をフォローアップしてください」と言います。この時点で、アシスタントは実際には第一級の情報を取得していませんが、会議記録者によって整理された会議議事録を取得しています。会議議事録は中間言語によって処理された情報に似ています。
したがって、多くの場合、人間によって明示的に提供された情報は判断には不十分です。この時点で、コンテキスト情報を補足する必要がありますが、これは特定のAIの権限ではありません。
(3) 万能のAGIがまったく存在しない可能性がある
将来のAIは、人間社会と同じ労働分割の問題に必ず遭遇します。個々のAI(iFayに類似)と社会的公共機能を持つAI(coFayに類似)が存在します。それらの間には必然的に権限の境界が生じます。
将来のAIエコシステムにおいて、AIの責任が提供された(システム入力)情報を処理することのみであるか、またはAIがより多くの「含意」を積極的に収集する責任も負うべきかを予測することは困難です。
したがって、慎重なアプローチを選択します。AIは既知の情報のみを処理すると仮定します。この情報は毎回処理フローを通過し、この処理アクションは、ソフトウェア、端末デバイス、またはAIによって完了される可能性があります。これは、ブラウザを使用してWebサイトにアクセスする場合など、現在のエンジニアリング技術ソリューションでも非常に成熟した実践であり、サーバーはユーザーのコンテキスト情報の一部を学習できます。
🌟 ビジョン
ICP(Interactive Conversation Protocol)は、人間と機械の間の中間言語形態を構築し、人間と機械の間の効率的で正確で豊富な双方向通信を実現することを目指しています:
人間 → 機械:表現された意味とコンテキストの包括的な複製
- 人間が表現する意味とコンテキストを可能な限り包括的に捕捉する
- 自然言語と相互作用の意図を、機械が正確に理解できる構造化要素に変換する
- 相互作用の精度とコンテキスト情報を保持する
機械 → 人間:相互作用方法の動的組み立て
- 概念注釈を現在のコンテキストと統合する
- デバイス機能とユーザーの好みに基づいて、最も適切な相互作用方法を動的に組み立てる
- マルチ知覚情報提示(テキスト、音声、視覚、触覚、嗅覚など)をサポートする
