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

Transcript

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

• 0:00
  Уявіть, що ви запускаєте свого першого агента Co-Pilot Studio, і замість того, щоб справити враження, він видає щось безглозде, наприклад, думаю, політика каже, можливо, це природна частина створення бота.
• 0:09
  Але за допомогою кількох виправлень та чітких інструкцій, що базуються на реальному документи з політикою, ви можете перетворити цей провал на влучну відповідь з посиланнями на конкретні пункти.
• 0:16
  До кінця цього відео ви дізнаєтеся, як відтворити невдалу відповідь у тестовій панелі, виправити її, щоб бот посилався на справжній документ, і опублікувати робочий пілот.
• 0:23
  Короткий відступ. Підпишіться зараз, щоб ці інструкції автоматично з'являлися у вашому списку відтворення.
• 0:28
  Звісно, отримати ідеальну відповідь у тестовому вікні легко.
• 0:31
  Справжні проблеми починаються, коли ваш бот залишає тренувальну зону і потрапляє в реальні умови.
• 0:35
  Чому ваш ідеальний тестовий бот ламається у реальному світі?
• 0:37
  Отже, чому бот, який виглядає бездоганно в тестовій панелі, раптом починає помилятися, як тільки стикається з реальними користувачами?
• 0:42
  Коротко кажучи, студіо утримає все в безпечних і ввічливих межах, тоді як реальний світ не знає такої ввічливості.
• 0:47
  У студіо дані, які ви вводите, є аккуратними.
• 0:50
  Запитання короткі, сформульовані чітко і зазвичай збігаються з підготовленими вами прикладами для навчання.
• 0:54
  Ось чому здається, що все йде бездоганно.
• 0:56
  Але перейдіть до реальної експлуатації, і люди почнуть друкувати так, як вони це роблять у житті.
• 0:59
  Керівник запитає, скільки я можу отримати від шкодування за готель.
• 1:02
  Представник може надрукувати ліміт витрат на готель з друкарською помилкою.
• 1:05
  Хтось інший може просто сказати, нагадай ще раз про гроші на відрядження.
• 1:09
  Усі вони означають одне й те саме, але якщо ви тестували лише, який ліміт витрат, бот не завжди зможе поєднати ці факти.
• 1:15
  Ось спосіб побачити цей розрив прямо зараз.
• 1:17
  Відкрійте тестову панель і випробуйте три варіанти на своєму боті.
• 1:20
  Спочатку чітку версію, потім повсякденну, а потім версію з друкарською помилкою.
• 1:23
  Спостерігайте, як змінюються відповіді.
• 1:25
  Іноді він влучає в усі три, іноді спрацьовує лише чітка версія.
• 1:28
  Це ваш перший сигнал, що гарні результати тестів не гарантують виживання в реальному світі.
• 1:32
  Технічна причина охоплення намірів – інтент каверадж.
• 1:34
  Боти покладаються на фрази-тригери та визначення тем, щоб знати, коли надати відповідь.
• 1:38
  Якщо всі ваші приклади виглядають однаково, модель стає вразливою.
• 1:40
  Один синонім може збити її з пантелику.
• 1:42
  Виправлення нудне, але воно працює.
• 1:44
  Додайте ширші фрази-тригери до своїх тем і не використовуйте лише офіційне формулювання з вашої документації.
• 1:48
  Додайте повсякденні, скорочені, навіть трохи недоладні фрази, які люди використовують насправді.
• 1:52
  Вам не потрібні десятки, достатньо покрити очевидні варіації, а потім повторно протестувати.
• 1:56
  Відмінності в каналах зв'язку роблять це завдання складнішим.
• 2:07
  Рядки інакше.
• 2:08
  Веб-сторінка може видалити форматування.
• 2:10
  Навіть незначні зміни, як от перенесення ключової фрази на інший рядок, можуть вплинути на те, як модель її оцінює.
• 2:15
  Ось чому Microsoft наголошує на необхідності ітеративного тестування в різних каналах.
• 2:18
  Бот, який успішно працює в Studio, може помилитися, коли форматування в реальних умовах змінює ситуацію.
• 2:23
  Користувачі також мають свої очікування.
• 2:25
  Для них перефразування запитання – це звичайна розмова.
• 2:28
  Вони не думають про наміри, тригери чи семантичне перекриття.
• 2:30
  Вони просто припускають, що бот розуміє їх як колега.
• 2:33
  Одна невдала відповідь, особливо під час демонстрації, і довіра втрачена.
