LLMデータコストの内訳：LLMのトレーニングにかかるデータコストのすべて

1. はじめに

大規模言語モデル（LLM）の急速な発展に伴い、ますます多くの企業がLLMを実際のビジネスに適用することを検討しています。しかし、LLMを実装する過程で、データコストはしばしば無視できない重要な要素です。意思決定者として、LLMトレーニングのさまざまな段階におけるデータ要件と関連コストを理解することは、プロジェクトの成功に不可欠です。

ABAKA AIは、LLMトレーニングの3つの主要な段階である事前トレーニング、教師ありファインチューニング（SFT）、および人間のフィードバックからの強化学習（RLHF）を詳細に調査し、各段階のデータ要件の特性とコストへの影響を分析します。データ量、データ品質、データの多様性などの複数の側面からLLMデータコストの構成を詳細に解釈し、モデルのパフォーマンスを確保しながらデータ投資を最適化する方法についても説明します。

LLMアプリケーションの調査を始めたばかりの企業幹部であれ、AI分野ですでに実績を上げている技術リーダーであれ、私たちは、AI実装の決定を容易にし、過去の経験を活かしてコスト計算のフレームワークを整理するのに役立つ、包括的で実用的なLLMデータコスト評価フレームワークを提供します。

2. 事前トレーニング段階

2.1. データセット規模の推定

計算予算Cが与えられた場合に、必要な事前トレーニングデータセットのサイズを推定することは、LLMプロジェクトを実装する最初のステップです。このプロセスには、さまざまなスケーリング則が関係しており、最も有名なのはOpenAIのスケーリング則とDeepMindのChinchilla則です。

2020年に発表されたOpenAIの研究では、最初のスケーリング則が提案され、モデルのパフォーマンスとモデルのパラメータ数、データセットサイズ、および計算リソースの間にべき乗則の関係があることが示されました。しかし、2022年にDeepMindが提案したChinchilla則はこれを修正し、最適なデータ量はモデルのパラメータ数に匹敵するべきであると主張しました。

OpenAIスケーリング則:

DeepMindスケーリング則:

これらの式は、モデルのパフォーマンス（$L$または$\hat{L}$）とモデルのパラメータ数（$N$）およびデータセットサイズ（$D$）の関係を表しています。

これら2つの式は、LLMのスケーリング動作に関する異なる理解とモデリング方法を表しています。実際のアプリケーションでは、モデルサイズとデータ量のバランスをとる必要があることがよくあります。たとえば、推論コストを削減するために、より多くのデータを持つより小さなモデルの使用を検討できます。Hoffmannら[1]の研究によると、固定された計算予算の下では、十分にトレーニングされた小さなモデルは、トレーニングが不十分な大きなモデルよりもパフォーマンスが優れている可能性があります。具体的には、当初8Bパラメータのモデルをトレーニングする予定だったが、推論コストを削減したい場合は、パラメータの少ないモデル（7Bなど）に置き換え、トレーニングデータ量を増やすことを検討できます。このアプローチは、モデルのパフォーマンスを維持または向上させるだけでなく、展開および運用コストを大幅に削減する可能性もあります。

データ予算の最初のステップは非常に重要であり、モデルのサイズと必要な事前トレーニングデータセットのサイズを決定します。ABAKA AIは、高品質のデータセットを構築できるだけでなく、ニーズに応じてより適切なデータを正確に照合できる、より多くのストックデータも保有しています。

2.2. マルチドメインデータ比率

事前学習コーパスには、Webページ、学術資料、書籍、法律文書、年次財務報告書、医療教科書、その他のドメイン固有のデータなど、さまざまな分野の関連テキストなど、さまざまな種類のテキストデータを含めることができます。事前学習段階では、LLMは大規模なラベルなしテキストデータから幅広い知識を学習し、それをモデルパラメータに保存することで、ある程度の言語理解能力と生成能力を獲得します。

一般的な事前学習コーパスは、さまざまなドメインやソースからの大量のテキストで構成される大規模なデータセットです。Liu、Yangらの研究[2]では、一般データをWebページ、言語テキスト、書籍、学術資料、コード、パラレルコーパス、ソーシャルメディア、百科事典の8つの主要カテゴリに分類しています。モデルの事前学習プロセスでは、データの多様性と品質が重要であるため、事前学習データセットを構築する際には、これらのさまざまなカテゴリのデータの比率を慎重に設計する必要があります。

1. Webデータ: Webデータは、事前学習データで最も広く使用されているソースの1つです。データは通常、ハイパーテキストマークアップ言語（HTML）形式で存在し、特定の構造的特徴を示し、トピックが豊富で、さまざまな分野や分野のコンテンツをカバーしています。ただし、Webデータにはノイズや低品質のコンテンツが含まれている場合もあるため、慎重なスクリーニングとクリーニングが必要です。

