OpenAIとLangChainによるMLエンジニアリングとLLMOpsへの導入

OpenAIとLangChainによるMLエンジニアリングとLLMOpsの導入

次の記事は、Andy McMahonによるPackt、2023年の「Pythonによる機械学習エンジニアリングの第2版」からの抜粋に基づいています。

LLMsで大規模に生きる

執筆時点では、GPT4はOpenAIによって2023年3月にわずか数か月前にリリースされました。このモデルは、報告された1兆のパラメータを持つ、これまでに開発された可能性のある最大の機械学習モデルです。ただし、OpenAIはこの数を確認しないことを拒否しています。それ以来、MicrosoftとGoogleは、それに似た大規模なモデルを製品スイートに使用した高度なチャット機能を発表し、さまざまなオープンソースのパッケージとツールキットがリリースされました。誰もが理解し、適用しようとしているような感じです。これらのソリューションのすべては、これまでに開発された最大のニューラルネットワークモデルの一部であるLarge Language Models（LLMs）を活用しています。LLMsは、テキストアプリケーションだけでなく、ビデオやオーディオなども含むFoundation Modelsとしても知られるさらに広範なクラスのモデルの一部です。これらのモデルは、ほとんどの組織がトレーニングすることを考慮するには大きすぎる、またはおそらくホスティングすることもできないため、通常はサードパーティのサービスとして利用されます。安全かつ信頼性のある方法でこの統合の課題を解決することは、現代の機械学習エンジニアリングにおける主要な課題の1つを表しています。新しいモデルや機能が毎日のようにリリースされる中、時間を無駄にする余裕はありません。行きましょう！

LLMsの理解

LLMベースのシステムの主な焦点は、さまざまなテキストベースの入力に対して人間のような応答を作成することです。LLMsは、トランスフォーマーアーキテクチャに基づいており、これによりこれらのモデルは入力を並列に処理することができ、トレーニングに必要な時間を大幅に短縮することができます。

LLMsのトランスフォーマーベースのアーキテクチャは、任意のトランスフォーマーと同様に、エンコーダーとデコーダーの一連の処理と、セルフアテンションとフィードフォワードニューラルネットワークを活用しています。高レベルでは、エンコーダーは入力を処理し、適切な数値表現に変換し、これをデコーダーに送り、そこから出力を生成する責任を持っていると考えることができます。トランスフォーマーの魔法は、文の中の単語間の文脈関係を捉えるためのメカニズムであるセルフアテンションの使用によって生じます。これにより、これを数値的に表す注意ベクトルが得られ、これらの複数が計算されるときは「マルチヘッドアテンション」と呼ばれます。エンコーダーとデコーダーの両方は、入力と出力シーケンスの文脈依存性を捉えるためにセルフアテンションメカニズムを使用します。

• 「機械学習を利用した資産の健全性とグリッドの耐久性の向上」
• 「Amazon Rekognition、Amazon SageMaker基盤モデル、およびAmazon OpenSearch Serviceを使用した記事のための意味論的画像検索」
• 「英語のアクセント分類のための機械学習パイプラインの構築」

LLMsで使用される最も人気のあるトランスフォーマーベースのモデルの1つは、Googleによって開発されたBidirectional Encoder Representations from Transformers（BERT）モデルです。BERTは、さまざまな自然言語のタスクに対してファインチューニングできる事前トレーニング済みモデルです。もう1つの人気のあるアーキテクチャは、OpenAIによって作成されたGenerative Pre-trained Transformer（GPT）です。

OpenAIが2022年11月にリリースしたChatGPTシステムは、世界中で大成功を収めたとき、おそらく第3世代のGPTモデルを使用したようです。執筆時点の2023年3月では、これらのモデルは第4世代に達し、非常に強力です。私がこれを入力している間にも、GPT-4は世界中の一部のユーザーにしか利用できませんが、AIの将来や人工的な汎用知能（AGI）に到達したかどうかについて、すでに激しい議論を引き起こしています。筆者は、私たちが到達したとは思っていませんが、とにかくこの領域にいるのは興奮する時です！

