本ブログは 「Evaluating generative AI performance: When your data is “anything”」の抄訳となります。
オブザーバビリティをすべてのユーザーに解き放つ、という使命のもと、ユーザーがテレメトリデータに関するあらゆることを質問できるよう、私たちは New Relic AI の構築に取り組みました。
New Relic AI は、お客様が自然言語を使用して New Relic データベース(NRDB)と対話できるようにすることで、New Relic クエリ言語(NRQL)の熟練度への依存を減らし、技術スタック全体の分析の合理化を実現します。その他の機能として、ドキュメントとナレッジベースから得られる情報の統合や、システム異常の表面化などがあります。
パフォーマンスの評価
堅牢な評価基準とプロトコルを確立することは、 AI モデルが活躍するビッグ データを扱う上で重要な側面です。数え切れないほど多くの決定を下す必要があるため、それらを体系的かつ大規模に評価することが不可欠です。従来の機械学習 (ML) アルゴリズムの多くは、それぞれのユースケースに対応した、明確かつ確立された評価基準を持っています。たとえば、車両の分類を行う場合は「道路を走る車を正しく識別できたか?」、回帰問題では、「予測した数値と実際の結果はどのくらい離れていたか?」といったものです。
ChatGPT の発表により、OpenAI は生成 AI を使用して達成できることの基準を一段と引き上げました。OpenAI が新たに確立したパフォーマンスは、前例がないほどの飛躍的な進歩であり、既存の機能を強化するだけでなく、まったく新しい可能性を切り開きました。ただし、この新しいテクノロジーには課題があり、その 1 つがパフォーマンスの検証方法です。生成 AI に関しては新しい機能が日々登場していますが、基礎となるタスクを測定するための標準的な評価プロトコルとメトリックはまだ確立されていません。自然言語の出力は厳密に構造化されていないため、これらのプロトコルを策定することは重要な作業になります。私たち New Relic AI 開発チームは、ユーザーに真の価値と心からの信頼を提供するために、この側面に細心の注意を払いました。
先述の通り、New Relic AI の目標は、どんな質問にも答えられるツールであることです。他のビッグデータ プロジェクトと同様に、情報に基づいた設計上の決定を下し、パフォーマンスを最適化するには、その回答の妥当性を評価する必要があります。しかし、何をもって正しい答えが得られていると判断できるのでしょうか。この記事では、この問題に対処するために私たちが講じた対策のいくつかについて説明します。
戦略 1:明確な成功指標を適用できる領域を特定する
自然言語は構造化されておらず、New Relic AI のような生成 AI ベースのシステムは複雑になる可能性がありますが、コンポーネントを細分化することで、明確な成功の尺度を定義できるシステムの部分を特定できます。New Relic AI は、管理可能な独立したコンポーネントによってモジュール化された設計であるため、システム全体をより体系的に評価することが可能です。設計と実装のすべての段階で、測定可能性を常に考慮し、明確な尺度を適用できる領域を特定しました。
例 1:ユーザーリクエストをユースケース別に分類する
特定した領域の 1 つは、ユーザーの質問をさまざまなフローに分類することです。これは各ユーザーのリクエストを処理する最初の段階です。New Relic AI に質問すると、まずその質問が送られるフローが決定されます。New Relic に関する一般的な質問であれば、ドキュメントの検索が必要です。ユーザー個別のシステムに関する質問であれば、NRQL クエリを実行します。または、システム内のエラー概要のリクエストであれば、Lookout サービスを呼び出します。このような「ルーティング」段階には生成 AI が関係していますが、本質的には分類の問題であり、分類には確立された評価指標を使用できます。これは、ソリューションへのアプローチが正しいかどうかを評価する上で、また将来的に新たなフローを追加して New Relic AI の機能を拡張するためにも重要なポイントです。
例 2:NL2NRQLでの構文検証
もう 1 つの例は、自然言語から NRQL への変換(NL2NRQL)です。ここでは、ユーザー入力を自然言語で受け取り、それを NRQL クエリに変換します。New Relic AI は、NR2NRQL を実行し、NRDB に対してクエリを実行し、取得したデータを元に結果を説明することができます。プログラミングのアシスタントとして ChatGPT を使用した経験がある方なら、コードブロックの構造は一見完全でありながらも、一部のキーワードや関数、属性が存在しない、といった現象(ハルシネーション)に遭遇したことががあるかもしれません。NL2NRQL では、このような問題を回避するため、パーサーとコンパイラーで生成された NRQL クエリの構文を評価し、次に NRDB に対して実行して結果が返されることを確認しています。New Relic AI は、リアルタイムで継続的に構文検証を実行し、構文的に正しいクエリのみをユーザーに返します。これにより、システムのこの側面の成功を明確な真偽値として測定できるようになります。これは、私たちが最初から NRQL を中心に開発したいと考えていた理由の 1 つです。
余談ですが、OpenAI は最近、新しいコードインタープリタープラグインで同様のアプローチを採用し、提案されたコードを実行してその正確性を確認しています。
戦略2: 検索強化生成(RAG)とタスクの再構築によるハルシネーション対策
私たちのように生成 AI に関する製品に携わる技術者や、その活用に関心を持つ友人にとって、「どのようにハルシネーションの対策をするか」は共通の懸念事項でした。
ハルシネーションは、日本語に直訳すると幻覚症状を意味しますが、生成 AI の文脈においては、大規模言語モデルの既知の落とし穴とされており、事実ではないことをあたかも事実であるように説明する文章を作り、自信満々に述べてしまう傾向のことを指します。先のプログラミングアシスタントの構文ハルシネーションの例が典型的なものですが、基本的に生成 AI の応答は、正確かどうかに関係なく、常に自信を持って提示されます。さらに、OpenAI のモデルを扱う上では、どの時点までの情報を学習に使用したかで組み込みの知識が制限される、知識カットオフについても留意が必要です。
New Relic AI (現在は完全に GPT-4 で動作) の場合、この問題は New Relic に関する一般的な質問や知識ベースの質問に答えるときに特に重要です。私たちは、すべての回答において 100% 正確で最新の情報を提供することを目指しています。
RAGの使用
検索拡張生成(RAG)は、生成 AI のハルシネーションに対処するために確立された一般的な手法です。外部データベースから関連情報を取得し、それを大規模言語モデルのプロンプトに組み込むというものです。この背後にある理由は単純です。よくあるケースでは、モデルに組み込まれた知識がユースケースに対して正確かどうか不明な場合、あるいは最新の事実が含まれていないことがわかっている場合は、外部ソースからモデルに事実を持ち込むことができます。New Relic AI では、Pinecone ベクトルデータベースに保存されたドキュメントを外部ソースとして使用しています。
タスクの再構築
RAGを使用して関連するコンテキストをモデルに取り込んだら、モデルが組み込みの知識から応答するのではなく、実際にそのコンテキストに正しく依存するよう調整する必要があります。つまり、質問がNew Relicの一般的な知識に関連する場合に、ユーザーの質問をモデルに提示する方法を調整する必要がありました。
これを説明するために、例を使用してみましょう。具体的な指示のあるタスクが与えられたとします。最初のシナリオでは、「米国の第 3 代大統領は誰ですか?」のような質問に答えるように求められます。この言い回しでは、事前の知識を使って答えることが期待されていると想定するのが妥当です。次に、2 番目のシナリオでは、同じ質問がされるものの、役に立つかもしれない補足テキストも同時に与えられます。これが RAG の例で、回答の正確さを最大化することが目標であれば、このアプローチの方がおそらくより良い結果が得られます。最後に、これをさらに一歩進めてみましょう。3 番目のシナリオの指示は、「ここにテキストがあります。あなたのタスクは、質問『米国の第 3 代大統領は誰ですか?』の答えがその中にあるかどうかを判断し、ある場合は説明を提供することです。」であると考えてください。この 3 番目の設定は、単なる知識の想起ではなくテキストの理解に重点が置かれているため、最初の設定とはまったく異なるタスクです。
知識の正確さに起因するハルシネーションは生成 AI の潜在的な落とし穴ですが、一方で要約とテキスト理解は生成 AI の強みであるため、3 番目の設定の概念に従ってプロンプトを作成します。
戦略 3:透明性と明確なコミュニケーションを通じた信頼性の向上
New Relic AI の信頼性を高めるために行っているもう 1 つのステップは、ユーザーが回答を自分で評価するために必要な情報をユーザーに提供することです。コンテキストなしで回答を提供すると、ユーザーは回答の妥当性に確信が持てなくなる可能性があります。これに対処するために、私たちはプロセス全体を通して明確なコミュニケーションを重視し、Q&A フローのさまざまな段階で中間ステップを追加しています。
たとえば、「今日はトランザクションがいくつありましたか?」のように、ユーザーが自分のシステムに関するデータについて質問すると、New Relic AI はまず、その質問を解釈して NRQL クエリに変換することをユーザーに通知します。これにより、ユーザーは NRQL を使用して質問に答えてようとしていることを認識し、このアプローチが理にかなっているかどうかを評価できます。次に、AI は NRQL クエリ (例:SELECT count(*) FROM Transaction SINCE TODAY
) を生成します。生成されたクエリを元に NerdGraph(当社のGraphQL API)を実行して情報の可視化方法を決定し、最終的に NRDB から返されたクエリ結果に基づいた回答を提示します (例:"16,443,606,861")。AI が最終的な回答を導き出すまでに使用された情報を共有することで、ユーザーは応答をよりよく理解し、それが信頼に足るものであると確認することができます。NRQL に精通していなくても、クエリ構文とキーワードは多くの場合一目瞭然であるため、直感的に理解しやすいものになります。
同様に、AI が New Relic に関する一般的な知識に質問に答えるときは、まずドキュメントを検索することをユーザーに通知し、回答とともに参照したドキュメントへのリンクを提供します。
フィードバックに耳を傾ける
New Relic の機能に対する最終的な評価はユーザーの皆様にお任せしており、私たちは継続的にフィードバックを収集しています。貴重な洞察を提供してくださった社内外のすべてのユーザーの皆様に感謝いたします。
New Relic AI をご利用頂いているユーザーの皆様、ぜひご意見をお聞かせください。AI からのそれぞれの回答の下部にある、Good / Bad の評価ボタンから、回答に対する評価を簡単にフィードバックすることができます。または、画面左側のナビゲーション パネル下部の Help > Give Us Feedback から追加のフィードバックを送信して、引き続き製品の改善にご協力頂けますと幸いです。
Next steps
- 詳細はドキュメントを ご覧ください
- New Relic の利用をご検討中ですか?無料アカウントを作成すると、100GB/月の無料データ取り込みと、 APM、インフラストラクチャ監視、ログ管理、カスタムダッシュボード、Errors Inbox、Change Tracking(変更追跡機能)、その他の主要ツールを含む New Relic プラットフォームの 30 以上の機能へのアクセスが得られます。
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.