Latest / M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською / Copilot Studio чи Teams Toolkit: що обрати для агентів Copilot? (ШІ-дубляж)

Transcript

Copilot Studio чи Teams Toolkit: що обрати для агентів Copilot? (ШІ-дубляж) · M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською

• 0:00
  Впровадження Microsoft 365 Co-Pilot схоже на отримання легендарного предмета, поки не розумієш, що це лише базовий комплект.
• 0:06
  Відразу після встановлення він використовує базові знання, моделі та контент у вашому орендарі.
• 0:10
  Корисно, але як щодо ваших запилених інструкцій, кадрових регламентів чи тієї величезної ERP-системи в кутку.
• 0:16
  Без конекторів, граундингу або власних агентів Co-Pilot не зможе з ними взаємодіяти.
• 0:20
  Хороша новина, ви можете його навчити.
• 0:21
  Секрет у тому, щоб знати, коли використовувати Co-Pilot Studio, коли переходити на Teams Toolkit і як керування, моніторинг та ліцензування вписуються в процес.
• 0:28
  Тому що ось у чому справжня несподіванка.
• 0:30
  Створення першого агента – це не фінальна битва з босом. Це лише закінчення навчання.
• 0:34
  Створення – це не битва з босом.
• 0:36
  Ви тестуєте першого агента, запити працюють, демо-дані виглядають бездоганно і намить здається, що ви пройшли гру.
• 0:41
  Це пастка.
• 0:41
  Справжня робота починається, коли ви спрямовуєте цю ж збірку у продуктивне середовище, де діють зовсім інші правила.
• 0:46
  Багато розробників помилково вважають, що успішний тест означає виконання завдання.
• 0:50
  Насправді це лише сюжетний режим на легкому рівні складності.
• 0:53
  Продуктивному середовищу байдуже, що ваш прототип добре працював на ноутбуці розробника.
• 0:57
  Продакш не вимагає стабільності під навантаженням, перевірок на відповідність, захисту ідентифікації та стандартів без перебійної роботи.
• 1:04
  І ось тут з'являються перші боси.
• 1:07
  Масштабованість, чи витримає агент корпоративне навантаження без збоїв.
• 1:10
  Саме тут важливі моніторинг та діагностичні логи системи керування Coopilot.
• 1:15
  Застарілі дані, коли дані в SharePoint або Dataverse змінюються, чи підключається агент до потрібного знімка.
• 1:20
  Конектори та граундинг через граф є запобіжниками.
• 1:23
  Відповідність вимогам та можливість аудиту.
• 1:25
  Якщо регулятор або внутрішній аудитор запитає, чи можна переглянути історію агента з логами та мітками конфіденційності.
• 1:32
  Якщо щось із цього підведе, екран перемоги швидко зникне.
• 1:35
  Тестування в Coopilot Studio – це як спарринг на арені з нескінченними зіллями здоров'я.
• 1:40
  Ви можете чаклувати, змінювати запити, і все виглядає чудово, але в реальному використанні кожен блок-бранд Мауера – це провал,
• 1:47
  а перевантажене зовнішнє джерело даних сповільнює відповіді до мінімуму.
• 1:50
  Це момент, коли користувачі перестають вважати його розумним і починають подавати тікети.
• 1:54
  Найпоширеніша помилка виникає в командах, які відкладають управління на потім.
• 1:57
  Вони переконують себе, що це можна додати пізніше, але відкладання керування майже завжди призводить до неприємних сюрпризів.
• 2:03
  Проблеми з масштабуванням, невідповідність даних або прогалини в безпеці з'являються в найбільш невідповідний момент.
• 2:08
  Безпека та комплеєнс – це недодаткові квести.
• 2:11
  Це частина основної карти кампанії.
• 2:13
  Тепер поговоримо про архітектуру, адже мозок Coopilot – це не єдиний блок.
• 2:16
  У вас є базова модель, рушій обробки мови, а зверху – оркестратор, який визначає, які функції та коли викликати.
• 2:22
  Microsoft 365 Coopilot забезпечує таку оркестрацію за замовчуванням, тому кожен запит має структуру.
• 2:27
  Далі йде обґрунтування, драмдин, зв'язок із корпоративним контентом, щоб відповіді не були вигаданими.
• 2:32
  І, нарешті, навички, ваші власні плагіни чи конектори для виконання конкретних завдань.
• 2:36
  Якщо сприймати ці чотири елементи як окремі ізольовані блоки, вся конструкція стає хиткою.
