落とし穴とリーディングプラクティス: Conv カタログアイテムと LLM トピック (仮想エージェントの Now Assist と共に) (翻訳)

[naoto kadowaki]

本稿はこちらの記事の翻訳です。最新の情報は元となる記事をご覧ください。
このトピックの一部は機械翻訳で処理されている場合があります。

はじめに

ServiceNow の AI センターオブエクセレンスチームへようこそ! 私たちは、専任の AI ストラテジストとアーキテクトのチームであり、顧客向けの AI ソリューションの実装と採用を促進することに重点を置いています。数多くの実践的なカスタマーエンゲージメントを通じて、ServiceNow コミュニティと共有できることを嬉しく思います。この記事は、一般的なお客様の問題領域のサブセットを概説し、当社の経験に基づいて解決策の検討事項を提供するシリーズの第 1 回です。ここでは、仮想エージェントの Now Assist を使用した会話型カタログアイテムと LLM トピックに焦点を当てます。これは完全なガイドではなく、何が効果的で、何が効果的でないか、そして何に注意すべきかなど、実際の話を少しだけまとめたものです。

実装に関する一般的な課題

AI ソリューションの導入は複雑な道のりであり、多くの顧客がその過程で同様のハードルに遭遇します。ここでは、よく目にする一般的な実装上の課題を大きく分けて 3 つのカテゴリに示します。

1. 製品の「Configurable Knobs (構成可能なノブ)」についての理解: お客様は、ServiceNow 製品でできることとできないことを十分に理解するのに苦労することがよくあります。未知の構成可能な機能ナゲット (「ノブ」) が多数あります。
2. アーキテクチャに関する考慮事項: 多くの顧客は何年も前からこのプラットフォームを使用しており、何百ものカタログアイテムで技術的負債を蓄積しています。顧客は、既存の構成を操作し、情報に基づいた最適なアプローチについて意思決定を行うためのガイダンスを求めます。たとえば、会話型カタログアイテムと LLM トピックを使用する場合、およびプラットフォーム/ポータルでフォームベースのカタログとして保持する場合などです。
3. AI の一般的な理解: AI は急速に進化しており、それについていくのは難しい場合があります。私たちの多くは決定論的なワークフローに慣れており、AI の確率的な性質に適応するのが難しいと感じています。

ソリューションの考慮事項

このセクションでは、上記の各課題に対するソリューションに関する考慮事項のサブセットの概要を説明します。

1. 製品の「Configurable Knobs (構成可能なノブ)」についての理解

a. インテントの理解と曖昧さ回避

課題:仮想エージェントがユーザーの意図を理解するのに苦労し、誤ったカタログアイテムやLLMトピックが表示されます。

ソリューションの考慮事項:

• アイテムと LLM の説明:インテントの理解を向上させる上で最も重要な要素は、アイテムまたは LLM の名前と説明の明確さです。IT 部門が LLM を混乱させる可能性のある専門用語を追加する可能性があるため、ビジネスユーザーまたはチャンピオンに働きかけて、これらの説明を強化してください。
• プロンプトの例:説明にプロンプトの例をいくつか含めると、LLM が特定のトピックをトリガーするタイミングを理解するのに役立ちます。生成 AI 以前の NLU の世界のように、考えられるすべてのインテントを追加しないように注意してください。
• UAT 前の計画:ユーザー受け入れテスト (UAT) の前に説明を計画し、改良して、後で問題が発生しないようにします。
• LLM の選択:Xanadu パッチ 7 以降では、NowLLM または Azure OpenAI を選択できます。一部の顧客では、Azure OpenAI が意図の理解と曖昧さの解消によりパフォーマンスが向上していることがわかりました。ただし、お使いの環境で比較を行い、より適した適切な LLM を選択する必要があります。

例： 

1. ある顧客には、「従業員ルックアップに使用」などのあいまいな説明が付いた「従業員ルックアップ」の LLM トピックがありました。実際には、ユーザーは仮想エージェントに「James Henning は誰ですか?」または「James は誰に報告しますか?」と尋ねます。LLM はこれらのクエリを照合するのに苦労しました。 「このトピックは、従業員またはユーザーを検索し、名前、ロール、マネージャー、部門、場所などの詳細を提供するために使用されます。サンプルプロンプトは次のとおりです。 James Henning とは? ジェームズのコストセンターとは何ですか? ジェームズは誰に報告しますか?」

2. 顧客には「訪問者アクセス」のカタログアイテムがありました。カタログの説明は「物理的な GRE アクセスを要求するには、このフォームに入力してください」でした。 実際には、ユーザーは仮想エージェントに「面接候補者に建物へのアクセス権を付与したい」と尋ねます。LLM は、カタログアイテムの説明に基づいてこのクエリを照合するのに苦労する可能性があります。LLM は GRE が何であるかを知らないかもしれません。より適切な説明は、「このカタログアイテムを使用して、訪問者、クライアント、面接候補者、またはパートナーに対して、GREなどの物理的な建物や場所へのアクセスを要求します」です。

