«HeyGitHub!», мысли об агентстве и разговорном втором пилоте

В моих последних двух более технических статьях для этой публикации я позволил себе довольно безудержно представить себе добавление «шерлоковского» дедуктивного мышления в диалог голосового кодирования #HeyGitHub между #DisabledDevelopers и блестящим, но похожим на ученого «Человеком дождя» GitHub. Генератор кода второго пилота. Во время написания этих статей я начал поиск методов и общедоступных реализаций достижений в исследовательском сообществе по машинному обучению, которые могли бы обеспечить поддержку, необходимую для реализации этих более вдумчивых диалогов по генерации кода.

К счастью, я обнаружил, что существует ряд исследовательских подсообществ по машинному обучению, работающих над этими проблемами, чтобы поддерживать более «человеческие» процессы мышления, используя контекст и предшествующие знания в качестве дополнения к распознаванию паттернов методом грубой силы LLM ( Большая языковая модель ) производительность. Я узнал о #CoT ( Цепь мыслей ), быстром секвенировании , переключении моделей и агентах , а также о других областях исследований и разработок в области машинного обучения. Я начинаю получать непосредственный опыт использования захватывающей библиотеки Python LangChain от Harrison Chase и LangChainAI.Разработчики. Многие из этих «хлебных крошек» , по которым я следовал, начались с прочтения проницательной обзорной статьи Джона Макдоннелла «Ближайшее будущее ИИ — это действие» .

Я также узнал о масштабной программе Microsoft с чрезмерным финансированием — Project Bonsai , которая предлагает решения AI/ML для решения задач автоматизации робототехники и управления промышленными процессами. В этом пространстве проблем физического мира моделирование и обучение человека в цикле столь же важны, если не более, как акцент на моделировании данных и методах науки о данных в более общей прикладной области машинного обучения.

Моя цель в этой статье не в том, чтобы углубиться в эти достижения SOTA, а в том, чтобы немного порассуждать о роли ролевого агентства , поскольку оно может быть применено к платформе #HeyGitHub/Copilot для поддержки разработки программного обеспечения не только #DisabledDevelopers и #DisabledSTEMstudents , но и всеми потенциальными разработчиками, использующими #HeyGitHub/Copilot в качестве множителя продуктивности разработки.

Возвратное размышление об агентстве в исполняемых бизнес-моделях

В моей статье Metamodel Subgraph в этой серии #HeyGitHub я дал краткий обзор своего участия в skunkworks, разрабатывающем фреймворк на основе Smalltalk, поддерживающий динамическую композицию и генерацию приложений EBM , исполняемых бизнес-моделей .

В начале-середине 1990-х годов появился ряд методов, основанных на моделях, как для разработки программного обеспечения, так и для проектирования бизнес-процессов. Одной из сильных сторон того времени было движение BPR , или реинжиниринга бизнес-процессов . В консультационных службах IBM в то время использовался популярный метод, который назывался LOVEM , Line Of Visibility Enterprise Model или иногда Line Of Visibility Engineering Method . Центральным элементом этого метода был формат диаграммы с использованием «плавательных дорожек» для моделей бизнес-процессов.

Плавательные дорожки LOVEM представляли роли, которые могли играть как люди, так и машины (программные процессы AKA). Вдохновленный книгой Дэвида Гелернтера 1993 года «Зеркальные миры: или Программное обеспечение дня помещает Вселенную в коробку из-под обуви… Как это произойдет и что это будет означать». , мои коллеги и я из IBM Object Technology Practice придумали объектную структуру Smalltalk , которую можно было бы использовать для составления и выполнения этих ролевых моделей LOVEM. Наша EBM , исполняемая бизнес-модель , фреймворк была основана на «конструкторе» метамодели классов объектов, который был очень похож на эту модель класса UML из моей ранней деятельности в моем перерождении после рака в качестве гражданского ученого в области цифровых гуманитарных наук:

Аспект нашей модели EBM, который я хочу выделить в этой статье, — это кластер классов, показанный в красной рамке в нижнем левом углу этой диаграммы. Эти три класса — Лица или Агенты как акторы — участвуют в процессах, ориентированных на достижение цели и на основе ролей . Таким образом, наша структура EBM реализовала концепцию Агентства, необходимую для метода бизнес-процессов LOVEM. Реализация Агентства в нашей метамодели, как и следовало ожидать, была вдохновлена ​​нашим Зеркальным миром .

