専門家混合モデル (MoE) のアーキテクチャとその作動原理を詳細に解説。Mixtral 8X7B、DBRX、Deepseek-v2といった注目のMoEモデルの応用と利点を探索。PythonでMoEモデルを実装し、論理推論、要約、エンティティ抽出などのタスクにおけるパフォーマンスを評価します。

専門家混合モデル（Mixture of Experts, 略してMoE）は、大規模言語モデル（LLMs）の分野で長らく注目されている概念です。これはモデルの効率性やスケーラビリティを飛躍的に向上させるだけでなく、複雑なタスクへの新しいアプローチを提供します。簡単に言えば、MoEモデルは1つの大規模モデルを複数の小規模モデルに分割し、それぞれが特定のタスクやデータタイプに特化します。これにより、タスクを処理する際に関連性のある「専門家」のみが活動し、モデル全体を動かす必要がなくなるため、計算リソースを大幅に節約できます。

この記事で学べること：

• MoEモデルの基本アーキテクチャと動作原理の理解
• Mixtral 8X7B、DBRX、Deepseek-v2といった注目の MoEモデルの仕組みと特徴
• Google Colab上でPythonを使ってMoEモデルを実装する方法
• MoEモデルの論理推論、要約、エンティティ抽出といったタスクにおけるパフォーマンスの評価
• MoEモデルが自然言語処理やコード生成などの複雑な課題でどのような利点と課題を持つかの理解

1 専門家混合モデル (MoE) とは何か？

現在のディープラーニングモデルは主に人工ニューラルネットワークに基づいており、それぞれの層に多数の「ニューロン」が含まれています。各ニューロンは入力データを処理し、簡単な数学演算（例：活性化関数）を行って、その結果を次の層に渡します。さらに高度なモデル、例えば Transformer では、自己注意メカニズムを導入し、データ内の複雑なパターンを捉えることができます。

しかし、従来の密集モデルは全ての入力データを処理する際にネットワーク全体を計算に使用するため、計算コストが非常に高くなります。この問題を解決するため、Mixture of Experts（MoE）モデルではスパースアーキテクチャを採用しており、現在のタスクに関連するネットワークの一部、つまり「専門家」のみを活性化させます。これにより、特に自然言語処理のような複雑なタスクの処理において、計算資源を大幅に削減できます。

例えば、チームプロジェクトでチームメンバーが複数のグループに分かれ、それぞれ異なるタスクに専念する状況をイメージすると、MoEモデルの動作方式が理解しやすくなります。MoEモデルは、複雑な問題を複数のサブタスクに分解し、各サブタスクを特化した「専門家」に担当させる構造です。

1.1 MoEモデルの主な利点：

• 事前学習が高速：従来の密集モデルと比較して、学習プロセスが効率的。
• 推論速度が向上：パラメータ数が同じでも、MoEモデルの推論はより高速。
• VRAM需要が高い：全ての専門家がメモリに格納される必要があるため、グラフィックメモリの要求が高い。

MoEモデルの構成には、主に2つの重要なコンポーネントがあります：**専門家（Experts）とルーター（Router）**です。専門家は特定のタスクに特化した小規模なニューラルネットワークであり、ルーターは入力データを基に関連する専門家を選択的に活性化します。この選択的活性化により、タスクに必要な部分だけが計算に使用され、効率が向上します。

2 代表的なMoEモデル

近年、MoEモデルはAI研究の中で注目を集めております。これは、高いパフォーマンスを維持しながら、大規模言語モデルを効率的にスケールさせることができるからです。その中でも、例えば Mixtral 8x7B は、スパースな専門家混合アーキテクチャを採用しており、入力ごとに専門家の一部だけを活性化させることで、従来の完全密集型モデルに匹敵する性能を発揮しながらも効率を大幅に向上させました。

以下、注目すべきMoEモデルについての詳細を見ていき、それらをGoogle Colabを利用したPythonコードで実装する方法についても学びます。

2.1 Mixtral 8X7B

Mixtral 8X7B は、decoder-only 型の Transformer に基づいたアーキテクチャです。モデルの入力としてはトークンのシーケンスが与えられ、これらのトークンはベクトルに埋め込まれ、次にデコーダ層で処理されます。このプロセスにより、各位置でどの単語が占めるかの確率が生成され、テキスト生成や予測が可能となります。

デコーダ層は、以下の2つの主要部分で構成されています：

1. 注意機構（Attention Mechanism）：コンテクスト情報を統合します。
2. スパース専門家混合 (SMOE) 部分：個々の単語ベクトルを個別に処理します。MLP層（多層パーセプトロン層）は計算資源を大きく消費する部分です。SMOEでは、各入力に対して最も関連性の高い専門家の出力の加重和が活性化されます。この仕組みにより、計算コストの抑制と複雑なパターンの学習を両立しています。

モデルの主な特徴：

• 専門家の総数：8
• 活性化する専門家の数：2
• デコーダ層数：32
• 語彙サイズ：32000
• 埋め込みサイズ：4096
• 各専門家のパラメータ数：56 億（全体に占める一部。残りは共通成分。）
• 活性化パラメータ総数：128 億
• コンテクスト長：32k トークン

Mixtral 8x7B は、テキスト生成、翻訳、感情分析、教育、顧客サービスの自動化などさまざまな分野で優れた性能を発揮します。

2.2 DBRX

DBRX は Databricks が開発した、Transformer に基づく decoder-only 型の大規模言語モデル（LLM）で、次のトークンの予測（Next-Token Prediction）を用いて訓練されました。本モデルは細粒度の専門家混合 (MoE) アーキテクチャを採用しており、総パラメータは 1320 億にのぼりますが、各入力においては 360 億のパラメータのみが活性化されます。このモデルは 12 兆トークンに及ぶテキストとコードデータを用いて事前学習が行われています。他のオープンソースMoEモデル（例えば Mixtral や Grok-1）と比較して、DBRXはより細かい専門家の設計を特徴とし、小型の専門家を多数使用しています。また、専門家数を増やしつつも、必要に応じて活性化される専門家の数を抑えた設計となっています。

2.2.1 アーキテクチャの特徴

• 細粒度の専門家 通常、標準的なFFNレイヤーから専門家混合 (MoE) レイヤーに移行する際には、FFNを複数回コピーして複数の専門家を作成します。しかし、細粒度専門家の場合、より多くの専門家を生成しながらも、パラメータ数を増やさない仕組みが必要です。そのため、単一のFFNを複数のセグメントに分割し、各セグメントを個別の専門家として扱います。DBRXでは16個の専門家のうち4個の専門家が活性化される構造を採用しています。

• 革新技術の採用 本モデルでは、さらなる効率化のために以下の技術が採用されています：

  • 回転ポジショナルエンコーディング (RoPE)
  • ゲーティッド線形単位 (GLU)
  • グループ化クエリ注意 (GQA)

2.2.2 モデルの主な特徴：

• 専門家の総数：16
• 各層で活性化する専門家の数：4
• デコーダ層数：24
• 活性化パラメータ総数：360 億
• 総パラメータ数：1320 億
• コンテクスト長：32k トークン

DBRXモデルは、コード生成、高度な言語理解、数学的推論、プログラミングタスクに関する使用例で優れた性能を発揮します。特に、高精度と効率性が求められる場合、例えばコードスニペットの生成、数学問題の解決、複雑な指示への詳細な解答などでその力を発揮します。

2.3 Deepseek-v2

Deepseek-v2 のMoEアーキテクチャでは、以下の2つの重要なアイデアが活用されています：

1. 細粒度の専門家
   専門家をより細かい粒度に分割することで、専門家が習得する知識をさらに特化させ、より正確な結果を提供できるようにしています。

2. 共有専門家
   特定の専門家を「共有専門家」として指定し、必ず活性化されるよう設計。これにより、様々なコンテクストにおいて汎用的かつ価値の高い知識を収集・統合します。

2.3.1 モデルの主な特徴：

• 総パラメータ数：2360 億
• 活性化パラメータ総数：210 億
• 各層での専門家数：160（その中から2つを選択）
• 各層での共有専門家数：2
• 各層で活性化する専門家数：8
• デコーダ層数：60
• コンテクスト長：128k トークン

このモデルは8.1兆トークンの膨大なデータセットで事前学習が行われ、特に対話に優れた性能を発揮するため、チャットボットや仮想アシスタントとしての用途に最適です。また、文章生成や翻訳、要約といった高品質な文章処理に適しており、コード生成にも効率的に利用可能です。

3 PythonでMoEモデルを実装する方法

MoEモデルは、異なる専門家ネットワークを動的に選択してタスクを処理する高度な機械学習モデルです。以下では、Pythonを使用してMoEモデルをどのように実装するかを説明します。

3.1 ステップ1：必要なPythonライブラリのインストール

まず、必要なライブラリをインストールします：

1
2
3
4
5

!sudo apt update
!sudo apt install -y pciutils
!pip install langchain-ollama
!curl -fsSL https://ollama.com/install.sh | sh
!pip install ollama==0.4.2

3.2 ステップ2：スレッドの有効化

次に、threadingを用いてOllamaサービスを実行します：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

import threading
import subprocess
import time

def run_ollama_serve():
  subprocess.Popen(["ollama", "serve"])

thread = threading.Thread(target=run_ollama_serve)
thread.start()
time.sleep(5)

3.3 ステップ3：Ollamaモデルの取得

例えばDBRXモデルをOllamaから取得：

1

!ollama pull dbrx

3.4 ステップ4：モデルを用いたクエリ

モデルをテストするため、以下のようにクエリを投げます：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

from langchain_core.prompts import ChatPromptTemplate
from langchain_ollama.llms import OllamaLLM
from IPython.display import Markdown

template = """Question: {question}

Answer: Let's think step by step."""

prompt = ChatPromptTemplate.from_template(template)

model = OllamaLLM(model="dbrx")

chain = prompt | model

# 入力データを準備
input_data = {
    "question": '以下の内容を1文に要約してください："ボブは男の子です。彼は犬を飼っています。ボブと彼の犬は散歩に出かけました。公園に着いたとき、ボブは棒を投げ、犬はそれを拾ってきました。犬はリスを追い、ボブはそれを追いかけました。ボブは犬を見つけ、一緒に家へ帰りました。"'
}

# チェーンを呼び出し、応答を表示
response = chain.invoke(input_data)
display(Markdown(response))

このコードにより、モデルの性能をテストし、その結果を見ることができます。

4 Mixtral 8x7B モデルの性能評価

異なるMoEモデルの出力を比較する際、例えば論理推論、要約、エンティティ抽出といったタスクの実績を見ることで、パフォーマンスの違いを分析できます。

以下、具体例をいくつか検証していきます。

論理推論問題：

1

13個の単語を挙げてください。各単語は9文字で構成されています。

出力例：

1
2
3
4
5
6
7

以下の13個の9文字の単語を示します：
1. Agriculture
2. Beautiful
3. Chocolate
4. Dangerous
5. Encyclopedia
...

上記のような問題では、一部の単語が条件を満たさない場合があります。ただし、一連の正確性を検討することができます。

要約問題

1

次の内容を1文にまとめてください：「ボブは男の子です。彼は犬を飼っています。ボブと彼の犬は散歩に出かけました。ボブと彼の犬は公園に着きました。公園では、ボブが棒を投げ、犬がそれを拾ってきました。犬がリスを追い、ボブがそれを追いかけました。ボブは犬を見つけて、一緒に家に帰りました。」

出力：

1

少年ボブは愛犬と活発な散歩を楽しみ、公園では棒拾いやリス追いを一緒に遊び、その後一緒に家に帰りました。

上記の出力から判断すると、要約は非常に適切にまとめられています。

エンティティ抽出

1

次のテキストから、すべての数値とそれに対応する単位を抽出してください：「マラソンの長さは42キロメートルで、30,000人以上が参加しました。」

出力：

1
2
3
4
5
6
7

1. 与えられたテキストには、2つの数値と対応する単位があります：
   - 42（マラソンの長さ。文中では単位が明示されていませんが、後述からキロメートルと推測できます）
   - 30,000（参加人数）
2. 文中で後にマラソンの長さの単位が示されています：「キロメートル」。特に別の単位が指定されていないため、この数値もキロメートルと仮定します。
3. したがって、最終的な解答は以下の通りです：
   - 42（キロメートル、マラソンの長さ）
   - 30,000（参加人数）

上記の出力から判断すると、すべての数値と単位が正確に抽出されています。

数学的推論問題

1

2個のりんごを持っています。その後、さらに2個買いました。その2個のりんごを使ってパイを作ります。パイを半分食べた後、残りのりんごは何個ですか？

出力：

1
2
3
4

1. 最初に2個のりんごを持っています。
2. さらに2個買ったので、合計で4個のりんごを持っています（2 + 2 = 4）。
3. パイを作るために2個のりんごを使用しました。その結果、残りは2個です（4 - 2 = 2）。
4. パイを半分食べましたが、パイに含まれるりんごの数は不明のため、この情報だけでは残ったりんごの正確な数を判断できません。

モデルの出力は不正確です。正しい答えは2です。理由は、合計4個のりんごのうち、2個がパイ作りに使用され、残り2個のりんごはそのまま手元に残っているためです。

5 まとめ

MoEモデルは、各タスクに関連する専門家のみを活性化することで、効率的な深層学習方法を提供します。この選択的な活性化により、従来の密集型モデルと比較して計算資源を削減しつつ、複雑な操作を実行することが可能です。しかし、MoEモデルにはすべての専門家をメモリ内に格納するための大量のVRAMが必要であり、トレードオフが伴います。

Mixtral 8X7Bアーキテクチャはその典型例であり、スパースな専門家混合（SMoE）メカニズムを活用して、専門家の一部を活性化し効率的なテキスト処理を実現し、計算コストを大幅に削減しました。このモデルは128億の活性化パラメータと32kトークンのコンテクスト長を持ち、テキスト生成から顧客サービスの自動化に至る多くの応用において優れた性能を発揮しています。Databricks社のDBRXモデルは、革新的な細粒度MoEアーキテクチャにより、入力ごとに360億パラメータのみを活性化しつつ、合計1320億パラメータを効率的に利用します。同様に、DeepSeek-v2は細粒度と共有専門家を組み合わせた強力なアーキテクチャを採用しており、2360億パラメータと128,000トークンのコンテクスト長を持つことで、チャットボット、コンテンツ作成、コード生成といった多様な応用に理想的な選択肢となっています。

5.1 重要なポイント

• MoEモデルは、特定のタスクに関連する専門家のみを活性化することで深層学習の効率性を高め、従来の密集型モデルと比べて計算資源の使用を削減します。
• MoEモデルは計算効率を提供する一方で、すべての専門家を保存するために膨大なVRAMを必要とし、計算能力とメモリ需要の間に課題があります。
• Mixtral 8X7Bはスパース専門家混合（SMoE）メカニズムを採用し、専門家の128億活性化パラメータを一部活性化させることで効率的なテキスト処理を実現します。このモデルは32,000トークンのコンテクスト長をサポートし、テキスト生成や顧客サービス自動化を含む幅広い応用に最適です。
• DatabricksのDBRXモデルは細粒度専門家混合アーキテクチャを採用し、各入力で360億パラメータのみを活性化する効率的な方式で、1320億パラメータを活かして複雑な言語タスクに対応します。
• DeepSeek-v2は、細粒度専門家と共有専門家戦略を組み合わせた強力なアーキテクチャを採用し、2360億パラメータと128,000トークンのコンテクスト長を備え、多面的な応用において成果を挙げています。

