WEBVTT

00:00:00.000 --> 00:00:04.740
Вы кликнули, потому что в подкасте сказали, что Azure iPhone 3 – это ловушка. Верно? Хорошо.

00:00:04.980 --> 00:00:10.280
Вы попали по адресу. Сразу к делу. Капайлот бесполезный без опоры на факты, но такие инструменты,

00:00:10.380 --> 00:00:15.340
как RAG, генерация с дополнением выборкой, вместе с гибридным семантическим поиском Azure AI

00:00:15.340 --> 00:00:19.660
и оценщиками обоснованности, релевантности и согласованности – это реальные решения,

00:00:19.820 --> 00:00:23.980
которые не дадут вам выдавать галлюцинации за ответы. Мы отбросим маркетинговые презентации

00:00:23.980 --> 00:00:27.740
и покажем вам руководство по выживанию на реальных примерах из практики. Подписывайтесь

00:00:27.740 --> 00:00:32.880
на рассылку M365 Show и следите за прямыми эфирами с экспертами MVP. Именно там обсуждают

00:00:32.880 --> 00:00:36.700
реальные ошибки и способы их исправления. А поскольку первые трещины обычно появляются в

00:00:36.700 --> 00:00:40.380
мультимодальных приложениях, давайте начнем с них. Почему мультимодальные приложения терпят

00:00:40.380 --> 00:00:43.640
неудачу в реальном мире? Когда вы видите мультимодальную демонстрацию на сцене,

00:00:43.760 --> 00:00:47.720
она выглядит безупречно. Докладчик вводит текстовый запрос, чистое изображение, может быть,

00:00:47.820 --> 00:00:51.400
даже голосовую команду, и модель выдает идеальный график или четкое резюме контракта.

00:00:51.500 --> 00:00:54.820
Все это кажется магией, но как только вы пытаетесь применить это в реальной компании,

00:00:54.820 --> 00:00:58.920
магия быстро рассеивается. Демонстрации работают на идеальных данных. В работе мы

00:00:58.920 --> 00:01:03.200
сталкиваемся с мусором. В этом вся разница. В продакшене никто не будет давать вашей модели

00:01:03.200 --> 00:01:07.980
аккуратно подготовленные скриншоты или CSV-файлы, отформатированные по стандартам. Отдел кадров

00:01:07.980 --> 00:01:11.960
подсовывает смазанные копии удостоверений личности. Отдел закупок загружает PDF-файлы,

00:01:12.100 --> 00:01:16.140
которые прошли через пять циклов факса. Кто-то в бухгалтерии фотографирует счет на камеру

00:01:16.140 --> 00:01:20.380
разбитого Android-смартфона. Мультимодальные модели могут работать с текстом, изображениями,

00:01:20.500 --> 00:01:24.040
голосом и видео, но для работы в сложных условиях им нужны хорошо проиндексированные

00:01:24.040 --> 00:01:28.180
данные и поиск. Иначе вы просто просите модель импровизировать на основе мусора. И никакие

00:01:28.180 --> 00:01:32.560
затраты на GPU не исправят ситуацию «мусор на входе, мусор на выходе». Здесь на помощь должна

00:01:32.560 --> 00:01:36.880
прийти генерация с дополнением выборкой или arranging. Простыми словами, модель не знает вашего

00:01:36.880 --> 00:01:41.220
бизнеса, поэтому вы подключаете ее к источнику знаний. Она извлекает фрагмент данных и формирует

00:01:41.220 --> 00:01:45.840
на его основе ответ. Если поиск точен, вы получаете полезные и обоснованные ответы. Если он небрежен,

00:01:46.000 --> 00:01:50.080
модель начинает фантазировать, уверенно выдавая бессмыслицу. И именно так вы получаете чат-бота,

00:01:50.080 --> 00:01:54.160
который клянется, что у вашей компании новая скидочная политика на третий квартал, который не

00:01:54.160 --> 00:01:59.540
существует. Модель не обрела сознание, она просто вытянула не те данные. Azure iStudio и Azure iFoundry

00:01:59.540 --> 00:02:04.480
опираются на этот шаблон и поддерживают все типы модальностей — язык, зрение, речь и даже поиск

00:02:04.480 --> 00:02:08.660
по видео. Но подвох в том, что Rage хорош ровно настолько, насколько хороши его данные. Вот ключевой

00:02:08.660 --> 00:02:12.440
момент, который упускает большинство команд. Нельзя просто подключить один метод поиска и считать,

00:02:12.600 --> 00:02:16.500
что этого достаточно. Чтобы результаты были качественными, вам нужен гибридный поиск по ключевым словам

00:02:16.500 --> 00:02:20.240
и векторам, дополненный семантическим переранжированием, встроенным в Azure iStudio. Это позволяет

00:02:20.240 --> 00:02:23.300
системе сопоставлять буквальные совпадения по ключевым словам с семантическим смыслом,

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

00:02:26.160 --> 00:02:30.160
Внедрите это в свою мультимодальную систему, и модель внезапно сможет работать с кривыми сканами

00:02:30.160 --> 00:02:33.900
и нечеткими изображениями, вместо того, чтобы выдумывать правила комплаенса из ниоткуда.

