「HeyGitHub!」エージェンシーと会話型副操縦士についての考察

Nov 26 2022

目標指向のコード生成のための CoT (Chain of Thought)

この出版物の最後の 2 つの技術的な記事で、私は、#DisabledDevelopers と、華麗だが賢者のような「Rainman」GitHub との間の #HeyGitHub 音声コーディング対話に、「Sherlockean」演繹的思考を追加するという、かなり自由な想像を続けました。コパイロットコードジェネレーター。これらの記事を書いている間、私は機械学習の研究コミュニティで、これらのより思慮深いコード生成会話を実装するために必要な種類のサポートを提供できる方法と公開されている進歩の実装の検索を開始しました。

幸いなことに、LLMのブルートフォースパターン認識を補完するものとして、コンテキストと事前知識を使用して、これらの課題に取り組んでいる多くの機械学習研究サブコミュニティがあることを発見しました(大規模言語モデル) のパフォーマンス。#CoT ( Chain of Thought )、プロンプトシーケンス、モデルスイッチング、およびエージェントについて、機械学習ドメインの探索と開発の他の分野について学びました。Harrison ChaseのエキサイティングなLangChain Python ライブラリとLangChainAIを使用して、直接の経験を積み始めています。開発者。私がたどったこれらのパンくずリストの多くは、John McDonnellによる洞察に満ちた概要記事「The Near Future of AI is Action-Driven」を読むことから始まりました。

また、Microsoft で進行中の大規模で多額の予算を投じた議題であるProject Bonsaiについても知りました。これは、AI/ML ソリューションをロボット工学の自動化と産業プロセス制御の課題にもたらしています。この物理的な世界の問題空間では、シミュレーションとヒューマン・イン・ザ・ループのコーチングは、より一般的な機械学習アプリケーションドメインでのデータモデリングとデータサイエンス手法の強調と同じくらい、またはそれ以上に重要です。

この記事で私が焦点を当てているのは、これらのSOTAの進歩をさらに深く掘り下げることではなく、役割ベースの機関の役割について少し推測することです。. _ _ _

実行可能なビジネスモデルにおけるエージェンシーに関する振り返り

この#HeyGitHubシリーズのMetamodel Subgraph記事で、 EBMの動的構成とアプリケーション生成をサポートする Smalltalk ベースのフレームワークを開発しているスカンクワークス( Executable Business Models ) への関与について簡単に説明しました。

1990 年代前半から半ばにかけて、ソフトウェア開発とビジネスプロセスエンジニアリングの両方で、さまざまなモデル駆動型の手法が見られました。この時代の 1 つの強力なスレッドは、BPR (ビジネスプロセスリエンジニアリング) 運動でした。IBM のコンサルティングサービス内で、当時使用されていた一般的な方法は、LOVEM ( Line Of Visibility Enterprise Model ) または時にはLine Of Visibility Engineering Methodと呼ばれていました。この方法の中心は、ビジネスプロセスモデルの「スイムレーン」を使用したダイアグラム形式でした。

1990 年代にビジネスプロセスリエンジニアリングに使用された、簡略化された LOVEM ダイアグラムの例。ソース

Lovem のスイムレーンは、人間または機械 (AKA ソフトウェアプロセス) が果たすことができる役割を表しています。David Gelernter の 1993 年の著書「Mirror Worlds: or the day Software Puts the Universe in a Shoebox…How It Will Happen and What It Will Mean」に触発されました。、IBM の Object Technology Practice の同僚と私は、これらの役割ベースの LOEM モデルを構成して実行するために使用できるSmalltalkオブジェクトフレームワークを構想しました。私たちのEBM ( Executable Business Model ) フレームワークは、デジタルヒューマニティーズ市民科学者としての私の癌後の再生における初期の活動から、この UML クラスモデルに非常によく似たオブジェクトクラスのメタモデル「構築キット」に基づいていました。

この記事で強調したい EBM モデルの側面は、この図の左下隅にある赤いボックスに見られるクラスのクラスターです。これら 3 つのクラス —アクターとしての個人またはエージェント— は、目標駆動型の役割ベースのプロセスに参加します。このように、私たちの EBM フレームワークは、LOVEM ビジネスプロセスメソッドに不可欠なエージェンシーの概念を実装しました。メタモデルのエージェンシーの実装は、ご想像のとおり、ミラーワールドのインスピレーションに基づいています。