6 よくある質問

Q1. 専門家混合モデル (MoE) とは何ですか？

A. MoEモデルはスパースアーキテクチャを使用し、特定のタスクに関連する専門家のみを活性化して計算資源の使用を削減する、効率的なディープラーニングモデルです。

Q2. MoEモデルのメリットとデメリットは何ですか？

A. MoEモデルは計算効率を向上させる一方、すべての専門家をメモリに格納するために大量のVRAMを必要とするため、計算能力とメモリ需要のバランスを取る必要があります。

Q3. Mixtral 8X7Bモデルの活性化パラメータ数はいくつですか？

A. Mixtral 8X7Bは128億（2×56億）の活性化パラメータを持ち、総数448億（8×56億）の一部を使用します。このことにより、複雑なタスクを効率的に処理し、より高速な推論を可能にしています。

Q4. DBRXモデルと他のMoEモデル（例: MixtralやGrok-1）の違いは何ですか？

A. DBRXは細粒度の専門家混合方式を採用しており、各層に16個の専門家を含み、そのうち4個を活性化します。一方、他のMoEモデル（例: MixtralやGrok-1）は各層に8個の専門家を持ち、そのうち2個を活性化します。

Q5. DeepSeek-v2は他のMoEモデルとどう異なりますか？

A. DeepSeek-v2は細粒度専門家と共有専門家を組み合わせ、2360億パラメータと128,000トークンのコンテクスト長を備えています。その結果、チャットボット、コンテンツ作成、コード生成のような多様な用途に応用可能なモデルとなっています。

7 推奨文献

1. Mixtral of experts | Mistral AI | Frontier AI in your hands
2. DeepSeekMoE: MoE with Segmented and Shared Experts
3. Mixtral of Experts
4. DBRX: A Large-Scale Decoder-Only Language Model with Fine-Grained Mixture of Experts

サポートベクターマシン（SVM）は機械学習における古典的なアルゴリズムです。この記事では、SVMの公式導出に焦点を当て、マージン距離の詳細な推論や、元の問題と双対問題の公式化を説明します。制約付き最適化問題をラグランジュ関数を用いて解決し、KKT条件を利用して最適解を求める過程を深く探ります。また、多項式カーネル関数とガウスカーネル関数の公式特性についても触れます。

マージン距離の推論

サポートベクターマシン（SVM）において、正の超平面と負の超平面の式はそれぞれ以下の通りです： $$ \vec{w} \cdot \vec{x} + b = 1 \quad \text{(正の超平面)} $$ $$ \vec{w} \cdot \vec{x} + b = -1 \quad \text{(負の超平面)} $$ ここで$\vec{w}=(w_1, w_2)$は重みベクトル、$b$はバイアス項、$\vec{x}=(x_1, x_2)$はデータポイントです。

仮に$\vec{x_m}$が正の超平面上の点、$\vec{x_n}$が負の超平面上の点であるとすると、次のようになります： $$ w_1 x_{1m} + w_2 x_{2m} + b = 1 \quad \text{(1)} $$ $$ w_1 x_{1n} + w_2 x_{2n} + b = -1 \quad \text{(2)} $$

式(1)から式(2)を引くと、次のようになります： $$ w_1 (x_{1m} - x_{1n}) + w_2 (x_{2m} - x_{2n}) = 2 $$ ベクトル形式で書くと： $$ \vec{w} \cdot (\vec{x_m} - \vec{x_n}) = 2 \quad \text{(3)} $$ 決定超平面上の2点$\vec{x_0}$と$\vec{x_p}$を考え、それらは決定超平面の式$\vec{w} \cdot \vec{x} + b = 0$を満たします。すなわち： $$ w_1 x_{10} + w_2 x_{20} + b = 0 $$ $$ w_1 x_{1p} + w_2 x_{2p} + b = 0 $$ 2式を引くと： $$ w_1 (x_{10} - x_{1p}) + w_2 (x_{20} - x_{2p}) = 0 $$ ベクトル形式で書くと： $$ \vec{w} \cdot (\vec{x_0} - \vec{x_p}) = 0 \quad \text{(4)} $$ 式(4)は、$\vec{w}$が決定超平面上の任意の2点のベクトル差に垂直であることを示しています。

式(3)と(4)から、$\vec{w}$と$(\vec{x_m} - \vec{x_n})$の内積が2であることがわかります。ベクトルの内積の定義$\vec{a} \cdot \vec{b}=|\vec{a}| \cdot |\vec{b}| \cdot \cos \theta$に基づき、ここで$\theta$は$\vec{w}$と$(\vec{x_m} - \vec{x_n})$の間の角度です。次のようになります： $$ |\vec{x_m} - \vec{x_n}| \cdot \cos \theta \cdot |\vec{w}| = 2 $$ $L = |\vec{x_m} - \vec{x_n}| \cdot \cos \theta$とすると： $$ L \cdot |\vec{w}| = 2 $$ 解くと： $$ L=\frac{2}{|\vec{w}|} $$

ここで$L$はSVMのマージン（margin）距離です。

マージン距離を導出する際に、ベクトルの内積の幾何学的意味を利用しました。すなわち、$\vec{a} \cdot \vec{b}=|\vec{a}| \cdot |\vec{b}| \cdot \cos \theta$であり、ここで$\theta$は2つのベクトルの間の角度です。この関係を通じて、内積をベクトルの長さと角度の関係に変換し、マージン距離の表現を導き出しました。

双対性の証明

線形サポートベクターマシン(SVM)において、元の問題は目的関数を最小化する重みベクトル$w$とバイアス$b$を見つけることです：

$$ \min_w f(w) = \frac{1}{2} |w|^2 $$

ここでの$|w|^2$はベクトル$w$のユークリッドノルムの平方、すなわち$L_2$ノルムを表します。目的は決定境界の幅を最小化し、より良い一般化能力を得ることです。この問題は以下の制約を受けます：

$$ y_j (w^T x_j + b) - 1 \geq 0 $$

ここで$x_j$は第$j$番目の訓練サンプル、$y_j$は対応するラベルで、+1または-1の値を取ります。これにより、すべてのデータポイントが正しく分類され、決定境界から少なくとも1単位の距離を持つことが保証されます。

この制約付き最適化問題を処理するために、ラグランジュ関数を構築します：

$$ L(w, b, \alpha) = f(w) - \sum_{j = 1}^n \alpha_j g_j(w, b) $$

ここで$\alpha_j \geq 0$はラグランジュ乗数で、元の問題の制約条件$g_j(w, b) = y_j (w^T x_j + b) - 1 \geq 0$を導入するために用いられます。

次に、双対関数$q(\alpha)$を定義します：

$$ q(\alpha) = \min_{w, b} L(w, b, \alpha) = \min_{w, b} \left( f(w) - \sum_{j = 1}^n \alpha_j g_j(w, b) \right) $$

$\alpha_j \geq 0$ および$g_j(w^{*}, b^{*}) \geq 0$であるため、次のように導出できます：

$$ q(\alpha) = \min_{w, b} \left( f(w) - \sum_{j = 1}^n \alpha_j g_j(w, b) \right) \leq f(w^*) - \sum_{j = 1}^n \alpha_j g_j(w^*, b^*) \leq f(w^*) \leq f(w) $$

これは、双対関数が元の問題の下限を与えることを意味します。次に、$\alpha^*$を見つける必要があります。これにより：

$$ q(\alpha) \leq q(\alpha^*) \leq f(w^*) \leq f(w) $$

SVMの元の問題と双対問題は次のように表現できます：

$$ \max_{\alpha} q(\alpha) = \max_{\alpha} \min_{w, b} L(w, b, \alpha) $$

その制約条件は：$ \alpha_i \geq 0 $

弱双対性が満たされるとき、$q(\alpha^*) \leq f(w^*)$が成り立ちます。強双対性が満たされる場合、すなわちSlater条件が成立する場合、$q(\alpha^*) = f(w^*)$が成り立ちます。Slater条件は、すべての不等式制約が厳密に成立する可行解が存在することを要求します。線形サポートベクターマシンは線形可分であり、Slater条件を自動的に満たします。

これにより、次のようになります：

$$ f(w) \geq q(\alpha^*) = f(w^*) \geq q(\alpha_i) $$

上記の式に基づいて、次のことがわかります：

$$ q(\alpha^*) \geq q(\alpha_i) $$ $$ f(w^*) \leq f(w) $$

$f(w)$は最小値を見つけ（元の問題）、$q(\alpha)$は最大値を見つけ（双対問題）、元の問題と双対問題の最適解は等しいです。すなわち：

$ w^*, b^* $は元の問題の解であり、$\alpha^*$は双対問題の解であり、$f(w^*) = q(\alpha^*)$です。

線形SVMにおいて、特定の条件（Slater条件）が満たされるとき、元の問題と双対問題の解が一致することがわかります。これは、複雑な最適化問題を解決するための有効な方法であり、特に元の問題を直接解くことが難しい場合に、双対問題を解くことで間接的に問題を解決することができます。

簡単な例

上記の元の問題と双対問題の解が同じであることをより直感的に理解するために、簡単な最適化問題を考えます。元の問題は次のように定義されます：

元の問題は： $$ \min_x f(x) = x^2 $$ 制約条件は： $$ x - 1 \geq 0 $$

この問題の目標は、関数$f(x) = x^2$を最小化し、同時に$x$が$x \geq 1$を満たす必要があります。直感的には、$x = 1$のとき、$f(x) = 1$であり、これは与えられた制約下での最小値です。

双対性を検証するために、ラグランジュ関数を構築します：

$$ q(\alpha) = \min_x L(x, \alpha) = \min_x (x^2 - \alpha(x - 1)) $$

ここで$\alpha \geq 0$はラグランジュ乗数で、元の問題の制約条件$x - 1 \geq 0$を導入するために用いられます。ラグランジュ関数を構築することで、制約付きの最適化問題を無制約の問題に変換しました。

次に、$L(x, \alpha)$について$x$の偏導数を求め、それを0に設定します：

$$ \frac{\partial L}{\partial x} = 0 2x - \alpha = 0 $$

解くと：

$$ x = \frac{\alpha}{2} $$

$x = \frac{\alpha}{2}$を$q(\alpha)$に代入します：

$$ q(\alpha) = - \frac{\alpha^2}{4} + \alpha $$

これで、双対関数$q(\alpha)$の形式を得ました。次に、双対問題の最大値$\max_{\alpha} q(\alpha) $を求める必要があります。

そのために、$q(\alpha)$について$\alpha$の導関数を求め、それを0に設定します：

$$ \frac{dq}{d\alpha} = - \frac{\alpha}{2} + 1 = 0 $$

解くと$$ \alpha = 2 $$

$\alpha = 2$を$x = \frac{\alpha}{2}$に代入すると、$$ x = 1 $$

このとき、$\alpha = 2$を$q(\alpha)$に代入して計算すると：

$$ q(\alpha) = - \frac{2^2}{4} + 2 = 1 $$

この簡単な例を通じて、元の問題の解$x = 1$、$f(x) = 1$と、双対問題の解$\alpha = 2$、$q(\alpha) = 1$が等価であることがわかります。これは、一定の条件が満たされる場合に、双対問題の解が元の問題の解と一致することを検証しています。

双対理論の応用を通じて、元の問題の解を見つけただけでなく、双対問題を解くことで同じ結果を得ることができ、双対問題の解の等価性を検証しました。

KKT条件による解法

SVMがKKT条件を満たす

SVMの元の最適化問題は凸最適化問題です。SVMの目的関数 $\frac{1}{2}|w|^2$ は$w$に関する二次関数であり、凸関数です。同時に、制約条件 $y_i(w \cdot x_i + b) \geq 1$ は線形（アフィン制約）であり、したがって凸です。凸最適化問題では、局所最適解が全体最適解であり、KKT条件は必要かつ十分な条件です。これは、ある点がKKT条件を満たす場合、それが全体最適解であることを意味します。

目的関数 $\frac{1}{2}|w|^2$ は連続で微分可能であり、制約条件 $y_i(w \cdot x_i + b) \geq 1$ も連続で微分可能です。この滑らかさは、勾配の存在と一意性を保証し、KKT条件における勾配条件（すなわち$w$と$b$に関する偏導数を求めて0に設定する）が有効に適用できるようにします。

凸最適化問題では、KKT条件は必要条件であるだけでなく、十分条件でもあります。つまり、ある点がKKT条件を満たす場合、それは全体最適解であることを意味します。SVMにおいて、KKT条件を解くことで最適な$w^*$と$b^*$を見つけ、最適な分離超平面を決定することができます。

KKT条件を利用した線形サポートベクターマシンの解法

元のSVM最適化問題は、$\frac{1}{2}|w|^{2}$を最小化し、同時に制約条件$y_{i}(w\cdot x_{i}+b)\geqslant1$を満たすことです。ここで$i = 1,2,\cdots,N$です。

まず、ラグランジュ関数を構築します。$L(w,b,\alpha)=\frac{1}{2}|w|^{2}-\sum_{i = 1}^{N}\alpha_{i}(y_{i}(w\cdot x_{i}+b)-1)$、ここで$\alpha_{i}\geqslant0$はラグランジュ乗数です。KKT条件に基づき、次のようになります：

$$ \nabla_{w}L(w^*,b^*,\alpha^*) = w^*-\sum_{i = 1}^{N}\alpha_{i}^*y_{i}x_{i}=0 $$

$$ \nabla_{b}L(w^*,b^*,\alpha^*)=-\sum_{i = 1}^{N}\alpha_{i}^*y_{i}=0 $$

$$ \alpha_{i}^*(y_{i}(w^*\cdot x_{i}+b^*)-1)=0 $$

$$ y_{i}(w^*\cdot x_{i}+b^*)-1\geqslant0 $$

$$ \alpha_{i}^*\geqslant0 $$

これらの条件はすべての$i = 1,2,\cdots,N$に適用されます。

$\nabla_{w}L(w^*,b^*,\alpha^*) = w^*-\sum_{i = 1}^{N}\alpha_{i}^*y_{i}x_{i}=0$から次のことが得られます：

$$ w^*=\sum_{i = 1}^{N}\alpha_{i}^*y_{i}x_{i} \quad \text{(5)} $$ 少なくとも1つの$\alpha_{j}^*>0$が存在します（もし$\alpha_{i}^*=0$と仮定すると、式$\nabla_{w}L(w^*,b^*,\alpha^*) = w^*-\sum_{i = 1}^{N}\alpha_{i}^*y_{i}x_{i}=0$から導かれる解に矛盾が生じます）。

$b^*$の解法については、$w^*=\sum_{i = 1}^{N}\alpha_{i}^*y_{i}x_{i}$を$y_{j}(w^*\cdot x_{j}+b^*)-1 = 0$に代入することで求めることができます（$\alpha_{j}^*>0$が存在する場合を考慮）。また、$y_{j}^{2}=1$に注意して次のように得られます：

