WEBVTT

00:00:00.660 --> 00:00:07.560
Приветствуем всех на подкасте MC65FM. Сегодня мы выйдем за рамки одного из самых распространенных

00:00:07.560 --> 00:00:13.720
разговоров о разработке подсказок для Microsoft 365 Copilot, потому что, как только одна из

00:00:13.720 --> 00:00:18.860
организаций начинает серьезно использовать Copilot, вопрос быстро меняется с «Как нам писать

00:00:18.860 --> 00:00:24.880
более качественные подсказки?» на «Как нам связать Copilot с приложениями, данными,

00:00:24.880 --> 00:00:29.880
бизнес-процессами и знаниями, которые фактически работают в нашей компании?»

00:00:30.340 --> 00:00:34.480
И вот здесь становится интересной расширяемость Copilot, тестирование.

00:00:34.480 --> 00:00:41.060
Мой сегодняшний гость – EWAS Harvest, Microsoft MVP, консультант по бизнес-приложениям

00:00:41.060 --> 00:00:49.400
AI и ЦУОРД Групп в Швейцарии. EWAS работает с Microsoft 365, Azure Dynamics 365 и Power Platform,

00:00:49.400 --> 00:00:55.280
уделяя особое внимание расширению Microsoft 365 Copilot с помощью агентов и пользовательской

00:00:55.280 --> 00:01:03.260
разработки. Мы собираемся изучить расширяемость Microsoft 365 Copilot, Copilot Studio, Microsoft Azure Foundry,

00:01:03.260 --> 00:01:08.000
я не знаю, как они изменили название, Microsoft Graph, пользовательская разработка,

00:01:08.000 --> 00:01:18.380
MCPS и т.д. Итак, добро пожаловать на подкасты MC65. Привет всем, спасибо, что пригласили. Это действительно

00:01:18.380 --> 00:01:25.220
хорошая возможность для меня быть здесь. Спасибо, что пригласили. Спасибо.

00:01:25.220 --> 00:01:31.640
Прежде чем мы перейдем к техническим деталям, не могли бы вы немного рассказать о своем пути,

00:01:31.640 --> 00:01:38.840
как вы попали в экосистему Microsoft? Да, да, да, конечно, потому что, честно говоря,

00:01:38.840 --> 00:01:46.820
я начал свою карьеру не в мире Microsoft, так что я начал свою карьеру в мире Apple. Я был инженером-программистом

00:01:46.820 --> 00:01:55.390
на платформе Mac, а затем перешел на iOS и т.п. И это было довольно давно, может быть,

00:01:55.390 --> 00:02:04.210
лет 15 или 20 назад, я перешел на работу в Microsoft. Честно говоря, я начал свою карьеру в Sharp,

00:02:04.210 --> 00:02:15.340
а затем перешел в облако Azure M365. Эээ, если бы я начал с таких предпосылок, я бы сказал так,

00:02:15.340 --> 00:02:21.880
эээ, потом перешел на облачные сервисы, а в конце — на платформу Power Platform и совсем недавно — на

00:02:21.880 --> 00:02:29.560
все, что связано с I. Честно говоря, потому что это сейчас большая часть M265, потому что у вас есть,

00:02:29.560 --> 00:02:36.340
у вас есть, у вас есть, эээ, переход, и, в общем, это в двух словах — мой, мой, эээ, мой путь.

00:02:36.340 --> 00:02:44.510
Но я начал свою карьеру в мире разработки программного обеспечения, что сегодня, возможно,

00:02:44.510 --> 00:02:49.970
многие забывают, потому что у нас, у вас, у вас сейчас есть все, что связано с I и E,

00:02:49.970 --> 00:02:55.630
по сути, такого рода деятельность или работа переместились в сферу I, так что это совсем не то,

00:02:55.630 --> 00:03:05.330
что было 20 лет назад. Да, вы работаете, вы говорите, что работаете с SharePoint, и я вижу,

00:03:05.330 --> 00:03:12.610
что вы также работаете с Graph Spike Dynamic Power Platform. Как ваш опыт подготовил вас к нынешнему

00:03:12.610 --> 00:03:26.180
поколению разработки I? В общем, мой профиль очень разносторонний, потому что за свою карьеру я

00:03:26.180 --> 00:03:35.090
работал со многими продуктами, как от Microsoft, так и от сторонних компаний. Поэтому у меня широкий

00:03:35.090 --> 00:03:45.290
спектр навыков в различных технологиях и инструментах. Все мои предыдущие работы дали мне

00:03:45.290 --> 00:03:50.990
хорошую базу, потому что сейчас I – это очень актуальная тема, так как существуют разные подходы

00:03:50.990 --> 00:03:59.550
и технологии для его применения. Это может быть агентный I, IE для рабочих процессов и тому подобное.

00:03:59.550 --> 00:04:06.210
В общем, все мои предыдущие работы дали мне много навыков, чтобы быть готовым к этому переходу на I,

00:04:06.210 --> 00:04:16.390
если честно. Я перешел от I с низким уровнем кодирования к IE без использования процедурного кода. Да,

00:04:16.390 --> 00:04:21.930
все эти возможности и виды деятельности на моих предыдущих работах дали мне хорошие навыки,

00:04:22.130 --> 00:04:30.840
чтобы воспользоваться преимуществами в мире I, если честно. Да, и теперь вы – руководитель

00:04:30.840 --> 00:04:38.960
тестирования IE. Что значит быть руководителем тестирования IE? Это действительно хороший вопрос,

00:04:38.960 --> 00:04:45.140
потому что многие меня об этом спрашивают. Моя работа заключается в том, чтобы сопоставить

00:04:45.140 --> 00:04:52.400
функциональную спецификацию с технической спецификацией. Я беру на себя руководство после

00:04:52.400 --> 00:05:01.140
проведения бизнес-анализа. Мы определили варианты использования IE. Мы определили сценарии

00:05:01.140 --> 00:05:09.180
использования. Мы провели полный бизнес-анализ, и моя работа состоит в том, чтобы взять эти потребности

00:05:09.180 --> 00:05:18.140
и сопоставить их с технической инфраструктурой. А затем я руковожу внедрением инструментов и решения,

00:05:18.140 --> 00:05:31.970
когда мы готовы начать разработку. Да, интересно. На самом деле, многие компании покупают своим

00:05:31.970 --> 00:05:41.520
сотрудникам обучение, особенно для оперативного проектирования. И почему вы говорите, что этого

00:05:41.520 --> 00:05:52.890
недостаточно? Вы имеете в виду только оперативное проектирование в наши дни? Да, да. Почему,

00:05:52.890 --> 00:06:00.190
почему, почему, почему, почему они? Это только. Знаете, почему для компаний IE недостаточно просто

00:06:00.190 --> 00:06:10.170
обучать людей оперативной разработке? А, да, хорошо, понятно, понятно. Хорошо, да, да, IE. В общем,

00:06:10.410 --> 00:06:16.030
честно говоря, сегодня, как я уже говорил, у вас есть множество различных инструментов и технологий,

00:06:16.210 --> 00:06:22.490
поэтому, в основном, в какой-то момент и может понять, что делать, и, возможно, немного направить вас.

00:06:22.890 --> 00:06:31.420
Но для меня IE роль, например, архитектора или разработчика программного обеспечения IE требует

00:06:31.420 --> 00:06:37.780
присутствия человека за кулисами, потому что вам нужно понимать клиента. В основном,

00:06:38.020 --> 00:06:46.640
IE иногда не может понять контекст клиента. IE, вы видите здесь всю сеть, но за кулисами IE сосредоточение

00:06:46.640 --> 00:06:52.200
и внимание только на оперативной разработке может быть хорошим в какой-то момент, но вам нужно больше,

00:06:52.200 --> 00:06:58.200
потому что вам нужны люди, которые работают за кулисами IE, архитекторы, разработчики программного

00:06:58.200 --> 00:07:04.200
обеспечения и, по сути, много людей, обладающих навыками в технологиях IE и информационных

00:07:04.200 --> 00:07:10.620
технологиях, таких как SharePoint, как OneDrive, например, Я не знаю, или Salisforce и тому подобное.