• 2:36
  Саме тут новачки часто припускаються помилок.
• 2:38
  Репетиція в Studio дала їм хибне відчуття впевненості, але перший же звичайний запит користувача в Teams зруйнував цю ілюзію.
• 2:44
  Закріпімо це ще одним прикладом.
• 2:45
  У Studio ви пишете, який ліміт витрат.
• 2:48
  Бот відповідає прямо, згідно з політикою, на проживання передбачено 200 доларів на день.
• 2:52
  Ідеально. Розгортаємо.
• 2:53
  Тепер спробуйте, гей, а на яку суму за готель я можу розраховувати.
• 2:56
  Замість цитування політики бот відповідає щось на кшталт «Зверніться до HR» або робить неточне припущення.
• 3:01
  Намір той самий, результат зовсім інший.
• 3:03
  Ця різниця, точність під час репетиції та невизначеність у робочому середовищі – це саме те, про що ми говоримо.
• 3:08
  Практичний висновок такий.
• 3:10
  Ставтеся до Studio як до спарингу.
• 3:12
  Це корисно для навчання, але не є доказом готовності.
• 3:14
  Перш ніж рухатися далі, спробуйте тест із трьома варіантами в панелі тестування,
• 3:17
  а потім розширті свої теми, додавши синоніми та розмовні фрази.
• 3:20
  Нарешті, після публікації проведіть повторне тестування в кожному каналі, де працюватиме бот.
• 3:23
  Ви виявите проблеми раніше за ваших користувачів.
• 3:26
  Але попереду ще більша пастка, адже навіть якщо ви охопили всі фрази та канали,
• 3:29
  ваш бот все одно може помилятися, якщо він не базується на правильному джерелі.
• 3:32
  Саме тоді він перестає пропускати запитання і починає вигадувати відповіді.
• 3:35
  Уявіть бота, який звучить впевнено, але просто вгадує.
• 3:38
  Ось тут і починаються справжні проблеми.
• 3:40
  Помилка новачка – залишати бота без належної бази знань.
• 3:44
  Перша помилка новачка – ставитися до Coopilot Studio як до магічної кулі, а не як до збірника правил.
• 3:48
  Коли ви запускаєте агента без опори на реальні знання,
• 3:51
  ви фактично відправляєте стажера на нараду керівників без жодної підготовки.
• 3:54
  Він говоритиме швидко, звучитиме впевнено, але половина сказаного розсиплеться,
• 3:57
  щойно хтось перевірить факти.
• 3:59
  Це і є пастка відсутності бази знань у бота.
• 4:01
  Спочатку зовнішній близьк це приховує.
• 4:03
  Свіжа збірка в студіо виглядає чудово, ввічливі привітання, швидкі відповіді, жодних затримок.
• 4:07
  Але за лаштунками ці слова нічим не підкріплені.
• 4:10
  Система використовує лише шаблони, а не факти.
• 4:13
  Не обґрунтовані боти нічого не знають.
• 4:15
  Вони блефують.
• 4:15
  Блефують.
• 4:16
  І хоча блеф може виглядати ефектно в тестовому вікні,
• 4:18
  користувачі в реальних умовах миттєво його викриють.
• 4:21
  Найгірший результат – це не просто слабкі відповіді, а галюцинації.
• 4:24
  Це коли бот вигадує те, що виглядає правдоподібно, але немає підґрунтя в реальності.
• 4:28
  Ви запитуєте про відшкодування витрат на відрядження,
• 4:30
  і замість ввічливої відмови бот вигадує суму, яка звучить переконливо.
• 4:33
  Співробітник бронює готель на основі цієї помилкової відповіді,
• 4:36
  і раптом вам доводиться розбиратися зі спорами щодо витрат та роздратованими листами.
• 4:39
  Речення виглядало професійно, а зміст був порожнім.
• 4:42
  Приклад Contoso Labs робить це очевидним.
• 4:44
  В офіційній практичній вправі ви маєте завантажити файл під назвою
• 4:47
  Expenses Policy – DocEx.
• 4:49
  У ньому чітко вказано ліміт на проживання – 200 доларів за ніч.
• 4:52
  А тепер, якщо ви пропустите обґрунтування і запитаєте свого новенького бота,
• 4:55
  яка політика щодо готелів?
• 4:56
  Він може впевнено відповісти – 100 доларів за ніч.
• 4:59
  Повністю вигадано.