$$ b^*=y_{j}-\sum_{i = 1}^{N}\alpha_{i}^*y_{i}(x_{i}\cdot x_{j}) \quad \text{(6)} $$

上記の理論に基づき、分離超平面は次のように表現できます：

$$ \sum_{i = 1}^{N}\alpha_{i}^*y_{i}(x\cdot x_{i})+b^*=0 $$

したがって、分類の決定関数は次のように書くことができます：

$$ f(x)=\text{sign}(\sum_{i = 1}^{N}\alpha_{i}^*y_{i}(x\cdot x_{i})+b^*) $$

SVMにおいて、相補的緩和条件$\alpha_i (y_i(w \cdot x_i + b) - 1) = 0$は、あるサンプル点$x_i$がサポートベクターでない場合（すなわち$y_i(w \cdot x_i + b) > 1$）、対応するラグランジュ乗数$\alpha_i$がゼロでなければならないことを示しています。逆に、あるサンプル点がサポートベクターである場合（すなわち$y_i(w \cdot x_i + b) = 1$）、対応する$\alpha_i$はゼロでない可能性があります。この条件は、サポートベクターのみが最適化問題の解に寄与することを保証し、問題の解法を簡素化します。

多項式カーネル関数とガウスカーネル関数

既存の問題が線形に分離できない場合、既存のデータを高次元空間にマッピングし、高次元空間で線形に分離可能な問題にすることができます。しかし、高次元特徴空間で直接計算することは非常に複雑です。式（5）と式（6）からわかるように、実際にデータを高次元空間にマッピングする必要はなく、データ点間の内積を知るだけで十分です。カーネル関数の役割は、高次元特徴マッピングを明示的に行わずに、元の特徴空間でカーネル関数の値を計算することで、高次元特徴空間での内積計算を間接的に実現することです。

ガウスカーネル関数は一般的なカーネル関数で、その形式は次の通りです： $$ K(x, y) = \exp\left(-\gamma |x - y|^2\right) $$

ここで$\gamma$は正のパラメータで、カーネル関数の幅を制御します。

指数関数をテイラー展開することができます：

$$ \exp(z) = \sum_{k=0}^{\infty} \frac{z^k}{k!} $$

$ z = -\gamma |x - y|^2 $を上記の式に代入すると、次のようになります：

$$ K(x, y) = \exp\left(-\gamma |x - y|^2\right) = \sum_{k=0}^{\infty} \frac{(-\gamma |x - y|^2)^k}{k!} $$

多項式カーネル関数の形式は次の通りです：

$$ K_{\text{poly}}(x, y) = (x \cdot y + c)^d $$

ここで$c$は定数項、$d$は多項式の次数です。

$|x - y|^2$は次のように展開できます：

$$ |x - y|^2 = (x - y) \cdot (x - y) = x \cdot x + y \cdot y - 2 x \cdot y $$

この表現をガウスカーネル関数のテイラー展開式に代入します：

$$ K(x, y) = \sum_{k=0}^{\infty} \frac{(-\gamma (x \cdot x + y \cdot y - 2 x \cdot y))^k}{k!} $$

各項$\frac{(-\gamma (x \cdot x + y \cdot y - 2 x \cdot y))^k}{k!}$は実際には多項式項であり、すなわち各項は$x$と$y$の異なるべき乗の組み合わせとして表現できます。

各項を注意深く観察すると、ガウスカーネル関数は実際には異なる次数の多項式カーネル関数を加重して得られたものであることがわかります。各項$\frac{(-\gamma (x \cdot x + y \cdot y - 2 x \cdot y))^k}{k!}$は、$k$次の多項式カーネル関数の加重形式と見なすことができます。

例えば、$k = 1$の場合：

$$ \frac{(-\gamma (x \cdot x + y \cdot y - 2 x \cdot y))^1}{1!} = -\gamma (x \cdot x + y \cdot y - 2 x \cdot y) $$

$k = 2$の場合：

$$ \frac{(-\gamma (x \cdot x + y \cdot y - 2 x \cdot y))^2}{2!} = \frac{\gamma^2 (x \cdot x + y \cdot y - 2 x \cdot y)^2}{2} $$

これらの項はすべて$x$と$y$の多項式形式であり、階乗$k!$によって加重されています。

ガウスカーネル関数は、無限次元で異なる次数の多項式カーネル関数を調和させて得られたものと見なすことができます。この調和により、ガウスカーネル関数は高次元特徴空間でより複雑な非線形関係を捉えることができます。したがって、多くの非線形タスクのシナリオで、ガウスカーネル関数は非常に優れた選択肢となります。

VLDB 2024 はデータ管理とデータベース分野のトップ国際会議であり、データ管理、データベースアーキテクチャ、グラフデータ管理、データプライバシーとセキュリティ、データマイニング、機械学習、人工知能とデータベースシステム研究などの分野をカバーしています。今年の会議は8月26日から30日まで中国の広州で開催され、世界中の研究者と企業が集まりました。会議内容は豊富で、250以上の研究報告、11の基調講演、複数のチュートリアルとワークショップがあり、参加者に幅広い学習と交流の機会を提供しました。

最近広州に行って、VLDB 2024に参加し、学術会議の全プロセスを体験しました。旅行中にも多くの面白いことに出会い、ブログに書いてシェアしようと思いました。

今回の旅程は6日間で、以下のようにスケジュールされています。最初の5日間は琶洲島の広交会展館付近で、主に会議に参加したり珠江夜游を楽しんだりしました。最後の1日は特種兵のような観光で、西側は沙面島から始まり、十三行博物館を経て、聖心大教堂まで歩き、東側は黄埔軍校記念館です。

Day 0：現実充実者に小さな広州の衝撃を

午後3時、広州南駅から地下鉄で琶洲駅へ。駅を出る前に、地下鉄がコスプレイヤーでいっぱいになっていることに気づきました。運悪く、地図が保利世貿館の出口を選んでしまい、二次元の巣に突っ込んでしまいました。地下鉄の出口から会場の地下、保利世貿館から広交会展館まで、琶洲島は二次元の人々で溢れていました。参加者の数が多いだけでなく、コスプレのキャラクターも非常に豊富で、国産ゲームから日本のアニメ、牢大からトランプ暗殺まで…駐車場も痛車でいっぱいで、これらの車はほとんど電車ではなく、車の持ち主もおそらく二次元の人々でしょう。

やっとのことでホテルにたどり着きましたが、夜の21時に食事に行ったところ、展示会がまだ終わっておらず、なんと川沿いに夜の会場が設けられていました。翌日は月曜日なのに！広州の二次元の雰囲気はやはり濃厚です。

Day 1：学術バッタと晩餐のウロン

VLDB2024は香港科技大学（広州）が広州朗豪ホテルで開催しました。初日の登録は朝8時から始まり、初めて学術会議に参加する興奮から、早起きして行きました。登録時には胸章、会議手帳、スケジュール、食券、船券、記念品の箱、スポンサーの広告が渡されます。記念品にはハードカバーノート、ボールペン、傘が含まれており、黒と青の2つのテーマカラーがあります。

初日の会議内容はすべてワークショップ形式で行われました。現場では異なるテーマのワークショップが同時に行われるため、事前に興味のあるテーマを選んで参加する必要があります。私はLLM、Knowledge Graph、Vector Databaseに関するテーマを選びました。発表内容を理解するのは問題ありませんが、ディスカッションの段階になると、何人かの方が話に夢中になり、話すスピードが速くなり、理解できなくなりました。英語のリスニングとスピーキングをもっと練習しなければなりません。

ティーブレイクは午前10時と午後3時にあり、8時の朝食もティーブレイクの規格です。大物たちにとって、ティーブレイクはソーシャルを行う良い機会であり、研究内容を議論したり、連絡先を交換したりします。しかし、私のような学術バッタにとって、ティーブレイクは本当にただのティーブレイクです。各ティーブレイクの食べ物は多少の変化がありますが、全体的にはビスケット、パン、ケーキ、果物、飲み物の数種類です。その中で、ムースケーキとタイ風焼き魚の甘辛ソースが特に気に入りました。

夜の歓迎宴会も非常に豪華で、ビュッフェ形式でした。しかし、当時は行列が多すぎて、事前にどの料理があるのか注意を払わず、最初にご飯を2杯も取ってしまい、多くの良い料理を逃しました。料理の中で中華料理は約30％を占め、残りは日本料理（寿司と刺身）、カレー、野菜サラダ、西洋菓子、果物、飲み物（赤ワインとジュース）で、異なる食事の違いに十分に配慮されています。しかし、その中の中華料理は本当に普通で、最終的には炭水化物と炭水化物の組み合わせであるカレーライスと小さなケーキになりました。嗟乎、吾其辞小蛋糕難矣。

晩餐会の間にウロンがありました。今回の会議にはもう一人の同級生と一緒に参加しましたが、私たちはまだ指導教官に会ったことがありませんでした。料理を選んで適当なテーブルに座った後、同席の他の人たちが何を話しているのかを聞き始めました。そして、私たちの間で以下のような会話がありました：「向かいの人が私たちの指導教官に似ていると思わない？」、「そんな偶然ある？」、「研究方向が合っているし、さっき彼らが言ったことが…」、「年齢が違うんじゃない？」、「人数も合っているし」、「身長も合っている」、「本当に似ている」、「まさにその通り」、「どうする、今認める？」、「ここまで来たら、まずは食事をしよう」。こうして私たちは非常に緊張しながら食事を終え、認めに行った結果、全く違う人でした。彼らはそれぞれ天津大学と華東師範大学の博士生で、研究方向が非常に似ており、相互紹介の後に友達になりました。後で彼らの論文が最優秀研究論文にノミネートされていることを知り、非常に羨ましかったです。

Day 2：獅子舞、開幕！

開幕式で最も印象に残ったのは、広州沙坑の獅子舞のパフォーマンスです。パフォーマンスの開始時に、舞者は獅子を操り、頭を振ったり、かゆみを掻いたり、転がったりするなど、獅子の生活習性を模倣するさまざまなリアルな動作を行いました。その中で最も特徴的なのは、獅子の目が動くことです（これが沙坑の獅子舞であると判断した理由です）。その後、獅子はステージ上で高難度のジャンプや柱を踏む動作を行い、舞者の正確な技術と強健な体力を示しました。最後に、リーダーが上がって目を入れ、獅子が祝賀の対聯をくわえて出しました。全体のパフォーマンスは、太鼓のリズムに合わせて、獅子が時に威猛で、時に軽やかで、力強さと面白さを兼ね備えていました。

これが私が初めて見た本物の獅子舞のパフォーマンスであり、最も特徴的な広東の獅子舞です。多くのゲームにも広東の獅子舞をモデルにしたシーンがありますが、特に象徴的な柱を踏む動作があるものの、これらのシーンはしばしばパフォーマンスの場面の演出に重点を置き、獅子の模倣動作による面白さが欠けており、現場のパフォーマンスほどの力強さを感じることはできません。

獅子舞のパフォーマンスが終わった後、会議の議長である香港科技大学の陳雷先生が会議の大まかな状況を紹介しました：今回の会議はVLDBの開催歴史上、参加者数が最も多いもので、中国本土の参加者が60％を占め、会議は最も資金が豊富で（half a million dollar）、AI関連の論文が最も多く、データベースの基礎設計の論文が最も少ないなど。

開幕式が終わった後、1日中の分科会が正式に始まりました。分科会も事前に興味のあるテーマを選んで参加する必要があり、興味のある論文を事前に読んでおくことが望ましいです。夕食は前日と同じくらい豪華で、イタリア風の野菜スープとミルフィーユが非常に美味しかったです！（唯一）この日は焼き串もあり、手羽元と麺筋の2種類がありました。食事を終えた後、少し歩いてみると、中国人のテーブルには焼き串を取らない人はいなく、白米と焼き串を組み合わせている人もいました。やはりみんな中国の味覚を持っているようです。プログラマーの焼き肉、大いに可能性があります。

Day 3：広東料理の頂点から甲板まで

朝はGoogleからの基調講演で始まり、テーマは大規模モデルがデータベース研究に与える影響についてでした。その後は前日と同じ分科会が行われました。

広東料理の逸品

夜の宴会は炳勝品味海印総店で行われました。途中でアメリカで留学している2人の学生に会い、彼らは中国人が主催する会議では、場面をしっかりと整える必要があると言いました。その言葉に偽りはなく、後でこの店がミシュランであり、広東料理の頂点と称されていることを知りました。この2人のうち1人はアメリカ西部に住んでおり、自分の生活が村にいるようだと評価し、食べるものも遊ぶものもないと言いました。もう1人はアメリカ東部に住んでおり、食事条件が悪く、毎日異なるスポーツを続けることができると言いました。しかし、大学院で学ぶ目的について話すと、そのうちの1人は洞察力と生涯学習の思考能力を維持するためだと言い、非常に同意しました。

夕食の料理は本当に豊富でした。テーブルで携帯電話を使うのが難しかったため、記憶に頼って印象に残った料理をいくつか思い出しました：西洋人参のスペアリブスープ、丸ごと焼き乳豚（ただし目に赤い電球が詰められており、外来人としては邪能焼き乳豚と呼びたい）、ニンニク蒸しボストンロブスター、大きな海参、魚、鶏とアヒル、酢豚、甘水、トマトとメロン、サチーマとプーアル茶。全体的に悪くはありませんでした。焼き乳豚は皮がカリカリで肉が柔らかく、酢豚は酸っぱくて美味しかったです。食材の選択には広東の特色がありました。しかし、慣れないためか、広東料理の中で特色のある料理は、逆に最も食べにくかったです：甘水は本当に甘すぎて、スペアリブスープに西洋人参を入れると酸っぱくなり、ある点心はまるで月餅の皮にセロリと豚肉の餃子の生の具を包んだようで、まったく受け入れられませんでした。面白いことに、レストランではデフォルトでナイフとフォークが提供されず、何人かの外国人もやむを得ず箸を使っていましたが、特に問題はなさそうでした。

私たちの師門の同席にはアマゾンの研究員とアメリカのある大学のAPがいました。アマゾンの研究員は私の指導教官の前で、産業界の観点から学生には適さない話をしました。APはアメリカの大学で自分のペースで仕事をするだけで終身職を得られる緩やかな雰囲気について話しました。スペアリブスープはこの時に西洋人参で酸っぱくなったのかもしれません。

食事の後、全員で徒歩で埠頭に向かい、珠江夜游に参加しました。途中で名古屋大学で博士1年生の方に会い、日本での博士生活を大いに称賛しました。指導教官の放任、高い補助金、日本の売り手市場の就職環境、文化環境などです。博士課程を楽しむことができるなんて？

珠江夜游

夜が更けると、珠江の両岸に明かりが灯り始めました。私たちは遊覧船に乗り、輝く夜の中へとゆっくりと進みました。両岸の高層ビルは灯りが輝き、波のきらめきに映えて、まるで星が碧波に落ちたかのようでした。

沿道には象徴的な建物があり、広州塔はそびえ立ち、変幻自在の光影が夢のように幻想的でした。珠江新城の摩天楼群は輝きを放ち、現代都市のスカイラインを描いていました。船が海珠橋を通過する際、橋上の車の流れは絶え間なく、橋下の遊覧船が行き交い、賑やかな光景が広がっていました。