00:07:10.620 --> 00:07:17.040
Вам нужны специалисты в этих технологиях, потому что IE может понимать многое.

00:07:17.740 --> 00:07:24.140
Он может IE, он может направлять вас. Вы можете создавать отличные технические или функциональные

00:07:24.140 --> 00:07:29.320
документы, но вам нужны люди за кулисами, которые будут заботиться о том, хорошо ли это,

00:07:29.700 --> 00:07:35.800
удовлетворяет ли это потребности клиента и тому подобное, вы видите, проверять все и сосредотачиваться

00:07:35.800 --> 00:07:40.840
только на оперативной разработке. Для меня сейчас это, да, это может быть вариантом,

00:07:40.980 --> 00:07:50.380
если у вас нет времени на обучение или инвестиции в приобретение каких-либо навыков. Но,

00:07:50.640 --> 00:07:57.020
честно говоря, вам нужны хорошие навыки в базовых технологиях, на основе которых вы хотите

00:07:57.020 --> 00:08:06.700
создавать свои решения. Да, да. И вы эксперт в расширяемости Co-Pilot. Где?

00:08:06.700 --> 00:08:20.640
Заканчивается стандартный Co-Pilot Microsoft 365 и где начинается расширяемость Co-Pilot. Да,

00:08:20.880 --> 00:08:26.720
это хороший вопрос, потому что, честно говоря, два года назад, когда был выпущен Co-Pilot и,

00:08:26.920 --> 00:08:34.600
возможно, первая версия, чат был, честно говоря, очень минималистичным. В основном,

00:08:34.800 --> 00:08:42.060
вы могли, ладно, это был чат GPT, как, но Microsoft значительно развила Microsoft 365 Co-Pilot.

00:08:42.060 --> 00:08:48.340
В принципе, теперь у вас есть покрытие, у вас есть различные типы функций, поэтому расширяемость

00:08:48.340 --> 00:09:00.470
сейчас меньше, чем раньше, потому что раньше я разрабатывал плагины и тому подобное, но сейчас,

00:09:00.750 --> 00:09:05.390
честно говоря, расширяемость – это когда вы хотите что-то создать и хотите настроить,

00:09:05.570 --> 00:09:10.910
по сути, оркестратор или, например, пользовательский интерфейс. Если вы хотите интегрировать

00:09:10.910 --> 00:09:17.110
своего агента не только в чат Microsoft 365, но, например, на свой веб-сайт и так далее,

00:09:17.370 --> 00:09:22.470
таким образом, расширяемость начинается. Когда вы хотите, по сути, больше настроить-то,

00:09:22.630 --> 00:09:26.070
что происходит за кулисами, вы хотите немного больше настроить.

00:09:32.930 --> 00:09:38.170
Это может быть оркестратор, если вы хотите настроить оркестратор, если вы хотите настроить

00:09:38.170 --> 00:09:44.250
свой интерфейс, если вы хотите настроить различные аспекты, где, по сути, чат Капайлот не может,

00:09:44.250 --> 00:10:02.100
не может, не может отвечать на сообщения. И? Я думаю, многие говорят об агентах. Что? Что?

00:10:03.640 --> 00:10:14.920
Почему? Почему мы сейчас так много? Агентов Капайлот. И? Почему мы не создаем, я не знаю,

00:10:15.180 --> 00:10:22.000
одного большого Капайлот для всего? Да, это действительно интересно, потому что, честно говоря,

00:10:22.000 --> 00:10:29.340
Microsoft, как я уже говорил, сильно развилась. И, возможно, если бы мы были шесть месяцев назад,

00:10:32.570 --> 00:10:39.090
агент был бы темой обсуждения. Теперь Майкрософт представила Капайлот Коуорк, и, честно говоря,

00:10:39.430 --> 00:10:47.170
сегодня Капайлот Коуорк может заменить множество агентов. И пока мы думаем об агентах, это просто для

00:10:47.170 --> 00:10:52.030
того, чтобы разделить вещи, потому что сейчас мы больше работаем в многоагентной модели,

00:10:52.030 --> 00:10:58.830
где у каждого агента есть своя область действия и свои обязанности. И мы не используем большого

00:10:58.830 --> 00:11:04.310
второго пилота. По сути, это просто из-за производительности. Во-первых, потому что ЭЭЭ,

00:11:04.530 --> 00:11:09.570
когда у вас есть большой набор инструкций и инструментов ЭЭЭ, с точки зрения производительности,

00:11:09.690 --> 00:11:15.990
это будет беспорядок. И ЭЭЭ, архитектура сейчас больше многоагентная. Это может быть Капайлот Студия,

00:11:16.190 --> 00:11:21.750
это может быть агент, разработанный на заказ с точки зрения вашего кода или собственной разработки.

00:11:22.030 --> 00:11:28.550
Но в наши дни лучше иметь многоагентный подход, где у каждого агента есть своя область действия

00:11:28.550 --> 00:11:34.290
и свои обязанности с точки зрения ЭЭЭ, просто с точки зрения производительности, и иметь четкую

00:11:34.290 --> 00:12:06.420
архитектуру с точки зрения агентов. Да, Шопенбер. И когда мы смотрим на это, хорошо, я думаю,

00:12:06.640 --> 00:12:14.640
базовое. Архитектура агента и, тогда у нас есть, я бы сказал, несколько паролей.

00:12:14.640 --> 00:12:22.690
Мы имеем пароли. Хорошо, но нам нужно подумать о рассуждениях, инструментах, знаниях и

00:12:22.690 --> 00:12:37.110
инструкциях. Как это вписывается в архитектуру и агента? Первое, о чем нужно подумать,

00:12:37.330 --> 00:12:44.690
один из первых вопросов, на который нужно ответить, это, какова цель? Первая задача этого агента.

00:12:44.690 --> 00:12:51.710
В основном, после архитектуры агента все зависит от того, используете ли вы подход с

00:12:51.710 --> 00:12:56.750
минимальным количеством кода или подход с индивидуальной разработкой, потому что подходы

00:12:56.750 --> 00:13:03.930
совершенно разные, так как при индивидуальной разработке вы управляете всем. Вы управляете

00:13:03.930 --> 00:13:12.010
безопасностью, хастингом. Множеством разных вещей. В подходе с минимальным количеством кода все совсем

00:13:12.010 --> 00:13:17.030
по-другому, потому что вы думаете о том, чтобы дать инструкцию, выбрать инструменты. Итак,

00:13:17.270 --> 00:13:24.270
в принципе, архитектура в подходе с низким уровнем кодирования. Не так проста, как я сказал сейчас,

00:13:24.450 --> 00:13:29.310
но она может быть очень быстрой, потому что вы можете определить, хорошо, у вас есть инструкция,

00:13:29.450 --> 00:13:36.430
вы можете выбрать свои инструменты, вы можете выбрать. Другой, ээ, другой, ээ, другой агент,

00:13:36.430 --> 00:13:41.350
если хотите подключиться. Но это действительно просто, когда вы имеете дело с собственной

00:13:41.350 --> 00:13:46.070
разработкой или когда вы разрабатываете свой собственный агент. Это может быть, например,

00:13:46.390 --> 00:13:51.750
ядро Семантик, агент ФАМы и тому подобное. Архитектура Арктик может быть действительно сложнее,

00:13:51.930 --> 00:13:56.090
потому что вам нужно иметь дело с действительно продвинутыми концепциями, как я уже сказал,

00:13:56.270 --> 00:14:02.650
безопасностью. ММ. Что касается аутентификации, если у вас есть несколько, ээ, если у вас есть,

00:14:02.650 --> 00:14:07.750
например, несколько инструментов, и вы хотите интегрировать какой-либо NCP, чтобы подключиться

00:14:07.750 --> 00:14:12.370
к внутренним инструментам, защищенным обратными прокси-серверами и тому подобными вещами.

00:14:13.530 --> 00:14:19.130
Итак, по сути, вам нужно больше размышлять об архитектуре, когда вы работаете с пользовательскими

00:14:19.130 --> 00:14:26.070
агентами, например, в Капайлот Студия. Что касается архитектуры, то определить ее можно очень быстро