2. 言語テキスト: 言語テキストデータは主に2つの部分で構成されています。最初の部分は、書面および口頭言語の幅広いソースに基づいて構築された電子テキストデータであり、通常は特定の言語の大規模なコーパスの形式で提示されます。2番目の部分は、さまざまな分野またはトピックの関連する書面資料に基づいて構築された電子テキストデータです。たとえば、FinGLMは、2019年から2021年までの一部の公開会社の年次報告書をカバーしています。このタイプのデータは、金融分野の言語テキスト資料に属します。

3. 書籍: 書籍データも、事前学習コーパスで一般的なデータタイプの1つです。Webページと比較して、書籍はテキストコンテンツが長く、データ品質が高いため、どちらも大規模言語モデルのパフォーマンス向上に役立ちます。書籍データは、深さと幅の両方を備えた知識を提供し、モデルがより深い文脈情報を学習しながら理解能力と知識の蓄積を向上させることを可能にします。

4. 学術資料: 学術資料データとは、学術論文、学術雑誌記事、会議論文、研究報告書、特許など、学術分野に関連するテキストデータを指します。これらのデータは、学界の専門家や学者によって執筆および公開されており、高い専門性と学術的厳密さを備えています。これらを事前学習コーパスに含めることで、より正確で専門的な情報を提供し、モデルが学術分野内の用語や知識を理解するのに役立ちます。学術文献、論文、教科書は、専門的および技術的な言語使用の例、および最新の科学的発見を提供します。このタイプのデータは、専門分野におけるモデルのパフォーマンスを向上させるために特に重要です。

5. コード: コードデータカテゴリとは、Python、Java、C++などのプログラミング言語を含むテキスト情報を指し、その目的は、モデルがプログラミング言語とコード構造をよりよく理解するのを助けることです。コードデータセットは、プログラミング能力を高めるだけでなく、論理的推論能力を向上させる可能性もあります。このタイプのデータにより、LLMはさまざまなプログラミング言語でコードを理解および生成でき、ソフトウェア開発およびコード分析タスクのサポートを提供します。

6. パラレルコーパス: パラレルコーパスデータとは、異なる言語のテキストまたは文のペアのコレクションを指します。これらのテキストペアは互いに翻訳されており、一方のテキストはソース言語（英語など）で、対応するテキストはターゲット言語（中国語など）です。パラレルコーパスデータの導入は、大規模言語モデルの機械翻訳能力とクロスリンガルタスクのパフォーマンスを向上させるために不可欠です。

7. ソーシャルメディア: ソーシャルメディアデータとは、さまざまなメディアプラットフォームから収集されたテキストコンテンツを指し、主にユーザーが生成した投稿、コメント、ユーザー間の会話を含み、非公式で口語的な言語使用を反映しています。スラング、新語、多様な表現が大量に含まれています。ソーシャルメディアデータには、偏見、差別、暴力などの有害な情報が含まれている可能性がありますが、大規模言語モデルの事前学習には依然として重要です。これは、ソーシャルメディアデータが、モデルが会話コミュニケーションにおける表現能力を学習し、社会的傾向、ユーザーの行動パターンなどを把握するのに有益であるためです。

8. 百科事典: 百科事典データとは、百科事典、オンライン百科事典ウェブサイト、またはその他の知識データベースから抽出されたテキスト情報を指します。オンライン百科事典ウェブサイトのデータは、専門家、ボランティア、またはコミュニティの貢献者によって執筆および編集されており、ある程度の権威と信頼性があります。アクセスしやすいため、事前学習コーパスに高い頻度で含まれており、大規模言語モデルの知識ベースを強化するための基礎となっています。

この事前学習データを合理的に構成することで、LLMのパフォーマンスと適用性を大幅に向上させることができます。データの品質と多様性は、多くの場合、データの量よりも重要です。高品質で多分野にわたるデータ比率の必要性に基づき、ABAKA AIは、事前学習データセットを設計する際に各種類のデータの特性と価値を慎重に検討し、特定のニーズに応じて比率を調整して、高品質で正確な事前学習データセット比率を達成し、モデルのトレーニングコストを削減するのに役立ちます。

この画像は、事前学習中にさまざまなモデルで使用されるコーパスのデータ型の分布を示しています。各円グラフはモデルを表し、さまざまなデータ型の割合を示しています。さまざまなデータ型は、Webページ、コード、百科事典、書籍、学術資料、ソーシャルメディア、言語テキスト、多様なデータなど、さまざまな色で区別されます。