00:02:34.020 --> 00:02:37.180
Теперь давайте обсудим, почему так много запусков терпят неудачу.

00:02:37.180 --> 00:02:42.300
Компании ожидают безупречных результатов с первого же дня, но не закладывают бюджет на циклы оценки.

00:02:42.300 --> 00:02:46.780
Без фоновой проверки на обоснованность, релевантность и логичность вы не заметите отклонений,

00:02:46.960 --> 00:02:51.500
пока пользователи уже не пострадают. Многие ранние внедрения проваливаются именно по этой причине.

00:02:51.680 --> 00:02:55.460
Результат звучит правильно, но никто не сверил его с первоисточником. Подумайте сами,

00:02:55.680 --> 00:02:58.700
вы бы никогда не запустили новую базу данных без мониторинга. Тем не менее,

00:02:58.860 --> 00:03:02.520
с мультимодальным и руководители внедряют его в продакшн, как будто это волшебная коробка,

00:03:02.520 --> 00:03:07.040
включи и работай. Этого финала можно избежать. Carvana – одна из историй успеха клиентов

00:03:07.040 --> 00:03:11.460
Foundry, подтверждающая это. Они сделали и для самообслуживания действительно полезным,

00:03:11.460 --> 00:03:16.020
настроив поиск, правильно обосновав своих агентов и вложившись в наблюдаемость. Это превратило то,

00:03:16.200 --> 00:03:20.000
что могло стать очередной игрушкой, в инструмент, которому клиенты могут доверять.

00:03:20.140 --> 00:03:24.300
А теперь сравните это с компаниями, которые просто прикрутили типичный чат-бот к странице

00:03:24.300 --> 00:03:28.640
поддержки без проверки и оценки. Вы видели результат. Гарантийные претензии попадают в отдел

00:03:28.640 --> 00:03:33.340
продаж, очереди поддержки раздуты, а репутация подорвана. Один и тот же стек Azur – противоположный

00:03:33.340 --> 00:03:38.460
результат. Итак, вот сухой остаток. Мультимодальный и рушится не потому, что он недостаточно умный.

00:03:38.460 --> 00:03:42.120
Он рушится, потому что данные не подготовлены, не проиндексированы и не контролируются.

00:03:42.280 --> 00:03:46.320
Загрузите мусор в поисковую систему, пропустите проверки и наблюдайте, как исчезает доверие.

00:03:46.440 --> 00:03:50.100
Но благодаря гибридному поиску, семантическому переранжированию и постоянным оценкам,

00:03:50.240 --> 00:03:54.220
вы можете обрабатывать счета, контракты, изображения и даже черные аудиозаметки с ответами,

00:03:54.360 --> 00:03:57.860
основанными на реальности, а не на фантазиях. И когда с обоснованностью покончено,

00:03:58.040 --> 00:04:02.120
на горизонте появляется новый риск. Ведь даже если конвейеры данных чисты, система,

00:04:02.280 --> 00:04:06.780
управляющая ими, может выйти из-под контроля. И здесь вопрос меняется. Помогает ли агент,

00:04:06.780 --> 00:04:11.560
координирующий все это вашему бизнесу, или он просто тихо превращает ваш ИТ-бюджет в топливо

00:04:11.560 --> 00:04:15.860
для костра? Полезный помощник или дорогой пресс-папье? Агент координирует модели,

00:04:16.140 --> 00:04:20.380
данные, трикгеры и действия. Представьте его в качестве регулировщика ваших автоматизированных

00:04:20.380 --> 00:04:24.840
рабочих процессов. Иногда он управляет всем гладко, а иногда впускает три самосвала и клоунскую

00:04:24.840 --> 00:04:29.340
машину, а затем уходит на обед. Этот разрыв между четким описанием и запутанной реальностью – место,

00:04:29.340 --> 00:04:33.960
где большинство команд теряют управление. На бумаге агент выглядит безупречно. Дайте ему инструкции,

00:04:33.960 --> 00:04:38.340
укажите путь к данным и приложениям, и он сможет запускать процессы, находить ответы и даже

00:04:38.340 --> 00:04:42.380
начинать рабочие циклы. Но это не идеальный коллега. Он с такой же вероятностью устранит

00:04:42.380 --> 00:04:45.920
повторяющуюся проблему в два часа ночи, как и завалит, в вашу очередь, сотней фантомных

00:04:45.920 --> 00:04:50.240
этикетов из-за неверно прочитанного журнала ошибок. Представьте его внутри сервис Now. При четко

00:04:50.240 --> 00:04:54.580
заданных рамках и создает реальные этикеты только для настоящих проблем – экономия часы работы

00:04:54.580 --> 00:04:58.120
сотрудников. Если оставить его без контроля, он может похоронить службу поддержки под ловиной ложных

00:04:58.120 --> 00:05:01.420
оповещений о критических збоях принтеров, которые исправно работают. Попробуйте объяснить такой

00:05:01.420 --> 00:05:05.100
прирост продуктивности своему ИТ-директору. Вот различия, которые многие упускают.

00:05:05.180 --> 00:05:09.240
Капайлот и агенты – это не одно и то же. Капайлот – это, по сути, помощник по работе с запросами.