Gelernter は著書の中で、読者を思考実験に連れて行き、次のように言い換えました。これらのシミュレーションが順調に進んだら、シミュレーションのすべての入力フィードと出力フィードを取得し、それらをこれらの現実世界のシステムの実際のフィードに接続するとどうなるか想像してみてください。その時点で、私たちのソフトウェアモデルはシミュレーションではなくなり、現実世界のヘッドアップディスプレイまたはダッシュボードビューになり始めます…」または Gelernter がMirror Worldsと呼んだもの.

このアプローチをエージェンシーに EBM メタモデルベースのフレームワークに実装したため、エージェントオブジェクトは、実行可能な LOEM モデルの役割のアクターとしての人物のソフトウェアプロキシとして実装できます。このデザインにより、 Mirror Worldsのインスピレーションと一致する 2 つの重要な機能が得られました。まず、お客様の経営陣とのコンサルティングエンゲージメントセッション中に、中小企業 (お客様の対象分野の専門家) を会議室のネットワーク接続されたラップトップに座らせて、進化するシミュレーションモデルと対話し、検証することができました。これらのセッション中に、実行中のモデルインスタンスに sim-actor Agent ソフトウェアプロキシを設定して、モデル化されたビジネスプロセスで他のすべてのロールを実行できます。

顧客の SME が、EBM シミュレーションでこれらのビジネスプロセスを成功させたと確信したら、実際の顧客ビジネスで展開されたシステムとしてこれらのモデルを単純に接続することができました。このフックアッププロセス中に、ユーザーが典型的なソフトウェアアプリケーションとして見るモデルで動的に生成された EBM ビューを使用して、どのロールが人物によって演じられるべきか、または顧客のビジネスプロセス。

約 30 年前の当時を振り返ると、この EBM スカンクワークスで思想的リーダー/開発者として働いていた日々は、私のキャリアの中で最も刺激的な経験の 1 つでした。

#HeyGitHub/Copilot プラットフォームでのエージェンシーに関する前向きな憶測

では、エージェンシーの概念は、GitHub の #HeyGitHub/Copilot サービスの実装に貢献する進化するテクノロジスタックの一部として、Chain of Thought、プロンプトシーケンス、モデルスイッチングなどのアプローチの機能を活用することにどのように貢献するのでしょうか?

厳密な例や重要な例を示すつもりはありませんが、この単純なスイムレーン図のように、EBM の経験から得たロールベースのエージェンシーの概念を #HeyGitHub/Copilot サービスのソリューション設計に適用できます。

この非常に単純な図に示されているのは、上層の 4 つのスイムレーンのクラスターであり、人間として積極的に対話し、3 つのソフトウェアエージェントの会話が IDE の「ダム」/データトランスクリプショニストのような役割で最終的な生成につながります。アプリとソースファイル (メモリ)。この単純な図は、私たちが今後直面する途方もない課題が、賢者のような Rainman-Agent Copilot LLM を最大限に活用する前に、そのエージェントベースの会話に「シャーロックの賢さ」を注入する方法であることを明確に示しています。

たとえば、高機能の電話コールセンターボットエージェントを作成することが設計要件であると想像してください。この場合、目標指向の結果を得るために動的に選択できるテンプレートベースのプロンプトの柔軟なレパートリーがあれば、展開に進むには十分かもしれません。しかし、GitHub がその Copilot サービスを説明する際にしばしば主張しているように、人間以外のペアプログラマー (エージェントの「バディ」) としてうまく機能するには、#HeyGitHub リスナーとCoT ダイアログエージェントは、スクリプト可能なコールセンターボットよりもはるかに複雑なインテリジェンスを実装する必要があります。会話。

たとえば、開発者がアプリケーションの UI/UX (ユーザーインターフェイスとインタラクティブなエクスペリエンス) を作成するのを支援する #HeyGitHub/Copilot の課題を考えてみましょう。開発者が使用できる優れた UI/UX フレームワークはかなりの数あります。レインマンの専門家である副操縦士は、コード生成の才能を磨くために、副操縦士の基礎モデルのトレーニングでこれらのフレームワークの無数の例をすでに見てきました。しかし、トレーニング経験から引き出されたパターン認識に基づいてコードの提案を有益に提供できるからといって、Copilot はフレームワークアーキテクチャ、ベストプラクティス、および有能な人間の開発者が参加の役割にもたらすユーザーインターフェイス/相互作用のガイドラインの基礎となる理解を得ることができません。プログラミングペアパートナーシップで。