微風が頬を撫で、江水が船の側面を軽く叩いていました。甲板の下からは民俗音楽が聞こえ、この夜の色に心地よい雰囲気を添えていました。観光客たちは欄干に寄りかかって遠くを眺めたり、杯を傾けて語り合ったりしながら、この魅力的な夜の色に酔いしれていました。

2時間の航程はあっという間に過ぎ去りました。旅全体を振り返ると、繁華な都市と悠久の歴史がこの母なる川で完璧に融合し、忘れられないものとなりました。

新しいナンパ

同行の同級生と一緒に三層の船首で風景を楽しんでいると、外国人がやって来ました。彼はリュックを背負い、汗だくで、少し慌ただしい様子でした。彼はこの船にWIFIがあるかどうか、パスワードを知っているかどうかを尋ね、家族と連絡を取りたいと言いました。それから私たちはそれがないことに気づき、彼にホットスポットを提供することを提案しました。接続が成功した後、私たちはまた、海外のソーシャルメディアはほとんどが壁の外にあるため、この老兄が広州に来た後、ずっとWifiを探していたが、ずっと壁に阻まれていたのではないかと考えました。彼の立場から考えると、遠くて神秘的な東洋にいる人々が、どのWifiもファイアウォールを突破できず、家族と3日間連絡が取れず、他の人にホットスポットを開いてもらおうとしても、誰も「共有」してくれないというのは、本当に可哀想です。それで私たちは、魔法の猫の能力を局域ネットワークで共有しようとしましたが、コンピュータでは簡単なことでも、携帯電話では最終的に成功しませんでした。

しかし、私たちはすぐにこの老兄が社交的な牛であることに気づきました。道中、彼は話題を見つけるのに必死でした：「ICBCは何の略ですか？『猎德』は何を意味しますか？あなたたちはどこから来ましたか？あのロゴは何ですか」…そして私たちと一緒に写真を撮りまくりました。

こうして話しながら、夜游に異なる楽しみを加えました。

後にwhovaで、この老兄が活躍度ランキングで2位であり、ドイツのある大学に勤務しており、会社も持っていることを知りました。これは家族と連絡が取れず、ネットを探し回るような様子ではありませんでした。

Day 4：無料収集

VLDB2024の期間中、Google、Meta、アリババ、バイトダンスなどのスポンサー企業のブースがあり、ブースでアンケートに記入すると、無料で何かをもらえます。アンケートは主に研究方向と就職の傾向を調査するもので、名刺を直接受け取ることもあります。すべての無料品の中で、私が最も気に入ったのはGoogleの白いシャツと下の写真のペンギンです。このペンギンがどの会社のものか知らない場合、上に正規の防偽ステッカーが貼られているのを見れば、それがテンセントのものであることがわかります。

午後の報告は私に多くのインスピレーションを与えてくれました。ある作業は一見簡単で、単なる素朴なアイデアに過ぎないように見えますが、深く研究することで、完全な論文に仕上げることができ、感心しました。印象に残ったのは、コーネル大学の独り狼の老兄が、同じ報告会で自分で独立して完成させた2つの作業を連続して報告したことです。彼はマイクを手に持ち、片手をポケットに入れ、両腕を講台に支え、PPTはシンプルな大文字スタイルを採用していました（1枚のPPTに30文字を超えるものはありませんでした）。完全に報告を講演として行っていました。これが大物かもしれません、すでに完全に次のレベルです。

この日で私たちのすべての会議日程が終了し、ホテルを出るときに非常に極端な雷雨の天気に遭遇し、大雨が降りました。

Day 5：半日で中国の500年を歩く

「来たからには」という原則に基づき、広州での最後の日に特種兵式の密集したスケジュールを組みました。この日、私は広州のいくつかの有名な観光地を巡り、この都市の豊かな歴史と文化の底力を感じました。 朝早く、まず異国情緒あふれる沙面島に行きました。このかつての租界地を散策し、欧風建築と熱帯植物が調和して、まるで過去にタイムスリップしたかのようでした。ある場所の風景が十分に美しいかどうかを判断する基準は、そこに結婚写真を撮る人がいるかどうかです。南京の浦口駅、緑博園、中山陵がそうであるように、広州の沙面島もそうです。

沙面島で午前中を過ごし、昼に隣の十三行博物館に歩いて行き、広州が海上シルクロードの重要な港としての輝かしい歴史を深く理解しました。博物館に展示されている文物と写真は、広州が17世紀から商業的に繁栄していた様子から、19世紀の半植民地の景観までを生き生きと示しています。ここで知ったのは、広州が強制的に開港された後、各国の商館は現在の広州塔の対岸の市中心の沿江位置に設置されていましたが、後に火災が発生し、沙面島に移転したことです。

午後には聖心大教堂に行きました。これは規模の大きなゴシック建築で、小紅書で必ず訪れるべきスポットとして推奨されています。結果的に、実際には打卡スポットでしかなく、ほとんどの時間は開放されていません。

午後には黄埔軍校旧址を見学しました。この無数の革命先烈を育てた場所を歩き、その情熱に燃えた時代を感じたいと思いました。事前に下調べをしていなかったため、想像していたものとは少し違い、多少の失望がありました。黄埔軍校の原址は抗日戦争時に日本軍によって爆撃されて灰燼に帰したため、現在の観光地はできる限り再現されたものです。整然とした再現された建物を見ていると、「夫子廟」の既視感があり、景区にいるとしか感じられませんでした。しばらく探しても、門には「昇官発財請往他処、貪生怕死勿入斯門」という対聯が見つかりませんでした。

夜が更けると、再び珠江のほとりに行き、川沿いを散歩しました。夜の広州は、地平線と天際線、小蛮腰と大劇院があり、何度見ても飽きません。海珠大橋から猎德大橋まで、同じ珠江でありながら、17世紀から21世紀まで、各世紀の景観がこんなにも異なることに驚きました。

この広州での数日間は、まるで古今を行き来する旅のようでした。琶洲の学術殿堂から珠江両岸の灯火輝く夜景まで、沙面島の異国情緒から黄埔軍校の革命遺跡まで。この都市は独自の方法で、学術、文化、歴史、現代性を完璧に融合させています。高層ビルの影の下には、都市村の生活感があり、橋の下にはホームレスの姿があり、この都市が進化と包容の過程にあることを思い出させます。しかし、これらの光景は広州の魅力を削ぐことなく、むしろこの都市をよりリアルで、人情味あふれるものにしています。

さようなら、広州。

我们估计人类产生的的公共文本存量约为 300 万亿个token。如果趋势持续，语言模型将在 2026 年至 2032 年之间完全耗尽这一存量，或者如果过度训练，甚至会更早。 ——Epoch AI

2006年、当時イリノイ大学の教授であった李飛飛（現スタンフォード大学教授）は、インターネットが人工知能（AI）研究を変える可能性を見出しました。言語学の研究では、8万の「名詞同義語セット」、つまり同じ種類の物を表す同義語の集合が特定されていました。李飛飛は、インターネット上の数十億枚の画像に、これらの同義語セットの無数の実例が含まれているに違いないと推測しました。これらの画像を十分に集めることができれば、これまでのAIトレーニング資源を超える巨大なデータベースを作成できると考えました。彼女は「多くの人がモデルに注目していますが、私たちはデータに注目すべきです」と述べ、ImageNetプロジェクトが誕生しました。

インターネットは画像だけでなく、画像のラベル付けのためのリソースも提供しました。検索エンジンで猫、犬、椅子などの画像を見つけた後、AmazonのクラウドソーシングプラットフォームMechanical Turkの人々がこれらの画像を手動でチェックし、ラベル付けしました。最終的に、数百万の検証済み画像を含むデータベースが構築されました。ImageNetデータの一部を使用してトレーニングされたAlexNetが2012年に「ディープラーニング」の巨大な可能性を示し、前回のAIサイクルを開始し、大量のラベル付けデータに依存する業界を生み出しました。

1 データ駆動のAI時代

このAIサイクルでは、AIの発展が大規模言語モデル（LLM）にまで拡大し、これらのモデルのトレーニングもインターネットデータに依存していますが、その方法は異なります。コンピュータビジョン分野（CV）の古典的なトレーニングタスクは、画像の内容を予測すること（画像分類タスク）ですが、LLMのトレーニングの古典的なタスクは、文脈に基づいてテキストの中で削除された単語を予測することです。

このトレーニング方法は、手動でラベル付けされたデータを必要とせず、システムが単語を空け、自動的に推論し、「自己監督トレーニング」を通じて答えの正確性を評価できます。しかし、この方法には大量のデータが必要です。一般的に、モデルが得るテキストが多ければ多いほど、データ量が大きければ大きいほど、その性能は向上します（スケーリング則）。 インターネットは数十億のテキストを提供し、LLMにとっては、現代の産業にとって精製可能な燃料のような貴重な資源です。

一般的なトレーニングデータのソースはCommon Crawlで、500億のウェブページを含むインターネットアーカイブです。AIモデルの発展に伴い、Books3のような数千冊の書籍を含むデータベースなど、より多くのデータが追加されました。しかし、AIのテキストデータ需要の増加に伴い、インターネット上の高品質なデータ供給は徐々に限界に達しています。Epoch AIの推定によれば、2028年までにインターネット上の高品質なテキストデータは完全に使い果たされ、業界は「データウォール」と呼ばれる問題に直面します。中国語インターネットはさらに深刻で、「中国語インターネットが崩壊している」と言われ、各プラットフォームが次々と門を閉ざし、データの価値に気づいた後、それを金庫に入れました。この壁をどう乗り越えるかは、AIの将来の発展において最も難しい問題の一つであり、進行を遅らせる可能性が最も高い問題でもあります。

2 データ所有権と著作権の問題

AIモデルはますますインターネットデータに依存していますが、データの著作権問題も議論を呼んでいます。多くの大規模言語モデルのトレーニングに使用されるデータは、著作権者の同意を得ずに使用されることが多く、一部のAI企業は有料のコンテンツも利用しています。AI企業はこの使用が著作権法の「フェアユース」に該当すると主張しますが、著作権者は納得していません。Getty Imagesは画像生成企業Stability AIを訴え、その画像ライブラリを無断で使用したと主張しました。ニューヨークタイムズはOpenAIとMicrosoftを訴え、数百万の記事の著作権を侵害したと主張しました。Stack Overflow、Reddit、X（旧Twitter）は現在、AI企業に料金を請求しています。知乎もビングやグーグルなどのクローラーを妨害するために乱数を使用し、その中国語コンテンツがAIトレーニングのデータセットとして使用されるのを制限しています。

地域によってこの問題に対する態度は異なります。日本とイスラエルはAI産業の発展を促進するために寛容な立場を取っています。EUには共通の「フェアユース」概念がなく、より厳しいかもしれません。国内でも国家データ局が設立され、データが生産資料と生産対象の両方の役割を持つことが明確にされています。

3 現在のデータ使用戦略

データウォールに直面して、AI分野ではいくつかの対策が提案されています。その中の重要な対策の一つは、データの量ではなく質に焦点を当てることです。各AIラボはもはやインターネット全体のデータを盲目的に使用してモデルをトレーニングするのではなく、データのフィルタリング、クリーニング、最適化により重点を置き、モデルが最も価値のあるコンテンツを抽出できるようにしています。過去1年（2024年）で、OpenAIのモデルはもはや「圧倒的なリード」を示していないようで、各社のモデルが互角に戦っており、これらのモデルの異なるタスクでの性能の違いは、トレーニングデータの構築に由来しています。結局のところ、オープンソースのアルゴリズムやモデルは多いですが、オープンソースのデータセットはほとんどありません。

「現実世界の情報」を取得することは非常に重要であり、特にモデルが大量の推論を含む場合、学術教科書などの権威あるリソースが非常に貴重になります。しかし、異なるデータソース間で最適なバランスを見つけることは依然として難しい課題です。

データの使用過程で、モデルは「破滅的な忘却」の問題にも直面します。これは、システムが特定のタイプのデータで過度にトレーニングされると、その分野で得意になる一方で、以前学んだ他の知識を忘れてしまう可能性があるという問題です。そのため、トレーニング時のデータの順序も慎重に考慮する必要があります。特定のテーマ（例えば数学）に関するすべてのデータをトレーニングプロセスの最後に集中させると、モデルは数学の問題で優れたパフォーマンスを発揮するかもしれませんが、同時に他の分野の能力が弱まる可能性があります。この不均衡なトレーニング方法は、破滅的な忘却のリスクを高めます。

データが異なる分野だけでなく、異なる形式（モダリティ）も含む場合、これらの戦略はさらに複雑になります。新しいテキストデータが供給不足になる中、OpenAIのGPT-4やGoogleのGeminiのような先進的なモデルは、自己監督学習の過程でテキストだけでなく、画像、ビデオ、音声も使用してトレーニングされています。しかし、ビデオデータは特に厄介です。ビデオファイルには非常に密度の高いデータポイントが含まれているためです。問題を簡略化するために、現行のモデルは通常、部分的なフレームを抽出して簡略化処理を行っており、学界はより効率的な解決策を模索しています。

4 合成データとAIの自己トレーニング

モデルの能力は、自己監督学習で生成されたバージョン（事前トレーニングバージョン）を基に、追加のデータを使用して微細に調整することで向上させることができます（微調整）。例えば、「監督微調整」は、人間が収集または作成した質問応答ペアをモデルに提供し、良い答えとは何かを教える方法です。別の方法「人間のフィードバックに基づく強化学習」（RLHF）は、モデルに答えが質問者を満足させるかどうかを伝える方法です。

RLHFでは、ユーザーがモデルの出力の品質にフィードバックを行い、そのフィードバックがモデルのパラメータ（重み）を調整するために使用されます。チャットボットとのユーザーインタラクション、例えばいいねやバッドを押すことは、RLHFに特に有用です。これが「データフライホイール」のメカニズムです：より多くのユーザーがより多くのデータをもたらし、そのデータが逆により良いモデルを最適化します。AI企業は、ユーザーがそのモデルに提出するさまざまな質問を注意深く監視し、それに応じてデータを収集してモデルを調整し、これらのテーマをカバーします。アリババ、バイトダンス、Minimaxなどの企業は、モデルの価格競争を繰り広げており、この側面を考慮していないとは言えません。

インターネット上の事前トレーニングデータが徐々に枯渇する中、後期トレーニング（ポストトレーニング）の重要性がますます高まっています。Scale AIやSurge AIのようなラベル付け会社は、後期トレーニングデータを収集することで毎年数億ドルを稼いでいます。Scaleは最近、140億ドルの評価額で10億ドルを調達しました。今日のラベル付け作業は、Mechanical Turkの時代を超えています：トップのラベル付け者は1時間あたり最大100ドルを稼ぐことができます。後期トレーニングはより良いモデルを生成し、多くの商業アプリケーションのニーズを満たすのに役立ちますが、これは依然として増分改善であり、根本的な解決策ではありません。