00:05:09.380 --> 00:05:13.920
Вы спрашиваете, он отвечает, а вы сохраняете контроль. Агенты, напротив, принимают решения,

00:05:14.100 --> 00:05:18.280
не дожидаясь вас. Они дословно следуют вашим расплывчатым инструкциям, даже если результаты

00:05:18.280 --> 00:05:22.220
лишены смысла. Именно тогда автоматизация либо экономит реальное время, либо погружает вас в хаос,

00:05:22.340 --> 00:05:26.240
на устранение которого уйдет вдвое больше времени. Правда в том, что многие команды дают своему агенту

00:05:26.240 --> 00:05:30.440
описание вакансии, которая звучит как предвыборное обещание. Оптимизировать процессы, предоставлять

00:05:30.440 --> 00:05:34.460
инсайты, помогать людям. Поздравляю, вы фактически разрешили боту делать все, что заблагорассудится.

00:05:34.620 --> 00:05:37.620
Агенты без четких рамок не будут вежливо оставаться в своей зоне ответственности. Они будут

00:05:37.620 --> 00:05:41.580
суетиться. Они будут выдумывать проблемы для решения. Они будут дублировать записи. Они будут

00:05:41.580 --> 00:05:45.260
зацикливаться. А потом руководство удивляется, почему красивая демонстрация обернулась кошмаром в

00:05:45.260 --> 00:05:49.940
продакшене. Теперь давайте проясним ситуацию. Дело не в том, что большинство организаций терпит неудачу в первые

00:05:49.940 --> 00:05:54.000
два месяца. Этого нет в исследованиях. Что действительно происходит, и быстро, так это-то,

00:05:54.100 --> 00:05:57.840
что многие организации рано сталкиваются с преградами, потому что не ограничили рамки агентов,

00:05:58.000 --> 00:06:02.000
не добавили этапы проверки и не настроили телеметрию. Без этих защитных барьеров ваш блестящий

00:06:02.000 --> 00:06:05.280
новый инструмент — это просто безрассудный стажер с правами администратора. И вот здесь

00:06:05.280 --> 00:06:08.220
стек Майкрософт действительно предоставляет вам все необходимые инструменты.

00:06:08.220 --> 00:06:12.180
Капайлот Студия — это лоу-код среда, где разработчики проектируют поведение агента,

00:06:12.320 --> 00:06:16.320
потоки, промпты, трикгеры событий. Затем агент-сервис в составе iPhone 3 служит

00:06:16.320 --> 00:06:19.920
корпоративным фундаментом, который переводит агентов в продуктивную среду с возможностью

00:06:19.920 --> 00:06:24.900
наблюдения. В агент-сервис вы добавляете мониторинг, логи и метрики. Он специально разработан

00:06:24.900 --> 00:06:28.740
для автоматизации со встроенным контролем со стороны человека, потому что в Майкрософт знают,

00:06:28.860 --> 00:06:32.700
что будет, если выпустить непроверенного агента в дикую природу. Итак, как понять,

00:06:32.700 --> 00:06:36.780
полезен ли ваш агент на самом деле? Проверьте его с помощью простого контрольного списка.

00:06:36.940 --> 00:06:40.780
Первое, экономит ли он время сотрудников или заставляет вашу команду заниматься отладкой.

00:06:40.980 --> 00:06:44.800
Во-вторых, очлеживаете ли вы такие метрики, как обоснованность, беглость и связность,

00:06:44.800 --> 00:06:48.660
или просто лубуетесь красивыми маркетинговыми панелями? В-третьих, настроена ли у вас

00:06:48.660 --> 00:06:52.600
телеметрия, чтобы выявлять отклонения до того, как пользователи начнут жаловаться? Если вы

00:06:52.600 --> 00:06:56.100
ответили неверно на любой из этих вопросов, у вас нет интеллектуального агента. У вас просто

00:06:56.100 --> 00:07:00.800
очень дорогая заставка на экране. Выход, использовать функции наблюдаемости и встроенные

00:07:00.800 --> 00:07:05.820
оценщики Azure iPhone 3. Это не дополнительные опции, это проверенный способ измерения обоснованности,

00:07:06.020 --> 00:07:11.200
релевантности, связности и соответствия источникам. Без них вы лишь гадаете, умен ли ваш агент или он

00:07:11.200 --> 00:07:15.140
просто вежливо выдумывает факты. С ними вы можете уверенно вмешаться и настроить систему,

00:07:15.340 --> 00:07:19.100
когда результаты отклоняются от нормы. Итак, да, агенты могут изменить правила игры.

00:07:19.240 --> 00:07:22.460
При неправильном охвате они становятся усилителями хаоса, отнимающими больше времени,

00:07:22.620 --> 00:07:26.320
чем экономящими. При правильном охвате, с четкими границами задач, реальной телеметрии и

00:07:26.320 --> 00:07:29.820
обоснованными ответами они справляются с делами, пока люди заняты более важной работой.

00:07:29.900 --> 00:07:33.180
И как только кажется, что вы нашли баланс, ситуация снова меняется.

00:07:33.360 --> 00:07:37.200
Microsoft уже продвигает автономных агентов, ботов, которые не ждут ваших указаний,

