RAGを使ったドメイン特化型言語生成の進展
新しい方法がドメイン特化型言語を使った自動化タスクのコード生成を改善する。
Nastaran Bassamzadeh, Chhaya Methani
― 1 分で読む
近年、タスクを計画する際にコードを使うのが、複雑なアクティビティを整理するための信頼できる方法になってきた。コードは自然言語で作成されたステップよりも、タスク管理を簡単にするんだ。これにより、論理を単純化するために関数を使って複雑なシーケンスを整理するのが助けられる。コードは、エラーチェックを通じて、間違った関数名などのエラーを見つけるのにも役立つ。ただ、コード生成の手法は主にCやPythonといった一般的なプログラミング言語に焦点を当ててるのが現状。大規模言語モデル(LLM)は、特定のドメインで使われるカスタム関数名に苦戦していて、出力にエラーや不整合が増えてしまってる。この問題は、計画に関連するカスタム名で作業する際は特に深刻だ。さらに、新しい関数名でこれらのモデルを更新するのも難しい。特に多くのアプリケーションプログラミングインターフェース(API)を含むタスクの計画には、特別な言語を使うので問題になりがちだ。
この記事では、タスク計画の例としてロボティックプロセスオートメーション(RPA)に焦点を当てる。ドメイン特化型言語(DSL)を生成するために、LLMとリトリーバル拡張生成(RAG)の使用改善について紹介する。また、これらの方法をファインチューニングされたモデルと比較する。結果から、ファインチューニングモデルがコードの類似性に関して最も優れたパフォーマンスを発揮したことがわかった。でも、私たちの改善により、RAGメソッドはテストでよく知られたAPI名に類似した品質の結果を出すことができた。さらに、馴染みのないAPI名に対してもかなりのメリットが見られ、ファインチューニングモデルより7ポイント優れた結果を出した。
ドメイン特化型言語の重要性
ドメイン特化型言語(DSL)は、特定のアプリケーション用に調整されたプログラミング言語だ。例えば、SQLやAPI呼び出しに使われる特定の言語がある。この記事では、さまざまなウェブベースのAPIを使って自動化ワークフローを作成するのを助けるDSLのタスクに重点を置く。これらのワークフローは、請求書の処理や異なるソースからの営業リードの統合など、さまざまな顧客タスクを処理できる。自動化DSLは、API名を関数として表現し、API呼び出しのシーケンスを認識しつつ条件付き論理も含む。構文はJavaScriptのような馴染みのある言語から取られているが、ユニークな論理とカスタム関数名がそれを差別化する。
既存のコード生成手法は、頻繁なエラーや不整合のためにこのシナリオに適応するのが難しい。カスタムAPI名、さまざまな公開APIやプライベートAPI、そしてAPIの急速な変化がこの障害に寄与している。典型的なワークフローでは、利用可能な数千のAPIから選択する必要があるため、ビジネスプロセスを自動化するタスクはかなり複雑だ。
提案されたシステムアーキテクチャ
この記事では、自然言語入力からDSLを生成しつつ、OpenAIモデルを使ってRAG技術の選択的改善によって応答率を向上させる包括的なシステムアーキテクチャを示す。異なるコンテキストを使ったベンチマーク結果を比較し、ファインチューニングされたCodexモデルとの比較を行う。
まず、NL2DSLの問題を定式化し、既存の文献をレビューする。次に、RAGを最適化した方法とベンチマークのファインチューニングモデルを説明する。その後、データ生成の方法を説明し、評価指標を定義し、最後に我々の発見と結論を示す。
コード生成に関する先行研究
コード生成は挑戦的な研究分野だ。多くのオープンソースモデルは一般的なプログラミング言語に焦点を当て、データセットを改善する事前トレーニングモデルで進展を見せている。しかし、特定のドメインに適応させるには、通常、ベースモデルのファインチューニングに依存する。他の手法は、LLMをプロンプトとともに使い、モデルにより良い出力を生成させるために例を選ぶことに焦点を当てている。
API呼び出しで作業する際は、理由付けとタスク管理スキルを組み合わせる必要がある。LLMは論理的な理解が良いけれど、現在の知識や数学的タスクについては不足することがある。これらの制限を克服するために、多くのモデルが外部ツールへのアクセスを提供していて、これが人気を集めている。ただ、大半の研究は特定のツールの使用に重点を置く傾向があり、多くのビジネスシナリオに必要なツールの包括的なリストを形成することにはあまり関心が向けられていない。
コード生成とタスクオーケストレーションの分野は注目を集めている。しかし、多くのアプローチは、良く文書化されたAPIの小さなセットに制限してしまったり、単一の出力APIを予測することにのみ焦点を当てたりしている。API呼び出しのシーケンスを選択するタスクをコード生成の課題として提示するのは関連性があり、DSL生成の質を向上させることが論理や計画タスクの両方にとっての利点をもたらす。
グラウンディングコンテキストとデータ生成
DSL生成を改善するために、グラウンディングコンテキストを使用し、関連データを組み込むシステムを設計した。データ生成プロセスは、ユーザーのクエリとそれに対応するDSL表現を含む大規模なデータセットを作成することから成る。合計で67,000のサンプルをトレーニングセットに、1,000をテストに利用し、すべての機密情報を削除した。ワークフローはさまざまなAPIをカバーし、対応する自然言語プロンプトは合成的に生成された。
生成されたコードの質を評価するために、平均類似性、未解析率、ハルシネーション率の3つの重要な指標を設定した。平均類似性は、予測されたフローが最長共通部分列法に基づいて実際のフローとどれだけ一致しているかを測定する。未解析率は、正しく解析できなかったフローの数を反映する。一方、ハルシネーション率は、作り上げられたAPIや出力コード内の不正なパラメータキーの事例を捕らえる。
結果と分析
1,000のNL-DSLペアを使ってアプローチをテストした結果、よく知られたサンプルと馴染みのないサンプルを含んでいた。結果は、メタプロンプトにより多くの例を含めることの影響を強調し、すべての指標においてパフォーマンスの明確な改善を示した。
異なる数の例を追加する効果を比較したところ、より多くの例が事前トレーニングとファインチューニングされたモデルのパフォーマンスを大幅に向上させる可能性があることがわかった。APIメタデータを統合する際、関連する関数の説明を追加することでパフォーマンスが改善されることにも気づいた。
私たちの分析は、見未知のAPIに対するRAGベースのアプローチの一般的な改善を示した。これは、グラウンディングコンテキストがモデルが馴染みのないAPI名に遭遇したときのコード生成の質を向上させるのに役立つことを示している。それでも、ファインチューニングモデルは、構文エラーや予期しないパラメータキーのケースではまだ優れたパフォーマンスを発揮していた。
結論
提出された成果は、DSL生成を向上させるために動的に選ばれた例の重要な役割を強調している。関連する例の追加は、モデルに正しい構文を教え、生成されるコードの全体的な質を向上させるのに効果的だ。ハルシネーションされたAPI名やパラメータキーを減らす観点でのメリットが見られたが、ファインチューニングモデルのパフォーマンスと比較するといくつかのギャップが残っている。
最終的に、RAGによるDSL生成でかなりの進展を遂げたことがあり、API名やパラメータキーのハルシネーション率が低下したことがわかった。結果は、RAGモデルが特に馴染みのないAPIに対してファインチューニングモデルと競争できることを示唆している。この進展は、頻繁なモデルのファインチューニングの必要を減らし、計算リソースの節約につながる。
倫理的考慮事項
モデルが有害なクエリに応じないように、安全対策を講じ、有害なプロンプトのための分類器を利用した。また、ファインチューニングモデルは出力を生成しないべき例から学ぶことで、コード生成においてより責任を持ったアプローチを確保した。
例の付録
- 平均類似性の計算を示すサンプル。
- 異なるフローの類似性がどのように決定されるかのイラスト。
- 関数の説明に含まれる具体的な内容を示すAPIメタデータの一部。
タイトル: Plan with Code: Comparing approaches for robust NL to DSL generation
概要: Planning in code is considered a more reliable approach for many orchestration tasks. This is because code is more tractable than steps generated via Natural Language and make it easy to support more complex sequences by abstracting deterministic logic into functions. It also allows spotting issues with incorrect function names with the help of parsing checks that can be run on code. Progress in Code Generation methodologies, however, remains limited to general-purpose languages like C, C++, and Python. LLMs continue to face challenges with custom function names in Domain Specific Languages or DSLs, leading to higher hallucination rates and syntax errors. This is more common for custom function names, that are typically part of the plan. Moreover, keeping LLMs up-to-date with newer function names is an issue. This poses a challenge for scenarios like task planning over a large number of APIs, since the plan is represented as a DSL having custom API names. In this paper, we focus on workflow automation in RPA (Robotic Process Automation) domain as a special case of task planning. We present optimizations for using Retrieval Augmented Generation (or RAG) with LLMs for DSL generation along with an ablation study comparing these strategies with a fine-tuned model. Our results showed that the fine-tuned model scored the best on code similarity metric. However, with our optimizations, RAG approach is able to match the quality for in-domain API names in the test set. Additionally, it offers significant advantage for out-of-domain or unseen API names, outperforming Fine-Tuned model on similarity metric by 7 pts.
著者: Nastaran Bassamzadeh, Chhaya Methani
最終更新: 2024-08-15 00:00:00
言語: English
ソースURL: https://arxiv.org/abs/2408.08335
ソースPDF: https://arxiv.org/pdf/2408.08335
ライセンス: https://creativecommons.org/licenses/by/4.0/
変更点: この要約はAIの助けを借りて作成されており、不正確な場合があります。正確な情報については、ここにリンクされている元のソース文書を参照してください。
オープンアクセスの相互運用性を利用させていただいた arxiv に感謝します。