3. 顧客が「DL にユーザーを追加」のカタログアイテムを持っていました。カタログの説明は「DL 要求」でした。実際には、ユーザーは仮想エージェントに「Sheela をグループに追加したい」と尋ねます。LLM は、カタログアイテムの説明に基づいてこのクエリを照合するのに苦労する可能性があります。さらに、LLM は必ずしも DL = 配布リストを理解しているわけではありません。この例では、LLM はこれをデータレイクと混同しています。

より適切な説明は、「このカタログアイテムを使用して、ユーザーを配布リスト (DL) またはグループに追加します」です。

b. 会話の途中での切り替え

課題: 仮想エージェントは、コンテキストを切り替えたり、会話内のさまざまな要求間を移行したりできるほどスマートではありません。たとえば、仮想エージェントは、新しいラップトップ要求を会話形式で入力するのを支援しており、同じ新規雇用者のために携帯電話で簡単な質問をします。そして、これはLLMを混乱させます。

ソリューション:トピックの途中での切り替えにより、同じ仮想エージェント会話で新しいクエリが行われるたびに、分かりやすい言葉を使用して要求を簡単に切り替えることができます。トピックの途中での切り替えを有効にするシステムプロパティは 2 つあります。

• com.glide.cs.gen_ai.enable_mid_topic_ai_search (「maint」ロールが必要なため、変更するには HI サポートケースを開く必要があります。)
• sn_nowassist_va.enable_mid_topic_ai_search_catalog_result

 c. チャネル (メール/電話と、ポータル、MS Teams、または Slack の仮想エージェント)

課題:

• 従来のメール/電話から仮想エージェントにユーザーを誘導するにはどうすればよいですか?   
• 仮想エージェントにアクセスするのはポータルで行うべきですか、それとも MS Teams や Slack などの既存のエンタープライズチャネルを介してアクセスする必要がありますか?

ソリューションの考慮事項:

• 一部のお客様は、ユーザーに仮想エージェントの使用を促す自動IVRとメール応答を追加しました。これには組織的な変更管理が必要であり、ユーザーが仮想エージェントエクスペリエンスを気に入り始めるにつれて、移行は時間の経過とともに起こります。OCM に関する今後の記事にご期待ください。
• 仮想エージェントオプション (ポータル、MS Teams、Slack) を決定するときは、ユーザーがいる場所 (MS Teams や Slack など) とユーザーエクスペリエンスの間のトレードオフを考慮してください。MS Teams または Slack のエクスペリエンスは、ポータルの仮想エージェントとまだ一致しない可能性があることに注意してください。ただし、これらのチャネル間の同等性を実現することは、2025年上半期のロードマップ(将来を見据えたアイテムのセーフハーバー)に含まれています。

推奨事項:これをどちらか一方の決定にするのではなく、ポータルと MS Teams または Slack の両方で仮想エージェントを提供します。これにより、ユーザーは好みのエクスペリエンスを選択できるようになり、全体的な満足度が向上します。

2. アーキテクチャに関する考慮事項

a. 会話型カタログアイテムと LLM トピックとカタログアイテムフォーム

課題: 多くの場合、顧客は何百ものカタログアイテムを持っていますが、その多くは会話型ではない可能性があります。どのようにジャーニーを計画し、カタログアイテムや LLM トピックを使用するか、またはフォームベースのカタログアイテムのままにしておくかを決定する必要がありますか?

ソリューションの考慮事項: まず、カタログアイテムを会話型にする方法に関するこの優れたガイダンスを読むことをお勧めします。これは大変な労力のように思えるかもしれませんが、代わりに LLM トピックを構築するべきだと考えているかもしれません。カタログアイテムを会話型にすることと LLM トピックを構築することのトレードオフを理解することが重要です。既存のカタログアイテムを会話型にすると、カタログアイテムを維持するだけで済むため、継続的なメンテナンスが削減されます。一方、LLM トピックでは、ユーザーエクスペリエンスを向上させるための詳細制御が提供されます。

推奨事項:ユースケースベースの戦略を採用します。

• 最も頻度が高い/影響度が高い (上位 2 〜 3 件): 最も頻度が高く影響度の高いカタログアイテムに LLM トピックを使用して、ユーザーエクスペリエンスを向上させます。
• 大多数: カタログアイテムの大部分を会話型にして、メンテナンスを合理化し、使いやすさを向上させます。これは旅であることを忘れないでください。1 日目にすべてのカタログアイテムを会話型にする必要はありません。 最も影響力のあるものから始めて、時間をかけて段階的に構築してください。
• 複雑なフォームとビジネスロジック: 複雑なフォームとビジネスロジックはフォームベースのカタログアイテムとして保持します。すべてのカタログアイテムを会話型にする必要はありません。カタログフォームへのリンクを指定するだけです。

この戦略に従うことで、ユーザー エクスペリエンスとメンテナンス作業のバランスを効果的に取ることができます。