• 5:00
  Тільки коли ви додасте файл Expenses Policy – DocEx, модель перестане імпровізувати.
• 5:04
  Обґрунтовані боти посилаються на документ.
• 5:06
  Згідно з корпоративною політикою відряджень,
• 5:08
  витрати на проживання обмежені 200 доларами на день.
• 5:10
  І ця різниця між вигадкою та цитуванням полягає саме в етапі обґрунтування.
• 5:14
  Отже, ось як саме це виправити в інтерфейсі.
• 5:16
  Перейдіть до свого агента в Co-Pilot Studio.
• 5:18
  На екрані огляду натисніть «Знання – Knowledge».
• 5:20
  Оберіть «Додати знання – PlusEd Knowledge», а потім завантажте файл.
• 5:23
  Вкажіть на файл Expenses Policy, DocEx або інше надійне джерело.
• 5:26
  Якщо ви віддаєте перевагу підключенню до публічного веб-сайту або SharePoint,
• 5:29
  ви можете обрати і це, але файли – надійніший варіант.
• 5:31
  Після завантаження зачекайте.
• 5:33
  Індексація може тривати 10 хвилин або довше, перш ніж контент стане доступним.
• 5:36
  Не панікуйте, якщо перші тестові запити не використовують його одразу.
• 5:39
  Коли індексація завершиться, повторіть свій запит.
• 5:41
  Коли бот обґрунтований правильно, ви побачите реальну відповідь про 200 доларах
• 5:45
  разом із посиланням на завантажений документ.
• 5:47
  Саме завдяки цьому посиленню ви знаєте, що досягли успіху.
• 5:50
  Поширеною помилкою є припущення, що розмовне підсилення
• 5:52
  Conversational Boosting магічно заповнить прогалини.
• 5:55
  Підсилення не створює знання політики, воно лише підсилює текстові шаблони.
• 5:59
  Без джерела знань для опори підсилення просто генерує загальні фрази.
• 6:02
  Це як дати стажеру три чашки кави, сподіваючись, що кофеін компенсує відсутність знань.
• 6:06
  У документації до лабораторної роботи навіть було попередження про це.
• 6:10
  Якщо у вашій базі знань не знайдено збійів, система може звернутися
• 6:13
  до вбудованих загальних знань моделі і надати розмиті або неточні відповіді.
• 6:16
  Тому варто налаштувати критично важливі теми так, щоб пошук здійснювався
• 6:19
  лише за доданими вами джерелами, коли важлива точність.
• 6:21
  Не дозволяйте ботовільно використовувати широку мовну модель,
• 6:23
  якщо на кону питання відповідності вимогам, фінанси чи HR.
• 6:26
  Наслідки ігнорування цього кроку швидко накопичуються.
• 6:29
  Необґрунтовані боти можуть підійти для баличок, але як тільки вони відповідають
• 6:31
  на питання про відшкодування чи політику відпусток, вони створюють реальні тікети
• 6:34
  для техпідтримки. Уявіть, як ви пояснюєте фінансовому відділу, чому 5 співробітників
• 6:38
  подали заявки за неправильною ставкою, бо ваш бот вигадав ліміт на ходу.
• 6:41
  Виправлення коштує дорожче, ніж просто завантаження документа в перший день.
• 6:44
  Обґрунтування перетворює вашого агента з ентузіаста, але не відгласа на того,
• 6:48
  кого геймери назвали б юристом за правилами. Він цитує книгу, а не власні здогадки.
• 6:52
  Додайте документ про політику витрат, і система почне дотримуватися
• 6:54
  корпоративних правил замість імпровізації. Ще краще те, що відповіді містять
• 6:58
  підтвердження, чіткі цитати, які можна перевірити. Ось так ви зберігаєте довіру.
• 7:01
  При невдалому результаті ви створили впевнену машину пліток, що поширює вигадані правила.
• 7:05
  При невдалому результаті ви створили обґрунтованого експерта з цитатами.
• 7:09
  Єдиний спосіб отримати останнє – це надати перевірені джерела знань із самого початку.
• 7:14
  І коли ваш бот нарешті зможе говорити правду, ви зіткнетеся з наступним викликом,
• 7:18
  як її подати, адже точність без індивідуальності все одно відштовхує користувачів.
• 7:22
  Наступним кроком є навчання бота його індивідуальності, а в Co-Pilot Studio ви не отримуєте її безкоштовно.
