Приветствуем всех на подкасте MC65FM. Сегодня мы выйдем за рамки одного из самых распространенных разговоров о разработке подсказок для Microsoft 365 Copilot, потому что, как только одна из организаций начинает серьезно использовать Copilot, вопрос быстро меняется с «Как нам писать более качественные подсказки?» на «Как нам связать Copilot с приложениями, данными, бизнес-процессами и знаниями, которые фактически работают в нашей компании?» И вот здесь становится интересной расширяемость Copilot, тестирование. Мой сегодняшний гость – EWAS Harvest, Microsoft MVP, консультант по бизнес-приложениям AI и ЦУОРД Групп в Швейцарии. EWAS работает с Microsoft 365, Azure Dynamics 365 и Power Platform, уделяя особое внимание расширению Microsoft 365 Copilot с помощью агентов и пользовательской разработки. Мы собираемся изучить расширяемость Microsoft 365 Copilot, Copilot Studio, Microsoft Azure Foundry, я не знаю, как они изменили название, Microsoft Graph, пользовательская разработка, MCPS и т.д. Итак, добро пожаловать на подкасты MC65. Привет всем, спасибо, что пригласили. Это действительно хорошая возможность для меня быть здесь. Спасибо, что пригласили. Спасибо.

Прежде чем мы перейдем к техническим деталям, не могли бы вы немного рассказать о своем пути, как вы попали в экосистему Microsoft? Да, да, да, конечно, потому что, честно говоря, я начал свою карьеру не в мире Microsoft, так что я начал свою карьеру в мире Apple. Я был инженером-программистом на платформе Mac, а затем перешел на iOS и т.п. И это было довольно давно, может быть, лет 15 или 20 назад, я перешел на работу в Microsoft. Честно говоря, я начал свою карьеру в Sharp, а затем перешел в облако Azure M365. Эээ, если бы я начал с таких предпосылок, я бы сказал так, эээ, потом перешел на облачные сервисы, а в конце — на платформу Power Platform и совсем недавно — на все, что связано с I. Честно говоря, потому что это сейчас большая часть M265, потому что у вас есть, у вас есть, у вас есть, эээ, переход, и, в общем, это в двух словах — мой, мой, эээ, мой путь. Но я начал свою карьеру в мире разработки программного обеспечения, что сегодня, возможно, многие забывают, потому что у нас, у вас, у вас сейчас есть все, что связано с I и E, по сути, такого рода деятельность или работа переместились в сферу I, так что это совсем не то, что было 20 лет назад. Да, вы работаете, вы говорите, что работаете с SharePoint, и я вижу, что вы также работаете с Graph Spike Dynamic Power Platform. Как ваш опыт подготовил вас к нынешнему поколению разработки I? В общем, мой профиль очень разносторонний, потому что за свою карьеру я работал со многими продуктами, как от Microsoft, так и от сторонних компаний. Поэтому у меня широкий спектр навыков в различных технологиях и инструментах. Все мои предыдущие работы дали мне хорошую базу, потому что сейчас I – это очень актуальная тема, так как существуют разные подходы и технологии для его применения. Это может быть агентный I, IE для рабочих процессов и тому подобное.

В общем, все мои предыдущие работы дали мне много навыков, чтобы быть готовым к этому переходу на I, если честно. Я перешел от I с низким уровнем кодирования к IE без использования процедурного кода. Да, все эти возможности и виды деятельности на моих предыдущих работах дали мне хорошие навыки, чтобы воспользоваться преимуществами в мире I, если честно. Да, и теперь вы – руководитель тестирования IE. Что значит быть руководителем тестирования IE? Это действительно хороший вопрос, потому что многие меня об этом спрашивают. Моя работа заключается в том, чтобы сопоставить функциональную спецификацию с технической спецификацией. Я беру на себя руководство после проведения бизнес-анализа. Мы определили варианты использования IE. Мы определили сценарии использования. Мы провели полный бизнес-анализ, и моя работа состоит в том, чтобы взять эти потребности и сопоставить их с технической инфраструктурой. А затем я руковожу внедрением инструментов и решения, когда мы готовы начать разработку. Да, интересно. На самом деле, многие компании покупают своим сотрудникам обучение, особенно для оперативного проектирования. И почему вы говорите, что этого недостаточно? Вы имеете в виду только оперативное проектирование в наши дни? Да, да. Почему, почему, почему, почему, почему они? Это только. Знаете, почему для компаний IE недостаточно просто обучать людей оперативной разработке? А, да, хорошо, понятно, понятно. Хорошо, да, да, IE. В общем, честно говоря, сегодня, как я уже говорил, у вас есть множество различных инструментов и технологий, поэтому, в основном, в какой-то момент и может понять, что делать, и, возможно, немного направить вас.