2.3. トレーニングデータの取得

オープンソースのデータセットはモデルトレーニングの基盤を提供しますが、本当に価値がありユニークなデータの多くは、多くの場合、公開チャネルには表示されません。したがって、特定のドメインまたはソースからデータをターゲットを絞ってクロールすることは、モデルのパフォーマンスと競争力を向上させるための重要な戦略となっています。この部分のデータの取得は非常に必要です。高品質のトレーニングデータ取得に関して、ABAKA AIは、ターゲットを絞った取得において、より深い洞察、より高い適時性、およびよりユニークなデータを提供し、垂直ドメインでのモデルのパフォーマンスと精度を向上させ、最新の情報とトレンドに対するモデルの理解を深めるのに役立ちます。

ターゲットを絞ったデータ取得のチャネルには、通常、データクロール、商用データベースのサブスクリプション、データ協力と交換などが含まれます。Webクローラーを除き、他のチャネルはあまりにもカスタマイズされているため、このセクションではデータクロールの関連コンテンツのみを説明します。データクロールはインフラストラクチャに対する要件が高くないため、以下の計算では開発コストのみを考慮します。

開発の前に、さらに重要なのは、適切なデータソースを選択することです。適切なデータソースからクロールすることで、特定のドメインにおけるモデルのパフォーマンスを大幅に向上させることができます。データソースを決定した後、開発とクロールのコストは主に次の側面から発生します。

• 開発コスト：

ここで、$D_{initial}$と$D_{update}$は、それぞれ初期開発とWebサイト更新後のクロールコードの更新にかかる時間です。Webサイトの複雑さ、検証メカニズム、リクエストの複雑さなどが開発時間に影響します。

• 維持費：

メンテナンスコストは常勤ではない場合があるため、係数$\alpha (0 < \alpha \le 1)$を導入して、必要な実際のメンテナンス時間の割合を表すことができます。データが継続的な更新を必要とする場合や、クロール期間が非常に長い場合は、クローラーを正常に実行し続け、Webサイトの変更に対応するためにメンテナンス担当者の介入が必要です。クローラーシステムが分散戦略を使用している場合は、より多くのメンテナンスサポートが必要になる場合があります。

• IPプロキシプール：

ここで、$N_{req}$はリクエストの総数、$N_{req_per_ip}$は各IPが処理できるリクエストの数、$C_{ip}$は各IPの単価です。WebサイトのIP制限ポリシー、総データ量、IP品質、IP地理的位置要件、プロキシタイプなどの要因が価格に影響します。

• クロール材料費：

ここで、$C_{mem}$と$N_{mem}$は必要なメンバーシップの数とメンバーの数、$D_{mem_validity}$はメンバーシップの有効期間（日数）です。メンバーシップレベル、同時実行戦略などの要因が最終的な予算に影響します。ターゲットWebサイトがダウンロードに登録またはメンバーシップを必要とする場合は、このコストを考慮する必要があります。

したがって、全体として：

一般的に言えば、垂直ドメインのウェブサイトは難易度に応じて15,00ドルから15,000米ドルの費用がかかり、大規模なソーシャルネットワーキングサイトはさらに費用がかかります。ABAKA AIは、より深い洞察、より高い適時性、よりユニークで高品質のデータを提供し、総取得コストを70％削減して、さまざまな側面で優れた大規模言語モデルをトレーニングするのに役立ちます。

2.4. 文書情報抽出

高品質なLLM事前学習データの多くは、PDFやスキャン画像の形式で存在します。レイアウトやフォーマットの多様性、スキャン画像の品質のばらつきにより、このデータを利用してデータセットを構築することは困難な作業であり、このコンテンツをマークダウンなどのデータ形式に変換して使用する必要があります。中心的な問題は主に、コンテンツ情報とレイアウト情報（本文、タイトル、図キャプション、画像、表、数式）の抽出と、レイアウト要素間の関係の処理という2つの側面に集中しています。

複数のオープンソースデータセットを処理する際、ABAKA AIはPP-StructureV2、Marker、Vary、Nougatなど、いくつかの優れたオープンソースソリューションを観測しましたが、それぞれに欠点があります。PP-StructureV2はLaTeX形式のコンテンツを識別できず、必要な後処理ステップが欠けています。Markerは対応言語が少なく、図の処理が苦手です。Nougatは複数列データのサポートが限られており、識別できる言語も限られています。一方、Vary / Vary-toyはより多くの計算リソースを消費します。