データウォールを徐々に突破する以外に、完全にそれを飛び越える解決策もあります。それは、機械生成の合成データを使用することです。DeepMind（Googleの子会社）が発表したAlphaGo Zeroモデルはその良い例です。同社の最初の成功した囲碁モデルは、数百万のアマチュア試合のデータでトレーニングされましたが、AlphaGo Zeroは既存のデータを全く使用しませんでした。代わりに、3日間で490万回自分と対局することで囲碁を学び、成功した戦略を記録しました。この「強化学習」は、対戦相手の手に対して多くの可能な応答をシミュレートし、成功の可能性が最も高い戦略を選択する方法を教えました。

同様の方法はLLMにも適用できます。例えば、現在最強のオープンソース大規模モデルLlama 3.1です。LLama3.1のSFTデータには、モデル生成の合成データが相当な割合を占めており、Gemma2のSFT段階のデータも大規模なモデルによって合成されたものが多く、合成データの品質が手動ラベル付けの品質に劣らないことを証明しています。

では、無限に合成データを生成し、左足で右足を踏んで天に登ることができるのでしょうか？私は答えは否定的だと思います。先月『Nature』に発表された研究は、モデルトレーニングで合成データを「乱用」することが「不可逆的な欠陥」を引き起こす可能性があることを発見しました。モデル合成のデータを使用してモデルを微調整する場合、数回繰り返すだけでモデルは意味不明なことを言い始め、この現象を「モデル崩壊」と呼びます。

より大きな問題は、この方法を医療や教育などの垂直分野にどのように拡張するかです。ゲームでは、勝利の定義が明確であり、特定の行動が有利かどうかのデータを収集するのが容易です。他の分野では、これがはるかに複雑です。「良い」決定に関するデータは通常、専門家から収集されますが、これは高価で時間がかかり、解決策も包括的ではありません。ある専門家が正しいかどうかを判断する方法も、また別の問題です。

5 まとめ

より多くのデータを取得することは、AIの急速な進歩を維持するための鍵です。専門家のソースから取得した専門データであれ、機械生成の合成データであれ、AIの進歩はデータの継続的な供給に依存しています。最も容易に取得できるデータの蓄えが徐々に枯渇する中、AI業界はこの問題を緩和するために多くの努力をしています：

• データ品質を強調し、データクリーニングを行う
• 数学、論理、コードデータの比率を増やし、トレーニング順序を調整する
• 合成データを使用して実データを補完する

しかし、これらは持続可能ではないように見え、新しいデータソースを見つけるか、持続可能な代替案を開発する必要があります。または、アルゴリズムアーキテクチャの観点から、データに依存しない新しいアーキテクチャを設計し、次のAIサイクルを開始する必要があります。

6 推薦読書

1. 中文互联网正在加速崩塌 | 何加盐
2. Will We Run Out of Data? Limits of LLM Scaling Based on Human-Generated Data | EpochAI
3. 知乎正通过乱码来干扰必应/谷歌等爬虫 | CSDN
4. 人工智能的训练数据正在枯竭，合成数据引发巨大争议 | 华尔街见闻
5. 浅谈Llama3.1，从结构、训练过程、影响到数据合成 | 火山社区
6. AI models collapse when trained on recursively generated data | Nature

Llama 3.1 405Bを使えないわけではなく、GPT-4o-miniの方がコストパフォーマンスが良いのです。

1 微調適用シーン

一般的な簡単なタスクには、プロンプト（Prompting）を作成するだけでモデルがうまく完了できます。タスクが比較的複雑な場合、思考チェーン（Chain of Thought）を使用して複雑なタスクを複数のステップに分解し、段階的に推論することができます。しかし、高精度と一貫性のある出力が必要なタスクには、微調（Fine-tuning）が必要です。

以下の表は、これら三つの方法の利点と欠点、および応用シーンを比較したものです。

NFL定理は、どの方法もすべてのシーンに適用できるわけではないと教えてくれます。ここでも同様に、微調が他の二つの方法よりも優れているとは限りません。しかし、微調は「説明しにくいタスク」に適用されることは明らかです。例えば、あるスタイルやトーンなどです。さらに、これら三つの方法は互いに排他的ではなく、微調モデルに精巧に設計されたプロンプトを使用し、さらには思考チェーンを組み合わせることで、より良い結果を達成できるかもしれません。

単に記事や段落を書く場合は、プロンプトで十分です。しかし、ブログ記事を書く場合、SEOを考慮すると、コアキーワードの出現頻度など、多くの詳細があります。これらの詳細を大モデルがすべて理解できるとは限らず、ユーザーとしてもプロンプトでうまく説明できるとは限りません。したがって、このようなブログ記事を書くには微調を使用できます。

2 データ準備

データはjsonl形式で組織する必要があります。各行は1つのjsonです。例：

1
2
3

{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "What's the capital of France?"}, {"role": "assistant", "content": "Paris, as if everyone doesn't know that already."}]}
{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "Who wrote 'Romeo and Juliet'?"}, {"role": "assistant", "content": "Oh, just some guy named William Shakespeare. Ever heard of him?"}]}
{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "How far is the Moon from Earth?"}, {"role": "assistant", "content": "Around 384,400 kilometers. Give or take a few, like that really matters."}]}

また、複数の対話で重みを設定することもできます。weightを0に設定すると、モデルがそのような回答を避けます。

1
2
3

{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "What's the capital of France?"}, {"role": "assistant", "content": "Paris", "weight": 0}, {"role": "user", "content": "Can you be more sarcastic?"}, {"role": "assistant", "content": "Paris, as if everyone doesn't know that already.", "weight": 1}]}
{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "Who wrote 'Romeo and Juliet'?"}, {"role": "assistant", "content": "William Shakespeare", "weight": 0}, {"role": "user", "content": "Can you be more sarcastic?"}, {"role": "assistant", "content": "Oh, just some guy named William Shakespeare. Ever heard of him?", "weight": 1}]}
{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "How far is the Moon from Earth?"}, {"role": "assistant", "content": "384,400 kilometers", "weight": 0}, {"role": "user", "content": "Can you be more sarcastic?"}, {"role": "assistant", "content": "Around 384,400 kilometers. Give or take a few, like that really matters.", "weight": 1}]}

もちろん、データ処理は最も時間がかかるため、ここでは私が作成したデータセットを直接使用することもできます。このデータセットは大モデルの微調に使用され、reads.alibaba.comサイトの13の分類分野から3000以上のページをクロールしたもので、処理済みデータだけでなく、元データやクローラーコードもオープンソース化されています。

準備したデータをアップロードし、返されたファイルIDを記録します。

1
2
3
4
5
6
7

from openai import OpenAI
client = OpenAI()

client.files.create(
  file=open("all_filter_2120.jsonl", "rb"),
  purpose="fine-tune"
)

3 微調モデル

データを準備し、誤りがないことを確認し、トークンコストを確認した後、微調タスクを作成できます。

1
2
3
4
5
6
7

from openai import OpenAI
client = OpenAI()

client.fine_tuning.jobs.create(
  training_file="file-zWptPbsD37ZnemssjpsK6CnF", 
  model="gpt-4o-mini"
)

このステップの詳細なパラメータ設定については、公式APIドキュメントを参照してください。

上記の2ステップもUIインターフェースで迅速に完了でき、タスクを提出した後、UIインターフェースで進捗と損失の変化をリアルタイムで確認できます。

4 モデル呼び出し

以下のコードで微調タスクの状態を確認し、作業が成功した後、fine_tuned_modelフィールドにモデルの名前が入力されます。この名前を記録して呼び出しを行います。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

from openai import OpenAI
client = OpenAI()

# 微調タスクリストを確認
client.fine_tuning.jobs.list(limit=10)

# 微調タスクの詳細を確認
client.fine_tuning.jobs.retrieve("ftjob-gvP0VB7RlWcF3QHdQrEVf49Y")

# タスクをキャンセル
client.fine_tuning.jobs.cancel("ftjob-gvP0VB7RlWcF3QHdQrEVf49Y")

# タスクのログを確認
client.fine_tuning.jobs.list_events(fine_tuning_job_id="ftjob-gvP0VB7RlWcF3QHdQrEVf49Y", limit=10)

# 微調モデルを削除
client.models.delete("ft:gpt-3.5-turbo:acemeco:suffix:abc123")

呼び出し方法は公式のモデルと同じで、モデル名を1つ変更するだけで済みます。例えば：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

from openai import OpenAI
client = OpenAI()

completion = client.chat.completions.create(
  model="ft:gpt-4o-mini-2024-07-18:personal:0724:9oMH6S7A",
  messages=[
    {"role": "system", "content": "Please write an SEO article of no less than 800 words based on the title I gave you, including at least 4 subtitles by HTML format. Do not include the <h1> , <body> tag.  Do not include the <html> tag in the start and end of the content. Directly start with the content."},
    {"role": "user", "content": f"title:{task.title},core keyword:{task.coreKeywords},related keyword:{task.relatedKeywords}"}
  ]
)
print(completion.choices[0].message)

5 評価結果

トレーニング中に参考にできる指標が2つあり、それぞれ損失値とトークン正確率です。公式の説明は以下の通りです：

検証損失と検証トークン正確率は、2つの異なる方法で計算されます。各ステップ中の小バッチデータで計算され、各エポックの終わりに全体の検証セットで計算されます。全体の検証損失と全体の検証トークン正確率の指標は、モデルの全体的な性能を追跡する最も正確な指標です。これらの統計は、トレーニングが順調に進んでいることを確認するための合理的なチェックを提供します（損失は減少し、トークン正確率は増加するはずです）。

しかし、指標はあくまで参考であり、実際の効果は自分で評価する必要があります。微調後のモデルは少なくとも以下の改善があります：

• 記事の長さが20%増加
• 記事の構造がトレーニングデータにより近くなる
• フォーマットエラー（例えばmarkdownフォーマット、CSSの追加など）が発生しなくなる

「What is the Difference Between a Mural and a Mosaic?」という題で生成された記事は以下の通りです：

6 参考記事

• https://platform.openai.com/docs/guides/fine-tuning

もしAIを使ってタスクを完了することを作文に例えるならば、非エージェント（Agent）の方法はAIに最初から最後まで一度で書き上げさせ、修正を許さないものであり、Agentの方法はAIに何度も修正を許し、その過程でツールを利用したり、外部と協力したりすることを可能にします。2024年において、Agentは通用人工智能（AGI）を実現する道の一つと見なされています。

基礎モデルは生成型人工知能の発展を推進し、AI Agentがユーザーのタスクを自動的に完了するのを助けています。この1年間で、さまざまなAgentが次々と登場しています。Andrew Ngの紅杉AIサミットでの講演に触発され、この記事では過去1年以内に発表された論文やLangchainなどのエンジニアリングブログを組み合わせて、既存のAgentを整理し、設計パラダイムをまとめ、基礎モデルに基づくインテリジェントエージェントの設計に役立てることを目指しています。

以下の表に示す16のモードを初歩的に整理することができます：

これらの16のモードは、Andrew Ngが紅杉AIサミットでの講演で提案した4つのパラダイムにまとめることができます：

• Reflection
• Tool Use
• Planning
• Multiagent Collaboration

1 Reflection

1.1 Basic Reflection

LLM Agent構築の背景において、反思（Reflection）は、LLMに過去のステップ（およびツール/環境からの潜在的な観察）を観察させ、選択した行動の質を評価するプロセスを指します。これらのフィードバックは、再計画、検索、評価などの下流タスクに使用されます。以下の図は基本的な反思モードの一例です。

Basic Reflection

1.2 Reflexion Actor

Shinnらによって提案されたReflexionは、言語フィードバックと自己反思を通じて学習するアーキテクチャです。このエージェントはタスクの結果を評価し、より高品質な最終結果を生成しますが、実行時間が長くなります。主に以下の3つの構成要素を含みます：

1. Actor (agent) with self-reflection 自己反思を行うワーカー
2. External evaluator (task-specific, e.g. code compilation steps) 外部評価者（特定タスク、例：コードコンパイルステップ）
3. Episodic memory that stores the reflections from (1). （1）からの反思を保存するエピソード記憶

Reflexion Actor

1.3 LATS

言語エージェントツリー検索（LATS）は、Zhouらによって提案された一般的なLLM Agent検索アルゴリズムで、反思/評価と検索（特にモンテカルロツリー検索）を組み合わせ、ReACT、Reflexion、Tree of Thoughtsなどの類似技術と比較して、全体的なタスクパフォーマンスを向上させます。

主に以下の4つのステップがあります：

1. Select: pick the best next actions based on the aggregate rewards from step (2). Either respond (if a solution is found or the max search depth is reached) or continue searching.

   選択：ステップ（2）からの総報酬に基づいて最適な次のアクションを選択します。解決策が見つかった場合または最大検索深度に達した場合は応答し、そうでない場合は検索を続けます。

2. Expand and simulate: select the “best” 5 potential actions to take and execute them in parallel.

   拡張とシミュレーション：選択した「最適な」5つの候補アクションを並行して実行します。

3. Reflect + Evaluate: observe the outcomes of these actions and score the decisions based on reflection (and possibly external feedback)

   反思 + 評価：これらのアクションの結果を観察し、反思（および可能な外部フィードバック）に基づいて決定を評価します。

4. Backpropagate: update the scores of the root trajectories based on the outcomes.

   逆伝播：結果に基づいてルート軌道のスコアを更新します。

LATS

2 Tool Use

ツールを呼び出し、関数の形式で使用します。

3 Planning

3.1 ReAct

ReActは推論と行動を組み合わせることでエージェントの能力を強化します。ReActメソッドは、情報を受け取った後に即座に反応することをエージェントに許可し、すべての情報が処理されるのを待つのではなく、推論と行動の緊密な結合を重視します。エージェントは入力情報を分析し理解するだけでなく、分析結果に基づいて適切な行動を取る必要があります。この方法の利点は、その柔軟性と環境適応性にあります。

ReActフレームワーク

3.2 Plan and Execute

Plan and Executeの核心思想は、まず多段階の計画を立て、その計画を項目ごとに実行することです。特定のタスクを完了した後、計画を再検討し、適切な修正を行うことができます。

これは典型的なReActスタイルのエージェントと比較して、後者は一度に一歩を考えるものです。この「計画と実行」スタイルの利点は：

1. 明確な長期計画（非常に強力なLLMでも難しい）
2. 実行ステップでより小さな/弱いモデルを使用し、計画ステップでより大きな/優れたモデルを使用できる

Plan-and-Execute

3.3 ReWOO

ReWOOでは、Xuらは多段階のプランナーと変数置換を組み合わせたエージェントを提案し、効果的なツール使用を実現します。以下の点でReACTスタイルのエージェントアーキテクチャを改善します：

1. 使用する完全なツールチェーンを一度に生成することで、トークン消費と実行時間を削減します。（ReACTスタイルのエージェントアーキテクチャは多くのLLM呼び出しを必要とし、システムプロンプトと前のステップが各推論ステップでLLMに提供されるため冗長なプレフィックスがあります）
2. 微調整プロセスを簡素化します。計画データはツールの出力に依存しないため、理論的にはツールを実際に呼び出さなくてもモデルを微調整できます

Reasoning without Observation

3.4 LLMCompiler