Но для меня IE роль, например, архитектора или разработчика программного обеспечения IE требует присутствия человека за кулисами, потому что вам нужно понимать клиента. В основном, IE иногда не может понять контекст клиента. IE, вы видите здесь всю сеть, но за кулисами IE сосредоточение и внимание только на оперативной разработке может быть хорошим в какой-то момент, но вам нужно больше, потому что вам нужны люди, которые работают за кулисами IE, архитекторы, разработчики программного обеспечения и, по сути, много людей, обладающих навыками в технологиях IE и информационных технологиях, таких как SharePoint, как OneDrive, например, Я не знаю, или Salisforce и тому подобное. Вам нужны специалисты в этих технологиях, потому что IE может понимать многое. Он может IE, он может направлять вас. Вы можете создавать отличные технические или функциональные документы, но вам нужны люди за кулисами, которые будут заботиться о том, хорошо ли это, удовлетворяет ли это потребности клиента и тому подобное, вы видите, проверять все и сосредотачиваться только на оперативной разработке. Для меня сейчас это, да, это может быть вариантом, если у вас нет времени на обучение или инвестиции в приобретение каких-либо навыков. Но, честно говоря, вам нужны хорошие навыки в базовых технологиях, на основе которых вы хотите создавать свои решения. Да, да. И вы эксперт в расширяемости Co-Pilot. Где?

Заканчивается стандартный Co-Pilot Microsoft 365 и где начинается расширяемость Co-Pilot. Да, это хороший вопрос, потому что, честно говоря, два года назад, когда был выпущен Co-Pilot и, возможно, первая версия, чат был, честно говоря, очень минималистичным. В основном, вы могли, ладно, это был чат GPT, как, но Microsoft значительно развила Microsoft 365 Co-Pilot. В принципе, теперь у вас есть покрытие, у вас есть различные типы функций, поэтому расширяемость сейчас меньше, чем раньше, потому что раньше я разрабатывал плагины и тому подобное, но сейчас, честно говоря, расширяемость – это когда вы хотите что-то создать и хотите настроить, по сути, оркестратор или, например, пользовательский интерфейс. Если вы хотите интегрировать своего агента не только в чат Microsoft 365, но, например, на свой веб-сайт и так далее, таким образом, расширяемость начинается. Когда вы хотите, по сути, больше настроить-то, что происходит за кулисами, вы хотите немного больше настроить.

Это может быть оркестратор, если вы хотите настроить оркестратор, если вы хотите настроить свой интерфейс, если вы хотите настроить различные аспекты, где, по сути, чат Капайлот не может, не может, не может отвечать на сообщения. И? Я думаю, многие говорят об агентах. Что? Что? Почему? Почему мы сейчас так много? Агентов Капайлот. И? Почему мы не создаем, я не знаю, одного большого Капайлот для всего? Да, это действительно интересно, потому что, честно говоря, Microsoft, как я уже говорил, сильно развилась. И, возможно, если бы мы были шесть месяцев назад,

агент был бы темой обсуждения. Теперь Майкрософт представила Капайлот Коуорк, и, честно говоря, сегодня Капайлот Коуорк может заменить множество агентов. И пока мы думаем об агентах, это просто для того, чтобы разделить вещи, потому что сейчас мы больше работаем в многоагентной модели, где у каждого агента есть своя область действия и свои обязанности. И мы не используем большого второго пилота. По сути, это просто из-за производительности. Во-первых, потому что ЭЭЭ, когда у вас есть большой набор инструкций и инструментов ЭЭЭ, с точки зрения производительности, это будет беспорядок. И ЭЭЭ, архитектура сейчас больше многоагентная. Это может быть Капайлот Студия, это может быть агент, разработанный на заказ с точки зрения вашего кода или собственной разработки. Но в наши дни лучше иметь многоагентный подход, где у каждого агента есть своя область действия и свои обязанности с точки зрения ЭЭЭ, просто с точки зрения производительности, и иметь четкую архитектуру с точки зрения агентов. Да, Шопенбер. И когда мы смотрим на это, хорошо, я думаю, базовое. Архитектура агента и, тогда у нас есть, я бы сказал, несколько паролей.

Мы имеем пароли. Хорошо, но нам нужно подумать о рассуждениях, инструментах, знаниях и инструкциях. Как это вписывается в архитектуру и агента? Первое, о чем нужно подумать, один из первых вопросов, на который нужно ответить, это, какова цель? Первая задача этого агента. В основном, после архитектуры агента все зависит от того, используете ли вы подход с минимальным количеством кода или подход с индивидуальной разработкой, потому что подходы совершенно разные, так как при индивидуальной разработке вы управляете всем. Вы управляете безопасностью, хастингом. Множеством разных вещей. В подходе с минимальным количеством кода все совсем по-другому, потому что вы думаете о том, чтобы дать инструкцию, выбрать инструменты. Итак, в принципе, архитектура в подходе с низким уровнем кодирования. Не так проста, как я сказал сейчас, но она может быть очень быстрой, потому что вы можете определить, хорошо, у вас есть инструкция, вы можете выбрать свои инструменты, вы можете выбрать. Другой, ээ, другой, ээ, другой агент, если хотите подключиться. Но это действительно просто, когда вы имеете дело с собственной разработкой или когда вы разрабатываете свой собственный агент. Это может быть, например, ядро Семантик, агент ФАМы и тому подобное. Архитектура Арктик может быть действительно сложнее, потому что вам нужно иметь дело с действительно продвинутыми концепциями, как я уже сказал, безопасностью. ММ. Что касается аутентификации, если у вас есть несколько, ээ, если у вас есть, например, несколько инструментов, и вы хотите интегрировать какой-либо NCP, чтобы подключиться к внутренним инструментам, защищенным обратными прокси-серверами и тому подобными вещами.