これらの状況に基づき、ABAKA AIは、Multimodal Art Projection（M-A-P）チームのメンバーとして、完全にオープンソースの大規模言語モデルMAP-Neoの構築に全面的に参加し、Document Convert Pipelineもオープンソース化しました。このパイプラインは、パフォーマンスと計算オーバーヘッドのバランスをより良く取ることができ、モジュール間の分離により解釈性が向上し、さまざまなモジュールのアップグレード、追加、置換が容易になり、より柔軟で効率的でCPUに優しいソリューションを提供します。

変換にモデルを使用する以外に、mathpix、Doc2x、Paodin PDFlux、pix2text、X Information、X Xun Cloud Large Model Knowledge Engine Document Parsingなど、多くのベンダーが同様のサービスを提供しています。したがって、以下にコストを計算する2つの方法を示します。

• 自社構築の変換サービス費用：

ここで、$N_{pages}$はドキュメントの総数、$R_{process}$は1ノードあたり1日に処理されるドキュメントの数、$C_{node}$は1ノードあたりの1日あたりの価格、$F_{complexity}$はドキュメントの複雑さの係数（$0 \le F_{complexity} \le 1$）です。一般的に、雑誌や新聞のレイアウトやフォントはより複雑になり、文献や特許は画像や表が豊富になります。これらの要因は、予算を指定する際に考慮する必要があります。$C_{integration}$は、展開、更新戦略/モデル、およびメンテナンスのコストです。この部分のコストは、タスクによって大きく異なります。

• サードパーティのサービス費用：

ここで、$n$は価格帯の数、$C_{tier,i}$はi番目の価格帯のページあたりの価格、$N_{pages,i}$はi番目の価格帯のページ数、$C_{integration}$はAPI統合とメンテナンスのコストです。

これらの方法の選択は、文書の数と種類、必要な変換品質、内部リソースの可用性、予算の制約など、複数の要因によって決まります。実際、ほとんどの場合、簡単なデータは自社のサーバーを使用して変換され、難しいデータは商用グレードのサービスを使用します。

2.5. トレーニングデータのクリーニング

Webクロール、ドキュメント変換、オープンソースデータセットを通じて取得した生データは、モデルトレーニングの基盤を提供しますが、このデータには通常、ノイズ、エラー、バイアス、誤った情報が含まれており、モデルのトレーニング効果を低下させます。したがって、データクリーニングは、モデルのパフォーマンスと信頼性を向上させるための重要なステップになります。高品質のデータを取得するために、ABAKA AIは、よりクリーンで洗練されたデータクリーニングを提供し、データ品質を大幅に向上させ、それによって特定のタスクに対するモデルのパフォーマンスを向上させ、複雑なパターンを理解するモデルの能力を強化し、データの問題による誤解を招く学習を減らすことができます。

クリーニングを開始する前に、さらに重要なのは、適切なクリーニング戦略を策定することです。これには、データの特性、モデルの要件、および潜在的なデータ品質の問題を完全に理解する必要があります。クリーニング戦略の策定では、データ規模、複雑さ、ドメインの特性などの要因を考慮する必要があります。コスト見積もりに関しては、ABAKA AIとGe Zhangら[3]が共同で参加したMAP-Neo大規模モデルのMatrixデータセットを例にとると、Matrixデータセットは4.7Tトークンのデータをリリースし、これは最高品質で最大規模のバイリンガルデータセットの1つと言えます。Matrixデータセットのデータクリーニングの一般的なアプローチは、「粗から密へ」および「単純から複雑へ」の原則に従います。クリーニング手順は、次の主要な段階に分けることができます。

1. ヒューリスティックフィルタリング：ヒューリスティックルールフィルタリングは、低品質のデータを迅速に特定して削除することを目的とした最初の防衛線です。このステップは計算コストが低いですが、後続の処理のためのデータ量を大幅に削減できます。フィルタリング基準には、URL、ブラックリスト単語テーブル、意味不明なテキストフィルター、ドキュメントの長さ、特殊文字の割合、短く、連続した、または不完全な行の割合、繰り返される単語、n-gramまたは段落が含まれます。フィルタリングのしきい値は、大規模なドキュメントサンプルの統計分析に基づいています。ヒューリスティックルールは、低品質のデータを効果的に特定して削除し、低品質の事前トレーニングコーパスがモデルのパフォーマンスに影響を与えるのを防ぐことができます。チームは複数のソースからの複合データを使用したため、データの多様性に基づいて、チームは各メソッドのクリーニング方法と調整されたルールを特別に設計して、データ品質の一貫性を維持しました。