• 2:40
  Надійна навичка без обґрунтування – це лише витончена галюцинація.
• 2:43
  Базова модель без засобів контролю відповідності стає джерелом ризиків.
• 2:46
  Лише коли ці рівні розглядаються як єдиний стек, агент залишається стійким.
• 2:49
  Отже, як виглядає успіх у реальних умовах?
• 2:52
  Це не просто влучна відповідь на демонстраційний запит.
• 2:54
  Це лише тренувальний режим.
• 2:55
  Ознака успіху – стабільна робота в реальних умовах під час нарахування зарплат, міграції даних,
• 3:00
  під наглядом офіцерів комплеєнсу та при високому навантаженні.
• 3:03
  Саме тоді агент доводить, що гідний працювати.
• 3:05
  І ось ще одна причина, чому багато розробок зазнають невдачі.
• 3:08
  Організації сприймають їх як одноразові проєкти, а не як робочі системи.
• 3:11
  Хтось створює прототип, показує ефектну демо-версію, а потім залишає її без нагляду.
• 3:15
  Незабаром різні відділи створюють власні рішення, не документуючи їх і безконтрольно витрачаючи токени.
• 3:19
  Без простого операційного посібника, хто відповідає за коннектори, хто перевіряє обґрунтування,
• 3:23
  Хто стежить за використанням кредитів, середовище перетворюється на хаос із неузгоджених розрізнених елементів.
• 3:28
  Змініть перспективу, і все стане набагато простіше.
• 3:30
  Якщо ви почнете з операційного мислення, підхід до проєктування зміниться.
• 3:33
  Вас цікавить не лише те, чи перший тест виглядав добре.
• 3:35
  Ви готуєтесь до щоденної інтенсивної експлуатації.
• 3:38
  Журнали аудиту, адміністративні обмеження, резервні копії, перевірки стану –
• 3:40
  все це формує довіру та зберігає працездатність системи під навантаженням.
• 3:53
  Ось чому створення прототипу не робить вас переможцем.
• 3:56
  Тестове середовище лише допомагає досягти першого рівня.
• 3:59
  Реальне розгортання з налаштованим керуванням і моніторингом – це момент,
• 4:01
  коли починається справжнє випробування на витривалість.
• 4:03
  І перш ніж іти далі, вам знадобиться правильна зброя для цієї боротьби.
• 4:07
  Microsoft пропонує два різні набори інструментів із різними правилами.
• 4:10
  Виберете неправильний, і це буде схоже на похід у рейд із пластиковим мечем.
• 4:14
  Co-Pilot Studio проти Teams Toolkit – вибір вашої зброї.
• 4:17
  Саме тут виникає головне питання – який інструмент обрати?
• 4:21
  Co-Pilot Studio чи Teams Toolkit, який також називають Microsoft 365 Agents Toolkit.
• 4:25
  Вони звучать подібно, обидва нібито розширюють Co-Pilot,
• 4:28
  але призначені для зовсім різних груп, розробників і потреб.
• 4:30
  Неправильний вибір коштує вам часу, бюджету, а можливо, і репутації,
• 4:32
  коли ваша ефектна демонстрація згасає у робочому середовищі.
• 4:35
  Co-Pilot Studio – це майданчик для творців.
• 4:37
  Це візуальний лоу-коуд-конструктор, створений для швидкості та ясності.
• 4:40
  Ви отримуєте потоки з методом перетягування drag-and-drop,
• 4:42
  шаблони, керовані діалоги та вбудовану аналітику.
• 4:44
  Studio постачається з набором конекторів до джерел даних Microsoft 365,
• 4:48
  тому досвідчений користувач може отримувати вміст SharePoint,
• 4:51
  відстежувати повідомлення Teams або працювати з документами HR-політики,
• 4:54
  не торкаючись коду.
• 4:55
  Ви можете тестувати, налаштовувати та публікувати безпосередньо в Microsoft 365 Co-Pilot
• 5:00
  або навіть випустити як окремий агент з мінімальними зусиллями.
• 5:02
  Для відділу, якому потрібен робочий процес у цьому кварталі,
• 5:05
  а не в наступному фінансовому році, Studio – це найшвидший шлях.
• 5:09
  Понад 160 тисяч клієнтів вже використовують Studio саме для цього
• 5:12
  звірки фінансових даних, адаптації співробітників
• 5:14
  або відповіді на питання щодо товарів у роздрібній торгівлі.