LLMsを新しいビジネスコンテキストや組織ごとにトレーニングすることは不可能なため、それらをトレーニングするためには膨大なデータセットが必要です。2020年にリリースされたGPT-3は、ほぼ5000億トークンのテキストでトレーニングされました。この場合のトークンとは、LLMsのトレーニングと推論プロセスで使用される単語の小さなフラグメントであり、英語では約4文字程度です。ですから、非常に多くのテキストです！これらのモデルのトレーニングにかかる費用も相当なものであり、推論さえ非常に高額です。このため、これらのモデルを生産しない組織は、おそらくスケールの経済性や必要なリターンを見落とし、これらの規模での投資を正当化することはできません。これは、専門のスキルセット、最適化されたインフラストラクチャの必要性、およびそのデータを取得する能力を考慮する前の話です。数年前に公共クラウドの誕生と同様に、組織はもはやオンプレミスのインフラストラクチャや専門知識に多くの投資をする必要はありませんが、代わりに「使用する分」を支払う必要があります。最も洗練された機械学習モデルでも同じことが起こっています。これは、より小さな、よりドメイン固有のモデルが排除されたわけではないことを意味しています。実際、私はこれが組織が自社の固有のデータセットを活用し、競合他社に対して優位性を持つためにより良い製品を構築する方法の1つとして残ると思っています。最も成功するチームは、このアプローチと最大のモデルからのアプローチをロバストに組み合わせることができるチームです。

ただし、スケールは重要な要素だけではありません。ChatGPTとGPT-4は、巨大なデータ量だけでなく、強化学習と人間のフィードバックを用いたFine-tuning（強化学習による調整）という技術も使用しています。このプロセスでは、モデルに対して対話型の質問などのプロンプトを提示し、潜在的な回答のシリーズを生成させます。その後、回答は人間の評価者に提示され、回答の品質についてフィードバックを提供してもらいます。通常は、それらをランキングするなどの方法でフィードバックを行い、それを報酬モデルのトレーニングに使用します。このモデルは、Proximal Policy Optimisation（PPO）などの手法を用いて基礎となる言語モデルをFine-tuningします。これに関する詳細は、本書の範囲を超えていますが、おそらくこのようなデータサイエンスは、どのチームでも簡単にスケールアップできるものではないことがわかっていただけるでしょう。そのため、これらのツールをより「ブラックボックス」として扱い、サードパーティのソリューションとして利用する方法を学ばなければなりません。次のセクションでこれについて説明します。

APIを介したLLMの利用

前のセクションで説明したように、LLMやFoundationモデルと対話したいMLエンジニアの考え方の主な変化は、モデルアーティファクトやトレーニングデータ、テストデータにアクセスできるとは限らないということです。代わりに、モデルを呼び出して利用するためのサードパーティのサービスとして扱う必要があります。幸いにも、これを実装するための多くのツールと技術があります。

次の例では、人気のあるLangChainパッケージを使用してLLMを活用するパイプラインを構築する方法を示します。その名前は、LLMのパワーを活用するために、それらとのインタラクションを他のシステムや情報源の呼び出しと組み合わせる必要があることからきています。

まず、OpenAI APIを呼び出す基本的な例を見ていきましょう。

1. LangChainとOpenAI Pythonバインディングをインストールします。

2. ユーザーがOpenAIのアカウントを設定し、APIキーにアクセスできるようになっていることを前提とします。環境変数として設定するか、GitHubが提供するようなシークレットマネージャを使用して保存します。ここでは、キーが環境変数としてアクセス可能であると仮定します。

3. ここで、Pythonのスクリプトやモジュールで、LangChainラッパーを介してアクセスするOpenAI APIを使用して呼び出すモデルを定義できます。ここでは、GPT-3.5のチャットモデルである「gpt-3.5-turbo」と一緒に作業します。

4. LangchainはLLMを使用したパイプラインの構築を容易にし、PromptTemplatesを介してLLMのプロンプトと応答の形式を標準化することができます。

5. 次に、LangChainの中で関連するステップをまとめるためのメカニズムである「chain」を作成できます。この最初のチェーンは、適切なプロンプトをLLM APIに送信し、適切な形式の応答を返すという単純なものです。

この質問を実行して結果をターミナルに表示できます。