• 7:28
  Ви повинні її прописати. Це момент, коли ви перестаєте дозволяти системі звучати як тестовий манекен
• 7:32
  і починаєте формувати з неї щось, з чим користувачі справді захочуть спілкуватися.
• 7:35
  На практиці це означає редагування полів назви, опису та інструкцій на сторінці огляду.
• 7:39
  Якщо залишити їх порожніми, ви отримаєте шабленні відповіді, схожі на NPC, який застряг у режимі навчання.
• 7:44
  Ось частина, яку багато новачків пропускають.
• 7:47
  Система вже має стиль за замовчуванням у ту саму секунду, як ви натискаєте «Створити».
• 7:50
  Якщо не змінити ці поля, ви отримаєте прісного вітальника без авторитету та контексту.
• 7:55
  Саме контекст завоювує довіру.
• 7:56
  У таких сферах, як HR чи фінанси, загальний тон змушує людей думати, що вони тестують прототип, а не користуються надійним інструментом.
• 8:03
  Швидкий приклад. Скажімо, ви планували створити експерта з політики витрат, але через те, що не змінили назву чи опис,
• 8:08
  агент відображається як звичайний коупайлот без передісторії.
• 8:11
  Хтось запитує про відшкодування за готель, очікуючи професійної поради.
• 8:15
  Вони отримують лише прісний текст без оформлення, що створює тонкий, але потужний сигнал, не довіря й мені.
• 8:21
  Довіра швидко зникає, втрачайте користувачів під час першого контакту, і вони рідко повертаються.
• 8:25
  Уявіть усе це як написання короткого аркуша персонажа.
• 8:29
  Ім'я – це клас, опис, передісторія, поле довгих інструкцій, характеристики, атон, світогляд.
• 8:34
  Ви ж не прийшли б на гру без розподілених очок, навичок.
• 8:37
  Не випускайте бота в такому ж вигляді.
• 8:39
  Тут важливі конкретні цифри.
• 8:41
  Поле імені бота обмежене 30 символами, тому воно має бути коротким і влучним.
• 8:45
  Експерт із політики витрат, путівник, помічник із більг.
• 8:48
  Опис дозволяє використати близько тисячі символів, чого достатньо для кількох чітких речень.
• 8:52
  Наприклад, цей агент надає працівникам актуальні відповіді на основі офіційної політики подорожей.
• 8:57
  Він цитує відповідні розділи та уникає припущень.
• 9:01
  Далі йде поле інструкцій «Ваше гнучке вікно» до восьми тисяч символів.
• 9:05
  Саме там ви можете закріпити реальні правила роботи.
• 9:07
  Не просто пишіть «Будь корисним», а чітко пропишіть сценарій.
• 9:10
  Завжди посилайтеся на пункт політики, якщо це можливо.
• 9:12
  Уникайте відповідей, що базуються на припущеннях.
• 9:14
  Підсумовуйте одним чітким реченням для керівників, а потім надавайте посилання.
• 9:18
  Зручний чек-лист, який можна використовувати при створенні, виглядає так.
• 9:21
  Назвіть роль, напишіть короткий опис експертизи, встановіть тон – офіційний, повсякденний, простий для нефахівців,
• 9:27
  заповніть інструкції поведінковими правилами, що включати, чого уникати, як форматувати.
• 9:32
  Кожен із цих кроків підсилює ідентичність.
• 9:34
  Жоден із них не вимагає складного налаштування.
• 9:36
  Налаштування. Все доступно під час створення або пізніше на сторінці огляду.
• 9:40
  Налаштування тону є тонким, але потужним інструментом.
• 9:43
  Ви можете явно задати його за допомогою фраз типу «офіційний і професійний»
• 9:46
  або «повсякденний і легкий для розуміння персоналом без технічних знань».
• 9:49
  За бажанням додайте приклади прямо в інструкції.
• 9:51
  Потрібно зовсім небагато тексту, щоб спрямувати те, як бот формулює кожне речення.
• 9:55
  Два швидкі покращення, про які знають не всі.
• 9:58
  Відредагуйте стартову тему розмови та змініть іконку агента.
• 10:00
  Обидва кроки займають менше п'ятьох хвилин.
• 10:03
  У панелі тестування ви побачите вступне повідомлення,
• 10:05
  яке бот видає під час першого відкриття чату.
• 10:07
  За замовчуванням воно загальне.
• 10:08
  Натисніть на нього, відредагуйте тему початку розмови