00:14:26.070 --> 00:14:31.850
при использовании подхода, основанного на разработке пользовательских приложений. Вам приходится иметь

00:14:31.850 --> 00:14:37.290
дело с продвинутыми концепциями, и для многих это может быть сложно, потому что это действительно

00:14:37.290 --> 00:14:46.730
фундаментальный аспект. И, честно говоря, в моей работе мне приходится иметь дело со множеством

00:14:46.730 --> 00:14:51.430
различных потребностей. Это может быть разработка пользовательских приложений, это может быть

00:14:51.430 --> 00:14:56.310
Капайлот Студия, это может быть простой агент в Агент Билдер с очень простым и удобным интерфейсом.

00:14:56.930 --> 00:15:02.610
Так что, по сути, определение архитектуры действительно зависит от того, какой подход вы хотите

00:15:02.610 --> 00:15:08.030
использовать. В основном, у вас есть общая архитектура, которую вы можете создать, но в дальнейшем

00:15:08.030 --> 00:15:12.450
все зависит от того, какой подход вы хотите использовать с низким уровнем кода или с высоким

00:15:12.450 --> 00:15:21.650
уровнем кода, понимаете? Да, да. М. Но можем ли мы, можем ли мы, можем ли мы описать структуру

00:15:21.650 --> 00:15:37.260
типичного корпоративного ИИ-агента? Ах да, могу, М, в принципе, если. Говорить максимально просто,

00:15:37.500 --> 00:15:43.460
когда у вас возникает потребность, например, в агенте ИТ-поддержке, М, в принципе, это может быть

00:15:43.460 --> 00:15:54.700
набор агентов. Но сейчас, как я уже сказал, используется многоагентный подход, и я ставлю первого

00:15:54.700 --> 00:16:02.750
агента в качестве фронтенда. Это фронт-агент, и этот фронт-агент будет перенаправлять все.

00:16:02.750 --> 00:16:12.780
Запросы, например, разным агентам. Например, если пользователь задает вопрос, например,

00:16:12.980 --> 00:16:17.440
о Солисфорс, он перенаправит весь запрос агенту ИТ-поддержке Солисфорс.

00:16:18.980 --> 00:16:24.620
Видите, в основном для некоторых клиентов мы создали такую архитектуру, потому что каждый

00:16:24.620 --> 00:16:30.560
агент отвечает за свою область действия. Это может касаться таких продуктов, как Солисфорс,

00:16:30.560 --> 00:16:37.900
это может касаться М365 и тому подобного. И за кулисами у каждого агента есть набор инструкций

00:16:37.900 --> 00:16:46.140
и набор из двух. И в настоящее время лучше использовать MCP-серверы, потому что MCP-серверы

00:16:46.140 --> 00:16:50.640
теперь являются универсальным плагином для интеграции нескольких сервисов в Сейл.

00:16:52.660 --> 00:16:56.180
Таким образом, у меня есть набор MCP-серверов, а также

00:16:56.180 --> 00:17:01.140
Некоторые внутренние источники знаний. Это может быть, например,

00:17:01.400 --> 00:17:05.000
Jira, это может быть база знаний последнего сервиса и тому подобное.

00:17:05.140 --> 00:17:08.340
Таким образом, у вас есть набор инструкций для каждого агента.

00:17:11.180 --> 00:17:14.640
Эти инструкции определяют область действия агента и его роль.

00:17:17.360 --> 00:17:22.820
После этого у вас есть набор MCP-серверов и, возможно, источниками знаний могут быть

00:17:22.820 --> 00:17:26.420
PDF-файлы. Таким образом, это может быть множество

00:17:26.420 --> 00:17:35.940
различных источников данных. И после того, как пользователь запрашивает,

00:17:36.160 --> 00:17:41.040
например, у главного агента, система определяет, нужно ли делегировать эту задачу

00:17:41.040 --> 00:17:52.720
соответствующему агенту. Давайте немного рассмотрим возможности

00:17:52.720 --> 00:18:03.590
Copilot Studio и его место в общей архитектуре. Честно говоря, Copilot Studio – это локальный

00:18:03.590 --> 00:18:08.410
инструмент от Microsoft. Во-первых, с точки зрения архитектуры,

00:18:08.610 --> 00:18:16.080
Copilot Studio действительно предназначен для разработчиков, в основном для людей,

00:18:16.300 --> 00:18:23.150
которые не являются разработчиками. Что касается архитектуры, то, например,

00:18:23.430 --> 00:18:28.930
если мы возьмем пример, который я приводил ранее, и Т-поддержку, Copilot Studio подойдет,

00:18:29.130 --> 00:18:33.650
потому что с точки зрения архитектуры Copilot Studio справится со своей задачей,

00:18:33.650 --> 00:18:38.510
так как вы можете определить его, вы можете определить сервер NCP, вы можете легко

00:18:38.510 --> 00:18:43.170
интегрировать некоторые внешние или внутренние источники знаний, если хотите.

00:18:47.580 --> 00:18:52.440
Как я уже говорил, если, например, у вас есть сценарий использования, где вы хотите

00:18:52.440 --> 00:18:57.800
немного настроить оркестратор, потому что за кулисами Copilot Studio вы не можете его настроить,

00:18:58.020 --> 00:19:05.000
вы активируете оркестратор и… и все. Вы не можете, например, настроить приоритет задачи,

00:19:05.000 --> 00:19:09.920
которую хотите выполнить, потому что за кулисами Copilot Studio определит ваш план,

00:19:10.120 --> 00:19:18.090
и вы его выполните. Но если вы хотите немного больше настроек, в этом случае вам нужно

00:19:18.090 --> 00:19:22.830
использовать пользовательскую разработку, например, Semantic Kernel, LongChain,

00:19:23.030 --> 00:19:27.750
фреймворком, который Microsoft выпустила совсем недавно, и в этом PH вы можете

00:19:27.750 --> 00:19:36.780
легко настроить оркестровку, определить рабочие процессы, настроить все, что хотите.

00:19:38.460 --> 00:19:43.540
Это Copilot Studio как архитектура, которая действительно определенно предназначена для

00:19:43.540 --> 00:19:47.920
разработчиков и создателей, потому что очень просто заставить агента работать.

00:19:49.280 --> 00:19:55.100
Единственная проблема Copilot Studio, и об этом нужно помнить, заключается в том, что при определении

00:19:55.100 --> 00:20:01.360
пути развития и, возможно, архитектуры, необходимо учитывать лицензирование, поскольку это важная часть

00:20:01.360 --> 00:20:10.400
любого современного решения. В настоящее время Copilot Studio немного эволюционировал в модель оплаты

00:20:10.400 --> 00:20:15.820
по мере использования, и необходимо учитывать оценку затрат, потому что, в зависимости от того,

00:20:16.040 --> 00:20:21.680
чего вы хотите достичь, иногда лучше создать собственную среду разработки, поскольку после размещения

00:20:21.680 --> 00:20:27.280
на хастинге в нужном месте вы позаботитесь обо всех расходах и сможете оценить их гораздо проще,

00:20:27.540 --> 00:20:34.580
чем сейчас. Потому что при использовании кредитного подхода Copilot иногда сложно предсказать,

00:20:34.800 --> 00:20:39.020
сколько это будет стоить в течение одного месяца, двух месяцев и так далее.

00:20:43.410 --> 00:20:45.610
И каковы ограничения Copilot Studio?

00:20:50.710 --> 00:20:57.310
Студия, эээ, когда я буду выбирать, я думаю, эээ, да, Microsoft Foundry, Azure Foundry,

00:20:57.310 --> 00:21:03.330
я не знаю, как это на самом деле называется, эээ, эээ, и когда эээ, мне нужно сказать,

00:21:03.470 --> 00:21:08.710
хорошо, мне нужно полностью разработать собственное решение, первый вопрос, на который нужно

00:21:08.710 --> 00:21:19.270
ответить, это, хорошо, нужно ли мне настраивать оркестровку? Для меня это первый вопрос,

00:21:19.530 --> 00:21:25.030
потому что он покажет вам, хорошо, если вы не хотите слишком углубляться в настройку оркестровки,