Итак, по сути, вам нужно больше размышлять об архитектуре, когда вы работаете с пользовательскими агентами, например, в Капайлот Студия. Что касается архитектуры, то определить ее можно очень быстро при использовании подхода, основанного на разработке пользовательских приложений. Вам приходится иметь дело с продвинутыми концепциями, и для многих это может быть сложно, потому что это действительно фундаментальный аспект. И, честно говоря, в моей работе мне приходится иметь дело со множеством различных потребностей. Это может быть разработка пользовательских приложений, это может быть Капайлот Студия, это может быть простой агент в Агент Билдер с очень простым и удобным интерфейсом. Так что, по сути, определение архитектуры действительно зависит от того, какой подход вы хотите использовать. В основном, у вас есть общая архитектура, которую вы можете создать, но в дальнейшем все зависит от того, какой подход вы хотите использовать с низким уровнем кода или с высоким уровнем кода, понимаете? Да, да. М. Но можем ли мы, можем ли мы, можем ли мы описать структуру типичного корпоративного ИИ-агента? Ах да, могу, М, в принципе, если. Говорить максимально просто, когда у вас возникает потребность, например, в агенте ИТ-поддержке, М, в принципе, это может быть набор агентов. Но сейчас, как я уже сказал, используется многоагентный подход, и я ставлю первого агента в качестве фронтенда. Это фронт-агент, и этот фронт-агент будет перенаправлять все.

Запросы, например, разным агентам. Например, если пользователь задает вопрос, например, о Солисфорс, он перенаправит весь запрос агенту ИТ-поддержке Солисфорс. Видите, в основном для некоторых клиентов мы создали такую архитектуру, потому что каждый агент отвечает за свою область действия. Это может касаться таких продуктов, как Солисфорс, это может касаться М365 и тому подобного. И за кулисами у каждого агента есть набор инструкций и набор из двух. И в настоящее время лучше использовать MCP-серверы, потому что MCP-серверы теперь являются универсальным плагином для интеграции нескольких сервисов в Сейл.

Таким образом, у меня есть набор MCP-серверов, а также Некоторые внутренние источники знаний. Это может быть, например, Jira, это может быть база знаний последнего сервиса и тому подобное. Таким образом, у вас есть набор инструкций для каждого агента.

Эти инструкции определяют область действия агента и его роль.

После этого у вас есть набор MCP-серверов и, возможно, источниками знаний могут быть PDF-файлы. Таким образом, это может быть множество различных источников данных. И после того, как пользователь запрашивает, например, у главного агента, система определяет, нужно ли делегировать эту задачу соответствующему агенту. Давайте немного рассмотрим возможности Copilot Studio и его место в общей архитектуре. Честно говоря, Copilot Studio – это локальный инструмент от Microsoft. Во-первых, с точки зрения архитектуры, Copilot Studio действительно предназначен для разработчиков, в основном для людей, которые не являются разработчиками. Что касается архитектуры, то, например, если мы возьмем пример, который я приводил ранее, и Т-поддержку, Copilot Studio подойдет, потому что с точки зрения архитектуры Copilot Studio справится со своей задачей, так как вы можете определить его, вы можете определить сервер NCP, вы можете легко интегрировать некоторые внешние или внутренние источники знаний, если хотите.

Как я уже говорил, если, например, у вас есть сценарий использования, где вы хотите немного настроить оркестратор, потому что за кулисами Copilot Studio вы не можете его настроить, вы активируете оркестратор и… и все. Вы не можете, например, настроить приоритет задачи, которую хотите выполнить, потому что за кулисами Copilot Studio определит ваш план, и вы его выполните. Но если вы хотите немного больше настроек, в этом случае вам нужно использовать пользовательскую разработку, например, Semantic Kernel, LongChain, фреймворком, который Microsoft выпустила совсем недавно, и в этом PH вы можете легко настроить оркестровку, определить рабочие процессы, настроить все, что хотите. Это Copilot Studio как архитектура, которая действительно определенно предназначена для разработчиков и создателей, потому что очень просто заставить агента работать. Единственная проблема Copilot Studio, и об этом нужно помнить, заключается в том, что при определении пути развития и, возможно, архитектуры, необходимо учитывать лицензирование, поскольку это важная часть любого современного решения. В настоящее время Copilot Studio немного эволюционировал в модель оплаты по мере использования, и необходимо учитывать оценку затрат, потому что, в зависимости от того, чего вы хотите достичь, иногда лучше создать собственную среду разработки, поскольку после размещения на хастинге в нужном месте вы позаботитесь обо всех расходах и сможете оценить их гораздо проще, чем сейчас. Потому что при использовании кредитного подхода Copilot иногда сложно предсказать, сколько это будет стоить в течение одного месяца, двух месяцев и так далее.

И каковы ограничения Copilot Studio?

