この記事は、2023 年 9 月 3 日に開催された QCon Global Software Development Conference 2023 北京駅での同名の基調講演「MLOps から LMOps サブフォーラムへ」を編集したものです。

この共有のコンテンツ構造は次のとおりです。

MLOps から LMOps へ。
MLOps の概要、課題、解決策。
LMOps実装の課題と主要テクノロジー（大規模モデル推論パフォーマンスの最適化、迅速な構築と自動最適化、コンテキスト長の拡張）。
今後の展望。

1 MLOps から LMOps へ

ご存知のとおり、人工知能を実現するために現在使用されている主な技術手段は、機械学習技術、特にディープニューラルネットワークに基づく深層学習技術です。機械学習の本質は、学習機能を備えたアルゴリズムを通じてデータをモデル化するテクノロジーです。

ディープラーニングは、大規模なコンピューティング能力を使用して、機械学習における特徴表現における手動介入のボトルネックを解決し、有効性において大きな進歩を遂げました。したがって、機械学習は現在の人工知能の主流の技術となっています。

深層学習と大規模生成モデルの関係は、下図の右側に示されています。2012 年から 2016 年頃には、畳み込みニューラルネットワーク、敵対的生成ネットワーク、ResNet などの古典的な深層学習モデルがすでにコンピューティングビジョンで使用されていました。音声認識や自然言語処理などの分野で実現されています。これらの古典的な深層学習モデルは、識別的かつ生成的であり、多くの場合、ImageNet や COCO などのラベル付きデータセットで事前トレーニングされ、さらに微調整可能な事前トレーニング済みの重みを備えた事前トレーニング済みモデルを形成します。

2017 年に Transformer 構造の自然言語処理分野への応用に初めて成功し、その後、Transformer を基本コンポーネントとする生成大規模モデルは、視覚、自然言語処理、クロスモーダル理解、視覚などの分野で徐々に主流の技術となりました。世代。

この種の技術は通常、コンポーネントとしてTransformerとattentionメカニズムを使用し、10億を超えるパラメータ規模で自己教師あり学習を並行して実行できます。このうち、生成ラージモデル技術を言語モデリングに適用する手法を「ラージ言語モデル」と呼びます。さらなる最適化の後、ChatGPT や Wenxinyiyan などのよく知られた会話型および生成型の大規模言語モデルアプリケーションが形成されました。

DevOps は、従来のソフトウェアライフサイクルを通じて実行される方法論およびベストテクニカルプラクティスであり、ソフトウェア要件、コード開発、テスト、オンライン運用と保守、プロモーションと運用が含まれます。主要なテクノロジーには、要件管理、バージョン管理、継続的インテグレーション、コンポーネント化、コンテナ化、マイクロサービス、継続的デリバリー、自動化された運用とメンテナンスなどが含まれます。現在、DevOps プラットフォームとツールは、ほとんどのソフトウェア開発会社にとって、ソフトウェアの研究開発業務を管理するための最も効果的な方法となっています。

MLOps は機械学習時代の DevOps であり、その主な機能は、モデル構築チームとビジネスを結び付け、モデルの開発、トレーニング、展開、オンライン、監視に関する標準化されたベストプラクティスを確立することで、品質を向上させ、管理プロセスを簡素化することです。機械学習モデルと深層学習モデルを大規模な運用環境に自動的にデプロイし、モデルをビジネスニーズやルール要件に合わせて調整します。

以下では、MLOps と DevOps の概要、共通点と相違点について説明し、その後、MLOps と DevOps に関連する概念、課題、ソリューションについても詳しく説明します。

MLOps と DevOps の共通点:

簡素化されたステッププロセス: MLOps と DevOps は、明確で連続したステップを確立することにより、ソフトウェア開発/モデル開発プロセスを簡素化します。 MLOps は、ML 開発の所要時間を短縮することに重点を置いています。
通信コストの削減: MLOps と DevOps は、標準化されたプロセス手順を確立することで通信コストを削減します。 MLOps は、運用モデルの開発と維持方法について、組織全体のシステム管理者、データサイエンスチーム、およびその他の部門の間で合意されることになります。

MLOps と DevOps の違い:

MLOps にはより複雑なバージョン管理があり、機械学習の場合、変更される入力はコードだけではなく、データ、パラメーター、メタデータ、ログ、そして最終的にはモデルのすべてをバージョン管理する必要があります。
継続的モニタリングと継続的トレーニング: DevOps と MLOps でのモニタリングの違いは、機械学習モデルは劣化するのに対し、ソフトウェアは劣化しないことです。ビジネス環境の変化と適応に応じてデータも変化し続け、モデルの劣化を引き起こします。

古典的な深層学習モデルと比較して、大規模モデルでは、次の 4 つのレベルなど、人工知能テクノロジーとアプリケーションレベルでも大きな変化が見られます。

データ: まず第一に、大規模モデルの事前トレーニングには通常、TB から PB レベルのデータが必要ですが、このデータ規模と対応するデータ処理テクノロジーは、従来の深層学習モデルとは大きく異なります。同時に、今日の大規模モデルでは、マルチモーダル、指示、対話データをトレーニングまたはチューニングの入力として使用することが増えており、データの内容も以前とは異なります。
トレーニング: 数千億のパラメータを持つ今日の大規模モデルは、分散トレーニングにキロワット時、さらには 10,000 キロカロリーを必要とすることがよくあります。スケジューリング、フォールトトレランス、および通信テクノロジは以前とは大きく異なります。また、チューニングプロセスでも多くの問題が発生します。大規模モデル、リソースのオーバーヘッドが低く、高効率のテクノロジ。
評価: 従来の深層学習モデルは、多くの場合、手動でラベル付けされたテストデータセットに基づいて、客観的な指標を計算し、モデルの効果を評価します。大規模なモデルによって生成される膨大なコンテンツに対する標準的な答えがないため、コンテンツの品質の判断を人間に完全に依存することはできません。したがって、大規模モデルの効果や性能には、これまでとは異なる評価基準や評価方法の確立が必要となります。
推論: プロンプトエンジニアリングを使用して大規模モデルの出力を調整する自然言語処理やビジュアル生成の分野に関係なく、以前の古典的な深層学習モデルにはこれらの機能がありません。

大規模モデルはテクノロジーとアプリケーションモデルに大きな変化をもたらし、AI 機能の使用と管理の方法、大規模モデルの実装方法など、企業に新たな課題ももたらしました。これらにより、データエンジニアリング、モデルのチューニング、モデルの配信、サービス運用、サポート機能などの側面に対する新しい要件が提示されました。

LMOps は、企業が大規模モデルによってもたらされる上記の新たな課題を解決するのに役立ちます。

LMOps は、大規模モデルの開発と運用のための統合ソリューションであり、企業が大規模モデルを迅速に構築および管理できるようにします。モデル運用プロセス全体のさまざまな機能と標準化要件を統合することで、企業がデータからサービスまでの完全なプロセスを実現できるように支援し、大規模なモデルを実稼働環境に迅速かつ効率的にデプロイできるようにし、大規模なモデルアプリケーションの効率と品質を向上させます。実装。

人工知能の発展により、MLOps および LMOps のプラットフォームとツールが私たちの目に届くようになりました。次に、MLOps と LMOps が直面する課題と、それに対応する解決策を詳しく説明します。

2 MLOps の概要、課題、解決策

データとモデルには統一された管理が欠けています。基盤となるインフラストラクチャは統一されておらず、さまざまなアルゴリズム開発グループに分散しています。たとえば、自動車産業の初期の慣行では、自動車の生産プロセスには 1 人の作業員のみが手動で参加していましたが、コラボレーションが欠如していたために、自動車製造に多大な時間と労力が無駄になりました。

これにより、機械学習モデルの研究開発は 2 つ目の問題に直面することになり、モデルの全体的な開発、展開、反復サイクルが比較的長くなります。

モデルのモニタリングシステムは完全ではありません。実験室環境ではモデルの効果は変わりませんが、実際のビジネスデータは異なります。データの分布やデータ構造が変化するにつれて、モデルの実際の適用効果は減衰する可能性があります。継続的な監視機能が必要です。