00:07:37.200 --> 00:07:41.720
прежде чем действовать. Это переводит ставки из категории «помощник» или «балласт» в совершенно

00:07:41.720 --> 00:07:46.020
иную плоскость, ведь теперь речь о системах, работающих даже тогда, когда никто не следит.

00:07:46.260 --> 00:07:51.260
Ловушка автономных агентов. Автономные агенты – это момент, когда хайп становится опасным.

00:07:51.400 --> 00:07:55.560
На бумаге это звучит как мечта. Позвольте и действовать за вас. Автоматизируйте рутину и

00:07:55.560 --> 00:07:58.820
перестаньте вскакивать с кровати в 2 часа ночи, чтобы разгребать очередь этикетов.

00:07:58.960 --> 00:08:02.920
Звучит отлично на заседании совета директоров. Ловушка проста. Они не ждут разрешения.

00:08:02.920 --> 00:08:07.200
Капайлот ждет вашего подтверждения. Автономные агенты – нет. И когда они принимают неверные решения,

00:08:07.380 --> 00:08:10.740
ущерб наступает мгновенно и распространяется на весь ваш тенант. Концепция достаточно проста.

00:08:10.860 --> 00:08:14.240
Капайлот работает в реактивном режиме. Агенты работают проактивно. Вместо того,

00:08:14.340 --> 00:08:17.740
чтобы сидеть и ждать ввода команды, вы настраиваете агентов на контроль работоспособности сервисов,

00:08:17.840 --> 00:08:20.560
обработку сигналов безопасности или автоматический запуск рабочих процессов.

00:08:20.680 --> 00:08:24.020
Microsoft преподносит это как повышение эффективности, экономию человеческих ресурсов,

00:08:24.200 --> 00:08:28.440
быстрое обнаружение проблем и бесперебойную работу. Перспективы реальны, но вот важный контекст.

00:08:28.440 --> 00:08:32.360
Автономные агенты в Капайлот Студия сегодня все еще находятся в предварительной версии.

00:08:32.520 --> 00:08:36.660
Предварительная версия не значит «сломана», но это значит «не протестирована в реальных условиях».

00:08:36.660 --> 00:08:40.580
Даже Microsoft заявляет, что вам нужны механизмы управления жизненным циклом и консоль Капайлот,

00:08:40.700 --> 00:08:42.360
прежде чем задумываться о массовом развертывании.

00:08:42.580 --> 00:08:46.600
Рассмотрим реалистичный риск. Допустим, вы создали автономного агента техподдержки и наделили

00:08:46.600 --> 00:08:50.780
его полномочиями реагировать на аномалии при входе в систему. В демо-версии с пяти пользователями он работает

00:08:50.780 --> 00:08:54.900
идеально. Оповещения приходят, аккаунты управляются. Затем в промышленной эксплуатации появляются

00:08:58.440 --> 00:09:02.860
сотен учетных записей из-за ложных срабатываний. Результат – это не гипотетический сбой. Это

00:09:02.860 --> 00:09:07.280
вполне может парализовать операции в конце месяца. Это не научная фантастика. Это тот сценарий

00:09:07.280 --> 00:09:10.820
сбоя, на который вы подписываетесь, если игнорируете ограничения. Решение не в том, чтобы отказаться

00:09:10.820 --> 00:09:14.600
от технологий, а в том, чтобы сначала создать систему безопасности. Итак, каков же контрольный список

00:09:14.600 --> 00:09:18.320
для выживания? Три обязательных пункта перед любой эффектной автоматизацией. Первое – определение

00:09:18.320 --> 00:09:22.760
границ идентификации и доступа. Предоставьте агенту минимальные права, никаких общих прав администратора.

00:09:22.760 --> 00:09:27.500
Второе – логирование и откат. Каждое действие должно оставлять след, который можно проверить. И для

00:09:27.500 --> 00:09:32.180
каждого серьезного действия нужен путь отмены, если агент ошибся. Третье – фильтры контента и

00:09:32.180 --> 00:09:37.120
поведения. Майкрософт выделяет это через Azure iContent Софети и конфигурацию знаний. Фильтры,

00:09:37.240 --> 00:09:41.120
которые не дают рьяному боту генерировать неуместные ответы или отклоняться от сценария.

00:09:41.280 --> 00:09:45.260
Сделайте это сначала, иначе изобретательность вашего агента скорее погубит работу, чем поможет ей.

00:09:45.400 --> 00:09:49.260
Этический уровень делает этот вопрос еще острее. Представьте HR-агента, который автоматически

00:09:49.260 --> 00:09:52.740
помечает сотрудников как рискованных, или финансового агента, блокирующего платежи поставщикам,

00:09:52.840 --> 00:09:55.700
который он ошибочно классифицировал как мошенничество. Это не безобидные причуды,

00:09:55.820 --> 00:09:59.380
это сбои с последствиями для людей, влекущие за собой юридические проблемы и нарушения комплайнса.

00:09:59.500 --> 00:10:03.380
Предвзятость в обучающих данных или при поиске не исчезает просто потому, что вы работаете в