LLMCompilerは、DAGでタスクを突撃実行することでエージェントタスクの実行を加速するエージェントアーキテクチャです。また、LLMの呼び出し回数を減らすことで冗長なトークン使用のコストを節約します。主に以下の3つの部分を含みます：

1. Planner: stream a DAG of tasks.

   プランナー：タスクの有向非巡回グラフをストリーム処理します。

2. Task Fetching Unit: schedules and executes the tasks as soon as they are executable

   タスク取得ユニット：タスクが実行可能になるとすぐにスケジュールし実行します

3. Joiner: Responds to the user or triggers a second plan

   ジョイナー：ユーザーに応答するか、2番目の計画をトリガーします

LLMCompiler

4 Multiagent collaboration

4.1 Supervison

監督者を通じて、複数のエージェントを管理し協力します。

監督方式

4.2 Hierarchical Teams

階層的、段階的にエージェントを組織し、複雑で作業量の多いタスクを完了します。AutoGenはこの方法の典型的な例です。

階層チーム方式

4.3 Collaboration

単一のエージェントが使用できるツールの能力には限界があり、複数のエージェントが協力してより多くの種類のツールを使用する必要があります。「分治法」の考え方を使用し、各エージェントを特定の問題を処理する「専門家」にし、彼らが協力するようにします。

基本的な多エージェント協力

5 评估

最も直接的な考え方は、エージェントを「仮想ユーザー」として使用して評価を行うことです。多くのタスク結果が量的に評価できないタスクは、この方法を使用せざるを得ないかもしれません。しかし、明確な指標があるタスク（分類、回帰）については、直接ツールを使用して評価を行うことができるかもしれません。

Agent-based Evaluation

6 AGIの其它方式

エージェントはAGIの実現において有望な方法の一つですが、唯一の方法ではありません。エージェント方式自体はRAGやユーザー参加などの方法と有機的に組み合わせることができます。例えば、以下のShiらはエージェントと検索を組み合わせる方法を用いて、大規模モデルでオリンピックプログラミング問題を解決しました。

7 推荐阅读

https://github.com/AGI-Edgerunners/LLM-Agents-Papers

https://github.com/zjunlp/LLMAgentPapers

AI agent智能体任务分解和调度的几篇经典文章 - bonelee - 博客园 (cnblogs.com)

Agent四大范式 | CRITIC：吴恩达力推Agent设计范式 - 知乎 (zhihu.com)

8 参考

1. Kim, Sehoon, Suhong Moon, Ryan Tabrizi, Nicholas Lee, Michael W. Mahoney, Kurt Keutzer, and Amir Gholami. “An LLM Compiler for Parallel Function Calling.” arXiv, February 6, 2024. https://doi.org/10.48550/arXiv.2312.04511.
2. Liu, Yue, Sin Kit Lo, Qinghua Lu, Liming Zhu, Dehai Zhao, Xiwei Xu, Stefan Harrer, and Jon Whittle. “Agent Design Pattern Catalogue: A Collection of Architectural Patterns for Foundation Model Based Agents.” arXiv, May 16, 2024. https://doi.org/10.48550/arXiv.2405.10467.
3. Shi, Quan, Michael Tang, Karthik Narasimhan, and Shunyu Yao. “Can Language Models Solve Olympiad Programming?” arXiv, April 16, 2024. https://doi.org/10.48550/arXiv.2404.10952.
4. Shinn, Noah, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. “Reflexion: Language Agents with Verbal Reinforcement Learning.” arXiv, October 10, 2023. https://doi.org/10.48550/arXiv.2303.11366.
5. Wang, Lei, Wanyu Xu, Yihuai Lan, Zhiqiang Hu, Yunshi Lan, Roy Ka-Wei Lee, and Ee-Peng Lim. “Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models.” arXiv, May 26, 2023. https://doi.org/10.48550/arXiv.2305.04091.
6. Xu, Binfeng, Zhiyuan Peng, Bowen Lei, Subhabrata Mukherjee, Yuchen Liu, and Dongkuan Xu. “ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models.” arXiv, May 22, 2023. https://doi.org/10.48550/arXiv.2305.18323.
7. Yao, Shunyu, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. “ReAct: Synergizing Reasoning and Acting in Language Models.” arXiv, March 9, 2023. https://doi.org/10.48550/arXiv.2210.03629.
8. “Yoheinakajima/Babyagi.” Accessed May 21, 2024. https://github.com/yoheinakajima/babyagi/tree/main.
9. “LangGraph tutorials.” Accessed May 21, 2024. https://langchain-ai.github.io/langgraph/tutorials/
10. Zhou, Andy, Kai Yan, Michal Shlapentokh-Rothman, Haohan Wang, and Yu-Xiong Wang. “Language Agent Tree Search Unifies Reasoning Acting and Planning in Language Models.” arXiv, December 5, 2023. https://doi.org/10.48550/arXiv.2310.04406.
11. Zhou, Pei, Jay Pujara, Xiang Ren, Xinyun Chen, Heng-Tze Cheng, Quoc V. Le, Ed H. Chi, Denny Zhou, Swaroop Mishra, and Huaixiu Steven Zheng. “Self-Discover: Large Language Models Self-Compose Reasoning Structures.” arXiv, February 5, 2024. https://doi.org/10.48550/arXiv.2402.03620.

多くのベクトルデータベースとベクトルライブラリの中で、それぞれが独自の特徴を持っており、自分のアプリケーションシナリオに適したものを選ぶには評価が必要です。本稿では、RAGにベクトルデータベースを選択する際に考慮すべき重要な要素について深く掘り下げます。これには、オープンソースの可用性、CRUD（作成、読み取り、更新、削除）サポート、分散アーキテクチャ、レプリカサポート、スケーラビリティ、パフォーマンス、継続的なメンテナンスなどの6つの側面が含まれます。

現在、Weaviate、Milvus、Qdrant、Vespa、Pineconeのようなベクトル専用に設計されたデータベースが業界で非常に注目されています。それに加えて、誕生が早いベクトルライブラリもこの機能を持っています。本文では、FAISS、HNSWLib、ANNOYのようなベクトルライブラリ、およびpgvectorやSupabaseなどのベクトル機能をサポートするSQLデータベースも比較します。

1 ベクトルライブラリ（FAISS、HNSWLib、ANNOY）

ベクトルデータベースとベクトルライブラリの違いは、ベクトルライブラリが主に静的データの保存に使用される点です。これらのライブラリでは、インデックスデータは不変です。これは、ベクトルライブラリがベクトル埋め込みのみを保存し、これらのベクトル埋め込みを生成する関連オブジェクトを保存しないためです。したがって、ベクトルデータベースとは異なり、ベクトルライブラリはCRUD（作成、読み取り、更新、削除）操作をサポートしていません。これは、FAISSやANNOYのようなベクトルライブラリで既存のインデックスに新しいドキュメントを追加するのが難しい可能性があることを意味します。HNSWLibはこの例外であり、CRUD機能を持ち、同時読み書き操作を独自にサポートしています。しかし、それもベクトルライブラリとしての制限を逃れることはできず、デプロイメントエコシステム、インスタンスのレプリケーション能力、およびフォールトトレランスを提供しません。

2 全文検索データベース（ElasticSearch、OpenSearch）

全文検索データベース（例えばElasticSearchやOpenSearch）は、比較的包括的なテキスト検索と高度な分析機能をサポートしています。しかし、ベクトル類似性検索を実行し高次元データを処理する際には、専用のベクトルデータベースに比べて強力ではありません。これらのデータベースは、主にインバーテッドインデックスに依存しており、ベクトルインデックスではないため、セマンティック検索を実現するためには他のツールと組み合わせて使用する必要があります。Qdrantのテスト結果によると、ElasticsearchはWeaviate、Milvus、Qdrantなどのベクトルデータベースと比較してパフォーマンスが劣っています。

3 ベクトルをサポートするSQLデータベース（pgvector、Supabase、StarRocks）

pgvectorのようなSQLデータベースは、ベクトルサポート拡張を通じて、ベクトルデータを既存のデータストレージシステムに統合する方法を提供しますが、専用のベクトルデータベースと比較して、いくつかの明らかな欠点もあります。

最も明らかな欠点は、従来のSQLデータベースのリレーショナルモデルと非構造化ベクトルデータの本質との間に不一致があることです。この不一致は、ベクトル類似性検索を含む操作の効率を低下させ、この種のデータベースは大量のベクトルデータを処理する際のパフォーマンスが理想的ではありません。詳細はANNテストを参照してください。さらに、pgvectorがサポートするベクトル次元の上限（2000次元）は、Weaviateのような専用ベクトルデータベースと比較して低く、後者は最大65535次元のベクトルデータを処理できます。スケーラビリティと効率の面で、専用ベクトルデータベースはより優れています。ベクトルをサポートするSQLデータベース拡張、例えばpgvectorは、ベクトルデータ量が少ない（10万ベクトル未満）で、ベクトルデータがアプリケーションの補完機能としてのみ使用されるシナリオに適しています。逆に、ベクトルデータがアプリケーションのコアである場合や、スケーラビリティに高い要求がある場合、専用ベクトルデータベースがより適した選択となります。

StarRocksについては、SQLフレームワーク上で動作する別のシステムであり、オンライン分析処理（OLAP）およびオンライントランザクション処理（OLTP）シナリオに最適化されていますが、ベクトル類似性検索に特化して最適化されているわけではありません。

4 ベクトルをサポートするNoSQLデータベース（Redis、MongoDB）

NoSQLデータベースに新たに追加されたベクトルサポート機能はまだ初期段階にあり、十分なテスト検証を経ていません。Redisベクトル類似性検索（VSS）を例にとると、この機能は2022年4月に公開され、まだ2年未満です。Redis VSSは多機能データベースとしてサービスを提供できますが、ベクトル類似性検索に最適化された設計ではありません。

5 専用ベクトルデータベース（Pinecone、Milvus、Weaviate、Qdrant、Vald、Chroma、Vespa、Vearch）

専用ベクトルデータベースは、ドット積、コサイン類似度など、さまざまなベクトル演算をネイティブにサポートしています。これらのデータベースは高次元データを処理するために設計されており、大量のクエリ要求に対応し、ベクトル間の類似性検索を迅速に完了することができます。これらの目標を達成するために、通常は近似最近傍（ANN）アルゴリズムに基づいた多様なインデックス戦略を採用しています。これらのアルゴリズムは、効率、ストレージスペースの占有、および検索の正確性の間でトレードオフを必要とします。たとえば、FLATインデックスは、最適化や近似技術を使用しないベクトルインデックスであり、100％のリコール率と精度を実現できますが、他のタイプのベクトルインデックスよりも遅く、効率が低いです。相対的に、IVF_FLATインデックスは、いくつかの精度を犠牲にして、より高速な検索速度を実現します。HNSWインデックスは、精度と検索速度の間で妥協案を提供します。

Pineconeは、プロフェッショナルチームによって維持されるクローズドソースのベクトルデータベースであり、無料版ではスケーラビリティの面で限られた機能を提供しています。Chromaは音声データ専用に設計されたシステムですが、テキストデータの処理に特別な最適化は行われていません。他の主流のベクトルデータベースと比較して、Chromaの総合的なパフォーマンスベンチマークの資料は比較的少ないです。Chromaは0.4バージョンでSQLiteをドキュメントストレージ方式として採用しているため、スケーラビリティと効率の面で、他のベクトルデータ専用に設計されたストレージソリューションに劣る可能性があります。

VearchとValdは、Langchainとの統合において不足しており、開発の使用にとって非常に不利です。Milvusなどの競合他社と比較して、開発者コミュニティの規模が小さく、オープンソースコミュニティのメンテナンスも活発ではありません。

したがって、RAGにとって、Weaviate、Milvus、Qdrant、Vespaは最良の選択肢かもしれません。理論的には、パフォーマンスとスケーラビリティのベンチマークテスト（下記のANNベンチマークを参照）に基づいて最適なシステムを選択する必要があります。しかし、システム設計や機能の特徴も比較する必要があります。以下の表は、これらの側面から視覚的に比較しています。

要約すると、Qdrantは非常に小さなオーバーヘッドで、Weaviateはベクトル検索、オブジェクトストレージ、インバーテッドインデックスの組み合わせをサポートし、Milvusは最も強力なパフォーマンスと多くの機能を持っています。

6 ベクトルデータベースの検索方法の比較

6.1 Milvus

Milvusは、コレクション内のベクトルフィールドの数に応じて、2種類の検索をサポートしています：単一ベクトル検索と多ベクトル検索。

単一ベクトル検索は、search()メソッドを使用して、クエリベクトルとコレクション内の既存のベクトルを比較し、最も類似したエンティティのIDとその間の距離を返します。また、結果のベクトル値とメタデータをオプションで返すこともできます。

多ベクトル検索は、2つ以上のベクトルフィールドを持つコレクションに適しており、hybrid_search()メソッドを使用して実行されます。このメソッドは、複数の近似最近傍（ANN）検索リクエストを実行し、結果を再ランキングして最も関連性の高い一致を返します。（最新の2.4.xバージョンでサポートされ、最大10個のベクトル検索が可能です）

多ベクトル検索は、高精度が必要な複雑な状況に非常に適しており、特に1つのエンティティが複数の異なるベクトルで表現できる場合に役立ちます。これは、同じデータ（例えば1つの文）が異なる埋め込みモデルで処理される場合や、多モーダル情報（例えば個人の画像、指紋、声紋）がさまざまなベクトル形式に変換される場合に適しています。テーブル全体の「マルチウェイリコール」を通じて、これらのベクトルに重みを割り当てることで、それらの総合的な効果がリコール能力を大幅に向上させ、検索結果の有効性を高めることができます。

その他の基本的な検索操作：

• 基本検索には、単一ベクトル検索、バッチベクトル検索、パーティション検索、指定された出力フィールドを持つ検索が含まれます。
• フィルタ検索は、スカラーフィールドのフィルタ条件に基づいて検索結果を絞り込みます。
• 範囲検索は、クエリベクトルと特定の距離範囲内のベクトルを見つけます。
• グループ検索は、特定のフィールドに基づいて検索結果をグループ化し、結果の多様性を確保します。

6.2 Weaviate

• ベクトル類似度検索：一連の近似検索方法をカバーし、この種の検索はクエリベクトル表現に最も類似したオブジェクトを探します。
• 画像検索：画像を類似度検索の入力として使用します。
• キーワード検索：BM25Fアルゴリズムを使用して結果をランク付けするキーワード検索。
• ハイブリッド検索：BM25と類似度検索を組み合わせて結果をランク付けします。
• 生成的検索：検索結果をLLMのプロンプトとして使用します。
• 再ランキング：検索された検索結果を再ランキングモジュールを使用して再ランキングします。
• 集計：結果セットからデータを集計します。
• フィルタ：検索に条件フィルタを適用します。

6.3 Qdrant

サポートされている基本的な検索操作：

• 関連スコアによるフィルタリング
• 単一リクエストで複数の検索操作をロード
• 推奨API
• グループ操作

Qdrantがサポートするその他の検索方法：

Qdrantは全文検索またはハイブリッド検索をサポートしていますか？

Qdrantはまずベクトル検索エンジンであり、ベクトル検索ユースケースに影響を与えない場合にのみ全文サポートを実装します。これにはインターフェースとパフォーマンスが含まれます。