役割のコラボレーション: 人工知能アプリケーションシステム全体の開発プロセスには、ビジネスチーム、運用保守チーム、アルゴリズムエンジニアチーム間のコラボレーション関連のリンクの確立が含まれるため、このリンクでは多くの場合、次のような問題に遭遇します。 a 乗り越えられない障害、これはまさにトルストイの有名な言葉に相当します。「スムーズな会社は似ており、スムーズでない会社にはそれぞれ独自のスムーズでないやり方がある」というものです。誰がどのような権限を持っているか、アクセスできるリソースの数、それらが相互に競合または影響を与えるかどうか、統一された調整と管理のためのプラットフォームまたはメカニズムも必要です。

MLOps の具体的な実践において、MLOps 実践の構築を計画している場合は、データ処理、モデルの構築、モデルのトレーニング、モデルのデプロイメント、予測サービスの実装など、機械学習のライフサイクルのプロセス全体を実行する必要があります。モニタリングと最適化。各リンクには、解決および管理すべき一連の問題があります。

したがって、MLOps プラクティスを構築するには、さまざまなプロセスを自動化して接続し、パイプラインに基づいたコラボレーションメカニズムを確立するための対応するツールが必要です。

この目的を達成するために、Baidu Intelligent Cloud は、AI ミドルプラットフォームで MLOps を構築する実践を開始し、機械学習システムのすべてのステップを自動的に実行し、リアルタイムで監視できるようにしました。

Baidu AI ミドルプラットフォームは、Baidu Brain の 10 年以上にわたる AI 技術と機能の蓄積に依存しており、現在、金融、エネルギー、インターネット、教育、通信事業者、製造、政府およびその他の業界にインテリジェントなミドルプラットフォームソリューションを提供し、企業の構築を支援しています。 AI 資産の共同構築と共有、およびアジャイルなインテリジェントアプリケーション開発を実現する統合 AI インフラストラクチャ。

Baidu AI ミドルプラットフォームの機能アーキテクチャのパノラマを以下の図に示します。

サンプルセンター: 主にデータセンターに接続し、データを取得し、データの特徴処理やデータアノテーションを実行します。
AI 開発プラットフォーム: データの特徴処理とアノテーションが完了すると、データはさらなる開発作業のために AI 開発プラットフォームに入力されます。 AI 開発プラットフォームは主にアルゴリズムエンジニアを対象としており、アルゴリズムエンジニアがプラットフォームの他の機能を開発し、モデルを迅速に開発およびトレーニングできるようにします。
モデルセンター: トレーニングを完了したモデルはモデルセンターに入り、一元管理されます。
AI サービスオペレーティングプラットフォーム: モデルセンターによって処理された最終モデル展開パッケージは、オンライン展開のために AI サービスオペレーティングプラットフォームに送信され、最終的にソフトウェアエンジニアによって顧客のアプリケーションに統合されます。

モデルリスク管理の監視システムの下で、AIミドルプラットフォームのプロセス全体を検査および追跡することができ、企業がAI機能を適用するリスクを軽減します。プロセス全体のデータは、対応する AI 資産を形成することもでき、企業内の組織や部門間で共有できるため、部門間の障壁がなくなり、構築の重複が回避されます。

大型モデルプラットフォームは、AI ミドルプラットフォームの不可欠な部分であり、生成 AI のインフラストラクチャです。 Baidu AI ミドルプラットフォームは、モデル機能を外部に直接提供するだけでなく、企業が独自かつ効率的に構築できるようにサポートします。

現在、Baidu AI ミドルプラットフォームは MLOps 手法の中核的な側面をカバーしており、情報通信技術アカデミーの関連標準の主力認定を取得しています。 Baidu AI Center は、中国でこのレベルの認証を取得できる唯一の製品またはソリューションでもあります。

以下に、MLOps のコア技術を簡単に紹介します。

