DrafterBench: Benchmarking Large Language Models for Tasks Automation in Civil Engineering

著者 Yinsheng Li, Zhen Dong, Yi Shao

所属 McGill University, UC Santa Barbara and NVIDIA

投稿日 2025年7月16日

カテゴリ cs.AI, cs.CL

arXiv 2507.11527v1 ↗

DrafterBench: Benchmarking Large Language Models for Tasks Automation in Civil Engineering

基本情報

arXiv ID: 2507.11527v1 (https://arxiv.org/abs/2507.11527)
著者: Yinsheng Li, Zhen Dong, Yi Shao
所属: McGill University, UC Santa Barbara and NVIDIA
投稿日: 2025年7月16日
カテゴリ: cs.AI, cs.CL

簡単に説明すると

この論文は、土木工学における技術図面の改訂作業を自動化するためのLLMエージェントを評価する包括的なベンチマーク「DrafterBench」を提案しています。実際の工学業務で必要となる単調で低技術だが労働集約的なタスクを自動化する際のLLMの能力を、12種類のタスク、46個のカスタマイズ済み関数、1920個のタスクで体系的に評価します。産業応用の観点から、暗黙的な方針の理解、詳細な指示への追従、エラー処理など、実用的な課題に焦点を当てています。ベンチマークはGithub-DrafterBenchで公開されており、テストセットはHuggingfaceでホストされています。

1. 研究概要

1.1 背景と動機

LLMエージェントは実世界の問題解決において大きな可能性を示しており、産業界でのタスク自動化ソリューションとして期待されています。特に土木工学分野では、建設段階から設計段階まで、単調で低技術的かつ労働集約的な作業が数多く存在します。しかし、既存のベンチマークは一般的なタスクに焦点を当てており、実際の産業タスク、特に土木工学のタスクに適用する際の課題を十分に考慮していません。図面改訂作業は、北米の10社以上の建設会社へのインタビューから、最も労働集約的で自動化が必要な作業の1つとして特定されました。

産業タスクには特有の課題があります。第一に、単純な関数呼び出しではなく、利用可能なツール、事前知識、暗黙的な方針を統合した完全なソリューションが必要です。第二に、異なる個人からの様々な言語スタイルや表現で指示が与えられても、正確な図面を期待される高い堅牢性が重要です。第三に、単純な操作の省略、パラメータ値の誤り、予期しないパラメータの指定など、ワークフローのすべての詳細の正確性を確保することが不可欠です。第四に、「見えるものが実行されたものではない」ため、改訂された図面から直接LLMの性能品質を評価することが困難です。

1.2 主要な貢献

産業シナリオ、特に土木工学における単調で低技術的なタスクを自動化するLLMエージェントの強みと限界を包括的に分析するDrafterBenchを導入
モデルの応答スタイルや方法の確率的変動に耐性があり、安定かつ正確な評価を提供する完全自動評価ツールキットをリリース
主流のLLMに対して実験を実施し、DrafterBenchがそれらの強みと欠陥の明確なビューを提供できることを実証

2. 提案手法

2.1 手法の概要

DrafterBenchは、図面改訂を自動化するエージェントとしてLLMモデルを評価するように設計されています。評価は前処理プロセスをスキップし、エージェントが抽出された指示と準備されたファイルを受け取り、アクションを開始する状況をシミュレートします。アクションは、コーディングによってツール/関数を呼び出すことです（他の関数呼び出し方法よりも柔軟で安定しています）。

100以上の実世界の図面改訂ファイル（設計会社や建設会社から提供）を収集し、包括的に分析しました。ターゲットタスクは、3つの要素（テキスト、テーブル、ベクトルエンティティ）と4つの操作（追加、内容修正、マッピング、フォーマット更新）に分類され、合計12種類のタスクになります。

2.2 技術的詳細

各タスクの難易度は、4つの次元における6つのパラメータによって制御されます。

構造化データの理解の難しさ：指示の言語スタイルや表現は大きく異なり、構造化言語（明確で簡潔）または非構造化言語（冗長で時に過剰な情報を含む）として分類されます。
関数実行の難しさ：各タスクタイプには異なる関数呼び出しパイプラインがありますが、その複雑さは大きく異なります。比較的簡単なタスクではストレートフォワードなステップのみを含み、ベクトル追加のようなタスクではより豊富なノードとエッジを持つグラフ構造になります。
指示追従の難しさ：関与するオブジェクトと改訂の数により、指示の長さと複雑さが変動します。
批判的推論の難しさ：人間の手作業の確率的性質により、指示の品質は一定の標準で維持されません。詳細な値が明確に指定されていない「曖昧な値の定義」と、必要な情報が指定されていない「不完全（エラー）指示」の2種類のエラーが頻繁に発生します。

評価には二重関数が導入されています。これらは対応する元の関数と同じ関数名、呼び出し方法、引数、出力タイプを持ちますが、図面を修正する代わりに引数の詳細と実行パスを記録します。これにより、コーディングスタイルによるノイズを排除し、操作品質を正確に推定できます。

2.3 新規性

DrafterBenchの新規性は主に3点あります。第一に、土木工学という特定の産業分野における実際のタスク自動化に焦点を当てた初めてのベンチマークです。第二に、暗黙的な方針や事前知識の適用、動的な指示品質への適応など、産業応用に特有の課題を評価します。第三に、最終結果だけでなく、詳細な操作パスを記録・評価することで、エラーの原因を明確に特定できる評価方法を採用しています。

3. 実験結果

3.1 実験設定

実験では、OpenAI o1、GPT-4o、Claude 3.5 Sonnet、Deepseek-v3、Qwen2.5-72B、Llama3-70Bなど、最先端の商用およびオープンソースのLLMをAPIを通じてテストしました。評価は、コードの実行可能性、ターゲット完全性の2つのレベルで行われます。ターゲット完全性は、引数定義、変数転送、関数呼び出し、（単一）ツール選択、マルチツール選択、計画実行の6つのサブタスクで評価されます。

3.2 主要な結果

OpenAI o1がほぼすべてのタスクセットで明確な優位性を持ってパフォーマンスをリードしました。平均タスクスコアは81.92、包括的スコアは79.90でした。第2層にはClaude3.5-sonnet（76.27/73.79）とDeepseek-v3-685B（76.05/73.09）があり、2位を争っています。

注目すべき点として、広く認識されている強力なOpenAI o1でさえ、単純で単調な低技術的な産業タスクで約20ポイントを失っており、産業応用を中心とした評価の必要性を強調しています。

堅牢性の分析では以下が明らかになりました。

構造化データ理解：異なる言語スタイルに対して、Claude3.5-sonnet（5%）を除き、ほぼすべてのモデルが平均1%の劣化で大きな安定性を示しました。
関数実行：各モデルの最良のタスクタイプに対する各タスクタイプのパフォーマンス劣化は約9%でした。
指示追従：複数オブジェクトを扱う際の劣化は4%未満、複数操作を扱う際はOpenAI o1とClaude3.5-sonnetが1%未満の優れた安定性を示しました。
批判的推論：詳細が曖昧に指定されている場合、Qwen2.5-72B-Instructは5%、他は12%の劣化を示しました。指示にエラーがある場合、OpenAI o1以外のすべてのモデルで18%のパフォーマンス劣化が見られました。

3.3 既存手法との比較

エラー分析により、計画実行の精度と他の5つのサブタスクの間に明確なギャップがあることが判明しました。この差はすべてのモデルで一貫して約20%でした。これは、モデルが各サブタスクを高い精度で完了しようとしているが、すべての詳細に十分な注意を払うことが困難であることを示しています。

限界と今後の方向性として、不完全な指示に遭遇した際のインタラクティブスタイル、詳細の理解、新しい方針の実装などの課題が特定されました。

4. 実用性評価

4.1 実装の容易性

DrafterBenchはAPIを介してLLMを呼び出すため、特別なハードウェア要件はありません。実験では、i9-13900F CPUで約30分ですべての結果を取得できました。ベンチマークはGitHubで公開されており、テストセットはHuggingfaceでホストされています。

ツールキットは46個のカスタマイズされた図面改訂関数を提供し、PyMuPDF、Reportlab、cv2、pyOCRなどの既知のライブラリを活用しています。デフォルトプロンプトは、タスク背景、標準パイプライン、利用可能な関数、例の4つのコンポーネントで構成されています。

4.2 計算効率

計算効率の面では、DrafterBenchは単一ターンでタスクを完了するように設計されており、マルチターン・マルチラウンドのインタラクティブスタイルよりも効率的です。産業タスクの自動化では、観察可能な環境の構築が容易でない場合があり、生産性を最大化するために人間の関与を最小限に抑えることが望ましいため、この設計は実用的です。

評価は操作パスの記録と比較に基づいているため、実際の図面生成よりも高速です。二重関数により、一般的なコーディングエラーに対する互換性を保ちながら、正確な評価が可能です。

4.3 応用可能性

DrafterBenchは土木工学の図面改訂タスクに焦点を当てていますが、その評価フレームワークと方法論は他の産業分野にも適用可能です。特に、暗黙的な方針の理解、詳細な指示への追従、エラー処理などの評価は、製造業、建築、その他のエンジニアリング分野でのLLM応用評価にも有用です。

ベンチマークの限界として、現在は英語のタスクのみを対象としており、多言語入力は今後の課題です。また、土木工学の図面改訂タスクのみをカバーしており、より多くのタスクタイプが今後追加される予定です。

5. まとめと所感

5.1 論文の意義

この論文の産業的意義は、実際の工学タスクに基づいた初めての包括的なLLMベンチマークを提供した点です。単純な関数呼び出しタスクではなく、実際の産業現場で必要とされる暗黙的な知識や方針の理解、エラー処理、詳細への注意など、実用的な課題に焦点を当てています。

学術的意義として、LLMの産業応用における課題を体系的に分析し、構造化データ理解、関数実行、指示追従、批判的推論の4つの本質的な能力に分解して評価する枠組みを提供しました。特に、最終結果だけでなく操作パスを評価することで、エラーの原因を詳細に分析できる点は重要です。

実験結果から、最先端のLLMでさえ単純な産業タスクで完璧なパフォーマンスを達成できないことが明らかになり、産業応用を中心とした評価とモデル改善の必要性を強調しています。

5.2 今後の展望

今後の発展方向として、まず多言語対応が期待されます。非英語環境での産業タスク自動化におけるLLMの能力を考慮することは重要です。次に、より多様なタスクタイプの追加が必要です。土木工学以外の分野、例えば機械工学、電気工学、化学工学などの産業タスクも含めることで、より包括的な産業応用ベンチマークになります。

技術的には、インタラクティブスタイルとの統合が課題です。現在のLLMは即座の人間とのインタラクションに偏っており、前処理と後処理ファイルを通じた遅延的・間接的なインタラクションなど、他のインタラクションモードとの互換性を維持することも重要です。

また、新しい方針の実装に関するLLMの柔軟性を向上させることも必要です。サイバーセキュリティや違法リスクに関しては内在的な方針を持ち続けることが必要ですが、それほど深刻でない定型的でない側面では、産業応用シナリオの多様な要求と方針を考慮して、新しい方針に対するLLMの許容性と実装を改善する必要があります。