Qdrantができること：

• 全文フィルタを使用して検索
• 全文フィルタをベクトル検索に適用する（つまり、特定の単語やフレーズを含むレコードでベクトル検索を実行する）
• プレフィックス検索とセマンティックインスタント検索を行う

Qdrantが将来導入する予定の機能：

• SPLADEや類似モデルで使用されるスパースベクトルのサポート

Qdrantがサポートする予定のない機能：

• BM25または他の非ベクトルベースの検索またはランキング関数
• 組み込みのオントロジーまたは知識グラフ
• クエリアナライザーやその他のNLPツール

現在のところ、ベクトルデータベースのセマンティック検索特性と、従来のキーワード検索の正確な特性を両立させる方法があるかどうかが課題です。

7 付録

7.1 ANNベンチマーク

ベンチマークは、検索タイプ（フィルタ検索または通常検索）、設定、インデックスアルゴリズム、データ埋め込み、ハードウェアなど、データベースのパフォーマンスに影響を与えるさまざまな要因によって影響を受けます。ベンチマークのパフォーマンスに加えて、ベクトルライブラリを選択する際には、分散能力、メモリレプリカとキャッシュのサポート、採用されているインデックスアルゴリズム、ベクトル類似性検索の能力（ハイブリッド検索、フィルタリング、およびさまざまな類似性メトリックを含む）、シャーディングメカニズム、クラスター方法、スケーラビリティの可能性、データの一貫性、およびシステムの全体的な可用性など、複数の側面を考慮する必要があります。

ANN-Benchmarks は、近似最近傍アルゴリズムの検索パフォーマンスを評価する主要なベンチマークプラットフォームです。テキスト検索では、ベクトルデータベースの角度メトリックでのパフォーマンスは、ユークリッドメトリックでのパフォーマンスよりも重要です。これは、角度メトリックが文書のセマンティック類似性に対してより敏感であり、ユークリッドメトリックが文書の長さと規模に対してより敏感であるためです。したがって、生成されたコンテキストの検索を強化する際には、異なる次元を超えた角度データセットでのベクトルデータベースのパフォーマンスを評価することに焦点を当てる必要があります。

7.1.1 glove-100-angular

7.1.2 nytimes-256-angular

7.2 ベクトル類似度指標

以下は、各指標の詳細な紹介であり、それらの相対的な利点、欠点、およびそれらが適した使用シナリオを含んでいます。

7.2.1 コサイン距離

コサイン距離は、2つのベクトル間の角度のコサイン値を測定し、正規化または凸集合を処理する際によく使用されます。

• 利点：主にベクトルの方向を考慮し、高次元空間（例えばテキストの比較）に非常に適しています。テキストの比較では、文書の長さがそれほど重要ではありません。
• 欠点：ベクトル次元の一致が必要なシナリオには適していません。例えば、ピクセル密度に基づいて画像の埋め込みを比較する場合です。データが凸集合を形成していない場合、正確な類似性メトリックを提供できない可能性があります。

コサイン距離は、文書分類、セマンティック検索、推薦システム、および高次元データと標準化データを含むその他のタスクに適しています。情報を検索する際には、コサイン距離はクエリコンテンツと文書ベクトル間の類似性を測定するために使用され、長さを無視し、セマンティックな意味に焦点を当てます。

7.2.2 ユークリッド距離 L2

ユークリッド距離は、多次元空間で2つのベクトル間の直線距離を計算し、二乗ノルムとも呼ばれます。

• 利点：直感的で計算が容易であり、ベクトルの大きさと方向の両方に敏感です。
• 欠点：「次元の呪い」により、高次元空間でのパフォーマンスが低下する可能性があります。

画像認識、音声認識、手書き分析などのシナリオに適しています。

7.2.3 内積

内積は、ベクトルの対応する成分の積の和を計算し、n乗ノルムとも呼ばれます。

• 利点：計算速度が速く、ベクトルの大きさと方向を反映します。
• 欠点：ベクトルの方向に敏感であるだけでなく、ベクトルの大きさにも敏感です。

内積の最も古典的な応用は、推薦システムの分野です。推薦システムでは、内積を使用してユーザーベクトルとアイテムベクトル間の類似度を決定し、ユーザーが特定のアイテムに対して持つ興味を予測するのに役立ちます。内積は、推薦システム、協調フィルタリング、行列分解に適しています。

7.2.4 L2平方距離

2つのベクトル間のユークリッド距離の平方。

• 利点：ベクトル要素間の大きな差異を罰することができ、特定の状況で役立つ可能性があります。
• 欠点：平方操作が距離を歪める可能性があり、外れ値に敏感です。

L2平方距離は、特定の次元の差異の問題に特に適しており、例えば画像処理で2つの画像の違いを比較する際に使用されます。

7.2.5 ハミング距離

各次元でベクトル間の差異数を測定します。

• 利点：バイナリまたは分類データの比較に適しています。
• 欠点：連続または数値データには適していません。

適用シナリオも比較的特殊であり、例えばエラー検出と修正（分類データ）や、2つのDNA鎖間の遺伝的距離を測定する際に使用されます。

7.2.6 マンハッタン距離 L1

直角軸に沿って2つのベクトル次元間の距離を測定し、一乗ノルムとも呼ばれます。

• 利点：ユークリッド距離よりも外れ値に対して耐性があります。
• 欠点：幾何学的な意味ではユークリッド距離ほど直感的ではありません。

チェスボード距離の計算や、物流計画における最短経路問題に適しています。

8 参考資料

1. https://github.com/milvus-io/milvus
2. Powering AI With Vector Databases: A Benchmark - Part I - Data - Blog - F-Tech (farfetchtechblog.com)
3. Fundamentals - Qdrant
4. Milvus documentation
5. Home | Weaviate - Vector Database
6. Qdrant Documentation - Qdrant
7. Vector Database Use Cases - Qdrant

1 RAGとは何か

外部資料を検索することで生成AIモデルの正確性と信頼性を向上させる技術が、検索強化生成技術（Retrieval-Augmented Generation）です。大規模言語モデル（LLM）がタスクを完了する過程を試験に例えるなら、RAGを持つ大規模モデルはオープンブックテストに相当し、RAGのサポートがない場合はクローズドブックテストのようです。RAGはLLMが資料を検索することで、生成効果を向上させる技術です。

RAGはPatrick Lewisらによってこの論文で初めて提案され、彼らが所属する会社がCohereです。この会社は現在、EmbeddingやRerankモデルを含むAPIサービスを提供しており、性能も非常に優れています。

2 なぜRAGが必要なのか

RAGの登場は、大規模言語モデルがアプリケーションで直面するいくつかの問題と不足を解決するためです。最も顕著な点は大規模モデルの幻覚問題であり、これは大規模モデルの出力が事実と一致しないか、答えを捏造することです。また、LLMを訓練するためのデータが古く、LLMが新しい資料を全く知らない可能性があります。

RAGはLLMが最新またはカスタムの資料にアクセスできるようにし、ユーザーがLLMの情報源を検証できるようにして、その正確性を確保します。RAGが検索するデータは公開されているもの（検索エンジンなど）もあれば、非公開のもの（企業資料、個人の機密データなど）もあります。この点がRAGに広い応用の可能性を与えています。RAGはすでに広く使用されており、例えばNVIDIAのNeMo Retrieverは企業内部資料を読み取り、月の暗面のKimi Chatは検索エンジンを利用して回答しています。

3 RAGを中心に構築されたナレッジベース

AIナレッジベースはAIが「オーダーメイド」できるようにする重要なツールです。ナレッジベースを通じてAIがタスクをより良く完了できるようにするために、現在のAIナレッジベースの構築方法には以下の3つがあります：

• プロンプトエンジニアリング (Prompt Engineering)
• 微調整 (Fine Tuning)
• 埋め込み (Embedding)

プロンプトエンジニアリングは、プロンプト内にナレッジベースを直接構築し、すべての資料をプロンプトに入れる方法です。この方法は小規模での使用に適していますが、現在のAIモデルの入力トークン数ではこの実装方法を満たすことは基本的にできません。実際、AIが発展し、ある日AIの入力ウィンドウが一般的なナレッジベースを収容できるほど十分に大きくなったとしても、ナレッジベースを構築することには依然として価値があります。なぜなら、入力の内容の長さがAIの性能に影響を与えるからです（少なくとも現在のモデルではそうです）。具体的にはNeedle In A Haystack - Pressure Testing LLMsを参照してください。

微調整は学界でよく見られる形式で、特定のタスクデータを使用して事前訓練モデルを微調整します。この方法は実際には業界共通の大規模モデルを作成するのに適しています。例えば、法律業界の大規模モデル、医療大規模モデルなどです。一方で、微調整には多くの訓練データが必要で、コストも高いです。また、微調整はあまり柔軟ではなく、1、2つのドキュメントに基づいて即座に調整することはできません。微調整の過程は実際には訓練データを学習し、一般化することであり、内容を記憶するというよりも、特定の分野の能力を強化することです。

したがって、現在最も主流のナレッジベースの構築方法は、Embeddingの方法を採用しています。そして、この形式のナレッジベースもRAGと組み合わせる必要があります。

4 RAGの基本構成

クラシックで基本的なRAGの構成は以下の図のようになっています。

4.1 Embedding 埋め込み

このプロセスでは、ユーザーは最初にドキュメントをアップロードし、システムはアップロードされたドキュメントをEmbeddingを通じてベクトルデータベースに保存します。Embeddingは、意味が類似したテキストを距離が近いベクトルに変換することであり、このプロセスは俗にベクトル化と呼ばれます。

4.2 Retrieval 検索

ユーザーがLLMに質問すると、質問の内容はEmbeddingを経てベクトルデータベースで一致し、一連の内容が検索されます。これが第一段階の検索です。

4.3 Rerank 再順位付け

ベクトルデータベースで直接検索された内容は完璧ではない可能性があり、結果が検索内容と一致しないことがよくあります。したがって、第二段階の検索、つまりRerankが必要です。この段階では、Rerankモデルが前の段階で検索された内容を再順位付けし、関連性に基づいて結果を出力します。Rerankが完了した後、Top Kを取得して後の生成段階で使用できます。

5 5行コードでRAGを実装

代入文が1行と数える

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

from transformers import RagTokenizer, RagRetriever, RagTokenForGeneration
from datasets import load_dataset

retriever = RagRetriever.from_pretrained(
    config_name = "facebook/rag-token-nq",
    index_name = "compressed",  # インデックスのタイプ
    use_dummy_dataset = True,  # テスト用にダミーデータセットを使用
    dataset = "wiki_dpr"  # 検索に使用するデータセット
)

# 事前訓練されたtokenizerとモデルをロード
tokenizer = RagTokenizer.from_pretrained("facebook/rag-token-nq")
model = RagTokenForGeneration.from_pretrained("facebook/rag-token-nq", retriever=retriever)

# 質問を入力しベクトルに変換
input_ids = tokenizer(input_text = "What is the capital of France?", 
		return_tensors="pt").input_ids

# 回答を生成
outputs = model.generate(input_ids)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

RagTokenizerはテキストのトークン化に使用され、RagTokenForGenerationはRAGモデルの生成部分であり、RagRetrieverは検索を担当する部分です。RagTokenizer.from_pretrained("facebook/rag-token-nq")は、事前に訓練されたトークナイザーをロードし、テキストをモデルが理解できる形式（トークン化）に変換します。RagTokenForGeneration.from_pretrained("facebook/rag-token-nq", retriever=retriever)は、事前訓練されたRAGモデルをロードします。facebook/rag-token-nqはモデルとトークナイザーの名称で、Natural Questionsデータセットで事前訓練されています。

6 オープンソースのRAG実装

DifyはLLMアプリケーション開発プラットフォームで、すでに10万以上のアプリケーションがDify.AIを基に構築されています。Backend as ServiceとLLMOpsの理念を融合し、生成AIネイティブアプリケーションを構築するために必要なコア技術スタックをカバーしています。内蔵RAGエンジンを含む。Difyを使用すると、任意のモデルに基づいてAssistants APIやGPTsの能力を自動展開できます。このプロジェクトは蘇州の会社によって主催されており、SasSサービスを提供しています。

Langchain-Chatchatは、ChatGLMなどの大規模言語モデルとLangchainなどのアプリケーションフレームワークに基づいて実装された、オープンソースでオフラインデプロイ可能な検索強化生成（RAG）大規模モデルナレッジベースプロジェクトです。最初はChatGLMモデルのみをサポートしていましたが、その後多くのオープンソースモデルやオンラインモデルのサポートが追加されました。

両社の機能比較は以下の表の通りです：

実際には、現在のオープンソースプロジェクトが完全にカバーしていない機能もいくつかあります。例えば：

• マルチモーダル能力
• 伝統的なリレーショナルデータベースのサポート
• 複数のデータベースの統合/クロスデータベースの資料取得
• 引用機能
• 高度なRAG
• 評価指標

7 参考資料

1. gkamradt/LLMTest_NeedleInAHaystack: Doing simple retrieval from LLM models at various context lengths to measure accuracy (github.com)
2. What is retrieval-augmented generation? | IBM Research Blog
3. Retrieval (langchain.com)
4. langgenius/dify (github.com)
5. Langchain-Chatchat (github.com)

1 標準出力（stdout）と標準エラー（stderr）

ほとんどのオペレーティングシステムでは、標準出力と標準エラーはプロセスの2つの主要な出力ストリームです。これらは、プロセスが情報やエラーメッセージを端末やファイルに送信するためのメカニズムを提供します。物理的には同じ（例えば、同じ端末インターフェースに表示される）場合があるものの、論理的には異なる目的で使用されます：

• 標準出力（stdout）：通常、プログラムの実行結果や正常な動作情報を出力するために使用されます。
• 標準エラー（stderr）：エラーメッセージや警告を出力するために特化しており、標準出力がリダイレクトされている場合でも、これらの情報は通常表示されるか記録される必要があります。

2 Pythonにおけるprintとlogging

Pythonでは、print関数はデフォルトで情報をstdoutに送信し、loggingモジュールはデフォルトでログメッセージをstderrに送信します。これは、通常のプログラム出力とログ（エラーやデバッグ情報を含む）出力を区別しやすくするためです。

2.1 printの使用

printはPythonで最も基本的な出力関数で、情報を標準出力ストリームに出力するために使用されます。簡単で使いやすく、迅速なデバッグやユーザーへの情報表示に適しています。例えば：

1

print("Hello, world!")

2.2 loggingの使用

loggingモジュールは、アプリケーションにログメッセージを追加するための柔軟なフレームワークを提供します。printとは異なり、loggingは異なるログレベル（DEBUG, INFO, WARNING, ERROR, CRITICAL）をサポートしており、必要に応じてログの詳細度や出力先を調整できます。例えば：

1
2
3

import logging

logging.error('This is an error message')

3 tqdmとstderr

複雑または長時間実行されるプログラムでは、進行状況バーを使用してプロセスの進行をユーザーに示すことが効果的です。Pythonのtqdmライブラリは、コマンドラインに進行状況バーを追加するための広く使用されているツールです。tqdmはデフォルトで進行情報をstderrに出力し、通常のプログラム出力（stdout）を妨げないようにします。