自動化されたデータアノテーション: モデルが実際に実行されている場合、手動アノテーションには多くの時間と人件費がかかります。 MLOps は、自動化された方法でデータアノテーションを実行し、ノイズの多いデータを削除し、モデルトレーニングデータの品質を確保し、手動でのデータアノテーションの時間とコストを節約します。
実験管理 + バージョン管理: 実験パラメータを自動的に収集し、Git などのバージョン管理システムと連携してコード、データ、モデルファイルなどを管理します。モデルを追跡して比較する必要がある場合、初期段階で自動的に収集された実験パラメータを通じてモデルを追跡し、モデルの効果を継続的に最適化できます。
AutoML + AutoDL: AutoML などのテクノロジーを使用して、アルゴリズムを自動的に検索してパラメーターを調整し、最適なモデルをすばやく見つけて実験サイクルを加速します。
解釈可能性: 解釈可能テクノロジーを使用してモデルの動作を分析し、大規模なモデルの監視とセキュリティのニーズに対応し、モデルの透明性を向上させます。
ドリフト監視: モデルがオンラインになった後はデータが変化し、モデルの効果が減少するため、モデルを継続的に監視して最適化する必要があります。ドリフト監視では、モデルのトレーニングと推論のログを収集し、主要な指標を設定し、モデルのパフォーマンスを監視し、自動再トレーニングを実装できます。
モデル適応: モデル適応のハードウェア範囲を継続的に拡大し、幅広い環境での自動展開を促進します。
モデルの圧縮: プルーニングや定量化などの手法を使用して、モデルサイズを圧縮し、メモリ使用量を削減し、実行速度を向上させ、展開コストを削減します。
API 中心: プラットフォームの主な動作動作をコーディングでき、実験版の情報と併せて自動的に実行できます。

3 LMOps 導入の課題と主要テクノロジー

下図にあるように、LMOpsが誕生してまだ日が浅いにもかかわらず、川上から川下までさまざまな企業が共同で豊かなエコシステムを構築しています。大型モデルをきっかけとした最近の投資ブームでは、資金の 3 分の 1 が LMOps 関連のツールやプラットフォームに投資されています。

多くの企業があり、いくつかの新しい顔も現れていますが、データ、トレーニング、評価、推論、導入、セキュリティという 6 つの主要なリンクに分けることができます。本日は時間が限られておりますので、大型モデルの特徴を踏まえた技術的なポイントをいくつかピックアップしてご紹介させていただきました。

現在、大規模モデルの推論パフォーマンスの最適化、プロンプトエンジニアリング、コンテキスト長の拡張など、大規模モデルの特徴を持つ3つの技術ポイントがBaidu Intelligent Cloud Qianfan大規模モデルプラットフォームに統合されています。

Qianfanの大規模モデルプラットフォームは、インテリジェントなクラウドコンピューティングインフラストラクチャと AI ミドルプラットフォームの成熟した機能に基づいており、大規模モデル時代の AI アプリケーション構築パラダイムを再定義します。市場の数十の主流の大型モデルと広く互換性があり、LMOps ライフサイクルをカバーし、自動化も可能です。

アプリケーション開発者はモデルの詳細をマスターする必要がなく、単純なページ操作を通じて大規模なモデルの微調整、評価、圧縮、展開、プロンプト機能やその他の機能を実行できます。同時にプラグイン機構もサポートしており、アプリケーション側はプラグインを通じて独自の大規模モデルシーンを拡張できます。

3.1 大規模モデルの推論パフォーマンスの最適化

QAT は、Quantization-aware-training の略で、モデルのトレーニングプロセスに疑似量子化 (Fake-quantization) を導入し、量子化プロセスによって生じる誤差をシミュレートする方法です。その目的は、モデルが量子化されたトレーニングに適応できるようにすることです。数値表現を使用することで、量子化モデルの精度損失が軽減されます。

QAT の利点は次のとおりです。

トレーニング中に量子化誤差を考慮して、モデルをより堅牢にし、後処理の量子化によって引き起こされる大きな精度の損失を回避できます。
量子化ノイズが最適化プロセスに干渉するのを避けるために、より高精度の勾配を使用して重みを更新できます。
異なるレイヤに対して異なる量子化ビット幅を使用する、異なるチャネルに対して異なるスケーリング係数を使用するなど、より柔軟な量子化戦略を使用できます。

QAT の欠点と制限は次のとおりです。