00:21:25.250 --> 00:21:30.970
в то, как создается оркестровка или генерируется план, вы можете использовать подход с низким уровнем

00:21:30.970 --> 00:21:37.830
кодирования с помощью Copilot, эээ, конструктора. Также, иногда, когда у вас простой сценарий

00:21:37.830 --> 00:21:45.410
использования, вы можете использовать подобные инструменты. Но если вы хотите настроить

00:21:45.410 --> 00:21:50.610
оркестровку, вам нужно перейти к конкретной разработке, и в этом случае вам нужно использовать

00:21:50.610 --> 00:21:55.570
Foundry для модели, или, если у вас есть собственная платформа, потому что преимущество

00:21:55.570 --> 00:21:59.990
пользовательской разработки заключается в том, что вы можете интегрировать модели,

00:21:59.990 --> 00:22:07.310
которые не размещены в Microsoft. При желании вы можете использовать модели Fungi, но также,

00:22:07.550 --> 00:22:20.290
если у вас есть AWS или Google. Например, платформа Google, или вы развернули модели извне,

00:22:20.510 --> 00:22:25.330
у вас есть возможность интегрировать эти модели непосредственно в ваш агент при использовании

00:22:25.330 --> 00:22:34.700
пользовательского подхода. Это также преимущество, и после этого вы можете настроить оркестровку,

00:22:34.700 --> 00:22:42.420
способ генерации плана. Все это будет размещено в агенте Foundry. Проблема Foundry сегодня

00:22:42.420 --> 00:22:48.340
заключается в том, что изначально Foundry был просто платформой для размещения моделей. Если посмотреть

00:22:48.340 --> 00:22:53.880
на ситуацию несколько лет назад, это был просто простой каталог моделей, и вы его развертывали.

00:22:55.300 --> 00:23:00.840
В настоящее время Microsoft развила этот продукт до такой степени, что теперь вы можете создавать

00:23:00.840 --> 00:23:06.240
агентов с помощью пользовательского интерфейса Copilot Studio практически без написания кода.

00:23:07.560 --> 00:23:14.380
Вы можете управлять управлением, управлять многими вещами. Это стало действительно агентной

00:23:14.380 --> 00:23:23.070
платформой, подобной Copilot Studio для лагкода и тому подобного. А вот Foundry сейчас очень сложно

00:23:23.070 --> 00:23:31.780
вписать в экосистему, потому что Foundry быстро развивается. И, по сути, Microsoft представила

00:23:31.780 --> 00:23:40.220
некоторые функции, которые действительно, я не знаю, отличаются, но есть сходство с Copilot Studio

00:23:40.220 --> 00:23:48.130
с точки зрения интеграции MCP и тому подобного. Но после Copilot Studio основным ограничением

00:23:48.130 --> 00:23:54.110
являются модели. Таким образом, у вас есть возможность интегрировать код или визуализировать

00:23:54.110 --> 00:23:59.530
что-то подобное. Но если вы хотите интегрировать, например, свою собственную модель, потому что у вас

00:23:59.530 --> 00:24:04.790
есть определенная версия вашей модели, то это невозможно, и вам, по сути, потребуется использовать

00:24:04.790 --> 00:24:10.230
собственную платформу разработки, чтобы интегрировать, например, платформу LM, если она у вас есть.

00:24:10.810 --> 00:24:17.050
У меня есть клиенты, у которых есть собственная платформа AWS, в этом случае вы можете интегрировать

00:24:17.050 --> 00:24:27.520
эту модель с внешним управлением ценообразованием. Хорошо, хорошо. И я думаю, что когда мы создаем

00:24:27.520 --> 00:24:59.910
агента, одна тема тоже вся связана с войной. Да, Шоп Энбер. Большинство людей говорят о MCP,

00:25:00.130 --> 00:25:08.030
протоколе контекста модели. Почему же он стал одной из самых обсуждаемых тем в разработке агентов?

00:25:11.560 --> 00:25:19.590
И для тех, кто еще не работал с ним, что такое протокол контекста модели? Да, это большое слово.

00:25:20.670 --> 00:25:30.020
В основном, многие говорят об этом, потому что он решает важную проблему. Речь идет о том,

00:25:30.020 --> 00:25:35.260
как объединить интеграцию инструментов, навыков, возможно, внешних инструментов для ИИ,

00:25:35.440 --> 00:25:41.400
и это решило проблему, потому что раньше, без MCP, все было как в хаосе, потому что многие сервисы

00:25:41.400 --> 00:25:52.400
взаимодействовали по-разному. Были разные технологические протоколы, разные архитектурные

00:25:52.400 --> 00:25:58.100
подходы, и, по сути, MCP объединяет или интегрирует сервисы в ваш и агент или решение,

00:25:58.340 --> 00:26:07.980
если говорить более обобщенно. Но сейчас MCP – это действительно способ интеграции

00:26:07.980 --> 00:26:14.710
внешних или внутренних инструментов, возможно, и тех, и других. Но сейчас

00:26:14.710 --> 00:26:19.530
MCP – это большая часть архитектуры ИИ, потому что у вас есть это единство

00:26:19.530 --> 00:26:26.290
с точки зрения технологий. И сегодня это очень важно, потому что раньше это была

00:26:26.290 --> 00:26:35.930
интеграция API, а теперь это MCP. Это не эволюция, но раньше вы интегрировали

00:26:35.930 --> 00:26:41.410
своего агента с API. Вам нужно управлять процессом аутентификации, или управлять этим

00:26:41.410 --> 00:26:46.370
процессом, или вызывать инструмент. Теперь же ИИ может сказать, у меня есть этот

00:26:46.370 --> 00:26:55.700
инструмент, я могу выбрать то, что мне нужно для достижения цели. И что же на самом деле

00:26:55.700 --> 00:27:07.300
изменилось от MCP к API-интерфейсу? В основном, в прошлом, с точки зрения интеграции,

00:27:07.560 --> 00:27:16.760
API не были интеллектуальными. Если можно так выразиться, API – это просто, вы вызываете инструмент,

00:27:16.760 --> 00:27:26.640
и он предоставляет вам данные. Разница с MCP заключается в том, что MCP более интеллектуален с

00:27:26.640 --> 00:27:31.440
точки зрения архитектуры, потому что за кулисами у вас есть не только инструменты, которые

00:27:31.440 --> 00:27:37.220
предоставляют вам данные или информацию, но и навыки, обучающие вас, и различные другие вещи,

00:27:37.480 --> 00:27:46.670
которые делают MCP действительно интеллектуальным. По сути, MCP может дать ИИ «хорошо, вы хотите этого

00:27:46.670 --> 00:27:55.300
добиться». Я могу дать вам. Именно те инструменты, которые соответствуют вашему запросу,

00:27:55.520 --> 00:28:00.040
и вы можете вызвать не один инструмент, а несколько, чтобы достичь желаемого.

00:28:01.600 --> 00:28:08.380
В этом и заключается роль MCP. Он дает ИИ «хорошо, у меня есть эти инструменты», и после этого вы

00:28:08.380 --> 00:28:13.160
можете вызвать этот или этот или несколько инструментов для достижения ваших целей.

00:28:13.160 --> 00:28:21.460
Он дает вам, дает вам, дает и контекст, реальный контекст всего, а API – это просто у вас есть

00:28:21.460 --> 00:28:29.940
инструменты, у вас есть описание, и это, в общем-то, все. Так что, это протокол контекста модели.

00:28:31.660 --> 00:28:37.960
Я думаю, он похож на метаданные, или как это работает. Нет.

00:28:37.960 --> 00:28:49.060
MCP – это просто протокол. В принципе, это технологический протокол, и за кулисами у вас есть

00:28:49.060 --> 00:28:55.540
метаданные, описания, навыки ИИ, которые более подробно описаны, он действительно ориентирован на ИИ.

00:28:57.870 --> 00:29:04.230
В основном, у вас есть навыки, инструкции, ИИ лучше понимает «хорошо, эти инструменты делают это,

00:29:04.390 --> 00:29:11.190
этот инструмент делает-то хорошо, я могу вызвать эти навыки, я могу запросить эту информацию на MCP-сервере,