Студия, эээ, когда я буду выбирать, я думаю, эээ, да, Microsoft Foundry, Azure Foundry, я не знаю, как это на самом деле называется, эээ, эээ, и когда эээ, мне нужно сказать, хорошо, мне нужно полностью разработать собственное решение, первый вопрос, на который нужно ответить, это, хорошо, нужно ли мне настраивать оркестровку? Для меня это первый вопрос, потому что он покажет вам, хорошо, если вы не хотите слишком углубляться в настройку оркестровки, в то, как создается оркестровка или генерируется план, вы можете использовать подход с низким уровнем кодирования с помощью Copilot, эээ, конструктора. Также, иногда, когда у вас простой сценарий использования, вы можете использовать подобные инструменты. Но если вы хотите настроить оркестровку, вам нужно перейти к конкретной разработке, и в этом случае вам нужно использовать Foundry для модели, или, если у вас есть собственная платформа, потому что преимущество пользовательской разработки заключается в том, что вы можете интегрировать модели, которые не размещены в Microsoft. При желании вы можете использовать модели Fungi, но также, если у вас есть AWS или Google. Например, платформа Google, или вы развернули модели извне, у вас есть возможность интегрировать эти модели непосредственно в ваш агент при использовании пользовательского подхода. Это также преимущество, и после этого вы можете настроить оркестровку, способ генерации плана. Все это будет размещено в агенте Foundry. Проблема Foundry сегодня заключается в том, что изначально Foundry был просто платформой для размещения моделей. Если посмотреть на ситуацию несколько лет назад, это был просто простой каталог моделей, и вы его развертывали.

В настоящее время Microsoft развила этот продукт до такой степени, что теперь вы можете создавать агентов с помощью пользовательского интерфейса Copilot Studio практически без написания кода. Вы можете управлять управлением, управлять многими вещами. Это стало действительно агентной платформой, подобной Copilot Studio для лагкода и тому подобного. А вот Foundry сейчас очень сложно вписать в экосистему, потому что Foundry быстро развивается. И, по сути, Microsoft представила некоторые функции, которые действительно, я не знаю, отличаются, но есть сходство с Copilot Studio с точки зрения интеграции MCP и тому подобного. Но после Copilot Studio основным ограничением являются модели. Таким образом, у вас есть возможность интегрировать код или визуализировать что-то подобное. Но если вы хотите интегрировать, например, свою собственную модель, потому что у вас есть определенная версия вашей модели, то это невозможно, и вам, по сути, потребуется использовать собственную платформу разработки, чтобы интегрировать, например, платформу LM, если она у вас есть.

У меня есть клиенты, у которых есть собственная платформа AWS, в этом случае вы можете интегрировать эту модель с внешним управлением ценообразованием. Хорошо, хорошо. И я думаю, что когда мы создаем агента, одна тема тоже вся связана с войной. Да, Шоп Энбер. Большинство людей говорят о MCP, протоколе контекста модели. Почему же он стал одной из самых обсуждаемых тем в разработке агентов?

И для тех, кто еще не работал с ним, что такое протокол контекста модели? Да, это большое слово. В основном, многие говорят об этом, потому что он решает важную проблему. Речь идет о том, как объединить интеграцию инструментов, навыков, возможно, внешних инструментов для ИИ, и это решило проблему, потому что раньше, без MCP, все было как в хаосе, потому что многие сервисы взаимодействовали по-разному. Были разные технологические протоколы, разные архитектурные подходы, и, по сути, MCP объединяет или интегрирует сервисы в ваш и агент или решение, если говорить более обобщенно. Но сейчас MCP – это действительно способ интеграции внешних или внутренних инструментов, возможно, и тех, и других. Но сейчас MCP – это большая часть архитектуры ИИ, потому что у вас есть это единство с точки зрения технологий. И сегодня это очень важно, потому что раньше это была интеграция API, а теперь это MCP. Это не эволюция, но раньше вы интегрировали своего агента с API. Вам нужно управлять процессом аутентификации, или управлять этим процессом, или вызывать инструмент. Теперь же ИИ может сказать, у меня есть этот инструмент, я могу выбрать то, что мне нужно для достижения цели. И что же на самом деле изменилось от MCP к API-интерфейсу? В основном, в прошлом, с точки зрения интеграции, API не были интеллектуальными. Если можно так выразиться, API – это просто, вы вызываете инструмент, и он предоставляет вам данные. Разница с MCP заключается в том, что MCP более интеллектуален с точки зрения архитектуры, потому что за кулисами у вас есть не только инструменты, которые предоставляют вам данные или информацию, но и навыки, обучающие вас, и различные другие вещи, которые делают MCP действительно интеллектуальным. По сути, MCP может дать ИИ «хорошо, вы хотите этого добиться». Я могу дать вам. Именно те инструменты, которые соответствуют вашему запросу, и вы можете вызвать не один инструмент, а несколько, чтобы достичь желаемого.

В этом и заключается роль MCP. Он дает ИИ «хорошо, у меня есть эти инструменты», и после этого вы можете вызвать этот или этот или несколько инструментов для достижения ваших целей. Он дает вам, дает вам, дает и контекст, реальный контекст всего, а API – это просто у вас есть инструменты, у вас есть описание, и это, в общем-то, все. Так что, это протокол контекста модели. Я думаю, он похож на метаданные, или как это работает. Нет. MCP – это просто протокол. В принципе, это технологический протокол, и за кулисами у вас есть метаданные, описания, навыки ИИ, которые более подробно описаны, он действительно ориентирован на ИИ.

В основном, у вас есть навыки, инструкции, ИИ лучше понимает «хорошо, эти инструменты делают это, этот инструмент делает-то хорошо, я могу вызвать эти навыки, я могу запросить эту информацию на MCP-сервере, чтобы выполнить свой запрос». Но у вас есть часть метаданных, потому что вам нужно определить «хорошо», название инструмента, что он делает за кулисами.