В своей книге Гелернтер познакомил читателей с мысленным экспериментом, который, перефразируя здесь, сказал: «Представьте, если бы мы построили подробные программные симуляции наших сложных систем, работающих в реальном мире. Как только мы запустим эти симуляции, представьте, что произойдет, если мы возьмем все входные и выходные каналы наших симуляций и подключим их к реальным каналам этих систем реального мира. В этот момент наши программные модели перестали бы быть симуляциями и стали бы дисплеями на лобовом стекле или панелями мониторинга реального мира…» или того, что Гелернтер называл « Зеркальными мирами» .

Мы реализовали этот подход к Агентству в нашей платформе, основанной на метамодели EBM, чтобы объекты Агента могли быть реализованы как программные прокси для Людей как Актеров Ролей в исполняемых моделях LOVEM. Этот дизайн дал нам две важные особенности, соответствующие нашему вдохновению от Mirror Worlds . Во-первых, во время консультационных сессий с руководителями клиентов мы могли бы пригласить SME, экспертов в предметной области клиентов, сидеть за подключенными к сети ноутбуками в конференц-зале, чтобы взаимодействовать и проверять наши развивающиеся имитационные модели. Во время этих сеансов мы могли заполнить экземпляр исполняемой модели программными прокси-агентами sim-actor Agent для выполнения всех остальных ролей в смоделированном бизнес-процессе.

Как только малые и средние предприятия клиентов убедились, что мы отладили эти бизнес-процессы в моделировании EBM, мы могли — в духе «Зеркальных миров» — просто подключить эти модели как развернутую систему к реальному бизнесу клиента. Во время этого процесса подключения мы определяли, какие Роли должны играть Лица — используя динамически генерируемые EBM-представления модели, воспринимаемой пользователями как типичные программные приложения, — или Роли, которые должны играть программные прокси-агенты-акторы в клиентских системах. деловые процессы.

Размышляя о том времени почти тридцать лет назад, я могу сказать, что дни, проведенные в качестве идейного вдохновителя/разработчика в этом чудачестве EBM, были одними из самых волнующих событий в моей карьере.

Прогнозное предположение об агентстве на платформе #HeyGitHub/Copilot

Итак, как концепция Агентства может помочь нам использовать возможности таких подходов, как цепочка мыслей, быстрое определение последовательности и переключение моделей, как часть развивающегося стека технологий, способствующих реализации сервиса GitHub #HeyGitHub/Copilot?

Не стремясь к строгости или нетривиальному примеру, мы могли бы применить эту концепцию агентства на основе ролей из моего опыта EBM к дизайну решения службы #HeyGitHub/Copilot, как на этой простой диаграмме плавательных дорожек:

То, что мы видим на этой чрезмерно простой диаграмме, представляет собой кластер из четырех плавательных дорожек на верхних уровнях, которые активно взаимодействуют как человек, и трех программных агентов, чей разговор приводит к конечному порождению в «тупых»/подобных транскрипционисту данных ролях IDE. приложение и исходный файл (память). Эта простая диаграмма ясно показывает, что огромная проблема, с которой мы сталкиваемся в будущем, заключается в том, как внедрить «шерлоковский ум» в этот диалог на основе агента, прежде чем наилучшим образом использовать наш ученый, похожий на Rainman-Agent Copilot LLM.

Представьте себе, что нашим требованием к дизайну является, например, создание высокофункционального бота-агента телефонного центра обработки вызовов. В этом случае для перехода к развертыванию может быть достаточно гибкого набора подсказок на основе шаблонов, которые можно динамически выбирать для получения целевого результата. Но успешно работая в качестве нечеловека-программиста («приятель»), как часто утверждает GitHub, описывая свой сервис Copilot, агенты #HeyGitHub Listener и CoT Dialoguer должны будут реализовать гораздо более сложный интеллект, чем бот call-центра с поддержкой скриптов. беседа.

Возьмем, к примеру, задачу #HeyGitHub/Copilot, которая помогает разработчику создать UI/UX — пользовательский интерфейс и интерактивный опыт — для приложения. Существует приличное количество отличных UI/UX фреймворков, которые может использовать разработчик. Наш Copilot, обладающий знаниями о Rainman, уже видел бесчисленное количество примеров этих фреймворков в рамках обучения базовой модели Copilot, чтобы отточить свой талант в области генерации кода. Но возможность полезного предоставления предложений по коду на основе распознавания шаблонов, полученных из его опыта обучения, не дает Copilot базового понимания архитектуры фреймворка, лучших практик и руководств по пользовательскому интерфейсу / взаимодействию, которые компетентный разработчик-человек привносит в роль участника. в партнерстве Programming Pair.

