Агент в Copilot Studio

Бот в Copilot Studio отвечает чётко, ссылается на политику компании и выглядит готовым к запуску. Затем он выходит к реальным людям и вместо точного ответа выдаёт «обратитесь в отдел кадров» или просто выдумывает цифру. Чаще всего причина в нескольких типичных ошибках новичка, и каждую из них можно исправить.

В статье разберём, как воспроизвести плохой ответ в тестовой панели, привязать агента к реальным документам (grounding), настроить его персону, выстроить цикл отладки и безопасно опубликовать пилот.

Почему идеальный бот в тестовой панели ломается в реальных условиях

Тестовая панель Copilot Studio создаёт тепличные условия. Вопросы там короткие, аккуратные и обычно совпадают с теми, что вы заранее придумали. В рабочей среде люди пишут иначе. Руководитель спросит: «Сколько я могу получить компенсации за отель?». Сотрудник напечатает «лимит на отель» с опечаткой. Кто-то бросит: «Напомни-ка про деньги на командировку». Смысл один, но бот, проверенный только на фразе «каков лимит расходов», не всегда сопоставит эти формулировки.

Тест с тремя вариантами вопроса

Увидеть пробел можно прямо сейчас. Задайте боту один и тот же вопрос в трёх видах: чистом, в разговорной перефразировке и с опечаткой. Иногда бот справляется со всеми тремя, а иногда отвечает правильно только на чистую версию. Это первый сигнал, что красивый результат теста не гарантирует работу в реальном мире.

Охват намерений и триггерные фразы

Боты опираются на триггерные фразы и определение тем. Если все примеры похожи друг на друга, модель становится негибкой, и один синоним может её запутать. Решение простое: добавьте в темы более широкие триггерные фразы. Нужны не только формулировки из документов, но и разговорные, сокращённые и слегка небрежные. Десятки вариантов не требуются, достаточно покрыть очевидные вариации и протестировать снова.

Различия каналов

Тестовая панель — лишь симуляция. В Teams, SharePoint или на демо-сайте платформа может иначе обрабатывать входной текст и показывать ответы: Teams по-другому разбивает строки, веб-страница может убрать форматирование. Поэтому Microsoft подчёркивает необходимость итеративного тестирования во всех каналах. Относитесь к студии как к спаррингу: для тренировки она полезна, но готовность не доказывает.

Grounding в Copilot Studio: привяжите агента к реальным документам

Первая и самая дорогая ошибка — запустить агента без опоры на знания. Это похоже на отправку стажёра на совещание без подготовки. Он говорит быстро и уверенно, но половина сказанного рушится, как только кто-то проверит факты. Бот без источников использует языковые закономерности, а не факты, то есть блефует.

Худший результат — галлюцинации, когда бот выдумывает правдоподобное. Спросите про проживание в отеле, и он может уверенно ответить «100 долларов за ночь», хотя в политике расходов указано 200 долларов. Сотрудник забронирует отель по неверной цифре, и вы получите споры о расходах и раздражённые письма.

Как добавить знания

1. Откройте агента в Copilot Studio и на экране обзора перейдите в раздел Knowledge.
2. Нажмите плюс (Add knowledge) и выберите загрузку файла.
3. Укажите документ, например файл с политикой расходов.
4. Дождитесь индексации. Она может занять 10 минут и больше, и первые тестовые запросы могут ещё не использовать новый источник.
5. Повторите вопрос. Если всё настроено верно, бот назовёт 200 долларов и приложит небольшую ссылку на загруженный документ.

Можно подключить и публичный сайт или SharePoint, но файлы работают надёжнее. Ссылка на источник в ответе — признак того, что grounding сработал.

Что не заменит источник знаний

Распространённое заблуждение: усиление диалога заполнит пробелы само. Оно не создаёт знание политики, а лишь усиливает текстовые закономерности. Если в базе знаний нет соответствий, система может обратиться к общим встроенным знаниям модели и дать расплывчатый или неточный ответ. Поэтому для критичных тем (комплаенс, финансы, кадровые вопросы) стоит настроить поиск только по добавленным источникам, когда важна точность.

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