Послушайте, можно ли сказать, что будущее за MCP? Поэтому нам нужно начать думать о том, что у компаний внутри организации сотни REST API, должны ли они начать создавать MCP-серверы вокруг них. Да, да, в основном, MCP-сервер, мы работаем с API за кулисами. Это, по сути, не замена. Если я правильно понял, сервер MCP – это просто, он предоставляет контекст, а за кулисами MCP может вызывать API. За кулисами, но сервер MCP – это фронтенд, фронтенд, фронтенд, инструмент, который вам нужно вызвать, потому что за кулисами вы будете обрабатывать. Свой запрос на основе «за кулисами» – это может быть API, база данных, множество инструментов, но вам, если вы хотите, нужен собственный MCP-сервер. Например, если у вас внутри компании есть API и различные сервисы – это может быть, скажем, финансовый сервис или HR-сервис, то для создания собственного MCP вам нужно будет разобраться со всеми этими API, и MCP-сервер должен будет предоставлять доступ ко всем этим API, какие сервисы доступны, какие инструменты необходимы и так далее.

После этого вам нужно будет разобраться с аутентификацией, потому что API работают по-разному, а аутентификация может осуществляться по ключу, по вводу данных и так далее. Поэтому вам нужно будет этим заниматься, но MCP будет предоставлять доступ ко всем инструментам, и за кулисами все эти инструменты могут обращаться к нескольким API. Один API может иметь другую архитектуру, скрытую за кулисами. Хорошо. И?

Как MCP? Выбирает правильный инструмент, когда у меня, я не знаю, 100 или 500 агентов И? Это будет основано на, ЭЭ, первых вещах. В основном, когда у вас есть запрос к агенту, вы обнаружите все доступные инструменты. Сервер MCP проверит, хорошо, у меня есть все эти инструменты.

И, по сути, оркестратор агента поймет, хорошо, у меня есть это, у меня есть доступный LLM. После этого вы создадите план. Если я немного подытожу, вы создадите план с каким-то действием, которое нужно выполнить, и после этого, в действии, которое вы хотите выполнить, вы можете вызвать один, два, три или более инструментов, чтобы выполнить задачу, запрошенную пользователем. Итак, по сути, оркестратор агента будет понимать инструменты MCP и выбирать лучшие для запроса. Видите ли, это и есть роль оркестратора, выбор инструментов и тому подобное, с помощью LLM, конечно же, потому что LLM – это часть мозга, и оркестратор будет взаимодействовать с LLM, а также с инструментами, чтобы сделать лучший выбор и составить лучший план для выполнения задачи. Да, я, я думаю, что некоторое время многие компании начинали с PowerShell, а теперь они используют API Microsoft Graph. Создается ли график, и появляется ли NCP, или как это работает?

Да, я думаю, что на самом деле, на самом деле API для графиков, честно говоря, нет, нет MCP для графиков.

Если вы назовете это, вы знаете, что сейчас в мире Microsoft Graph, Microsoft представила множество серверов MCP, и эти серверы MCP основаны на Microsoft Graph. Например, если вы хотите использовать, я не знаю, сервер LCP вашей команды, то в фоновом режиме будет вызываться API Graph, когда вы используете сервер NCP. Таким образом, графический и в мире Microsoft 365 играет центральную роль, потому что в фоновом режиме NCP взаимодействует с граф, чтобы запрос работал корректно.

Но да, сегодня граф также играет центральную роль в Copilot в целом, потому что семантический индекс Copilot основан на необработанных данных, но на самом деле вы используете граф через MCP. Сегодня. Microsoft 365 содержит невероятную ценность, организационные контексты, документы, встречи, электронная почта, люди, команды, беседы Converge и, я бы сказал, обмен контентом. Как нам раскрыть этот контекст? Нет.

Создавая кошмар безопасности.

Вы имеете в виду с точки зрения управления подобными вещами. Да, это всегда проблема, потому что многие создают агентов, не обеспечивая надлежащего управления ими за кулисами. Итак, я хочу создать агента. Хорошо, давайте начнем. Мы создаем и развертываем, и после этого. Но, хорошо, этот агент будет обрабатывать большой объем данных. Как этим управлять? Первый вопрос. Как мне организовать управление агентом? Раньше, как вы сказали, это могло быть полным бардаком. Потому что многие хотят создать агента, агента, агента, или я хочу создать что-то, я хочу создать решение на основе ИИ, но за кулисами, если вы работаете, например, в контексте Microsoft 365, одно из первых дел, это понять свои данные. Потому что без понимания данных вы заблудитесь. Вам нужно понимать свои данные, потому что важно понимать, имею ли я дело с конфиденциальными данными или нет. Имею ли я дело с, э, крайне конфиденциальными данными.

Хорошо. Э, вам нужно понимать свои данные. После этого, если вы работаете с Microsoft CR, вам нужно внедрить, например, функции DLP, маркировку конфиденциальности и тому подобное, потому что без этого, э, могут возникнуть проблемы. И после этого, вам также нужно немного очистить свои данные, э, потому что, э, ИС, с плохими, с плохими данными, ваш агент не будет работать так, как вы хотите, э, потому что, э, если у вас есть маска в вашем, я не знаю, SharePoint, э, командном, канале, э, если это маска, э, в основном, будет сложно правильно работать, э, в агентном, э, подходе. Но да, вам нужно понимать свои данные, вам необходимо внедрить некоторые, некоторые, э, базовые меры безопасности, такие как, э, аутентификация, как я уже сказал, функция Purview, и Purview стал центральным решением для внедрения всего этого, э, обеспечения безопасности и управления.