• 10:10
  та замініть стандартне привітання на специфічне, наприклад, «Я тут»,
• 10:13
  щоб допомогти вам розібратися в політиці подорожей
• 10:15
  і буду цитувати офіційні документи, коли це можливо.
• 10:17
  Потім он увіть розмову, щоб протестувати зміни.
• 10:19
  Мить і все виглядає значно професійніше.
• 10:21
  Для іконки система підтримує формат PNG
• 10:23
  розміром до 192х192 пікселі та вагою до 30 кібайтам.
• 10:27
  Додавання фірмової графіки, навіть простого логотипа,
• 10:29
  не дає відчуттю демо-версії знищити довіру ще до першої відповіді.
• 10:32
  Дехто відкидає ці правки як необов'язковий лоск,
• 10:34
  але сприймайте їх як базову броню.
• 10:36
  Персонаж без броні може битися, звісно,
• 10:38
  але він гине одразу після першого ж серйозного удару.
• 10:41
  Бот, який вітає користувачів безликою назвою
• 10:42
  та розмитим вступом перебуває в такому ж вразливому становищі.
• 10:45
  Заповніть базові дані, і ви вже забезпочите
• 10:47
  реальний захист від плутанини та відтоку користувачів.
• 10:49
  Невеликі зміни швидко приносять результати.
• 10:51
  Налаштування вступу з описом ролі бота
• 10:52
  підштовхує користувачів ставити доречні запитання.
• 10:55
  Використання правил тону допомагає уникнути
• 10:57
  занадто довгих розмов.
• 10:58
  Уточнення інструкцій спрямовує ще від води
• 11:00
  до зрозумілого людського стилю спілкування.
• 11:02
  Кожна з цих правок означає менше запитів «я не розумію»
• 11:12
  Пишіть короткий і чіткий опис.
• 11:14
  Налаштуйте тон. Додайте в інструкції правила,
• 11:16
  яких слід дотримуватися.
• 11:17
  Оновіть привітання на початку розмови.
• 11:19
  Становіть просту іконку. Це дії з мінімальними зусиллями
• 11:21
  та високою віддачею. При вдалому підході
• 11:23
  продумана персона перетворює навіть нову збірку
• 11:25
  на помічника, з яким хочеться працювати.
• 11:27
  Якщо проігнорувати персону, ви отримаєте незграбного
• 11:29
  NPC, з яким ніхто не захоче спілкуватися вдруге.
• 11:32
  І як тільки ви дали своєму агенту ідентичність,
• 11:34
  ви готові до складнішої роботи, адже справжній тест
• 11:36
  це не створення, а те, що відбувається,
• 11:38
  коли ви бачите помилки в реальних діалогах.
• 11:40
  Саме тоді потрібно зупинитися і вивчити логи
• 11:42
  замість того, щоб здаватися після першої невдачі.
• 11:45
  Налагодження помилок у режимі реального часу.
• 11:47
  Налагодження в реальному часі дозволяє перетворити
• 11:49
  невдачі на уроки, а не натикати підтримки.
• 11:50
  Це практичний цикл, який має проходити кожен розробник.
• 11:53
  Побачте помилку, ізолюйте її, виправте,
• 11:55
  а потім знову запустіть тест.
• 11:56
  Co-Pilot Studio надає інструменти, але тільки якщо
• 11:58
  ви використовуєте їх послідовно.
• 11:59
  Ось алгоритм дій, який ви можете озвучувати під час демонстрації.
• 12:02
  Крок перший. Відтворіть помилковий запит
• 12:04
  користувача в тестовій панелі. Не ігноруйте це.
• 12:06
  Задайте саме те питання, яке поставив би користувач.
• 12:09
  Крок другий. Натисніть іконку
• 12:10
  «Оновлення» або «Новий чат», щоб скинути розмову
• 12:12
  перед повторним тестом. Важливо починати
• 12:14
  з чистого аркуша. Крок третій. Відкрийте
• 12:16
  теми, щоб побачити, яка з них спрацювала.
• 12:18
  Якщо це була не ваша тема, а системна тема
• 12:20
  для посилення розмови, це підказка, щоб
• 12:22
  от поклався на модель, а не на ваші знання.
• 12:24
  Крок четвертий. Якщо це сталося через функцію посилення,
• 12:26
  перевірте, чи був завантажений та індексований ваш файл або сайт.
• 12:28
  Немає індексу, немає опори на ваші дані.