これにより、次の結果が返されます：

AI言語モデルとして、リアルタイムの情報にはアクセスできません。ただし、Andrew McMahonはイギリス、ブリストルを拠点とするフリーランスのデータサイエンティストおよびソフトウェアエンジニアです。

私は大手銀行のMLエンジニアで、イギリス、グラスゴーを拠点としていますので、最も洗練されたLLMでも間違えることがあることがわかります。これは、LLMが間違っているが信じられる答えを出す「幻覚」と呼ばれる例です。これは、プログラムでLLMと標準化された方法で対話するための基本的なメカニズムの良い例です。

また、LangChainは「generate」というチェーン内のメソッドを使用して複数のプロンプトをまとめる機能も提供しています。

この一連の質問からの応答は非常に冗長ですが、返されたオブジェクトの最初の要素は次のとおりです：

再度、完全ではありませんが、アイデアはわかりますね！プロンプトのエンジニアリングとより良い会話デザインを行うことで、簡単に改善できるでしょう。お楽しみください。

LangChainとLLMについてのこの簡単な紹介は、表面的な内容に過ぎませんが、MLワークフローにこれらのモデルの呼び出しを組み込むための十分な情報を提供していると思います。次に、AIアシスタントを使用したソフトウェア開発を探索する中で、LLMがこのワークフローの一部となるもう一つの重要な方法について説明します。

LLMOpsによる未来の構築

最近、LLM（Language Model）への関心が高まっており、これらのモデルをさまざまなソフトウェアシステムに統合したいという意欲的な人々が少なくありません。私たちMLエンジニアとしては、これはすぐに「運用上の意味は何か？」という問いを引き起こすべきです。本書全体で議論されているように、運用とMLシステムの開発の結びつきはMLOpsと呼ばれています。ただし、LLMの取り組みには独自の興味深い課題が生じる可能性があります。そのため、このMLOpsのサブフィールドに対して「LLMOps」という新しい用語が生まれ、この分野に対して適切なマーケティングが行われています。これは本当に異なるのでしょうか？私はそれほど異なるとは思いませんが、独自の追加的な課題を持つMLOpsのサブフィールドとして捉えるべきです。この分野で見られる主な課題のいくつかは以下の通りです：

• より大規模なインフラストラクチャ、さらにファインチューニングでも: 以前にも述べたように、これらのモデルは通常の組織やチームにとっては大きすぎるため、オープンソースまたはプロプライエタリなサードパーティのモデルを活用し、それらをファインチューニングする必要があります。このスケールのモデルのファインチューニングは非常に高価になるため、非常に効率的なデータ取り込み、準備、トレーニングパイプラインの構築にはより高いプレミアムがかかるでしょう。
• モデル管理は異なる：独自のモデルをトレーニングする場合、効果的なMLエンジニアリングはモデルのバージョン管理やメタデータの定義によって実現されます。これらのメタデータには、モデルを生成するために経験した実験やトレーニングランの経緯を提供するものが含まれます。外部にホストされるモデルの世界では、トレーニングデータやコアモデルアーティファクト、詳細なモデルアーキテクチャにアクセスできないため、これを行うのはやや困難です。バージョン管理のメタデータは、おそらくモデルの公開メタデータにデフォルトで設定されるでしょう。gpt-4-v1.3などのような名前を想像してください。これに頼るだけでは情報が少なすぎるため、特定のシナリオでモデルの振る舞いを理解するために、独自の実行例やテスト結果などでこのメタデータを充実させる方法を考える必要があるでしょう。これは次のポイントにも関連しています。
• ロールバックがより困難になる：モデルがサードパーティによって外部にホストされている場合、そのサービスのロードマップを制御することはできません。つまり、モデルのバージョン5に問題があり、バージョン4にロールバックしたい場合、そのオプションが利用できない可能性があります。これは、本書で詳しく議論したモデルの性能ドリフトとは異なる種類の「ドリフト」ですが、ますます重要になるでしょう。したがって、問題が発生した場合に切り替えるための、おそらくは機能やスケールがはるかに劣る自己のモデルを用意しておく必要があります。
• モデルのパフォーマンスはより困難になる：前のポイントで述べたように、ファウンデーションモデルが外部ホストされるサービスとして提供されるようになると、以前ほど制御力を持つことができなくなります。そのため、消費しているモデルに何らかの問題がある場合、ドリフトやその他のバグであっても、あなたができることは非常に限られており、さきほど議論したデフォルトのロールバックを考慮する必要があります。
• 独自のガードレールの適用が重要になります：LLMは幻想を生み出し、誤った情報を提供することがあります。トレーニングデータを吐き出したり、相手との対話で無意識に不快感を与える可能性もあります。これらのモデルがより多くの組織で採用されるにつれ、それらを利用するシステムに対して独自のガードレールを適用するための手法を開発する必要が増えるでしょう。例えば、LLMを次世代のチャットボットのエンジンとして使用する場合、LLMサービスとチャットインターフェースの間に、急激な感情の変化や重要なキーワードやデータの隠蔽が必要なシステムレイヤを配置することができます。このレイヤは、より簡単なMLモデルやさまざまな他のテクニックを活用することができます。最も洗練された場合、組織が倫理的な規範や他の規範に違反しないようにチャットボットを制御することができるでしょう。たとえば、組織が気候危機を重要な領域としている場合、この領域の重要な科学的な成果に反する情報をリアルタイムで会話からスクリーニングすることができます。

