WEBVTT 00:00:00.000 --> 00:00:02.220 첫 번째 코파일럿 스튜디오 에이전트를 출시했는데 00:00:02.220 --> 00:00:04.360 사람들에게 깊은 인상을 남기기는 커녕 00:00:04.360 --> 00:00:07.340 정책에 따르면 아마도 그게 복구축의 자연스러운 부분인 것 같아요 00:00:07.340 --> 00:00:09.720 와 같이 엉뚱한 답변을 내뱉는 상황을 상상해보세요 00:00:09.720 --> 00:00:13.380 하지만 몇 가지 수정사안과 실제 정책 문서를 기반으로 한 명확한 지침을 더하면 00:00:13.380 --> 00:00:16.800 그런 실수를 정확한 조항을 인용하는 완벽한 답변으로 바꿀 수 있습니다 00:00:16.800 --> 00:00:19.620 이 영상이 끝날 때 쯤이면 테스트창에서 잘못된 응답을 재현하고 00:00:19.620 --> 00:00:21.480 보시 실제 문서를 인용하도록 수정하며 00:00:21.480 --> 00:00:23.920 제대로 작동하는 파일럿을 게시하는 방법을 알게 될 것입니다 00:00:23.920 --> 00:00:28.040 잠깐, 지금 구독 버튼을 눌러 이 가이드들을 재생 목록에 자동으로 추가하세요 00:00:28.040 --> 00:00:30.980 물론 테스트창에서 매끄러운 결과를 얻기는 쉽습니다 00:00:30.980 --> 00:00:34.940 진짜 고통은 봇이 연습실을 떠나 실제 환경에서 허우적될 때 시작됩니다 00:00:34.940 --> 00:00:37.780 완벽했던 테스트 봇이 실제 환경에서 무너지는 이유 00:00:37.780 --> 00:00:40.160 그렇다면 테스트창에서는 흠 잡을 데 없어 보이던 봇이 00:00:40.160 --> 00:00:42.440 왜 실제 사용자들을 상대할 때는 갑자기 헤매는 걸까요? 00:00:42.600 --> 00:00:45.720 간단히 말해, 스튜디오는 환경을 정돈하고 예의 바르게 유지하지만 00:00:45.720 --> 00:00:47.700 현실 세계에는 그런 배려가 없기 때문입니다 00:00:47.700 --> 00:00:50.400 스튜디오에서는 입력값이 깔끔하게 들어옵니다 00:00:50.400 --> 00:00:54.120 질문은 짧고 명확하며 보통 준비한 학습 예제와 일치하죠 00:00:54.120 --> 00:00:56.500 그래서 완벽한 연속 성공처럼 느껴지는 것입니다 00:00:56.500 --> 00:00:59.400 하지만 실제 운영 환경으로 넘어가면 사람들은 평소처럼 타이핑합니다 00:00:59.400 --> 00:01:02.840 선임 직원은 호텔에 머물 때 얼마까지 청구할 수 있나요? 라고 물을 것입니다 00:01:02.840 --> 00:01:05.820 담당자는 호텔 경비 한도를 오타 섞어 입력할 수도 있습니다 00:01:05.820 --> 00:01:09.240 다른 누군가는 그냥 출장비 좀 다시 알려줘 라고 말할지도 모르죠 00:01:09.240 --> 00:01:12.880 모두 같은 의미지만 만약 경비 한도가 얼마인가만 테스트했다면 00:01:12.880 --> 00:01:15.140 봇은 항상 연결고리를 찾지는 못할 것입니다 00:01:15.140 --> 00:01:17.440 지금 바로 이 격차를 확인하는 방법이 있습니다 00:01:17.440 --> 00:01:20.180 테스트창을 열고 봇에게 3가지 변형 질문을 던져보세요 00:01:20.180 --> 00:01:23.780 먼저 깔끔한 버전, 그 다음 평소 사용하는 말투, 마지막으로 오타가 있는 버전을 입력합니다 00:01:23.780 --> 00:01:25.420 응답이 어떻게 바뀌는지 지켜보세요 00:01:25.420 --> 00:01:28.540 때로는 3가지를 모두 맞히지만 때로는 깔끔한 질문에만 제대로 응답할 수도 있습니다 00:01:28.540 --> 00:01:32.180 그것이 바로 아름다운 테스트 결과가 현실 세계에서의 생존을 보장하지 않는다는 첫 번째 신호입니다 00:01:32.180 --> 00:01:34.240 기술적인 이유는 위도 커버리지에 있습니다 00:01:34.240 --> 00:01:37.900 보순 응답을 보낼 시점을 알기 위해 트리거 구문과 토픽 정의에 의존합니다 00:01:37.900 --> 00:01:40.600 모든 예제가 비슷해 보이면 모델은 유연성을 잃게 됩니다 00:01:40.600 --> 00:01:42.900 단 하나의 유의어만으로도 보순 혼란에 빠질 수 있습니다 00:01:42.900 --> 00:01:44.640 해결책은 지루하지만 효과적입니다 00:01:44.640 --> 00:01:48.420 토픽에 덕복 넓은 트리거 구문을 추가하고 정책 문서에 공식적인 문구만 사용하지 마세요 00:01:48.420 --> 00:01:50.380 사람들이 실제로 사용하는 일상적이고 축약된 00:01:50.380 --> 00:01:52.460 심지어는 약간 거친 표현들도 섞어 넣으세요 00:01:52.460 --> 00:01:53.980 수십 개씩 필요하지는 않습니다 00:01:53.980 --> 00:01:56.400 명백한 변형을 커버할 만큼만 추가하고 다시 테스트하세요 00:01:56.400 --> 00:01:58.360 채널 간의 차이가 상황을 더 어렵게 만듭니다 00:01:58.360 --> 00:02:00.820 스튜디오의 테스트 창은 단지 시뮬레이션일 뿐이기 때문입니다 00:02:00.820 --> 00:02:03.500 팀즈, 시어포인트 또는 데모 웹사이트와 같은 채널에 게시하면 00:02:03.500 --> 00:02:06.600 플랫폼에 따라 입력 텍스트 처리 방식이나 응답 렌더링 방식이 달라질 수 있습니다 00:02:06.600 --> 00:02:08.700 팀즈는 줄 바꿈을 다르게 처리할 수 있습니다 00:02:08.700 --> 00:02:10.680 웹페이지는 서식을 제거할 수 있습니다 00:02:10.680 --> 00:02:14.900 핵심 구문을 다른 줄로 옮기는 것 같은 작은 변화도 모델이 가중치를 두는 방식을 바꿀 수 있습니다 00:02:14.900 --> 00:02:19.160 이것이 바로 마이크로소프트가 채널 전반에 걸친 반복적인 테스트의 필요성을 강조하는 이유입니다 00:02:19.160 --> 00:02:22.920 스튜디오에서 통과 한 보디라도 실제 환경의 서식 문제로 인해 실패할 수 있습니다 00:02:22.920 --> 00:02:25.240 사용자에게는 나름의 기대치가 있기 때문입니다 00:02:25.240 --> 00:02:27.900 그들에게 질문을 바꿔 말하는 것은 평범한 대화일 뿐입니다 00:02:27.900 --> 00:02:31.000 사용자는 인텐트, 트리거 또는 의미적 중복에 대해 생각하지 않습니다 00:02:31.000 --> 00:02:33.500 그저 동료가 이해하듯 보또 이해할 것이라고 가정합니다 00:02:33.500 --> 00:02:36.380 특히 데모 중에 한 번이 실수가 발생하면 신뢰도는 무너집니다 00:02:36.380 --> 00:02:38.640 초보 개발자들이 바로 여기서 큰 타격을 입습니다 00:02:38.640 --> 00:02:40.840 스튜디오에서의 연습은 잘못된 안정감을 주지만 00:02:40.840 --> 00:02:43.360 팀즈에서 사용자의 첫 질문이 환상을 깨뜨립니다 00:02:43.360 --> 00:02:45.320 한 가지 예시로 더 자세히 살펴보겠습니다 00:02:45.320 --> 00:02:48.500 스튜디오에서 비용 한도가 얼마인가요? 라고 입력합니다 00:02:48.500 --> 00:02:51.620 보순 숙박비는 하루 200달러입니다 라고 바로 답변합니다 00:02:51.620 --> 00:02:53.560 완벽합니다 이제 배포해봅니다 00:02:53.560 --> 00:02:56.840 이번에는 호텔 비용으로 얼마까지 받을 수 있나요? 라고 물어봅니다 00:02:56.840 --> 00:03:01.300 보순 정책을 인용하는 대신 인사팀에 문외하라는 식의 모호한 답변을 내놓습니다 00:03:01.300 --> 00:03:03.600 위도는 같지만 결과는 완전히 다릅니다 00:03:03.600 --> 00:03:08.260 연습 때는 정확하다가 운영 환경에서 모호해지느니 격차가 바로 우리가 말하고자 하는 핵심입니다 00:03:08.260 --> 00:03:09.940 실질적인 교훈은 다음과 같습니다 00:03:09.940 --> 00:03:12.380 스튜디오를 연습용 스파링 파트너로 여기십시오 00:03:12.380 --> 00:03:14.900 학습에는 유용하지만 준비가 완료되었다는 증거는 아닙니다 00:03:14.900 --> 00:03:17.700 다음 단계로 넘어가기 전에 테스트창에서 세 가지 변형 테스트를 수행하고 00:03:17.700 --> 00:03:20.220 유의어나 일상적인 표현을 포함하여 주제 범위를 넓히십시오 00:03:20.220 --> 00:03:23.500 마지막으로 게시 후에는 봇이 작동할 모든 채널에서 다시 테스트하십시오 00:03:23.500 --> 00:03:26.020 사용자가 문제를 발견하기 전에 여러분이 먼저 찾아낼 수 있습니다 00:03:26.020 --> 00:03:27.680 더 큰 함정이 기다리고 있습니다 00:03:27.680 --> 00:03:30.860 표현과 채널을 다 커버했더라도 올바른 출처에 근거하지 않으면 00:03:30.860 --> 00:03:32.300 봇은 여전히 실패할 수 있습니다 00:03:32.300 --> 00:03:35.360 그때부터 봇은 질문을 놓치는 대신 없는 사실을 지어내기 시작합니다 00:03:35.360 --> 00:03:38.500 자신감 있게 말하지만 실제로는 추측에 불과한 봇을 상상해보세요 00:03:38.500 --> 00:03:40.540 바로 여기서 상황이 복잡해집니다 00:03:40.540 --> 00:03:41.640 초보자의 실수 00:03:41.640 --> 00:03:43.980 즉 봇을 근거 없이 방치하는 것입니다 00:03:43.980 --> 00:03:47.180 첫 번째 초보자의 실수는 코파일럿 스튜디오를 규칙서가 아닌 00:03:47.180 --> 00:03:48.800 수정 구슬처럼 대하는 것입니다 00:03:48.800 --> 00:03:51.720 실제 지식에 근거하지 않고 에이전트를 시작하는 것은 00:03:51.720 --> 00:03:54.420 준비 없이 신입 인턴을 이사회에 내보내는 것과 같습니다 00:03:54.420 --> 00:03:56.420 그들은 빠르게 말하고 자신감 있게 들리겠지만 00:03:56.420 --> 00:03:58.920 누군가 확인하는 즉시 그 말의 절반은 무너질 것입니다 00:03:58.920 --> 00:04:01.180 그것이 바로 봇을 근거 없이 방치하는 함정입니다 00:04:01.180 --> 00:04:03.340 처음에는 그 화려함이 그 허점을 숨겨줍니다 00:04:03.340 --> 00:04:06.020 스튜디오에서 새로 만든 빌드는 세련되고 공손한 인사와 빠른 응답 00:04:06.020 --> 00:04:07.520 지연 없는 매끄러운 모습을 보여줍니다 00:04:08.500 --> 00:04:10.340 그 말 들을 뒷받침할 실체는 없습니다 00:04:10.340 --> 00:04:12.880 시스템은 사실이 아닌 패턴을 끌어다 쓸 뿐입니다 00:04:12.880 --> 00:04:15.100 근거가 없는 봇은 아무것도 알지 못합니다 00:04:15.100 --> 00:04:16.380 허풍을 떠는 것이죠 00:04:16.380 --> 00:04:18.440 테스트 창에서는 그럴듯해 보일지 몰라도 00:04:18.440 --> 00:04:20.880 실제 사용자들은 금방 눈치 챌 것입니다 00:04:20.880 --> 00:04:24.200 가장 최악의 결과는 단순히 부실한 답변이 아니라 환각현상입니다 00:04:24.200 --> 00:04:25.920 환각이란 봇이 사실처럼 보이지만 00:04:25.920 --> 00:04:28.340 실제로는 근거 없는 내용을 지어내는 것을 말합니다 00:04:28.340 --> 00:04:29.920 출장비 환급에 대해 물어보면 00:04:29.920 --> 00:04:31.740 봇은 정중히 거절하는 대신 00:04:31.740 --> 00:04:33.820 그럴듯하게 들리는 숫자를 만들어냅니다 00:04:33.820 --> 00:04:36.380 직원 한 명이 그 잘못된 답변을 믿고 호텔을 예약하면 00:04:36.380 --> 00:04:39.420 즉시 비용 분쟁과 항의 메일을 수습해야 하는 상황이 발생합니다 00:04:39.420 --> 00:04:42.260 문장은 전문적으로 보였지만 내용은 허상이었습니다 00:04:42.260 --> 00:04:44.620 컨투소 랩스위 사례가 이를 잘 보여줍니다 00:04:44.620 --> 00:04:47.120 공식 실습 과정에서는 익스펜시스 플리시 00:04:47.120 --> 00:04:49.300 도크엑스라는 파일을 업로드해야 합니다 00:04:49.300 --> 00:04:52.680 파일 안에는 숙박비 한도가 1박당 200달러라고 명시되어 있습니다 00:04:52.680 --> 00:04:55.000 이제 근거 설정을 건너 뛰고 새로 만든 보색에 00:04:55.000 --> 00:04:56.620 호텔 규정이 뭐야? 라고 물어보면 00:04:56.620 --> 00:04:59.140 1박당 100달러라고 자신있게 답변할지도 모릅니다 00:04:59.140 --> 00:05:00.440 완전히 지어낸 말이죠 00:05:00.440 --> 00:05:01.420 익스펜시스 플리시 00:05:01.420 --> 00:05:03.020 도크엑스 파일을 직접 청구해야만 00:05:03.020 --> 00:05:04.720 모델이 제멋대로 답변하는 것을 멈춥니다 00:05:04.720 --> 00:05:06.780 근거를 가진 보습문서를 인용합니다 00:05:06.780 --> 00:05:08.120 회사 출장 규정에 따르면 00:05:08.120 --> 00:05:10.580 숙박비는 1박당 200달러로 제한됩니다 00:05:10.580 --> 00:05:11.780 날조와 인용의 차이 00:05:11.780 --> 00:05:14.160 그것이 바로 근거 설정 단계의 핵심입니다 00:05:14.160 --> 00:05:16.740 그럼 이제 인터페이스에서 어떻게 해결하는지 알려드리겠습니다 00:05:16.740 --> 00:05:18.760 코파일럿 스튜디오에서 에이전트로 이동하세요 00:05:18.760 --> 00:05:20.920 개요 화면에서 지식 날리지 을 클릭합니다 00:05:20.920 --> 00:05:23.500 지식 추가 플러스를 선택한 다음 파일 업로드를 선택하세요 00:05:23.500 --> 00:05:24.480 익스펜시스 폴리시 00:05:24.480 --> 00:05:26.780 도크엑스 또는 다른 신뢰할 수 있는 소스를 지정합니다 00:05:26.780 --> 00:05:30.180 공개 웹사이트 나쉐어 포인트 위치에 연결하고 싶다면 그렇게 해도 되지만 00:05:30.180 --> 00:05:31.660 파일이 훨씬 깔끔합니다 00:05:31.660 --> 00:05:33.240 업로드한 후에는 기다리세요 00:05:33.240 --> 00:05:36.060 내용이 준비되기까지 인덱싱의 10분이 상소요될 수 있습니다 00:05:36.060 --> 00:05:39.120 초기 테스트 질문에서 즉시 결과가 나오지 않는다고 당황하지 마세요 00:05:39.120 --> 00:05:41.400 인덱싱이 완료되면 질문을 다시 실행해보세요 00:05:41.400 --> 00:05:42.680 제대로 근거가 설정되면 00:05:42.680 --> 00:05:45.100 업로드 한 문서에서 가져왔다는 작은 인용 표시와 함께 00:05:45.100 --> 00:05:47.280 200달러라는 정확한 답변을 보게 될 것입니다 00:05:47.280 --> 00:05:50.180 그 인용 표시가 바로 제대로 설정되었다는 증거입니다 00:05:50.180 --> 00:05:51.780 흔한 오해 중 하나는 대화형 부스팅 00:05:51.780 --> 00:05:53.080 컨버세이셔널 부스팅 00:05:53.080 --> 00:05:55.280 이 부족한 부분을 마법처럼 채워줄 것이라고 믿는 것입니다 00:05:55.280 --> 00:05:57.500 부스팅은 정책에 대한 이해를 새로 만들어내는 것이 아니라 00:05:57.500 --> 00:05:59.000 텍스트 패턴을 강화할 뿐입니다 00:05:59.000 --> 00:06:00.380 근거가 되는 지식 소스가 없으면 00:06:00.380 --> 00:06:02.800 부스팅은 기분 좋게 일반적인 헛소리만 늘어놓습니다 00:06:02.800 --> 00:06:04.740 마치 인턴에게 커피 3잔을 마시게 하고 00:06:04.740 --> 00:06:07.000 카페인이 무지를 보상해주길 기대하는 것과 같습니다 00:06:07.000 --> 00:06:09.580 실습 문서에서도 이에 대해 경고하고 있습니다 00:06:09.580 --> 00:06:11.640 지식 베이스에서 일치하는 내용을 찾지 못하면 00:06:11.640 --> 00:06:14.400 부스팅 기능이 모델에 내장된 일반 지식으로 대체되어 00:06:14.400 --> 00:06:16.560 모호하거나 부정확한 답변을 내놓을 수 있습니다 00:06:16.560 --> 00:06:19.020 그렇기 때문에 정확성이 중요한 중요한 주제의 경우 00:06:19.020 --> 00:06:21.400 추가한 소스에서만 검색하도록 구성해야 합니다 00:06:21.400 --> 00:06:23.660 규정 준수, 재무, 인사 관련 문제라면 00:06:23.660 --> 00:06:26.160 보시 더 넓은 언어모델에서 마음대로 답변하지 않도록 하세요 00:06:26.160 --> 00:06:28.960 이 단계를 무시해서 발생하는 문제는 빠르게 누적됩니다 00:06:28.960 --> 00:06:30.940 근거가 없는 보순 잡담에는 괜찮을지 몰라도 00:06:30.940 --> 00:06:33.180 비용 청구나 휴가 정책에 대해 답변하게 되면 00:06:33.180 --> 00:06:35.120 실제 헬프 데스크 티켓을 유발하게 됩니다 00:06:35.120 --> 00:06:37.180 보시의 즉흥적으로 제한 규정을 지어내는 바람에 00:06:37.180 --> 00:06:39.280 직원 5명이 모두 잘못된 요율로 비용을 청구했다면 00:06:39.280 --> 00:06:41.420 재무팀의 일을 어떻게 설명할지 생각해보세요 00:06:41.420 --> 00:06:44.780 나중에 수정하는 비용이 처음부터 문서를 업로드하는 것보다 훨씬 더 큽니다 00:06:44.780 --> 00:06:47.520 그라운딩, 그라운딩 은 열이만 있고 무제한 인턴 같던 에이전트를 00:06:47.520 --> 00:06:49.660 게이머들이 말하는 규정 준수 전문가로 바꿔줍니다 00:06:49.660 --> 00:06:52.360 보시의 자기 생각이 아닌 규정집을 그대로 인용하게 되는 것입니다 00:06:52.360 --> 00:06:55.380 경비정책 문서를 첨부하면 시스템은 즉흥적으로 행동하는 대신 00:06:55.380 --> 00:06:56.660 사내 규정을 강제하게 됩니다 00:06:56.660 --> 00:07:00.100 더 좋은 점은 답변과 함께 확인할 수 있는 명확한 출처를 제공한다는 것입니다 00:07:00.100 --> 00:07:01.700 그렇게 신뢰를 지키는 것입니다 00:07:01.700 --> 00:07:03.860 운이 나쁘면 내추럴 1, 포위 규정을 퍼뜨리는 00:07:03.860 --> 00:07:05.900 자신감 넘치는 가심머신을 만들게 될 수도 있습니다 00:07:05.900 --> 00:07:09.840 운이 좋으면 내추럴 20 출처를 갖춘 완벽한 전문가를 구축하게 됩니다 00:07:09.840 --> 00:07:14.040 후자를 얻는 유일한 방법은 처음부터 검증된 지식 소스를 입력하는 것입니다 00:07:14.040 --> 00:07:17.280 보시 진실을 말할 수 있게 된 후에는 다음 과제에 직면하게 됩니다 00:07:17.280 --> 00:07:19.520 진실을 전달하는 방식을 다듬는 일이죠 00:07:19.520 --> 00:07:22.700 정확하더라도 개성이 없으면 사용자는 떠나버리기 때문입니다 00:07:22.700 --> 00:07:25.100 보색의 개성을 부여하는 단계가 다음입니다 00:07:25.100 --> 00:07:28.160 코파일러 스튜디오에서는 개성이 저절로 생기지 않습니다 00:07:28.160 --> 00:07:29.520 직접 작성해야 합니다 00:07:29.520 --> 00:07:32.180 이 단계에서 시스템이 시험용 로봇처럼 들리지 않게 하고 00:07:32.180 --> 00:07:35.020 사용자가 실제로 대화하고 싶어하는 존재로 만들어야 합니다 00:07:35.020 --> 00:07:39.680 실제로는 개요 페이지에 있는 이름, 설명, 지침 필드를 편집하는 것을 의미합니다 00:07:39.680 --> 00:07:44.440 이 필드를 비워두면 튜토리얼 모드에 갇힌 NPC 같은 딱딱한 답변만 나오게 됩니다 00:07:44.440 --> 00:07:47.180 많은 초보 빌더 들이 놓치는 부분이 바로 여기입니다 00:07:47.180 --> 00:07:50.720 생성 버튼을 누르는 순간 시스템에는 이미 기본 스타일이 적용되어 있습니다 00:07:50.720 --> 00:07:54.820 필드를 수정하지 않으면 권한도 맥락도 없는 무미건조 한 안내자만 남게 됩니다 00:07:54.820 --> 00:07:56.740 맥락이 있어야 신뢰가 싸딥니다 00:07:56.740 --> 00:08:00.600 인사나 재무 같은 환경에서는 평범한 어조가 사람들에게 이것이 믿을 수 있는 도구가 아니라 00:08:00.600 --> 00:08:03.240 단순한 프로토타입을 테스트하는 것이라고 느끼게 만듭니다 00:08:03.240 --> 00:08:06.040 간단한 예로 비용 정책 전문가를 만들려고 했지만 00:08:06.040 --> 00:08:11.420 이름이나 설명을 바꾸지 않아서 에이전트가 배경 설명도 없는 일반 코파일럿으로 표시되는 경우를 생각해보세요 00:08:11.420 --> 00:08:15.240 누군가 호텔 비용 청구에 대해 전문적인 조언을 기대하며 질문을 던지게 됩니다 00:08:15.240 --> 00:08:18.060 사용자가 받는 것은 아무런 틀도 없는 평범한 텍스트일 뿐이며 00:08:18.060 --> 00:08:21.460 이는 나를 신뢰하지 마세요 라는 미묘하지만 강력한 신호를 보냅니다 00:08:21.460 --> 00:08:22.980 신뢰는 빠르게 무너집니다 00:08:22.980 --> 00:08:25.620 첫 만남에서 사용자를 잃으면 다시 돌아오는 일은 거의 없습니다 00:08:25.620 --> 00:08:28.880 이 전체 설정을 간단한 캐릭터 시트를 작성하는 것처럼 생각해보세요 00:08:28.880 --> 00:08:34.480 이름은 직업, 설명은 배경 이야기, 긴 지시사항 입력란은 능력치, 그리고 어조는 성향입니다 00:08:34.480 --> 00:08:37.520 스킬 포인트를 할당하지 않고 게임 캠페인에 참여하지는 않을 것입니다 00:08:37.520 --> 00:08:39.480 봇을 배포할 때도 그렇게 해서는 안 됩니다 00:08:39.480 --> 00:08:41.320 이제 실제 수치가 중요합니다 00:08:41.320 --> 00:08:44.680 봇 이름 필드는 30자까지 가능함으로 짧고 명확하게 작성하세요 00:08:44.680 --> 00:08:48.380 경비정책 전문가, 여행 가이드, 혜택 도우미 등이 예입니다 00:08:48.380 --> 00:08:52.820 설명란은 약 천자까지 가능하며 명확한 문장 몇 개를 쓰기에 충분합니다 00:08:52.820 --> 00:08:57.500 이 에이전트는 직원들에게 공식 여행 정책에 따른 최신 답변을 제공합니다 00:08:57.500 --> 00:09:00.520 관련 구절을 인용하며 추측성 답변은 피합니다 00:09:00.520 --> 00:09:03.320 그 다음은 최대 8천자까지 작성 가능한 지시사항 필드가 있는데 00:09:03.320 --> 00:09:05.380 이것이 바로 유연하게 활용할 공간입니다 00:09:05.380 --> 00:09:07.600 이곳의 실제 작동 규칙을 고정할 수 있습니다 00:09:07.600 --> 00:09:10.460 단순히 친절하게 대화라고만 하지 말고 구체적인 지침을 제시하세요 00:09:10.460 --> 00:09:12.620 가능할 때는 항상 정책 내용을 인용하세요 00:09:12.620 --> 00:09:14.280 추측성 답변은 피하세요 00:09:14.280 --> 00:09:18.020 임원들을 위해 명확한 한 문장으로 요약한 뒤 근거를 제시하세요 00:09:18.020 --> 00:09:21.640 봇을 만들 때 실제로 확인해볼 수 있는 편리한 체크리스트는 다음과 같습니다 00:09:21.640 --> 00:09:32.080 역할 지정, 전문 분야에 대한 짧은 설명 작성, 어조 설정, 격식 있는, 캐주얼한, 비전문가를 위한 쉬운 어조, 행동규칙으로 지시사항 채우기, 포함할 것, 피할 것, 형식 지정 방법 00:09:32.080 --> 00:09:34.720 이 단계 하나하나가 정체성을 더 탄탄하게 만듭니다 00:09:34.720 --> 00:09:36.960 어느 것도 복잡한 설정이 필요하지 않습니다 00:09:36.960 --> 00:09:40.400 생성 과정에서 바로 할 수 있거나 나중에 개요 페이지에서 수정할 수 있습니다 00:09:40.400 --> 00:09:42.780 어조에 대한 지침은 미묘하지만 강력합니다 00:09:42.780 --> 00:09:49.320 격식 있고 전문적인 또는 기술적 배경이 없는 직원을 위한 캐주얼하고 이해하기 쉬운 과 같은 문구로 명시적으로 유도할 수 있습니다 00:09:49.320 --> 00:09:51.760 원한다면 지시사항에 바로 예시를 추가하세요 00:09:51.760 --> 00:09:55.460 보시 모든 문장을 구성하는 방식을 조절하는데 많은 텍스트가 필요한 것은 아닙니다 00:09:55.460 --> 00:09:58.040 잘 알려지지 않은 두 가지 빠른 개선 방법이 있습니다 00:09:58.040 --> 00:10:01.080 대화 시작 주제를 편집하고 에이전트 아이콘을 교체하세요 00:10:01.080 --> 00:10:03.020 둘 다 5분도 채 걸리지 않습니다 00:10:03.020 --> 00:10:06.700 테스트 창에서 처음 채팅을 열 때 보시 제공하는 소개 메시지를 볼 수 있습니다 00:10:06.700 --> 00:10:08.640 기본적으로는 일반적인 내용입니다 00:10:08.640 --> 00:10:11.080 해당 메시지를 클릭하여 대화 시작 주제를 편집하고 00:10:11.080 --> 00:10:15.620 상투적인 환영 인사를 여행 정책을 이해하도록 돕고 가능한 경우 공식 문서를 인용하겠습니다 00:10:15.620 --> 00:10:17.500 와 같이 역할에 맞는 소개로 바꾸세요 00:10:17.500 --> 00:10:19.800 그런 다음 대화를 새로 고침하여 테스트 해보세요 00:10:19.800 --> 00:10:21.720 즉시 훨씬 더 전문적으로 보입니다 00:10:21.720 --> 00:10:26.800 아이콘의 경우 시스템은 30킬로바이트 미만 최대 192x192 픽셀의 png 파일을 지원합니다 00:10:26.800 --> 00:10:28.800 브랜드 그래픽이나 간단한 로고를 넣기만 해도 00:10:28.800 --> 00:10:31.940 데모 같은 느낌 때문에 첫 응답부터 신뢰를 잃는 일을 막을 수 있습니다 00:10:31.940 --> 00:10:34.740 어떤 이들은 이런 수정사항을 선택적인 보완작업으로 치부합니다 00:10:34.740 --> 00:10:36.900 하지만 이를 기본적인 방어부라고 생각해보세요 00:10:36.900 --> 00:10:38.880 방어부가 없는 캐릭터도 공격은 할 수 있겠지만 00:10:38.880 --> 00:10:41.040 제대로 된 첫 타격에 바로 쓰러지고 맙니다 00:10:41.040 --> 00:10:45.060 특색 없는 이름과 모호한 인산말로 사용자를 맞는 봇도 이처럼 무방비 한 상태와 같습니다 00:10:45.060 --> 00:10:49.160 기본적인 사항만 채워 넣어도 혼란과 이탈을 막는 확실한 방어막을 구축하게 됩니다 00:10:49.160 --> 00:10:51.240 작은 변화가 빠르게 큰 효과를 냅니다 00:10:51.240 --> 00:10:53.060 역할을 명시하는 소개문구를 설정하면 00:10:53.060 --> 00:10:55.300 사용자가 적절한 질문을 하도록 유도할 수 있습니다 00:10:55.300 --> 00:10:58.060 톤 규칙을 활용하면 장황한 답변을 피할 수 있습니다 00:10:58.060 --> 00:11:00.540 지침을 구체화하여 ai가 불필요한 말을 줄이고 00:11:00.540 --> 00:11:02.600 사람이 읽기 쉬운 스타일로 답변하게 합니다 00:11:02.600 --> 00:11:04.200 이런 조정 하나하나가 이해하지 못했습니다 00:11:04.200 --> 00:11:05.040 라는 티켓을 줄이고 00:11:05.040 --> 00:11:07.280 커넥터 나플라그인 추가 없이도 더 매끄러운 흐름을 만듭니다 00:11:07.280 --> 00:11:08.580 그러니 원칙으로 삼으세요 00:11:08.580 --> 00:11:10.840 고급 로직을 다루기 전에 페르소나부터 설정하세요 00:11:10.840 --> 00:11:12.460 목적을 드러내는 이름을 선택하세요 00:11:12.460 --> 00:11:14.120 짧고 명확한 설명을 작성하세요 00:11:14.120 --> 00:11:15.180 어조를 설정하세요 00:11:15.180 --> 00:11:17.120 따라야 할 규칙들로 지침을 채우세요 00:11:17.120 --> 00:11:18.880 대화 시작 인삿말을 업데이트하세요 00:11:18.880 --> 00:11:20.460 간단한 아이콘으로 교체하세요 00:11:20.460 --> 00:11:22.800 이는 적은 노력으로 큰 성과를 거두는 방법입니다 00:11:22.800 --> 00:11:24.380 성공적으로 설정된 페르소나는 00:11:24.380 --> 00:11:27.220 신규 빌드조차 사용자가 함께하고 싶은 팀원으로 바꿔놓습니다 00:11:27.220 --> 00:11:28.620 반면 페르소나를 생략하면 00:11:28.620 --> 00:11:31.440 아무도 두 번 다시 찾지 않는 어색한 NPC만 남게 됩니다 00:11:31.440 --> 00:11:33.220 에이전트에게 정체성을 부여했다면 00:11:33.220 --> 00:11:35.340 이제 더 어려운 작업에 나설 준비가 된 것입니다 00:11:35.340 --> 00:11:36.740 진짜 테스트는 생성이 아니라 00:11:36.740 --> 00:11:38.920 실제 상황에서 봇이 잘 대응하는지 아니면 00:11:38.920 --> 00:11:40.920 실수하는지를 지켜보는 것이기 때문입니다 00:11:40.920 --> 00:11:42.640 첫 번째 실수에 포기하지 말고 00:11:42.640 --> 00:11:45.180 멈춰서서 로그를 확인해야 할 때입니다 00:11:45.180 --> 00:11:47.180 실시간으로 실수를 디버깅하세요 00:11:47.180 --> 00:11:49.080 실시간 디버깅은 실수를 티켓이 아닌 00:11:49.080 --> 00:11:50.660 교훈으로 바꿀 수 있는 과정입니다 00:11:50.660 --> 00:11:53.220 이것이 모든 빌더가 실행해야 할 실무적인 루프입니다 00:11:53.220 --> 00:11:55.360 실수를 확인하고 격리하고 수정하고 00:11:55.360 --> 00:11:56.440 다시 테스트를 실행하세요 00:11:56.440 --> 00:11:58.060 코파일러 스튜디오는 도구를 제공하지만 00:11:58.060 --> 00:11:59.780 순서대로 사용할 때만 효과가 있습니다 00:11:59.780 --> 00:12:02.460 시연하면서 소리 내어 따라 할 수 있는 루틴은 다음과 같습니다 00:12:02.460 --> 00:12:05.620 1단계 테스트 창에서 실패한 사용자 질문을 재현하세요 00:12:05.620 --> 00:12:06.920 대충 넘기지 마세요 00:12:06.920 --> 00:12:09.360 사용자가 질문할 것과 정확히 똑같이 물어보세요 00:12:09.360 --> 00:12:10.960 2단계 다시 실행하기 전에 00:12:10.960 --> 00:12:13.520 새로 고침 아이콘이나 새 채팅을 눌러 대화를 초기화하세요 00:12:13.520 --> 00:12:15.680 깨끗한 상태에서 시작하는 것이 중요합니다 00:12:15.680 --> 00:12:18.000 3단계 어떤 토픽이 작동했는지 확인하려면 00:12:18.000 --> 00:12:18.800 토픽 창을 여세요 00:12:18.800 --> 00:12:20.800 직접 만든 토픽이 아니라 시스템의 대화 강화 00:12:20.800 --> 00:12:22.060 부스팅, 토픽이었다면 00:12:22.060 --> 00:12:24.280 고시 지식이 아닌 모델에 의존했다는 신호입니다 00:12:24.280 --> 00:12:25.980 4단계 강화 토픽에서 발생했다면 00:12:25.980 --> 00:12:27.420 관련 파일이나 사이트가 업로드되고 00:12:27.420 --> 00:12:28.480 인덱싱 되었는지 확인하세요 00:12:28.480 --> 00:12:30.600 인덱스가 없으면 근거, 그라운딩, 도 없습니다 00:12:30.600 --> 00:12:33.000 인덱싱에는 몇 분 정도 걸릴 수 있다는 점을 기억하세요 00:12:33.000 --> 00:12:35.740 5단계 지침이나 주제 콘텐츠를 수정하고 저장한 다음 00:12:35.740 --> 00:12:37.280 똑같은 커리를 다시 실행하세요 00:12:37.280 --> 00:12:39.100 재현, 수점, 재실행 00:12:39.100 --> 00:12:40.860 반복이라는 이 루프가 여러분의 만들어입니다 00:12:40.860 --> 00:12:42.360 이를 건너뛰면 다음번에 눈 좋게 00:12:42.360 --> 00:12:44.100 더 나은 결과가 나오길 바랄 뿐인 셈입니다 00:12:44.100 --> 00:12:45.620 때로는 답이 모호한 어조 때문이 아니라 00:12:45.620 --> 00:12:47.200 구조가 부족해서 그럴 수 있습니다 00:12:47.200 --> 00:12:49.720 바로 그럴 때 새로운 주제를 만드는 것이 효과적입니다 00:12:49.720 --> 00:12:52.280 스튜디오의 주제 페이지에는 코파일럿을 사용하여 00:12:52.280 --> 00:12:54.460 설명에서 바로 추가하는 편리한 옵션이 있습니다 00:12:54.460 --> 00:12:56.520 사용자가 비용 한도에 대해 물어볼 때 00:12:56.520 --> 00:12:58.860 바로 답하라는 식으로 필요한 내용을 설명하세요 00:12:58.860 --> 00:13:01.340 추가를 누르면 시스템이 그 설명을 바탕으로 00:13:01.340 --> 00:13:02.860 주제 노트 트리를 작성합니다 00:13:02.860 --> 00:13:05.700 빠르고 명확하며 답답했던 모호한 응답을 00:13:05.700 --> 00:13:08.300 다음번에는 확실한 답변 경로로 바꿔줍니다 00:13:08.300 --> 00:13:10.600 보시 똑같은 기본 질문을 계속 회피할 때 00:13:10.600 --> 00:13:11.880 마다이 기능을 사용하세요 00:13:11.880 --> 00:13:14.380 하지만 예, 아니오식의 수정에만 그치지 마세요 00:13:14.380 --> 00:13:15.840 어조를 A, B 테스트하는 것처럼 00:13:15.840 --> 00:13:17.140 10분 정도 실험을 해보세요 00:13:17.140 --> 00:13:18.400 지침 필드로 들어가서 00:13:18.400 --> 00:13:21.000 격식 있는 정체 거너를 사용하는 A버전을 작성하세요 00:13:21.000 --> 00:13:23.620 저장하고 출장 경비 한도가 얼마인지 물어본 뒤 00:13:23.620 --> 00:13:24.600 답변을 기록하세요 00:13:24.600 --> 00:13:26.820 그 다음 지침을 B버전으로 바꾸세요 00:13:26.820 --> 00:13:29.620 규정을 인용하면서 간단하고 친근하게 설명하는 00:13:29.620 --> 00:13:31.080 인사 담당자 페르소나입니다 00:13:31.080 --> 00:13:32.540 같은 질문을 다시 실행하면 00:13:32.540 --> 00:13:35.100 어떤 페르소나가 더 나은지 비교 로그가 나타나며 00:13:35.100 --> 00:13:37.340 테스트 창만 있으면 충분히 가능합니다 00:13:37.340 --> 00:13:39.140 그렇게 하면 추측이 아닌 증거를 바탕으로 00:13:39.140 --> 00:13:40.180 어조를 결정할 수 있습니다 00:13:40.180 --> 00:13:42.260 이제 근거 확인, 그라운딩 체크스, 을 추가하세요 00:13:42.260 --> 00:13:44.200 테스터가 호텔 비용은 얼마까지 청구할 수 있나요? 00:13:44.280 --> 00:13:45.480 라고 물었다 고가정 해봅시다 00:13:45.480 --> 00:13:46.840 그런데 보시, 인사팀에 확인하세요 00:13:46.840 --> 00:13:47.840 라고 모호하게 응답합니다 00:13:47.840 --> 00:13:49.800 이건 완전히 실패한 게 아니라 하나의 피드백입니다 00:13:49.800 --> 00:13:51.680 아마도 익스펜시스, 폴리시, 닥스 파일이 00:13:51.680 --> 00:13:52.700 아직 세긴되지 않았을 수 있습니다 00:13:52.700 --> 00:13:55.180 혹은 트리거 문구에 호텔이 포함되지 않았을 수도 있죠 00:13:55.180 --> 00:13:57.880 지식탭을 다시 확인하여 파일이 활성화되어 있는지 확인하고 00:13:57.880 --> 00:13:59.420 여행 주제의 트리거 문구로 00:13:59.420 --> 00:14:00.900 호텔 비용을 추가하여 해결하세요 00:14:00.900 --> 00:14:02.180 이제 다시 실행해보세요 00:14:02.180 --> 00:14:04.880 정책에 따르면 숙박비는 1박당 200달러로 제한됩니다 00:14:04.880 --> 00:14:07.240 라는 답변이 나오면 문제를 성공적으로 해결한 것입니다 00:14:07.240 --> 00:14:08.880 미묘하지만 중요한 요령 하나는 00:14:08.880 --> 00:14:10.600 대화시장 문구를 사용하는 것입니다 00:14:10.600 --> 00:14:11.880 빈 텍스트 상자를 보면 00:14:11.880 --> 00:14:14.180 사용자는 망설이익이 마련이지만 00:14:14.180 --> 00:14:16.100 개요페이지에서 몇 가지 추천 질문을 00:14:16.100 --> 00:14:17.340 미리 채워넣을 수 있습니다 00:14:17.340 --> 00:14:19.460 호텔 비용 한도는 얼마인가요? 00:14:19.680 --> 00:14:21.360 출장비 청구는 어떻게 하나요? 00:14:21.500 --> 00:14:22.660 어떤 식비가 환급되나요? 00:14:22.660 --> 00:14:24.660 와 같은 질문 3개에서 5개를 추가하세요 00:14:24.660 --> 00:14:25.840 사용자가 바로 클릭하게 되면 00:14:25.840 --> 00:14:27.320 실제 경로를 더 빨리 테스트할 수 있고 00:14:27.320 --> 00:14:28.980 사용자는 보시 입력을 시작하기도 전에 00:14:28.980 --> 00:14:30.440 자신의 역할을 알고 있다고 느끼게 됩니다 00:14:30.440 --> 00:14:31.900 이런 흐름은 경로를 거칠수록 00:14:31.900 --> 00:14:33.500 봇을 더욱 견고하게 만들어줍니다 00:14:33.500 --> 00:14:35.240 운에 맡긴 채 실패한 출력을 무시하고 00:14:35.240 --> 00:14:37.540 다음번엔 마법처럼 성공하길 바라는 건 금물입니다 00:14:37.540 --> 00:14:39.680 그렇게 되면 사람들은 지원 티켓을 제출하게 되고 00:14:39.680 --> 00:14:40.780 결국 신뢰를 잃게 됩니다 00:14:40.780 --> 00:14:41.840 자연수 20이 나오면 00:14:41.840 --> 00:14:43.660 보시 출처와 적절한 페르소나를 통해 00:14:43.660 --> 00:14:45.780 복잡한 입력까지 이해한다는 것을 입증할 때까지 00:14:45.780 --> 00:14:46.800 그 루틴을 반복하세요 00:14:46.800 --> 00:14:49.340 반복할 때 마다봇은 불안정한 도박 같은 존재에서 00:14:49.340 --> 00:14:51.340 믿음직한 팀원으로 한 걸음씩 다가갑니다 00:14:51.340 --> 00:14:52.460 표실은 이렇습니다 00:14:52.460 --> 00:14:55.040 테스트 창 안에서 다듬는 것은 안전모드일 뿐입니다 00:14:55.040 --> 00:14:56.180 루프가 제대로 작동한다면 00:14:56.180 --> 00:14:58.260 다음 단계는 그 수정사항들이 내 컴퓨터 밖에서 00:14:58.260 --> 00:14:59.660 어떻게 작동하는지 확인하는 것입니다 00:14:59.660 --> 00:15:01.640 그때부터 채널별 차이가 드러나기 시작하는데 00:15:01.640 --> 00:15:04.480 초보 개발자들이 가장 간과하는 부분이 바로 여기입니다 00:15:04.480 --> 00:15:05.420 번전이 공개될 때 00:15:05.420 --> 00:15:07.840 즉 게시와 채널에서의 놀라운 일들이 기다리고 있습니다 00:15:07.840 --> 00:15:09.460 마침내 게시 버튼을 누르는 순간 00:15:09.460 --> 00:15:11.000 에이전트는 작업실을 떠나 00:15:11.000 --> 00:15:12.900 실제 사용자들 앞에서 살아남아야 합니다 00:15:12.900 --> 00:15:14.520 코파일러 스튜디오에서의 단계를 00:15:14.520 --> 00:15:16.320 번전이 공개될 때라고 부르는 이유는 00:15:16.320 --> 00:15:18.360 게시하는 순간 공들여 연습시킨 봇이 00:15:18.360 --> 00:15:20.540 각자의 규칙을 가진 채널로 던져지기 때문입니다 00:15:20.540 --> 00:15:21.640 첫 번째 놀라운 점은 00:15:21.640 --> 00:15:24.300 게시가 단순히 클릭 한 번으로 끝나는 작업이 아니라는 것입니다 00:15:24.300 --> 00:15:26.000 이는 누가 에이전트에 접근할 수 있는지 00:15:26.000 --> 00:15:27.120 어떻게 접속하는지 00:15:27.120 --> 00:15:29.200 그리고 응답이 실제 환경에서 어떻게 나타나는지를 00:15:29.200 --> 00:15:30.120 결정하는 과정입니다 00:15:30.120 --> 00:15:32.160 팀즈, 시어포인트, 데모 웹사이트까지 00:15:32.160 --> 00:15:33.780 각 채널에는 저마다의 특성이 있습니다 00:15:33.780 --> 00:15:35.260 스튜디오에서 깔끔했던 답변도 00:15:35.260 --> 00:15:37.560 배포 후에는 다르게 보이거나 아예 실패할 수 있습니다 00:15:37.560 --> 00:15:38.980 팀즈를 예로 들어보죠 00:15:38.980 --> 00:15:41.460 스튜디오에서는 답변이 아주 깔끔하게 나옵니다 00:15:41.460 --> 00:15:42.960 숙박비는 하루 200달러입니다 00:15:42.960 --> 00:15:44.360 라는 정책이 있다고 해봅시다 00:15:44.360 --> 00:15:46.140 팀즈에서 같은 문구를 테스트하면 00:15:46.140 --> 00:15:46.980 보순 그대로인데 00:15:46.980 --> 00:15:49.120 갑자기 이해하지 못하겠다는 반응이 돌아옵니다 00:15:49.120 --> 00:15:50.360 팀즈가 텍스트를 감싸고 00:15:50.360 --> 00:15:51.900 메타 데이터를 전달하는 방식 때문에 00:15:51.900 --> 00:15:52.900 정렬이 깨진 것입니다 00:15:52.900 --> 00:15:55.520 셰어포인트는 줄간격 처리 방식이 독자적입니다 00:15:55.520 --> 00:15:57.260 데모 웹사이트가 가장 단순하지만 00:15:57.260 --> 00:15:59.800 스튜디오와는 다르게 서식을 렌더링할 수 있습니다 00:15:59.800 --> 00:16:01.800 각 계시 대상은 서로 다른 경기장이므로 00:16:01.800 --> 00:16:03.140 각각 따로 테스트해야 합니다 00:16:03.140 --> 00:16:05.720 작업을 완료하기 전에 거쳐야 할 올바른 순서는 무엇일까요? 00:16:05.720 --> 00:16:08.480 초보적인 실수를 피할 수 있는 게시 체크리스트를 소개합니다 00:16:08.480 --> 00:16:11.320 첫째, 지식 파일이 완전히 인덱싱 되었는지 확인하세요 00:16:11.320 --> 00:16:12.260 방금 업로드했다면 00:16:12.260 --> 00:16:14.720 실시간 답변을 하기 위한 준비가 아직 안 되었을 수 있습니다 00:16:14.720 --> 00:16:16.580 둘째, 인증을 설정하세요 00:16:16.580 --> 00:16:18.140 광범위한 데모를 진행한다면 00:16:18.140 --> 00:16:19.340 인증 없음을 선택하여 00:16:19.340 --> 00:16:21.360 링크가 있는 누구나 사용해 볼 수 있게 하세요 00:16:21.360 --> 00:16:22.840 셋째, 게시를 누르고 00:16:22.840 --> 00:16:26.600 채널 페이지에서 녹색 확인 배너나 상태 업데이트가 뜨는지 확인하세요 00:16:26.600 --> 00:16:29.280 넷째, 데모 웹사이트 채널 설정을 여세요 00:16:29.280 --> 00:16:31.320 환영 메시지와 대화 시작 문구를 업데이트하여 00:16:31.320 --> 00:16:33.600 테스터들이 빈 채팅 창 앞에서 당황하지 않게 하세요 00:16:33.600 --> 00:16:35.720 마지막으로, 클로즈드 파일럿을 실행하세요 00:16:35.720 --> 00:16:37.640 전체 테넌트에 바로 공개하지 마세요 00:16:37.640 --> 00:16:39.140 명확한 지침을 가진 소규모 그룹이 00:16:39.140 --> 00:16:40.740 전체 공개보다 훨씬 현명한 선택입니다 00:16:40.740 --> 00:16:41.600 해당 파일럿 그룹은 00:16:41.600 --> 00:16:43.640 자신들이 테스트 팀이라는 사실을 인지하고 있어야 합니다 00:16:43.640 --> 00:16:44.920 일상적인 언어를 사용하고 00:16:44.920 --> 00:16:45.900 오타를 섞고 00:16:45.900 --> 00:16:47.700 적절한 경우 파일을 업로드하도록 요청하세요 00:16:47.700 --> 00:16:49.920 그들의 실수가 취약점을 드러내는 단서가 됩니다 00:16:49.920 --> 00:16:50.780 비공개 파일럿은 00:16:50.780 --> 00:16:52.700 단순히 출시 과정을 완화하기만 하는 것이 아닙니다 00:16:52.700 --> 00:16:53.920 전사적으로 배포하기 전에 00:16:53.920 --> 00:16:56.420 빌드를 보완하는 데 필요한 기초 보고서를 생성합니다 00:16:56.420 --> 00:16:59.100 채널별 동작 특성 때문에의 단계는 필수적입니다 00:16:59.100 --> 00:17:00.660 스튜디오에서 테스트했던 공식 지리 00:17:00.660 --> 00:17:03.020 일상적인 표현, 오타, 출처 기반 인용 등 00:17:03.020 --> 00:17:05.300 모든 시나리오를 각 대상 채널에서 그대로 다시 실행하세요 00:17:05.300 --> 00:17:07.320 팀즈에서 다르게 렌더링 되는지 확인하세요 00:17:07.320 --> 00:17:09.400 셰어포인트에서 간격이 깨지는지 확인하세요 00:17:09.400 --> 00:17:11.840 웹 데모에서 여전히 출처 인용이 표시되는지 확인하세요 00:17:11.840 --> 00:17:14.020 이것이 일관성을 입증하는 유일한 방법입니다 00:17:14.020 --> 00:17:15.660 스튜디오에서의 완벽한 테스트 한 번이 00:17:15.660 --> 00:17:17.240 성공적인 출시를 보장하지는 않습니다 00:17:17.240 --> 00:17:19.200 개시는 사용자 피드백에만 의존하던 것에서 벗어나 00:17:19.200 --> 00:17:21.440 원격 분석 데이터를 확인하기 시작한다는 의미이기도 합니다 00:17:21.440 --> 00:17:23.440 보�이 팀즈 나 데모 웹사이트에 배포되면 00:17:23.440 --> 00:17:25.240 사용량 데이터가 수집되기 시작합니다 00:17:25.240 --> 00:17:27.740 파워 플랫폼 관리 센터와 내장된 분석 도구가 00:17:27.740 --> 00:17:28.800 여러분을 도울 것입니다 00:17:28.800 --> 00:17:31.360 구입 수치, 오류 횟수, 심지어 어떤 대화가 00:17:31.360 --> 00:17:33.320 토픽을 트리거하지 못했는지도 확인할 수 있습니다 00:17:33.320 --> 00:17:34.640 이는 단순한 부가 작업이 아니라 00:17:34.640 --> 00:17:36.000 여러분의 모니터링 시스템입니다 00:17:36.000 --> 00:17:37.200 게시하고 잊어버리는 것이 아니라 00:17:37.200 --> 00:17:39.200 로그를 주시하며 보시이 올바르게 사용되고 있는지 00:17:39.200 --> 00:17:41.560 새로운 기술 지원 요청을 유발하지 않는지 확인해야 합니다 00:17:41.560 --> 00:17:43.520 이 단계를 서두르면 신뢰를 잃게 됩니다 00:17:43.520 --> 00:17:45.520 최악의 경우 게시 버튼을 무작정 누르고 00:17:45.520 --> 00:17:46.500 전 부서에 배포했다가 00:17:46.500 --> 00:17:47.920 팀즈에서 핵심 응답이 누락되어 00:17:47.920 --> 00:17:49.680 지원 요청이 쇄도하는 사태를 맞을 수 있습니다 00:17:49.680 --> 00:17:50.780 사용자들은 포기하게 되고 00:17:50.780 --> 00:17:51.960 그 자체를 수정하는 것보다 00:17:51.960 --> 00:17:52.860 그들의 마음을 돌리는데 00:17:52.860 --> 00:17:53.800 더 많은 시간이 걸립니다 00:17:53.800 --> 00:17:54.520 최선의 경우 00:17:54.520 --> 00:17:56.960 게시 단계를 또 하나의 테스트 단계로 취급합니다 00:17:56.960 --> 00:17:59.200 색인 완료, 인증 설정, 게시 확인, 00:17:59.580 --> 00:18:01.480 데모 사이트 조정, 파일럿 실행을 거칩니다 00:18:01.480 --> 00:18:03.620 복잡한 피드백을 수집하고 응답을 보완하며 00:18:03.620 --> 00:18:05.680 각 채널에서 모든 핵심 질의를 다시 실행합니다 00:18:05.680 --> 00:18:07.000 본격적으로 확장 배포할 때 00:18:07.000 --> 00:18:09.140 쯤이면 이미 스트레스 테스트를 통과한 상태가 됩니다 00:18:09.140 --> 00:18:12.220 진정한 요령은 게시를 끝으로 생각하는 방식에서 벗어나는 것입니다 00:18:12.220 --> 00:18:13.860 그 버튼은 책의 마지막 문장이 아니라 00:18:13.860 --> 00:18:15.560 현장 캠페인의 시작을 의미합니다 00:18:15.560 --> 00:18:16.700 파일럿 데이터가 수집되고 00:18:16.700 --> 00:18:18.120 로그를 통해 사용자가 모든 곳에서 00:18:18.120 --> 00:18:19.520 정확한 답변을 얻고 있음이 확인되면 00:18:19.520 --> 00:18:21.640 그때 비로소 안정적이라고 부를 자격이 생깁니다 00:18:21.640 --> 00:18:23.740 이러한 인식은 코파일럿 스튜디오 로빌드하는 00:18:23.740 --> 00:18:25.180 전체적인 그림과 연결됩니다 00:18:25.180 --> 00:18:26.360 이는 일회성 구축이 아니라 00:18:26.360 --> 00:18:28.720 계속해서 조정해나가는 시스템이기 때문입니다 00:18:28.720 --> 00:18:30.940 이제 실제로 중요한 내용을 요약해드립니다 00:18:30.940 --> 00:18:32.060 빌드를 불안정함에서 00:18:32.060 --> 00:18:33.820 신뢰성으로 바꾸는 세 가지 요소가 있습니다 00:18:33.820 --> 00:18:35.200 첫째, 에이전트의 기반을 다지고 00:18:35.200 --> 00:18:36.260 실제 문서를 업로드하거나 00:18:36.260 --> 00:18:37.400 신뢰할 수 있는 소스를 연결하여 00:18:37.400 --> 00:18:38.480 추측성 답변을 멈추게 하세요 00:18:38.480 --> 00:18:40.020 둘째, 페르소나를 부여하고 00:18:40.020 --> 00:18:41.860 이름, 설명, 어조를 설정하며 00:18:41.860 --> 00:18:44.320 8천자 지침필드의 동작 방식을 명확히 기재하세요 00:18:44.320 --> 00:18:46.100 셋째, 리허설 결과만 믿지 말고 00:18:46.100 --> 00:18:47.300 테스트 창을 활용해 00:18:47.300 --> 00:18:48.440 비공개 시범 운영을 거친 뒤 00:18:48.440 --> 00:18:49.560 게시하고 모니터링하세요 00:18:49.560 --> 00:18:50.220 운이 좋다면 00:18:50.220 --> 00:18:51.320 이러한 단계를 통해 00:18:51.320 --> 00:18:52.040 문의 티켓이 아닌 00:18:52.040 --> 00:18:53.780 신뢰를 쌓는 곳을 만들 수 있을 겁니다 00:18:53.780 --> 00:18:54.840 구독하고 댓글로 00:18:54.840 --> 00:18:56.280 여러분의 에이전트 기반이 될 00:18:56.280 --> 00:18:57.400 정책 문서 한 가지를 00:18:57.400 --> 00:18:58.640 한 문장으로 남겨주세요