Агент у Copilot Studio

Ви запускаєте першого агента в Copilot Studio, а він замість влучної відповіді видає щось безглузде. Для створення бота це звична ситуація. Кілька виправлень і чіткі інструкції, що спираються на реальний документ із політикою, перетворять цей провал на точну відповідь із посиланням на конкретний пункт.

У цій статті розглянемо, як відтворити невдалу відповідь у тестовій панелі, прив'язати агента до справжнього джерела знань (grounding), задати йому персону, налагодити помилки й безпечно опублікувати пілотну версію.

Чому ідеальний тестовий бот ламається в реальному світі

У студії все виглядає бездоганно, бо запитання там короткі, чіткі й зазвичай збігаються з прикладами, які ви підготували. Реальні люди пишуть інакше. Керівник запитає, скільки він може отримати за готель. Хтось зробить друкарську помилку в слові «ліміт». Ще хтось напише: «нагадай ще раз про гроші на відрядження». Усі троє питають про одне й те саме, але бот, перевірений лише на запиті «який ліміт витрат», не завжди з'єднає ці формулювання.

Тест із трьома варіантами

Відкрийте тестову панель і перевірте три версії одного запитання: чітку, повсякденну й з друкарською помилкою. Іноді бот влучає в усі три, іноді спрацьовує лише чітка. Це перший сигнал, що гарні результати тестів не гарантують стабільності в реальних умовах.

Охоплення намірів (intent coverage)

Бот орієнтується на фрази-тригери та визначення тем. Якщо всі приклади однакові, модель вразлива, і один синонім може збити її з пантелику. Виправлення просте:

• додайте до тем ширші фрази-тригери, а не лише офіційне формулювання з документації;
• включіть повсякденні, скорочені й навіть трохи недоладні фрази, які люди вживають насправді;
• покрийте очевидні варіації (десятки не потрібні) і протестуйте знову.

Відмінності каналів

Канали по-різному обробляють рядки й форматування. Навіть перенесення ключової фрази на інший рядок може вплинути на оцінку моделі. Тому потрібне ітеративне тестування в кожному каналі. Користувачі не думають про наміри й тригери, вони просто очікують, що бот розуміє їх як колега. Одна невдала відповідь, особливо під час демонстрації, підриває довіру.

Ось типовий приклад. У Studio на запит «який ліміт витрат» бот відповідає, що на проживання передбачено 200 доларів на день. Але на запитання «а на яку суму за готель я можу розраховувати» він може відповісти «Зверніться до HR» або зробити неточне припущення. Намір той самий, результат різний. Тому ставтеся до Studio як до спарингу: він корисний для тренування, але не доводить готовності.

Grounding у Copilot Studio: чому агенту потрібна база знань

Перша помилка новачка полягає в тому, що він сприймає Copilot Studio як магічну кулю. Агент без опори на реальні знання схожий на стажера, якого відправили на нараду керівників без підготовки: говорить швидко й упевнено, але половина сказаного розсипається після перевірки фактів. Такий бот не знає відповіді, він блефує.

Галюцинації та їхня ціна

Найгірший наслідок відсутності обґрунтування — галюцинації, коли бот вигадує правдоподібну, але нічим не підтверджену відповідь. Ви запитуєте про відшкодування витрат на відрядження, а бот називає переконливу, проте вигадану суму. Співробітник бронює готель за цією відповіддю, і з'являються спори щодо витрат та роздратовані листи.

У навчальному прикладі Contoso Labs потрібно завантажити файл Expenses Policy, де чітко вказано ліміт на проживання: 200 доларів за ніч. Без цього файла бот може впевнено відповісти, що ліміт становить 100 доларів. Це повна вигадка. Після додавання документа модель перестає імпровізувати й цитує політику: витрати на проживання обмежені 200 доларами на день.

Як додати знання в агента

1. Відкрийте свого агента в Copilot Studio.
2. На екрані огляду натисніть «Знання» (Knowledge).
3. Оберіть «Додати знання» і завантажте файл із політикою або інше надійне джерело.
4. Зачекайте на індексацію: вона може тривати 10 хвилин або довше.
5. Повторіть запит. У правильно обґрунтованої відповіді буде сума в 200 доларів і посилання на завантажений документ.

Якщо хочете, підключіть публічний вебсайт або SharePoint, але файли — надійніший варіант. Не панікуйте, якщо перші запити ще не використовують новий контент, бо це може бути просто незавершена індексація.

Conversational Boosting не замінює джерело

Поширена помилка — вважати, що Conversational Boosting заповнить прогалини. Воно не створює знань про вашу політику, а лише підсилює текстові шаблони. Без джерела воно генерує загальні фрази, як стажер, якому дали три чашки кави замість знань.