00:29:11.190 --> 00:29:18.480
чтобы выполнить свой запрос». Но у вас есть часть метаданных, потому что вам нужно определить

00:29:18.480 --> 00:29:22.140
«хорошо», название инструмента, что он делает за кулисами.

00:29:24.160 --> 00:29:30.400
Послушайте, можно ли сказать, что будущее за MCP? Поэтому нам нужно начать думать о том,

00:29:30.540 --> 00:29:36.740
что у компаний внутри организации сотни REST API, должны ли они начать создавать MCP-серверы вокруг них.

00:29:36.740 --> 00:29:44.750
Да, да, в основном, MCP-сервер, мы работаем с API за кулисами.

00:29:46.370 --> 00:29:55.470
Это, по сути, не замена. Если я правильно понял, сервер MCP – это просто, он предоставляет контекст,

00:29:55.710 --> 00:30:03.850
а за кулисами MCP может вызывать API. За кулисами, но сервер MCP – это фронтенд, фронтенд, фронтенд,

00:30:03.850 --> 00:30:09.370
инструмент, который вам нужно вызвать, потому что за кулисами вы будете обрабатывать.

00:30:10.850 --> 00:30:16.750
Свой запрос на основе «за кулисами» – это может быть API, база данных, множество инструментов,

00:30:17.010 --> 00:30:20.370
но вам, если вы хотите, нужен собственный MCP-сервер.

00:30:20.370 --> 00:30:32.020
Например, если у вас внутри компании есть API и различные сервисы – это может быть, скажем,

00:30:32.160 --> 00:30:37.980
финансовый сервис или HR-сервис, то для создания собственного MCP вам нужно будет разобраться со

00:30:37.980 --> 00:30:43.400
всеми этими API, и MCP-сервер должен будет предоставлять доступ ко всем этим API, какие

00:30:43.400 --> 00:30:51.540
сервисы доступны, какие инструменты необходимы и так далее.

00:30:51.540 --> 00:31:00.930
После этого вам нужно будет разобраться с аутентификацией, потому что API работают по-разному,

00:31:01.250 --> 00:31:05.510
а аутентификация может осуществляться по ключу, по вводу данных и так далее.

00:31:06.710 --> 00:31:11.930
Поэтому вам нужно будет этим заниматься, но MCP будет предоставлять доступ ко всем инструментам,

00:31:12.070 --> 00:31:15.610
и за кулисами все эти инструменты могут обращаться к нескольким API.

00:31:15.970 --> 00:31:19.630
Один API может иметь другую архитектуру, скрытую за кулисами.

00:31:20.890 --> 00:31:22.130
Хорошо. И?

00:31:25.080 --> 00:31:25.940
Как MCP?

00:31:25.940 --> 00:31:34.470
Выбирает правильный инструмент, когда у меня, я не знаю, 100 или 500 агентов И?

00:31:36.430 --> 00:31:39.570
Это будет основано на, ЭЭ, первых вещах.

00:31:40.210 --> 00:31:44.810
В основном, когда у вас есть запрос к агенту, вы обнаружите все доступные инструменты.

00:31:46.570 --> 00:31:50.570
Сервер MCP проверит, хорошо, у меня есть все эти инструменты.

00:31:53.130 --> 00:31:58.630
И, по сути, оркестратор агента поймет, хорошо, у меня есть это, у меня есть доступный LLM.

00:31:59.310 --> 00:32:03.010
После этого вы создадите план.

00:32:03.010 --> 00:32:09.890
Если я немного подытожу, вы создадите план с каким-то действием, которое нужно выполнить,

00:32:09.890 --> 00:32:16.810
и после этого, в действии, которое вы хотите выполнить, вы можете вызвать один, два, три или более инструментов,

00:32:17.050 --> 00:32:19.890
чтобы выполнить задачу, запрошенную пользователем.

00:32:19.890 --> 00:32:27.970
Итак, по сути, оркестратор агента будет понимать инструменты MCP и выбирать лучшие для запроса.

00:32:28.770 --> 00:32:49.560
Видите ли, это и есть роль оркестратора, выбор инструментов и тому подобное, с помощью LLM, конечно же, потому что LLM – это часть мозга, и оркестратор будет взаимодействовать с LLM, а также с инструментами, чтобы сделать лучший выбор и составить лучший план для выполнения задачи.

00:32:49.560 --> 00:33:02.220
Да, я, я думаю, что некоторое время многие компании начинали с PowerShell, а теперь они используют API Microsoft Graph.

00:33:02.220 --> 00:33:10.970
Создается ли график, и появляется ли NCP, или как это работает?

00:33:11.310 --> 00:33:18.630
Да, я думаю, что на самом деле, на самом деле API для графиков, честно говоря, нет, нет MCP для графиков.

00:33:23.700 --> 00:33:33.940
Если вы назовете это, вы знаете, что сейчас в мире Microsoft Graph, Microsoft представила множество серверов MCP, и эти серверы MCP основаны на Microsoft Graph.

00:33:33.940 --> 00:33:47.260
Например, если вы хотите использовать, я не знаю, сервер LCP вашей команды, то в фоновом режиме будет вызываться API Graph, когда вы используете сервер NCP.

00:33:47.260 --> 00:34:03.590
Таким образом, графический и в мире Microsoft 365 играет центральную роль, потому что в фоновом режиме NCP взаимодействует с граф, чтобы запрос работал корректно.

00:34:06.080 --> 00:34:17.340
Но да, сегодня граф также играет центральную роль в Copilot в целом, потому что семантический индекс Copilot основан на необработанных данных, но на самом деле вы используете граф через MCP.

00:34:17.340 --> 00:34:40.460
Сегодня. Microsoft 365 содержит невероятную ценность, организационные контексты, документы, встречи, электронная почта, люди, команды, беседы Converge и, я бы сказал, обмен контентом.

00:34:41.600 --> 00:34:44.280
Как нам раскрыть этот контекст? Нет.

00:34:46.730 --> 00:34:48.590
Создавая кошмар безопасности.

00:34:50.870 --> 00:34:54.130
Вы имеете в виду с точки зрения управления подобными вещами.

00:34:54.130 --> 00:35:03.300
Да, это всегда проблема, потому что многие создают агентов, не обеспечивая надлежащего управления ими за кулисами.

00:35:03.920 --> 00:35:07.340
Итак, я хочу создать агента. Хорошо, давайте начнем.

00:35:07.540 --> 00:35:10.060
Мы создаем и развертываем, и после этого.

00:35:10.380 --> 00:35:14.280
Но, хорошо, этот агент будет обрабатывать большой объем данных.

00:35:14.440 --> 00:35:15.420
Как этим управлять?

00:35:16.880 --> 00:35:20.340
Первый вопрос. Как мне организовать управление агентом?

00:35:20.340 --> 00:35:25.120
Раньше, как вы сказали, это могло быть полным бардаком.

00:35:25.900 --> 00:35:41.460
Потому что многие хотят создать агента, агента, агента, или я хочу создать что-то, я хочу создать решение на основе ИИ, но за кулисами, если вы работаете, например, в контексте Microsoft 365, одно из первых дел, это понять свои данные.

00:35:41.460 --> 00:35:46.180
Потому что без понимания данных вы заблудитесь.

00:35:46.800 --> 00:35:53.500
Вам нужно понимать свои данные, потому что важно понимать, имею ли я дело с конфиденциальными данными или нет.

00:35:53.680 --> 00:35:57.100
Имею ли я дело с, э, крайне конфиденциальными данными.

00:35:57.400 --> 00:35:57.760
Хорошо.

00:35:58.360 --> 00:36:00.420
Э, вам нужно понимать свои данные.

00:36:00.420 --> 00:36:13.300
После этого, если вы работаете с Microsoft CR, вам нужно внедрить, например, функции DLP, маркировку конфиденциальности и тому подобное, потому что без этого, э, могут возникнуть проблемы.