• 5:17
  Причина не є таємницею, він просто знижує поріг входу.
• 5:20
  Якщо ваша команда вже працює в Pava Apps або автоматизує рутинні звіти в Pava Automate,
• 5:24
  Studio здасться рідним середовищем.
• 5:26
  Вам не потрібно бути інженером-програмістом, достатньо мати чітку мету
• 5:29
  та базові навички лоу-коуд, щоб натискати, налаштовувати та розгортати.
• 5:32
  Тепер перейдемо до Teams Toolkit.
• 5:34
  Це місце, де процвітають фулл-стек-розробники.
• 5:36
  Toolkit інтегрується у VS Code, а не в полотно з перетягуванням об'єктів.
• 5:40
  Тут ви архітектурно створюєте декларативні агенти зі структурованими правилами
• 5:43
  або йдете далі і створюєте власні агентні рушії,
• 5:45
  де ви визначаєте виклики моделей оркестрації та обробку ARIS 0.
• 5:48
  Ви отримуєте каркаси, засоби налагодження, конфігурацію та шляхи публікації
• 5:52
  не лише в межах Co-Pilot, а й у Teams, додатках Microsoft 365 в інтернеті та зовнішніх каналах.
• 5:57
  Якщо Co-Pilot Studio – це готові меблі з каталогу,
• 5:59
  то Toolkit – це самостійне виготовлення дощок та проведення електропроводки в будинку.
• 6:03
  Свобода вражаюча, але ви також несете відповідальність за кожен цвях і запобіжник.
• 6:06
  Справжня плутанина в тому, що обидва інструменти кажуть, що розширюють Co-Pilot.
• 6:10
  На практиці Studio означає розширення в межах визначених Microsoft обмежень,
• 6:13
  безпечних конекторів, адміністративних елементів керування та полегшеного управління.
• 6:17
  Toolkit означає переписування обмежень, створення власної оркестрації,
• 6:20
  виклик зовнішніх LLM або створення поведінки агентів,
• 6:23
  яку Microsoft не надала в готовому вигляді.
• 6:25
  Один підхід забезпечує вашу безпеку за допомогою шаблонів,
• 6:27
  інша ідея необмежені можливості і очікує, що ви будете використовувати їх відповідально.
• 6:30
  Багато хто думає, що вибір інструменту означає різний інтерфейс.
• 6:33
  Аж ніяк.
• 6:34
  Кінцеві користувачі бачать однакове вікно запиту та картку відповіді,
• 6:36
  незалежно від того, чи створили ви агента в Studio чи за допомогою Toolkit.
• 6:38
  Це закладено в дизайн Riven UX єдиний, що насправді змінюється,
• 6:42
  так це те, що за лаштунками.
• 6:43
  Параметри обґрунтування, grounding, масштабованість та адміністративний контроль.
• 6:46
  Ось чому це рішення є операційним, а не косметичним.
• 6:49
  Ось практичне правило.
• 6:50
  Деякі можливості обґрунтування, як-от вміст SharePoint,
• 6:53
  чати і наради Teams, вбудовані файли, дані Dataverse або коннектори до електронної пошти
• 6:56
  та пошуку людей стають доступними, лише якщо ваш орендар має ліцензію Microsoft 365 Co-Pilot
• 7:01
  або активовану тарифікацію Co-Pilot Studio.
• 7:04
  Якщо у вас немає відповідних прав, вибір Studio не відкриє ці функції.
• 7:08
  Ця єдина перевірка ліцензування може стати вирішальним фактором у виборі шляху.
• 7:11
  Отже, як спростити цей вибір?
• 7:13
  Складіть швидкий контрольний список.
• 7:15
  Перше, чи потрібні вам швидкі аудіювані агенти під контролем адміністратора,
• 7:18
  яких можуть створити досвідчені користувачі без залучення IT?
• 7:20
  Обирайте Co-Pilot Studio.
• 7:21
  Друге, чи потрібна вам власна оркестрація, зовнішні моделіщі або глибока інтеграція,
• 7:25
  вбудована безпосередньо в корпоративну інфраструктуру?
• 7:27
  Обирайте Agents Toolkit.
• 7:28
  Третє, не довіряйте назвам, довіряйте реальним навичкам і цілям вашої команди.
• 7:32
  Я використовую метафору з житлом.
• 7:33
  Studio – це збірний будинок.
• 7:35
  Ви обираєте кольори та шафи, але сантехніка і проводка вже надійні.