И после того, как вы очистите свои данные и внедрите базовые меры безопасности, вам также необходимо понять. Лицензирование, потому что, прежде чем начать создавать агента, вам нужно понять, кто такие разработчики, обучены ли они этому, есть ли у нас необходимые лицензии для начала работы, нужны ли нам подписки и тому подобное.

Кроме того, одна из больших проблем – это инструменты.

Как правильно интегрировать все инструменты в мой агент разработки?

Нужно ли что-то ограничивать?

Честно говоря, это большой вопрос. Вам нужно учитывать различные факторы, но для меня самое важное – это понимать свои данные.

Если компания не понимает данные, это будет проблемой на начальном этапе, честно говоря. Хорошо. И? Когда мы? Как?

Мы?

Хорошо. Спросите об этом.

Тема безопасности.

Я думаю, есть два.

Типа людей. Один говорит, хорошо, им нужны права доступа пользователей, а другой, им нужны права доступа приложений.

Как агент должен работать в целом?

Моя лучшая рекомендация, когда вам нужно работать с решением агентик, всегда используйте. Делегированные права доступа пользователей, потому что с точки зрения безопасности это, честно говоря, лучше, так как пользователь будет работать только с теми данными и инструментами, которым у него есть доступ.

Это главный принцип. После этого, если вам нужны права доступа приложений для конкретного API, конкретного контекста, вы можете это сделать. Но не используйте права доступа приложений напрямую, используйте их в контексте оболочки.

Например, создайте сервер MCP и интегрируйте этот MCP с правами доступа приложений в фоновом режиме.

Итак, MCP будет вызывать, например, ваш API в фоновом режиме с правами доступа приложения, и после этого предоставит вам необходимую информацию, но пользователь не будет напрямую взаимодействовать с правами доступа приложения. Мы вызываем, например, сервер MCP с правами доступа пользователя, и сервер MCP будет вызывать в фоновом режиме приложения или сервисы с выделенными правами доступа приложения. Видите разницу?

Хорошо. Интересно. Я думаю, когда мы думаем об архитектуре, мы также должны немного углубиться в нее.

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

Давайте начнем с рек. Какое место занимает рек в архитектуре? Ах, RAG. Честно говоря, RAG – это, пожалуй, самый эффективный инструмент с точки зрения производительности, потому что и должен понимать разные типы данных, и, по сути, RAG предназначен для ответа на вопросы.

Раньше, без RAG приходилось использовать другие подходы. Не устаревшие, но сложные.

RAG же играет центральную роль, потому что он понимает разные типы данных и позволяет получать необходимую информацию, даже если документы содержат множество различных типов данных. Так что да, RAG сегодня является центральным элементом архитектуры ИИ. Да.

Но правда в том, что многие пользователи, когда речь заходит о RAG, не знают, что это такое, потому что Microsoft и многие другие компании-разработчики программного обеспечения сейчас об этом не говорят, потому что за кулисами работает RAG. Например, в Copilot Studio пользователь не понимает, что это такое, и понимает, что это такое. И сегодня, когда вы хотите углубиться в тему, у вас есть подобная концепция, но для многих пользователей RAG совершенно неизвестен, потому что они просто используют инструмент, и за кулисами есть эти концепции. А затем у нас есть следующая тема, это знания, как мы их получаем, откуда системы и получают свои знания, как они их собирают, как это работает.

Честно говоря, знания могут Храниться во множестве Разных систем Это может быть обычный текстовый файл, файл Markdown, база знаний, что угодно. Но на самом деле, если у вас есть сервер MCP, вы можете получить доступ к этим знаниям. Или, например, если у вас есть коннектор к SharePoint, коннектор ко многим сервисам, доступ к знаниям стал проще, чем раньше, давайте будем честны. Потому что раньше вам нужно было создавать свой плагин и просматривать все. Сегодня у вас есть прямой коннектор к любой системе, вы можете интегрировать свои знания, не имея дела с большим эээ, большим штатом разработчиков. Я думаю, что часто мы, не знаю, собираем, я говорю своим, не знаю, ребята. И как? И понимает, что? Документы не готовы, или устарели, или, не знаю, дублируются. Как? Как? Как система и может это понять? Что нам следует использовать и что? В общем, вы используете RAG, потому что, по сути, вам нужно понимать, что представляют собой ваши данные, но...

Честно говоря, если я немного подытожу, вы начинаете с запроса, хорошо? Пользователь хочет, например, выполнить поиск в базе знаний или, например, на OneDrive. По сути, когда оркестратор с помощью LM понимает запрос и намерения пользователя, за кулисами у вас есть индекс. Например, в Copilot есть семантический индекс, и этот индекс, по сути, дает вам всю необходимую информацию, и вы можете с помощью запроса к семантическому индексу. И напрямую обращаться к нему для выполнения. Например, RAG запроса, и вы можете напрямую выбирать нужные документы в соответствии с вашими потребностями. Но в Copilot у вас есть семантический индекс, и, и может напрямую обращаться к нему с помощью естественного языка. Например, я спрашиваю, я хочу понять, как настроить VPN-сеть моей компании. И за кулисами вы выполняете RAG запрос к семантическому индексу и, по сути, извлекаете документ, содержащий, например, все настройки VPN-сети компании.