2. データ重複排除：多くの研究で、反復的なテキストがモデルのパフォーマンスの低下につながる可能性があることが示されており、重複排除はコーパス処理の重要なステップとなっています（この点は多少議論の余地がありますが、より反復的なデータは、この部分のデータが高品質であることを正確に示している可能性があり、これは重要な特徴です。たとえば、Finewebの見解では、重複排除が多いほどパフォーマンスが向上するとは限らず、ダンプ間で重複排除を実行すると、実際にはパフォーマンスが悪化する可能性があります）。 a. 完全な重複：完全なドキュメントの重複排除は、テキスト全体が別のテキストと完全に同一であるかどうかを評価するために使用される方法です。完全に同一であることが判明した場合、重複は削除されます。データ量が多いため、処理にはクラスターを使用する必要があり、メモリ不足の問題も発生する可能性があります。実際には、テキストデータをバッチで異なるストレージバケットに保存します。次に、各ストレージバケットのデータを順番に処理して重複を削除します。 b. ほぼ重複：ほぼ重複については、MinHash LSH重複排除法を使用して可能な限り削除します。これは特にWebデータに適しており、大規模なデータセットでの類似性検索や重複検出で広く使用されています。テキストの内容は基本的に同じですが、Webページの散在するテンプレートブロックが異なるという非常に一般的なシナリオを処理できます。MinHashの原則は、セットをより小さなハッシュ値で表し、次にこれらのハッシュ値を使用して2つのセット間のジャカード類似性を推定することです。このステップの計算コストは依然としてかなり高いです。 c. 類似行：テキスト内で同じコンテンツが複数回出現する問題を解決するために、直接的な方法は、特定の区切り文字を使用してテキストを複数の行に分割し、各行間の類似性を比較することです。類似している場合は、後続の行が削除されます。 d. さらに、より良い結果を得るために、段落の重複排除と部分文字列の重複排除も実行されました。

3. 品質スクリーニング：データクリーニング後、Fineweb-eduはLLama3-70B-Instructモデルを使用してデータにスコアを付け、Bertのような分類モデルをトレーニングしました。その後、分類モデルを使用してデータをフィルタリングし、データ品質を大幅に向上させました。データ品質スクリーニングにモデルを使用する以外に、多くの開発者はCCデータセットをクリーニングする際にfasttextモデルを言語識別に用いています。

上記の手順に基づいて、データクリーニングのコストを計算できます。

• エンジニアのデバッグとルール決定コスト：

ここで、$S_{eng}$は開発者の日給、$T_{rules}$と$T_{debug}$はルールの策定と最適化に必要な時間（USD/日）です。

• ストレージコスト：

F ここで、$C_{storage}$は1TBあたりの月額ストレージコスト、$V_{data}$は総データ量（TB）、$T_{retention}$はデータ保持期間（月）です。

• 計算コスト：

ここで、$i$は処理段階（1からn）を表し、$C_i$はi番目の段階の計算リソースの単価（USD/日）、$V_{data,i}$はi番目の段階のデータ量（TB）、$R_i$はi番目の段階の処理速度（TB/日）、$\beta_i$はi番目の段階がクラスター処理を使用するかどうかを示すバイナリインジケーター（単一ノード処理の場合は0、クラスター処理の場合は1）、$F_{comm}$と$F_{ops}$はクラスターを使用する場合の通信および運用オーバーヘッドです。クラスターの使用は面倒でコストがかかるため、最初のステップとしてヒューリスティックフィルタリングを使用します。

• 品質スクリーニング：

ここで、$C_{train}$と$C_{inference}$はトレーニングと推論の計算コストであり、通常は価格が大幅に異なります。$T_{training}$はトレーニング時間（日数）、$C_{data_annotation}$は注釈コスト、$\frac{V_{data}}{R_{inference}}$はすべてのデータの推論を完了するために必要な時間を示します。

2.6. データコストの計算

高品質のデータ処理にはコストがかかります。データ取得から最終的なクリーニングプロセスまで、各ステップには複雑な計算と人的資源への投資が含まれ、そのすべてが実際のコストに変換されます。この章では、ABAKA AIの以前のコンテンツと豊富な経験を組み合わせて、LLMを実装する際のデータコストの計算に役立つ実行可能なアイデアをいくつか提供します。

前述のデータ処理フローに基づき、データコストを大まかに次の主要カテゴリに分類できます。ストレージコスト、データ取得コスト、データ変換コスト、およびデータクリーニングコストです。ABAKA AIの過去の豊富な経験を通じて、直感的な予算システムを確立するのに役立つことを願っています。