b. カタログの分類と構造

課題: 多くの顧客は、分類を通じて網羅的なカタログ構造を構築しています。たとえば、ラップトップ、電話、その他のハードウェア要求ごとに数百の異なるカタログアイテムを含むハードウェア要求のカテゴリがあるとします。ユーザーが慣れ親しんだこの構造をあきらめるべきでしょうか?

ソリューションに関する考慮事項と推奨事項:

ユーザーの好みは異なる可能性があるため、ユーザーエクスペリエンスを優先することが重要です。カタログが適切に整理されている場合は、会話要素と共存させます。ユースケースベースのアプローチをお勧めします。

例: ラップトップタイプごとに数百の異なるカタログアイテムを持つある顧客のために、既存の構造を維持しつつすべてのラップトップ用に新しい LLM トピックも構築しました。このフローは、単一の LLM トピック内のドロップダウンとして対象となるラップトップの選択肢を提供しました。何百ものカタログアイテムすべてを会話型にする必要はありません。会話エクスペリエンス用に LLM トピックを 1 つ作成し、それを適切に整理されたカタログ構造と共存させるだけです。

c. 一般的なリーディングプラクティス

このセクションでは、カタログアイテムを会話型にするための一般的なリーディングプラクティスのいくつかを概説します。

• 会話ラベルの使用:会話ラベルを使用して質問を言い換え、明確さとユーザーの理解を高めます。変数に会話ラベルがある場合、LLM は独自のラベルを作成するのではなく、そのラベルを一貫して表示します。
• UI ポリシー: OnLoad() UI ポリシーを使用する代わりに、質問に直接属性を設定して、属性を必須、表示、読み取り専用にします。初期化されていない変数の OnLoad() 条件を避けるには、[OnLoad] ボックスのチェックを外します。
• 変数を最小化する:変数の数を最小限に抑えて、会話の流れを簡素化し、複雑さを軽減します。
• 会話モードをオフにする:フォーム要求の場合は、[VA で非会話型にする] オプションを選択してインタラクションを簡素化します。
• 明確なコンテキストを確保する:明確な名前、ラベル、ツールヒントを使用して、アイテムのコンテキストを提供し、ユーザーエクスペリエンスを向上させます。可能であれば、頭字語を詳しく説明します。
• 標準の変数タイプを使用する: 一貫性とシンプルさを維持するために、複数選択肢、選択ボックス、1 行テキストなどの標準的な変数タイプに固執します。
• スクリプティングの制限:クライアント側のスクリプティングを減らし、検証に「検証正規表現」を利用して、信頼性とメンテナンスの容易さを確保します。
• 依存関係の簡素化:変数の関係を合理化 (または縮小) して、会話の流れを改善し、潜在的な問題を軽減します。
• テストと改善: 会話型インターフェイスのアイテムを継続的に評価し、ユーザーからのフィードバックに基づいてアイテムを強化します。常にある程度の試行錯誤があります。

3. AI の一般的な理解

a. 通説:LLMはすべてのインタラクションで自分自身を訓練

誤解:ユーザーは、すべてのインタラクションで賛成または反対のフィードバックを提供することで、LLM の継続的な改善に役立つと考えています。ただし、すぐに改善は見られません。

現実:NowLLMは命令を微調整しており、ServiceNowとデータを共有した場合でも、その場で自分自身をトレーニングすることはできません。このプロセスには、GPU のトレーニングなど、より多くの労力とリソースが必要です。

b. レベルセットの期待値:LLM ベースのアプリの評価

私たちの多くは、しばらくの間、AI の確率論的な世界をナビゲートしてきました。私たちは、ChatGPT、Claude、Geminiなどのツールを私生活で経験してきましたが、そのたびに反応が異なる可能性があります。しかし、顧客がビジネス現場でこれらのLLMに高度な不合理な一貫性を期待する頻度は驚くべきことです。完璧よりも価値と進歩を優先することが重要です。幻覚を減らすことは重要ですが、LLM ベースのアプリの評価方法を根本的に変える必要があります。

従来の決定論的ソフトウェアテストは合格か不合格かで動作します。このアプローチは、LLM の性質とうまく一致しません。

LLM ベースのアプリはユーザーの目標の解決に関連性があるかどうかをテストする必要があります。多くの場合、パーセンテージで測定されます。この評価基準の変化は、AI の確率的性質を認め、提供されるソリューションの実際的な有効性に焦点を当てています。

まとめ

この記事が実践的な実装ガイダンスに役立てば幸いです。これは、実装のすべての側面を網羅しているわけではなく、顧客エンゲージメントから得られた学習と洞察のサブセットです。他にご質問がございましたら、お気軽にコメントしていただければ、お答えし、必要に応じてこの記事を更新します。役に立った場合は、フィードバックをお寄せください。今後さらに記事を作成していく予定です。次回は仮想エージェントでの Now Assist を使用した AI 検索に焦点を当てる予定です。どうぞご期待ください。

免責事項

一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。