00:10:03.380 --> 00:10:07.640
корпоративной предварительной версии. Без фильтров, проверок и участия человека вы делегируете решения,

00:10:07.760 --> 00:10:10.720
которые ваши юристы точно не хотели бы доверять неконтролируемому алгоритму.

00:10:10.900 --> 00:10:14.260
Собственные сообщения Microsoft на конференции Ягниты были прямолинейны в этом вопросе.

00:10:14.380 --> 00:10:17.780
Ограничители, управление жизненным циклом, мониторинг и система контроля Капайлот – это

00:10:17.780 --> 00:10:21.420
неприятное дополнение, а обязательное требование. Предварительная версия сегодня – это не

00:10:21.420 --> 00:10:25.480
столько эффектные демо, сколько тестирования, выявляющие слабые места. Если вы запускаетесь

00:10:25.480 --> 00:10:29.460
без поэтапного тестирования, рабочих процессов утверждения и аудита, вы не запускаете агента,

00:10:29.640 --> 00:10:33.540
вы стресс-тестируете свой клиент в рабочей среде. Вот почему наблюдаемость – это не опция.

00:10:33.540 --> 00:10:37.100
Вам нужны панели мониторинга, которые показывают каждый шаг агента и проверяют,

00:10:37.240 --> 00:10:41.520
был ли его результат обоснованным, актуальным и соответствующим вашей политике. И вам нужны опции с

00:10:41.520 --> 00:10:46.100
участием человека. Microsoft этого не скрывает. Они ссылаются на шаблоны, где человек остается

00:10:46.100 --> 00:10:50.440
последним рубежом защиты. Подумайте об этом как об автопилоте в самолеты. Невероятно полезно,

00:10:50.580 --> 00:10:55.000
но всегда разработано с возможностью ручного управления. Если бот считает, что оптимальная посадка – в

00:10:55.000 --> 00:10:59.120
озере, вы захотите взять управление на себя до приземления на воду. Правильная аналогия здесь – позволить

00:10:59.120 --> 00:11:03.380
подростку учиться водить машину. Потенциал реален, скорость впечатляет, но вы не отдаете ключи,

00:11:03.500 --> 00:11:07.000
не уходите с подъездной дорожки, надеясь на лучшее. Вы садитесь на пассажирское сидение,

00:11:07.000 --> 00:11:11.400
устанавливаете границы и нажимаете на тормоза, если нужно. Это и есть управление жизненным циклом

00:11:11.400 --> 00:11:15.440
на практике. Тренировочные колеса – пока вы не убедитесь, что система не свернет с дороги. Это

00:11:15.440 --> 00:11:18.460
приводит нас на более масштабную производственную площадку, где объединяются агенты,

00:11:18.620 --> 00:11:22.380
копайлотс и все протестированные вами рабочие процессы. Microsoft называет это Azure iPhone 3

00:11:22.380 --> 00:11:26.760
универсальное пространство для создания и со всеми необходимыми инструментами. Станет ли это мощным

00:11:26.760 --> 00:11:31.780
производственным центром или местом, где ваш проект самоликвидируется, зависит только от вашего подхода.

00:11:31.780 --> 00:11:35.140
Azure iPhone 3 – ваша фабрика или ваше минное поле?

00:11:35.140 --> 00:11:40.560
Azure iPhone 3 – это новая флагманская концепция Microsoft, так называемая фабрика для любых

00:11:40.560 --> 00:11:45.400
задач и… В чем проблема? Слишком многие команды приходят туда и относятся к ней как к Икеа. Они

00:11:45.400 --> 00:11:49.820
бродят, ослепленные каталогами, хватают пару блестящих больших языковых моделей, добавляют

00:11:49.820 --> 00:11:54.300
коннекторы и собирают что-то без всяких инструкций. В итоге получается не корпоративная и система,

00:11:54.480 --> 00:11:58.520
а демонстрационная игрушка, которая ломается, как только реальный пользователь загружает запутанный

00:11:58.520 --> 00:12:03.480
PDF-файл. Вот что на самом деле предлагает Phone 3, согласно официальному руководству. Каталог моделей,

00:12:03.480 --> 00:12:08.440
включающий решения от Microsoft, OpenAI, Meta, Mistral, DeepSeq и других. Опции кастомизации,

00:12:08.700 --> 00:12:13.640
такие как генерация с дополненной выборкой, RAG, дообучение и дистилляция. Сервис агентов для

00:12:13.640 --> 00:12:18.860
оркестрации, инструменты вроде PromptFlow для оценки и отладки, базовые функции безопасности,

00:12:19.080 --> 00:12:23.980
контроль доступа, фильтры контента и панели мониторинга. Короче говоря, здесь есть все компоненты

00:12:23.980 --> 00:12:27.780
для создания копайлотс, агентов и автономных потоков с соблюдением всех требований.

00:12:27.920 --> 00:12:31.340
Это и есть инвентарь. Проблема не в том, что ящик с инструментами пуст, а в том,

00:12:31.340 --> 00:12:35.500
что многие администраторы просто переключают тумблер GPT-4 Turbo и называют это «готовым к

00:12:35.500 --> 00:12:39.660
производству». Правда в том, что Phone 3 – это цех, а не коробка с игрушками для хакатона.