• 12:30
  Пам'ятайте, індексація може зайняти кілька хвилин.
• 12:33
  Крок п'ятий. Відредагуйте свої інструкції
• 12:34
  або вміст теми, збережіть і запустіть той самий
• 12:36
  запит знову. Цей цикл відтворення, виправлення,
• 12:38
  повторний запуск має стати вашою мантрою.
• 12:40
  Якщо ви пропустите цей етап, ви просто сподіватиметеся,
• 12:42
  що наступного разу пощастить більше.
• 12:44
  Іноді проблема не у розпливчастому тоні, а у відсутності
• 12:46
  структури. Саме тут створення нової теми
• 12:48
  дає найкращі результати. У студіоу є
• 12:50
  зручна опція «Додати з опису» за допомогою
• 12:52
  Coopilot прямо на сторінці тем.
• 12:54
  Ви описуєте, що потрібно, наприклад, відповідати
• 12:56
  прямо, коли користувачі питають про ліміти
• 12:58
  витрат. Натискаєте «Додати» і система
• 13:00
  створює дерево тем на основі вашого
• 13:02
  опису. Це швидко, чітко і гарантує,
• 13:04
  що нечітка відповідь наступного разу
• 13:06
  стане надійним шляхом до рішення.
• 13:08
  Використовуйте це щоразу, коли бот ігнорує
• 13:10
  одне й те саме просте запитання. Але не
• 13:12
  обмежуйтеся лише виправленнями «Так чи ні».
• 13:14
  Проведьте 10 хвилинні експерименти, наприклад,
• 13:16
  а в тестування тону спілкування. Зайдіть у поле інструкції,
• 13:18
  напишіть варіант з офіційною мовою
• 13:20
  політики компанії. Збережіть, запитайте
• 13:22
  про ліміт відрядних витрат, зафіксуйте
• 13:24
  відповідь, а потім змініть інструкції на варіант
• 13:26
  «Привітний HR-консультант, який
• 13:28
  дає прості пояснення, посилаючись на
• 13:30
  правила». Запустіть запитання знову, ви
• 13:32
  отримаєте порівняльні записи, які покажуть,
• 13:34
  яка роль працює краще і для цього не потрібно
• 13:36
  нічого, крім тестової панелі. Так ви прийматимете
• 13:38
  рішення щодо тону на основі даних, а не з догадок.
• 13:40
  Тепер додайте перевірку надійності даних
• 13:41
  «Grounding Checks». Припустимо, тестувальник запитує,
• 13:43
  які витрати на готелі я можу відшкодувати. Абот
• 13:45
  відповідає розплив часто «Зверніться до відділу кадрів».
• 13:47
  Це не повний провал, це зворотний зв'язок.
• 13:49
  Можливо, документ «Expensers» по лісі «Докс»
• 13:51
  ще не проіндексовано. Можливо, ваші фрази-тригери
• 13:53
  не включають слово «Готель». Виправте це, перевіривши
• 13:56
  вкладку знань, щоб переконатися, що файл активний,
• 13:58
  а потім додайте «Витрати на готель» як фразу-тригер
• 13:59
  у вашу тему про відрядження. Тепер запустіть
• 14:01
  ще раз. Якщо ви отримаєте, згідно з політикою,
• 14:04
  ліміт на проживання становить 200 доларів за ніч,
• 14:05
  ви успішно виправили помилку. Один тонкий,
• 14:07
  але важливий трюк – використовувати стартові
• 14:09
  фрази для розмови. Порожні текстові поля
• 14:11
  змушують реальних користувачів розгубитися,
• 14:13
  але ви можете додати кілька підказок прямо
• 14:15
  на сторінці огляду. Додайте від 3 до 5
• 14:17
  запитань, наприклад, який ліміт на готель?
• 14:20
  Як подати заявку на відрядження?
• 14:21
  Які витрати на харчування відшкодовуються?
• 14:24
  Користувач відразу натискає на підказку, що означає
• 14:26
  швидше тестування реальних сценаріїв, а сам бот
• 14:27
  справляє враження, що знає свою роль ще до того, як користувач
• 14:29
  почне друкувати. Цей ритм робить вашого бота
• 14:31
  все більш надійним з кожним кроком. Якщо ви
• 14:33
  просто ігноруєте невдалі відповіді, сподіваючись,
• 14:35
  що наступного разу все вийде магічним чином.
• 14:37
  Це призводить до того, що люди створюють тікети в підтримку