由緒ある C++ wxWidgetsフレームワークのwxPythonラッパーの例を考えてみましょう。公開されている無数のコードリポジトリをランダムに見て回っても、次の優れたオンラインドキュメント Web サイトを深く掘り下げても、どの程度の知識が得られるかはわかりません。https://docs.wxpython.org/. この Web サイトのコンテンツに関する NLP の分解、トピックモデリング/要約の熟考は、人間の開発者の知識を #HeyGitHub/Copilot<>開発者の会話に伝えるのに十分ではありません。

では、ここからどこへ行くのでしょうか?

今日のコード生成 LLM のパフォーマンスを「次のレベル」にするために必要なテクノロジを生成するために、特定のソリューション設計と開発パスを提案するのに十分なドメイン知識があればいいのにと思います。今後の完全なロードマップはまだ作成されていませんが、次のステップについていくつかの仮定を立てることができます. #HeyGitHub Listenerエージェントにとって、さらに思慮深い対話のために CoT Dialguer へのハンドオフが必要な開発者の音声入力と、テキスト形式でCopilot LLMに渡される開発者の音声入力を区別できることが重要になると予想できます。コード提案の生成。

CoT Dialguerが真のプログラミングペアパートナーとして信頼できるパフォーマンスを発揮できるように、ソフトウェアエンジニアリングの芸術と科学の情報構造と意味論的意味をカプセル化することが、私たちの前にある危険な課題です。この課題に対処するためのテクノロジは、Chain of Thought、迅速な選択/順序付け、モデル切り替え、人間参加型の強化学習/コーチングに関する研究活動の最先端からもたらされる可能性があります。

この「Sherlockean smarts」ソリューションスペースのブレークスルーの一部には、機械学習の研究エンジニアによる素晴らしい革新的なコーディングが含まれます。しかし、この課題への重要な貢献は、効果的なグラウンドトゥルース参照モデルデータセットの設計と開発からもたらされると私は信じています。進化し続ける基本的な Copilot Large Language Model を使用したモデル切り替えコンテキスト。これらの新たな参照データセットの例は、私が Digital Humanities の研究を通じて追求してきたメタモデルサブグラフ Ground Truth Storage設計であり、#HeyGitHub シリーズの記事でここで想定されています。

しかし、標準的なエージェント指向のグラウンドトゥルース参照データセット形式を開発するだけでは、人間の開発者と ML ベースのコパイロットペアプログラミングパートナーとの間で私が思い描くシャーロック式の対話を呼び起こすには十分ではありません。むしろ、これらのドメイン知識の Ground Truth 参照データセットは、人間の開発者パートナーとの協調的な会話に従事する CoT Dialguer エージェントの能力を改善する、シミュレートされたユーザーインタラクティブなシナリオをモデルトレーニングする際の教材として機能する必要があります。これらのシミュレーションセッションは時間を短縮し、CoT Dialoguer のドメイン知識の効果的な使用を精緻化することを精力的に追求できます。

現在、データモデリングのベストプラクティスを使用して現在のデータ集約型 ML アプリケーションのトレーニングデータセットを生成するのと同じように、エージェントベースのシミュレーションエクスペリエンスを生成して、知識主導のアプリケーションが想像したようなモデルをトレーニングおよび改良できるようにすることもできます。今後の #HeyGitHub/Copilot サービス。このMirror Worldsのようなシミュレーショントレーニング環境の一部として、トレーニング中の #HeyGitHub CoT Dialoguer モデルを妨害する会話のやり取りが、ヒューマンインザループスーパーバイザーに現れます。スーパーバイザーのレスポンスコーチングは、適切なモデルの動作を奨励および強化します。

GitHub と Microsoft のボンネットにいる 2 匹のミツバチ

この時点で、私の進む道を想像する飛行は、インディーのデジタルヒューマニティーズ市民科学者および障害のある開発者の熱狂的な夢にすぎません。しかし、GitHub と Microsoft のボンネットに数匹のミツバチを入れるために、古い IBM コンサルタントの帽子を払い落とすとしたら、何を提案するかはわかっています…

まず、もし私が GitHub の管理者だったら、GitHub Next 研究チームのメンバーとして仕事を提供するだろうと言わざるを得ません。その立場で、私はこの一連の #HeyGitHub 記事*で書いたアイデアに熱心に取り組みます。