00:12:39.820 --> 00:12:44.000
Это значит установить границы доступа, чтобы только нужные люди работали с нужными моделями.

00:12:44.120 --> 00:12:48.340
Это значит внедрить фильтры безопасности контента в каждый конвейер. Это значит использовать

00:12:48.340 --> 00:12:52.900
мониторинг, чтобы различать обоснованные ответы и ситуации, когда модель выдумывает политику

00:12:52.900 --> 00:12:57.740
компании из головы. И это значит выбирать подходящую модель для задачи, а не просто самую большую,

00:12:57.740 --> 00:13:01.980
потому что она звучит солидно. Пропустите эти шаги, и хаос войдет через заднюю дверь.

00:13:02.120 --> 00:13:05.640
Я видел, как команда подключила Phone 3 Copilot к SharePoint, который радостно выложил

00:13:05.640 --> 00:13:09.840
конфиденциальные данные HR-20 стажерам. Это было не умно, это была катастрофа с соблюдением норм,

00:13:10.020 --> 00:13:12.220
которой можно было избежать с помощью встроенных правил доступа.

00:13:12.320 --> 00:13:16.460
Давайте поговорим о реальных сценариях сбоев. Одна организация использовала GPT-4 Turbo

00:13:16.460 --> 00:13:21.420
для тегирования фотографий товаров. В лаборатории она блестяще справилась с демо. Чистые студийные фото,

00:13:21.660 --> 00:13:26.140
идеальные теги – все аплодировали. В реальности на входе были не глянцевые JPG,

00:13:26.140 --> 00:13:30.700
а размытые снимки с телефона на складе. Внезапно и начал помечать детские коляски,

00:13:30.840 --> 00:13:34.400
как офисные стулья, а UPC-коды превращать в вымышленные серийные номера.

00:13:34.580 --> 00:13:39.520
В дополнение к удару по доверию начали расти расходы. И это не сказка о цене в 1 цент за сообщение.

00:13:39.780 --> 00:13:43.360
Ценообразование Phone 3 основано на потреблении и привязано к конкретным используемым вами службам.

00:13:43.480 --> 00:13:46.520
Каждый коннектор, каждый запрос на извлечение данных, каждый тарифицируемый объем сообщений

00:13:46.520 --> 00:13:49.940
оплачивается в рамках вашего тенанта. У каждого компонента своя модель тарификации.

00:13:50.120 --> 00:13:53.780
Гибкость – это хорошо, но если вы не рассчитываете стоимость в калькуляторе Азур и не

00:13:53.780 --> 00:13:57.500
очлеживаете использование, ваш финансовый отдел будет в восторге от неожиданного счета.

00:13:57.640 --> 00:14:01.280
Это и есть ловушка Билллинга. Потребляемая модель оплаты работает, если вы планируете,

00:14:01.420 --> 00:14:04.860
очлеживаете и оптимизируете. В противном случае это похоже на использование спорткара в

00:14:04.860 --> 00:14:08.500
качестве мопеда для доставки пиццы. Дорого, шумно и бессмысленно. Мы все проходили это с тем же

00:14:08.500 --> 00:14:13.540
Power BI – отличная демо-версия. А потом – огромный счет. Не допустите, чтобы с Phone 3 вы оказались в той же ситуации.

00:14:13.740 --> 00:14:16.880
Разработчики любят прототипировать в Phone 3, потому что в песочнице выглядит очень удобно.

00:14:16.980 --> 00:14:20.340
И в песочнице это действительно так. Чистые демо-данные, никакого беспорядка,

00:14:20.460 --> 00:14:24.480
мгновенный вау-эффект. Но вот в чем подвох. Команды переводят этот прототип в продакшн без

00:14:24.480 --> 00:14:29.320
конвейеров оценки. Если вы пропускаете оценку на обоснованность, беглость, релевантность и связность,

00:14:29.460 --> 00:14:33.080
вы работаете вслепую. И что происходит? Пользователи видят отклонения в ответах,

00:14:33.260 --> 00:14:37.860
доверие падает, руководство урезает бюджет. Это не сбой Phone 3, это провал команд в вопросах управления.

00:14:37.860 --> 00:14:41.720
Многие прототипы Phone 3 застревают до этапа внедрения именно по этой причине. Никакой

00:14:41.720 --> 00:14:46.100
наблюдаемости, никаких проверок качества, никакой телеметрии. Решение уже есть в самой платформе.

00:14:46.260 --> 00:14:49.820
Используйте средства наблюдаемости Azure iPhone 3 с первого дня. Подключите потоки

00:14:49.820 --> 00:14:53.760
промптов. Запускайте встроенные оценщики для каждого теста. Обоснуйте свою систему с помощью

00:14:53.760 --> 00:14:57.600
Azure iSearch, используя гибридный поиск и семантическое переранжирование, прежде чем думать о запуске.

00:14:57.700 --> 00:15:01.180
Microsoft не прятала эти инструменты в приложении, они задокументированы для безопасного

00:15:01.180 --> 00:15:05.860
продакшена. Но разработчики слишком часто пролистывают их, как сноски. Такой менталитет контрольных