• 7:38
  Toolkit – це необроблена ділянка.
• 7:39
  Ви проєктуєте кожен сантиметр, але й берете на себе всі ризики, якщо конструкція дасть збій.
• 7:43
  Обидва варіанти можуть дати чудовий результат.
• 7:45
  Один швидший і простіший, інший – безмежний, але вразливий, якщо ним неправильно керувати.
• 7:48
  Обидва руйнуються без обґрунтування даних.
• 7:50
  Обраний інструмент допомагає з побудовою, але якщо не надати йому правильних даних, він лише швидше генеруватиме впевнену нісенітницю.
• 7:55
  Агент Studio без коннекторів – це просто папуга.
• 7:57
  Агент Toolkit без обґрунтування – це папуга, написаний кодом.
• 8:00
  У будь-якому разі ви отримуєте пташку, яка вигукує припущення вашим користувачам.
• 8:04
  І це підводить нас до справжньої основи будь-якого агента – прив'язки до даних, яка не дає його мозку грати увіщена з неповною колодою карт.
• 8:10
  Обґрунтування агентів – це живлення інтелекту, а не порожнечі.
• 8:14
  Обґрунтування – це момент, коли агент припиняє імітувати мудрість і починає працювати з реальними знаннями.
• 8:18
  Дайте йому правильні джерела, і він перейде від блефу до надання відповідей, які можна захистити.
• 8:22
  Пропустіть це і те, що виглядало досконалим, швидко розвалиться, коли хтось запитає, звідки взагалі взялася ця відповідь.
• 8:28
  Внутрішній Microsoft 365 Co-Pilot вже спирається на дані, які він бачить через Microsoft Graph.
• 8:32
  Файли, чати, наради та навіть календарні події – це непоганий початок, але найцінніший вміст знаходиться за межами цього ядра.
• 8:39
  ERP зберігають інвентар, CRM відстежують життєвий цикл клієнтів, HR тримає регламенти в глибинах SharePoint,
• 8:45
  а політики лежать у захищених папках юридичного відділу.
• 8:48
  Якщо ви не прив'яжете агента до цих джерел, він впевнено здогадуватиметься, використовуючи загальні знання моделі,
• 8:53
  замість того, щоб посилатися на щось перевірене.
• 8:55
  Підключення їх – це не просто перетягування об'єктів, це тонка інженерна робота.
• 8:59
  Co-Pilot Studio та коннектори Microsoft Graph надають доступ до SharePoint для збережених документів,
• 9:04
  Dataverse для структурованих таблиць, Exchange для записів пошти та Teams для чатів.
• 9:08
  Окрім основних рішень Microsoft, понад 1200 коннекторів через Pava Platform відкривають доступ до зовнішніх систем.
• 9:14
  Фінанси, HR, тікетингові системи, будь-що.
• 9:16
  А якщо готових варіантів бракує, Ари дозволяють підключити бізнес-додатки, для яких немає стандартних коннекторів.
• 9:22
  При правильному налаштуванні агент отримує актуальні факти з цих сховищ і надає їх разом із контекстом.
• 9:26
  Те, що здається магією, це лише добре налагоджена інфраструктура.
• 9:29
  Але є нюанс.
• 9:30
  Деякі з цих варіантів обґрунтування Grounding не є безкоштовними для всіх.
• 9:33
  Доступ до джерел, таких як вміст SharePoint на ради Teams, електронна пошта або Dataverse,
• 9:37
  часто потребує ліцензії Co-Pilot або активації вимірювання в орендарі.
• 9:40
  Без цього доступу коннектори не запрацюють, і ваший помічник не бачитиме частину ваших найважливіших даних.
• 9:46
  Не варто думати, що просте натискання перемикача дасть вам усе.
• 9:48
  Спочатку перевірте свою схему ліцензування.
• 9:50
  Згадаємо приклад роботи служби підтримки персоналу.
• 9:53
  Хтось запитує, яка політика щодо відпустки по догляду за дитиною.
• 9:55
  Без обґрунтування агент формує правдоподібну відповідь на основі загальних знань моделі.
• 9:59
  Це звучить корисно, але немає ні посилання, ні доказів.
• 10:02
  З обґрунтуванням агент може витягти реальну політику з SharePoint,
• 10:05
  вказати назву документа та додати посилання на довідник.
• 10:08
  Ця єдина відмінність перетворює неперевірне твердження на надійну відповідь,
• 10:11
  яку схвалять аудитори та HR.