モデルのトレーニングコードを変更し、擬似量子化操作とオブザーバーを追加する必要があります。これは、モデルの構造とパフォーマンスに影響を与える可能性があります。
モデルを再トレーニングする必要があるため、トレーニング時間とコストが増加します。
量子化ビット幅、オブザーバのタイプ、キャリブレーションデータセットなど、量子化効果に影響を与える可能性がある適切な量子化構成とハイパーパラメータを選択する必要があります。

Baidu Smart Cloud は、大規模モデル向けに 4 つのトレーニング後の量子化ソリューションを提供します。これらは、重み付け、アクティベーションレイヤー、k/v キャッシュの量子化であり、これにより、開発者が使用できるさまざまな圧縮効果を実現します。

チャネルごととは、ウェイトの各チャネルが個別の量子化パラメータを使用することを意味し、この方法はテンソルごとの量子化方法よりも詳細であり、量子化パラメータの自由度も優れているため、精度がロスレスです。

グループごととは、重みパラメータをグループ化し、各グループを int8/Int4 に量子化することを指します。グループ化にはさまざまな戦略を使用できます。たとえば、128 個の重みパラメータごとに 1 つのグループに分割すると、各グループに独自の異なる最大値と最小値の範囲と精度を持たせることができ、全体の精度が向上します。

大規模なモデルの量子化の場合、量子化の前に特定のスムーズなプロセスを追加して、重み分布を平滑化し、大規模モデルの不均一な重み分布の問題を解決できます。

ハイパーパラメータの導入により、量子化プロセスにおける活性化関数の量子化と重みの量子化の難易度の違いをうまくバランスさせることができ、量子化プロセス全体がよりスムーズになり、量子化スキームの汎用性が向上します。これら 2 つの改善により、大規模モデルの量子化によって生じる精度の損失が効果的に低減され、量子化されたモデルの精度が元の完全精度モデルに近づくため、効率的な大規模モデルの展開が実現します。

このソリューションは優れた汎用性を備えており、精度を損なうことなく、数千億レベルの大規模モデルのビデオメモリやカードの数を半分に節約でき、速度も 1.5 倍高めることができます。

前述のソリューションでは、重みとアクティベーションは int8 に保存されますが、大規模なモデルでビデオメモリを消費する別のランタイムパラメーター k/v キャッシュは依然として FP16 に保存されます。

このため、k/v キャッシュ int8 量子化を追加しました。速度を確保しながら、ビデオメモリをさらに 15% 圧縮してランタイムビデオメモリを節約し、真のフルプロセス int8 量子化を実現できます。

モデルの疎性はモデル圧縮テクノロジであり、その目的は、モデル内のパラメータの数を減らし、それによってモデルの記憶領域と計算の複雑さを軽減することです。モデルの疎性の原理は、何らかの戦略 (重み枝刈り、特徴選択、行列分解など) を使用して、モデル内の一部のパラメーターをゼロに設定するか、パラメーターを削除してモデルを疎にすることです。モデルのスパース性では、少数のパラメーターのみがゼロ以外になります。

静的圧縮はトレーニング後にモデルを圧縮しますが、動的圧縮はトレーニングプロセス中にモデルを圧縮します。動的圧縮は、次の理由から静的圧縮よりも頻繁に使用されます。

動的圧縮は継続的に最適化できます。トレーニングプロセス中に重要でないパラメータが特定された場合、それらのパラメータを直接圧縮できます。動的圧縮では、トレーニングプロセスの進行に応じて圧縮を継続的に最適化できます。
柔軟な調整。動的圧縮では、リソースの状態に応じて圧縮率を動的に調整し、さまざまな導入ニーズに適応できます。
動的圧縮により、重要な情報をより適切に保存できます。動的圧縮により、トレーニング中にパラメーターの重要性を特定し、モデルにとってより重要な情報を保持できます。

Baidu Intelligent Cloud の大規模モデルソリューションは、主に業界の最新の調査に基づいて実装されています。 SparseGPT は応用ソリューションの 1 つです。

SparseGPT アルゴリズムは、オーストリア科学技術研究所 (ISTA) の 2 人の研究者である Elias Frantar と Dan Alistarh によって開発され、100 ～ 1000 億パラメータのモデルサイズに対して正確なシングルショットプルーニング手法を初めて可能にしました。