1. ストレージコスト：この分野では、データ規模は一般的なプロジェクトよりもはるかに大きく、事前トレーニングデータセットはPBレベルに達します。単一のマシンではこのような大規模なデータストレージのニーズを満たすことができず、プロジェクトには高い帯域幅要件もあります。したがって、一般的に分散ストレージが使用されます。分散ストレージは水平方向の拡張を容易にし、増大するストレージニーズを満たすことができ、データバックアップとフォールトトレランスメカニズムを備えているため、高いデータ信頼性が保証されます。マルチノードの並列読み取り/書き込みもI/Oパフォーマンスを向上させることができます。一般的に、分散ストレージの容量価格は約85 USD/T（NVME + HDD）であり、これは1PBの利用可能なストレージスペースのコストが約85,000 USDであることを意味します。セキュリティの冗長性とネットワーク機器、セキュリティ機器を追加すると、コストは99,000 USD/PBに近づきます。

2. データ取得：有名な大規模ウェブサイトのすべての履歴データは、約42,500〜70,500米ドルと見積もられ、増分更新には年間約14,000米ドルの費用がかかります。垂直ドメインのウェブサイトの場合、4,200〜14,000米ドルの範囲になる可能性があります。ビデオウェブサイトは、通常のウェブサイトよりも3〜5倍高価です（帯域幅、ストレージ）。海外のウェブサイトは2〜3倍高価です（海外プロキシ、海外サーバー、コンプライアンス）。8つの主要なソーシャルメディアおよびニュースウェブサイトと15の垂直ドメインウェブサイト（コード、数学、金融など）をクロールする必要があると仮定すると、706,000米ドルの予算が適切です。

3. 文書情報抽出：ABAKA AIの経験に基づくと、ABAKA AIが開発したパイプラインを文書変換に使用する方が、費用対効果が高く、柔軟性があります。コンシューマーグレードのGPUを変換に使用する場合、1ページあたりのコストは約0.000035米ドルで、mathpixの1ページあたり0.025/0.01米ドルよりもはるかに低くなります。もちろん、現在、多くの優れた国内メーカーがこの分野で試みており、国内のサービスプロバイダーからより良いモデルとより安い価格が提供されることを期待しています。全体として、Gapとデバッグの時間を含め、10,000,000ページの文書ごとに約14,000米ドルを見積もります（80％は独自のモデルを使用+ 20％はサードパーティのサービスを使用）。

4. データクリーニング：このステップのコストは、主にデータソースの数とそのドメインに依存します。非常に汚れたデータを処理する場合、ABAKA AIは1,000を超えるコアを約1か月間使用し、より高品質のデータを取得するために多くの特別なルールを追加しました。データ保持率は1％未満でした。したがって、この部分のデータは次のように計算できます。

つまり、各ドメインのデータクリーニング費用は、アルゴリズムエンジニアの2週間分の給与と、クラスターが設定されている場合にデータクリーニング費用がデータ量に比例して増加すると仮定して、100Tごとに2,800米ドルのクリーニング費用で構成されます。たとえば、Fineweb-eduがLlama3-70BおよびBertライクモデルを使用しているように、価格も非常に手頃で、100Tあたりのコストをわずかに上げるだけです。

要約すると、LLMの事前学習データの準備は、複雑で費用のかかるプロセスです。データ取得、ストレージ、文書情報抽出、データクリーニングなど、複数の段階があり、それぞれに慎重な計画と多額の投資が必要です。データの品質と多様性は、モデルの最終的なパフォーマンスにとって非常に重要であるため、各段階は予算の制約内で可能な限り最適化する必要があります。同時に、経験豊富なアルゴリズムエンジニアの価値は見過ごせないことがわかります。彼らの経験と専門知識は、チームが多くの潜在的な落とし穴や回り道を回避するのに役立ちます。LLMプロジェクトでは、人的資源の問題による回り道のコストは驚くほど高くなることが多く、かなりの時間とリソースの浪費につながる可能性があります。

3. SFTおよびRLHFステージ

大規模言語モデル（LLM）のトレーニングプロセスにおいて、教師ありファインチューニング（SFT）と人間のフィードバックからの強化学習（RLHF）は、密接に関連する2つの重要な段階です。これら2つの段階は、技術的な実装と特定の目的において異なりますが、データ要件とコスト構成の点で大きな類似点を共有しています。この章では、これら2つの段階を組み合わせて説明します。これは主に、それらのコアコストがデータ注釈と要件定義に集中しているためであり、この特性により、データ準備とコスト見積もりにおいて多くの共通点が生まれます。

3.1. SFTデータセットの特性

SFTデータセットは、「指示入力」と「回答出力」を含む一連のテキストペアで構成されています。「指示入力」は、人間がモデルに対して行う要求を表し、分類、要約、書き換えなど、さまざまなタイプをカバーしています。「回答出力」は、指示に基づいてモデルが生成する応答であり、人間の期待に応えます。指示ファインチューニングデータセットを構築するには、手動作成、Self-Instructメソッドなどのモデル生成、既存のオープンソースデータセットの収集と改善、および上記の3つの方法の組み合わせの4つの方法があります。