Например, в чате Microsoft 365 Copilot, по сути, используется граф API, потому что, как я уже говорил, семантический индекс построен на основе граф API. Это функция граф, работающая за кулисами, но, когда вы занимаетесь собственной разработкой, за кулисами используется, например, Foundry EQ. Раньше это был сервис Azure с другим названием, но теперь вы можете использовать собственную систему RAG, если хотите. И, по сути, когда у вас есть собственный агент, вы можете напрямую запросить. Экземпляр Foundry EQ. Хорошо. Я хочу использовать, я хочу получить настройки моей VPN-компании, и, и сможет найти-то, что вам нужно в плане документов. Это могут быть PDF-файлы, Word, Excel и тому подобное. И, вот так работает поиск, верно? Или, вы имеете в виду, за кулисами? Да. А, за кулисами. Да, у вас есть поиск. В общем, сейчас, в основе работы Copilot и Copilot Chat лежат три функции. Стандартный поиск, который представляет собой поиск по ключевым словам, которые вы просто вводите.

В документы и так далее. Это простой поиск, известный всем, как поиск по ключевым словам в Google. Затем у вас есть две другие функции. Во-первых, это функция RAG, ресурс Agile в Graph API, а также. Семантический индекс поиска Copilot, который немного отличается, поскольку RAG гораздо более продвинут, чем семантический индекс поиска Copilot. Все эти три функции работают за кулисами, чтобы ваш. И и мог использовать их для извлечения данных из OneDrive, Teams и M365 в целом. Он может включать в себя семантический индекс Copilot, а также коннекторы Copilot. Например, если у вас есть подключенный Salisforce к коннектору Copilot, он также может осуществлять поиск по всем вашим данным в Salisforce, в ServiceNow, в нескольких инструментах. Потому что с помощью коннектора Copilot вы интегрируете все данные в Graph, Index, семантический индекс и можете напрямую запрашивать данные из внешних систем.

Ага. Хорошо. И я думаю, что. Когда мы создаем агентов, у нас есть часть, связанная с управлением, и одна из частей, которую я бы назвал управлением жизненным циклом агента, как это выглядит на самом деле. Как это выглядит на самом деле? Честно говоря, в экосистеме Microsoft это довольно просто, если можно так сказать. Потому что, когда вы работаете с LowCode, например, Compiler Studio, вы работаете с четырьмя платформами, концепцией управления жизненным циклом, IAM, и ничего не изменилось. Итак, у вас есть решение, у вас есть ALM, у вас есть конвейер. Честно говоря, при работе с Copilot Studio все то же самое, что и раньше, потому что у вас есть все те же инструменты, что и раньше, включая управление жизненным циклом Power Platform ALM. Это абсолютно то же самое. И это хорошо, потому что многие спрашивают меня, о, Competitive Studio, как вы управляете? Это отличается? Нет, все очень просто, как для приложений или Core Automate – управление жизненным циклом приложений.

В данном случае это управление жизненным циклом агентов, но за кулисами та же концепция, что и у Core Platform. А когда вы работаете? Например, с пользовательской разработкой это, по сути, то же самое, что и при создании приложений, NIT-приложений и тому подобного, потому что вы управляете всем как кодом. У вас есть фреймворки, аспекты безопасности и тому подобное. Так что, честно говоря, все, что касается управления жизненным циклом приложений и агентов – это та же самая концепция, что и раньше. И это для меня важный момент, потому что вам не нужно много инвестировать в процесс жизненного цикла, в подобные вещи. Единственное изменение, которое у вас есть – это, хорошо, вам нужно позаботиться о LLM, подобных вещах, развертывании, подобных вещах. Но за кулисами это выглядит так же, как и раньше, с подходом DevOps, с конвейером и подобными вещами. Поэтому, на мой взгляд, ничего не изменилось, потому что мы управляем агентами.

Это может быть разработка на заказ или копирование, но, честно говоря, сейчас подход тот же, что и раньше. И. Это означает, что когда компания не использует ИИ до его внедрения, но у нее есть идеальная настройка для предварительного просмотра Defender и всех остальных инструментов, есть ли какие-либо изменения, которые нужно внести, или это означает готовность к ИИ. Ах, это очень важный вопрос, потому что готовность к ИИ. Для Microsoft, ИИ, в порядке, ИИ, вы оттачиваете навыки управления, решаете подобные вопросы. Но, ИИ, готовность для меня, это не только технический подход, потому что, хорошо, с технической точки зрения мы знаем, что делать. Хорошо, нам нужно управлять правами доступа во многих сервисах, понимаете. Для меня готовность к ИИ должна также включать в себя. Данные, данные, понимаете, потому что, ИИ, когда вы не понимаете свои данные, Как я уже говорил, ИИ, вы не можете, ИИ, вы не можете управлять технической частью, потому что, ИИ, когда вы не знаете, что является конфиденциальным, а что нет, например, ИИ, трудно внедрить какие-то меры безопасности, какие-то меры безопасности.