SparseGPT 再構成アルゴリズムの視覚化。固定の枝刈りマスク M を指定すると、ヘッセ行列逆数列 (HUj) を使用して重み行列 W の各列の重みを段階的に枝刈りし、これらの行の残りの重みを列の「右」に更新します。具体的には、枝刈りされた重みの「右側」の重み (濃い青) は枝刈りエラーを補正するために更新されますが、枝刈りされていない重みは更新を生成しません (水色)。

この方法で処理された大規模モデルのパフォーマンスは最大 60% 向上します。さらに、SparseGPT は定量的手法を補完するものであり、この 2 つを組み合わせて適用できます。

使用されているもう 1 つのソリューションは WandA です。

従来の枝刈りの考え方は非常に単純です。つまり、ネットワーク内の重みの絶対値が特定のしきい値よりも小さい場合、その重みはほとんど役割を果たしていないとみなされ、直接 0 にクリアされます。

新しい WandA ソリューションは、重みとアクティベーションを同時に考慮する必要があることを提案しているため、処理中に、最初に重みとアクティベーションを乗算し、次にしきい値より小さいパラメーターをゼロにリセットする必要があります。

このソリューションは精度の点で SparseGPT よりも優れているわけではありませんが、非常に効率的であり、時間消費量が数十倍向上します。

これらの方法により、Qianfan 大型モデルプラットフォーム上の一部のモデルの推論パフォーマンスは、今年 4 月以降 10 倍以上向上しました。

3.2 迅速な構築と自動最適化

大規模モデルには膨大な数のパラメーターがあるため、強力な言語生成機能を備えています。しかし、その出力は入力の品質にも大きく依存します。入力を間違えると、間違った答えが得られる可能性があります。

したがって、大規模なモデルに適切な入力をどのように与えるかは、研究する価値のある問題となっています。最適な入力方法を見つける作業は、現在ではプロンプトエンジニアリングと呼ばれています。

プロンプトエンジニアリングでは、さまざまな種類のプロンプト形式を研究して、特定のタスクに対してそれらを表現する最も効果的な方法を見つけることが含まれます。同時に、プロンプトに冗長になりすぎずに十分な情報が含まれるように、入力の長さや文の構造などの要素を考慮する必要があります。

適切なプロンプトにより、タスクの要件が明確に説明され、モデルが重要な情報に集中できるようになり、高品質の出力が生成されます。

高品質のプロンプトを設計するには専門知識と多くの時間を必要とするため、一般のユーザーが複雑なプロンプトを自分で構築することは現実的ではないことがよくあります。ユーザーが自然言語で質問やリクエストを直接提供でき、システムがユーザーがそれらを適切なプロンプトに自動的に変換できるようになれば、よりユーザーフレンドリーになります。理想的には、ユーザーは簡単なステートメントでニーズを表現するだけでよく、基礎となるプロンプトの形式について心配する必要はありません。

この目標を達成するための 1 つの方法は、プロンプトテンプレートライブラリを確立し、ユーザーのクエリの意図に従って既存の効率的なテンプレートを照合し、クエリの主要な情報を挿入してプロンプトを自動的に生成することです。もう 1 つのアプローチは、自然言語をその意図を完全に表現するプロンプトステートメントに直接変換できるモデルをトレーニングすることです。さらに、ユーザーがクエリを行った後、フィードバックメカニズムを使用して、満足のいく応答が生成されるまでプロンプトを複数回繰り返し最適化できます。

一般的なプロンプトプロジェクトには、いくつかの古典的な方法があります。

直接質問することは、結果を保証する最も難しい方法です。直接質問する場合、回答の効果は大規模モデルが適切にトレーニングされているかどうか、および適切な命令の微調整が行われているかどうかに依存し、プレッシャーは主に大規模モデル側に集中します。
小さなサンプルサイズのチップ。ユーザーは最初に大規模モデルにいくつかの例を与え、次に大規模モデルに同じ種類の質問に答えるように依頼します。この方法は通常、より効果的です。
CoT プロンプトプロセスは、大規模な言語モデルに推論プロセスの説明を促す、最近開発されたプロンプト手法です。思考連鎖の主なアイデアは、論理的推論プロセスを含むいくつかの例を大規模な言語モデルに示し、大規模なモデルが答えるときに推論プロセスも示すことを要求することです。この種の推論を解釈すると、より正確な結果が得られる傾向があります。
知識プロンプトを生成し、大規模モデルが豊富な潜在的な知識を活用し、背景情報を自己改善することで正確な答えを取得できるようにします。