人工的に生成されたデータセットを構築するには、一般的に2つのアプローチがあります。最初のアプローチは、会社の従業員、ボランティア、注釈プラットフォームのスタッフなどが、与えられた要件とルールに従って指示テキストセットを直接作成することです。指示セットの設計、注釈ガイドラインの作成、または実際のデータ注釈と品質管理の実施にかかわらず、多大な人間の時間と労力が必要です。たとえば、Databricks-dolly-15kデータセットの作成には、何千人ものDatabricks従業員が関与し、複数の指示カテゴリにわたって15,000を超えるレコードを生成しました。2番目のアプローチは、Webページから人間が生成した実際の質疑応答データをスクレイピングし、それを指示形式に標準化することです。例としては、InstructionWild、v2LCCC、Zhihu-KOLなどのデータセットがあり、これらはソーシャルチャット、コード関連のQ&A、その他のソースからのコンテンツを集約および整理してデータセットを構築します。

ABAKA AIの過去の実践では、データセットを構築するために最初のアプローチがより一般的に使用されてきました。一方、Liu、Yangら[2]は、専門の注釈者による処理とレビューにより、この方法で構築されたデータセットは高品質でクリーンであると考えています。人間による処理後、これらのデータセットはより解釈しやすくなり、人間の理解とより一致するため、説明可能性が高まります。研究者はトレーニングサンプルを柔軟に制御でき、さまざまなタスクに応じて調整できるため、より汎用性が高くなります。

3.2. RLHFデータセットの特性

RLHFデータセットは、同じ入力プロンプトに対する複数の応答の優先度評価を提供する指示のコレクションです。通常、人間や他のモデルからのフィードバックを含む、異なる応答を持つ指示ペアで構成されます。この設定は、特定のタスクまたはコンテキストにおける異なる応答に対する人間またはモデルの相対的な好みを反映しています。優先度データセットのフィードバック情報は、通常、投票、ランキング、スコアリング、またはその他の比較形式で表現されます。

優先データセットは、主に大規模モデルのアライメント段階で使用され、モデルの出力を人間の好みや期待に近づけるのに役立ちます。人間の好みとのアライメントは、主に3つの側面で反映されます。実用性（指示に従う能力）、誠実さ（情報の捏造を避ける）、安全性（違法または有害な情報の生成を避ける）です。

RLHF（人間のフィードバックからの強化学習）とRLAIF（AIのフィードバックからの強化学習）はどちらも、フィードバック信号を使用してモデルを最適化するために強化学習手法を利用します。指示データセットによる微調整に加えて、優先データセットを使用して報酬モデルをトレーニングできます。その後、近接ポリシー最適化（PPO）アルゴリズムを適用して、報酬モデルからのフィードバックに基づいてさらに微調整できます。

3.3. データコストの計算

SFTおよびRLHF段階では、データコストは主に以下の側面から発生します。

• ルール設計コスト：

この中で、$R_{x} (0 < R_{x} \le 1)$は参加率を表します。アルゴリズムエンジニア$S_{expert}$はモデルの能力の境界を理解し、ドメインの専門家$S_{expert}$は専門的な知識と洞察を提供し、$S_{user}$は最前線の使用シナリオと要件のフィードバックを提供します。このステップは必要かつ重要です。慎重に設計されたルールはデータ品質を大幅に向上させ、モデルのパフォーマンスに直接影響を与え、優れたルール設計は注釈効率を高め、手戻り率を低下させることができます。詳細なルール設計プロセスは初期コストを増加させる可能性がありますが、その価値はこれらの費用をはるかに上回ります。データとモデルの品質を向上させるだけでなく、プロジェクト全体と組織に長期的な利益をもたらします。

• 指示データセット構築コスト：

ここで、$N_{instructions}$は指示の総数、$R_{creation_speed}$は注釈者が1時間あたりに作成できる指示の数、$S_{annotator}$は注釈者の平均時給、$R_{review}$はレビューのサンプリング率、$S_{reviewer}$と$R_{review_speed}$はそれぞれレビュー担当者の平均時給とレビュー担当者が1時間あたりにレビューできる指示の数です。

• RLHFデータセットの構築コスト：

最初の部分は応答を生成するための推論コストであり、2番目の部分は手動注釈のコストです。注釈方法と戦略の選択は、$\alpha$に大きく影響します。たとえば、$N$個の応答をペアで比較する必要がある場合、手動注釈のコストは次のようになります。