Рассмотрим пример оболочки wxPython для почтенного C++ фреймворка wxWidgets . Никакое количество случайных блужданий по бесчисленному множеству общедоступных репозиториев кода не покажет объем знаний, полученных при глубоком погружении на превосходный веб-сайт онлайн-документации по адресуhttps://docs.wxpython.org/. Никакой декомпозиции НЛП, размышлений о тематическом моделировании/суммировании содержимого этого веб-сайта будет недостаточно, чтобы передать знания человека-разработчика в диалоге #HeyGitHub/Copilot<>Разработчик.

Так куда мы идем отсюда?

Хотелось бы, чтобы у меня было достаточно знаний в предметной области, чтобы предложить конкретный дизайн решения и путь развития для создания технологий, необходимых для поднятия производительности сегодняшних LLM, генерирующих код, на этот пресловутый «следующий уровень». Хотя полная дорожная карта еще не написана, есть некоторые предположения, которые мы можем сделать в отношении следующих шагов. Мы можем предположить, что для агента слушателя #HeyGitHub будет важно иметь возможность различать голосовые вводы разработчика, которые требуют передачи либо диалогу CoT для дальнейшего вдумчивого взаимодействия, либо переданы в текстовой форме второму пилоту LLM для генерация предложений по коду.

Перед нами стоит непростая задача — инкапсулировать информационные структуры и семантическое значение искусства и науки разработки программного обеспечения, чтобы CoT Dialoguer мог надежно работать как настоящий партнер по программной паре. Технологии для решения этой задачи, скорее всего, появятся на переднем крае исследовательской деятельности в области цепочки мыслей, быстрого выбора/установки последовательности, переключения моделей и обучения/коучинга с подкреплением «человек в цикле».

Некоторые из прорывов в этой области решений «шерлоковского ума» будут связаны с блестящим инновационным кодированием инженерами-исследователями машинного обучения. Однако я также считаю, что нетривиальный вклад в решение этой задачи внесет проектирование и разработка эффективных наборов данных эталонной модели Ground Truth, которые будут служить учебными материалами для предметно-ориентированных моделей для совместной работы в единой среде. контекст переключения модели с постоянно развивающейся базовой большой языковой моделью Copilot. Примером этих новых эталонных наборов данных является дизайн хранилища данных Metamodel Subgraph Ground Truth Storage , который я проводил в рамках своего исследования в области цифровых гуманитарных наук и представил здесь в своей серии статей #HeyGitHub.

Но разработки стандартного формата эталонного набора данных Ground Truth, ориентированного на агентов, будет недостаточно, чтобы вызвать шерлоковские диалоги, которые я представляю между разработчиком-человеком и партнером по программированию второго пилота на основе машинного обучения. Скорее, эти эталонные наборы данных Ground Truth знаний предметной области должны будут служить учебным материалом в моделируемых интерактивных сценариях обучения моделей, которые улучшают способность агента CoT Dialoguer участвовать в совместном разговоре со своим партнером-разработчиком. Эти сеансы моделирования могут сократить время и неустанно улучшать эффективное использование CoT Dialoguer знаний предметной области.

Точно так же, как сейчас мы используем передовой опыт моделирования данных для создания обучающих наборов данных для текущих приложений машинного обучения с интенсивным использованием данных, мы также сможем создавать опыт моделирования на основе агентов, который позволит нашим приложениям, основанным на знаниях, обучать и совершенствовать модели, подобные воображаемым. будущий сервис #HeyGitHub/Copilot. В рамках этой симуляционной учебной среды, похожей на « Зеркальные миры», диалоги, которые препятствуют работе модели #HeyGitHub CoT Dialoguer во время обучения, будут доступны непосредственному супервайзеру, чье реагирование на коучинг будет поощрять и укреплять соответствующее модельное поведение.

Пара пчел в шляпах на GitHub и Microsoft

На данный момент мои полеты воображения пути вперед не более чем лихорадочные мечты независимого ученого-гражданина цифровых гуманитарных наук и разработчика с ограниченными возможностями. Но если бы я стряхнул пыль со своей старой шляпы консультанта IBM, чтобы поставить парочку пчел в шляпы GitHub и Microsoft, я знаю, что бы предложил…

Во-первых, я не могу не сказать, что если бы я был частью руководства GitHub, я бы предложил мне работу в качестве члена исследовательской группы GitHub Next. На этом посту я бы усердно работал над идеями, о которых написал в этой серии статей #HeyGitHub * .