00:15:05.860 --> 00:15:09.860
точек — это то, что позволяет не попасть на минное поле. Относитесь к Phone 3 как к фабрике,

00:15:10.020 --> 00:15:13.600
где управление — это первый шаг. Политики соответствия внедрены как условный доступ,

00:15:13.780 --> 00:15:17.860
а конвейеры наблюдаемости работают с самого начала. И да, разграничения прав доступа и безопасность

00:15:17.860 --> 00:15:21.040
контента не должны добавляться потом, они должны быть в списке обязательных компонентов.

00:15:21.220 --> 00:15:25.300
Игнорируйте управление, и вы рискуете не только плохими ответами. Без него ваш мультимодальный

00:15:25.300 --> 00:15:29.860
бот может случайно раскрыть внешним пользователям зарплаты HR или пометить счета вымышленными номерами

00:15:29.860 --> 00:15:34.280
полисов. Это не просто сломанный ИИ, это заголовок в новостях, который ваш отдел комплайнса точно не захочет

00:15:34.280 --> 00:15:38.360
объяснять. И именно здесь фокус смещается, потому что следующий камень преткновения вовсе не

00:15:38.360 --> 00:15:42.840
технический. Вопрос в том, является ли ваш и ответственным. Все любят вставлять эти слова в слайды

00:15:42.840 --> 00:15:46.940
презентации, но на практике речь идет об аудитах, фильтрах, соблюдении требований и горе решений,

00:15:47.080 --> 00:15:50.600
которые вы принимаете до запуска. И именно здесь начинаются настоящие головные боли.

00:15:50.720 --> 00:15:54.680
Подписывайтесь на нас в новостной рассылке M365, шоу, чтобы получать прямые решения, и следите за

00:15:54.680 --> 00:15:59.380
обновлениями M365. Заходите на страницу в LinkedIn для просмотра прямых эфиров с MVP, которые тестировали

00:15:59.380 --> 00:16:03.420
Phone 3 в продакшене и знают, что может пойти не так. Ответственные ИИ или ответственные головные

00:16:04.280 --> 00:16:08.380
упоминать, ответственные ИИ в своих выступлениях. Это отлично смотрится рядом с модными словами

00:16:08.380 --> 00:16:12.580
вроде «справедливость» и «прозрачность». Но на деле это вовсе не вдохновляющая философия. Это

00:16:12.580 --> 00:16:16.980
конфигурации, аудиты, фильтры и процессы управления, которые больше похожи на обслуживание серверов,

00:16:17.080 --> 00:16:21.200
чем на инновации. Ответственные ИИ – это ремень безопасности, а не спортивный автомобиль. Пропустите

00:16:21.200 --> 00:16:25.420
его один раз, и авария произойдет очень быстро. Microsoft много говорит об этике и безопасности,

00:16:25.580 --> 00:16:29.360
но для администраторов, внедряющих это в жизнь, это означает практические защитные барьеры.

00:16:29.360 --> 00:16:33.500
Вам нужны политики доступа, которые не рухнут под нагрузкой, фильтры, реально блокирующие

00:16:33.500 --> 00:16:37.800
вредоносные запросы и журналы, достаточно детальные для регулятора с кофеином и повесткой в суд.

00:16:37.920 --> 00:16:42.400
Это не самая приятная работа. Это изоляция HR-копилотов от финансовых данных, настройка

00:16:42.400 --> 00:16:46.640
правил области действия, чтобы чат-боты не проникали в секреты SharePoint и маркировка логов,

00:16:46.800 --> 00:16:50.720
чтобы доказать, как именно был сформирован ответ. Если сделать все правильно, ответственность

00:16:50.720 --> 00:16:55.200
станет не корпоративным лозунгом, а условием выживания. Худший вариант пренебрежения этим – подключение

00:16:55.200 --> 00:16:58.840
бота напрямую к вашему HR-репозиторию без разграничения прав доступа в тенанте.

00:16:59.100 --> 00:17:04.000
Пользователь спрашивает о льготах по страхованию. Бот услужливо выдает в чат данные о зарплатных

00:17:04.000 --> 00:17:07.820
вилках сотрудников. Теперь у вас нарушение конфиденциальности, кошмар с моральным духом в

00:17:07.820 --> 00:17:11.960
коллективе и, возможно, регуляторы, дышащие вам в затылок. Самый быстрый способ убить внедрение – это

00:17:11.960 --> 00:17:15.820
неплохой интерфейс, а одна утечка конфиденциальных данных. Так что же защищает от этого хаоса?

00:17:15.940 --> 00:17:20.520
Начните с Azure iContent Sofetti. Он создан для фильтрации жестоких, непристойных и оскорбительных

00:17:20.520 --> 00:17:24.600
запросов и ответов, прежде чем они попадут к пользователям. Но это лишь базовая гигиена.

00:17:24.600 --> 00:17:29.260
Foundry и Copilot Studio используют конвейеры оценки, которые работают на следующем уровне.

00:17:29.380 --> 00:17:34.220
Проверка обоснованности, оценка релевантности, панели прозрачности и объяснимость результатов.

00:17:34.300 --> 00:17:37.600
Проще говоря, вы можете настраивать пороги срабатывания, фильтровать как входящие,