評価システムの場合は、$R_{rank_speed}$が大幅に増加するため、適切な評価方法を選択することがRLHFデータセットを構築する上で重要な要素となります。データ品質に影響を与えるだけでなく、コスト構造を直接決定します。レビュー戦略の選択と方向性も同様にコストに大きな影響を与えます。これらの要因の複雑さと相互作用を考慮すると、普遍的なコスト式を提供することは確かに困難であり、そのため特定の式は提示していません。

実際には、完全なデータセットに拡張する前に、小規模なパイロットテストを通じて評価および監査戦略を検証および最適化する必要があることがよくあります。この反復的なアプローチは、コストを最適化するのに役立つだけでなく、プロセス全体を通じてデータ品質と注釈ガイドラインを継続的に改善します。

ABAKA AIの過去の経験に基づくと、1,000問のIMOレベルの数学の問題を収集すると仮定すると、需要はすでに十分に確立されているため、主なコストは注釈と監査に集中します。注釈者のコストは1時間あたり20米ドルで、推定レートは1時間あたり1問です。その他の費用を含めると、予算は28,000米ドルと見積もられます。ただし、ABAKA AIのRLHFデータ構築方法を採用し、LEANなどの最新の証明ツールを利用すると、処理効率は応答構築よりもはるかに高くなり、1時間あたり約4〜6ペアを処理できます。

この時点で、要件に応じてデータ価格を評価できる包括的な評価システムを確立しました。

たとえば、上司がモデルに特定のドメインの知識を持たせたい、あるいはその分野で最先端になりたいと考えている場合、知識を追加するためにCPTを選択できます。D-CPT法[4]とREGMIX[5]に基づいて、約100Bのドメインデータが必要になる可能性があると計算できます。12のターゲットWebサイトをクロールして70Bのデータをカバーし、残りの30Bは公開データセットからフィルタリングできます。CPTの後、数千のSFTデータポイントを追加できます。データ部分は約42,000米ドルの費用がかかる可能性があり、これには、12のWebサイトからのデータクロールに約28,000米ドル、deepseek mathメソッドを使用して数十TBのデータをダウンロードおよびフィルタリングするのに約2,800米ドル、エントリあたり約6米ドルでSFTデータを構築し、2,000エントリで合計12,000米ドルが含まれます。

上記の見積もりは、現在の市場データとABAKAの長年の業界経験に基づいており、全体的なデータコスト費用をより直感的に見積もるのに役立つ、最も一般的な予算範囲のフレームワークを提供します。

ABAKA AIは、上記のフレームワークに基づいて、さまざまな段階で40％〜60％のコストを削減できます。高品質のトレーニングデータセットを構築する過程で、ABAKAは豊富なデータ処理経験に基づいて専門的なソリューションを提供します。ABAKA AIが提供するインテリジェントなデータエンジニアリングプラットフォームAbaka Forge Platformと高度に専門化され、標準化されたデータ処理サービスは、トレーニングデータの構築を強化し、高品質のデータセットを使用してLLMをトレーニングするのに役立ち、プロジェクトに必要なリソースと投資をよりよく理解できるようにします。

4. 参考文献

1. Hoffmann, Jordan, Sebastian Borgeaud, Arthur Mensch, Elena Buchatskaya, Trevor Cai, Eliza Rutherford, Diego de Las Casas, et al. "Training Compute-Optimal Large Language Models." arXiv, March 29, 2022. http://arxiv.org/abs/2203.15556.

2. Liu, Yang, Jiahuan Cao, Chongyu Liu, Kai Ding, and Lianwen Jin. "Datasets for Large Language Models: A Comprehensive Survey." arXiv, February 27, 2024. http://arxiv.org/abs/2402.18041.

3. Ge Zhang, Scott Qu, Jiaheng Liu, Chenchen Zhang, Chenghua Lin, Chou Leuang Yu, Danny Pan, et al. "MAP-Neo: Highly Capable and Transparent Bilingual Large Language Model Series." arXiv, June 2, 2024. http://arxiv.org/abs/2405.19327.

4. Que, Haoran, Jiaheng Liu, Ge Zhang, Chenchen Zhang, Xingwei Qu, Yinghao Ma, Feiyu Duan, et al. "D-CPT Law: Domain-Specific Continual Pre-Training Scaling Law for Large Language Models." arXiv, June 3, 2024. http://arxiv.org/abs/2406.01375.

5. Liu, Qian, Xiaosen Zheng, Niklas Muennighoff, Guangtao Zeng, Longxu Dou, Tianyu Pang, Jing Jiang, and Min Lin. "RegMix: Data Mixture as Regression for Language Model Pre-Training." arXiv, July 1, 2024. http://arxiv.org/abs/2407.01492.