00:36:13.300 --> 00:36:40.700
И после этого, вам также нужно немного очистить свои данные, э, потому что, э, ИС, с плохими, с плохими данными, ваш агент не будет работать так, как вы хотите, э, потому что, э, если у вас есть маска в вашем, я не знаю, SharePoint, э, командном, канале, э, если это маска, э, в основном, будет сложно правильно работать, э, в агентном, э, подходе.

00:36:40.700 --> 00:37:02.610
Но да, вам нужно понимать свои данные, вам необходимо внедрить некоторые, некоторые, э, базовые меры безопасности, такие как, э, аутентификация, как я уже сказал, функция Purview, и Purview стал центральным решением для внедрения всего этого, э, обеспечения безопасности и управления.

00:37:06.070 --> 00:37:12.610
И после того, как вы очистите свои данные и внедрите базовые меры безопасности, вам также необходимо понять.

00:37:12.610 --> 00:37:31.300
Лицензирование, потому что, прежде чем начать создавать агента, вам нужно понять, кто такие разработчики, обучены ли они этому, есть ли у нас необходимые лицензии для начала работы, нужны ли нам подписки и тому подобное.

00:37:36.220 --> 00:37:39.320
Кроме того, одна из больших проблем – это инструменты.

00:37:44.140 --> 00:37:47.600
Как правильно интегрировать все инструменты в мой агент разработки?

00:37:50.090 --> 00:37:51.550
Нужно ли что-то ограничивать?

00:37:54.620 --> 00:37:56.420
Честно говоря, это большой вопрос.

00:37:56.420 --> 00:38:03.200
Вам нужно учитывать различные факторы, но для меня самое важное – это понимать свои данные.

00:38:06.290 --> 00:38:11.490
Если компания не понимает данные, это будет проблемой на начальном этапе, честно говоря.

00:38:12.690 --> 00:38:13.870
Хорошо. И?

00:38:14.330 --> 00:38:18.220
Когда мы? Как?

00:38:20.640 --> 00:38:20.880
Мы?

00:38:22.940 --> 00:38:24.660
Хорошо. Спросите об этом.

00:38:27.240 --> 00:38:28.340
Тема безопасности.

00:38:31.130 --> 00:38:32.430
Я думаю, есть два.

00:38:36.460 --> 00:38:37.160
Типа людей.

00:38:37.160 --> 00:38:45.020
Один говорит, хорошо, им нужны права доступа пользователей, а другой, им нужны права доступа приложений.

00:38:49.470 --> 00:38:54.630
Как агент должен работать в целом?

00:38:56.790 --> 00:39:02.030
Моя лучшая рекомендация, когда вам нужно работать с решением агентик, всегда используйте.

00:39:02.030 --> 00:39:16.650
Делегированные права доступа пользователей, потому что с точки зрения безопасности это, честно говоря, лучше, так как пользователь будет работать только с теми данными и инструментами, которым у него есть доступ.

00:39:18.680 --> 00:39:19.820
Это главный принцип.

00:39:21.380 --> 00:39:28.520
После этого, если вам нужны права доступа приложений для конкретного API, конкретного контекста, вы можете это сделать.

00:39:28.520 --> 00:39:37.300
Но не используйте права доступа приложений напрямую, используйте их в контексте оболочки.

00:39:41.590 --> 00:39:48.230
Например, создайте сервер MCP и интегрируйте этот MCP с правами доступа приложений в фоновом режиме.

00:39:52.120 --> 00:40:04.960
Итак, MCP будет вызывать, например, ваш API в фоновом режиме с правами доступа приложения, и после этого предоставит вам необходимую информацию, но пользователь не будет напрямую взаимодействовать с правами доступа приложения.

00:40:04.960 --> 00:40:18.580
Мы вызываем, например, сервер MCP с правами доступа пользователя, и сервер MCP будет вызывать в фоновом режиме приложения или сервисы с выделенными правами доступа приложения.

00:40:18.940 --> 00:40:19.800
Видите разницу?

00:40:21.820 --> 00:40:22.320
Хорошо.

00:40:23.860 --> 00:40:24.540
Интересно.

00:40:25.840 --> 00:40:31.140
Я думаю, когда мы думаем об архитектуре, мы также должны немного углубиться в нее.

00:40:34.080 --> 00:40:37.140
Я думаю, есть три основные темы в архитектуре.

00:40:37.140 --> 00:40:46.640
У нас есть генерация аргументов для извлечения данных, у нас есть темы знаний и, я бы сказал, бэкдорный корпоративный поиск.

00:40:51.940 --> 00:40:53.040
Давайте начнем с рек.

00:40:54.240 --> 00:40:56.760
Какое место занимает рек в архитектуре?

00:40:58.520 --> 00:40:59.580
Ах, RAG.

00:40:59.580 --> 00:41:17.840
Честно говоря, RAG – это, пожалуй, самый эффективный инструмент с точки зрения производительности, потому что и должен понимать разные типы данных, и, по сути, RAG предназначен для ответа на вопросы.

00:41:21.660 --> 00:41:28.210
Раньше, без RAG приходилось использовать другие подходы.

00:41:28.210 --> 00:41:31.690
Не устаревшие, но сложные.

00:41:35.500 --> 00:41:46.080
RAG же играет центральную роль, потому что он понимает разные типы данных и позволяет получать необходимую информацию, даже если документы содержат множество различных типов данных.

00:41:46.080 --> 00:41:54.420
Так что да, RAG сегодня является центральным элементом архитектуры ИИ.

00:41:55.400 --> 00:41:55.700
Да.

00:41:59.660 --> 00:42:13.880
Но правда в том, что многие пользователи, когда речь заходит о RAG, не знают, что это такое, потому что Microsoft и многие другие компании-разработчики программного обеспечения сейчас об этом не говорят, потому что за кулисами работает RAG.

00:42:13.880 --> 00:42:24.910
Например, в Copilot Studio пользователь не понимает, что это такое, и понимает, что это такое.

00:42:25.650 --> 00:42:38.290
И сегодня, когда вы хотите углубиться в тему, у вас есть подобная концепция, но для многих пользователей RAG совершенно неизвестен, потому что они просто используют инструмент, и за кулисами есть эти концепции.

00:42:38.290 --> 00:42:49.940
А затем у нас есть следующая тема, это знания, как мы их получаем, откуда системы и получают свои знания, как они их собирают, как это работает.

00:42:56.650 --> 00:42:58.450
Честно говоря, знания могут

00:42:58.450 --> 00:43:03.520
Храниться во множестве

00:43:03.520 --> 00:43:07.340
Разных систем

00:43:07.340 --> 00:43:13.820
Это может быть обычный текстовый файл, файл Markdown, база знаний, что угодно.

00:43:13.820 --> 00:43:20.820
Но на самом деле, если у вас есть сервер MCP, вы можете получить доступ к этим знаниям.

00:43:20.820 --> 00:43:30.820
Или, например, если у вас есть коннектор к SharePoint, коннектор ко многим сервисам, доступ к знаниям стал проще, чем раньше, давайте будем честны.

00:43:30.820 --> 00:43:35.820
Потому что раньше вам нужно было создавать свой плагин и просматривать все.

00:43:35.820 --> 00:43:44.820
Сегодня у вас есть прямой коннектор к любой системе, вы можете интегрировать свои знания, не имея дела с большим эээ, большим штатом разработчиков.

00:43:44.820 --> 00:43:52.940
Я думаю, что часто мы, не знаю, собираем, я говорю своим, не знаю, ребята.

00:43:52.940 --> 00:44:08.110
И как? И понимает, что? Документы не готовы, или устарели, или, не знаю, дублируются.

00:44:08.110 --> 00:44:18.690
Как? Как? Как система и может это понять? Что нам следует использовать и что?

00:44:18.690 --> 00:44:28.740
В общем, вы используете RAG, потому что, по сути, вам нужно понимать, что представляют собой ваши данные, но...

00:44:28.740 --> 00:44:35.980
Честно говоря, если я немного подытожу, вы начинаете с запроса, хорошо?

00:44:35.980 --> 00:44:48.550
Пользователь хочет, например, выполнить поиск в базе знаний или, например, на OneDrive.

00:44:48.550 --> 00:45:01.320
По сути, когда оркестратор с помощью LM понимает запрос и намерения пользователя, за кулисами у вас есть индекс.