先ほど述べたように、手動プロンプトプロジェクトには 2 つの問題があります。1 つ目は、探索に時間がかかり、一般のユーザーはわざわざ適切なプロンプトを構築しないことです。 2 番目の問題は、さまざまなテンプレートが限られたタスクに適しており、普遍的ではないことです。

プロジェクトの実装に関しては、現在、Prompt プロジェクトをさらに自動化する方法が 2 つあります。

1 つ目は専用モデルです。つまり、アプリケーションシステムがプロンプトを受信した後、まずそれを分類モデルに送信して、プロンプトを最適化できるかどうかを判断させます。必要に応じて、多数の命令を使用して特別にトレーニングされた新しいモデルに送信され、元のプロンプトに磨きをかけ、補足した後、より良い回答を得るために LLM に送信されます。この解決策はシンプルで簡単ですが、全体的な推論のオーバーヘッドが大きくなります。

もう 1 つのオプションは、最初に大規模モデルに結果を生成させ、次にその結果を独自に分析し、同時に最適化提案を提供することです。引き続き大規模モデルに最適化提案を使用させて、複数の関連するプロンプトを生成させます。大規模モデルは評価を継続します。これらの新しく生成されたプロンプトに対して提案を行うことで、最適なプロンプトが生成されます。このソリューションはより自動化されていますが、2 つの制限もあります。1 つはコアの大規模モデル自体の機能に依存すること、もう 1 つは推論のオーバーヘッドが大きくなるということです。これは、プロンプトテンプレートライブラリを自動的に補完するオフラインタスクとして使用できます。

3.3 コンテキスト長の拡張

多くの大規模モデルの入力はわずか 2K ～ 3K トークンであるため、大規模モデルの適用は制限されます。したがって、GPT-4 や Claude などの大きなモデルが Context を拡張するたびに、市場から熱狂的なフィードバックが寄せられます。

この共通の問題点により、学術界や工学界は、大規模モデルの入出力長を迅速に拡張するための、プラグインソリューション、直接外挿、内挿ソリューションなどの一連の技術ソリューションを提案するようになりました。解決策が多すぎるため、この記事では 2 つの簡単な解決策を選択して詳しく説明します。

大規模なモデルのコンテキストの長さが不十分であるという問題を解決するには、元の入力データまたは背景データをセグメント化してベクトルデータベースに保存するという直接的なアプローチを採用できます。

次に、ベクトルデータベース内のユーザープロンプトと照合し、ベクトルデータベース内の一致したフラグメントをプロンプトの背景知識として使用して、大規模モデルが回答を生成できるようにします。

たとえば、この方法を使用して、本の内容について質問することができます。

ベクトルデータベースは高速なクエリと検索操作を提供し、処理プロセスをより効率的にできるため、最近ベクトルデータベースが突然人気を集めています。サマリータスクの場合は、最初にタスクをスライスしてからセグメントに要約したり、サマリーをマージしたり、ループの順序を変更したりすることもできます。順次サマリー、レイヤーごとのサマリー。

ただし、このアプローチにはいくつかの制限もあります。たとえば、シャーディングにより情報の損失や重複が発生し、モデルの精度に影響を与える可能性があります。

読解などの特殊な長い文脈のシナリオでは、Naive Bayes に基づく完全なプラグイン NBCE を使用して、クエリ + 元のテキストを入力した後に長さが制限を超える問題を解決できます。原理は、元のテキストをいくつかの小さな断片に切り分け、各断片に対してクエリの質問を使用し、生成されたどの結果がクエリに最も関連しているかを計算することです。質問は元のテキストの一部にのみ関連しており、分割された断片間の質問に対する回答は相互に依存しないことが前提となります。ただし、この方法にはシーンの制限が強く、効果は平均的です。

