AIモデルの性能評価や、新しいアルゴリズム（例えば以前取り上げたSVG: Support Vector Generationなど）の実験において、適切なデータセットの選定は極めて重要です。今回は、私がソフトウェアエンジニアリング領域の自然言語処理（NLP）タスクでベンチマークとして愛用している「PROMISE Dataset」について、その構造とAIモデルでの活用実験の経験を交えて紹介します。

PROMISE Datasetとは

私がよく利用しているのは、Software-Requirements-Classification リポジトリに含まれている PROMISE.CSV です。

元々は PROMISE Software Engineering Repository で公開されていたもので、ソフトウェア要件定義書のテキストデータと、それが「機能要件」か「非機能要件」か、さらに細かい分類ラベルが付与されたデータセットです。

データの構造とクラス定義

このデータセットは主に以下の構成になっています。

  • Project ID: プロジェクトの識別子
  • Requirement Text: 要件のテキスト（例: “The system shall refresh the display every 60 seconds."）
  • Class: 要件の分類クラス

クラス分類は以下の4つが主要なラベルとして使用されています。これらは要件エンジニアリングにおける古典的な分類に基づいています。

  1. F (Functional Requirement): 機能要件。システムが「何を」するか。
  2. PE (Performance): 性能要件。非機能要件の一種。
  3. LF (Look-and-Feel): 外観・操作感。UI/UXに関わる非機能要件。
  4. US (Usability): 使用性。使いやすさに関わる非機能要件。
graph TD Req[Software Requirement] Req --> F[Functional (F)] Req --> NF[Non-Functional] NF --> PE[Performance (PE)] NF --> LF[Look-and-Feel (LF)] NF --> US[Usability (US)] NF --> Other[Other NFRs...]

AIモデルによる実験：LLM vs SVG

私はこのデータセットを用いて、いくつかのAIモデルのアプローチを試みてきました。

1. LLMによる直接生成（失敗）

当初、GPT-3.5/4クラスのLLMに対し、プロンプトで「この要件テキストをF, PE, LF, USに分類せよ」と指示する生成タスク（Zero-shot/Few-shot）を行いました。 しかし、結果は期待した精度には届きませんでした。特に LF (Look-and-Feel) と US (Usability) の境界は人間でも曖昧な場合があり、LLMが文脈なしに正確に判定するのは困難でした。また、プロンプトのわずかな違いで出力が揺らぐという課題もありました。

2. SVG (Embedding + SVM) によるアプローチ（成功）

そこで採用したのが、SVG論文に学ぶ、埋め込み+SVMによる文書分類 でも触れたアプローチです。 LLMを「分類器」としてではなく、「特徴量抽出器（Embedding Generator）」として利用し、実際の分類境界の決定には SVM (Support Vector Machine) を用いる方法です。

import pandas as pd
from sklearn.svm import SVC
from sklearn.model_selection import train_test_split
# (疑似コード) Embedding取得関数
from my_llm_utils import get_embeddings 

# データの読み込み
df = pd.read_csv('PROMISE.csv')

# Embeddingの生成 (LLMの"脳"の一部を利用)
X = get_embeddings(df['RequirementText'].tolist())
y = df['Class']

# SVMによる分類
clf = SVC(kernel='linear')
clf.fit(X_train, y_train)

この手法は、LLMが持つ言語理解能力（意味空間へのマッピング）と、SVMが持つ高次元空間での境界決定能力（マージン最大化）を組み合わせることで、少数のデータでも非常に高い精度で要件を分類することに成功しました。

「曖昧性」という未踏のデータセット

PROMISEデータセットは有用ですが、個人的に今後検証したいと考えているのが「要件定義の曖昧性（Ambiguity）」に関するデータセットです。

要件定義において最大のリスクは「誤解を生む表現」です。しかし、既存のデータセットの多くは「正解ラベル（これは機能要件である、等）」が付与されたクリーンなデータです。「どの程度曖昧か」「複数の解釈が可能か」といったメタデータを持つデータセットは、Kaggle等を探してもなかなか見つかりません。

もし、AIが「この要件は曖昧です。AともBとも解釈できます」と指摘できるようになれば、上流工程におけるAI支援の価値は飛躍的に高まるはずです。今後は、既存のデータセットに独自の「曖昧性スコア」を付与するようなアプローチも必要になるかもしれません。

まとめ

システム要件のデータセットは、単なるテキスト分類の練習台以上の価値があります。それは、エンジニアリングの知識（ドメイン知識）と自然言語処理が交差する興味深い領域です。 もしAIモデルのベンチマークを探しているなら、手垢のついたニュース分類や映画レビューだけでなく、こうしたエンジニアリングデータセットに触れてみることを強くお勧めします。