00:45:01.320 --> 00:45:14.400
Например, в Copilot есть семантический индекс, и этот индекс, по сути, дает вам всю необходимую информацию, и вы можете с помощью запроса к семантическому индексу.

00:45:14.400 --> 00:45:18.710
И напрямую обращаться к нему для выполнения.

00:45:18.710 --> 00:45:26.990
Например, RAG запроса, и вы можете напрямую выбирать нужные документы в соответствии с вашими потребностями.

00:45:26.990 --> 00:45:34.990
Но в Copilot у вас есть семантический индекс, и, и может напрямую обращаться к нему с помощью естественного языка.

00:45:34.990 --> 00:45:44.740
Например, я спрашиваю, я хочу понять, как настроить VPN-сеть моей компании.

00:45:44.740 --> 00:45:55.740
И за кулисами вы выполняете RAG запрос к семантическому индексу и, по сути, извлекаете документ, содержащий, например, все настройки VPN-сети компании.

00:45:55.740 --> 00:46:06.740
Например, в чате Microsoft 365 Copilot, по сути, используется граф API, потому что, как я уже говорил, семантический индекс построен на основе граф API.

00:46:06.740 --> 00:46:15.740
Это функция граф, работающая за кулисами, но, когда вы занимаетесь собственной разработкой, за кулисами используется, например, Foundry EQ.

00:46:15.740 --> 00:46:23.740
Раньше это был сервис Azure с другим названием, но теперь вы можете использовать собственную систему RAG, если хотите.

00:46:23.740 --> 00:46:28.740
И, по сути, когда у вас есть собственный агент, вы можете напрямую запросить.

00:46:28.740 --> 00:46:32.740
Экземпляр Foundry EQ. Хорошо.

00:46:32.740 --> 00:46:40.740
Я хочу использовать, я хочу получить настройки моей VPN-компании, и, и сможет найти-то, что вам нужно в плане документов.

00:46:40.740 --> 00:46:45.740
Это могут быть PDF-файлы, Word, Excel и тому подобное.

00:46:45.740 --> 00:46:54.860
И, вот так работает поиск, верно?

00:46:54.860 --> 00:47:02.540
Или, вы имеете в виду, за кулисами?

00:47:02.540 --> 00:47:03.540
Да.

00:47:03.540 --> 00:47:05.540
А, за кулисами.

00:47:05.540 --> 00:47:07.540
Да, у вас есть поиск.

00:47:07.540 --> 00:47:16.500
В общем, сейчас, в основе работы Copilot и Copilot Chat лежат три функции.

00:47:16.500 --> 00:47:22.500
Стандартный поиск, который представляет собой поиск по ключевым словам, которые вы просто вводите.

00:47:22.500 --> 00:47:29.980
В документы и так далее.

00:47:29.980 --> 00:47:35.980
Это простой поиск, известный всем, как поиск по ключевым словам в Google.

00:47:35.980 --> 00:47:41.540
Затем у вас есть две другие функции.

00:47:41.540 --> 00:47:46.540
Во-первых, это функция RAG, ресурс Agile в Graph API, а также.

00:47:46.540 --> 00:48:00.990
Семантический индекс поиска Copilot, который немного отличается, поскольку RAG гораздо более продвинут, чем семантический индекс поиска Copilot.

00:48:00.990 --> 00:48:09.340
Все эти три функции работают за кулисами, чтобы ваш.

00:48:09.340 --> 00:48:15.340
И и мог использовать их для извлечения данных из OneDrive, Teams и M365 в целом.

00:48:15.340 --> 00:48:23.330
Он может включать в себя семантический индекс Copilot, а также коннекторы Copilot.

00:48:23.330 --> 00:48:35.330
Например, если у вас есть подключенный Salisforce к коннектору Copilot, он также может осуществлять поиск по всем вашим данным в Salisforce, в ServiceNow, в нескольких инструментах.

00:48:35.330 --> 00:48:45.330
Потому что с помощью коннектора Copilot вы интегрируете все данные в Graph, Index, семантический индекс и можете напрямую запрашивать данные из внешних систем.

00:48:45.330 --> 00:48:51.580
Ага. Хорошо. И я думаю, что.

00:48:51.580 --> 00:49:07.410
Когда мы создаем агентов, у нас есть часть, связанная с управлением, и одна из частей, которую я бы назвал управлением жизненным циклом агента, как это выглядит на самом деле.

00:49:07.410 --> 00:49:10.410
Как это выглядит на самом деле?

00:49:10.410 --> 00:49:16.410
Честно говоря, в экосистеме Microsoft это довольно просто, если можно так сказать.

00:49:16.410 --> 00:49:27.410
Потому что, когда вы работаете с LowCode, например, Compiler Studio, вы работаете с четырьмя платформами, концепцией управления жизненным циклом, IAM, и ничего не изменилось.

00:49:27.410 --> 00:49:31.410
Итак, у вас есть решение, у вас есть ALM, у вас есть конвейер.

00:49:31.410 --> 00:49:41.410
Честно говоря, при работе с Copilot Studio все то же самое, что и раньше, потому что у вас есть все те же инструменты, что и раньше, включая управление жизненным циклом Power Platform ALM.

00:49:41.410 --> 00:49:44.410
Это абсолютно то же самое.

00:49:44.410 --> 00:49:50.410
И это хорошо, потому что многие спрашивают меня, о, Competitive Studio, как вы управляете?

00:49:50.410 --> 00:49:51.410
Это отличается?

00:49:51.410 --> 00:49:57.410
Нет, все очень просто, как для приложений или Core Automate – управление жизненным циклом приложений.

00:49:57.410 --> 00:50:04.410
В данном случае это управление жизненным циклом агентов, но за кулисами та же концепция, что и у Core Platform.

00:50:04.410 --> 00:50:06.410
А когда вы работаете?

00:50:06.410 --> 00:50:19.520
Например, с пользовательской разработкой это, по сути, то же самое, что и при создании приложений, NIT-приложений и тому подобного, потому что вы управляете всем как кодом.

00:50:19.520 --> 00:50:24.520
У вас есть фреймворки, аспекты безопасности и тому подобное.

00:50:24.520 --> 00:50:33.520
Так что, честно говоря, все, что касается управления жизненным циклом приложений и агентов – это та же самая концепция, что и раньше.

00:50:33.520 --> 00:50:43.060
И это для меня важный момент, потому что вам не нужно много инвестировать в процесс жизненного цикла, в подобные вещи.

00:50:43.060 --> 00:50:53.060
Единственное изменение, которое у вас есть – это, хорошо, вам нужно позаботиться о LLM, подобных вещах, развертывании, подобных вещах.

00:50:53.060 --> 00:51:00.060
Но за кулисами это выглядит так же, как и раньше, с подходом DevOps, с конвейером и подобными вещами.

00:51:00.060 --> 00:51:05.060
Поэтому, на мой взгляд, ничего не изменилось, потому что мы управляем агентами.

00:51:05.060 --> 00:51:13.060
Это может быть разработка на заказ или копирование, но, честно говоря, сейчас подход тот же, что и раньше.

00:51:13.060 --> 00:51:14.060
И.

00:51:14.060 --> 00:51:41.900
Это означает, что когда компания не использует ИИ до его внедрения, но у нее есть идеальная настройка для предварительного просмотра Defender и всех остальных инструментов, есть ли какие-либо изменения, которые нужно внести, или это означает готовность к ИИ.

00:51:41.900 --> 00:51:46.900
Ах, это очень важный вопрос, потому что готовность к ИИ.

00:51:46.900 --> 00:51:53.900
Для Microsoft, ИИ, в порядке, ИИ, вы оттачиваете навыки управления, решаете подобные вопросы.

00:51:53.900 --> 00:52:01.900
Но, ИИ, готовность для меня, это не только технический подход, потому что, хорошо, с технической точки зрения мы знаем, что делать.

00:52:01.900 --> 00:52:06.900
Хорошо, нам нужно управлять правами доступа во многих сервисах, понимаете.

00:52:06.900 --> 00:52:10.900
Для меня готовность к ИИ должна также включать в себя.