• 14:39
  і втрачають довіру. На «Натуральних 20»
• 14:41
  Ви повторюєте цей цикл, доки бот не доведе за допомогою
• 14:44
  цитат і належної персони, що він розуміє
• 14:45
  навіть нечіткі вхідні дані. Кожна ітерація
• 14:47
  наближає вас до надійного помічника, а не до
• 14:50
  непередбачуваного ризику. А ось і реальність.
• 14:52
  Вдосконалення в панелі тестування – це
• 14:54
  безпечний режим. Коли ваш цикл запрацював,
• 14:56
  наступний етап – перевірити, як ці виправлення
• 14:58
  працюють поза вашим комп'ютером. Саме тоді
• 15:00
  з'являються відмінності в каналах, і це те,
• 15:02
  що більшість нових розробників недооцінюють.
• 15:04
  Е. Коли підземелля стає публічним,
• 15:06
  публікація та сюрпризи каналів. Коли ви
• 15:08
  нарешті натискаєте «Опублікувати», ваш агент
• 15:10
  залишає майстерню і має вижити перед реальними
• 15:12
  користувачами. У Coopilot Studio цей етап
• 15:14
  називається «Коли підземелля стає публічним»,
• 15:16
  тому що публікація кидає ваш ретельно підготовлений
• 15:18
  бот у канали, які діють за власними правилами.
• 15:20
  Перший сюрприз полягає в тому, що публікація
• 15:22
  це не просто один клік, щоб зробити бота доступним.
• 15:24
  Це процес, який визначає, хто може отримати
• 15:26
  доступ до вашого агента, як вони це зроблять
• 15:28
  і як ці відповіді виглядатимуть у реальному середовищі.
• 15:30
  Teams SharePoint Demo Website – кожен канал
• 15:32
  має свої особливості. Чітка відповідь
• 15:34
  у Studio може виглядати інакше або взагалі
• 15:36
  зникнути після розгортання. Візьмемо
• 15:38
  для прикладу Teams. У Studio ваша відповідь
• 15:40
  виглядає чітко. Згідно з правилами
• 15:42
  200 доларів на день на проживання.
• 15:44
  Перевірте ту саму фразу в Teams і раптом він
• 15:46
  відповідає «Я не розумію, хоча у вашому боті
• 15:48
  нічого не змінилося». Це спосіб, у який
• 15:50
  Teams обгортає текст і передає метадані, порушив
• 15:52
  вирівнювання. SharePoint має власні правила
• 15:54
  щодо міжрядкового інтервалу. Demo Website
• 15:56
  найпростіший, але він все одно може відображати
• 15:58
  форматування інакше, ніж Studio. Кожна
• 16:00
  ціль публікації – це різна арена і ви повинні
• 16:02
  тестувати їх окремо. Яка правильна послідовність
• 16:04
  дій перед тим, як вважати роботу завершеною? Ось контрольний
• 16:06
  список для публікації, який допоможе уникнути
• 16:07
  помилок новачків. По-перше, переконайтеся, що ваші
• 16:09
  файли знань повністю індексовані. Якщо ви їх
• 16:11
  щойно завантажили, вони можуть бути ще не готові до надання відповідей
• 16:14
  у реальному часі. По-друге, налаштуйте
• 16:15
  автентифікацію. Якщо ви проводите широку демонстрацію,
• 16:18
  оберіть відсутність автентифікації, щоб будь-хто
• 16:20
  з посиланням міг спробувати. По-третє, натисніть
• 16:22
  «Опублікувати» і переконайтеся, що ви бачите
• 16:24
  зелений банер підтвердження або оновлення статусу
• 16:25
  на сторінці каналів. По-четверте, відкрийте
• 16:27
  налаштування каналу демо-вебсайту. Оно від привітання
• 16:30
  та підказки для початку розмови, щоб ваші тестувальники
• 16:32
  не завмирали перед порожнім вікном чату. І нарешті
• 16:34
  запустіть закритий пілотний проект. Не запускайте
• 16:36
  його одразу для всього орендаря «Тенан». Невелика група
• 16:38
  з чіткими інструкціями – це розумніше, ніж повний
• 16:40
  реліз. Ця пілотна група повинна знати, що вони
• 16:42
  є тестовою командою. Попросіть їх спробувати невимушений
• 16:44
  стиль, додавати друкарські помилки або навіть
• 16:46
  завантажувати файли, де це доречно. Саме їхні
• 16:48
  помилки виявляють слабкі місця. Закритий