ファウンデーションモデルの時代はまだ始まったばかりであり、MLエンジニアとして長い時間を費やすために、ますます複雑な課題が生じる可能性があります。私にとって、これはコミュニティとして直面する最も興奮する課題の1つです。つまり、MLコミュニティによって開発された最も洗練された能力をソフトウェアが安全かつ効率的かつ堅牢にユーザーに提供する方法にどのように活用するかという課題です。この課題に取り組む準備はできていますか？それでは、LLMの検証について詳しく見ていきましょう。

LLMの検証

生成型AIモデルの検証は、他の機械学習モデルと比べて本質的に異なり、複雑に見えることがあります。その主な理由は、コンテンツを生成する際に、存在しなかった非常に複雑なデータを結果に作成することがよくあるからです！たとえば、ドキュメントの要約や分析を支援するためにLLMに生成テキストの段落を返す場合、それが「良い」答えかどうかをどのように判断しますか？データをテーブルに再フォーマットするようLLMに頼む場合、それが正しく行われているかを捉える適切な指標をどのように構築しますか？生成型の文脈では、「モデルの性能」と「ドリフト」とは実際にどういう意味であり、それらをどのように計算すればよいのでしょうか？その他の質問は、ユースケースに依存する場合があります。たとえば、情報検索や知識集約型NLPタスクにおける検索増強生成（Retrieval-Augmented Generation）ソリューションを構築している場合、LLMによって生成されたテキストの真実性をどのように評価しますか？

また、LLMが生成した出力を潜在的にバイアスのあるものや有害なものからスクリーニングすることについても重要な考慮事項があります。LLMの検証の世界は複雑です！

では、どうすれば良いのでしょうか？幸いなことに、これはすべて孤立して起こったわけではなく、私たちの道のりを支援してくれるいくつかのベンチマーキングツールやデータセットが公開されてきました。まだこれらのツールの実際の例はあまりないため、重要なポイントについて議論し、現状を把握し、事柄の進展について常に把握できるようにしましょう。以下に、LLMの高プロファイルな評価フレームワークとデータセットの一部をリストアップします。

• OpenAI Evals: OpenAIは、LLMによって生成されたテキスト補完に対するテストのクラウドソーシング開発を許可するフレームワークです。evalsの核心コンセプトは、「補完関数プロトコル」と呼ばれるもので、LLMとの対話時に返される文字列のテストを標準化するためのメカニズムです。このフレームワークはGitHubで利用可能です。
• Holistic Evaluation of Language Models (HELM): このプロジェクトは、LLMのパフォーマンスについての「生きたベンチマーク」として位置づけられています。さまざまなデータセット、モデル、メトリクスを提供し、これらの異なる組み合わせでのパフォーマンスを示しています。これは非常に強力なリソースであり、自分自身のテストシナリオをベースにするために使用したり、特定のユースケースにおける特定のLLMのリスクと潜在的な利点を理解するために直接情報を使用したりすることができます。HELMベンチマークは利用可能です。
• Guardrails AI: これはPythonパッケージであり、LLMの出力に対してPydanticと同様の方法で検証を行うことができるものです。これは非常に強力なアイデアです！問題が発生した場合、例えばプロンプトの応答が設定された基準に満たない場合、Guardrails AIを使用してLLMに再プロンプトすることで異なる応答を得ることができます。Guardrails AIを使用するには、信頼性のあるAIマークアップ言語（RAIL）ファイルを指定し、XMLのようなファイルでプロンプトの形式と期待される動作を定義します。Guardrails AIはGitHubで利用可能です。