Якщо в базі знань нічого не знайдено, система може звернутися до вбудованих загальних знань моделі й дати розмиті або неточні відповіді. Тому для критично важливих тем налаштуйте пошук лише за доданими вами джерелами. Це особливо важливо, коли йдеться про відповідність вимогам, фінанси чи HR. Виправляти наслідки коштує дорожче, ніж завантажити документ першого дня. Уявіть, що доведеться пояснювати фінансовому відділу, чому 5 співробітників подали заявки за неправильною ставкою.

Персона агента: назва, опис, інструкції й тон

Правильна відповідь потребує й правильної подачі. Точність без індивідуальності відштовхує користувачів. Персону в Copilot Studio потрібно прописати самостійно: якщо залишити поля порожніми, агент матиме стиль за замовчуванням, тобто прісні шаблонні відповіді без авторитету й контексту. У сферах на кшталт HR чи фінансів така загальна манера викликає враження прототипу, а не надійного інструмента.

Що заповнити на сторінці огляду

• Назва — до 30 символів, тому вона має бути короткою й влучною, наприклад «Експерт із політики витрат».
• Опис — близько тисячі символів, цього вистачить на кілька чітких речень. Наприклад: агент надає працівникам актуальні відповіді на основі офіційної політики подорожей, цитує відповідні розділи й уникає припущень.
• Інструкції — до 8000 символів. Тут закріплюються реальні правила роботи. Замість «Будь корисним» пропишіть конкретну поведінку: завжди посилатися на пункт політики, якщо це можливо; уникати відповідей на основі припущень; для керівників підсумовувати одним чітким реченням, а потім давати посилання.

Тон спілкування

Тон можна задати явно: «офіційний і професійний» або «повсякденний і легкий для розуміння персоналом без технічних знань». За бажанням додайте приклади прямо в інструкції. Навіть невеликий текст помітно спрямовує формулювання кожного речення.

Привітання та іконка

Два швидкі покращення займають менш ніж п'ять хвилин. По-перше, відредагуйте стартову тему розмови й замініть стандартне привітання на конкретне, наприклад: «Я допоможу вам розібратися в політиці подорожей і цитуватиму офіційні документи, коли це можливо». По-друге, змініть іконку агента: підтримується PNG розміром до 192×192 пікселі та вагою до 30 кілобайтів. Навіть простий логотип прибирає відчуття демоверсії ще до першої відповіді.

Ці правки — не косметика, а базовий захист від плутанини та відтоку користувачів. Вступ з описом ролі підштовхує ставити доречні запитання, правила тону допомагають уникнути надто довгих розмов, а уточнені інструкції прибирають «воду». Усе це зменшує кількість відповідей на кшталт «я не розумію».

Налагодження агента в реальному часі: цикл «відтворити — виправити — повторити»

Справжній тест починається не зі створення, а тоді, коли з'являються помилки в реальних діалогах. Налагодження перетворює невдачі на уроки. Працює простий цикл: побачити помилку, ізолювати її, виправити й запустити тест знову.

1. Відтворіть запит. Поставте в тестовій панелі саме те запитання, яке задав користувач.
2. Скиньте розмову. Натисніть «Оновлення» або «Новий чат», щоб почати з чистого аркуша.
3. Перегляньте теми. З'ясуйте, яка тема спрацювала. Якщо це системна тема посилення розмови, а не ваша, бот поклався на модель, а не на ваші знання.
4. Перевірте індексацію. Якщо спрацювало посилення, переконайтеся, що ваш файл або сайт завантажено й проіндексовано. Немає індексу — немає опори на ваші дані.
5. Виправте й повторіть. Відредагуйте інструкції або вміст теми, збережіть і запустіть той самий запит ще раз.

Нова тема з опису

Іноді проблема не в тоні, а у відсутності структури. На сторінці тем є опція створення за допомогою Copilot («Додати з опису»). Ви описуєте потрібну поведінку, наприклад «відповідати прямо, коли користувачі питають про ліміти витрат», і система будує дерево теми. Використовуйте це щоразу, коли бот ігнорує одне й те саме просте запитання.

Експерименти з тоном і перевірка grounding

Проведіть десятихвилинний експеримент. Задайте в інструкціях офіційну мову політики компанії, запитайте про ліміт відрядних витрат і запишіть відповідь. Потім змініть інструкції на «привітний HR-консультант, який дає прості пояснення, посилаючись на правила» і повторіть запит. Порівняння покаже, яка роль працює краще, і рішення про тон ґрунтуватиметься на даних, а не на здогадах.

Так само працює перевірка надійності даних (grounding checks). Припустимо, на запитання про відшкодування витрат на готель бот відповідає «Зверніться до відділу кадрів». Це не повний провал, а зворотний зв'язок. Можливо, документ ще не проіндексовано, а можливо, у фразах-тригерах немає слова «готель». Перевірте вкладку знань, додайте «Витрати на готель» як тригер у тему про відрядження й запустіть тест знову. Якщо бот відповість, що ліміт на проживання становить 200 доларів за ніч, помилку виправлено.

Стартові підказки