• 16:50
  пілотний запуск не просто полегшує реліз. Він
• 16:52
  надає серій звіти, необхідні для виправлення
• 16:54
  версії перед випуском на рівні всієї компанії.
• 16:56
  Поведінка каналів робить цей етап обов'язковим.
• 16:59
  Усі сценарії, які ви тестували в студіоу,
• 17:01
  офіційні запити, невимушені фрази, помилки
• 17:02
  та посилання на джерела повторіть у кожному
• 17:04
  цільовому каналі. Перевірте, чи інакше вони
• 17:06
  відображаються в Teams. Подивіться, як SharePoint
• 17:08
  змінює інтервали. Перевірте, чи веб-демо
• 17:10
  все ще додає посилання на джерело. Це єдиний
• 17:12
  спосіб довести стабільність роботи. Бездоганний
• 17:14
  тест у студіоу не гарантує успішного
• 17:16
  впровадження. Публікація також означає, що ви
• 17:18
  перестаєте покладатися лише на відгуки користувачів і починаєте
• 17:20
  стежити за телеметрією. Як тільки ваш бот з'являється
• 17:22
  в Teams або на демо-сайті, починають надходити дані
• 17:24
  про використання. Центр адміністрування
• 17:26
  Pava Platform і вбудована аналітика створені, щоб
• 17:28
  допомогти вам. Ви побачите показники впровадження,
• 17:30
  кількість помилок і навіть те, які діалоги
• 17:32
  не запустили потрібну тему. Це не зайва робота,
• 17:34
  це ваша система моніторингу. Ви не просто
• 17:36
  публікуєте і забуваєте, а стежите за логами,
• 17:38
  щоб бот працював правильно і не створював нових
• 17:40
  запитів у підтримку. Якщо ви поспішите на цьому
• 17:42
  етапі, ви втратите довіру. У гіршому випадку
• 17:44
  ви натискаєте кнопку публікації, розгортаєте
• 17:46
  бот на всі відділи і тонете в скаргах, коли
• 17:48
  Teams втрачає важливі відповіді. Користувачі
• 17:50
  здаються і повернути їхню довіру складніше,
• 17:52
  ніж полагодити сам бот. У кращому випадку
• 17:54
  ви сприймаєте публікацію як ще одну фазу
• 17:56
  тестування. Індекс готовий, автентифікація
• 17:58
  налаштована, публікацію підтверджено, демо-сайт
• 18:00
  налаштовано, пілот запущено. Ви збираєте
• 18:02
  складні відгуки, коригуєте відповіді та повторюєте
• 18:04
  всі основні запити в кожному каналі. До моменту
• 18:06
  масштабування на всю компанію тест на міцність
• 18:08
  уже пройдено. Головний секрет – перестати
• 18:10
  думати про публікацію як про фінал. Ця кнопка
• 18:12
  не ставить крапку в книзі, вона починає
• 18:14
  польову кампанію. Коли надійдуть дані пілота
• 18:16
  і логи, підтвердять, що користувачі всюди
• 18:18
  отримують чіткі відповіді, тоді ви заслужено
• 18:20
  зможете назвати його стабільним. Це усвідомлення
• 18:22
  є частиною ширшої картини розробки в
• 18:24
  Coopilot Studio, адже це не одноразова збірка,
• 18:26
  а система, яку ви постійно вдосконалюєте.
• 18:28
  Отже, ось підсумок, який дійсно має
• 18:30
  значення. Три речі перетворять вашу розробку
• 18:32
  з ненадійної на ефективну. По-перше, надайте
• 18:34
  агенту базу знань, завантажте реальні документи
• 18:36
  або вкажіть надійні джерела, щоб він перестав гадувати.
• 18:38
  По-друге, створіть йому персонаж, задайте ім'я,
• 18:40
  опис, тон і чітко пропишіть поведінку
• 18:42
  в полі інструкції на 8000 символів.
• 18:44
  По-третє, не довіряйте ідеальній репетиції, використовуйте
• 18:46
  панель тестування, запустіть закритий пілот,
• 18:48
  а вже потім публікуйте і відстежуйте. Якщо пощастить,
• 18:50
  ці кроки дадуть вам бота, який здобуває довіру
• 18:52
  замість тикетів у підтримку. Підписуйтесь на більше
• 18:54
  і напишіть одним реченням у коментарях назву документа
• 18:56
  з політикою, на основі якого ви налаштували б свого агента.