Latest / M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어) / Copilot Studio 에이전트 제대로 만들기: 그라운딩, 페르소나, 디버깅, 게시까지 초보자 실수 피하기 (AI 더빙)

Transcript

Copilot Studio 에이전트 제대로 만들기: 그라운딩, 페르소나, 디버깅, 게시까지 초보자 실수 피하기 (AI 더빙) · M365.FM – Microsoft 365, Copilot & AI 팟캐스트 (한국어)

0:00
첫 번째 코파일럿 스튜디오 에이전트를 출시했는데
0:02
사람들에게 깊은 인상을 남기기는 커녕
0:04
정책에 따르면 아마도 그게 복구축의 자연스러운 부분인 것 같아요
0:07
와 같이 엉뚱한 답변을 내뱉는 상황을 상상해보세요
0:09
하지만 몇 가지 수정사안과 실제 정책 문서를 기반으로 한 명확한 지침을 더하면
0:13
그런 실수를 정확한 조항을 인용하는 완벽한 답변으로 바꿀 수 있습니다
0:16
이 영상이 끝날 때 쯤이면 테스트창에서 잘못된 응답을 재현하고
0:19
보시 실제 문서를 인용하도록 수정하며
0:21
제대로 작동하는 파일럿을 게시하는 방법을 알게 될 것입니다
0:23
잠깐, 지금 구독 버튼을 눌러 이 가이드들을 재생 목록에 자동으로 추가하세요
0:28
물론 테스트창에서 매끄러운 결과를 얻기는 쉽습니다
0:30
진짜 고통은 봇이 연습실을 떠나 실제 환경에서 허우적될 때 시작됩니다
0:34
완벽했던 테스트 봇이 실제 환경에서 무너지는 이유
0:37
그렇다면 테스트창에서는 흠 잡을 데 없어 보이던 봇이
0:40
왜 실제 사용자들을 상대할 때는 갑자기 헤매는 걸까요?
0:42
간단히 말해, 스튜디오는 환경을 정돈하고 예의 바르게 유지하지만
0:45
현실 세계에는 그런 배려가 없기 때문입니다
0:47
스튜디오에서는 입력값이 깔끔하게 들어옵니다
0:50
질문은 짧고 명확하며 보통 준비한 학습 예제와 일치하죠
0:54
그래서 완벽한 연속 성공처럼 느껴지는 것입니다
0:56
하지만 실제 운영 환경으로 넘어가면 사람들은 평소처럼 타이핑합니다
0:59
선임 직원은 호텔에 머물 때 얼마까지 청구할 수 있나요? 라고 물을 것입니다
1:02
담당자는 호텔 경비 한도를 오타 섞어 입력할 수도 있습니다
1:05
다른 누군가는 그냥 출장비 좀 다시 알려줘 라고 말할지도 모르죠
1:09
모두 같은 의미지만 만약 경비 한도가 얼마인가만 테스트했다면
1:12
봇은 항상 연결고리를 찾지는 못할 것입니다
1:15
지금 바로 이 격차를 확인하는 방법이 있습니다
1:17
테스트창을 열고 봇에게 3가지 변형 질문을 던져보세요
1:20
먼저 깔끔한 버전, 그 다음 평소 사용하는 말투, 마지막으로 오타가 있는 버전을 입력합니다
1:23
응답이 어떻게 바뀌는지 지켜보세요
1:25
때로는 3가지를 모두 맞히지만 때로는 깔끔한 질문에만 제대로 응답할 수도 있습니다
1:28
그것이 바로 아름다운 테스트 결과가 현실 세계에서의 생존을 보장하지 않는다는 첫 번째 신호입니다
1:32
기술적인 이유는 위도 커버리지에 있습니다
1:34
보순 응답을 보낼 시점을 알기 위해 트리거 구문과 토픽 정의에 의존합니다
1:37
모든 예제가 비슷해 보이면 모델은 유연성을 잃게 됩니다
1:40
단 하나의 유의어만으로도 보순 혼란에 빠질 수 있습니다
1:42
해결책은 지루하지만 효과적입니다
1:44
토픽에 덕복 넓은 트리거 구문을 추가하고 정책 문서에 공식적인 문구만 사용하지 마세요
1:48
사람들이 실제로 사용하는 일상적이고 축약된
1:50
심지어는 약간 거친 표현들도 섞어 넣으세요
1:52
수십 개씩 필요하지는 않습니다
1:53
명백한 변형을 커버할 만큼만 추가하고 다시 테스트하세요
1:56
채널 간의 차이가 상황을 더 어렵게 만듭니다
1:58
스튜디오의 테스트 창은 단지 시뮬레이션일 뿐이기 때문입니다
2:00
팀즈, 시어포인트 또는 데모 웹사이트와 같은 채널에 게시하면
2:03
플랫폼에 따라 입력 텍스트 처리 방식이나 응답 렌더링 방식이 달라질 수 있습니다
2:06
팀즈는 줄 바꿈을 다르게 처리할 수 있습니다
2:08
웹페이지는 서식을 제거할 수 있습니다
2:10
핵심 구문을 다른 줄로 옮기는 것 같은 작은 변화도 모델이 가중치를 두는 방식을 바꿀 수 있습니다
2:14
이것이 바로 마이크로소프트가 채널 전반에 걸친 반복적인 테스트의 필요성을 강조하는 이유입니다
2:19
스튜디오에서 통과 한 보디라도 실제 환경의 서식 문제로 인해 실패할 수 있습니다
2:22
사용자에게는 나름의 기대치가 있기 때문입니다
2:25
그들에게 질문을 바꿔 말하는 것은 평범한 대화일 뿐입니다
2:27
사용자는 인텐트, 트리거 또는 의미적 중복에 대해 생각하지 않습니다
2:31
그저 동료가 이해하듯 보또 이해할 것이라고 가정합니다
2:33
특히 데모 중에 한 번이 실수가 발생하면 신뢰도는 무너집니다
2:36
초보 개발자들이 바로 여기서 큰 타격을 입습니다
2:38
스튜디오에서의 연습은 잘못된 안정감을 주지만
2:40
팀즈에서 사용자의 첫 질문이 환상을 깨뜨립니다
2:43
한 가지 예시로 더 자세히 살펴보겠습니다
2:45
스튜디오에서 비용 한도가 얼마인가요? 라고 입력합니다
2:48
보순 숙박비는 하루 200달러입니다 라고 바로 답변합니다
2:51
완벽합니다 이제 배포해봅니다
2:53
이번에는 호텔 비용으로 얼마까지 받을 수 있나요? 라고 물어봅니다
2:56
보순 정책을 인용하는 대신 인사팀에 문외하라는 식의 모호한 답변을 내놓습니다
3:01
위도는 같지만 결과는 완전히 다릅니다
3:03
연습 때는 정확하다가 운영 환경에서 모호해지느니 격차가 바로 우리가 말하고자 하는 핵심입니다
3:08
실질적인 교훈은 다음과 같습니다
3:09
스튜디오를 연습용 스파링 파트너로 여기십시오
3:12
학습에는 유용하지만 준비가 완료되었다는 증거는 아닙니다
3:14
다음 단계로 넘어가기 전에 테스트창에서 세 가지 변형 테스트를 수행하고
3:17
유의어나 일상적인 표현을 포함하여 주제 범위를 넓히십시오
3:20
마지막으로 게시 후에는 봇이 작동할 모든 채널에서 다시 테스트하십시오
3:23
사용자가 문제를 발견하기 전에 여러분이 먼저 찾아낼 수 있습니다
3:26
더 큰 함정이 기다리고 있습니다
3:27
표현과 채널을 다 커버했더라도 올바른 출처에 근거하지 않으면
3:30
봇은 여전히 실패할 수 있습니다
3:32
그때부터 봇은 질문을 놓치는 대신 없는 사실을 지어내기 시작합니다
3:35
자신감 있게 말하지만 실제로는 추측에 불과한 봇을 상상해보세요
3:38
바로 여기서 상황이 복잡해집니다
3:40
초보자의 실수
3:41
즉 봇을 근거 없이 방치하는 것입니다
3:43
첫 번째 초보자의 실수는 코파일럿 스튜디오를 규칙서가 아닌
3:47
수정 구슬처럼 대하는 것입니다
3:48
실제 지식에 근거하지 않고 에이전트를 시작하는 것은
3:51
준비 없이 신입 인턴을 이사회에 내보내는 것과 같습니다
3:54
그들은 빠르게 말하고 자신감 있게 들리겠지만
3:56
누군가 확인하는 즉시 그 말의 절반은 무너질 것입니다
3:58
그것이 바로 봇을 근거 없이 방치하는 함정입니다
4:01
처음에는 그 화려함이 그 허점을 숨겨줍니다
4:03
스튜디오에서 새로 만든 빌드는 세련되고 공손한 인사와 빠른 응답
4:06
지연 없는 매끄러운 모습을 보여줍니다
4:08
그 말 들을 뒷받침할 실체는 없습니다
4:10
시스템은 사실이 아닌 패턴을 끌어다 쓸 뿐입니다
4:12
근거가 없는 봇은 아무것도 알지 못합니다
4:15
허풍을 떠는 것이죠
4:16
테스트 창에서는 그럴듯해 보일지 몰라도
4:18
실제 사용자들은 금방 눈치 챌 것입니다
4:20
가장 최악의 결과는 단순히 부실한 답변이 아니라 환각현상입니다
4:24
환각이란 봇이 사실처럼 보이지만
4:25
실제로는 근거 없는 내용을 지어내는 것을 말합니다
4:28
출장비 환급에 대해 물어보면
4:29
봇은 정중히 거절하는 대신
4:31
그럴듯하게 들리는 숫자를 만들어냅니다
4:33
직원 한 명이 그 잘못된 답변을 믿고 호텔을 예약하면
4:36
즉시 비용 분쟁과 항의 메일을 수습해야 하는 상황이 발생합니다
4:39
문장은 전문적으로 보였지만 내용은 허상이었습니다
4:42
컨투소 랩스위 사례가 이를 잘 보여줍니다
4:44
공식 실습 과정에서는 익스펜시스 플리시
4:47
도크엑스라는 파일을 업로드해야 합니다
4:49
파일 안에는 숙박비 한도가 1박당 200달러라고 명시되어 있습니다
4:52
이제 근거 설정을 건너 뛰고 새로 만든 보색에
4:55
호텔 규정이 뭐야? 라고 물어보면
4:56
1박당 100달러라고 자신있게 답변할지도 모릅니다
4:59
완전히 지어낸 말이죠
5:00
익스펜시스 플리시
5:01
도크엑스 파일을 직접 청구해야만
5:03
모델이 제멋대로 답변하는 것을 멈춥니다
5:04
근거를 가진 보습문서를 인용합니다
5:06
회사 출장 규정에 따르면
5:08
숙박비는 1박당 200달러로 제한됩니다
5:10
날조와 인용의 차이
5:11
그것이 바로 근거 설정 단계의 핵심입니다
5:14
그럼 이제 인터페이스에서 어떻게 해결하는지 알려드리겠습니다
5:16
코파일럿 스튜디오에서 에이전트로 이동하세요
5:18
개요 화면에서 지식 날리지 을 클릭합니다
5:20
지식 추가 플러스를 선택한 다음 파일 업로드를 선택하세요
5:23
익스펜시스 폴리시
5:24
도크엑스 또는 다른 신뢰할 수 있는 소스를 지정합니다
5:26
공개 웹사이트 나쉐어 포인트 위치에 연결하고 싶다면 그렇게 해도 되지만
5:30
파일이 훨씬 깔끔합니다
5:31
업로드한 후에는 기다리세요
5:33
내용이 준비되기까지 인덱싱의 10분이 상소요될 수 있습니다
5:36
초기 테스트 질문에서 즉시 결과가 나오지 않는다고 당황하지 마세요
5:39
인덱싱이 완료되면 질문을 다시 실행해보세요
5:41
제대로 근거가 설정되면
5:42
업로드 한 문서에서 가져왔다는 작은 인용 표시와 함께
5:45
200달러라는 정확한 답변을 보게 될 것입니다
5:47
그 인용 표시가 바로 제대로 설정되었다는 증거입니다
5:50
흔한 오해 중 하나는 대화형 부스팅
5:51
컨버세이셔널 부스팅
5:53
이 부족한 부분을 마법처럼 채워줄 것이라고 믿는 것입니다
5:55
부스팅은 정책에 대한 이해를 새로 만들어내는 것이 아니라
5:57
텍스트 패턴을 강화할 뿐입니다
5:59
근거가 되는 지식 소스가 없으면
6:00
부스팅은 기분 좋게 일반적인 헛소리만 늘어놓습니다
6:02
마치 인턴에게 커피 3잔을 마시게 하고
6:04
카페인이 무지를 보상해주길 기대하는 것과 같습니다
6:07
실습 문서에서도 이에 대해 경고하고 있습니다
6:09
지식 베이스에서 일치하는 내용을 찾지 못하면
6:11
부스팅 기능이 모델에 내장된 일반 지식으로 대체되어
6:14
모호하거나 부정확한 답변을 내놓을 수 있습니다
6:16
그렇기 때문에 정확성이 중요한 중요한 주제의 경우
6:19
추가한 소스에서만 검색하도록 구성해야 합니다
6:21
규정 준수, 재무, 인사 관련 문제라면
6:23
보시 더 넓은 언어모델에서 마음대로 답변하지 않도록 하세요
6:26
이 단계를 무시해서 발생하는 문제는 빠르게 누적됩니다
6:28
근거가 없는 보순 잡담에는 괜찮을지 몰라도
6:30
비용 청구나 휴가 정책에 대해 답변하게 되면
6:33
실제 헬프 데스크 티켓을 유발하게 됩니다
6:35
보시의 즉흥적으로 제한 규정을 지어내는 바람에
6:37
직원 5명이 모두 잘못된 요율로 비용을 청구했다면
6:39
재무팀의 일을 어떻게 설명할지 생각해보세요
6:41
나중에 수정하는 비용이 처음부터 문서를 업로드하는 것보다 훨씬 더 큽니다
6:44
그라운딩, 그라운딩 은 열이만 있고 무제한 인턴 같던 에이전트를
6:47
게이머들이 말하는 규정 준수 전문가로 바꿔줍니다
6:49
보시의 자기 생각이 아닌 규정집을 그대로 인용하게 되는 것입니다
6:52
경비정책 문서를 첨부하면 시스템은 즉흥적으로 행동하는 대신
6:55
사내 규정을 강제하게 됩니다
6:56
더 좋은 점은 답변과 함께 확인할 수 있는 명확한 출처를 제공한다는 것입니다
7:00
그렇게 신뢰를 지키는 것입니다
7:01
운이 나쁘면 내추럴 1, 포위 규정을 퍼뜨리는
7:03
자신감 넘치는 가심머신을 만들게 될 수도 있습니다
7:05
운이 좋으면 내추럴 20 출처를 갖춘 완벽한 전문가를 구축하게 됩니다
7:09
후자를 얻는 유일한 방법은 처음부터 검증된 지식 소스를 입력하는 것입니다
7:14
보시 진실을 말할 수 있게 된 후에는 다음 과제에 직면하게 됩니다
7:17
진실을 전달하는 방식을 다듬는 일이죠
7:19
정확하더라도 개성이 없으면 사용자는 떠나버리기 때문입니다
7:22
보색의 개성을 부여하는 단계가 다음입니다
7:25
코파일러 스튜디오에서는 개성이 저절로 생기지 않습니다
7:28
직접 작성해야 합니다
7:29
이 단계에서 시스템이 시험용 로봇처럼 들리지 않게 하고
7:32
사용자가 실제로 대화하고 싶어하는 존재로 만들어야 합니다
7:35
실제로는 개요 페이지에 있는 이름, 설명, 지침 필드를 편집하는 것을 의미합니다
7:39
이 필드를 비워두면 튜토리얼 모드에 갇힌 NPC 같은 딱딱한 답변만 나오게 됩니다
7:44
많은 초보 빌더 들이 놓치는 부분이 바로 여기입니다
7:47
생성 버튼을 누르는 순간 시스템에는 이미 기본 스타일이 적용되어 있습니다
7:50
필드를 수정하지 않으면 권한도 맥락도 없는 무미건조 한 안내자만 남게 됩니다
7:54
맥락이 있어야 신뢰가 싸딥니다
7:56
인사나 재무 같은 환경에서는 평범한 어조가 사람들에게 이것이 믿을 수 있는 도구가 아니라
8:00
단순한 프로토타입을 테스트하는 것이라고 느끼게 만듭니다
8:03
간단한 예로 비용 정책 전문가를 만들려고 했지만
8:06
이름이나 설명을 바꾸지 않아서 에이전트가 배경 설명도 없는 일반 코파일럿으로 표시되는 경우를 생각해보세요
8:11
누군가 호텔 비용 청구에 대해 전문적인 조언을 기대하며 질문을 던지게 됩니다
8:15
사용자가 받는 것은 아무런 틀도 없는 평범한 텍스트일 뿐이며
8:18
이는 나를 신뢰하지 마세요 라는 미묘하지만 강력한 신호를 보냅니다
8:21
신뢰는 빠르게 무너집니다
8:22
첫 만남에서 사용자를 잃으면 다시 돌아오는 일은 거의 없습니다
8:25
이 전체 설정을 간단한 캐릭터 시트를 작성하는 것처럼 생각해보세요
8:28
이름은 직업, 설명은 배경 이야기, 긴 지시사항 입력란은 능력치, 그리고 어조는 성향입니다
8:34
스킬 포인트를 할당하지 않고 게임 캠페인에 참여하지는 않을 것입니다
8:37
봇을 배포할 때도 그렇게 해서는 안 됩니다
8:39
이제 실제 수치가 중요합니다
8:41
봇 이름 필드는 30자까지 가능함으로 짧고 명확하게 작성하세요
8:44
경비정책 전문가, 여행 가이드, 혜택 도우미 등이 예입니다
8:48
설명란은 약 천자까지 가능하며 명확한 문장 몇 개를 쓰기에 충분합니다
8:52
이 에이전트는 직원들에게 공식 여행 정책에 따른 최신 답변을 제공합니다
8:57
관련 구절을 인용하며 추측성 답변은 피합니다
9:00
그 다음은 최대 8천자까지 작성 가능한 지시사항 필드가 있는데
9:03
이것이 바로 유연하게 활용할 공간입니다
9:05
이곳의 실제 작동 규칙을 고정할 수 있습니다
9:07
단순히 친절하게 대화라고만 하지 말고 구체적인 지침을 제시하세요
9:10
가능할 때는 항상 정책 내용을 인용하세요
9:12
추측성 답변은 피하세요
9:14
임원들을 위해 명확한 한 문장으로 요약한 뒤 근거를 제시하세요
9:18
봇을 만들 때 실제로 확인해볼 수 있는 편리한 체크리스트는 다음과 같습니다
9:21
역할 지정, 전문 분야에 대한 짧은 설명 작성, 어조 설정, 격식 있는, 캐주얼한, 비전문가를 위한 쉬운 어조, 행동규칙으로 지시사항 채우기, 포함할 것, 피할 것, 형식 지정 방법
9:32
이 단계 하나하나가 정체성을 더 탄탄하게 만듭니다
9:34
어느 것도 복잡한 설정이 필요하지 않습니다
9:36
생성 과정에서 바로 할 수 있거나 나중에 개요 페이지에서 수정할 수 있습니다
9:40
어조에 대한 지침은 미묘하지만 강력합니다
9:42
격식 있고 전문적인 또는 기술적 배경이 없는 직원을 위한 캐주얼하고 이해하기 쉬운 과 같은 문구로 명시적으로 유도할 수 있습니다
9:49
원한다면 지시사항에 바로 예시를 추가하세요
9:51
보시 모든 문장을 구성하는 방식을 조절하는데 많은 텍스트가 필요한 것은 아닙니다
9:55
잘 알려지지 않은 두 가지 빠른 개선 방법이 있습니다
9:58
대화 시작 주제를 편집하고 에이전트 아이콘을 교체하세요
10:01
둘 다 5분도 채 걸리지 않습니다
10:03
테스트 창에서 처음 채팅을 열 때 보시 제공하는 소개 메시지를 볼 수 있습니다
10:06
기본적으로는 일반적인 내용입니다
10:08
해당 메시지를 클릭하여 대화 시작 주제를 편집하고
10:11
상투적인 환영 인사를 여행 정책을 이해하도록 돕고 가능한 경우 공식 문서를 인용하겠습니다
10:15
와 같이 역할에 맞는 소개로 바꾸세요
10:17
그런 다음 대화를 새로 고침하여 테스트 해보세요
10:19
즉시 훨씬 더 전문적으로 보입니다
10:21
아이콘의 경우 시스템은 30킬로바이트 미만 최대 192x192 픽셀의 png 파일을 지원합니다
10:26
브랜드 그래픽이나 간단한 로고를 넣기만 해도
10:28
데모 같은 느낌 때문에 첫 응답부터 신뢰를 잃는 일을 막을 수 있습니다
10:31
어떤 이들은 이런 수정사항을 선택적인 보완작업으로 치부합니다
10:34
하지만 이를 기본적인 방어부라고 생각해보세요
10:36
방어부가 없는 캐릭터도 공격은 할 수 있겠지만
10:38
제대로 된 첫 타격에 바로 쓰러지고 맙니다
10:41
특색 없는 이름과 모호한 인산말로 사용자를 맞는 봇도 이처럼 무방비 한 상태와 같습니다
10:45
기본적인 사항만 채워 넣어도 혼란과 이탈을 막는 확실한 방어막을 구축하게 됩니다
10:49
작은 변화가 빠르게 큰 효과를 냅니다
10:51
역할을 명시하는 소개문구를 설정하면
10:53
사용자가 적절한 질문을 하도록 유도할 수 있습니다
10:55
톤 규칙을 활용하면 장황한 답변을 피할 수 있습니다
10:58
지침을 구체화하여 ai가 불필요한 말을 줄이고
11:00
사람이 읽기 쉬운 스타일로 답변하게 합니다
11:02
이런 조정 하나하나가 이해하지 못했습니다
11:04
라는 티켓을 줄이고
11:05
커넥터 나플라그인 추가 없이도 더 매끄러운 흐름을 만듭니다
11:07
그러니 원칙으로 삼으세요
11:08
고급 로직을 다루기 전에 페르소나부터 설정하세요
11:10
목적을 드러내는 이름을 선택하세요
11:12
짧고 명확한 설명을 작성하세요
11:14
어조를 설정하세요
11:15
따라야 할 규칙들로 지침을 채우세요
11:17
대화 시작 인삿말을 업데이트하세요
11:18
간단한 아이콘으로 교체하세요
11:20
이는 적은 노력으로 큰 성과를 거두는 방법입니다
11:22
성공적으로 설정된 페르소나는
11:24
신규 빌드조차 사용자가 함께하고 싶은 팀원으로 바꿔놓습니다
11:27
반면 페르소나를 생략하면
11:28
아무도 두 번 다시 찾지 않는 어색한 NPC만 남게 됩니다
11:31
에이전트에게 정체성을 부여했다면
11:33
이제 더 어려운 작업에 나설 준비가 된 것입니다
11:35
진짜 테스트는 생성이 아니라
11:36
실제 상황에서 봇이 잘 대응하는지 아니면
11:38
실수하는지를 지켜보는 것이기 때문입니다
11:40
첫 번째 실수에 포기하지 말고
11:42
멈춰서서 로그를 확인해야 할 때입니다
11:45
실시간으로 실수를 디버깅하세요
11:47
실시간 디버깅은 실수를 티켓이 아닌
11:49
교훈으로 바꿀 수 있는 과정입니다
11:50
이것이 모든 빌더가 실행해야 할 실무적인 루프입니다
11:53
실수를 확인하고 격리하고 수정하고
11:55
다시 테스트를 실행하세요
11:56
코파일러 스튜디오는 도구를 제공하지만
11:58
순서대로 사용할 때만 효과가 있습니다
11:59
시연하면서 소리 내어 따라 할 수 있는 루틴은 다음과 같습니다
12:02
1단계 테스트 창에서 실패한 사용자 질문을 재현하세요
12:05
대충 넘기지 마세요
12:06
사용자가 질문할 것과 정확히 똑같이 물어보세요
12:09
2단계 다시 실행하기 전에
12:10
새로 고침 아이콘이나 새 채팅을 눌러 대화를 초기화하세요
12:13
깨끗한 상태에서 시작하는 것이 중요합니다
12:15
3단계 어떤 토픽이 작동했는지 확인하려면
12:18
토픽 창을 여세요
12:18
직접 만든 토픽이 아니라 시스템의 대화 강화
12:20
부스팅, 토픽이었다면
12:22
고시 지식이 아닌 모델에 의존했다는 신호입니다
12:24
4단계 강화 토픽에서 발생했다면
12:25
관련 파일이나 사이트가 업로드되고
12:27
인덱싱 되었는지 확인하세요
12:28
인덱스가 없으면 근거, 그라운딩, 도 없습니다
12:30
인덱싱에는 몇 분 정도 걸릴 수 있다는 점을 기억하세요
12:33
5단계 지침이나 주제 콘텐츠를 수정하고 저장한 다음
12:35
똑같은 커리를 다시 실행하세요
12:37
재현, 수점, 재실행
12:39
반복이라는 이 루프가 여러분의 만들어입니다
12:40
이를 건너뛰면 다음번에 눈 좋게
12:42
더 나은 결과가 나오길 바랄 뿐인 셈입니다
12:44
때로는 답이 모호한 어조 때문이 아니라
12:45
구조가 부족해서 그럴 수 있습니다
12:47
바로 그럴 때 새로운 주제를 만드는 것이 효과적입니다
12:49
스튜디오의 주제 페이지에는 코파일럿을 사용하여
12:52
설명에서 바로 추가하는 편리한 옵션이 있습니다
12:54
사용자가 비용 한도에 대해 물어볼 때
12:56
바로 답하라는 식으로 필요한 내용을 설명하세요
12:58
추가를 누르면 시스템이 그 설명을 바탕으로
13:01
주제 노트 트리를 작성합니다
13:02
빠르고 명확하며 답답했던 모호한 응답을
13:05
다음번에는 확실한 답변 경로로 바꿔줍니다
13:08
보시 똑같은 기본 질문을 계속 회피할 때
13:10
마다이 기능을 사용하세요
13:11
하지만 예, 아니오식의 수정에만 그치지 마세요
13:14
어조를 A, B 테스트하는 것처럼
13:15
10분 정도 실험을 해보세요
13:17
지침 필드로 들어가서
13:18
격식 있는 정체 거너를 사용하는 A버전을 작성하세요
13:21
저장하고 출장 경비 한도가 얼마인지 물어본 뒤
13:23
답변을 기록하세요
13:24
그 다음 지침을 B버전으로 바꾸세요
13:26
규정을 인용하면서 간단하고 친근하게 설명하는
13:29
인사 담당자 페르소나입니다
13:31
같은 질문을 다시 실행하면
13:32
어떤 페르소나가 더 나은지 비교 로그가 나타나며
13:35
테스트 창만 있으면 충분히 가능합니다
13:37
그렇게 하면 추측이 아닌 증거를 바탕으로
13:39
어조를 결정할 수 있습니다
13:40
이제 근거 확인, 그라운딩 체크스, 을 추가하세요
13:42
테스터가 호텔 비용은 얼마까지 청구할 수 있나요?
13:44
라고 물었다 고가정 해봅시다
13:45
그런데 보시, 인사팀에 확인하세요
13:46
라고 모호하게 응답합니다
13:47
이건 완전히 실패한 게 아니라 하나의 피드백입니다
13:49
아마도 익스펜시스, 폴리시, 닥스 파일이
13:51
아직 세긴되지 않았을 수 있습니다
13:52
혹은 트리거 문구에 호텔이 포함되지 않았을 수도 있죠
13:55
지식탭을 다시 확인하여 파일이 활성화되어 있는지 확인하고
13:57
여행 주제의 트리거 문구로
13:59
호텔 비용을 추가하여 해결하세요
14:00
이제 다시 실행해보세요
14:02
정책에 따르면 숙박비는 1박당 200달러로 제한됩니다
14:04
라는 답변이 나오면 문제를 성공적으로 해결한 것입니다
14:07
미묘하지만 중요한 요령 하나는
14:08
대화시장 문구를 사용하는 것입니다
14:10
빈 텍스트 상자를 보면
14:11
사용자는 망설이익이 마련이지만
14:14
개요페이지에서 몇 가지 추천 질문을
14:16
미리 채워넣을 수 있습니다
14:17
호텔 비용 한도는 얼마인가요?
14:19
출장비 청구는 어떻게 하나요?
14:21
어떤 식비가 환급되나요?
14:22
와 같은 질문 3개에서 5개를 추가하세요
14:24
사용자가 바로 클릭하게 되면
14:25
실제 경로를 더 빨리 테스트할 수 있고
14:27
사용자는 보시 입력을 시작하기도 전에
14:28
자신의 역할을 알고 있다고 느끼게 됩니다
14:30
이런 흐름은 경로를 거칠수록
14:31
봇을 더욱 견고하게 만들어줍니다
14:33
운에 맡긴 채 실패한 출력을 무시하고
14:35
다음번엔 마법처럼 성공하길 바라는 건 금물입니다
14:37
그렇게 되면 사람들은 지원 티켓을 제출하게 되고
14:39
결국 신뢰를 잃게 됩니다
14:40
자연수 20이 나오면
14:41
보시 출처와 적절한 페르소나를 통해
14:43
복잡한 입력까지 이해한다는 것을 입증할 때까지
14:45
그 루틴을 반복하세요
14:46
반복할 때 마다봇은 불안정한 도박 같은 존재에서
14:49
믿음직한 팀원으로 한 걸음씩 다가갑니다
14:51
표실은 이렇습니다
14:52
테스트 창 안에서 다듬는 것은 안전모드일 뿐입니다
14:55
루프가 제대로 작동한다면
14:56
다음 단계는 그 수정사항들이 내 컴퓨터 밖에서
14:58
어떻게 작동하는지 확인하는 것입니다
14:59
그때부터 채널별 차이가 드러나기 시작하는데
15:01
초보 개발자들이 가장 간과하는 부분이 바로 여기입니다
15:04
번전이 공개될 때
15:05
즉 게시와 채널에서의 놀라운 일들이 기다리고 있습니다
15:07
마침내 게시 버튼을 누르는 순간
15:09
에이전트는 작업실을 떠나
15:11
실제 사용자들 앞에서 살아남아야 합니다
15:12
코파일러 스튜디오에서의 단계를
15:14
번전이 공개될 때라고 부르는 이유는
15:16
게시하는 순간 공들여 연습시킨 봇이
15:18
각자의 규칙을 가진 채널로 던져지기 때문입니다
15:20
첫 번째 놀라운 점은
15:21
게시가 단순히 클릭 한 번으로 끝나는 작업이 아니라는 것입니다
15:24
이는 누가 에이전트에 접근할 수 있는지
15:26
어떻게 접속하는지
15:27
그리고 응답이 실제 환경에서 어떻게 나타나는지를
15:29
결정하는 과정입니다
15:30
팀즈, 시어포인트, 데모 웹사이트까지
15:32
각 채널에는 저마다의 특성이 있습니다
15:33
스튜디오에서 깔끔했던 답변도
15:35
배포 후에는 다르게 보이거나 아예 실패할 수 있습니다
15:37
팀즈를 예로 들어보죠
15:38
스튜디오에서는 답변이 아주 깔끔하게 나옵니다
15:41
숙박비는 하루 200달러입니다
15:42
라는 정책이 있다고 해봅시다
15:44
팀즈에서 같은 문구를 테스트하면
15:46
보순 그대로인데
15:46
갑자기 이해하지 못하겠다는 반응이 돌아옵니다
15:49
팀즈가 텍스트를 감싸고
15:50
메타 데이터를 전달하는 방식 때문에
15:51
정렬이 깨진 것입니다
15:52
셰어포인트는 줄간격 처리 방식이 독자적입니다
15:55
데모 웹사이트가 가장 단순하지만
15:57
스튜디오와는 다르게 서식을 렌더링할 수 있습니다
15:59
각 계시 대상은 서로 다른 경기장이므로
16:01
각각 따로 테스트해야 합니다
16:03
작업을 완료하기 전에 거쳐야 할 올바른 순서는 무엇일까요?
16:05
초보적인 실수를 피할 수 있는 게시 체크리스트를 소개합니다
16:08
첫째, 지식 파일이 완전히 인덱싱 되었는지 확인하세요
16:11
방금 업로드했다면
16:12
실시간 답변을 하기 위한 준비가 아직 안 되었을 수 있습니다
16:14
둘째, 인증을 설정하세요
16:16
광범위한 데모를 진행한다면
16:18
인증 없음을 선택하여
16:19
링크가 있는 누구나 사용해 볼 수 있게 하세요
16:21
셋째, 게시를 누르고
16:22
채널 페이지에서 녹색 확인 배너나 상태 업데이트가 뜨는지 확인하세요
16:26
넷째, 데모 웹사이트 채널 설정을 여세요
16:29
환영 메시지와 대화 시작 문구를 업데이트하여
16:31
테스터들이 빈 채팅 창 앞에서 당황하지 않게 하세요
16:33
마지막으로, 클로즈드 파일럿을 실행하세요
16:35
전체 테넌트에 바로 공개하지 마세요
16:37
명확한 지침을 가진 소규모 그룹이
16:39
전체 공개보다 훨씬 현명한 선택입니다
16:40
해당 파일럿 그룹은
16:41
자신들이 테스트 팀이라는 사실을 인지하고 있어야 합니다
16:43
일상적인 언어를 사용하고
16:44
오타를 섞고
16:45
적절한 경우 파일을 업로드하도록 요청하세요
16:47
그들의 실수가 취약점을 드러내는 단서가 됩니다
16:49
비공개 파일럿은
16:50
단순히 출시 과정을 완화하기만 하는 것이 아닙니다
16:52
전사적으로 배포하기 전에
16:53
빌드를 보완하는 데 필요한 기초 보고서를 생성합니다
16:56
채널별 동작 특성 때문에의 단계는 필수적입니다
16:59
스튜디오에서 테스트했던 공식 지리
17:00
일상적인 표현, 오타, 출처 기반 인용 등
17:03
모든 시나리오를 각 대상 채널에서 그대로 다시 실행하세요
17:05
팀즈에서 다르게 렌더링 되는지 확인하세요
17:07
셰어포인트에서 간격이 깨지는지 확인하세요
17:09
웹 데모에서 여전히 출처 인용이 표시되는지 확인하세요
17:11
이것이 일관성을 입증하는 유일한 방법입니다
17:14
스튜디오에서의 완벽한 테스트 한 번이
17:15
성공적인 출시를 보장하지는 않습니다
17:17
개시는 사용자 피드백에만 의존하던 것에서 벗어나
17:19
원격 분석 데이터를 확인하기 시작한다는 의미이기도 합니다
17:21
보�이 팀즈 나 데모 웹사이트에 배포되면
17:23
사용량 데이터가 수집되기 시작합니다
17:25
파워 플랫폼 관리 센터와 내장된 분석 도구가
17:27
여러분을 도울 것입니다
17:28
구입 수치, 오류 횟수, 심지어 어떤 대화가
17:31
토픽을 트리거하지 못했는지도 확인할 수 있습니다
17:33
이는 단순한 부가 작업이 아니라
17:34
여러분의 모니터링 시스템입니다
17:36
게시하고 잊어버리는 것이 아니라
17:37
로그를 주시하며 보시이 올바르게 사용되고 있는지
17:39
새로운 기술 지원 요청을 유발하지 않는지 확인해야 합니다
17:41
이 단계를 서두르면 신뢰를 잃게 됩니다
17:43
최악의 경우 게시 버튼을 무작정 누르고
17:45
전 부서에 배포했다가
17:46
팀즈에서 핵심 응답이 누락되어
17:47
지원 요청이 쇄도하는 사태를 맞을 수 있습니다
17:49
사용자들은 포기하게 되고
17:50
그 자체를 수정하는 것보다
17:51
그들의 마음을 돌리는데
17:52
더 많은 시간이 걸립니다
17:53
최선의 경우
17:54
게시 단계를 또 하나의 테스트 단계로 취급합니다
17:56
색인 완료, 인증 설정, 게시 확인,
17:59
데모 사이트 조정, 파일럿 실행을 거칩니다
18:01
복잡한 피드백을 수집하고 응답을 보완하며
18:03
각 채널에서 모든 핵심 질의를 다시 실행합니다
18:05
본격적으로 확장 배포할 때
18:07
쯤이면 이미 스트레스 테스트를 통과한 상태가 됩니다
18:09
진정한 요령은 게시를 끝으로 생각하는 방식에서 벗어나는 것입니다
18:12
그 버튼은 책의 마지막 문장이 아니라
18:13
현장 캠페인의 시작을 의미합니다
18:15
파일럿 데이터가 수집되고
18:16
로그를 통해 사용자가 모든 곳에서
18:18
정확한 답변을 얻고 있음이 확인되면
18:19
그때 비로소 안정적이라고 부를 자격이 생깁니다
18:21
이러한 인식은 코파일럿 스튜디오 로빌드하는
18:23
전체적인 그림과 연결됩니다
18:25
이는 일회성 구축이 아니라
18:26
계속해서 조정해나가는 시스템이기 때문입니다
18:28
이제 실제로 중요한 내용을 요약해드립니다
18:30
빌드를 불안정함에서
18:32
신뢰성으로 바꾸는 세 가지 요소가 있습니다
18:33
첫째, 에이전트의 기반을 다지고
18:35
실제 문서를 업로드하거나
18:36
신뢰할 수 있는 소스를 연결하여
18:37
추측성 답변을 멈추게 하세요
18:38
둘째, 페르소나를 부여하고
18:40
이름, 설명, 어조를 설정하며
18:41
8천자 지침필드의 동작 방식을 명확히 기재하세요
18:44
셋째, 리허설 결과만 믿지 말고
18:46
테스트 창을 활용해
18:47
비공개 시범 운영을 거친 뒤
18:48
게시하고 모니터링하세요
18:49
운이 좋다면
18:50
이러한 단계를 통해
18:51
문의 티켓이 아닌
18:52
신뢰를 쌓는 곳을 만들 수 있을 겁니다
18:53
구독하고 댓글로
18:54
여러분의 에이전트 기반이 될
18:56
정책 문서 한 가지를
18:57
한 문장으로 남겨주세요