Порожнє поле вводу збиває користувачів з пантелику. Додайте на сторінці огляду від 3 до 5 стартових фраз, наприклад: «Який ліміт на готель?», «Як подати заявку на відрядження?», «Які витрати на харчування відшкодовуються?». Користувач одразу натискає на підказку, а бот від початку виглядає компетентним.

Публікація агента: канали, пілот і моніторинг

Натискаючи «Опублікувати», ви випускаєте агента в канали, які діють за власними правилами. Публікація визначає, хто матиме доступ до агента, як він його отримає й як виглядатимуть відповіді в реальному середовищі. Teams, SharePoint, демовебсайт — кожен канал має свої особливості. Чітка відповідь у Studio може виглядати інакше або взагалі зникнути після розгортання. Наприклад, у Teams бот може відповісти «Я не розумію», хоча в самому боті нічого не змінилося: причина в тому, як Teams обгортає текст і передає метадані. SharePoint має власні правила міжрядкового інтервалу, а демовебсайт може відображати форматування інакше, ніж Studio.

Контрольний список перед публікацією

1. Переконайтеся, що файли знань повністю проіндексовані.
2. Налаштуйте автентифікацію. Для широкої демонстрації оберіть варіант без автентифікації, щоб будь-хто з посиланням міг спробувати.
3. Натисніть «Опублікувати» й перевірте зелений банер підтвердження або оновлення статусу на сторінці каналів.
4. У налаштуваннях демовебсайту задайте привітання та підказки для початку розмови.
5. Запустіть закритий пілот, а не відкривайте доступ одразу всьому орендарю (tenant).

Закритий пілот

Невелика група з чіткими інструкціями — розумніший вибір, ніж повний реліз. Учасники мають знати, що вони тестова команда. Попросіть їх писати невимушено, робити друкарські помилки й завантажувати файли, де це доречно. Саме їхні помилки виявляють слабкі місця й дають звіти для виправлень до запуску на всю компанію.

Усі сценарії зі Studio (офіційні запити, невимушені фрази, помилки, посилання на джерела) повторіть у кожному цільовому каналі. Подивіться, як відображається відповідь у Teams, як SharePoint змінює інтервали і чи демо досі додає посилання на джерело.

Телеметрія замість здогадів

Після публікації почнуть надходити дані про використання. Центр адміністрування та вбудована аналітика покажуть показники впровадження, кількість помилок і діалоги, у яких не запустилася потрібна тема. Це система моніторингу, тож публікувати й забувати не можна. Публікація — не фінал, а початок польової кампанії: коли дані пілота й логи підтвердять, що користувачі всюди отримують чіткі відповіді, бота можна вважати стабільним.

Типові помилки новачків

• Довіра до ідеальної репетиції. Тест у Studio із зручними запитаннями створює хибну впевненість.
• Бот без бази знань. Без джерела агент блефує й галюцинує.
• Сподівання на Conversational Boosting. Воно не замінює реальні документи.
• Дозвіл на вільне використання загальної моделі у темах про фінанси, HR чи відповідність вимогам.
• Порожні поля назви, опису й інструкцій. Результат — безлика відповідь, яка не викликає довіри.
• Тестування лише в одному каналі. У Teams, SharePoint чи на демосайті відповідь може змінитися.
• Масовий запуск без пілота і ігнорування логів після публікації.
• Поспіх з індексацією. Файл, який щойно завантажили, ще може бути не готовий до відповідей.

Практичні висновки

• Перевіряйте кожне запитання у трьох версіях: чіткій, повсякденній і з друкарською помилкою.
• Розширюйте фрази-тригери синонімами та розмовними формулюваннями.
• Завантажуйте реальні документи в розділ «Знання» й чекайте завершення індексації.
• Для критичних тем обмежуйте пошук доданими джерелами.
• Заповніть назву (до 30 символів), опис (близько тисячі символів) та інструкції (до 8000 символів), задайте тон.
• Оновіть привітання, додайте 3–5 стартових підказок і просту іконку (PNG до 192×192 пікселі, до 30 КБ).
• Налагоджуйте за циклом: відтворити, скинути чат, перевірити тему й індексацію, виправити, повторити.
• Перед публікацією перевірте індексацію й автентифікацію, потім підтвердьте статус публікації.
• Запустіть закритий пілот і повторіть усі сценарії в кожному каналі.
• Після публікації стежте за аналітикою та логами.

Висновок

Надійний агент у Copilot Studio тримається на трьох речах. Перша — база знань: реальні документи замість вгадування. Друга — продумана персона з іменем, описом, тоном і чіткими правилами в інструкціях. Третя — недовіра до ідеальної репетиції: тестування в панелі, закритий пілот і лише потім публікація з постійним моніторингом. Якщо пройти ці кроки послідовно, ви отримаєте бота, який здобуває довіру цитатами з офіційних документів і не створює зайвих тікетів у підтримку.