WEBVTT 00:00:00.000 --> 00:00:07.780 ポッドキャストでアジュールアイファウンドリーは罠だと言っていたのでクリックしたんですよね よかったですここは正しい場所ですまず最初に約束しておきます 00:00:07.780 --> 00:00:17.680 コパイロットは地上にいないと崩壊しますがアジュール ai 検索のハイブリッドとセマンティック さらに地上性関連性一貫性を評価する評価ツールを備えたリトリーバルオーグメンテッドジェネレーション 00:00:17.680 --> 00:00:27.080 ラグのようなツールは答えを装った幻覚を出荷しないようにするための実際の修正です マーケティング資料は抜きにして現場からの実際の例で生存のプレイブックをお見せします 00:00:27.080 --> 00:00:38.440 m365章ニュースレターに登録して mvp のライブストリームをフォローしてください そこに傷跡と修正がありますそして最初の亀裂は通常マルチモーダルアプリで現れるのでそこから始め 00:00:38.440 --> 00:00:44.120 ましょう 現実世界でマルチモーダルアプリが失敗する理由ステージでマルチモーダルデモを見ると完璧に 00:00:44.120 --> 00:00:49.360 見えます プレゼンターがテキストプロンプと鮮明な画像場合によっては簡単な音声入力を入力するとモデルは 00:00:49.360 --> 00:00:56.400 完璧なグラフや簡潔な契約概要を出力します まるで魔法のようですが実際の企業で同じことを試した途端その輝きはすぐに消え失せます 00:00:56.400 --> 00:01:01.220 デモは完璧な入力で実行されますが職場はゴミで動作します これが本当の違いです 00:01:01.220 --> 00:01:07.680 本番環境では誰もモデルに丁寧に準備されたスクリーンショットや標準委員会によって フォーマットされた csv ファイルを提供しません 00:01:07.680 --> 00:01:17.280 人事部は汚れた政府発行の id を入力し 調達部は5世代目のファックスである pdf を持ち込み財務部の誰かがひび割れたアンドロイドカメラで請求書の写真を撮っています 00:01:17.280 --> 00:01:24.620 マルチモーダルモデルはテキスト画像音声ビデオを処理できますが乱雑な条件下で 機能するには適切にインデックス付けされたデータと検索が必要です 00:01:24.620 --> 00:01:31.500 そうでなければモデルにゴミで即興で対応するように求めているだけです そしてどれだけ gpu に投資してもゴミ入力はゴミ出力になります 00:01:31.500 --> 00:01:38.900 ここで検索拡張生成ラグが役に立つはずです 簡単に言うとモデルはあなたのビジネスを知らないので知識ソースに接続します 00:01:38.900 --> 00:01:44.920 モデルはデータの一部を取得しそれに基づいて回答を形成します 一致が正確であれば役に立つ根拠のある回答が得られます 00:01:44.920 --> 00:01:53.540 一致が不正確であればモデルは自由奔放に自信満々のナンセンスを吐き出します その結果存在しない新しい第三四半期割引ポリシーが会社にあると断言するチャットボットが 00:01:53.540 --> 00:01:57.620 出来上がります チャットボットが意識を持ったわけではなく間違ったデータを取得しただけです 00:01:57.620 --> 00:02:05.080 Azure iStudioとAzure iFoundryはどちらもこのパターンに基づいており 言語画像音声さらにはビデオ検索などあらゆる種類のモダリティをサポートしています 00:02:05.080 --> 00:02:10.360 しかし落とし穴はラグの性能はデータの質に左右されるということです ほとんどのチームが見落としている重要な点があります 00:02:10.360 --> 00:02:16.740 一つの検索方法をプラグインするだけで良いというわけではありません 結果を安定させたい場合はキーワード検索とベクトル検索を組み合わせたハイブリッド検索に 00:02:16.740 --> 00:02:23.020 Azure ai検索に組み込まれている意味的再ランキング機能を追加する必要があります これによりシステムは文字通りのキーワードヒットと意味的な意味のバランスを取り 00:02:23.020 --> 00:02:30.060 適切なコンテキストが上位に表示されるように結果を並べ替えることができます これをマルチモーダル設定に組み込むとモデルは突然コンプライアンスポリシーを何もない 00:02:30.060 --> 00:02:37.340 ところから作り出すのではなく歪んだスキャンやぼやけた画像でも耐えられるようになります 次になぜ多くのロールアウトが失敗に終わるのかについて話しましょう 00:02:37.340 --> 00:02:47.260 企業は初日から洗練された結果を期待しますが評価ループの予算は組んでいません バックグラウンドで実行されている妥当性関連性一貫性のチェックがないとユーザーがすでに損を 00:02:47.260 --> 00:02:54.660 するまでドリフトに気づきません多くの初期展開はまさにこの理由ですぐに失敗します 出力は正しく聞こえますが誰もソースの真実と照らし合わせて検証していません 00:02:54.660 --> 00:03:02.940 考えてみてください監視なしで新しいデータベースをデプロイすることはありません しかしマルチモーダル ai では経営陣はそれをプラグ&プレイの魔法の箱のように本番環境に放り込みます 00:03:02.940 --> 00:03:08.440 必ずしも失敗に終わる必要はありません カーバナはこの点を証明するファウンドリの顧客事例の一つです 00:03:08.440 --> 00:03:15.120 彼らは検索の調整エージェントの適切な基盤構築そして可観測性への投資によって セルフサービス ai を実際に役立つものにしました 00:03:15.120 --> 00:03:24.840 これにより単なるおもちゃのボットになりかねなかったものが顧客が信頼できるもの へと変わりましたでは基盤構築や評価を行わずに汎用チャットボットをサポートページに設置した企業に目を 00:03:24.840 --> 00:03:31.320 向けてみましょうその結果はご存知の通りです 保証請求が誤って販売リードとして処理されサポート級が膨れ上がり信頼性は地に落ちました 00:03:31.320 --> 00:03:38.920 同じアジュールスタックなのに結果は正反対です つまり結論はこうですマルチモーダルが崩壊するのは ai が賢くないからではありません 00:03:38.920 --> 00:03:46.300 データが準備インデックスかまたは監視されていないからです 検索システムに不要なデータを入力し評価を怠れば信頼は失われるでしょう 00:03:46.300 --> 00:03:55.180 しかしハイブリッド検索セマンティック再ランキングおよび継続的な評価実行により 請求書契約書画像さらには粗雑な音声メモを処理して空想ではなく現実に基づいた 00:03:55.180 --> 00:04:04.340 回答を得ることができますそして基盤が整ったら別のリスクが明らかになります データパイプラインがクリーンであってもそれを駆動するシステムが暴走する可能性があるからです 00:04:04.340 --> 00:04:12.000 ここで問題が変わりますこれらすべてを調整するエージェントは実際にビジネスに役立って いるのでしょうかそれとも単に it 予算を静かに燃やす燃料に変えているだけなのでしょうか 00:04:12.000 --> 00:04:21.060 役に立つエージェントかそれとも高価な分鎮かエージェントはモデルデータトリガーおよび アクションを調整します自動化されたワークフローの交通整理係と考えてください 00:04:21.060 --> 00:04:26.620 すべてをスムーズに誘導することもあれば3台のダンプカーとピエロの車を合図して 昼食のために立ち去ることもあります 00:04:26.620 --> 00:04:35.500 クリーンな定義と混沌とした現実の間のギャップがほとんどのチームが脱落する場所です 紙の上ではエージェントは素晴らしいものに見えます指示を与えデータとアプリを指定すれば 00:04:35.500 --> 00:04:44.260 プロセスを実行し回答を取得しワークフローを開始するはずです しかしこれは完璧な同僚ではありません午前2時に繰り返し発生する問題を解決する可能性もあれば 00:04:44.260 --> 00:04:49.840 エラーログを読み間違えたために100件の架空のチケットで9を埋め尽くす可能性もあります サービスなうないでこれを想像してみてください 00:04:49.840 --> 00:04:58.800 厳密に範囲を設定すると ai は実際の問題に対してのみ実際のチケットを作成し人間の時間を節約します 自由にさせておくと問題のないハードウェアの重大なプリンター障害に関する偽のアラートで 00:04:58.800 --> 00:05:03.060 ヘルプデスクを埋め尽くしてしまう可能性があります この生産成功上を cio に説明してみてください 00:05:03.060 --> 00:05:07.000 多くの人が見落としている違いは次の通りです コパイロットとエージェントは同じではありません 00:05:07.000 --> 00:05:11.920 コパイロットは基本的にプロンプトバディーです あなたが質問するとそれが答えあなたはコントロールを維持します 00:05:11.920 --> 00:05:21.220 一方エージェントはあなたを待たずに物事を決定します 結果が意味をなさない場合でも曖昧な指示に文字通り従いますその時自動化は実際の時間を節約するか 00:05:21.220 --> 00:05:28.520 あなたが片付けるのに2倍の時間を費やす混乱に陥るかのどちらかです 実のところ多くのチームはエージェントに選挙公約のような職務記述書を渡しています 00:05:28.520 --> 00:05:34.480 プロセスの最適化洞察の提供人々の支援おめでとうございます 基本的にボットに好き勝手にやらせたことになります 00:05:34.480 --> 00:05:42.220 スコープのないエージェントは礼儀正しく自分の役割を全うしません 暴れ回ります解決すべき問題を作り出しますレコードを重複させます無限ループします 00:05:42.220 --> 00:05:47.480 そして経営陣はなぜ華やかなデモが本番環境での苦痛になったのか不思議に思います ここで誤解を解いておきましょう 00:05:47.480 --> 00:05:51.920 ほとんどの組織が最初の2ヶ月で失敗するわけではありません それは調査で示されていません 00:05:51.920 --> 00:06:00.320 実際に起こることはそしてすぐに起こることは多くの組織がエージェントのスコープを厳密に設定せず 検証手順を追加せずテレメトリを計測しなかったために早い段階で障害にぶつかることです 00:06:00.320 --> 00:06:08.020 これらのガードレールがなければあなたのピカピカの新しいツールは管理者権限を持つ無謀なインターンにすぎません そしてここでマイクロソフトスタックが実際に必要な要素を提供します 00:06:08.020 --> 00:06:14.300 コパイロットスタジオは開発者がエージェントの動作を設計しフロー プロンプトイベントトリガーを考えるローコードスポットです 00:06:14.300 --> 00:06:20.180 iFoundaryのエージェントサービスはこれらのエージェントをか観測性を備えた本番環境に 導入するためのエンタープライズスキャホールディングです 00:06:20.180 --> 00:06:27.540 エージェントサービスは監視ログメトリックを追加する場所です マイクロソフトはテストされていないエージェントを実環境で信頼するとどうなるかを知っているため 00:06:27.540 --> 00:06:34.580 エージェントサービスは人間の監視が組み込まれた自動化向けに意図的に範囲が設定されています ではエージェントが実際に役立つかどうかをどのように判断すれば良いでしょうか 00:06:34.580 --> 00:06:40.660 簡単なリトマスチェックリストで確認してみましょう 1つ目は人件費を削減できるかそれともスタッフをデバッグ作業に巻き込むかです 00:06:40.660 --> 00:06:47.160 2つ目は現実性流暢さ一貫性などのメトリックを収集しているかそれとも単に綺麗なマーケティング ダッシュボードを眺めているだけかです 00:06:47.160 --> 00:06:52.320 3つ目はユーザーが苦情を申し立て始める前にドリフトを検出できるようにテレメトリが実装されている かです 00:06:52.320 --> 00:06:57.420 これらのいずれかに間違って答えた場合インテリジェントエージェントではありません 高価なスクリーンセーバーです 00:06:57.420 --> 00:07:05.920 解決策はazure ifoundryの可観測性機能と組み込みの評価ツールを使用することです これらはオプションの追加機能ではありませんこれらは根拠関連性一貫性 00:07:05.920 --> 00:07:13.080 及び情報源への真実性を測定するための文書化された方法です これらがなければエージェントが賢いのかそれとも丁寧な口調ででっち上げているだけなのかを推測するしかありません 00:07:13.080 --> 00:07:19.200 これらがあれば出力が逸脱した時に自信を持って介入し微調整することができます つまりエージェントはゲームチェンジャーになり得るのです 00:07:19.200 --> 00:07:26.800 スコープが間違っているとエージェントは節約するよりも多くの時間を浪費する カオス増幅機になりますスコープが適切で明確なジョブ境界実際のテレメトリ根拠のある回答があれば 00:07:26.800 --> 00:07:33.320 人間がより価値の高い作業に集中している間エージェントはタスクを処理できます そしてそのバランスが適切だと思ったまさにその時話はまた変わります 00:07:33.320 --> 00:07:42.160 マイクロソフトはすでに自立型エージェントつまり行動する前にあなたを待たないボットを推進しています これは役に立つか分鎮になるかという問題から全く別のカテゴリーにリスクを置きます 00:07:42.160 --> 00:07:51.340 なぜなら今や誰も見ていない時でも実行されるシステムについて話しているからです 自立型エージェントの罠自立型エージェントは古代広告が危険なものに変わる場所です 00:07:51.340 --> 00:07:58.640 紙の上ではそれらは夢です ai に任せて面倒な作業を自動化し午前2時にベッドから這い出してチケットの給を処理するのをやめましょう 00:07:58.640 --> 00:08:03.240 役員会議では素晴らしい話に聞こえます 落とし穴は単純です彼らは許可を待ってくれません 00:08:03.240 --> 00:08:09.500 コパイロットはあなたのために一時停止しますが自立エージェントはそうではありません そして彼らが誤った判断を下すと損害は瞬時に発生しテナント全体に広がります 00:08:09.500 --> 00:08:16.860 コンセプトは簡単ですコパイロットは反応的です エージェントは能動的です誰かがプロンプトを入力するまで静かに座っている代わりにエージェントの範囲を指定して 00:08:16.860 --> 00:08:20.660 サービスの健全性を監視したりセキュリティシグナルを処理したり ワークフローを自動的に実行したりします 00:08:20.660 --> 00:08:25.880 マイクロソフトはこれを効率性人的無駄の削減 検出の迅速化運用のスムーズ化として売り込んでいます 00:08:25.880 --> 00:08:32.160 約束は本物ですが重要な背景があります 今日のコパイロットスタジオの自立エージェントはまだプレビューです 00:08:32.160 --> 00:08:36.380 プレビューは壊れているという意味ではありませんが 混沌とした現実世界でテストされていないことを意味します 00:08:36.380 --> 00:08:42.380 そしてマイクロソフトでさえそれらを広く展開することを検討する前に ナイフサイクルガバナンスガードレールとコパイロットコンソールシステムを導入する必要があると述べています 00:08:42.380 --> 00:08:48.620 現実的なリスクを検討してください 自立型ヘルプデスクエージェントを構築しログイン以上に対応する権限を与えたとします 00:08:48.620 --> 00:08:53.720 5人のユーザーによるデモでは完璧に動作します アラートが発砲されアカウントが管理されます 00:08:53.720 --> 00:09:00.320 しかし本番環境でノイズの多い入力が発生すると待機する代わりに 誤検知に基づいて数百のアカウントを一括リセットし始めます 00:09:00.320 --> 00:09:06.720 これは架空の障害ではなく現実的には月末の業務を停止させる可能性があります これは sf ではありません 00:09:06.720 --> 00:09:12.960 スコープ設定を怠るとこのような失敗モードに陥る可能性があります 解決策はテクノロジーを捨てることではなくまずセーフティネットを構築することです 00:09:12.960 --> 00:09:17.320 では生存チェックリストとは何でしょうか 派手な自動化を行う前に必ず行うべき3つのことがあります 00:09:17.320 --> 00:09:22.580 一つ目は id とアクセスのスコープ設定です エージェントには最小限の権限のみを与え包括的な管理者ロールは与えません 00:09:22.580 --> 00:09:26.880 二つ目はログ記録とロールバックです 全てのアクションは監査可能な痕跡を残す必要があります 00:09:26.880 --> 00:09:30.600 またエージェントが誤作動を起こした場合に備えて重大なアクションには元に戻すパスが必要です 00:09:30.600 --> 00:09:36.740 三つ目はコンテンツと動作のフィルターです マイクロソフトは azure ai のコンテンツセーフティーとナレッジ構成でこの点を強調しています 00:09:36.740 --> 00:09:45.300 熱心なボットが不適切な回答を生成したりスクリプトから逸脱したりするのを防ぐフィルター これらを最初に実装しないとエージェントの賢さが勢いを添いでしまい役に立つどころか逆効果になります 00:09:45.300 --> 00:09:54.680 倫理レイヤーではこの点がさらに重要になります 人事担当者が従業員を自動的にリスクが高いと判断するあるいは財務担当者が不正行為とご分類したサプライヤーへの支払いを保留するといった状況を想像してみてください 00:09:54.680 --> 00:10:04.640 これらは無害な癖ではなく法的及びコンプライアンス上の問題を引き起こす人的影響の失敗です トレーニングデータやデータ取得におけるバイアスはエンタープライズプレビューで実行しているからといって消えるわけではありません 00:10:04.640 --> 00:10:10.400 フィルターチェックおよび人間のフォールバックがなければ弁護士が絶対に望まない判断を監視されていないアルゴリズムに委ねることになります 00:10:10.400 --> 00:10:19.680 イグナイトでのマイクロソフトのメッセージはこの点について率直でした ガードレールライフサイクル管理モニタリングおよびコパイロット制御システムはあれば良いものではなく必須です 00:10:19.680 --> 00:10:31.380 今日のプレビューは華やかなデモよりもテスターがどこに欠陥があるかを証明することに重点が置かれています ステージテスト承認ワークフロー監査なしで本番環境に移行するとエージェントを実行しているのではなく本番環境でテナントのストレステストを行っていることになります 00:10:31.380 --> 00:10:40.200 そのため可観測性はオプションではありません エージェントが実行するすべてのステップを表示しその出力が根拠に基づき関連性がありポリシーと整合しているかどうかを確認するダッシュボードが必要です 00:10:40.200 --> 00:10:47.140 また人間が関与するオプションも必要です マイクロソフトはこれを隠していません人間がフェールセーフとして機能するパターンを参照しています 00:10:47.140 --> 00:10:53.020 飛行機の自動操縦装置を想像してみてください 非常に便利ですが常に手動オーバーライドが可能なように設計されています 00:10:53.020 --> 00:11:00.620 ボットが最適な着陸地点が湖だと判断した場合着水前に制御を奪いたいと思うでしょう 適切な例えは10代の若者に運転を教えることです 00:11:00.620 --> 00:11:09.680 潜在能力は高くスピードも素晴らしいですが鍵を渡して車道に出て後は運任せにするわけにはいきません 助手席に座り境界線を設け自分で操作できるブレーキを取り付けます 00:11:09.680 --> 00:11:15.320 これがライフサイクルガバナンスの実践です システムが道路から外れないことを確信するまで補助輪を装着するようなものです 00:11:15.320 --> 00:11:20.540 そしてエージェントコパイロットテストしたすべてのワークフローが集まるより大きな工場フロアへと話は移ります 00:11:20.540 --> 00:11:25.680 マイクロソフトはこれをアジュールアイファウンドリーと呼んでおり すべてのツールを備えたワンストップのAI構築スペースです 00:11:25.680 --> 00:11:31.200 これが生産の原動力となるかプロジェクトが自爆する場所となるかは完全にその扱い方次第です 00:11:31.200 --> 00:11:41.340 アジュールアイファウンドリーはあなたの工場あるいは地雷源です アジュールアイファウンドリーはマイクロソフトの新しい主力製品でありいわゆるAIの工場です 00:11:41.340 --> 00:11:45.040 問題は多くのチームがそこに入り イケアのように扱います 00:11:45.040 --> 00:11:52.000 カタログに目を奪われて歩き回り ピカピカの大きな言語モデルをいくつか手に取り コネクタをいくつか放り込み説明書なしで何かを組み立てます 00:11:52.000 --> 00:11:59.120 最終的に出来上がるのはエンタープライズAIシステムではなく 実際のユーザーが乱雑なPDFをドロップしただけで倒れてしまうデモグレードのおもちゃです 00:11:59.120 --> 00:12:03.080 ファウンドリーが実際に提供するものは公式のプレイブックから直接引用したものです 00:12:03.080 --> 00:12:12.200 マイクロソフトオープンAIメタミストラルディープシークなどを含むモデルカタログ 取得拡張生成微調整上流などのカスタマイズオプション 00:12:12.200 --> 00:12:16.440 オーケストレーション用のエージェントサービス 評価とデバッグ用のプロンプトフローなどのツール 00:12:16.440 --> 00:12:22.080 セキュリティベースライン機能 id とアクセス制御コンテンツセーフティフィルター オブザーバビリティダッシュボード 00:12:22.080 --> 00:12:27.760 要するにコパイロットエージェント自立フローを構築し コンプライアンスを維持するために必要なすべてのコンポーネントです 00:12:27.760 --> 00:12:36.040 これがインベントリです問題はツールボックスが空っぽなことではなく 多くの管理者がそれを gpt 4ターボスイッチをオンにして本番環境対応とみなすように扱っていることです 00:12:36.040 --> 00:12:44.280 実際ファウンドリは工場でありハッカソンのおもちゃ箱ではありません つまり適切な人だけが適切なモデルにアクセスできるように id 境界を設定する必要があります 00:12:44.280 --> 00:12:51.820 すべてのパイプラインにコンテンツセーフティを組み込む必要があります オブザーバビリティを使用して回答が根拠に基づいているかモデルが何もないところから会社の 00:12:51.820 --> 00:12:56.900 ポリシーを考案しているかを把握する必要があります そして単に賢そうに聞こえるからといって最大のモデルを選択するのではなく 00:12:56.900 --> 00:13:02.080 ジョブに適切なモデルをマッチングさせる必要があります これらの手順を省略すると裏口から混乱が忍び込んできます 00:13:02.080 --> 00:13:07.680 あるチームがシェアポイントにファウンドリコパイロットを組み込んだところ 制限された人事データが20人のインターンに簡単に公開されてしまったのを見たことがあります 00:13:07.680 --> 00:13:14.160 これは賢いやり方ではなく組み込みのアクセスルールで回避できたはずのコンプライアンス上の大惨事でした 実際の失敗例について話しましょう 00:13:14.160 --> 00:13:21.860 ある組織はかつて製品写真のタグ付けに gpt 4ターボを実行しました ラボではデモを圧倒しました綺麗なスタジオ写真完璧なタグ付け 00:13:21.860 --> 00:13:28.380 みんなが拍手喝采しました しかし本番環境では入力は光沢のある jpegではなく倉庫で撮影されたぼやけた携帯電話の写真でした 00:13:28.380 --> 00:13:34.280 突然 ai はベビーカーをオフィスチェアと誤認識し upc ラベルを偽のシリアル番号に書き換えてしまいました 00:13:34.280 --> 00:13:39.940 信頼が損なわれただけでなくコストも上昇し始めました これは1メッセージあたり0.01ドルの夢物語ではありません 00:13:39.940 --> 00:13:47.640 ファウンドリの料金体系は重量性で使用する特定のサービスに紐づいています すべてのコネクタすべての取得呼び出しすべてのメッセージメーターはテナントに対して課金されます 00:13:47.640 --> 00:13:53.440 各コンポーネントには独自の課金モデルがあります その柔軟性は素晴らしいですが azure料金計算ツールで見積もり 00:13:53.440 --> 00:13:59.200 使用状況を追跡しないと財務チームは予期せぬ請求書に喜ぶことになるでしょう これが課金の落とし穴です 00:13:59.200 --> 00:14:07.080 重量課金は計画監視最適化すれば機能します そうしないとスポーツカーをピザスクーターとして走らせるようなもので効果でうるさくて無意味です 00:14:07.080 --> 00:14:15.420 パワーdiのようなもので素晴らしいデモの後請求額が跳ね上がった経験は誰にでもあるでしょう ファウンドリで同じ状況に陥らないようにしましょう開発者はサンドボックスが宣伝されていると感じられるため 00:14:15.420 --> 00:14:21.060 ファウンドリでプロトタイプを作成するのが好きです そしてサンドボックスではそれは宣伝されていますクリーンなデモデータ混乱なしすぐに驚き 00:14:21.060 --> 00:14:28.940 しかし致命的なのはここですチームは評価パイプラインなしでプロトタイプを本番環境に プッシュします現実性流調査関連性一貫性を評価する評価者をスキップすると 00:14:28.940 --> 00:14:35.100 メクラ目的にデプロイすることになります そしてどうなるでしょうかユーザーは出力の変動に気づき信頼が失われ経営人は資金を削減します 00:14:35.100 --> 00:14:41.580 これはファウンドリの失敗ではなくチームのガバナンスの失敗です 多くのファウンドリプロトタイプが本番稼働前に停滞するのはまさにこの理由からです 00:14:41.580 --> 00:14:48.900 過観測性も品質チェックもテレメトリもありません 答えはプラットフォームにありますアジュールアイファウンドリーの過観測性を初日から活用しましょう 00:14:48.900 --> 00:14:55.900 プロンプとフローを組み込みすべてのテストで組み込みの評価ツールを実行します 本番稼働を検討する前にハイブリッド検索とセマンティックサイランキングを使用したアジュール 00:14:55.900 --> 00:15:01.420 AI検索でシステムを基盤化しましょう マイクロソフトはこれらのツールを付録に隠したわけではなく本番環境の安全性を確保するために文書化しています 00:15:01.420 --> 00:15:08.040 しかし開発者は客中のようにそれらを読み飛ばしてしまうことがあまりにも多いのです チェックポイントの考え方こそが地雷源を避ける方法です 00:15:08.040 --> 00:15:13.880 ファウンドリを工場のように扱いガバナンスを最初のステップとし条件付きアクセスなどのコンプライアンスポリシーを組み込み 00:15:13.880 --> 00:15:20.780 過観測性パイプラインを最初から稼働させましょう そしてIDスコープとコンテンツの安全性は後から追加するのではなく部品表に含まれています 00:15:20.780 --> 00:15:27.720 ガバナンスを怠ると悪い回答以上のリスクを負うことになります ガバナンスがなければマルチモーダルボットは外部ユーザーに人事部の給与を公開したり 00:15:27.720 --> 00:15:34.660 請求書に架空のポリシー番号を付けたりする可能性があります これは単にAIが壊れているというだけでなくコンプライアンス部門が説明したくない見出しのネタになります 00:15:34.660 --> 00:15:41.460 そして次の障害は技術的なものではないためここで注目が集まります それはAIが責任あるものであるかどうかです 00:15:41.460 --> 00:15:48.380 誰もが基調講演のスライドにこれらの言葉を入れるのが好きですが実際には監査 フィルターコンプライアンスそしてローンチ前に行う膨大な選択の問題です 00:15:48.380 --> 00:15:55.240 そしてここで本当の頭痛が始まります m365.showニュースレターに登録してフォローすると率直な解決策が得られます 00:15:55.240 --> 00:16:01.460 また m365showのリンクとインページをフォローすると本番環境でハウンドリをテストし何が問題になるかを見た mvp とのライブストリームをご覧いただけます 00:16:01.460 --> 00:16:09.820 責任あるAIか責任ある頭痛か誰もが基調講演に責任あるAIを入れるのが好きです 公平性や透明性などのバズワードの隣に置けば見栄えがします 00:16:09.820 --> 00:16:15.780 しかし現場ではそれは刺激的な哲学ではありません それはイノベーションというよりはサーバーのメンテナンスのように感じられる構成 00:16:15.780 --> 00:16:20.740 監査フィルターガバナンスの手順です 責任あるAIはシートベルトであってスポーツカーではありません 00:16:20.740 --> 00:16:29.360 一度でもこれを怠るとすぐにクラッシュします マイクロソフトは倫理とセキュリティについて最初に語りますがこれを本番環境に展開する管理者にとってはそれは実用的なガードレールを意味します 00:16:29.360 --> 00:16:37.600 プレッシャーに屈しないアクセスポリシー有害なプロンプトを実際にブロックするフィルター カフェインと召喚状を持った規制当局を満足させるのに十分な詳細なログが必要です 00:16:37.600 --> 00:16:45.400 それは華やかな仕事ではありません それはHRの副操縦士を財務データから隔離しチームのスポットがシェアポイントの秘密に忍び込まないようにスコープルールを設定し 00:16:45.400 --> 00:16:53.040 応答がどのように形成されたかを正確に証明できるようにログにタグ付けすることです これを正しく行えば責任あるは企業のスローガンではなく生き残りです 00:16:53.040 --> 00:17:01.520 これを怠った醜いバージョンはテナントスコープなしでボットをHRリポジトリに直接接続することです ユーザーが保険給付について質問します 00:17:01.520 --> 00:17:09.920 ボットが従業員の給与バンドをチャットに公開するとプライバシー侵害指揮低下 そして規制当局の監視といった事態に陥ります 00:17:09.920 --> 00:17:13.800 導入を阻害する最も早い方法は ux の悪さではなく機密データの漏洩です 00:17:13.800 --> 00:17:18.040 ではどうすればこの混乱を防げるのでしょうか まずはアジュール ai のコンテンツセーフティーから始めましょう 00:17:18.040 --> 00:17:24.840 暴力歪説不快なプロンプトやレスポンスがユーザーに漏れる前にフィルタリングするように設計されています しかしこれは基本的な衛生管理です 00:17:24.840 --> 00:17:34.100 ファウンドリとコパイロットスタジオは次のレイヤーを処理する評価パイプラインを構築します 妥当性チェック関連性スコアリング透明性ダッシュボード説明可能性です 00:17:34.100 --> 00:17:40.160 簡単に言うと指揮位置を調整したり入力と出力の両方をフィルタリングしたり ボットに作業内容を表示させたりできます 00:17:40.160 --> 00:17:45.140 これらがなければ ai が何を吐き出すかは運任せです そしてリソースの現実について 00:17:45.140 --> 00:17:49.940 マイクロソフトはこれに力を入れています セキュリティに専念するフルタイム相当のエンジニアが34,000人 00:17:49.940 --> 00:17:54.540 さらにセキュリティに関する深い専門知識を持つパートナーが15,000人います それは要塞です 00:17:54.540 --> 00:17:59.560 しかし油断してはいけませんこれらのエンジニアは誰もテナント内にいてアクセスルールを 作成しているわけではありません 00:17:59.560 --> 00:18:06.480 マイクロソフトはガードレールを提供しますが id のロックダウンデータ分離の設定 暗号化の適用ポリシーの構成は依然としてあなたの仕事です 00:18:06.480 --> 00:18:12.000 スコープがずさんであれば侵害の責任は依然としてあなたにあります 本当の解決策はライフサイクルガバナンスです 00:18:12.000 --> 00:18:20.360 マイクロソフト自身が推奨するレシピと考えてください テスト承認リリース監査反復各サイクルにチェックポイントがあれば 00:18:20.360 --> 00:18:26.120 ドリフトがヘッドラインのネタになる前に発見し続けることができます 一度出荷して放置するチームは必ず破綻します 00:18:26.120 --> 00:18:31.440 モデルは進化しプロンプトは変化し出力は迷走します ガバナンスは官僚主義ではありません 00:18:31.440 --> 00:18:38.420 それは全員が寝ている間にインターンボットがチームでポリシーを作成するのを防ぐ方法です 一部の管理者は責任あることは単に遅くなることを意味すると不満を言います 00:18:38.420 --> 00:18:43.460 それは間違った見方です 責任を持つことは速度を低下させるのではなく速度があなたを破滅させないようにします 00:18:43.460 --> 00:18:49.240 優れたガバナンスとは実際に監査を乗り越えプロジェクトを継続できることを意味します それを無視すれば崖から飛び降りるようなものです 00:18:49.240 --> 00:18:53.540 制御のないスピードでは記録は一種類しか得られません 事後検証までの最短時間です 00:18:53.540 --> 00:18:59.280 山道のヘアピンカーブを運転することを想像してみてください ガードレールを呪うのではなく道路が200フィートも下がった時に感謝します 00:18:59.280 --> 00:19:05.500 責任あるAIも同じです スコープポリシーフィルターログはスピードを止めるのではなくあなたの車が夜のニュースにならないようにします 00:19:05.500 --> 00:19:11.920 要するにマイクロソフトはあなたに強力な力を与えてくれました コンテンツの安全性評価パイプラインセキュリティフレームワーク 00:19:11.920 --> 00:19:19.040 SDKガードレールですがテナントの範囲を設定しアクセスを構成しそれらのループを生産サイクルに 組み込むのは依然としてあなたの仕事です 00:19:19.040 --> 00:19:26.820 それを行えばコンプライアンスに耐え崩壊しないAIが実現します それを無視すれば単なる障害リスクではなくキャリアが危うくなります 00:19:26.820 --> 00:19:32.300 責任あるAIは遅いものではありません 責任あるAIは生き残れるものであり生き残れるかどうかが真の試練です 00:19:32.300 --> 00:19:38.300 なぜなら次に重要なのは機能ではなくこのプラットフォームをプラグ&プレイのように扱うか ガバナンスを最優先とするインフラストラクチャとして尊重するかだからです 00:19:38.300 --> 00:19:46.420 この違いが生き残るか燃え尽きるかを決定づけます 結論はこうです落とし穴はファウンドリアコパイロットスタジオではなくそれらをプラグ&プレイだと考えることです 00:19:46.420 --> 00:19:50.700 覚えておくべきことは単純です ガバナンスが最優先実験が2番目本番環境が最後です 00:19:50.700 --> 00:19:57.300 アイデンティティとか観測性を軽視すると大きなリスクを負うことになります ツールは揃っていますがプロトタイプを実際の本番環境に移行させるのはガバナンスだけです 00:19:57.300 --> 00:20:02.900 ですからテナントを実際に存続させるための直接的な解決策が欲しい場合は ポッドキャストを購読してレビューを残してください 00:20:02.900 --> 00:20:08.680 私は毎日何時間もこれに時間を費やしておりあなたのサポートは本当に助かります ツールは変化しますが生き残るための戦術は生き残ります