• 10:13
  Такий аудитний слід – це справжній приріст ефективності.
• 10:15
  Обґрунтовані відповіді можуть містити цитати,
• 10:17
  що спрямовують користувачів та регуляторів до першоджерела.
• 10:20
  Коли служба комплеєнсу запитає, чому бот відповів саме так,
• 10:22
  вам не потрібна довга історія.
• 10:23
  Логи показують шлях.
• 10:25
  Ось запит.
• 10:26
  Ось документ, який він отримав.
• 10:27
  Ось відповідь, яку він згенерував.
• 10:29
  Не потрібно сподіватися на диво, але кожне підключення – це також точка ризику.
• 10:32
  Якщо підключитися до HR даних недбало,
• 10:34
  можна випадково розкрити особисті записи працівників разом із публічними FAQ.
• 10:38
  Якщо неправильно налаштувати доступ до ERP,
• 10:39
  торговий агент може побачити дані про зарплати.
• 10:42
  Такі недогляди є критичними помилками для виробництва.
• 10:44
  Найбезпечніший шлях – додати мітки конфіденційності
• 10:46
  та класифікацію перв'ю до вашого плану обґрунтування.
• 10:49
  Тоді агент отримуватиме лише той вміст,
• 10:51
  який відповідає його правилам доступу,
• 10:52
  дотримуючись ваших класифікацій даних, а не ігноруючи їх.
• 10:55
  Попередження просте.
• 10:57
  Необґрунтовані агенти вигадують із виглядом експертів,
• 10:59
  а погано обґрунтовані розкривають те, що не повинно залишати сховище.
• 11:02
  В обох випадках ви поширюєте помилки або витоки конфіденційних даних
• 11:05
  під логотипом вашої компанії.
• 11:06
  Інструменти управління, такі як перв'ю, існують не дарма.
• 11:09
  Поєднуйте конектори даних із класифікацією з першого дня,
• 11:11
  інакше потім доведеться виправляти проблеми з репутацією
• 11:14
  та порушення комплеєнсу.
• 11:15
  Отже, урок зрозумілий.
• 11:16
  Обґрунтування – це недодаткова розширена функція.
• 11:19
  Це база, яка відрізняє корисні co-пайлот від ненадійних базікань.
• 11:22
  Якщо все зроблено правильно, це озброює користувачів фактами,
• 11:24
  пов'язаними з реальним контентом і підкріпленими журналами,
• 11:26
  які можна захистити.
• 11:27
  Якщо неправильно, це масштабу є галюцинації та витоки в організації швидше,
• 11:30
  ніж ви встигнете відкрити тікет.
• 11:32
  Ось чому наступний виклик є настільки ж критичним.
• 11:34
  Оскільки один обґрунтований агент – це керовано,
• 11:36
  а десятки агентів без нагляду – це початок справжніх проблем.
• 11:39
  Управління, що зупиняє розростання агентів,
• 11:41
  перш ніж воно переростив хаос.
• 11:42
  Управління в цьому контексті – це набір правил,
• 11:45
  які не дають агентам Coopilot перетворитися на неконтрольований безлад.
• 11:48
  Це спосіб визначити, хто може їх створювати,
• 11:50
  де вони працюють і до яких даних мають доступ,
• 11:52
  не залишаючи все на волю випадку.
• 11:53
  Майкрософт уже надає вам інструменти для забезпечення цього.
• 11:56
  Система керування Coopilot у центрі адміністрування Microsoft 365,
• 12:00
  керування життєвим циклом у центрі адміністрування Pava Platform,
• 12:03
  Microsoft Perview для міток конфіденційності та DLP,
• 12:05
  а також діагностичні журнали Coopilot для аудиту.
• 12:08
  Уявіть їх як чотири опори, що не дають картковому будиночку завалитися.
• 12:12
  Одне, що варто знати заздалегідь – керування сценаріями Coopilot –
• 12:15
  не для кожного, хто має права адміністратора.
• 12:17
  Це потребує спеціальних ролей, таких як глобальний адміністратор або адміністратор ЩІ.
• 12:21
  Дотримуйтесь принципу мінімальних привілеїв,
• 12:22
  щоб не давати комусь меч, який може поранити сильніше, ніж вони усвідомлюють.
• 12:25
  Обмеження кола осіб, які можуть перемикати ці налаштування,
• 12:27
  є окремою формою управління.
• 12:28
  Впроваджуйте правила життєвого циклу ще на етапі проєктування,