これらのフレームワークは常に作成されていますが、より多くの組織がLLMベースのシステムを楽しい概念実証から本番のソリューションに移行したいと考えるようになるにつれて、基本的なコンセプトとデータセットについて慣れ親しむことはますます重要になります。この章の最後のセクションでは、LLMアプリケーションの構築時に「プロンプト」の管理に関連するいくつかの具体的な課題について簡単に説明します。

PromptOps

テキスト入力を受け入れる生成型AIと作業する際、入力するデータはしばしば「プロンプト」と呼ばれ、会話の原点を捉え、入力には応答が要求されるという概念が含まれます。このため、ユーザーインターフェースやAPI呼び出しを介して提供するコンテンツの性質に関係なく、LLMに供給するすべての入力データをプロンプトと呼びます。

プロンプトは通常、MLモデルに通常供給するデータとはかなり異なるものです。プロンプトは効果的に自由形式であり、さまざまな長さを持ち、ほとんどの場合、モデルがどのように動作するかの意図を示しています。他のMLモデル化の問題では、非構造化のテキストデータを供給することは確かに可能ですが、この意図の部分が欠落しています。これにより、これらのモデルを使用するMLエンジニアとして、いくつかの重要な考慮事項が生じます。

まず、プロンプトの形成が重要です。最近、データコミュニティで「プロンプトエンジニアリング」という用語が流行しており、これはプロンプトの内容や形式を設計する際に考えるべきことが多いことを指しています。これは、これらのモデルを使用してMLシステムを設計する際に考慮すべきことです。例えば、「アプリケーションやユースケースのプロンプト形式を標準化できますか？」「ユーザーや入力システムが提供する内容に加えて、より良い結果を得るために適切な追加のフォーマットやコンテンツを提供できますか？」などの質問をする必要があります。ここでは、このプロンプトエンジニアリングという用語を使用し続けます。

第二に、プロンプトは通常のMLの入力とは異なり、それらを追跡して管理することは新たな興味深い課題です。この課題は、同じプロンプトでも異なるモデルや同じモデルの異なるバージョンでも非常に異なる出力を生成する可能性があるため、複雑化します。プロンプトとそれらが生成する出力の系譜を注意深く追跡することを考える必要があります。私はこの課題をプロンプト管理と呼んでいます。

最後に、プロンプトに特有のものではない課題がありますが、ユーザーが自分自身のプロンプトをシステムに入力することを許可する場合、特に関連性の高い課題となります。この場合、モデルに入力されるデータとモデルから出力されるデータに対して、いくつかのスクリーニングや曖昧化の規則を適用して、モデルがどのような方法で「ジェイルブレイク」されることなく、制約を回避することができないようにする必要があります。また、これらのシステムからトレーニングデータを抽出するために設計された敵対的な攻撃からも保護したいです。これにより、個人を特定できる情報やその他の重要な情報が漏洩しないようにします。リニューアルされたLLMOpsのこの新たな世界を他の人々と一緒に探索を始めるにあたり、プロンプトに関連するこれらの課題を念頭に置くことが重要です。

チャレンジを受けてみましょう！

前の段落が、LLMOpsに取り組む際に探索すべきユニークな領域があること、そしてこの領域が革新のために熟成されていることを納得させたことを願っています。これらのポイントは、この豊かな新たな世界の表面にしか触れていませんが、私は個人的にはまだ答えを持っていないと思っています。未来を築くために協力していただける準備はできていますか？

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!