Точность без индивидуальности заставляет пользователей уходить. В Copilot Studio персона не появляется сама, её нужно прописать в полях имени, описания и инструкций на странице обзора. Если оставить их пустыми, получится безликий бот с шаблонными ответами, без авторитета и контекста. В HR или финансах такой общий тон создаёт ощущение прототипа, а не надёжного инструмента.

Ограничения полей

• Имя — до 30 символов. Делайте его коротким и ёмким: «Эксперт по расходам», «Гид по поездкам», «Помощник по льготам».
• Описание — около 1000 символов, этого хватает на пару чётких предложений. Например: агент даёт сотрудникам актуальные ответы на основе официальной политики командировок, цитирует положения и избегает домыслов.
• Инструкции — до 8000 символов. Здесь фиксируются рабочие правила.

Просьбы вроде «будь полезным» работают слабо. Лучше прописать регламент: всегда ссылаться на пункты политики, если они есть; не отвечать предположениями; кратко резюмировать ответ для руководства одним предложением, а затем приводить цитату.

Тон, приветствие и иконка

Тон можно задать прямо: «официально и профессионально» или «непринуждённо и понятно» для сотрудников без технической подготовки. В инструкции можно добавить примеры. Ещё два быстрых улучшения занимают меньше пяти минут:

• Замените стандартную тему начала диалога на специализированное приветствие, например: «Я помогу вам разобраться в политике поездок и по возможности буду ссылаться на официальный документ».
• Загрузите иконку: поддерживается PNG до 192×192 пикселей и весом до 30 кБ.

Это не просто лоск, а базовая «броня». Роль бота в приветствии подталкивает пользователей задавать правильные вопросы, правила тона убирают пустые рассуждения, а строгие инструкции делают стиль естественнее. В итоге меньше жалоб «я вас не понимаю», и для этого не нужны новые коннекторы или плагины.

Отладка в реальном времени: цикл «воспроизвести — исправить — повторить»

Настоящее испытание начинается после создания, когда вы видите успехи и неудачи бота в диалогах. Тогда нужно читать логи, а не бросать всё после первой ошибки. Алгоритм такой:

1. Воспроизведите неудачный запрос в тестовой панели, задав в точности тот же вопрос, что задал бы пользователь.
2. Сбросьте диалог иконкой обновления или новым чатом, чтобы начать с чистого листа.
3. Откройте темы и посмотрите, какая сработала. Если это системная тема расширения диалога, а не ваша, бот опирался на модель, а не на вашу базу знаний.
4. Проверьте, загружен и проиндексирован ли нужный файл или сайт. Нет индексации — нет опоры на знания.
5. Отредактируйте инструкции или содержание темы, сохраните и повторите тот же запрос.

Дополнительные приёмы

Тема из описания. Если проблема в отсутствии структуры, на странице тем используйте «Добавить из описания» с помощью Copilot. Опишите, что нужно, например отвечать прямо на вопросы о лимитах расходов, и система составит дерево узлов темы.

A/B-тест тона. За 10 минут можно сравнить два варианта инструкций. Сначала напишите официальный язык корпоративной политики, задайте вопрос про лимит командировочных и запишите ответ. Затем замените инструкции на «Дружелюбный HR-консультант» с простыми объяснениями и ссылками на правила и снова задайте тот же вопрос. Так выбор тона опирается на факты, а не на догадки.

Проверка достоверности. Если на вопрос о компенсации отеля бот отвечает расплывчато, это обратная связь, а не провал. Возможно, файл ещё не проиндексирован или в триггерных фразах нет слова «отель». Проверьте вкладку знаний, добавьте «расходы на отель» как триггерную фразу в тему о поездках и запустите тест заново.

