表示
超・人工知能研究所 Super AI Research Lab トップへ超・人工知能研究所AI Research Lab / ぱそ太郎工事中

since
平成38年9月29日

← 検索結果に戻る

REST APIの旧仕様と現行仕様を分けて検索し、誤用コードを修正する

Database-Augmented RAG

保存した記事を見るこのブラウザに保存します。無料会員で端末間の同期・フォルダ整理
原論文の図

Database-Augmented RAGの原論文から掲載した図です。細部はクリックして拡大できます。

原論文の図の説明を読む

Figure 2: Overview of the Standard RAG Method

出典:Database-Augmented RAG / arXiv ↗

概要

  • 旧版・現行版の仕様をコード例と説明文にも分け、四つのデータベースから修正に必要な箇所を検索する。
  • SwitchBotとFitbitの21事例で、著者らが報告した修正率はBLの54.3%に対し、四分割構成のDsLsで88.6%だった。
  • 評価対象は2サービスに限られ、検索で渡す情報量の影響も切り分けられていないため、導入先の事例で検証が必要である。
補足:編集した模式図で仕組みを確認する

VISUAL EXPLAINER

図でつかむ、Database-Augmented RAGの仕組み

左から右へ読む
  1. 01旧・現行仕様と対象関数
  2. 02版と内容別に保存
  3. 03関連箇所を検索
  4. 04修正コードを生成

原論文の説明をもとにした模式図です。処理の細部は省略しています。

研究の背景

REST APIは、アプリがサービスへ送る要求の接続先やヘッダーなどを仕様で定める仕組みである。提供者が仕様を更新してもクライアントコードが旧版のままだと、要求が現行仕様と合わなくなる。

エラー応答や状態コードだけでは原因が分からず、開発者は要求と応答を繰り返し確かめることがある。旧仕様と現行仕様の該当箇所を修正対象の関数に結び付けられれば、変更すべき点を調べやすい。

手法

Database-Augmented RAGは、REST API仕様から関連箇所を探し、大規模言語モデルに渡して誤用コードを修正する。RAGは外部文書を検索して生成時の入力に加える方法である。DsLs構成では旧版・現行版のそれぞれでコード例と説明文を分け、計四つのデータベースに保存する。

対象関数を手掛かりに各データベースから関連箇所を検索する。モデルには旧仕様の分析、対象関数との照合による誤用特定、現行仕様に沿った修正を順に指示する。論文にあるSwitchBotの例では、接続先をv1.0からv1.1へ変え、要求ヘッダーにsign、t、nonceを追加する必要がある。

新規性

著者らが検証したのは、REST API仕様の版と内容の種類に応じて検索先を分ける設計である。旧仕様と現行仕様を混同せず、コード例と説明文も区別して修正に渡す。

データベース構成を変えた11種類のRAGを、同じ誤用事例で比較した。四分割構成の結果は良好だったが、著者らは検索で得られる情報量の影響を構成の効果から切り分けられないと述べている。

従来手法との違い

基準となるBLは、修正対象のコードと公式仕様へのリンクをGPT-4oに渡し、モデル内蔵のウェブ検索を使わせる。RAGでは仕様の関連箇所を検索し、コードとともに渡す。

旧版と現行版を一つのデータベースに混ぜるDLmの修正率は81.0%、版ごとに分けるDLは84.8%だった。同じ仕様を使う比較だが、検索結果の量なども変わり得るため、差を保存方法だけの効果とは断定できない。

実験結果

著者らはSwitchBotとFitbitを使う公開リポジトリから、要求ヘッダーと接続先の両方に誤用がある9事例、接続先だけに誤用がある12事例を集めた。各事例を5回実行し、対象関数内の誤用をすべて直せた修正案の割合を修正率とした。

著者らの結果ではBLの修正率が54.3%、四つのデータベースを使うDsLsが88.6%だった。成功判定では生成コードを元のリポジトリに適用してコンパイルを確認し、公式仕様とリポジトリの修正内容にも人手で照らした。数値はこの2サービス、21事例での結果である。

応用の可能性

編集上の応用案 · 論文が実証した用途とは区別しています。

編集上の応用案:IoT機器の管理サービスで、API更新後も旧仕様を使うクライアント関数の修正候補を開発者に提示する。入力は対象関数と旧版・現行版の公式仕様、出力は変更箇所を示すコード案とし、担当者が仕様と照合して採否を決める。

追加学習用の訓練データや教師ラベル、センサー入力は使わない想定とする。検証には過去の修正差分を正解例として用意し、導入先の仕様を版別に集め、コード例と説明文を分離して検索用データベースに登録する必要がある。

応用先の候補からNauhに相談できます。

導入時の検証

導入時の検証案 · 対象データでの再評価が必要です。

導入時の検証案:対象APIの旧版・現行版の公式仕様、誤用を含む関数、過去に人が直した差分を少数集める。追加学習用データと教師ラベル、センサー入力は使わず、過去の差分を評価用の正解例とする。仕様を版とコード例・説明文で分けて登録する。

同じ事例で、仕様リンクを渡すBL相当の方法と四分割RAGを比較する。関数内の全誤用を直せた割合に加え、必要な仕様箇所を検索できたか、存在しないAPIや不要な変更を出していないかを記録する。担当者が各案を公式仕様と照合する。

限界と課題

著者らは、評価対象がSwitchBotとFitbitの21事例に限られ、誤用も主に要求ヘッダーと接続先に集中すると述べる。また、データベースの分割と検索で渡される情報量の効果を切り分けられていない。

BLはウェブ検索に依存し、成功判定には第一著者の人手による判断が入ることも、著者らが挙げる妥当性上の制約である。編集上の検証事項は、導入先の認証方式や仕様書でも必要な根拠を検索でき、存在しないAPIや不要な変更を提案しないかである。

応用先の候補
研究内容と応用案に基づく分類です。業界での導入実績を示すものではありません。

出典

元のタイトル・要旨を確認する(英語)

Database-Augmented RAG for Automated Repair of REST API Misuses

Many Internet of Things (IoT) services provide Representational State Transfer (REST) APIs, which require client developers to implement applications that conform to the corresponding API specifications. When client programs contain API misuse, developers debug them based on error responses. However, such responses are often insufficient for identifying the root cause, requiring developers to repeatedly communicate with the server. Retrieval-Augmented Generation (RAG) is a promising approach for providing large language models (LLMs) with external knowledge. However, in automated repair of REST API misuses, it remains unclear how specifications should be stored in a RAG database. This study evaluates how different configurations for organizing API specifications affect RAG-based repair of REST API misuse. We constructed 11 RAG configurations with different database structures and compared their repair rates with a baseline method. For evaluation, we used REST API misuse cases collected from real-world repositories. The results show that, in the studied datasets, the baseline method achieved a repair rate of 54.3%, whereas a RAG-based method using four databases achieved a maximum repair rate of 88.6%. These results indicate that organizing specifications according to version and content type can be an effective design choice for RAG-based REST API misuse repair.

論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新:2026-10-01