• 12:31
  а не після того, як усе готово.
• 12:32
  Правило перше – визначте, хто може створювати агентів
• 12:34
  і прив'яжіть це до середовищ у Центрі адміністрування PAVA Platform.
• 12:37
  Правило друге – визначте, хто може публікувати агентів,
• 12:40
  використовуючи налаштування Coopilot у Центрі адміністрування 365
• 12:42
  для схвалення чи блокування релізів.
• 12:44
  Правило третє – визначте, де можуть працювати агенти,
• 12:46
  призначаючи їх в ізольовані середовища,
• 12:48
  щоб робоче середовище не стало ще однією відкритою ареною.
• 12:51
  І правило четверте – визначте, як розподіляються кредити,
• 12:53
  для чого використовується лічильник споживання агентів Coopilot.
• 12:56
  Цей лічильник показує в цифрах, коли ваш запас ресурсів
• 12:58
  вичерпується занадто швидко і хто його витрачає.
• 13:00
  Перв'ю – це мережа відповідності, на яку ви вже покладаєтеся
• 13:03
  для документів і пошти, і тут вона працює так само.
• 13:06
  Застосовуйте мітки конфіденційності до даних,
• 13:08
  щоб, навіть якщо агент підключається до джерела,
• 13:10
  мітка переносилася у відповіді.
• 13:11
  Використовуйте політики DLP, щоб заблокувати агентам
• 13:14
  доступ до конфіденційних полів у відповідях.
• 13:16
  Політики зберігання не дають застарілому контенту затримуватися,
• 13:19
  щоб ваші агенти не використовували дані,
• 13:21
  які мали втратити актуальність тижні тому.
• 13:23
  Коли ви встановили ці запобіжники,
• 13:24
  кожен агент автоматично отримує цей нагляд.
• 13:27
  Ще один крок, який пропускають більшість команд –
• 13:29
  увімкнення діагностичних журналів.
• 13:30
  Перемкніть цей тумблер, і ви отримаєте чітку видимість
• 13:33
  кожної взаємодії.
• 13:34
  Запити, відповіді, посилання на контент, системні журнали –
• 13:37
  усе це формує записи, які можна використати пізніше.
• 13:39
  Якщо менеджер запитає, чому агент надав неправильну інструкцію,
• 13:42
  ви зможете відтворити історію замість того,
• 13:43
  щоб просто знизувати плечима.
• 13:44
  Більше того, адміністратори можуть надсилати звіти від імені користувачів,
• 13:47
  навіть якщо самі користувачі не надсилають відгуки.
• 13:49
  Це перетворює усунення несправностей з реактивного процесу на проактивний.
• 13:52
  Це не про сповільнення інновацій, а про їх спрямування.
• 13:54
  Студіо уробить створення потоків для просунутих користувачів неймовірно легким,
• 13:58
  а набір інструментів дозволяє розробникам швидко виводити складні збірки у роботу.
• 14:01
  Без належного контролю така швидкість призводить до дублювання та суперечностей.
• 14:04
  За наявності управління та сама швидкість забезпечує створення багаторазових ресурсів,
• 14:08
  що залишаються відповідними стандартами і контролюваними.
• 14:09
  Різниця не в тому, наскільки креативні ваші співробітники,
• 14:12
  а в тому, наскільки дисциплінованою є структура навколо них.
• 14:14
  Навіть відстеження витрат є частиною управління.
• 14:17
  Лічильник споживання в центрі адміністрування – це не просто бухгалтерський звіт,
• 14:20
  це ваш балансувальний інструмент.
• 14:21
  Ви можете призначати пакети кредитів, контролювати перевищення за моделью оплати за фактом
• 14:24
  і тримати використання в межах бюджету.
• 14:26
  Якщо ігнорувати це, ви дізнаєтеся про обмеження лише тоді,
• 14:28
  коли агент раптово зупиниться посеред робочого процесу через вичерпання ліміту.
• 14:31
  Ви ж не хочете займатися налагодженням продуктивної системи з порожнім баком.
• 14:34
  За вдалого сценарію управління відчувається як броня.
• 14:37
  Достатньо гнучка, щоб розробники могли рухатися швидко,
• 14:39
  але достатньо надійно, щоб одна помилка не потопила всю команду.
• 14:42
  При невдалому сценарії ви ігноруєте це,
• 14:44
  дозволяєте агентам створюватися без хвалення
• 14:46
  і змушені латати дірки в усіх відділах, поки аудитори дихають у потилицю.