3.1 stdoutとstderrの分流

場合によっては、通常の出力とエラーやログメッセージを分けることが有用です。例えば、これらを異なるファイルや端末にリダイレクトすることができます。コマンドラインでは、リダイレクト演算子>と2>を使用して実現できます。Pythonコードでは、loggingモジュールの設定や特定のファイルオブジェクトを使用して、より細かい制御が可能です。

1

python script.py > output.log 2> error.log

コマンドラインリダイレクト、Pythonのprint関数、さらにはloggingモジュールを通じて、これら2種類の出力を柔軟に制御および分流することができ、エラー処理、ログ記録、ユーザーインタラクションがより明確かつ秩序立ったものになります。

4 nohupを使用したstdoutとstderrの管理

長時間実行されるバックグラウンドプロセスをデプロイする際、nohupコマンドは重要なツールとなります。nohup（「no hang up」）は、ユーザーがログアウトした後もコマンドを実行し続けることを可能にし、特にリモートでタスクを開始する際に便利です。nohupの重要な特性の1つは、stdoutとstderrを管理する能力です。

デフォルトでは、nohupを使用してコマンドを実行すると、stdoutとstderrがnohup.outファイルに統合されてリダイレクトされますが、別途指定しない限りです。これにより、通常の出力とエラーメッセージの両方が同じファイルにキャプチャされ、後で確認するのに便利です。しかし、場合によっては、これら2種類の出力を分けることがより有用です。

4.1 stdoutとstderrを分けるnohupの使用

nohupを使用する際にstdoutとstderrを異なるファイルに出力するには、リダイレクト演算子を組み合わせて使用します。例えば：

1

nohup python script.py > output.log 2> error.log &

このコマンドは、stdoutをoutput.logにリダイレクトし、stderrをerror.logにリダイレクトし、&でバックグラウンドで実行します。これにより、端末やSSHセッションを閉じてもプログラムは実行を続け、その出力は適切に記録されます。

5 Pythonにおけるバッファリング動作

stdoutとstderrは、データをバッファリングする際に異なる動作を示します。デフォルトでは、stdoutは行バッファリングされ、端末に接続されている場合、データは改行文字を受け取るかバッファが満たされるまでキャッシュされます。非対話モードでは、stdoutはブロックバッファリングされます（ファイルのように）。一方、stderrは常に行バッファリングされます（Python 3.9以前のバージョンでは、非対話モードではブロックバッファリングされていました）。以下は公式ドキュメントからの引用です：sys — システム関連のパラメータと関数 — Python 3.12.2 ドキュメント

対話的な場合、stdoutストリームは行バッファリングされます。それ以外の場合、通常のテキストファイルのようにブロックバッファリングされます。stderrストリームはどちらの場合も行バッファリングされます。両方のストリームをバッファリングしないようにするには、[u](<https://docs.python.org/3.12/using/cmdline.html#cmdoption-u>)コマンドラインオプションを渡すか、[PYTHONUNBUFFERED](<https://docs.python.org/3.12/using/cmdline.html#envvar-PYTHONUNBUFFERED>)環境変数を設定します。

バージョン3.9で変更: 非対話的なstderrは、完全にバッファリングされる代わりに行バッファリングされるようになりました。

バッファの粒度が小さいほど、出力はより迅速になりますが、対応するIOコストも大きくなります。Python 3.8以前では、stdoutとstderrは同じ粒度でバッファリングされていましたが、これはあまり合理的ではありませんでした。3.9以降、stderrはより小さなバッファ粒度を持つようになり、各書き込み操作の出力がstdoutよりも迅速になります。この差異により、stderrはエラーやログ情報に適しており、プログラムがクラッシュしたり異常終了した場合でも、これらの情報が標準出力よりも高い優先度で出力されることが保証されます。

C++では、標準エラーはバッファリングされていない（後述）ため、より積極的ですが、個人的にはこの方が合理的だと思います。

幸いなことに、Pythonではpython -uや環境変数PYTHONUNBUFFEREDを設定することで、このバッファリング動作を無効にしたり、sys.stdout.flush()を直接操作して出力のタイミングを制御することができます。

6 Pythonの並行環境での動作

マルチスレッドまたはマルチプロセス環境でstdoutとstderrを使用する場合、出力が交錯したり混乱したりする可能性があります。これは、異なるスレッドやプロセスからの出力が端末やファイルに書き込まれる際に相互に干渉する可能性があるためです。この問題を解決する方法の1つは、各スレッドやプロセスに独立した出力ファイルを作成するか、スレッドロック（thread locks）やプロセス同期メカニズム（例：multiprocessing.Lock）を使用してstdoutやstderrへのアクセスを同期することです。

7 Pythonでのstdoutとstderrの制御

複雑なアプリケーションでは、出力ストリームの目的地をより柔軟に制御する必要があるかもしれません。Pythonはこれを実現するためのさまざまな方法を提供しています：

• stdoutとstderrのリダイレクト：Pythonプログラムの標準出力とエラー出力をリダイレクトするには、sys.stdoutとsys.stderrの値を変更することができます。これは、出力をキャプチャして分析したり、出力をグラフィカルインターフェースなどの非標準出力デバイスにリダイレクトする際に特に有用です。
• subprocessモジュールの使用：外部コマンドやスクリプトを実行する際、subprocessモジュールを使用すると、コマンドのstdoutとstderrストリームを制御できます。これには、Pythonプログラム内部の変数にリダイレクトしたり、分離または統合したりすることが含まれます。
• ログモジュールの高度な応用：Pythonのloggingモジュールは、ログを複数の目的地に出力することをサポートしています。これには、ファイル、標準出力、ネットワークなどが含まれます。異なるログハンドラ（handlers）を設定することで、ログレベルやメッセージ内容に基づいてログを異なる出力に分流するなど、複雑なログ管理スキームを実現できます。

7.1 提案

• 出力の管理に注意を払う：ソフトウェアを設計する際、ユーザーインタラクションに使用する出力（stdout）とエラー報告やログ記録に使用する出力（stderr）を明確に区別します。これにより、プログラムの可用性と保守性が向上します。
• パフォーマンスを最適化する：特に高頻度のログやデータ出力のシナリオでは、出力操作のパフォーマンスへの影響を考慮します。バッファリングやバッチ処理を適切に使用することで、パフォーマンスへの影響を軽減できます。
• セキュリティを考慮する：出力する前に適切なフィルタリングやデータのマスキングを行い、ログを通じて機密データが漏洩しないようにします。

stdoutとstderrを深く理解し、柔軟に応用することで、より堅牢で管理しやすいPythonアプリケーションを構築し、ログと出力を効果的に処理し、ユーザーエクスペリエンスとアプリケーションの安定性を向上させることができます。

8 C++におけるバッファリング動作

C++では、stdout（通常はstd::coutに対応）とstderr（std::cerrに対応）は異なるバッファリング戦略を持っています：

• std::cout はデフォルトで行バッファリングされており、端末に接続されている場合、出力は各行の終わりでフラッシュされるか、バッファが満たされたときにフラッシュされます。
• std::cerr はデフォルトでバッファリングされていないため、std::cerrに書き込まれたデータは即座に出力されます。これは、プログラムがクラッシュしてエラーメッセージが出力されないリスクを減少させるため、エラーメッセージの報告に非常に有用です。

9 stdoutとstderrのリダイレクト

C++プログラムでは、stdoutとstderrをリダイレクトするためのさまざまな方法があります。一般的な方法の1つは、プログラムの実行中にfreopen関数を使用して標準出力またはエラー出力をファイルにリダイレクトすることです：

1
2

freopen("output.txt", "w", stdout);
freopen("error.log", "w", stderr);

この方法は、出力をファイルにリダイレクトし、後で分析やデバッグを行うのに便利です。

10 C++のマルチスレッド環境での使用

C++のマルチスレッドプログラムでstd::coutやstd::cerrを使用する際、競合状態が発生し、出力が混乱する可能性があります。このような状況を回避するために、std::mutexなどのミューテックスを使用してこれらのストリームへのアクセスを同期することをお勧めします：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

#include <iostream>
#include <mutex>
#include <thread>

std::mutex cout_mutex;

void thread_function(int id) {
    std::lock_guard<std::mutex> lock(cout_mutex);
    std::cout << "Thread " << id << " is running\\n";
}

int main() {
    std::thread t1(thread_function, 1);
    std::thread t2(thread_function, 2);

    t1.join();
    t2.join();

    return 0;
}

11 C++での出力制御

C++標準ライブラリはstd::streambufを提供しており、std::coutやstd::cerrのより細かい制御を実現するために使用できます。これには、リダイレクトやカスタムバッファリング動作の実装が含まれます。std::streambufを継承し、対応するメンバ関数をオーバーライドすることで、カスタムバッファリング戦略を作成したり、出力をGUIコンポーネントやネットワーク接続などにリダイレクトすることができます。

11.1 提案

• バッファを適切に使用する：アプリケーションのシナリオに応じて適切なバッファリング戦略を選択します。即時フィードバックが必要なエラーメッセージには、std::cerrを使用するか、手動でstd::coutをフラッシュします。
• マルチスレッドで標準出力を直接使用しない：出力の一貫性と順序を保証するために、ミューテックスや他の同期メカニズムを使用します。
• リダイレクトとカスタムstreambufを使用する：出力をより柔軟に処理するために、リダイレクトやカスタムstreambufを使用して、ログ記録やネットワーク伝送などの特殊な出力要件を実現します。

これらの高度な技術を習得することで、C++プログラムの堅牢性と柔軟性を確保しながら、プログラムの出力を効果的に管理および制御することができます。

ウェブコンテンツを共有または分析する際、長いスクリーンショットは非常に便利な形式です。ページを完全に表示することができます。しかし、これらの長いスクリーンショットを処理する際に、情報の完全性と可読性を保ちながら後続の操作を容易にすることは常に課題でした。例えば、現在（2024年初頭）の市場にある主流のAI画像モデルは、非常に大きく複雑な画像を処理できません。長いスクリーンショットを無理にモデルに入力すると、モデルの出力性能が低下し（多くの詳細が認識されない）、問題が生じます。この問題を解決するために、OpenCVに基づいたツールを開発し、長いスクリーンショットの処理を簡素化し、その内容の完全性と可読性を保つことを目指しました。

このプロジェクトは私のGithubでオープンソース化されています：https://github.com/Ryaang/Web-page-Screenshot-Segmentation

多くの既存のツールや方法とは異なり、Web-page-Screenshot-SegmentationはOpenCVを使用してウェブコンテンツの自然な区切り線を自動で認識し、最適な分割点を見つけます。つまり、タイトル、段落、またはグラフが分割後の画像にきちんと保持され、内容の断裂や欠落が発生しません。

Web-page-Screenshot-Segmentationの使用は非常に簡単で、長いスクリーンショットを用意するだけで、ツールが画像内容を自動で分析し、分割点を賢く決定します。最終的に、一連の完全で構造化された画像が得られ、共有やさらなる処理が容易になります。

2 介绍

このプロジェクトは、テキストの高さに基づいてウェブページの長いスクリーンショットをいくつかの部分に分割するためのものです。主な考え方は、画像の低変化領域を見つけ、その低変化領域で分割線を見つけることです。

出力されるのは、ウェブページの小さくて完全な画像で、Screen-to-codeを使用してウェブページを生成したり、モデルを訓練したりするのに使用できます。より多くの結果は、imagesディレクトリで見つけることができます。

3 开始使用

3.1 安装

1

 pip install Web-page-Screenshot-Segmentation

4 在命令行中使用

画像の分割線の高さを取得する

1

python -m Web_page_Screenshot_Segmentation.master -f "path/to/img"

出力はリストであるはずです：[6, 868, 1912, 2672, 3568, 4444, 5124, 6036, 7698]。これは画像の分割線の高さのリストです。 画像にこの分割線を表示したい場合は、 -s Trueパラメータを追加できます：

1

python -m Web_page_Screenshot_Segmentation.master -f "path/to/img" -s True

4.1 在图像中画出分割线

1

python -m Web_page_Screenshot_Segmentation.drawer --image_file path/to/image.jpg --hl [100,200] --color (0,255,0)

4.2 切分图像

1

python -m Web_page_Screenshot_Segmentation.spliter --f path/to/image.jpg -ht "[233,456]"

分割された画像が得られ、コマンドの戻り値のパスに保存されます。

より多くの使用法の説明は、ヘルプを参照してください：

1
2

python master.py --help
python spliter.py --help

5 从源码使用

5.1 split_heights 函数

split_heights 関数は、さまざまな閾値に基づいて画像をいくつかの部分に分割するために使用されます。以下のパラメータを受け取ります：

• file_path: 画像ファイルのパス。
• split: 画像を分割するかどうかを示すブール値。
• height_threshold: 低変化領域の高さの閾値。
• variation_threshold: 低変化領域の変化の閾値。
• color_threshold: 色差の閾値。
• color_variation_threshold: 色差変化の閾値。
• merge_threshold: 2本の線の間の最小距離の閾値。

split が False の場合、関数は分割線の高さのリストを返します。split が True の場合、分割された画像のパスを返します。

5.1.1 示例用法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

import Web_page_Screenshot_Segmentation
from Web_page_Screenshot_Segmentation.master import split_heights

# 'path/to/image.jpg' をいくつかの部分に分割する
split_image_path = split_heights(
    file_path='path/to/image.jpg',
    split=True,
    height_threshold=102,
    variation_threshold=0.5,
    color_threshold=100,
    color_variation_threshold=15,
    merge_threshold=350
)

print(f"分割された画像は {split_image_path} に保存されました")

この例では、提供された閾値に基づいて、‘path/to/image.jpg’ の画像がいくつかの部分に分割されます。分割された画像は関数の戻り値のパスに保存されます。

5.2 draw_line_from_file 函数

draw_line_from_file 関数は、指定された高さの画像に線を描画するために使用されます。以下のパラメータを受け取ります：

• image_file: 画像ファイルのパス。
• heights: 指定された高さに線を描画する高さのリスト。
• color: 線の色。デフォルトの色は赤 (0, 0, 255) です。

この関数は、提供されたファイルパスから画像を読み込み、指定された高さに線を描画し、変更された画像を新しいファイルに保存します。新しいファイルは result ディレクトリに保存され、元のファイルと同じ名前ですが、ファイル拡張子の前に ‘result’ が追加されています。

関数が画像ファイルの読み込み中にエラーに遭遇した場合（例えば、ファイルパスに ‘.’ や日本語文字が含まれている場合）、例外がスローされます。

5.2.1 示例用法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

import Web_page_Screenshot_Segmentation
from Web_page_Screenshot_Segmentation.spliter import draw_line_from_file

# 'path/to/image.jpg' の画像に、高さ 100 と 200 に線を描画する
result_image_path = draw_line_from_file(
    image_file='path/to/image.jpg',
    heights=[100, 200],
    color=(0, 255, 0)  # 緑色で線を描画
)

print(f"変更された画像は {result_image_path} に保存されました")

この例では、‘path/to/image.jpg’ の画像が変更され、高さ 100 と 200 に緑色の線が描画されます。変更された画像は関数の戻り値のパスに保存されます。