Затем, как только у нас будет Proof of Concept для наборов данных для обучения модели знаний предметной области Metamodel Subgraph Ground Truth, я буду лоббировать выделение части недавно объявленного GitHub Accelerator или M12 GitHub Fund для предоставления стипендий или финансирования запуска проекта высокопроизводительным , опытные разработчики с открытым исходным кодом, чтобы создать коллекцию этих наборов данных для обучения моделей, ориентированных на конкретную предметную область. Особое внимание следует уделить разработке обучающих наборов данных на основе метамодели для конкретной платформы UI / UX.

Зачем нужны наборы данных знаний предметной области, специфичные для UI/UX? Потому что эти «звери» часто представляют собой большие, сложные архитектуры с чрезмерно детальной настройкой по параметрам. И для большинства сценариев проекта разработки создание пользовательского интерфейса приложения и его взаимодействия с пользователем являются необходимыми действиями, которые отнимают время и усилия от кодирования решения проблемного пространства проекта, которое простой пользовательский интерфейс/UX приложения делает доступным для конечного пользователя проекта. Предоставление надежной генерации кода среды UI/UX с помощью голосового ввода в #HeyGitHub/Copilot тогда сравнимо с наличием среды UI/UX с мощным приложением для создания интерфейсов WYSIWYG.

В качестве более далеко идущей и стратегической рекомендации я бы посоветовал ведущим контактам из GitHub Next и Microsoft Project Bonsai сформировать Комитет по сотрудничеству. Цель этой группы будет заключаться в изучении способов, с помощью которых GitHub может использовать лучшие практики и опыт обширных обязательств Microsoft на рынках робототехники и автоматизации промышленных процессов.

И, надеюсь, скрывается за горизонтом

Глядя еще дальше по шоссе инноваций, надевая розовые очки и футболку с оптимистичным лозунгом, к чему может привести эта исследовательская программа? Если после создания ограниченного числа наборов данных Ground Truth, относящихся к подграфам метамодели, для конкретных предметных областей и затрат времени и усилий на обучение модели машинного обучения, чтобы она играла роль агента CoT Dialoguer в ряде доменов, мы можем когда-нибудь увидеть систему Dialoguer. демонстрировать эмерджентное поведение .

Под этим я подразумеваю, что модель диалогового агента CoT может понимать обобщенную структуру и использовать знания предметной области настолько хорошо, что ее не нужно предварительно загружать новой эталонной моделью, специфичной для предметной области, чтобы она стала полезной для участия в новом контексте. На этом уровне функционирования мультимодельная система далекого будущего #HeyGitHub/Copilot может просто участвовать в самоуправляемом учебном диалоге со своим партнером по программированию Developer Pair, чтобы создать и проверить свою собственную новую модель знаний в предметной области. Благодаря этому процессу сервис #HeyGitHub/Copilot может стать по-настоящему универсальным коллегой по проектированию и разработке основных программных систем.

В заключение

Пережив борьбу с раком и научившись справляться с проблемами ловкости и подвижности из-за травмы спинного мозга, я не хотел бы ничего больше, чем иметь шанс победить Жнеца, внося свой вклад в грядущую захватывающую волну замечательных инноваций в дизайне и разработке. программного обеспечения, как это описано в моей серии статей #HeyGitHub. ✌️

Happy Healthy Vibes из Колорадо, США,
-: Джим: -

* PS Для ясности: в дополнение к моей заинтересованности в проведении исследований, предусмотренных в этой серии статей #HeyGitHub, я по-прежнему страстно привержен реализации программы второго пилота как #AssistiveTechnology посредством исследований и программы поддержки для #DisabledDevelopers и # Студенты-инвалиды STEM описаны в основной массе статей в этой публикации на Medium.

Джим Сэлмонс — семидесятиоднолетний человек, перенесший рак, гражданский ученый в области цифровых гуманитарных наук. Его основное исследование сосредоточено на разработке формата Ground Truth Storage, обеспечивающего интегрированную сложную структуру документа и модель отображения контента для изучения оцифрованных коллекций журналов и газет печатной эпохи. Падение дома в июле 2020 года привело к серьезной травме спинного мозга, которая резко ухудшила его ловкость рук и подвижность.

Джиму посчастливилось получить доступ к сообществу раннего доступа GitHub Copilot Technology во время его первоначальных попыток вернуться к работе над деятельностью по разработке инструментов на основе Python, представляющей его основной исследовательский интерес. Ощутив резкое положительное влияние GitHub Copilot на его собственную производительность разработки, он страстно заинтересовался разработкой программы исследований и поддержки для исследования и документирования использования этой инновационной вспомогательной технологии программирования для использования разработчиками с ограниченными возможностями.