• 14:49
  Управління не робить гру нудною, воно робить її здатною до виживання.
• 14:52
  А виживання веде прямісінько до наступної пастки в підземельній.
• 14:56
  Бо як тільки управління взято під контроль,
• 14:57
  наступний сюрприз буде не технічним, а фінансовим.
• 15:00
  Є причина, чому адміністратори прокидаються в холодному поті,
• 15:02
  коли фінансовий відділ перевіряє лічильник.
• 15:04
  Ніщо не псує враження від працюючої системи швидше,
• 15:06
  ніж вигляд рахунку, який вона генерує.
• 15:07
  Ліцензування та витрати – це пастки, які ви не помітили.
• 15:10
  Ліцензування та витрати – це пастки, які більшість команд не бачить,
• 15:13
  поки вони вже не опинилися на ігровому полі.
• 15:15
  Microsoft продає вам ілюзію швидких збірок і ефектних демонстрацій,
• 15:17
  але все це не має значення, якщо кредити зникають у середині місяця,
• 15:20
  або конектор тихо додає ще одну вимогу щодо ліцензії.
• 15:22
  Це не примітка, це ключовий механізм, яким ви повинні керувати,
• 15:25
  інакше ваші агенти зупиняться саме в той момент, коли люди почнуть на них покладатися.
• 15:29
  Co-Pilot Studio працює на кредитах Co-Pilot.
• 15:32
  Ви купуєте їх пакетами – 25 тисяч кредитів приблизно за 200 доларів на місяць для орендаря,
• 15:36
  або використовуєте лічильник з оплатою за фактом,
• 15:38
  де рахунок приходить наприкінці періоду залежно від того, що спожила організація.
• 15:41
  Звучить щедро, але документація чітко вказує, що споживання не є рівномірним.
• 15:45
  Тут діють багаторівневі тарифи, стандартні негенеративні дії коштують менше,
• 15:49
  тоді як генеративні відповіді витрачають більше.
• 15:51
  Точні цифри змінюються згідно з ліцензійними правилами Microsoft,
• 15:54
  тому розглядаєте документи з білінгу як частину свого робочого набору.
• 15:58
  Головне те, що тестові запити і виробничі відповіді вичерпують один і той самий пул ресурсів.
• 16:02
  У системі немає прихованої безкоштовної пісочниці, хоч якби ви цього хотіли.
• 16:06
  Оскільки кредити розподіляються на весь орендарський акаунт,
• 16:08
  кожен агент використовує спільний пул, чи то бот для онбордингу HR,
• 16:11
  чи бот підтримки угод продажів, чи асистент фінансової звітності.
• 16:14
  Такий дизайн забезпечує гнучкість, але означає,
• 16:16
  що інтенсивне тестування в одному відділі може вичерпати ресурси для робочих процесів іншої команди.
• 16:20
  Якщо пул спорожніє, Coopilot Studio не обмежує швидкість і не надсилає м'яких попереджень.
• 16:24
  Вона просто призупиняє роботу цих агентів, доки кредити не будуть поповнені.
• 16:27
  Ви б не хотіли бути тією людиною, яка пояснює, чому робочий бот підтримки замов посеред транзакції
• 16:32
  лише тому, що інша група залишила свій тест запущеним на ніч.
• 16:35
  Оплата за фактом використання корисна, якщо ви хочете уникнути попередніх зобов'язань,
• 16:38
  оскільки платите лише за те, що реально витратили за місяць.
• 16:41
  Але лічильник працює жорстко і безсторонню.
• 16:43
  Швидкий раунд тестування прототипу споживає кредити так само, як і виробничий процес,
• 16:46
  що створює ризик перевищення бюджету, якщо не налаштовані сповіщення.
• 16:50
  Безпечний підхід – розглядати навіть тестові збірки як частину планування кредитів
• 16:53
  і встановлювати ліміти заздалегідь.
• 16:55
  Teams Toolkit або набір інструментів для агентів у VS Code використовують інший підхід.
• 16:59
  Ви не бачите списання кредитів за запит, бо робота виконується в межах ліцензії Microsoft 365
• 17:03
  Co-Pilot-користувача після публікації в пакеті.
• 17:06
  Це виглядає як свобода порівняно зі Studio, але покриває лише базові речі.
• 17:09
  Як тільки ви будуєте кастомного агента або підключаєте зовнішні сервіси, витрати починають зростати.
• 17:14
  Ари мають власні лічильники, корпоративні конектори часто потребують окремих ліцензій,
