WEBVTT 00:00:00.000 --> 00:00:09.660 Уявіть, що ви запускаєте свого першого агента Co-Pilot Studio, і замість того, щоб справити враження, він видає щось безглозде, наприклад, думаю, політика каже, можливо, це природна частина створення бота. 00:00:09.820 --> 00:00:16.880 Але за допомогою кількох виправлень та чітких інструкцій, що базуються на реальному документи з політикою, ви можете перетворити цей провал на влучну відповідь з посиланнями на конкретні пункти. 00:00:16.880 --> 00:00:23.720 До кінця цього відео ви дізнаєтеся, як відтворити невдалу відповідь у тестовій панелі, виправити її, щоб бот посилався на справжній документ, і опублікувати робочий пілот. 00:00:23.860 --> 00:00:28.060 Короткий відступ. Підпишіться зараз, щоб ці інструкції автоматично з'являлися у вашому списку відтворення. 00:00:28.240 --> 00:00:30.920 Звісно, отримати ідеальну відповідь у тестовому вікні легко. 00:00:31.140 --> 00:00:35.140 Справжні проблеми починаються, коли ваш бот залишає тренувальну зону і потрапляє в реальні умови. 00:00:35.160 --> 00:00:37.780 Чому ваш ідеальний тестовий бот ламається у реальному світі? 00:00:37.780 --> 00:00:42.500 Отже, чому бот, який виглядає бездоганно в тестовій панелі, раптом починає помилятися, як тільки стикається з реальними користувачами? 00:00:42.640 --> 00:00:47.540 Коротко кажучи, студіо утримає все в безпечних і ввічливих межах, тоді як реальний світ не знає такої ввічливості. 00:00:47.680 --> 00:00:50.140 У студіо дані, які ви вводите, є аккуратними. 00:00:50.320 --> 00:00:54.500 Запитання короткі, сформульовані чітко і зазвичай збігаються з підготовленими вами прикладами для навчання. 00:00:54.680 --> 00:00:56.540 Ось чому здається, що все йде бездоганно. 00:00:56.540 --> 00:00:59.840 Але перейдіть до реальної експлуатації, і люди почнуть друкувати так, як вони це роблять у житті. 00:00:59.940 --> 00:01:02.600 Керівник запитає, скільки я можу отримати від шкодування за готель. 00:01:02.720 --> 00:01:05.820 Представник може надрукувати ліміт витрат на готель з друкарською помилкою. 00:01:05.980 --> 00:01:09.140 Хтось інший може просто сказати, нагадай ще раз про гроші на відрядження. 00:01:09.300 --> 00:01:15.100 Усі вони означають одне й те саме, але якщо ви тестували лише, який ліміт витрат, бот не завжди зможе поєднати ці факти. 00:01:15.300 --> 00:01:17.420 Ось спосіб побачити цей розрив прямо зараз. 00:01:17.420 --> 00:01:20.300 Відкрійте тестову панель і випробуйте три варіанти на своєму боті. 00:01:20.440 --> 00:01:23.700 Спочатку чітку версію, потім повсякденну, а потім версію з друкарською помилкою. 00:01:23.960 --> 00:01:25.580 Спостерігайте, як змінюються відповіді. 00:01:25.740 --> 00:01:28.380 Іноді він влучає в усі три, іноді спрацьовує лише чітка версія. 00:01:28.540 --> 00:01:31.960 Це ваш перший сигнал, що гарні результати тестів не гарантують виживання в реальному світі. 00:01:32.080 --> 00:01:34.400 Технічна причина охоплення намірів – інтент каверадж. 00:01:34.400 --> 00:01:37.900 Боти покладаються на фрази-тригери та визначення тем, щоб знати, коли надати відповідь. 00:01:38.020 --> 00:01:40.840 Якщо всі ваші приклади виглядають однаково, модель стає вразливою. 00:01:40.980 --> 00:01:42.780 Один синонім може збити її з пантелику. 00:01:42.980 --> 00:01:44.520 Виправлення нудне, але воно працює. 00:01:44.680 --> 00:01:48.560 Додайте ширші фрази-тригери до своїх тем і не використовуйте лише офіційне формулювання з вашої документації. 00:01:48.720 --> 00:01:52.580 Додайте повсякденні, скорочені, навіть трохи недоладні фрази, які люди використовують насправді. 00:01:52.580 --> 00:01:56.060 Вам не потрібні десятки, достатньо покрити очевидні варіації, а потім повторно протестувати. 00:01:56.200 --> 00:01:58.400 Відмінності в каналах зв'язку роблять це завдання складнішим. 00:02:07.900 --> 00:02:08.580 Рядки інакше. 00:02:08.760 --> 00:02:10.540 Веб-сторінка може видалити форматування. 00:02:10.720 --> 00:02:15.120 Навіть незначні зміни, як от перенесення ключової фрази на інший рядок, можуть вплинути на те, як модель її оцінює. 00:02:15.240 --> 00:02:18.920 Ось чому Microsoft наголошує на необхідності ітеративного тестування в різних каналах. 00:02:18.920 --> 00:02:23.180 Бот, який успішно працює в Studio, може помилитися, коли форматування в реальних умовах змінює ситуацію. 00:02:23.400 --> 00:02:25.280 Користувачі також мають свої очікування. 00:02:25.460 --> 00:02:27.900 Для них перефразування запитання – це звичайна розмова. 00:02:28.080 --> 00:02:30.740 Вони не думають про наміри, тригери чи семантичне перекриття. 00:02:30.740 --> 00:02:33.480 Вони просто припускають, що бот розуміє їх як колега. 00:02:33.600 --> 00:02:36.400 Одна невдала відповідь, особливо під час демонстрації, і довіра втрачена. 00:02:36.600 --> 00:02:38.540 Саме тут новачки часто припускаються помилок. 00:02:38.700 --> 00:02:43.880 Репетиція в Studio дала їм хибне відчуття впевненості, але перший же звичайний запит користувача в Teams зруйнував цю ілюзію. 00:02:44.080 --> 00:02:45.740 Закріпімо це ще одним прикладом. 00:02:45.880 --> 00:02:48.020 У Studio ви пишете, який ліміт витрат. 00:02:48.220 --> 00:02:51.880 Бот відповідає прямо, згідно з політикою, на проживання передбачено 200 доларів на день. 00:02:52.100 --> 00:02:53.500 Ідеально. Розгортаємо. 00:02:53.500 --> 00:02:56.500 Тепер спробуйте, гей, а на яку суму за готель я можу розраховувати. 00:02:56.680 --> 00:03:01.440 Замість цитування політики бот відповідає щось на кшталт «Зверніться до HR» або робить неточне припущення. 00:03:01.640 --> 00:03:03.640 Намір той самий, результат зовсім інший. 00:03:03.800 --> 00:03:08.560 Ця різниця, точність під час репетиції та невизначеність у робочому середовищі – це саме те, про що ми говоримо. 00:03:08.820 --> 00:03:10.080 Практичний висновок такий. 00:03:10.260 --> 00:03:12.140 Ставтеся до Studio як до спарингу. 00:03:12.300 --> 00:03:14.700 Це корисно для навчання, але не є доказом готовності. 00:03:14.700 --> 00:03:17.640 Перш ніж рухатися далі, спробуйте тест із трьома варіантами в панелі тестування, 00:03:17.740 --> 00:03:20.120 а потім розширті свої теми, додавши синоніми та розмовні фрази. 00:03:20.240 --> 00:03:23.720 Нарешті, після публікації проведіть повторне тестування в кожному каналі, де працюватиме бот. 00:03:23.880 --> 00:03:26.040 Ви виявите проблеми раніше за ваших користувачів. 00:03:26.180 --> 00:03:29.180 Але попереду ще більша пастка, адже навіть якщо ви охопили всі фрази та канали, 00:03:29.300 --> 00:03:32.260 ваш бот все одно може помилятися, якщо він не базується на правильному джерелі. 00:03:32.260 --> 00:03:35.500 Саме тоді він перестає пропускати запитання і починає вигадувати відповіді. 00:03:35.600 --> 00:03:38.320 Уявіть бота, який звучить впевнено, але просто вгадує. 00:03:38.480 --> 00:03:40.600 Ось тут і починаються справжні проблеми. 00:03:40.760 --> 00:03:43.860 Помилка новачка – залишати бота без належної бази знань. 00:03:44.000 --> 00:03:48.760 Перша помилка новачка – ставитися до Coopilot Studio як до магічної кулі, а не як до збірника правил. 00:03:48.920 --> 00:03:51.200 Коли ви запускаєте агента без опори на реальні знання, 00:03:51.320 --> 00:03:54.620 ви фактично відправляєте стажера на нараду керівників без жодної підготовки. 00:03:54.620 --> 00:03:57.880 Він говоритиме швидко, звучитиме впевнено, але половина сказаного розсиплеться, 00:03:57.980 --> 00:03:59.000 щойно хтось перевірить факти. 00:03:59.160 --> 00:04:01.220 Це і є пастка відсутності бази знань у бота. 00:04:01.380 --> 00:04:03.200 Спочатку зовнішній близьк це приховує. 00:04:03.380 --> 00:04:07.800 Свіжа збірка в студіо виглядає чудово, ввічливі привітання, швидкі відповіді, жодних затримок. 00:04:07.900 --> 00:04:10.280 Але за лаштунками ці слова нічим не підкріплені. 00:04:10.440 --> 00:04:12.820 Система використовує лише шаблони, а не факти. 00:04:13.020 --> 00:04:15.060 Не обґрунтовані боти нічого не знають. 00:04:15.220 --> 00:04:15.620 Вони блефують. 00:04:15.620 --> 00:04:16.140 Блефують. 00:04:16.240 --> 00:04:18.560 І хоча блеф може виглядати ефектно в тестовому вікні, 00:04:18.680 --> 00:04:20.960 користувачі в реальних умовах миттєво його викриють. 00:04:21.120 --> 00:04:24.140 Найгірший результат – це не просто слабкі відповіді, а галюцинації. 00:04:24.320 --> 00:04:28.220 Це коли бот вигадує те, що виглядає правдоподібно, але немає підґрунтя в реальності. 00:04:28.360 --> 00:04:30.540 Ви запитуєте про відшкодування витрат на відрядження, 00:04:30.640 --> 00:04:33.800 і замість ввічливої відмови бот вигадує суму, яка звучить переконливо. 00:04:33.980 --> 00:04:36.460 Співробітник бронює готель на основі цієї помилкової відповіді, 00:04:36.460 --> 00:04:39.560 і раптом вам доводиться розбиратися зі спорами щодо витрат та роздратованими листами. 00:04:39.680 --> 00:04:42.220 Речення виглядало професійно, а зміст був порожнім. 00:04:42.340 --> 00:04:44.480 Приклад Contoso Labs робить це очевидним. 00:04:44.660 --> 00:04:47.740 В офіційній практичній вправі ви маєте завантажити файл під назвою 00:04:47.740 --> 00:04:49.400 Expenses Policy – DocEx. 00:04:49.560 --> 00:04:52.620 У ньому чітко вказано ліміт на проживання – 200 доларів за ніч. 00:04:52.760 --> 00:04:55.640 А тепер, якщо ви пропустите обґрунтування і запитаєте свого новенького бота, 00:04:55.640 --> 00:04:56.800 яка політика щодо готелів? 00:04:56.920 --> 00:04:59.200 Він може впевнено відповісти – 100 доларів за ніч. 00:04:59.200 --> 00:05:00.360 Повністю вигадано. 00:05:00.540 --> 00:05:04.440 Тільки коли ви додасте файл Expenses Policy – DocEx, модель перестане імпровізувати. 00:05:04.720 --> 00:05:06.600 Обґрунтовані боти посилаються на документ. 00:05:06.820 --> 00:05:08.460 Згідно з корпоративною політикою відряджень, 00:05:08.600 --> 00:05:10.740 витрати на проживання обмежені 200 доларами на день. 00:05:10.880 --> 00:05:14.400 І ця різниця між вигадкою та цитуванням полягає саме в етапі обґрунтування. 00:05:14.580 --> 00:05:16.620 Отже, ось як саме це виправити в інтерфейсі. 00:05:16.620 --> 00:05:18.640 Перейдіть до свого агента в Co-Pilot Studio. 00:05:18.940 --> 00:05:20.940 На екрані огляду натисніть «Знання – Knowledge». 00:05:20.940 --> 00:05:23.500 Оберіть «Додати знання – PlusEd Knowledge», а потім завантажте файл. 00:05:23.600 --> 00:05:26.620 Вкажіть на файл Expenses Policy, DocEx або інше надійне джерело. 00:05:26.780 --> 00:05:29.500 Якщо ви віддаєте перевагу підключенню до публічного веб-сайту або SharePoint, 00:05:29.620 --> 00:05:31.640 ви можете обрати і це, але файли – надійніший варіант. 00:05:31.800 --> 00:05:33.160 Після завантаження зачекайте. 00:05:33.360 --> 00:05:36.160 Індексація може тривати 10 хвилин або довше, перш ніж контент стане доступним. 00:05:36.300 --> 00:05:39.060 Не панікуйте, якщо перші тестові запити не використовують його одразу. 00:05:39.060 --> 00:05:41.480 Коли індексація завершиться, повторіть свій запит. 00:05:41.480 --> 00:05:45.160 Коли бот обґрунтований правильно, ви побачите реальну відповідь про 200 доларах 00:05:45.160 --> 00:05:47.120 разом із посиланням на завантажений документ. 00:05:47.300 --> 00:05:50.300 Саме завдяки цьому посиленню ви знаєте, що досягли успіху. 00:05:50.400 --> 00:05:52.960 Поширеною помилкою є припущення, що розмовне підсилення 00:05:52.960 --> 00:05:55.400 Conversational Boosting магічно заповнить прогалини. 00:05:55.520 --> 00:05:59.000 Підсилення не створює знання політики, воно лише підсилює текстові шаблони. 00:05:59.000 --> 00:06:02.620 Без джерела знань для опори підсилення просто генерує загальні фрази. 00:06:02.620 --> 00:06:06.840 Це як дати стажеру три чашки кави, сподіваючись, що кофеін компенсує відсутність знань. 00:06:06.960 --> 00:06:09.900 У документації до лабораторної роботи навіть було попередження про це. 00:06:10.060 --> 00:06:13.080 Якщо у вашій базі знань не знайдено збійів, система може звернутися 00:06:13.080 --> 00:06:16.400 до вбудованих загальних знань моделі і надати розмиті або неточні відповіді. 00:06:16.560 --> 00:06:19.360 Тому варто налаштувати критично важливі теми так, щоб пошук здійснювався 00:06:19.360 --> 00:06:21.460 лише за доданими вами джерелами, коли важлива точність. 00:06:21.560 --> 00:06:23.740 Не дозволяйте ботовільно використовувати широку мовну модель, 00:06:23.740 --> 00:06:26.180 якщо на кону питання відповідності вимогам, фінанси чи HR. 00:06:26.340 --> 00:06:28.840 Наслідки ігнорування цього кроку швидко накопичуються. 00:06:29.140 --> 00:06:31.740 Необґрунтовані боти можуть підійти для баличок, але як тільки вони відповідають 00:06:31.740 --> 00:06:34.620 на питання про відшкодування чи політику відпусток, вони створюють реальні тікети 00:06:34.620 --> 00:06:38.400 для техпідтримки. Уявіть, як ви пояснюєте фінансовому відділу, чому 5 співробітників 00:06:38.400 --> 00:06:41.440 подали заявки за неправильною ставкою, бо ваш бот вигадав ліміт на ходу. 00:06:41.600 --> 00:06:44.760 Виправлення коштує дорожче, ніж просто завантаження документа в перший день. 00:06:44.760 --> 00:06:48.040 Обґрунтування перетворює вашого агента з ентузіаста, але не відгласа на того, 00:06:48.160 --> 00:06:51.980 кого геймери назвали б юристом за правилами. Він цитує книгу, а не власні здогадки. 00:06:52.160 --> 00:06:54.880 Додайте документ про політику витрат, і система почне дотримуватися 00:06:54.880 --> 00:06:58.120 корпоративних правил замість імпровізації. Ще краще те, що відповіді містять 00:06:58.120 --> 00:07:01.780 підтвердження, чіткі цитати, які можна перевірити. Ось так ви зберігаєте довіру. 00:07:01.920 --> 00:07:05.940 При невдалому результаті ви створили впевнену машину пліток, що поширює вигадані правила. 00:07:05.940 --> 00:07:09.640 При невдалому результаті ви створили обґрунтованого експерта з цитатами. 00:07:09.800 --> 00:07:14.300 Єдиний спосіб отримати останнє – це надати перевірені джерела знань із самого початку. 00:07:14.460 --> 00:07:18.180 І коли ваш бот нарешті зможе говорити правду, ви зіткнетеся з наступним викликом, 00:07:18.340 --> 00:07:22.360 як її подати, адже точність без індивідуальності все одно відштовхує користувачів. 00:07:22.540 --> 00:07:27.920 Наступним кроком є навчання бота його індивідуальності, а в Co-Pilot Studio ви не отримуєте її безкоштовно. 00:07:28.060 --> 00:07:32.180 Ви повинні її прописати. Це момент, коли ви перестаєте дозволяти системі звучати як тестовий манекен 00:07:32.180 --> 00:07:35.180 і починаєте формувати з неї щось, з чим користувачі справді захочуть спілкуватися. 00:07:35.320 --> 00:07:39.400 На практиці це означає редагування полів назви, опису та інструкцій на сторінці огляду. 00:07:39.560 --> 00:07:44.620 Якщо залишити їх порожніми, ви отримаєте шабленні відповіді, схожі на NPC, який застряг у режимі навчання. 00:07:44.800 --> 00:07:47.120 Ось частина, яку багато новачків пропускають. 00:07:47.300 --> 00:07:50.940 Система вже має стиль за замовчуванням у ту саму секунду, як ви натискаєте «Створити». 00:07:50.940 --> 00:07:54.880 Якщо не змінити ці поля, ви отримаєте прісного вітальника без авторитету та контексту. 00:07:55.060 --> 00:07:56.780 Саме контекст завоювує довіру. 00:07:56.780 --> 00:08:03.120 У таких сферах, як HR чи фінанси, загальний тон змушує людей думати, що вони тестують прототип, а не користуються надійним інструментом. 00:08:03.260 --> 00:08:08.680 Швидкий приклад. Скажімо, ви планували створити експерта з політики витрат, але через те, що не змінили назву чи опис, 00:08:08.820 --> 00:08:11.640 агент відображається як звичайний коупайлот без передісторії. 00:08:11.820 --> 00:08:15.400 Хтось запитує про відшкодування за готель, очікуючи професійної поради. 00:08:15.580 --> 00:08:21.300 Вони отримують лише прісний текст без оформлення, що створює тонкий, але потужний сигнал, не довіря й мені. 00:08:21.300 --> 00:08:25.660 Довіра швидко зникає, втрачайте користувачів під час першого контакту, і вони рідко повертаються. 00:08:25.820 --> 00:08:28.880 Уявіть усе це як написання короткого аркуша персонажа. 00:08:29.000 --> 00:08:34.580 Ім'я – це клас, опис, передісторія, поле довгих інструкцій, характеристики, атон, світогляд. 00:08:34.700 --> 00:08:37.480 Ви ж не прийшли б на гру без розподілених очок, навичок. 00:08:37.600 --> 00:08:39.400 Не випускайте бота в такому ж вигляді. 00:08:39.540 --> 00:08:41.080 Тут важливі конкретні цифри. 00:08:41.220 --> 00:08:44.900 Поле імені бота обмежене 30 символами, тому воно має бути коротким і влучним. 00:08:45.080 --> 00:08:48.260 Експерт із політики витрат, путівник, помічник із більг. 00:08:48.260 --> 00:08:52.600 Опис дозволяє використати близько тисячі символів, чого достатньо для кількох чітких речень. 00:08:52.760 --> 00:08:57.760 Наприклад, цей агент надає працівникам актуальні відповіді на основі офіційної політики подорожей. 00:08:57.940 --> 00:09:00.760 Він цитує відповідні розділи та уникає припущень. 00:09:01.100 --> 00:09:05.060 Далі йде поле інструкцій «Ваше гнучке вікно» до восьми тисяч символів. 00:09:05.240 --> 00:09:07.640 Саме там ви можете закріпити реальні правила роботи. 00:09:07.640 --> 00:09:10.160 Не просто пишіть «Будь корисним», а чітко пропишіть сценарій. 00:09:10.280 --> 00:09:12.400 Завжди посилайтеся на пункт політики, якщо це можливо. 00:09:12.400 --> 00:09:14.680 Уникайте відповідей, що базуються на припущеннях. 00:09:14.740 --> 00:09:18.200 Підсумовуйте одним чітким реченням для керівників, а потім надавайте посилання. 00:09:18.360 --> 00:09:21.840 Зручний чек-лист, який можна використовувати при створенні, виглядає так. 00:09:21.960 --> 00:09:27.580 Назвіть роль, напишіть короткий опис експертизи, встановіть тон – офіційний, повсякденний, простий для нефахівців, 00:09:27.740 --> 00:09:32.160 заповніть інструкції поведінковими правилами, що включати, чого уникати, як форматувати. 00:09:32.320 --> 00:09:34.600 Кожен із цих кроків підсилює ідентичність. 00:09:34.780 --> 00:09:36.400 Жоден із них не вимагає складного налаштування. 00:09:36.400 --> 00:09:40.100 Налаштування. Все доступно під час створення або пізніше на сторінці огляду. 00:09:40.320 --> 00:09:42.900 Налаштування тону є тонким, але потужним інструментом. 00:09:43.040 --> 00:09:46.360 Ви можете явно задати його за допомогою фраз типу «офіційний і професійний» 00:09:46.360 --> 00:09:49.460 або «повсякденний і легкий для розуміння персоналом без технічних знань». 00:09:49.460 --> 00:09:51.740 За бажанням додайте приклади прямо в інструкції. 00:09:51.900 --> 00:09:55.480 Потрібно зовсім небагато тексту, щоб спрямувати те, як бот формулює кожне речення. 00:09:55.660 --> 00:09:57.940 Два швидкі покращення, про які знають не всі. 00:09:58.100 --> 00:10:00.900 Відредагуйте стартову тему розмови та змініть іконку агента. 00:10:00.900 --> 00:10:03.100 Обидва кроки займають менше п'ятьох хвилин. 00:10:03.180 --> 00:10:05.080 У панелі тестування ви побачите вступне повідомлення, 00:10:05.220 --> 00:10:06.900 яке бот видає під час першого відкриття чату. 00:10:07.080 --> 00:10:08.560 За замовчуванням воно загальне. 00:10:08.700 --> 00:10:10.720 Натисніть на нього, відредагуйте тему початку розмови 00:10:10.720 --> 00:10:13.460 та замініть стандартне привітання на специфічне, наприклад, «Я тут», 00:10:13.460 --> 00:10:15.400 щоб допомогти вам розібратися в політиці подорожей 00:10:15.400 --> 00:10:17.520 і буду цитувати офіційні документи, коли це можливо. 00:10:17.680 --> 00:10:19.720 Потім он увіть розмову, щоб протестувати зміни. 00:10:19.860 --> 00:10:21.720 Мить і все виглядає значно професійніше. 00:10:21.720 --> 00:10:23.540 Для іконки система підтримує формат PNG 00:10:23.540 --> 00:10:26.960 розміром до 192х192 пікселі та вагою до 30 кібайтам. 00:10:27.080 --> 00:10:29.240 Додавання фірмової графіки, навіть простого логотипа, 00:10:29.360 --> 00:10:32.220 не дає відчуттю демо-версії знищити довіру ще до першої відповіді. 00:10:32.400 --> 00:10:34.860 Дехто відкидає ці правки як необов'язковий лоск, 00:10:34.920 --> 00:10:36.620 але сприймайте їх як базову броню. 00:10:36.760 --> 00:10:38.460 Персонаж без броні може битися, звісно, 00:10:38.560 --> 00:10:40.840 але він гине одразу після першого ж серйозного удару. 00:10:41.000 --> 00:10:42.820 Бот, який вітає користувачів безликою назвою 00:10:42.820 --> 00:10:45.240 та розмитим вступом перебуває в такому ж вразливому становищі. 00:10:45.380 --> 00:10:47.120 Заповніть базові дані, і ви вже забезпочите 00:10:47.120 --> 00:10:49.160 реальний захист від плутанини та відтоку користувачів. 00:10:49.320 --> 00:10:51.300 Невеликі зміни швидко приносять результати. 00:10:51.460 --> 00:10:52.980 Налаштування вступу з описом ролі бота 00:10:52.980 --> 00:10:55.180 підштовхує користувачів ставити доречні запитання. 00:10:55.360 --> 00:10:57.320 Використання правил тону допомагає уникнути 00:10:57.320 --> 00:10:58.280 занадто довгих розмов. 00:10:58.440 --> 00:11:00.540 Уточнення інструкцій спрямовує ще від води 00:11:00.540 --> 00:11:02.560 до зрозумілого людського стилю спілкування. 00:11:02.700 --> 00:11:05.160 Кожна з цих правок означає менше запитів «я не розумію» 00:11:12.820 --> 00:11:14.120 Пишіть короткий і чіткий опис. 00:11:14.320 --> 00:11:16.220 Налаштуйте тон. Додайте в інструкції правила, 00:11:16.340 --> 00:11:17.260 яких слід дотримуватися. 00:11:17.400 --> 00:11:19.020 Оновіть привітання на початку розмови. 00:11:19.200 --> 00:11:21.760 Становіть просту іконку. Це дії з мінімальними зусиллями 00:11:21.760 --> 00:11:23.580 та високою віддачею. При вдалому підході 00:11:23.580 --> 00:11:25.440 продумана персона перетворює навіть нову збірку 00:11:25.440 --> 00:11:27.140 на помічника, з яким хочеться працювати. 00:11:27.320 --> 00:11:29.560 Якщо проігнорувати персону, ви отримаєте незграбного 00:11:29.560 --> 00:11:31.880 NPC, з яким ніхто не захоче спілкуватися вдруге. 00:11:32.000 --> 00:11:34.120 І як тільки ви дали своєму агенту ідентичність, 00:11:34.120 --> 00:11:36.480 ви готові до складнішої роботи, адже справжній тест 00:11:36.480 --> 00:11:38.420 це не створення, а те, що відбувається, 00:11:38.540 --> 00:11:40.460 коли ви бачите помилки в реальних діалогах. 00:11:40.620 --> 00:11:42.700 Саме тоді потрібно зупинитися і вивчити логи 00:11:42.700 --> 00:11:45.060 замість того, щоб здаватися після першої невдачі. 00:11:45.360 --> 00:11:47.400 Налагодження помилок у режимі реального часу. 00:11:47.560 --> 00:11:49.220 Налагодження в реальному часі дозволяє перетворити 00:11:49.220 --> 00:11:50.820 невдачі на уроки, а не натикати підтримки. 00:11:50.940 --> 00:11:53.280 Це практичний цикл, який має проходити кожен розробник. 00:11:53.420 --> 00:11:55.160 Побачте помилку, ізолюйте її, виправте, 00:11:55.160 --> 00:11:56.380 а потім знову запустіть тест. 00:11:56.460 --> 00:11:58.520 Co-Pilot Studio надає інструменти, але тільки якщо 00:11:58.520 --> 00:11:59.740 ви використовуєте їх послідовно. 00:11:59.860 --> 00:12:02.660 Ось алгоритм дій, який ви можете озвучувати під час демонстрації. 00:12:02.820 --> 00:12:04.480 Крок перший. Відтворіть помилковий запит 00:12:04.480 --> 00:12:06.760 користувача в тестовій панелі. Не ігноруйте це. 00:12:06.960 --> 00:12:09.320 Задайте саме те питання, яке поставив би користувач. 00:12:09.440 --> 00:12:10.740 Крок другий. Натисніть іконку 00:12:10.740 --> 00:12:12.780 «Оновлення» або «Новий чат», щоб скинути розмову 00:12:12.780 --> 00:12:14.620 перед повторним тестом. Важливо починати 00:12:14.620 --> 00:12:16.800 з чистого аркуша. Крок третій. Відкрийте 00:12:16.800 --> 00:12:18.700 теми, щоб побачити, яка з них спрацювала. 00:12:18.860 --> 00:12:20.680 Якщо це була не ваша тема, а системна тема 00:12:20.680 --> 00:12:22.480 для посилення розмови, це підказка, щоб 00:12:22.480 --> 00:12:24.140 от поклався на модель, а не на ваші знання. 00:12:24.300 --> 00:12:26.300 Крок четвертий. Якщо це сталося через функцію посилення, 00:12:26.420 --> 00:12:28.620 перевірте, чи був завантажений та індексований ваш файл або сайт. 00:12:28.780 --> 00:12:30.620 Немає індексу, немає опори на ваші дані. 00:12:30.760 --> 00:12:32.980 Пам'ятайте, індексація може зайняти кілька хвилин. 00:12:33.080 --> 00:12:34.760 Крок п'ятий. Відредагуйте свої інструкції 00:12:34.760 --> 00:12:36.740 або вміст теми, збережіть і запустіть той самий 00:12:36.740 --> 00:12:38.840 запит знову. Цей цикл відтворення, виправлення, 00:12:38.940 --> 00:12:40.740 повторний запуск має стати вашою мантрою. 00:12:40.920 --> 00:12:42.860 Якщо ви пропустите цей етап, ви просто сподіватиметеся, 00:12:42.960 --> 00:12:44.240 що наступного разу пощастить більше. 00:12:44.400 --> 00:12:46.700 Іноді проблема не у розпливчастому тоні, а у відсутності 00:12:46.700 --> 00:12:48.560 структури. Саме тут створення нової теми 00:12:48.560 --> 00:12:50.520 дає найкращі результати. У студіоу є 00:12:50.520 --> 00:12:52.760 зручна опція «Додати з опису» за допомогою 00:12:52.760 --> 00:12:54.340 Coopilot прямо на сторінці тем. 00:12:54.480 --> 00:12:56.820 Ви описуєте, що потрібно, наприклад, відповідати 00:12:56.820 --> 00:12:58.640 прямо, коли користувачі питають про ліміти 00:12:58.640 --> 00:13:00.680 витрат. Натискаєте «Додати» і система 00:13:00.680 --> 00:13:02.460 створює дерево тем на основі вашого 00:13:02.460 --> 00:13:04.620 опису. Це швидко, чітко і гарантує, 00:13:04.780 --> 00:13:06.500 що нечітка відповідь наступного разу 00:13:06.500 --> 00:13:08.180 стане надійним шляхом до рішення. 00:13:08.480 --> 00:13:10.400 Використовуйте це щоразу, коли бот ігнорує 00:13:10.400 --> 00:13:12.280 одне й те саме просте запитання. Але не 00:13:12.280 --> 00:13:14.360 обмежуйтеся лише виправленнями «Так чи ні». 00:13:14.360 --> 00:13:16.100 Проведьте 10 хвилинні експерименти, наприклад, 00:13:16.200 --> 00:13:18.640 а в тестування тону спілкування. Зайдіть у поле інструкції, 00:13:18.760 --> 00:13:20.400 напишіть варіант з офіційною мовою 00:13:20.400 --> 00:13:22.540 політики компанії. Збережіть, запитайте 00:13:22.540 --> 00:13:24.340 про ліміт відрядних витрат, зафіксуйте 00:13:24.340 --> 00:13:26.560 відповідь, а потім змініть інструкції на варіант 00:13:26.560 --> 00:13:28.500 «Привітний HR-консультант, який 00:13:28.500 --> 00:13:30.440 дає прості пояснення, посилаючись на 00:13:30.440 --> 00:13:32.240 правила». Запустіть запитання знову, ви 00:13:32.240 --> 00:13:34.180 отримаєте порівняльні записи, які покажуть, 00:13:34.180 --> 00:13:36.180 яка роль працює краще і для цього не потрібно 00:13:36.180 --> 00:13:38.280 нічого, крім тестової панелі. Так ви прийматимете 00:13:38.280 --> 00:13:40.360 рішення щодо тону на основі даних, а не з догадок. 00:13:40.440 --> 00:13:41.880 Тепер додайте перевірку надійності даних 00:13:41.880 --> 00:13:43.780 «Grounding Checks». Припустимо, тестувальник запитує, 00:13:43.900 --> 00:13:45.640 які витрати на готелі я можу відшкодувати. Абот 00:13:45.640 --> 00:13:47.920 відповідає розплив часто «Зверніться до відділу кадрів». 00:13:47.920 --> 00:13:49.700 Це не повний провал, це зворотний зв'язок. 00:13:49.900 --> 00:13:51.760 Можливо, документ «Expensers» по лісі «Докс» 00:13:51.760 --> 00:13:53.860 ще не проіндексовано. Можливо, ваші фрази-тригери 00:13:53.860 --> 00:13:56.060 не включають слово «Готель». Виправте це, перевіривши 00:13:56.060 --> 00:13:58.000 вкладку знань, щоб переконатися, що файл активний, 00:13:58.060 --> 00:13:59.940 а потім додайте «Витрати на готель» як фразу-тригер 00:13:59.940 --> 00:14:01.860 у вашу тему про відрядження. Тепер запустіть 00:14:01.860 --> 00:14:03.940 ще раз. Якщо ви отримаєте, згідно з політикою, 00:14:04.040 --> 00:14:05.860 ліміт на проживання становить 200 доларів за ніч, 00:14:05.980 --> 00:14:07.820 ви успішно виправили помилку. Один тонкий, 00:14:07.980 --> 00:14:09.800 але важливий трюк – використовувати стартові 00:14:09.800 --> 00:14:11.680 фрази для розмови. Порожні текстові поля 00:14:11.680 --> 00:14:13.700 змушують реальних користувачів розгубитися, 00:14:13.840 --> 00:14:15.680 але ви можете додати кілька підказок прямо 00:14:15.680 --> 00:14:17.880 на сторінці огляду. Додайте від 3 до 5 00:14:17.880 --> 00:14:20.140 запитань, наприклад, який ліміт на готель? 00:14:20.300 --> 00:14:21.960 Як подати заявку на відрядження? 00:14:21.960 --> 00:14:24.080 Які витрати на харчування відшкодовуються? 00:14:24.220 --> 00:14:26.080 Користувач відразу натискає на підказку, що означає 00:14:26.080 --> 00:14:27.680 швидше тестування реальних сценаріїв, а сам бот 00:14:27.680 --> 00:14:29.860 справляє враження, що знає свою роль ще до того, як користувач 00:14:29.860 --> 00:14:31.820 почне друкувати. Цей ритм робить вашого бота 00:14:31.820 --> 00:14:33.900 все більш надійним з кожним кроком. Якщо ви 00:14:33.900 --> 00:14:35.820 просто ігноруєте невдалі відповіді, сподіваючись, 00:14:35.940 --> 00:14:37.560 що наступного разу все вийде магічним чином. 00:14:37.700 --> 00:14:39.960 Це призводить до того, що люди створюють тікети в підтримку 00:14:39.960 --> 00:14:41.840 і втрачають довіру. На «Натуральних 20» 00:14:41.840 --> 00:14:44.100 Ви повторюєте цей цикл, доки бот не доведе за допомогою 00:14:44.100 --> 00:14:45.820 цитат і належної персони, що він розуміє 00:14:45.820 --> 00:14:47.880 навіть нечіткі вхідні дані. Кожна ітерація 00:14:47.880 --> 00:14:50.000 наближає вас до надійного помічника, а не до 00:14:50.000 --> 00:14:52.500 непередбачуваного ризику. А ось і реальність. 00:14:52.780 --> 00:14:54.300 Вдосконалення в панелі тестування – це 00:14:54.300 --> 00:14:56.300 безпечний режим. Коли ваш цикл запрацював, 00:14:56.420 --> 00:14:58.260 наступний етап – перевірити, як ці виправлення 00:14:58.260 --> 00:15:00.240 працюють поза вашим комп'ютером. Саме тоді 00:15:00.240 --> 00:15:02.240 з'являються відмінності в каналах, і це те, 00:15:02.240 --> 00:15:04.440 що більшість нових розробників недооцінюють. 00:15:04.540 --> 00:15:06.180 Е. Коли підземелля стає публічним, 00:15:06.300 --> 00:15:08.140 публікація та сюрпризи каналів. Коли ви 00:15:08.140 --> 00:15:10.200 нарешті натискаєте «Опублікувати», ваш агент 00:15:10.200 --> 00:15:12.280 залишає майстерню і має вижити перед реальними 00:15:12.280 --> 00:15:14.380 користувачами. У Coopilot Studio цей етап 00:15:14.380 --> 00:15:16.300 називається «Коли підземелля стає публічним», 00:15:16.300 --> 00:15:18.420 тому що публікація кидає ваш ретельно підготовлений 00:15:18.420 --> 00:15:20.440 бот у канали, які діють за власними правилами. 00:15:20.560 --> 00:15:22.300 Перший сюрприз полягає в тому, що публікація 00:15:22.300 --> 00:15:24.360 це не просто один клік, щоб зробити бота доступним. 00:15:24.500 --> 00:15:26.360 Це процес, який визначає, хто може отримати 00:15:26.360 --> 00:15:28.100 доступ до вашого агента, як вони це зроблять 00:15:28.100 --> 00:15:30.300 і як ці відповіді виглядатимуть у реальному середовищі. 00:15:30.400 --> 00:15:32.480 Teams SharePoint Demo Website – кожен канал 00:15:32.480 --> 00:15:34.360 має свої особливості. Чітка відповідь 00:15:34.360 --> 00:15:36.380 у Studio може виглядати інакше або взагалі 00:15:36.380 --> 00:15:38.200 зникнути після розгортання. Візьмемо 00:15:38.200 --> 00:15:40.540 для прикладу Teams. У Studio ваша відповідь 00:15:40.540 --> 00:15:42.460 виглядає чітко. Згідно з правилами 00:15:42.460 --> 00:15:44.140 200 доларів на день на проживання. 00:15:44.140 --> 00:15:46.160 Перевірте ту саму фразу в Teams і раптом він 00:15:46.160 --> 00:15:48.260 відповідає «Я не розумію, хоча у вашому боті 00:15:48.260 --> 00:15:50.060 нічого не змінилося». Це спосіб, у який 00:15:50.060 --> 00:15:52.320 Teams обгортає текст і передає метадані, порушив 00:15:52.320 --> 00:15:54.220 вирівнювання. SharePoint має власні правила 00:15:54.220 --> 00:15:56.220 щодо міжрядкового інтервалу. Demo Website 00:15:56.220 --> 00:15:58.160 найпростіший, але він все одно може відображати 00:15:58.160 --> 00:16:00.160 форматування інакше, ніж Studio. Кожна 00:16:00.160 --> 00:16:02.120 ціль публікації – це різна арена і ви повинні 00:16:02.120 --> 00:16:04.080 тестувати їх окремо. Яка правильна послідовність 00:16:04.080 --> 00:16:06.240 дій перед тим, як вважати роботу завершеною? Ось контрольний 00:16:06.240 --> 00:16:07.920 список для публікації, який допоможе уникнути 00:16:07.920 --> 00:16:09.980 помилок новачків. По-перше, переконайтеся, що ваші 00:16:09.980 --> 00:16:11.840 файли знань повністю індексовані. Якщо ви їх 00:16:11.840 --> 00:16:14.020 щойно завантажили, вони можуть бути ще не готові до надання відповідей 00:16:14.020 --> 00:16:15.740 у реальному часі. По-друге, налаштуйте 00:16:15.740 --> 00:16:18.300 автентифікацію. Якщо ви проводите широку демонстрацію, 00:16:18.300 --> 00:16:20.220 оберіть відсутність автентифікації, щоб будь-хто 00:16:20.220 --> 00:16:22.220 з посиланням міг спробувати. По-третє, натисніть 00:16:22.220 --> 00:16:24.080 «Опублікувати» і переконайтеся, що ви бачите 00:16:24.080 --> 00:16:25.980 зелений банер підтвердження або оновлення статусу 00:16:25.980 --> 00:16:27.780 на сторінці каналів. По-четверте, відкрийте 00:16:27.780 --> 00:16:30.120 налаштування каналу демо-вебсайту. Оно від привітання 00:16:30.120 --> 00:16:32.120 та підказки для початку розмови, щоб ваші тестувальники 00:16:32.120 --> 00:16:34.160 не завмирали перед порожнім вікном чату. І нарешті 00:16:34.160 --> 00:16:36.220 запустіть закритий пілотний проект. Не запускайте 00:16:36.220 --> 00:16:38.500 його одразу для всього орендаря «Тенан». Невелика група 00:16:38.500 --> 00:16:40.520 з чіткими інструкціями – це розумніше, ніж повний 00:16:40.520 --> 00:16:42.500 реліз. Ця пілотна група повинна знати, що вони 00:16:42.500 --> 00:16:44.800 є тестовою командою. Попросіть їх спробувати невимушений 00:16:44.800 --> 00:16:46.520 стиль, додавати друкарські помилки або навіть 00:16:46.520 --> 00:16:48.520 завантажувати файли, де це доречно. Саме їхні 00:16:48.520 --> 00:16:50.560 помилки виявляють слабкі місця. Закритий 00:16:50.560 --> 00:16:52.660 пілотний запуск не просто полегшує реліз. Він 00:16:52.660 --> 00:16:54.580 надає серій звіти, необхідні для виправлення 00:16:54.580 --> 00:16:56.540 версії перед випуском на рівні всієї компанії. 00:16:56.700 --> 00:16:59.040 Поведінка каналів робить цей етап обов'язковим. 00:16:59.200 --> 00:17:00.920 Усі сценарії, які ви тестували в студіоу, 00:17:01.040 --> 00:17:02.900 офіційні запити, невимушені фрази, помилки 00:17:02.900 --> 00:17:04.600 та посилання на джерела повторіть у кожному 00:17:04.600 --> 00:17:06.460 цільовому каналі. Перевірте, чи інакше вони 00:17:06.460 --> 00:17:08.540 відображаються в Teams. Подивіться, як SharePoint 00:17:08.540 --> 00:17:10.500 змінює інтервали. Перевірте, чи веб-демо 00:17:10.500 --> 00:17:12.460 все ще додає посилання на джерело. Це єдиний 00:17:12.460 --> 00:17:14.700 спосіб довести стабільність роботи. Бездоганний 00:17:14.700 --> 00:17:16.460 тест у студіоу не гарантує успішного 00:17:16.460 --> 00:17:18.360 впровадження. Публікація також означає, що ви 00:17:18.360 --> 00:17:20.500 перестаєте покладатися лише на відгуки користувачів і починаєте 00:17:20.500 --> 00:17:22.540 стежити за телеметрією. Як тільки ваш бот з'являється 00:17:22.540 --> 00:17:24.580 в Teams або на демо-сайті, починають надходити дані 00:17:24.580 --> 00:17:26.200 про використання. Центр адміністрування 00:17:26.200 --> 00:17:28.340 Pava Platform і вбудована аналітика створені, щоб 00:17:28.340 --> 00:17:30.500 допомогти вам. Ви побачите показники впровадження, 00:17:30.640 --> 00:17:32.400 кількість помилок і навіть те, які діалоги 00:17:32.400 --> 00:17:34.440 не запустили потрібну тему. Це не зайва робота, 00:17:34.560 --> 00:17:36.440 це ваша система моніторингу. Ви не просто 00:17:36.440 --> 00:17:38.440 публікуєте і забуваєте, а стежите за логами, 00:17:38.560 --> 00:17:40.360 щоб бот працював правильно і не створював нових 00:17:40.360 --> 00:17:42.520 запитів у підтримку. Якщо ви поспішите на цьому 00:17:42.520 --> 00:17:44.640 етапі, ви втратите довіру. У гіршому випадку 00:17:44.640 --> 00:17:46.720 ви натискаєте кнопку публікації, розгортаєте 00:17:46.720 --> 00:17:48.380 бот на всі відділи і тонете в скаргах, коли 00:17:48.380 --> 00:17:50.420 Teams втрачає важливі відповіді. Користувачі 00:17:50.420 --> 00:17:52.440 здаються і повернути їхню довіру складніше, 00:17:52.560 --> 00:17:54.520 ніж полагодити сам бот. У кращому випадку 00:17:54.520 --> 00:17:56.440 ви сприймаєте публікацію як ще одну фазу 00:17:56.440 --> 00:17:58.320 тестування. Індекс готовий, автентифікація 00:17:58.320 --> 00:18:00.300 налаштована, публікацію підтверджено, демо-сайт 00:18:00.300 --> 00:18:02.180 налаштовано, пілот запущено. Ви збираєте 00:18:02.180 --> 00:18:04.320 складні відгуки, коригуєте відповіді та повторюєте 00:18:04.320 --> 00:18:06.460 всі основні запити в кожному каналі. До моменту 00:18:06.460 --> 00:18:08.520 масштабування на всю компанію тест на міцність 00:18:08.520 --> 00:18:10.500 уже пройдено. Головний секрет – перестати 00:18:10.500 --> 00:18:12.780 думати про публікацію як про фінал. Ця кнопка 00:18:12.780 --> 00:18:14.640 не ставить крапку в книзі, вона починає 00:18:14.640 --> 00:18:16.660 польову кампанію. Коли надійдуть дані пілота 00:18:16.660 --> 00:18:18.500 і логи, підтвердять, що користувачі всюди 00:18:18.500 --> 00:18:20.440 отримують чіткі відповіді, тоді ви заслужено 00:18:20.440 --> 00:18:22.640 зможете назвати його стабільним. Це усвідомлення 00:18:22.640 --> 00:18:24.380 є частиною ширшої картини розробки в 00:18:24.380 --> 00:18:26.540 Coopilot Studio, адже це не одноразова збірка, 00:18:26.540 --> 00:18:28.520 а система, яку ви постійно вдосконалюєте. 00:18:28.680 --> 00:18:30.500 Отже, ось підсумок, який дійсно має 00:18:30.500 --> 00:18:32.580 значення. Три речі перетворять вашу розробку 00:18:32.580 --> 00:18:34.500 з ненадійної на ефективну. По-перше, надайте 00:18:34.500 --> 00:18:36.320 агенту базу знань, завантажте реальні документи 00:18:36.320 --> 00:18:38.400 або вкажіть надійні джерела, щоб він перестав гадувати. 00:18:38.580 --> 00:18:40.640 По-друге, створіть йому персонаж, задайте ім'я, 00:18:40.780 --> 00:18:42.440 опис, тон і чітко пропишіть поведінку 00:18:42.440 --> 00:18:44.240 в полі інструкції на 8000 символів. 00:18:44.360 --> 00:18:46.560 По-третє, не довіряйте ідеальній репетиції, використовуйте 00:18:46.560 --> 00:18:48.200 панель тестування, запустіть закритий пілот, 00:18:48.280 --> 00:18:50.480 а вже потім публікуйте і відстежуйте. Якщо пощастить, 00:18:50.560 --> 00:18:52.420 ці кроки дадуть вам бота, який здобуває довіру 00:18:52.420 --> 00:18:54.400 замість тикетів у підтримку. Підписуйтесь на більше 00:18:54.400 --> 00:18:56.400 і напишіть одним реченням у коментарях назву документа 00:18:56.400 --> 00:18:58.700 з політикою, на основі якого ви налаштували б свого агента.