そこでNBCEが誕生しました。 NBCE (Naive Bayes-based Context Extension) は、Naive Bayes Context Extension です。 NBCE に適用できる主なシナリオは次のとおりです。予測される答えがいくつかのフラグメントに分割できると仮定すると、各フラグメントは 1 つのコンテキストにのみ依存します。これは、LLM のコンテキスト処理長を拡張するための素朴ベイジアンの考え方に基づいており、プラグアンドプレイ、モデルに依存しない、微調整の必要がない、線形効率、および実装が簡単であるという利点があります。

では、長いコンテキストを処理するためのより一般的な解決策はあるのでしょうか?

現在、業界では位置補間方式がより頻繁に使用されています。最もオリジナルの Transformer では、同じトークン、つまり入力 x の埋め込みを異なる位置で行うために、入力埋め込みベクトルの絶対位置エンコーディングの方法が使用されることがわかります。各埋め込みベクトル絶対位置に基づくデルタ三角関数が次元成分に追加されます。

しかし、この方法はコンテキスト長の上限をそのまま拡張することになるため、生成効果が大幅に低下してしまう。したがって、一部の学者は、クエリベクトルに重み行列 Q を乗算し、キーベクトルに行列 K を乗算し、位置ベースの三角関数の増分を乗算すること、つまり RoPE 符号化を提案しています。これは同じことです。 q および k ベクトルは、異なる位置で異なる角度で調整されます。

このエンコードに基づいて、ベクトルの各次元の距離システムがさらに調整され、位置補間のコンテキスト長拡張方法が形成されます。この方法はより汎用性が高く、チューニングには少量の長いテキストデータのみが必要です。もちろん、ロングコンテキスト強化の技術はまだ発展途上であり、チューニングを必要とせず、より汎用的な他の方法も登場しています。

4 今後の展望

過去 6 か月で、私たちは数百のモデルの戦争を経験しました。オープンソースコミュニティでは新しい大規模なモデルが時折登場し、関連テクノロジはますます標準化され、同種化しています。特にLLaMAシリーズでは、ラマはラマ、アルパカはアルパカ、ビキューナは小型アルパカなど、「ラクダ」の英単語をたくさん学びました。なぜラクダにちなんで名付けられた大きな言語モデルがこれほどたくさんあるのでしょうか?

Large Language Model の略語が LLM であるため、メタカンパニーは 2 つの L を一緒に発音するのが難しいと考え、ラマを意味する類似の単語 llama を選択しました。その後、この大規模なオープンソースモデルに基づいて調整された多くのオープンソースモデルには、ラクダの名前が付けられました。

同時に、OpenAIを除くシリコンバレーの大型モデルスタートアップの今回のラウンドでは、資金の3分の1近くがMLOpsとLMOpsのツールとプラットフォームの方向に投資されていることがわかります。

海外ではLLaMAシリーズ、中国では独立系のオープンソースモデルが続々と登場し、高品質なオープンソースモデルが市場に氾濫し、この状態はしばらく続くだろう。ただし、パラメータの数が少ない Dolly 12B などのモデル自体の同質性により、平均的な効果を持つモデルは完全に沈黙します。同時に、クローズドソースモデルは、マルチモーダルまたはよりインテリジェントな方向に焦点を当てます。

業界の大型モデルも短期的なブームとなるだろう。将来的には、新世代の超強力なモデルが業界の大型モデルの機能をカバーし、その開発の勢いが阻害されることになります。画期的な出来事は、金融分野における GPT-4 の能力が、特別に訓練された BloombergGPT を上回ったことです。説明の 1 つは、大規模なモデルは何兆ものトレーニングコーパスのサポートを受けて業界全体の知識を獲得していますが、適切な刺激方法が欠けているということです。もちろん、これは私たちの基本的な判断ですが、業界、特に企業の内部知識ベースには依然として価値があり、徹底的に蓄積する価値があります。

最後に、LMOps プラットフォームは依然として重要です。企業はコストを懸念しているため、大規模なモデルを独自に開発しようとしなくても、LMOps プラットフォームの使用と運用には、集中的な構築と大規模な運用によってもたらされるコスト上の利点が依然としてあります。