00:52:10.900 --> 00:52:16.900
Данные, данные, понимаете, потому что, ИИ, когда вы не понимаете свои данные,

00:52:16.900 --> 00:52:32.900
Как я уже говорил, ИИ, вы не можете, ИИ, вы не можете управлять технической частью, потому что, ИИ, когда вы не знаете, что является конфиденциальным, а что нет, например, ИИ, трудно внедрить какие-то меры безопасности, какие-то меры безопасности.

00:52:32.900 --> 00:52:45.900
Но если мы, если следовать примеру Microsoft, готовность к ИИ, это нормально, нужно управлять разрешениями, устанавливать метки конфиденциальности, соблюдать GLP, Global Lineage Price и тому подобное.

00:52:45.900 --> 00:52:54.220
Но есть и более высокий уровень.

00:52:54.220 --> 00:53:03.220
И для меня готовность к ИИ, это не только технический аспект, честно говоря, сегодня нужно учитывать и функциональный или высокоуровневый аспект.

00:53:03.220 --> 00:53:09.610
Да, это действительно интересно.

00:53:09.610 --> 00:53:23.030
Я думаю, многие компании, начав с ИИ, теперь с агентов, говорят, о, он удалил все мои электронные письма или делает что-то ужасное.

00:53:23.030 --> 00:53:32.570
Как вы думаете, что скажут компании, что боятся ИИ?

00:53:32.570 --> 00:53:52.530
Это хороший вопрос, потому что я живу в Швейцарии и у нас, в основном, много частных банков и, честно говоря, у нас много очень чувствительных клиентов и, в основном, самая важная часть – это «хорошо», где обрабатываются данные.

00:53:52.530 --> 00:54:03.140
И, да, также, ищет ЛИИ, мои электронные письма и тому подобное.

00:54:03.140 --> 00:54:23.700
Так что за кулисами они всегда задают этот вопрос, но, знаете, самая важная часть для них – это «хорошо», мне нужно понять, где обрабатываются данные, и, также, «хорошо», я являюсь владельцем ИИ.

00:54:23.700 --> 00:54:29.700
Итак, я даю инструкцию ИИ, и ИИ, работающий за кулисами, выполняет эту работу.

00:54:29.700 --> 00:54:43.340
Они боятся, например, автономного аспекта, потому что «сегодня, хорошо, вы можете это сделать, а за кулисами и будет что-то искать, задавать вопросы, что-то делать за кулисами».

00:54:43.340 --> 00:54:51.780
И они боятся «что, когда я прошу ИИ, что-то сделать, что он делает за кулисами».

00:54:51.780 --> 00:54:55.780
И да, таких вопросов много. Хорошо.

00:54:55.780 --> 00:55:02.780
Как мне взять под контроль весь процесс, стоящий за этим, будь то и агент или и сервис?

00:55:02.780 --> 00:55:19.330
Да, есть несколько подобных вопросов, но это действительно вопрос внедрения, а также обучения, чтобы внедрить некоторую подготовку, чтобы понять, как понимать и, как понимать, что именно делается за кулисами.

00:55:19.330 --> 00:55:39.200
Прозрачность – это тоже очень важный момент, потому что прозрачность должна быть внедрена в каждое решение на основе и, потому что для меня это очень важная тема, ведь нужно внедрить все, что необходимо, потому что ваше решение на основе и должно быть прозрачным.

00:55:39.200 --> 00:55:48.200
Нужно понимать, что происходит за кулисами, какие данные запрашиваются, нужно отслеживать, нужно все регистрировать.

00:55:48.200 --> 00:56:00.200
Поэтому все должно быть прозрачным, когда у вас есть решение в наше время, потому что нужно точно понимать, что происходит за кулисами, какие данные обрабатываются и какова логика всего этого.

00:56:00.200 --> 00:56:08.200
Хорошо. Как вы разработали этот план, основываясь на каких фактах и тому подобном?

00:56:08.200 --> 00:56:20.200
Замечательно. О, я вижу, у нас немного не хватает времени. Так что, да, извините. Знаете, это было действительно потрясающе. Но в каждом подкасте у меня есть блиц-опрос.

00:56:20.200 --> 00:56:29.200
То есть, я даю короткое предложение, а вы даете короткий ответ. Итак, вы готовы?

00:56:29.200 --> 00:56:43.200
Да. Капайлот Студия или собственный код. Капайлот Студия. Майкрософт Фаундри или Капайлот Студия. Капайлот Студия. Тайпскрипт или Сайпескрипт.

00:56:43.200 --> 00:57:12.260
Гитхаб или Азур Дефопс. Гитхаб. Рек или Тонкая настройка. Хорошо. Какой самый недооцененный АПИ Майкрософт 365? АПИ РАК РАК. Технология, которую каждый разработчик Майкрософт должен изучить в 2026 году.

00:57:12.260 --> 00:57:28.520
Гитхаб Капайлот. Когда Сатьяни далее придет к вам и скажет, дайте нам все деньги и ресурсы, которые вы хотите, чтобы улучшить нашу платформу и вы можете разработать одну функцию. Что это будет?

00:57:29.660 --> 00:57:53.820
Все необходимые нам инструменты управления. И? Кого мне пригласить на подкаст и какой вопрос задать? О, хороший вопрос. У меня много друзей, но да, может быть, вы можете пригласить меня.

00:57:54.040 --> 00:58:05.220
У меня есть садокладчик на многих конференциях. Вы можете пригласить, например, Хлою Мора. Она раньше работала функциональным консультантом, а теперь занимается технической стороной.

00:58:07.080 --> 00:58:12.460
У нее очень интересная история о функциональном и менее техническом аспектах в мире Dynamics.

00:58:12.460 --> 00:58:24.580
Так что, может быть, вы могли бы пригласить ее и спросить, как сейчас совмещать функциональную и техническую работу, потому что здесь есть очень большие проблемы.

00:58:26.960 --> 00:58:27.140
Да.

00:58:28.040 --> 00:58:34.420
И мой заключительный вопрос, что люди должны почерпнуть из этой сессии, если могут, что им следует вынести.

00:58:34.420 --> 00:58:43.340
Из нее вы имеете в виду, что и быстро развивается.

00:58:43.340 --> 00:58:56.580
И если вы хотите быть в курсе событий, вам нужно следить за всем, потому что сегодня и действительно присутствует во всех аспектах Microsoft, если честно.

00:58:56.580 --> 00:59:18.710
В наши дни одна из вещей, которую вам нужно понимать, это то, что эволюция происходит быстро, и вам нужно быть в курсе событий, действительно, действительно, всегда, потому что вы что-то упустите в какой-то момент, если вы, если вы, если вы, если вы, если вы не, если вы, если вы не учитесь, если вы не понимаете эволюцию в этом отношении.

00:59:21.300 --> 00:59:24.480
Да, так что да, спасибо, что присоединились ко мне.

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

00:59:38.540 --> 00:59:48.000
Я думаю, мы движемся к архитектуре, где Copilot и агенты могут связывать организационные знания, Microsoft Graph, бизнес-приложения, AP и так далее.

00:59:48.000 --> 00:59:58.200
Да, я думаю, что Copilot Studio, Microsoft Phone 3, пользовательская разработка и такие технологии, как MCP, предоставляют разработчикам, да.

00:59:59.280 --> 01:00:01.500
Удивительный, мощный набор инструментов.

01:00:02.760 --> 01:00:17.520
Да, и еще, чем более способными становятся агенты, тем важнее становятся и фундаментальные принципы идентификация, разрешение, безопасность, управление, тестирование, наблюдаемость, управление жизненным циклом приложений и так далее.

01:00:17.520 --> 01:00:24.040
Так что да, я думаю, вы дали действительно очень хороший обзор всех этих тем.

01:00:25.780 --> 01:00:37.680
Спасибо, что присоединились ко мне и всем слушателям вся информация, которую вы найдете в примечаниях к выпуску на странице подкаста MC65FM, а также информация о работе ИЕС.

01:00:38.880 --> 01:00:44.440
Спасибо, что были здесь. Спасибо, что пригласили меня. Было очень приятно провести с вами время.