WEBVTT 00:00:00.000 --> 00:00:05.060 COパイロットスタジオで初めてエージェントを公開したとしましょう ところが周囲を驚かせるどころかポリシーには 00:00:05.060 --> 00:00:09.900 多分それがボット構築の自然な姿だと書いてある気がします などと頼りない回答をしてしまうのです 00:00:09.900 --> 00:00:16.780 しかしいくつかの修正を加え実際のポリシー文書に基づいた明確な指示を与えることで その失敗を正確な根拠を引用する完璧な回答へと変えることができます 00:00:16.780 --> 00:00:21.440 この動画を見終わる頃にはテストペインで悪い回答を再現する方法 ボットが実際の文書を引用するように修正する方法 00:00:21.440 --> 00:00:25.420 そして機能するパイロットを公開する方法がわかるはずです 本題の前にチャンネル登録をお願いします 00:00:25.420 --> 00:00:31.140 そうすればこれらのチュートリアルが自動的にプレイリストに追加されます もちろんテストウィンドウでうまくいくのは簡単なことです 00:00:31.140 --> 00:00:38.040 本当の苦労はボットが道場を離れ現実世界でつまずいた時に始まります なぜ完璧だったはずのテスト用ボットが現実世界で崩壊してしまうのか 00:00:38.040 --> 00:00:42.440 テストペインでは完璧に見えたボットがなぜ実際のユーザーに対応した途端に混乱し始めるのでしょうか 00:00:42.440 --> 00:00:50.180 手短に言えばスタジオは状況を整理し丁寧に対応しますが現実世界にはそのような配慮が 存在しないからですスタジオでは入力されるデータは整理されています 00:00:50.180 --> 00:00:56.720 質問は短く綺麗に構成されており通常は準備したトレーニング例と一致します だからこそ完璧な結果が続いているように感じるのです 00:00:56.720 --> 00:01:02.800 しかし本番環境に移ると人々は人間らしく入力してきます 上級社員ならホテル滞在時の請求額はいくらまでと尋ねるかもしれません 00:01:02.800 --> 00:01:08.960 担当者ならホテル経費制限と5時混じりで入力するかもしれません また別の人は出張費について教えてとだけ言うかもしれません 00:01:08.960 --> 00:01:15.200 これらはすべて同じ意味ですが経費制限はいくらですかというテストしかしていない場合 ボットは常にそれらを結びつけられるとは限りません 00:01:15.200 --> 00:01:20.460 このギャップを確認する方法を今すぐ教えしましょう テストペインを開き3つの異なるパターンの質問をボットに投げかけてみてください 00:01:20.460 --> 00:01:25.500 まず綺麗な質問文次にカジュアルな書き換えそして5時のあるパターンです 回答が変化する様子を観察してください 00:01:25.500 --> 00:01:32.080 すべてうまくいくこともあれば綺麗な質問にしか正しく回答できないこともあります それが美しいテスト結果が現実世界での成功を保証するわけではないという最初の兆候です 00:01:32.080 --> 00:01:37.820 技術的な理由はインテント意図の網羅性にあります ボットはトリガーフレーズとトピック定義に依存していつ回答すべきかを判断します 00:01:37.820 --> 00:01:42.840 例がすべて同じようなものだとモデルは柔軟性を失ってしまいます たった一つの類義語でもボットを困惑させることがあります 00:01:42.840 --> 00:01:48.400 解決策は地味ですが非常に効果的です ポリシー文書の正式な言葉だけでなくより幅広いトリガーフレーズをトピックに追加しましょう 00:01:48.400 --> 00:01:53.520 人々が実際に使うようなカジュアルで略語を含んだ少し乱れた表現も混ぜておきます 何十個も必要はありません 00:01:53.520 --> 00:01:56.720 明白なバリエーションをカバーするだけで十分です その後再テストしてください 00:01:56.720 --> 00:02:00.860 チャンネルの違いが状況をさらに難しくします スタジオのテストペインはあくまでシミュレーションに過ぎないからです 00:02:00.860 --> 00:02:06.420 チームシェアポイントデモ用ウェブサイトなどのチャンネルに公開すると プラットフォームによって入力テキストの処理方法や応答のレンダリングが変わる可能性があります 00:02:06.420 --> 00:02:10.920 チームでは開業のされ方が異なるかもしれません ウェブページでは書式設定が削除される可能性があります 00:02:10.920 --> 00:02:18.960 重要なフレーズを別の行に移すといった些細な変更でもモデルがそれをどう評価するかが変わってしまうのです そのためマイクロソフトは各チャンネルで繰り返しテストを行う必要性を強調しています 00:02:18.960 --> 00:02:27.920 スタジオでは正常に動作したボットでも現実世界のフォーマットに直面するとつまずくことがあります ユーザーにはユーザーの期待があります彼らにとって質問の言い換えはごく自然な会話の一部です 00:02:27.920 --> 00:02:33.460 彼らはインテントやトリガー意味の重複などについては考えていません 彼らは同僚と同じようにボットが理解してくれるものだと単に思い込んでいます 00:02:33.460 --> 00:02:38.580 一度でもひどい失敗をすれば特にデモの場では信頼は失われてしまいます これが初めて作成する人が痛い目を見るポイントです 00:02:38.580 --> 00:02:43.660 スタジオ内でのリハーサルが誤った安心感を与えてしまいましたがチームでユーザーが 何気なく入力した内容がその幻想を打ち砕くのです 00:02:43.660 --> 00:02:48.340 もう一つ例を挙げて具体的に説明しましょう スタジオで経費の制限はと入力します 00:02:48.340 --> 00:02:55.780 ボットは規定では宿泊費は1日200ドルですと直接回答します 完璧ですこれをデプロイします次にねホテルの代金はいくらまで戻るんだっけ 00:02:55.780 --> 00:03:01.460 と試してみます 規定を引用する代わりにボットは人事に確認するように促したり曖昧な推測をしたりします 00:03:01.460 --> 00:03:08.340 意図は同じでも結果は全く異なります リハーサルでは正確なのに本番では曖昧になるというこの入れ替わりこそ私たちが話している問題そのものです 00:03:08.340 --> 00:03:12.360 ここから得られる教訓はこれです スタジオはスパーリングの練習相手として扱いましょう 00:03:12.360 --> 00:03:17.780 学習には役立ちますが準備万端であることの証明にはなりません 次に進む前にテストペインで3種類のバリエーションテストを試し 00:03:17.780 --> 00:03:23.500 類義語やカジュアルな言い回しを含めてトピックを広げてください 最後に公開する際はボットが展開されるすべてのチャンネルで再テストを行ってください 00:03:23.500 --> 00:03:32.260 そうすればユーザーに見つかる前に問題を捉えられます さらに大きな罠が待ち受けています言い回しやチャンネルをカバーしていても適切なソースに基づいていなければボットは崩壊してしまうからです 00:03:32.260 --> 00:03:38.380 質問を見逃すだけでなく事実とは異なることを捏造し始めるのです 自信ありげに聞こえるけれど実際は当てずっぽうなボットを想像してみてください 00:03:38.380 --> 00:03:44.220 そこから状況は厄介なことになります それがボットをグラウンディング根拠付けさせないという初心者のミスです 00:03:44.220 --> 00:03:48.980 初心者が犯す最初のミスはコパイロットスタジオをルールブックではなく 水晶玉のように扱ってしまうことです 00:03:48.980 --> 00:03:54.540 十分な知識に基づかずにエージェントを立ち上げることは準備ゼロで新人を役員会議に送り込むようなものです 00:03:54.540 --> 00:04:01.220 彼らは早口で話し自信ありげに見えますが誰かが確認した瞬間にその話の半分は崩れ去るでしょう それがボットをグラウンディングさせずに放置する罠なのです 00:04:01.220 --> 00:04:07.480 最初はその輝きに隠れて見えないかもしれませんが スタジオで作成したばかりのビルドは丁寧な挨拶と素早い返信で遅延もなく宣伝されて見えます 00:04:07.480 --> 00:04:12.820 しかしその裏側では言葉を裏付ける確かな根拠がありません システムが抽出しているのは事実ではなくパターンに過ぎないのです 00:04:12.820 --> 00:04:16.460 グラウンディング根拠付けされていないボットは何も知りません ただのハッタリです 00:04:16.460 --> 00:04:24.580 テスト画面ではうまく見えるかもしれませんが本番環境のユーザーはすぐに見抜いてしまいます 最悪の事態は回答の質の低さではなくハルシネーション幻覚です 00:04:31.220 --> 00:04:39.440 に断る代わりにありそうな数字をでっち上げます その不正確な回答を機にスタッフがホテルを予約してしまい経費のトラブルや苦情メールの対応に追われることになるのです 00:04:39.440 --> 00:04:44.660 文章はプロフェッショナルでも中身は空っぽでした コントソラボの例でこれが現実の問題であることがわかります 00:04:44.660 --> 00:04:52.860 公式のハンズオン演習ではエクスペンセスポリシーdocxというファイルをアップロードします その中には宿泊費の上限が1泊200ドルと明確に記されています 00:04:52.860 --> 00:05:02.820 もしグラウンディングをせずに新しいボットにホテルの規定はと尋ねると一泊100ドルと 自信満々に答えるかもしれません完全にデタラメですエクスペンセスポリシーdocxを実際に添付して 00:05:02.820 --> 00:05:06.960 初めてモデルは適当な回答をやめます グラウンディングされたボットはドキュメントを引用します 00:05:06.960 --> 00:05:14.360 社内規定によると宿泊費は1日200ドルまでとなっています その違いつまりレッチ上げか引用かを決めるのがグラウンディングのステップなのです 00:05:14.360 --> 00:05:20.880 ではインターフェースで修正する方法を具体的に説明します コパイロットスタジオで対象のエージェントを開きます概要画面からナレッジをクリックします 00:05:20.880 --> 00:05:26.920 プラスナレッジの追加を選択しファイルをアップロードします エクスペンセスポリシーdocxやその他の信頼できるソースを指定してください 00:05:26.920 --> 00:05:36.100 公開ウェブサイトやシェアポイントに接続することも可能ですがファイルの型が管理しやすいでしょう アップロードしたら待ちますコンテンツが準備できるまでインデックス作成に10分以上かかることがあります 00:05:36.100 --> 00:05:43.880 最初のテストクエリですぐに反映されなくても慌てないでください インデックス作成が完了したらもう一度質問してみましょう正しくグラウンディングされていればアップロードした 00:05:43.880 --> 00:05:53.020 ドキュメントからの引用元が表示され正しい200ドルという回答が得られます その引用こそが完璧な成功の証ですよくある誤解として会話ブースティングが魔法のように 00:05:53.020 --> 00:05:58.960 欠落を補ってくれると思い込むことがあります ブースティングは規定を理解するわけではなく単にテキストパターンを強化するだけです 00:05:58.960 --> 00:06:07.120 知識ソースというアンカーがなければブースティングは一般的な空虚な言葉を並べるだけです それはまるで知識のないインターンにコーヒーを3杯飲ませてカフェインで無知を補おうとするようなものです 00:06:07.120 --> 00:06:14.000 ラボのドキュメントにもその旨が警告されています 知識ベースに一致するものがない場合ブースティングはモデルに組み込まれた一般知識に頼ってしまい 00:06:14.000 --> 00:06:21.420 曖昧または不正確な回答を返す可能性があります そのため正確性が求められる重要なトピックについては追加したソースのみを検索するように設定する必要があります 00:06:21.420 --> 00:06:29.100 コンプライアンス財務人事などの重要な分野ではボットを広範な言語モデルの中で自由に 動かさないようにしてくださいこの手順を無視した場合の悪影響はすぐに積み重なってしまいます 00:06:29.100 --> 00:06:35.080 根拠のないボットは雑談には適していますが経費生産や休暇規定について回答し始めると ヘルプデスクへの問い合わせを誘発してしまいます 00:06:35.080 --> 00:06:41.000 ボットが勝手に限度額を作成したせいで5人の従業員が誤った料金で申請してしまい 財務部門に説明しなければならない状況を想像してみてください 00:06:41.000 --> 00:06:44.360 その修正にかかるコストは最初からドキュメントをアップロードする手間よりも はるかに大きくなります 00:06:44.360 --> 00:06:50.080 グラウンディング根拠付けによってあなたのエージェントはやる気はあるが何も知らない インターンからゲーマーが言うところのルール市場主義者に変わります 00:06:50.080 --> 00:06:56.480 それは自身の直感ではなくマニュアルに従って引用するようになります 経費規定のドキュメントを添付すればシステムは即座にアドリブではなく企業のルールを強制するようになります 00:06:56.480 --> 00:07:00.120 さらに良いことに回答には根拠となる裏付けや明確な引用が示されるため確認が可能です 00:07:00.120 --> 00:07:05.940 それこそが信頼を守る方法なのです 最悪の結果になればあなたはそのデタラメなルールを広める自信満々な噂話マシンを作り上げてしまうでしょう 00:07:05.940 --> 00:07:14.240 最高の結果になれば引用付きで回答する確かな専門家を作り上げることができます 後者を実現する唯一の方法は最初から検証済みの知識ソースを読み込ませることです 00:07:14.240 --> 00:07:19.640 ボットが正しく真実を語れるようになっても次の課題が待っています それはどう伝えるかです 00:07:19.640 --> 00:07:27.800 正確であっても個性がなければユーザーは離れてしまいます 次にボットに個性を教え込む必要がありますがコパイロットスタジオでは標準で個性はついてきません 00:07:27.800 --> 00:07:34.720 あなたが書き込む必要があるのです ここでシステムをテスト用ダミーのような話し方から卒業させユーザーが話したくなるような相手と形作って 00:07:34.720 --> 00:07:39.480 いきます 具体的には概要ページにある名前説明指示フィールドを編集することを意味します 00:07:39.480 --> 00:07:47.320 これらを空のままにするとチュートリアルモードから抜け出せない npc のようなありきたりな返答しか返ってきません これは初めて構築する人の多くが見落とすポイントです 00:07:47.320 --> 00:07:54.660 作成ボタンを押した瞬間にシステムにはすでにデフォルトのスタイルが設定されています フィールドを編集しなければ権威も文脈もない当たり障りのない挨拶をするだけのボットになってしまいます 00:07:54.660 --> 00:08:01.280 信頼を獲得するのは文脈コンテキストです 人事や財務のような環境で一般的な口調だとユーザーは信頼できるツールを使っているのではなく 00:08:01.280 --> 00:08:09.180 プロトタイプをテストしているのだと考えてしまいます 例えば経費規定の専門家を作ろうとしても名前や説明を変更しなければエージェントは背景情報のない 00:08:09.180 --> 00:08:15.040 一般的なコパイロットとして表示されてしまいます 誰かがホテルの生産について尋ねた時ユーザーは専門的なアドバイスを期待しているのです 00:08:15.040 --> 00:08:21.600 ユーザーが目にするのは何の工夫もない素っ気ないテキストです これでは私を信用しないでくださいというかすかですが強力なサインを送っているようなものです 00:08:21.600 --> 00:08:28.900 信頼はすぐに失われます最初の接触でユーザーを逃がせば二度と戻ってはきません 全体の設定を手早くキャラクターシートを作るような感覚で考えてみてください 00:08:28.900 --> 00:08:37.400 名前は職業クラス説明は背景バックストーリー長い指示ボックスは能力値 そしてトーンは属性アライメントです能力値を割り振らずにキャンペーンに挑むことはないでしょう 00:08:37.400 --> 00:08:44.720 ボットを公開するときも同じです さてここでは具体的な数字が重要になりますボットの名前は30文字が上限なので短く鋭いものにしましょう 00:08:44.720 --> 00:08:52.660 経費規定エキスパートトラベルガイド福利構成ヘルパーなどがいいですね 説明欄は約1000文字まで入力可能で明確な文章をいくつか書くには十分な長さです 00:08:52.660 --> 00:09:00.960 例えばこのエージェントは公式の出張規定に基づいた最新の回答を従業員に提供します 関連する条文を引用し推測による回答は避けますといった具合です 00:09:00.960 --> 00:09:05.420 次に指示フィールドがあります これは自由に使える枠で最大8000文字まで入力可能です 00:09:05.420 --> 00:09:10.500 ここで実際の運用ルールをしっかりと固定できます 単に親切にと書くのではなくプレイブックを具体的に明記しましょう 00:09:10.500 --> 00:09:18.400 ポリシーの該当箇所がある場合は必ず引用すること推測による回答は避けること 役員向けには簡潔な一問で要約しその後に引用元を提示すること 00:09:18.400 --> 00:09:24.460 作成時に読み上げられる便利なチェックリストはこのようなものです 役割に名前を付け専門性について短い説明を書き 00:09:24.460 --> 00:09:32.000 トーンフォーマルカジュアル専門外の人にも分かりやすくを設定し指示欄を行動ルール 含めるべき内容避けるべき内容フォーマット方法で埋めること 00:09:32.000 --> 00:09:36.820 これらのステップの一つ一つがアイデンティティを強固にしていきます どれも高度な設定は必要ありません 00:09:36.820 --> 00:09:42.920 作成時にすぐ行えますし概要ページから後で編集することも可能です トーンのガイダンスは控えめながら強力です 00:09:42.920 --> 00:09:49.060 フォーマルかつプロフェッショナルにや技術的背景のないスタッフにも分かりやすく カジュアルにといったフレーズで明示的に誘導できます 00:09:49.060 --> 00:09:55.420 必要であれば指示欄に直接例を追加しましょう ボットがすべての文章をどのように構成するかを制御するのに多くのテキストは必要ありません 00:09:55.420 --> 00:10:01.180 あまり知られていない2つの迅速な改善策を紹介します 会話開始トピックを編集しエージェントアイコンを変更することです 00:10:01.180 --> 00:10:06.620 どちらも5分以内で完了します テストペインでチャットを開いた時にボットが最初に行う挨拶メッセージを確認できます 00:10:06.620 --> 00:10:13.460 デフォルトでは汎用的な内容になっています そこをクリックして会話開始トピックを編集し決まりきった挨拶文を出張規定の理解をサポートします 00:10:13.460 --> 00:10:19.820 可能な限り公式ドキュメントを引用しますといった役割に応じた紹介文に置き換えましょう その後会話をリフレッシュしてテストします 00:10:19.820 --> 00:10:26.880 一瞬でプロフェッショナルな印象になります アイコンについては192x192ピクセル以下30kb未満のpng形式に対応しています 00:10:26.880 --> 00:10:31.960 ブランドロゴなどの画像を一つ入れるだけでもデモ感が払拭され最初の回答に対する信頼性が損なわれなくなります 00:10:31.960 --> 00:10:36.980 こうした修正を単なるオプションの仕上げだと考える人もいます しかしこれは最低限の防具だと考えてください 00:10:36.980 --> 00:10:45.200 防具のないキャラクターでも攻撃はできますが強烈な一撃を食らえば一瞬で倒されてしまいます 味気ない名前と曖昧な挨拶でユーザーを迎えるボットはこれと同じ無防備な状態です 00:10:45.200 --> 00:10:51.460 基本をしっかり抑えておけば混乱や離脱に対する強力な防御策となります 小さな調整の積み重ねが大きな効果を生みます 00:10:51.460 --> 00:10:59.260 役割を明記した導入文を設定すればユーザーは適切な質問をしやすくなります 口調のルールを決めれば長すぎる冗長な回答を防げます指示を明確にすることで 00:10:59.260 --> 00:11:07.220 aiは余計な情報をそぎ落とし人間にとって読みやすい形式で回答します こうした調整の一つ一つがわかりませんという問い合わせを減らし新しいコネクタやプラグインなしでスムーズなやり取りを実現します 00:11:07.220 --> 00:11:10.980 ですからこれをルールにしてください 高度なロジックを組む前にまずはペルソナを設定しましょう 00:11:10.980 --> 00:11:18.920 目的が伝わる名前を選びます短く明確な説明文を作成します 口調を設定します守らせたいルールを指示に盛り込みます会話の最初の挨拶文を更新します 00:11:18.920 --> 00:11:27.320 シンプルなアイコンに変更しますこれらは少ない労力で大きな成果が得られるアクションです うまく機能すれば明確なペルソナを設定するだけで作りたてのボットでもユーザーから頼りにされる存在になります 00:11:27.320 --> 00:11:34.940 逆にペルソナを怠ると誰も二度と使いたがらない不自然な npc になってしまいます エージェントに個性を与えたらいよいよ本番の作業です 00:11:34.940 --> 00:11:45.120 本当のテストは作成時ではなく実際のやり取りで成功や失敗を目の当たりにした後に始まります 一度の失敗で諦めるのではなくその時こそ立ち止まってログを確認する必要があります 00:11:45.200 --> 00:11:50.700 リアルタイムで失敗をデバッグするのです リアルタイムでのデバッグこそが失敗を問い合わせではなく学びへと変える鍵となります 00:11:50.700 --> 00:11:56.500 これこそすべての開発者が実践すべき実践的なループです 間違いを見つけ特定し修正しそして再度テストを実行する 00:11:56.500 --> 00:12:02.640 コパイロットスタジオにはツールが揃っていますが順序立てて使うことが大切です デモを行いながら実際に口に出して進められる手順がこちらです 00:12:02.640 --> 00:12:09.460 ステップ1テストウィンドウで失敗したユーザーのクエリを再現します 曖昧に流してはいけませんユーザーが尋ねたものと全く同じ質問を入力してください 00:12:09.460 --> 00:12:15.700 ステップ2リフレッシュアイコンか新しいチャットを押して再度実行する前に会話をリセットします 白紙の状態から始めることが重要です 00:12:15.700 --> 00:12:24.280 ステップ3トピックを開いてどのトピックが作動したかを確認します それが自分で作成したものではなくシステムの会話ブースト機能によるものならボットが独自の知識ではなくモデルの知識に頼ったというヒントになります 00:12:24.280 --> 00:12:33.100 ステップ4ブースト機能が働いていた場合関連するファイルやサイトがアップロードされインデックスされているか確認します インデックスがなければ根拠付けも行われませんインデックス作成には数分かかる場合があることを覚えておいてください 00:12:33.100 --> 00:12:44.080 ステップ5指示やトピックの内容を編集して保存し全く同じクエリを再実行します 再現修正再実行繰り返しというサイクルがあなたのマントラですこれを飛ばすと次回は運任せで結果が良くなることを願うだけになってしまいます 00:12:44.080 --> 00:12:49.760 回答が曖昧なのはトーンの問題ではなく構造の欠如である場合もあります そこで新しいトピックを作成することが効果を発揮します 00:12:49.760 --> 00:12:58.780 スタジオにはトピックページから直接コパイロットを使って説明文から追加できる便利なオプションがあります 経費の上限について聞かれたら直接答えるなど必要なことを記述します 00:12:58.780 --> 00:13:08.300 追加を押せばシステムはその説明からトピックのノートツリーを下書きします 迅速かつ明確であの厄介で曖昧な回答が次回からは確実な回答パスになることを保証します 00:13:08.300 --> 00:13:14.420 ボットが同じ基本的な質問を交わし続けるときはいつでもこれを使ってください ただしイエスかノーかの修正だけで満足しないでください 00:13:14.420 --> 00:13:20.820 トーンのabテストのような10分間の実験を行いましょう 指示フィールドに移動し形式的な規定言語を用いたパターンaを作成します 00:13:20.820 --> 00:13:26.940 保存して出張費の上限はと質問し回答を記録します 次に指示をパターンbに変えます 00:13:26.940 --> 00:13:35.620 ルールを引用しつつ親しみやすい人事担当者のように説明させます 同じ質問をもう一度実行すればどちらのペルソナがより優れているかを示すログが並んで表示され 00:13:35.620 --> 00:13:40.120 テストペイン以外に何も必要ありません そうすれば推測ではなく証拠に基づいてトーンを決定できます 00:13:40.120 --> 00:13:45.300 次にグラウンディング根拠付けの確認を追加します テスターがホテルの経費はいくらまでと質問したとします 00:13:45.300 --> 00:13:49.940 そこでボットが人事に確認してくださいと曖昧に答えたとします それは完全な失敗ではなくフィードバックです 00:13:49.940 --> 00:13:55.200 おそらく経費規定のドキュメントがまだインデックス化されていないのでしょう あるいはトリガーフレーズにホテルが含まれていないのかもしれません 00:13:55.200 --> 00:14:00.880 ナレッジタブを再確認してファイルが反映されているかを確認し トピックのトリガーフレーズにホテル経費を追加して修正します 00:14:00.880 --> 00:14:07.060 さあ再実行です 規定により宿泊費は1泊200ドルまでですという回答が得られれば問題は無事に修正されました 00:14:07.060 --> 00:14:13.120 繊細ですが重要なコツは会話のきっかけスターターを使うことです テキストボックスが空だとユーザーは戸惑いますが 00:14:13.120 --> 00:14:20.220 概要ページから推奨プロンプトをいくつか事前入力しておけます ホテルの上限はのような質問のフックを3から5個追加します 00:14:20.220 --> 00:14:27.040 出張経費の申請方法は食事代は生産される ユーザーは直接クリックできるため実際のパスをより早くテストでき 00:14:27.040 --> 00:14:33.560 入力する前からボットが自分の役割を理解していると感じてもらえます このリズムを繰り返すことでボットはパスを重ねるごとに頑強になります 00:14:33.560 --> 00:14:40.840 自然な失敗を無視して次の実行で魔法のように成功することを期待してはいけません それではユーザーはサポートチケットを作成する羽目になり信頼を失ってしまいます 00:14:40.840 --> 00:14:46.820 クリティカルヒットが出たらボットが引用元を明示し適切なペルソナで複雑な入力すら理解できると証明するまでそのルーティンを繰り返します 00:14:46.820 --> 00:14:52.680 繰り返すたびにサイコロ任せの不安定な存在から頼りになるチームメイトへと近づいていきます そしてこれが現実です 00:14:52.680 --> 00:14:59.520 テストペイン内での調整はいわば安全モードです ループがうまく機能するようになったら次の段階はその修正が自分の環境以外でどう動作するかを確認することです 00:14:59.520 --> 00:15:04.700 そこでチャンネルごとの違いが顔を出し始めます これこそ多くの初心者が過小評価している部分です 00:15:04.700 --> 00:15:12.680 ダンジョンが公開されるときつまりパブリッシュとチャンネルにまつわる驚きです いざパブリッシュを実行するとエージェントは攻防を離れ実際のユーザーの目にさらされることになります 00:15:12.680 --> 00:15:20.680 コパイロットスタジオではこのステップをダンジョンが公開されるときと呼びます パブリッシュによって入念にリハーサルしたボットが独自のルールを持つチャンネルへと放り込まれるからです 00:15:20.680 --> 00:15:30.140 最初の驚きはパブリッシュはクリック一つで完了する単純なものではないということです それは誰がエージェントにアクセスできどうやって接続しその応答が現場でどのように表示されるかを決定するプロセスなのです 00:15:30.140 --> 00:15:37.500 チームシェアポイントデモ用ウェブサイト各チャンネルには特有の癖があります スタジオで完璧だった返信もデプロイした途端に見た目が変わったり表示に失敗したりすることがあります 00:15:37.500 --> 00:15:48.980 チームを例に挙げてみましょうスタジオでは回答は明瞭に返ってきます ポリシーでは宿泊費は1日200ドルです同じフレーズをチームでテストするとボット側は何も変えていないのに突然理解できませんと返されてしまいます 00:15:48.980 --> 00:15:59.800 これはチームがテキストを折り返しメタデータを渡す際の方法が表示の整合性を崩しているためです シェアポイントは業間に関して独自の挙動をしますデモ用ウェブサイトが最もシンプルですがそれでもスタジオとは異なる形式でレンダリングされる可能性があります 00:15:59.800 --> 00:16:08.500 パブリッシュ先はそれぞれ異なるアリーナであり個別にテストしなければなりません 完了とする前に踏むべき正しい手順は何でしょうか初心者が陥りやすい罠を避けるためのパブリッシュチェックリストをご紹介します 00:16:08.500 --> 00:16:14.680 まずナレッジファイルが完全にインデックス化されていることを確認してください アップロードしたばかりだとまだライブ回答には対応できていない可能性があります 00:16:14.680 --> 00:16:26.600 次に認証を設定します広範囲なデモを行う場合は認証なしを選択しリンクを持つ誰でも試せるようにします 3番目にパブリッシュボタンを押し緑色の確認バナーまたはチャンネルページのステータス更新が表示されたことを確認します 00:16:26.700 --> 00:16:33.620 4番目にデモ用ウェブサイトのチャンネル設定を開きます ウェルカムメッセージと会話のきっかけを更新しテスターが空のチャットボックスを前に固まらないようにしましょう 00:16:33.620 --> 00:16:40.780 最後にクローズドパイロットを実施しますまだテナント全体に配信してはいけません 明確な指示を与えた小規模なグループで進める方が全体リリースよりも賢明です 00:16:40.780 --> 00:16:47.700 そのパイロットグループには彼らがテスト体であることを認識してもらう必要があります カジュアルな言葉遣いや誤字を含めたり適切な場面でファイルをアップロードしてみるよう依頼しましょう 00:16:47.700 --> 00:16:52.660 彼らのミスが弱点を浮き彫りにするのです 限定的なパイロット運用は単にリリースをスムーズにするだけではありません 00:16:52.660 --> 00:16:59.280 全社展開の前にビルドを修正するために必要な性のレポートが得られるのです チャネルごとの挙動を確認するためにはこの手順が不可欠です 00:16:59.280 --> 00:17:05.280 スタジオでテストしたあらゆるシナリオ正式なクエリカジュアルな表現 誤字根拠となる引用をすべてのターゲットチャンネルで再度実行してください 00:17:05.280 --> 00:17:09.360 チームでの表示に違いがないか確認しましょう シェアポイントで感覚が崩れていないか確認します 00:17:09.360 --> 00:17:14.080 webデモでソースの引用が正しく付加されているかも確認してください これが一貫性を証明する唯一の方法です 00:17:14.080 --> 00:17:21.420 スタジオで一度完璧に動作したからといってロールアウトでうまくいくとは限りません 公開するということはユーザーのフィードバックだけに頼るのではなくテレメトリの監視を始めることでもあります 00:17:21.420 --> 00:17:29.000 ボットがチームやデモサイトで公開されると利用データの収集が始まります パワープラットフォーム管理センターと組み込みの分析機能がその助けとなります 00:17:29.000 --> 00:17:35.680 導入数やエラー数どの会話がトピックをトリガーできなかったかまで把握できます それは余計な作業ではなく監視システムなのです 00:17:35.680 --> 00:17:41.520 一度公開して終わりではありません ログを監視しボットが正しく使われヘルプデスクのチケットを増やしていないか確認する必要があります 00:17:41.520 --> 00:17:49.100 この手順を急ぐと信頼を損ないます 最悪の場合公開ボタンを押し全部書にロールアウトした途端チームで重要な回答が欠落し動かないというチケットで 00:17:49.100 --> 00:17:53.580 あふれ返ることになります ユーザーは離れてしまい彼らを取り戻すにはボットを修正する以上の時間がかかります 00:17:53.580 --> 00:18:01.560 最高の結果を目指すなら公開を新たなテストフェーズと捉えましょう インデックスの完了認証の設定公開の確認デモサイトの調整パイロット運用の実施です 00:18:01.560 --> 00:18:09.240 散らかったフィードバックを集め応答を修正しすべての主要なクエリを各チャンネルで再実行します 本格的なロールアウトへと拡大する頃にはストレステストは完了しているはずです 00:18:09.240 --> 00:18:15.620 真のコツは公開を終わりと考えるのをやめることです 公開ボタンは物語の結末ではなくフィールドキャンペーンの始まりなのです 00:18:15.620 --> 00:18:21.600 パイロットのデータが集まりログですべてのユーザーが適切な回答を得ていることが確認できれば ようやく安定していると呼べるようになります 00:18:21.600 --> 00:18:28.600 この認識はコパイロットスタジオでの構築という大きな全体像につながります 一度作って終わりではなく何度も調整を繰り返すシステムだからです 00:18:28.600 --> 00:18:33.480 それでは本当に重要なポイントをまとめます ビルドを不安定から信頼できるものへと変えるのは3つの要素です 00:18:33.480 --> 00:18:38.540 第1にエージェントに根拠を与えること 実際のドキュメントをアップロードするか信頼できるソースを指定して推測を防ぎます 00:18:38.540 --> 00:18:44.280 第2にヘルソナを与えること 8000文字の指示フィールドで名前説明トーン挙動を具体的に指定してください 00:18:44.280 --> 00:18:49.380 3つ目リハーサルがうまくいったからと油断せずテストパネルを使い 限定的な試験運用を経てから公開し監視しましょう 00:18:49.380 --> 00:18:54.040 最高の成果が出ればこれらの手順で問い合わせチケットを増やすのではなく ユーザーの信頼を獲得するボットが完成します 00:18:54.040 --> 00:18:58.720 チャンネル登録をしてあなたのエージェントの根拠とするポリシー文書を一つだけコメント欄で教えてください