• 17:18
  а згоди адміністратора можуть підключити тарифи, на які ви не розраховували.
• 17:21
  Studio виставляє рахунок за дію, а Toolkit дозволяє уникнути моделі кредитів.
• 17:25
  Але обидва варіанти перекладають витрати в іншу площину.
• 17:27
  Називайте це компромісом, а не безкоштовним шляхом.
• 17:29
  Практичне правило таке.
• 17:30
  Teams Toolkit приховує витрати в рівнях інтеграції та сервісах, тоді як Studio змушує платити наперед кредитами.
• 17:35
  Жоден з варіантів не є дешевшим у будь-якому випадку.
• 17:37
  Ви повинні порівняти очікувані робочі процеси з документацією щодо ціноутворення, перш ніж обирати шлях.
• 17:41
  Легкий бот для погоджень на базі SharePoint може добре працювати в Studio, витрачаючи мізерну кількість кредитів.
• 17:46
  Складна інтеграція із зовнішньою CRM може бути доцільнішою в Toolkit,
• 17:50
  хоча ви платитимете за арі виклики CRM замість списання кредитів Co-Pilot.
• 17:54
  Все залежить від того, де саме відображаються витрати, а не від того, як їх повністю уникнути.
• 17:58
  Тож, як не дати цим пасткам перевернути весь стіл?
• 18:00
  По-перше, увімкніть моніторинг споживання на рівні орендаря за допомогою лічильника, агентів Co-Pilot або звітів з оплатою за фактом використання.
• 18:05
  По-друге, налаштуйте пороги сповіщень, щоб фінансовий та ІТ-відділи отримували повідомлення до того, як бюджет вичерпається.
• 18:11
  По-третє, розподіліть бюджети за підрозділами, використовуючи спеціальні пакети кредитів або чіткі внутрішні політики,
• 18:16
  щоб одна команда не витратила все за один спринт.
• 18:18
  Ці три елементи контролю допоможуть уникнути більшості неприємних сюрпризів.
• 18:21
  Розширена розробка додає ще один рівень складності.
• 18:23
  Інтеграції часто потребують прямої згоди адміністратора, і кожна така згода може за замовчуванням передбачати нові витрати.
• 18:28
  Той зовнішній ARRI, який ви підключили під час тестування, виставлятиме рахунки вам у робочому середовищі, а не Microsoft.
• 18:33
  Розумний крок – каталогізувати ліцензії та конектори під час проєктування та підтвердити відповідальних за оплату кожного з них перед впровадженням.
• 18:38
  Ставтеся до цього як до управління змінами для витрат, а не лише функціональності.
• 18:42
  Ліцензування – це не дрібний шрифт, а частина архітектури.
• 18:45
  Витрачайте кредити як токени в рейді, виважено, а не безрозсудно.
• 18:48
  Оберіть правильний набір ліцензій на старті, стежте за цифрами споживання та очікуйте на витрати за кожен новий інтеграційний конектор.
• 18:54
  Ніщо з цього не є необов'язковим, якщо ви хочете, щоб ваші агенти були доступні тоді, коли на них розраховують, що підводить нас до останньої фази.
• 19:01
  Створення, обґрунтування, керування та фінансування агента – це життєво важливі контрольні точки, але справжній показник – це не випуск у роботу, а тривала підтримка проєкту.
• 19:08
  Ось тут фінальна перспектива має найбільше значення.
• 19:10
  Отже, головний висновок – перемога не в яскравих демо, а в дотриманні правил, які роблять агентів корисними, а не непередбачуваними.
• 19:16
  По-перше, вибирайте шлях розробки з розумом.
• 19:18
  Co-Pilot Studio для швидкості Low-Code, Teams Toolkit для створення власних рушіїв та глибшого контролю.
• 19:22
  По-друге, забезпечте управління з моменту запуску.
• 19:25
  Мітки перв'ю, ролі адміністраторів, журнали діагностики та моніторинг споживання мають бути активовані перед публікацією.
• 19:30
  По-третє, плануйте свої витрати.
• 19:31
  Studio-O використовує кредитні пакети або оплату за фактом, тоді як Toolkit переносить витрати на зовнішні арі та сервіси.
• 19:37
  Питання закрито.
• 19:38
  Підписуйтесь, вмикайте сповіщення та залишайте коментарі.
• 19:40
  Що ви оберете для свого наступного проєкту – Studio-O чи Toolkit?