Подсказки для начала беседы. Пустое поле ввода заставляет пользователей замирать. Добавьте на странице обзора 3–5 ключевых вопросов, например: «Каков лимит на отель?», «Как подать запрос на компенсацию расходов?», «Какие приёмы пищи возмещаются?». Так вы быстрее проверяете реальные сценарии, а пользователь сразу видит, что бот знает свою роль.

Публикация и сюрпризы каналов

Нажатие «Опубликовать» — не один клик, а процесс. Он определяет, кто получит доступ к агенту, как именно и как будут выглядеть ответы. У Teams, SharePoint и демо-сайта свои особенности. Ответ, безупречный в студии, в Teams может превратиться в «Я не понимаю», хотя настройки не менялись: дело в том, как канал переносит текст и передаёт метаданные. SharePoint по-своему работает с межстрочными интервалами, а демо-сайт может иначе отображать форматирование. Каждый канал нужно тестировать отдельно.

Чек-лист публикации

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

Пилот и мониторинг

Пилотная группа должна знать, что она ваша тестовая команда. Попросите её писать разговорным языком, делать опечатки и прикреплять файлы там, где это уместно. Именно их ошибки покажут слабые места до выхода на всю компанию. Все сценарии из студии (формальный запрос, разговорные фразы, опечатки, ссылки на источники) повторите во всех целевых каналах: проверьте, как отображает ответы Teams, не ломает ли форматирование SharePoint, прикрепляет ли веб-демо ссылки на источники.

После публикации начинают поступать данные об использовании. Центр администрирования Power Platform и встроенная аналитика показывают статистику, количество ошибок и диалоги, которые не запустили ни одной темы. Это ваша система мониторинга: публикация не точка, а начало полевой кампании.

Частые ошибки и стопперы новичка

• Бот без базы знаний. Без grounding агент блефует и галлюцинирует, а потом это превращается в заявки в поддержку и споры с финансовым отделом.
• Уверенность по итогам тестов в студии. Чистые вопросы из панели не показывают, как бот справится с разговорной речью и опечатками.
• Расчёт на усиление диалога вместо источников. Оно не создаёт знаний и лишь усиливает текстовые закономерности.
• Пустые поля персоны. Безликое имя, отсутствие описания и инструкций, стандартное приветствие подрывают доверие при первом контакте.
• Неиндексированные файлы. Индексация занимает время, и тест, запущенный слишком рано, вводит в заблуждение.
• Публикация без проверки каналов. Teams, SharePoint и демо-сайт ведут себя по-разному, и общий релиз без пилота грозит жалобами.
• Отладка «на удачу». Если не воспроизводить ошибку и не повторять тест после правки, остаётся только надеяться на везение.

Практические выводы

• Проверяйте бота тремя вариантами одного вопроса: чистым, разговорным и с опечаткой.
• Добавляйте в темы разговорные и сокращённые триггерные фразы, а не только формулировки из документов.
• Загрузите реальные документы в Knowledge и дождитесь индексации. Ссылка на источник в ответе подтверждает, что grounding работает.
• Для критичных тем ограничьте поиск добавленными источниками.
• Заполните имя (до 30 символов), описание (около 1000), инструкции (до 8000), задайте тон, приветствие и иконку.
• Отлаживайте по циклу: воспроизвести, сбросить диалог, проверить тему и индексацию, исправить, повторить.
• Добавьте 3–5 подсказок для начала беседы.
• Проверьте индексацию, аутентификацию и подтверждение публикации, затем проведите закрытый пилот.
• Прогоните ключевые запросы в каждом канале и следите за аналитикой после запуска.

Заключение

Надёжный агент в Copilot Studio складывается из трёх вещей: привязки к проверенным документам, продуманной персоны и дисциплинированного тестирования с пилотом и мониторингом. Тогда бот цитирует правила вместо того, чтобы выдумывать их, звучит как уверенный помощник, а не как безликий манекен, и выдерживает встречу с реальными пользователями. Публикация здесь лишь начало: бота нужно постоянно донастраивать по логам и отзывам.