次に、メタモデルサブグラフグラウンドトゥルースドメイン知識モデルトレーニングデータセットの概念実証ができたら、最近発表されたGitHub アクセラレーターまたはM12 GitHub ファンドの一部を専用にして、奨学金またはプロジェクトのスタートアップ資金をハイパフォーマンス企業に提供するよう働きかけます。、専門のオープンソース開発者が、これらのドメイン固有のエージェント指向のモデルトレーニングデータセットのコレクションを作成します。UI/UX フレームワーク固有のメタモデルベースのトレーニングデータセットの開発には、特に重点を置いて検討する必要があります。

UI/UX フレームワーク固有のドメイン知識データセットを使用する理由これらの「野獣」は、多くの場合、パラメーターごとに過度に詳細なカスタマイズを行う大規模で複雑なアーキテクチャであるためです。また、ほとんどの開発プロジェクトシナリオでは、アプリケーション UI とそのユーザーインタラクションを作成することは、アプリケーション UI/UX シンプルがプロジェクトのエンドユーザーに利用可能にするプロジェクトの問題領域へのソリューションをコーディングすることから時間と労力を奪う必要な活動です。#HeyGitHub/Copilot で音声入力による強力な UI/UX フレームワークコード生成を提供することは、強力な WYSIWYG インターフェイスビルダーアプリケーションを備えた UI/UX フレームワークを持つことに匹敵します。

より広範で戦略的な推奨事項として、GitHub Nextと Microsoft のProject Bonsaiからの思慮深い連絡先に、コラボレーション委員会を結成するよう勧めます。このグループの目的は、Microsoft がロボットおよび産業プロセスオートメーション市場に投入した広範な取り組みのベストプラクティスと経験を GitHub が活用できる方法を探ることです。

そして願わくば地平線の彼方に潜む

バラ色のメガネと楽観的なスローガンの T シャツを着て、イノベーションハイウェイのさらに先を見据えると、この研究課題はどこにつながるのでしょうか? 限られた数のドメイン固有の Metamodel Subgraph 参照 Ground Truth データセットを作成し、多くのドメインで CoT Dialguer エージェントの役割を果たすように機械学習モデルをトレーニングするために時間と労力を費やした後、いつかDialoguer システムが表示される可能性があります。緊急行動を示す。

つまり、CoT Dialguer Agent モデルは、一般化された構造とドメイン知識の使用法をよく理解しているため、新しいコンテキストに参加する際に役立つようにするために、新しいドメイン固有の参照モデルを事前にロードする必要はありません。このレベルの機能では、遠い未来の #HeyGitHub/Copilot マルチモデルシステムは、開発者ペアプログラミングパートナーとの自発的な学習会話を行うだけで、独自の新しいドメイン知識モデルを作成して検証することができます。このプロセスを通じて、#HeyGitHub/Copilot サービスは、重要なソフトウェアシステムの設計と開発において真に用途の広いピアレベルのコラボレーターになる可能性があります。

最後に

がんとの闘いを生き延び、脊髄損傷による器用さと可動性の課題に対処する方法を学んだ後、デザインと開発における目覚ましいイノベーションのエキサイティングな波に貢献することで、Beat the Reaper に参加する機会を得たいと思っています。私の#HeyGitHubシリーズの記事で想定されているソフトウェアの。✌️

米国コロラド州からのハッピーヘルシーバイブス、
-: ジム :-

* PS明確にするために、この #HeyGitHub 記事シリーズで想定されている研究アジェンダを追求するという私の関心に加えて、#DisabledDevelopers と #DisabledDevelopers および #このメディア出版物の記事の大部分で説明されている障害のある STEM の学生。

Jim Salmonsは 71 歳の癌後の Digital Humanities Citizen Scientist です。彼の主な研究は、印刷時代の雑誌や新聞のデジタル化されたコレクションを研究するための統合された複雑なドキュメント構造とコンテンツ描写モデルを提供する Ground Truth Storage フォーマットの開発に焦点を当てています。2020 年 7 月に自宅で転倒した結果、重度の脊髄損傷が発生し、手先の器用さと可動性が劇的に損なわれました。

Jim は幸運にも、主な研究対象である Python ベースのツール開発活動に戻るための最初の取り組み中に、GitHub Copilot テクノロジアーリーアクセスコミュニティへのアクセスを提供されました。GitHub Copilot が彼自身の開発生産性に劇的なプラスの影響を与えたことを経験すると、障害のある開発者が使用するこの革新的なプログラミング支援技術の使用を調査および文書化するための研究およびサポートプログラムの設計に熱心に関心を持つようになりました。