Но если мы, если следовать примеру Microsoft, готовность к ИИ, это нормально, нужно управлять разрешениями, устанавливать метки конфиденциальности, соблюдать GLP, Global Lineage Price и тому подобное. Но есть и более высокий уровень. И для меня готовность к ИИ, это не только технический аспект, честно говоря, сегодня нужно учитывать и функциональный или высокоуровневый аспект. Да, это действительно интересно. Я думаю, многие компании, начав с ИИ, теперь с агентов, говорят, о, он удалил все мои электронные письма или делает что-то ужасное. Как вы думаете, что скажут компании, что боятся ИИ? Это хороший вопрос, потому что я живу в Швейцарии и у нас, в основном, много частных банков и, честно говоря, у нас много очень чувствительных клиентов и, в основном, самая важная часть – это «хорошо», где обрабатываются данные. И, да, также, ищет ЛИИ, мои электронные письма и тому подобное. Так что за кулисами они всегда задают этот вопрос, но, знаете, самая важная часть для них – это «хорошо», мне нужно понять, где обрабатываются данные, и, также, «хорошо», я являюсь владельцем ИИ.

Итак, я даю инструкцию ИИ, и ИИ, работающий за кулисами, выполняет эту работу. Они боятся, например, автономного аспекта, потому что «сегодня, хорошо, вы можете это сделать, а за кулисами и будет что-то искать, задавать вопросы, что-то делать за кулисами». И они боятся «что, когда я прошу ИИ, что-то сделать, что он делает за кулисами». И да, таких вопросов много. Хорошо. Как мне взять под контроль весь процесс, стоящий за этим, будь то и агент или и сервис? Да, есть несколько подобных вопросов, но это действительно вопрос внедрения, а также обучения, чтобы внедрить некоторую подготовку, чтобы понять, как понимать и, как понимать, что именно делается за кулисами. Прозрачность – это тоже очень важный момент, потому что прозрачность должна быть внедрена в каждое решение на основе и, потому что для меня это очень важная тема, ведь нужно внедрить все, что необходимо, потому что ваше решение на основе и должно быть прозрачным.

Нужно понимать, что происходит за кулисами, какие данные запрашиваются, нужно отслеживать, нужно все регистрировать. Поэтому все должно быть прозрачным, когда у вас есть решение в наше время, потому что нужно точно понимать, что происходит за кулисами, какие данные обрабатываются и какова логика всего этого. Хорошо. Как вы разработали этот план, основываясь на каких фактах и тому подобном? Замечательно. О, я вижу, у нас немного не хватает времени. Так что, да, извините. Знаете, это было действительно потрясающе. Но в каждом подкасте у меня есть блиц-опрос. То есть, я даю короткое предложение, а вы даете короткий ответ. Итак, вы готовы? Да. Капайлот Студия или собственный код. Капайлот Студия. Майкрософт Фаундри или Капайлот Студия. Капайлот Студия. Тайпскрипт или Сайпескрипт. Гитхаб или Азур Дефопс. Гитхаб. Рек или Тонкая настройка. Хорошо. Какой самый недооцененный АПИ Майкрософт 365? АПИ РАК РАК. Технология, которую каждый разработчик Майкрософт должен изучить в 2026 году.

Гитхаб Капайлот. Когда Сатьяни далее придет к вам и скажет, дайте нам все деньги и ресурсы, которые вы хотите, чтобы улучшить нашу платформу и вы можете разработать одну функцию. Что это будет? Все необходимые нам инструменты управления. И? Кого мне пригласить на подкаст и какой вопрос задать? О, хороший вопрос. У меня много друзей, но да, может быть, вы можете пригласить меня. У меня есть садокладчик на многих конференциях. Вы можете пригласить, например, Хлою Мора. Она раньше работала функциональным консультантом, а теперь занимается технической стороной. У нее очень интересная история о функциональном и менее техническом аспектах в мире Dynamics. Так что, может быть, вы могли бы пригласить ее и спросить, как сейчас совмещать функциональную и техническую работу, потому что здесь есть очень большие проблемы.

Да. И мой заключительный вопрос, что люди должны почерпнуть из этой сессии, если могут, что им следует вынести. Из нее вы имеете в виду, что и быстро развивается. И если вы хотите быть в курсе событий, вам нужно следить за всем, потому что сегодня и действительно присутствует во всех аспектах Microsoft, если честно. В наши дни одна из вещей, которую вам нужно понимать, это то, что эволюция происходит быстро, и вам нужно быть в курсе событий, действительно, действительно, всегда, потому что вы что-то упустите в какой-то момент, если вы, если вы, если вы, если вы, если вы не, если вы, если вы не учитесь, если вы не понимаете эволюцию в этом отношении.

Да, так что да, спасибо, что присоединились ко мне. Я думаю, важный вывод из этой беседы заключается в том, что расширяемость Microsoft C65 Copilot – это не просто написание все более сложных запросов.

Я думаю, мы движемся к архитектуре, где Copilot и агенты могут связывать организационные знания, Microsoft Graph, бизнес-приложения, AP и так далее. Да, я думаю, что Copilot Studio, Microsoft Phone 3, пользовательская разработка и такие технологии, как MCP, предоставляют разработчикам, да. Удивительный, мощный набор инструментов. Да, и еще, чем более способными становятся агенты, тем важнее становятся и фундаментальные принципы идентификация, разрешение, безопасность, управление, тестирование, наблюдаемость, управление жизненным циклом приложений и так далее. Так что да, я думаю, вы дали действительно очень хороший обзор всех этих тем. Спасибо, что присоединились ко мне и всем слушателям вся информация, которую вы найдете в примечаниях к выпуску на странице подкаста MC65FM, а также информация о работе ИЕС. Спасибо, что были здесь. Спасибо, что пригласили меня. Было очень приятно провести с вами время.