建築家または建築家を目指す人が知っておくべき事柄を毎月まとめた概要です。
プロフェッショナルソフトウェア開発における知識とイノベーションの普及を促進
Git は、ソフトウェア開発におけるバージョン管理によく使われるツールです。複数の Git アカウントを使用することは珍しくありません。Git アカウントを正しく構成して切り替えることは困難です。この記事では、Git が提供するアカウント構成とその制限、およびプロジェクトの親ディレクトリの場所に基づいてアカウントを自動的に切り替えるソリューションについて説明します。
このポッドキャストでは、Michael Stiefel が Robert Hurlbut に、コードだけでなくアプリケーションを安全にする意味について話を聞きました。Robert は、Aquia の主席アプリケーション セキュリティ アーキテクト兼脅威モデリング リーダーであり、Cap TechU の博士課程の学生で、アプリケーション セキュリティ ポッドキャストの共同ホストでもあります。
Shreya Rajpal は、リスクを軽減し、LLM の安全性と効率性を高めるために設計されたオープンソース プラットフォームである Guardrails AI を紹介します。
このポッドキャストでは、Culture & Methods の主任編集者である Shane Hastie が、Dannielle Pearson とテクノロジーにおける批判的思考の重要性について話し合いました。
Ranjith Kumar は、グローバルな容量を持つサービス所有者に提示される抽象化と保証、数十の地域にわたるワークロードを管理するための設計と実装、さまざまな需要の分類とモデル化、さまざまな地域間で需要をシフトすることによるグローバルな容量管理の実現について説明します。
ソフトウェア開発の意思決定をレベルアップするための変革的な洞察を発見してください。限定オファーにはコード LIMITEDOFFERIDSBOSTON24 を使用してください。
上級開発者から実践的なアドバイスを得て、現在の開発課題を解決しましょう。限定オファーにはコード LIMITEDOFFERIDSMUNICH24 を使用してください。
注目すべき新たなトレンドを発見して、ソフトウェア スキルをレベルアップしましょう。今すぐ登録してください。
すべてのプロフェッショナルが知っておくべきすべてのトピック、テクノロジー、テクニックに関する月刊ガイド。無料で購読できます。
InfoQ ホームページ プレゼンテーション LLM によるエンタープライズ AI アプリケーションのガードレールの構築
Shreya Rajpal は、リスクを軽減し、LLM の安全性と効率性を高めるために設計されたオープンソース プラットフォームである Guardrails AI を紹介します。
Shreya Rajpal 氏は、Guardrails AI の開発者兼メンテナーです。直近では、Predibase の創設エンジニアとして、ML インフラストラクチャ チームを率いていました。それ以前の役職では、Apple の特別プロジェクト グループ内の多機能 ML チームに所属し、Drive.ai で自動運転認識システム用のコンピューター ビジョン モデルを開発しました。
ソフトウェアは世界を変えています。QCon は、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発を強化します。実践者主導のカンファレンスである QCon は、チームのイノベーションに影響を与える技術チーム リーダー、アーキテクト、エンジニアリング ディレクター、プロジェクト マネージャー向けに設計されています。
Rajpal: エンタープライズ アプリケーションのガードレールについてお話しし、大規模言語モデルの信頼性、安全性、一貫性の問題を分析します。私の名前は Shreya です。現在、Guardrails AI の CEO 兼共同創設者です。機械学習に携わって約 10 年になります。最初は、古典的な AI やディープラーニングの最先端用途の研究と論文の発表をしていました。その後、自動運転車に数年間携わり、センサー、認識、意思決定など、機械学習と自動運転車のあらゆる分野に携わりました。その仕事は本当に楽しかったのですが、その後、ここベイエリアに拠点を置く MLOps 企業に最初の採用者として入社し、そこで ML インフラ チームを率いました。その後、Guardrails AI を立ち上げ、現在その会社を率いています。
これが私たちがこのことに関心を持っている理由です。ここ 1 年ほどで、AI の応用分野がカンブリア爆発的に増加しました。Auto-GPT や完全なエージェント ワークフローなど、非常に興味深い応用分野が数多くあります。さらに、精神疾患、医療、法律、営業など、価値の高いユース ケースでの非常に具体的な応用分野も見てきました。これは私のお気に入りのツイートの 1 つで、LLM と AI が私たちに何をもたらすかという初期の感情を捉えています。つまり、私たちが知っているソフトウェア エンジニアリングは死に絶え、AI は私たちよりも優れたコードを作成できます。時間の経過とともに AI への関心が高まっていることがわかります。ここのタイムラインを見ると、このあたりに ChatGPT がリリースされ、すぐに AI への関心が急上昇しました。突然、ソフトウェアとは関係のない人、たとえば私の母が人工知能について話していた人も、私が行った仕事について初めて理解しました。AI システムで何を構築できるかについて、みんなの想像力が刺激されるのを見るのは本当に素晴らしいことです。
現実は少し異なります。AI アプリケーションを扱うと、多くの問題に遭遇し、最終的には AI の使用から得られる価値が減ってしまいます。これは、AI システムがあまり信頼できないのに過度に AI システムに頼っているという、非常に現実的な意味合いがあったため、多くの注目を集めたケースだと思います。ある弁護士が法廷で ChatGPT を使用し、偽のケースを引用しました。この弁護士は、現在では ChatGPT 弁護士としてよく知られています。たとえば、Stack Overflow での回答の質は低下していると思います。他にも多くのユースケースがあります。Sequoia Capital が発表した、ジェネレーティブ AI の世界の現状に関する記事から、いくつかの数字を引用しました。1 億ユーザーへの道のりを見ると、ChatGPT は 1 億ユーザーに到達した最も急成長しているアプリケーションの 1 つです。次に、実際にこれらのアプリケーションの 1 か月のリテンション、または 1 日のアクティブ ユーザーを見ると、ジェネレーティブ AI アプリケーションのリテンションははるかに低い傾向があります。ここでは DAU グラフを掲載していませんが、このリンク https://www.sequoiacap.com/article/generative-ai-act-two/ で確認してください。同様に急激な増加が見られた従来のアプリケーションと比較すると、はるかに少ないです。これは非常に興味深い傾向です。これは、現在、生成 AI からは、他のソフトウェア システムから得ることができるはずの価値を人々が得られていないことを示しています。
なぜそうなるのでしょうか。私たちがよく目にする症状は、私のアプリケーションはプロトタイプでは完全に機能し、一度も失敗しなかったのに、それを他の人に渡した瞬間にエラーが出始めたり、API が機能しなくなったりするといったものです。この症状の根本的な原因は、機械学習が根本的に非決定論的であることだと考えています。これはバグではなく機能です。機械学習が完全に決定論的であれば、ChatGPT やその他の生成 AI ユースケースで私たち全員が頼りにしている創造性は得られないでしょう。適応性もそれほど高くなく、多くのアプリケーションほど柔軟ではないでしょう。ここでの目標の多くは、非常に有用でありながら、私たちが慣れ親しんできた従来のソフトウェアとは異なる動作をするものをどう扱うかということです。ここでその問題を概説しましたが、それは、ソフトウェア API は、それを使って構築すると、そのソフトウェア API は決定論的になるということです。そのサービスは時々ダウンするかもしれませんが、送信するクエリや応答は、何度でも同じ出力応答を返します。この特性のおかげで、複数の API を連結し、すべてが相互に依存する非常に複雑なソフトウェア システムを構築できます。
機械学習は異なります。機械学習モデルの可用性や稼働率が高い場合でも、基本的には、機械学習モデルを使用するたびに異なる応答が返されることになります。たとえば、生成 AI アプリケーションを構築しているとします。プロンプト エンジニアリングの方法に関する優れたガイドをすべて読み、自分にとって最適なプロンプトを構築することになります。「よし、この問題は解決した。これでこのプロンプトが機能する」ということになります。そのプロンプトを本番環境で実行するたびに、何も変更しなくても、異なる応答が表示されます。これは ChatGPT または OpenAPI API がダウンしていることを意味するのではなく、モデルが同じ入力に対して基本的に異なる応答をすることを意味します。その結果、生成 AI を使用して構築されているアプリケーションの多くは、依然として従来のソフトウェア システムと結合しています。複数の API を連鎖させ、LLM に推論させ、その出力を別の LLM に送信します。連鎖は非常に一般的な抽象化であり、非常に人気が高まっています。 AI モデル API が故障したり、期待したものやテストしたものと一致しない出力を生成したりすることがいかに一般的であるかを考慮すると、これは根本的に破綻し、機能しなくなります。
問題をまとめると、常に正しい出力を得るのは難しいということです。これは、従来のソフトウェア システムでは当然のこととして受け止められている基本的な前提です。アプリケーションで最終的に見られる不正確さの一般的な問題には、幻覚、虚偽、正しい構造の欠如などがあります。たとえば、多くの人が ML API を使用して JSON ペイロードを生成し、それを使用してツールなどをクエリします。これらの JSON ペイロードは、奇妙な方法で構造化されていることがよくあります。これはすべて出力側の問題です。入力側でも、プロンプト インジェクション攻撃の影響を受ける可能性があります。これは基本的に、誰かがプロンプトを明らかにさせるフレームワークです。プロンプトは秘密のソースである可能性があり、実際には明らかにしたくないものです。非常に単純化された方法では、LLM に丁寧に尋ねるようなものですが、LLM の応答が行うことと行わないことの制限を回避して多くのハッキングが必要になることがよくあります。基本的に、開発者のプロンプトが表示され、それを悪用することができます。問題をさらに複雑にしているのは、生成 AI システムを扱う開発者が利用できる唯一のツールがプロンプトだということです。これは非常に斬新な世界で、これらの問題から抜け出す方法を実際にコーディングすることはできず、多くの場合、もう一度大量の英語を書いて、同じ英語のプロンプトに対してさまざまなモデルがどのように応答するかを理解する必要がありました。
これらすべてが組み合わさって、正確さが重要になるところでは LLM の使用が制限される状況になります。たとえば、私たちが目にする LLM の最も一般的で成功しているアプリケーションの 1 つは、GitHub Copilot です。私は毎日ワークフローでこれを使用しています。私の会社のほとんどの人がこれを使用しています。これを機能させるものは何かというと、LLM 出力が生成され、それが間違っていたら無視して先に進むことです。正しい場合にのみ、その出力を受け入れ、実際に組み込むことになります。これには限られた価値しかありません。そのため、LLM が間違っていると大きなコストがかかる医療アプリケーション、銀行、企業アプリケーションでは、LLM を実際に使用することはできません。これは、個人的に非常に興味深い問題です。単に、この魅力的なテクノロジーを手に入れたからといって、それを今日のソフトウェア構築方法とどのように連携させるか、ということではありません。また、これは自動運転車でよく見られるパターンです。たとえば、ML モデルは最終的には確率的になりますが、ML モデルが間違っていると大きなコストがかかる現実世界のシナリオで機能する必要があります。
ここで私が注目している問題、そしてオープンソースの Guardrails AI が注目している問題は、LLM に正確性の保証をどのように追加するかということです。これはオープンソースのスクリーンショットです。これがオープンソースが注目している問題全体です。アーキテクチャについて、私たちがスタックの一部に位置づけて、これらの問題を評価できるようにする方法について、さらに詳しく掘り下げていきます。Guardrails AI は、LLM の周囲の安全ファイアウォールとして機能します。これは高レベルのシステム概要です。従来の AI アプリケーションの構築方法を見ると、AI アプリケーションがあります。その AI アプリケーション内には、LLM ロジックというコンポーネントがあります。その LLM ロジックには、基本的にプロンプトである入力があります。そのプロンプトは LLM API に送信されます。その LLM API は出力を返し、その出力はアプリケーションに戻ります。Guardrails AI が他と異なるのは、使用する LLM API に加えて、検証スイートの使用を基本的に推奨している点です。これは、LLM API に加えてサイドカーのようなもので、基本的に LLM の周囲の安全ファイアウォールとして機能し、すべての機能上のリスクと保証が考慮されていることを確認します。ここで、出力をアプリケーション ロジックに直接送り返す代わりに、まずその出力を検証スイートに渡します。この検証スイートには、独立して実装されたガードレールが多数あります。これらのガードレールはすべて、システム内のさまざまなリスク領域、さまざまな安全上の懸念を探します。これらの安全上の懸念の 1 つが、出力に個人を特定できる情報が含まれていないことを確認することであるとします。LLM によって誤って生成された PII をユーザーに送信したくない場合は、これをフィルタリングできます。特に顧客向けアプリケーションの場合は、システムに卑猥な言葉がないことを確認します。
商用アプリケーションも構築しているとしましょう。たとえば、マクドナルドで、チャットで注文を受けるチャットボットを構築したいとします。顧客がバーガーキングについて尋ねたとしても、実際にはバーガーキングについて話すつもりはありません。これは英語以外の出力にも当てはまります。たとえば、LLM でコードを生成しているとします。大規模な言語モデルが得意とするコード生成アプリケーションはたくさんあります。生成されたコードが実行可能で、開発環境で正しいことを確認する必要があります。最後に、メールを要約したり、非常に長い社内設計ドキュメントを要約したりするために LLM を使用するとします。要約が実際にそのドキュメントの現実に基づいており、正しく、出力を幻覚的にしていないことを確認できます。これで、ワークフローは次のようになります。その出力をエンドユーザーに直接渡すのではなく、検証スイートが独立して合格と不合格を判定します。各ガードレールをどの程度気にするかについてポリシーを設定できます。競合他社について言及するのはそれほど悪いことではないかもしれませんが、卑猥な言葉は本当によくありません。これは、適切に処理されるように設定できる項目の 1 つです。検証に合格した場合のみ、これをアプリケーション ロジックに送信します。検証に失敗した場合、Guardrails は大規模言語モデルの非常にユニークで斬新な機能、つまり自己修復機能を使用します。基本的に、LLM が間違っている理由について十分なコンテキストを提供すれば、多くの場合、LLM は自分自身を修正してフィードバックを取り入れることができます。この場合、Guardrails は自動的に新しいプロンプトを作成し、LLM が自分自身を修正する可能性が高くなるように LLM と対話します。このループは、検証に合格するか、ポリシーが無効になって予算がなくなるまで繰り返し実行されます。
なぜプロンプトエンジニアリングやより優れたモデルを使わないのでしょうか? まず、このセーフティファイアウォールを使用する代わりに、プロンプトを使用して LLM 出力を直接制御しようとします。 前に説明したように、LLM は皮肉です。 同じ入力でも、利用可能な最良のプロンプトがあっても、同じ出力が保証されるわけではありません。 最後に、プロンプトは保証を提供しません。LLM は常に指示に従うわけではないからです。 逸話的に、私が話したり一緒に仕事をしたりする多くの人は、出力を特定の方法で提供しないと人が死ぬなど、本当に悪いことが起こるだろうと極端な考えに陥りますが、これは優れた信頼性の高いソフトウェアを構築する方法としてはあまり持続可能ではありません。 代替案は、より優れたモデルを使用して LLM 出力を直接制御することだと思います。 1 つ目は、モデルを微調整する場合です。これにより、アプリケーションのより優れた基盤を実際に構築できます。 カスタムデータでモデルをトレーニングして微調整するには、コストと時間がかかるという問題が依然として残っています。私は機械学習のバックグラウンドのすべてを、モデルのトレーニングや微調整、またはモデルのトレーニングと微調整のためのインフラストラクチャの構築に費やしてきました。アプリケーションで見られる爆発的な増加の多くは、今ではそうした作業が簡単になり、問題に適したデータセットを構築する必要がなくなり、トレーニング インフラストラクチャを管理する必要がなくなり、API を呼び出して適切な出力を取得できるようになりました。これを行うと、生成 AI アプリケーションの使いやすさがある程度制限されます。一方、商用 API を使用している場合、たとえば OpenAI GPT-4 などの新しい GPT リリースに依存している場合、開発者としてモデル バージョンの更新を制御できないという問題が発生すると思います。毎日これらのモデルを扱っている者として、公式のモデル バージョン リリースがなくても、内部ではモデルが絶えず更新されているという現象が起こります。もう一度言いますが、ある特定のモデルで非常にうまく機能すると思われるプロンプトがあり、それを次のより優れたモデルに使用しようとすると、多くの場合、モデルが変わってしまい、同じプロンプトが機能しなくなります。
Guardrails AI は、より信頼性の高い生成 AI アプリケーションを構築するフレームワークで何をするのでしょうか。これは完全にオープン ソースのライブラリで、まず、前のスライドで説明したカスタム検証を作成するためのフレームワークを提供します。2 つ目は、プロンプトと検証、再プロンプト、または実装したその他の障害処理ポリシーのオーケストレーションを提供することです。これは、ユース ケース全体で必要になる可能性のある、よく使用される多くの検証ツールのライブラリとカタログです。後でいくつか詳しく説明します。最後に、これは LLM に要件を伝えるための仕様言語です。これにより、プロンプト エンジニアリングの苦労を軽減して、LLM が通常よりも正確になるように準備できます。各ガードレールは実際に内部でどのように機能するのでしょうか。PII の削除について説明しました。実行可能コードについても説明しました。ガードレール自体は、出力が適切に機能することを確認するために使用できる実行可能プログラムです。ここでよく見られる 1 つの一般的なことは、外部システムを介した接地のようなものです。たとえば、コードが実行可能であることを確認したい場合や、自然言語の質問に対して SQL クエリを生成し、データベースまたはデータベースのサンドボックスに接続してその SQL が機能することを確認し、構文エラーがないことを確認する場合、取得する出力は実際に機能する出力です。ルールベースのヒューリスティックを使用して、LLM 出力が正しいことを確認できます。たとえば、LLM を使用して PDF からデータ抽出を実行するとします。PDF を読み取り、非構造化データを生成します。生成する非構造化データが、そのシステムに期待されるルールに従っていることを確認できます。金利の後には必ずパーセント記号が続く必要があります。ドルの値は常に x と y の範囲内である必要があります。従来の機械学習方法を使用できます。たとえば、埋め込み分類子、決定木、K 近傍分類子を使用して、取得する出力がいくつかの制約に対して正しいことを確認できます。正しいことがわかっている以前のデータの宝庫があるとします。より伝統的な ML 手法を使用して、抽出した新しいデータが正しいことがわかっているデータに似ていることを確認できます。高精度のディープラーニング分類器を使用することもできます。これは基本的に、GPT スケール モデルを使用していないことを確認することを意味しますが、それでも確実にホストして提供できるモデルを使用します。これは、出力が正しく、懸念事項に違反していないことを確認するための監視役として機能します。最後に、LLM を自己反映ツールとして使用できます。LLM に、取得した応答を検査するように依頼し、指定した正確性の基準を検査し、応答がその正確性の基準を尊重していることを確認します。
また、無効な出力の処理についてもお話ししました。また、再質問についても少しお話ししました。オープンソース フレームワークの Guardrails には、検証スイートで失敗したバリデーターの処理方法を設定できる一連のポリシーが用意されています。たとえば、最終的に返される応答がこれだとします。2 つの値を持つ JSON を抽出しているとします。1 つはトランザクション フィーで、もう 1 つはトランザクション フィーの値 (5) です。ただし、ガードレールがあります。これは非常に簡単なルールベースのガードレールで、基本的に常に値が 2.5 未満であることをインラインでチェックします。これは、構成するさまざまなポリシーを使用して処理できます。ガードレールが新しいプロンプトを作成する場合の再質問についてお話ししました。たとえば、アシスタントの場合、XYZ の理由で間違っている以前の応答を修正します。最後に、その応答を LLM に送信し、新しい応答 (この場合はトランザクション フィーと 1.5) を取得します。出力はプログラムで修正できます。これは、特に私たちが持っているより複雑で洗練されたガードレールの多くでは、常に可能であるとは限りません。この場合、単純なルールベースのガードレールでは、多くの場合、これをプログラムで修正できます。この場合、しきい値の最大値などです。間違った値や問題のある値はフィルターできます。この場合、LLM 応答全体を破棄するのではなく、基本的に、間違った値 5 のみを削除するようにします。これは、文字列出力にも機能します。たとえば、長い段落があり、その段落内のいくつかの文が幻覚的であったり、間違っていたり、卑猥な言葉が含まれていたりするとします。その場合、段落全体を破棄するのではなく、基本的に、間違っているいくつかの文を削除し、全体の文章の流暢さが影響を受けないようにして、新しい応答を生成できます。定型ポリシー、または応答が間違っている理由に関するステートメントで応答できます。たとえば、「申し訳ありませんが、適切な応答はありません」などです。これは、要件を間違えた場合のコストが非常に大きいため、この場合は顧客の質問に答えないことが実際にはより良い妥協策であると基本的に確信している場合に使用するのがより適切です。これは私のお気に入りの 1 つである noop です。間違った出力をそのまま顧客に渡します。これは、これがあまり機密性の高い要件ではない場合です。同時に、失敗したガードレールはすべてログに記録されます。この場合、実行時に提供されるすべての応答に関する非常に豊富なメタデータと、その応答の正誤すべてが得られます。これを使用して、より優れたシステムを構築し、より優れたモデルをトレーニングできます。モデル トレーニング用のデータセットを作成することがいかに難しいかについて説明しました。それを使用して、モデル トレーニング データセットを作成できます。最後に、例外を発生させることもできます。その場合は、コード内またはプログラムで処理できます。
ここで、いくつかのアプリケーションについて見ていきましょう。たとえば、社内チャットボットを構築していて、そのチャットボットを使用するたびに正しい応答が得られるようにしたいとします。モバイル アプリケーションがあり、そのアプリケーションのヘルプ センターの記事を参照でき、誰でも英語で質問でき、その質問に答えられるチャットボットが必要だとします。これは、ジェネレーティブ AI アプリケーションの Hello World と呼ばれることが多く、データ チャット アプリです。次に、正確さの基準として、まず第一に、幻覚を起こさないこと、次に、汚い言葉を使わないこと、です。これは、基本的に、顧客に悪態をつかないことなど、最低限のことです。最後に、競合他社について言及しないことです。誰かが「町で一番おいしいハンバーガー店はどこですか」と尋ねてきたら、マクドナルドと答えているのにバーガー キングと答えてはいけません。この場合、基本的に、この問題が確実に解決されるように 3 つの異なるガードレールを実装することについてお話します。基本的に、私たちは、あなたが持っているコードとの埋め込みの類似性をチェックする機能を含む出所ガードレールを実装することでこの問題を解決します。これにより、生成される出力がソース コンテンツに類似していることが基本的に保証されます。NLI または自然言語推論モデルを使用して、あなたが持っている出力が正しいと分類されていることを確認します。最後に、LLM 自己反映を使用します。
私たちは、幻覚をどうやって防ぐかという基準をリストアップしました。これはかなり複雑な問題で、現在非常に活発に研究されている分野です。よくある質問は、モデルを実際に制御することはできないのに、実際に幻覚をどうやって修正するのか、というものです。ガードレールを追加します。私たちはこれを出所ガードレールと呼んでいます。出所ガードレールは、基本的に、生成されるすべての LLM 発話が、その出所である真実のソースに何らかの出所があることを確認します。これらのガードレールはアクティブであり、現在オープンソースで使用できます。これが問題になる理由は、これらのモデルが非常に強力で、インターネット全体でトレーニングされているため、「これは私のヘルプ センターの記事です。ヘルプ センターの記事にないもので応答しないでください」と伝えても、モデルはそこから引用することがよくありますが、その後、一般的な知識を使用したり、インターネットから記憶したものを引用したりします。モデルの出力を制限しようとする検索拡張生成アプリケーションを作成したにもかかわらず、実際には幻覚が発生してしまいます。プロビナンス ガードレールは、アプリケーションの実行および構築中にインラインで幻覚を検出および軽減する方法として機能します。
実際に何かを構築しているときに、これがどのように見えるかを見てみましょう。ここまでで、先ほど説明した図はおなじみです。唯一の違いは、今回は検証スイートが、出所、不適切な表現、およびピア機関で構成されていることです。すべての発話に何らかのソースがあり、幻覚ではないことを確認します。出力に不適切な表現がまったく含まれていないことを確認します。ピア機関への言及がないことを確認します。ご想像のとおり、これらはすべてそれ自体が複雑な問題です。これらの安全性の問題を解決するのは、アプリケーションを構築するのと同じくらい困難です。これらはすべて、現在オープンソースで利用できるガードレールです。なぜなら、私たちは機械学習を行い、オープンソースでこれらの ML 問題を解決するという大変な作業を行ったからです。システムがあり、ユーザーが「パスワードを変更するにはどうすればいいですか?」という質問をしたとします。 AI アプリケーションの構築に精通している場合、これはプロンプトになり、LLM に、自分が知識豊富なカスタマー サービス担当者であるかのように強制的に事前準備させることになります。誰かが「パスワードを変更するにはどうすればいいですか?」と質問してきたら、自分の知識の範囲内でこの質問に答えてください。次に、回答してよい記事のリストを渡します。ヘルプ センターの記事では、これらの記事が関連している可能性があります。LLM として、これらの記事を検討し、出力が顧客の質問に自分の能力の範囲内で答えていることを確認します。
たとえば、最終的に得られる最初の出力は、次のようなもので、アカウントにログインし、左上隅をクリックしてユーザー設定に移動し、パスワードの変更をクリックするという、生の LLM 出力があります。これは簡単な例です。基本的に、設定はアプリケーションの左上隅にはありません。これはややわかりにくいですが、これは、私が一緒に働いていた人の実際の例です。その人は、チャットボットが、アプリケーションを視覚的に確認する機能がないにもかかわらず、アプリケーションの特定のコンポーネントがどこにあるべきかを幻覚で予測するというユースケースでガードレールを使用していました。このような幻覚は、多くの場合、かなり一般的であり、顧客を誤解させたり、顧客に役立つ応答を提供したりしません。この出力が検証システムを通過するとき、はい、そこには冒とく的な言葉はありません。また、同業機関や競合他社への言及もありません。その発話は、真実のソースや LLM に提供した記事に関係がないため、出所ガードレールは失敗します。この場合、provenance のエラー修正ポリシーとして再質問を指定しているため、再質問プロンプトが自動的に生成され、その簡易版は次のようになります。具体的には、応答のどこが間違っていたのか、エラーはどのようなものだったのか、新しい手順についても説明します。この簡単な例では、正しい応答が得られました。基本的には、メニューをクリックして設定に移動してください。今回は検証に合格し、その出力を LLM にルーティングできます。
これは、1 回の LLM 呼び出しがあり、ガードレールでその LLM 呼び出しを保護する必要があるワンショット ワークフローで発生することです。ここで、ML モデリング API を使用する非常に複雑なシステムを構築したいが、ML モデリング API が信頼性が高く、安全で、保護されていることを確認したいという当初の動機に戻ります。これは、1 回の LLM API 呼び出しではなく、2 回の LLM API 呼び出しがあり、それぞれに機能する特定のプロンプトがあるということになります。通常、1 つの LLM API の出力は、他の API のプロンプトの入力として供給されます。実際には、ご想像のとおり、これらの API のいずれにも基本的に防水性がないため、これはエラーの複合的な問題にもつながります。チェーンを下るにつれて、誤った応答が増えることになります。これらのシステムを扱う際のガードレールの基本的な方法は、作成するすべての LLM API を囲む検証ロジックを確実に用意することです。これにより、最初の出力は最初に検証スイートを通過し、その出力が機能的に正しいことがわかった場合にのみそのスイートをクリアします。失敗した場合は、当然、再プロンプト戦略を実行します。検証に合格した場合のみ、次の段階に進み、この検証ロジックを再度実行し、検証ロジックに合格した場合にのみ AI アプリケーションに応答を返すようにします。このフレームワークからズームアウトすると、全体として、複合エラーの程度が軽減され、ワークフロー レベル全体で、LLM での作業に伴う不整合に対してはるかに堅牢なアプリケーションが実現します。
カスタマー エクスペリエンス チャットボットを構築する際に、一般的にどのようなガードレールが必要になるか、いくつか例を挙げてみました。出所や幻覚などについてお話ししました。一般的には、出力が信頼できること、出力が準拠していることを確認するなど、違反できない制約があります。または、ブランド セーフティがあり、ブランドでサポートされていない言語を使用しないなどの制約に違反していないことを確認します。機密情報を漏らさないようにします。一般的に、出力に信頼性があり、データのプライバシーがあることを確認します。実際には、信頼を構築するために検証済みのソースのみを使用するということになります。特定の法律のガードレールをエンコードできます。たとえば、ヘルスケア会社の場合、医療アドバイスを決して提供しないようにします。AI システムとして、医療アドバイスを提供することは許可されていないためです。AI システムでは、怒りや皮肉な言葉は決して使用しないでください。また、LLM に送信される情報や LLM から取得される情報の入出力を制御でき、機密データが漏洩していないことも確認します。最後に、カテゴリの境界内でのみ応答します。たとえば、顧客サポート チャットボットを構築しているとします。誰かがそのシステムの境界に関係のない内容であなたとチャットしている場合、構築するアプリケーションの不適切な使用を防ぐようにしてください。
私たちが重視する検証の例をもう少し挙げます。もちろん、幻覚について話しました。金融や医療に関するアドバイスを決して与えないことも、もう 1 つの一般的な基準です。おそらくご想像のとおり、これは非常に複雑な機械学習の問題であり、最初のケースでは金融に関するアドバイスや医療に関するアドバイスが何であるかを検出することさえ困難です。プライベートな質問を決してしません。顧客に「社会保障番号を教えてください」などの個人情報や機密情報を求めません。競合他社について言及しません。各文が検証済みのソースからのものであり、正確であることを確認するだけです。冒とく的な表現は使用しません。プロンプト インジェクションを防ぎ、プロンプトやアプリケーションのソース コードを決して公開しません。
Guardrails AI は完全にオープン ソースのフレームワークです。カスタム バリデーターの作成に使用できるほか、バリデーターのカタログを調べて AI アプリケーションにプラグインし、安全性、パフォーマンス、信頼性を高めることができます。AI システムの検証と確認のオーケストレーションにも使用できます。仕様言語として使用して、要件を LLM に正しく伝えることができます。詳細については、github.com/ShreyaR/guardrails の GitHub リポジトリをご覧ください。当社の Web サイトは guardrailsai.com です。
参加者 1: ガードレールという名前が気に入りました。ワイルド ワイルド ウェストを実際に制御できるパスにアレンジしたわけですね。バリデーターを作成し、入力がバリデーターに送られる場合、適切なバリデーターにルーティングするにはどうすればよいでしょうか。ロジックがあります。たとえば、バリデーターが 3 つあるとします。最初のバリデーターに送信し、次に 2 番目に送信し、3 番目に送信します。または、どのバリデーターが最初に送られるかをどのように確認しますか。
Rajpal: 現在、2 つの方法があります。1 つ目は、すべてのバリデータを並列に実行することです。出力または入力をすべてのバリデータに同時に送信します。それに加えて、バリデータの実行をずらすことができる仕様言語もあります。一部のバリデータは、通常、より高価です。幻覚については長々と話しました。幻覚をターゲットにする方法は複数あります。通常、最も高速で安価な方法と、最も正確な方法の間にはトレードオフがあります。それらをずらして、最初に高速で安価な方法を実行し、失敗した場合にのみ、より高価な方法に切り替えることができます。さまざまな方法でパイプライン化できる仕様言語があります。
参加者 1: そのために、MapReduce を使用するのですか。Mapper が並列で処理を行い、最後に Reduce がそれを実行しますか?
Rajpal: 私が挙げた MapReduce の例は、AI アプリケーションを構築するもう 1 つの一般的な例です。これらのシステムで構築する人が対処しなければならない一般的な問題は、コンテキスト制限です。たとえば、GPT-4 や最も一般的な GPT API では、送信できるトークンは 4000 個だけです。膨大な本があるとします。その場合、その本をそれぞれ 4000 個のトークンに分割し、各本に対してマップ ステージを実行し、LLM を使用して最終的な削減ステージを実行する必要があります。これは、マッピング ステージと削減ステージの両方で Guardrails が組み込まれた MapReduce フレームワークを使用するシステムでした。
参加者 2: 再度、ご意見ありがとうございます。コンテキスト ウィンドウについて質問するつもりでした。[inaudible 00:39:55] なぜなら、もちろん、毎回 [inaudible 00:40:00] コンテキスト ウィンドウを再プロンプトする必要があるからです。私が焦点を当てる質問は、実際にはコストについてです。手順のないガードレールがあるとおっしゃいましたが、時々 [inaudible 00:40:14] 質問を再質問することがあります。より正確にするために [inaudible 00:40:19] 再プロンプトを行ってきましたか?
Rajpal: コストに関して強調したい点が 2 つあります。すべての再プロンプトは構成可能です。あまり気にしないガードレールを扱っている場合や、間違えるとコストがかかる場合でも、他の方法で使用できます。常に再プロンプトする必要はなく、間違った値をフィルターで除外するか、プログラムによる修正が可能な場合はそれを使用するだけです。または、このクエリには答えられないかもしれない、というように判断することもできます。通常、ガードレールの場合のみ、ポリシーとして再プロンプトを構成し、このガードレールが間違っている場合、またはこのチェックが失敗した場合は、出力はまったく役に立たないという設定になっています。たとえば、ヘルスケア アドバイスや財務アドバイスは、私たちが一緒に仕事をしている人たちの 1 人として、とても気に入っています。彼らは、自分のアウトプットにヘルスケア アドバイスを誤って含めた場合のコストは組織として非常に大きいので、応答しないほうがよいと考えます。その場合、顧客に価値を提供できないか、再プロンプトの追加コストを負担することになるかもしれません。これらは通常、人々が再プロンプトを構成するガードレールのサブセットです。これはソフトウェア レベルではなく、問題の範囲レベルに関するものです。人々がこれらのシステムを使用することになる多くの場所では、通常、代替手段がはるかに高価です。多くの場合、質問の回答を得るには 1 時間も列に並ばなければなりません。その場合、企業は必要に応じて再プロンプトの追加コストを負担することにしばしば同意します。
参加者 3: 検証スイートについてですが、誤検知をどのように処理していますか?
Rajpal: 当社が採用しているガードレールの多くは ML ベースでもあり、その場合、独自の不可逆エラーや、基本的に時々間違っている可能性が伴います。この問題を私がどのように捉えるかは、ある意味では、私たちが行っているのはアンサンブル、つまり、各モデルがそれぞれ異なる長所と短所を持つ異なる機械学習モデルを連携させる手法である、と考えるのがよいと思います。これについて私がよく使うアナロジーは、異なるふるいを積み重ねることです。各ふるいには異なる場所に穴があります。その結果、ふるいを積み重ねた方が、個々のふるいよりもはるかに防水性の高いシステムになります。たとえば、プロベンスや当社の幻覚防止ガードレールでは、社内で多数のテストを行っており、システムの有効性を推定できます。これらのいくつかを組み合わせてガードレールをアンサンブルし、LLM を使用することで、全体としてはるかに堅牢なシステムを実現できるという考え方です。とはいえ、機械学習を扱う以上、エラーをゼロにすることは決してありません。利用可能なツールを使用して、エラーを可能な限り減らすことが目的です。
参加者 3: 誤検知が出始めると、それが何らかの形で新しいガードレールに変換されるのでしょうか。わかりません。[聞き取れない 00:44:06] 動的ガードレールか何か [00:44:11]。
Rajpal: 出所の例を基に答えます。出所の例では、類似性の埋め込みと NLI 分類器の比較について説明しました。類似性の埋め込みは、幻覚を検出する高速で安価な方法ですが、正確性は高くありません。その結果、誤検知が多く発生していることがわかりました。これにより、システムの不確実性の推定値を把握できます。基本的に、K 近傍法による分類を行うことになりますが、KNN 分類に基づいて、距離がしきい値より大きい場合は、この点について適切な推定値が得られない可能性が高いことがわかります。その場合は、ルーティングします。このガードレールの障害ポリシーは、よりパフォーマンスが高く、より高価なガードレールに送信することです。このガードレールの方が正確です。フェイルオーバーと別のシステムへの障害もその一部です。
参加者 4: 異なるスタイルのガードレールを用意するとともに、データを組み込んだ更新されたコスト関数を使用してモデルを微調整することを検討しましたか。
Rajpal: このシステムに対する私たちのアプローチは、基本的に、開発者がガードレールの結果をログに記録しやすくすることです。このライブ プロダクション システムを実行すると、毎日何千ものリクエストが処理されるため、1 か月以上実行すると、各リクエストに対して何が機能するか、何が機能しないかに関する機能を備えた適切なデータセットが得られます。このデータセットはエクスポートが非常に簡単なので、微調整などに直接使用できます。これは非常に興味深い点です。基本的に、モデルをトレーニングする損失関数で使用し、損失に追加して、より代表的な損失を得ることができます。今日、誰もそれをやっているのを見たことがありません。ガードレールは、基本的にモジュールのように独立して実装されているので、できない理由はわかりません。はい、理論的には可能です。
トランスクリプト付きのプレゼンテーションをもっと見る
InfoQ の先週のコンテンツのまとめが毎週火曜日に配信されます。250,000 人以上のシニア開発者のコミュニティに参加してください。例を見る
2024 年 6 月 24 日 – 25 日 | ボストン、マサチューセッツ州今日の重要な開発優先事項を明確にする実用的な洞察。InfoQ Dev Summit Boston は、InfoQ が主催する 2 日間のカンファレンスで、シニア ソフトウェア開発者が現在直面している最も重要な技術的決定に焦点を当てています。20 以上の技術講演を詳しく聞き、ジェネレーティブ AI、セキュリティ、最新の Web アプリケーションなどを扱うシニア ソフトウェア開発者から革新的な学びを得ましょう。今すぐ登録
InfoQ.com およびすべてのコンテンツの著作権は © 2006-2024 C4Media Inc. に帰属します。プライバシー通知、利用規約、Cookie ポリシー
元記事: https://www.infoq.com/presentations/guardrails-ai/