00:17:37.720 --> 00:17:41.460
так и исходящие данные и заставлять ботов показывать логику их работы. Без этого вы просто

00:17:41.460 --> 00:17:46.640
играете в кости с тем, что выдает i. А вот реальность с ресурсами. Microsoft вкладывает в это большие

00:17:46.640 --> 00:17:52.220
силы. 34 тысячи штатных инженеров, занимающихся безопасностью, плюс 15 тысяч партнеров с глубокой

00:17:52.220 --> 00:17:56.640
экспертизой в этой сфере. Это настоящая крепость. Но не спешите расслабляться. Ни один из этих

00:17:56.640 --> 00:17:59.740
инженеров не находится внутри вашего тенанта и не устанавливает там ваши правила доступа.

00:17:59.860 --> 00:18:03.480
Microsoft дает вам защитные барьеры, но именно ваша задача — настроить идентификацию,

00:18:03.640 --> 00:18:07.140
обеспечить изоляцию данных, применить шифрование и настроить политики. Если вы небрежно

00:18:07.140 --> 00:18:10.780
определили границы, ответственность за утечку все равно ляжет на вас. Настоящее решение — это

00:18:10.780 --> 00:18:14.920
управление жизненным циклом. Рассматривайте это как рецепт, который рекомендует сама Microsoft.

00:18:15.360 --> 00:18:20.480
Тестирование, утверждение, выпуск, аудит, итерация. Контрольные точки на каждом этапе позволяют

00:18:20.480 --> 00:18:24.280
заметить отклонения до того, как они попадут в заголовки новостей. Команды, которые выпускают

00:18:24.280 --> 00:18:28.260
продукт вслепую и забывают о нем, всегда терпят крах. Модели развиваются, промпты меняются,

00:18:28.460 --> 00:18:33.200
а результаты отклоняются от нормы. Управление — это не бурократия. Это способ помешать боту-стажеру

00:18:33.200 --> 00:18:37.660
выдумывать правила в Teams, пока все спят. Некоторые администраторы ворчат, что ответственный подход

00:18:37.660 --> 00:18:42.320
означает лишь замедление. Это неверный взгляд. Ответственность не убивает скорость, она не дает

00:18:42.320 --> 00:18:46.960
скорости убить вас. Грамотное управление позволяет проходить аудиты, не останавливая работу над проектами.

00:18:46.960 --> 00:18:50.340
Если проигнорировать это, вы совершите прыжок в пропасть. Скорость без контроля

00:18:50.340 --> 00:18:54.880
ведет лишь к одному рекорду — кратчайшему пути до разбора полетов. Представьте, что едете по

00:18:54.880 --> 00:18:59.200
горному серпантину. Вы не проклинаете отбойники, вы благодарите их, когда дорога обрывается на 60 метров

00:18:59.200 --> 00:19:03.580
вниз. С ответственным и все так же. Области охвата, политики, фильтры и журналы не снижают вашу

00:19:03.580 --> 00:19:08.220
скорость. Они берегут вас от попадания в вечерние новости. Суть в том, что Microsoft дала вам мощный

00:19:08.220 --> 00:19:15.020
инструментарий. Безопасность контента, пайплайны оценки, фреймворки защиты, SDK, но ограничивать тенанты,

00:19:15.220 --> 00:19:20.260
настраивать доступ и внедрять эти циклы в производство должны вы. Сделайте это, и ваш и выдержит

00:19:20.260 --> 00:19:24.160
проверку на соответствие требованиям, вместо того, чтобы рухнуть под их тяжестью. Проигнорируйте

00:19:24.160 --> 00:19:28.880
это, и возникнет риск не только сбоев, но и вашей карьеры. Ответственный ИИ — это немедленно.

00:19:29.120 --> 00:19:32.940
Ответственный ИИ — это жизнеспособность. И жизнеспособность — главный тест, ведь дело не в функциях,

00:19:32.960 --> 00:19:36.780
а в том, относитесь ли вы к платформе, как «подключил и забыл», или уважаете ее как инфраструктуру,

00:19:36.880 --> 00:19:41.460
где управление стоит на первом месте. Эта разница определяет, кто добьется успеха, а кто выиграет.

00:19:41.460 --> 00:19:46.780
Итог таков. Ловушка не в Foundry или Copilot Studio, а в мысли, что они работают по принципу «подключил и работай».

00:19:46.780 --> 00:19:50.340
Правило простое — сначала управление, потом эксперименты, в конце — производство.

00:19:50.500 --> 00:19:53.520
Игнорировать управление идентификацией и наблюдаемость — на ваш страх и риск.

00:19:53.700 --> 00:19:57.100
Инструменты есть, но только управление превращает прототипы в реальный продукт.

00:19:57.220 --> 00:20:01.120
Если вам нужны конкретные решения, которые помогут сохранить работоспособность вашего тенанта,

00:20:01.300 --> 00:20:04.560
подписывайтесь на подкаст и оставляйте отзывы. Я трачу на это ежедневно,

00:20:04.560 --> 00:20:08.660
и ваша поддержка мне очень помогает. Инструменты меняются, тактика выживания остается.