アーカイブ / LLM / AI Agent
利用者の好みをAPI呼び出しに反映するTAPS：必要な場合だけ指示文をタグ付け
TAPS
TAPSの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 1: Example of the NLSI task. Given a user query and user-specific list of preferences, and API documentation, the model has to parse the input into structured output. The model has to (i) select, which preferences are relevant for the current query and (ii) interpret the utterance into one or several API calls. The diagram is a replica of Figure 1 from Moghe et al. (2024) .
概要
- TAPSは依頼文と利用者の好みからAPI呼び出し案を作り、不確実性に応じて好みの文章のタグ付けと再生成を行う。
- 著者らのNLSI解釈課題では、Llama-3-Instの完全一致率はタグなしの41.76％からTAPSの51.18％になった。
- 評価では関連する好みの指示が正しく与えられている。実運用での好みの選択とAPI実行前の確認は別途検証が必要である。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、TAPSの仕組み
- 01依頼・好み・API仕様
- 02初回の呼び出し案
- 03不確実性で判定
- 04必要時にタグ付け・再生成
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
TAPSは、利用者の今回の依頼と、事前に登録された好みを合わせてAPI呼び出しを作る。APIは外部サービスの機能を呼び出す窓口で、出張便の検索なら日時に加え、好みの航空会社や乗り継ぎ条件が関係する。
著者らの分析では、言語モデルによる呼び出し案に、必要な引数の欠落、仕様と異なる名前への置き換え、存在しない引数の追加が見られた。条件を取り違えると、意図した検索につながらない。
手法
TAPSは、依頼文、関連する好みの指示、APIの仕様から、呼び出す関数と引数を生成する。まず言語モデルに案を作らせ、出力時の確率から確信の低さを見積もる。検証データで決めたしきい値に従い、初回案を採用するか、好みをタグ付けして生成し直すかを選ぶ。
タグ付けでは、好みの文章の外側に対応するAPIを示すタグ、内側に引数名と値を示すタグを付ける。例えば好みの航空会社を記した文に、API仕様上の航空会社の引数との対応を明示する考え方だ。元の文章も残すため、モデルは文脈と引数の手掛かりを併せて読み、最終的にAPI呼び出し案を出す。
新規性
TAPSは、利用者の好みを記した文章にAPIと引数の階層的なタグを付け、初回出力の不確実性に応じて、そのタグ付けを使うか決める。タグを付けた文章は、API呼び出しを作り直す際の補助情報になる。
文章を別の形式に置き換えず、元の表現と構造情報を併せてモデルに渡す点が特徴だ。著者らは、モデルの追加学習を必要としない手法として提案している。
従来手法との違い
著者らは、タグを使わないDefault、全件にタグを使うNaive Tag-S、必要と判定した場合に使うTAPSを比較した。Naive Tag-SとTAPSのタグ付けには、後続のAPI呼び出し生成と同じモデルを使う設定がある。
NLSIテストデータのLlama-3-Instでは、完全一致率が順に41.76％、47.55％、51.18％だった。この比較は、関連する好みの指示を正しく与えた「解釈」課題に限られ、指示を利用者情報から選び出す性能は示さない。
実験結果
著者らはNLSIのテストデータで、関連する好みの指示を正しく与え、API呼び出しを生成する解釈課題を評価した。完全一致率（EM）は呼び出し全体の一致を、スロット別F1は関数名・引数名・値の組について、適合率と再現率をまとめて測る。
Llama-3-Instでは、DefaultのEM 41.76％・F1 78.26％に対し、TAPSはEM 51.18％・F1 83.94％だった。Mistral-3-Instでは同じ順にEM 35.74％・F1 69.11％、EM 42.40％・F1 76.76％と著者らは報告する。いずれも好みの選択を評価に含めない設定である。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：社内の出張便検索窓口に、社員の今回の依頼、本人が登録・確認した航空会社や時間帯の好み、検索APIの仕様を入力する。出力する関数名と引数を担当者が確認し、承認後に検索する運用を想定する。
必要な元データは依頼文、好みの文章、API仕様で、センサー入力は使わない。モデルの追加学習を前提としない場合も、現場のAPI名と好みの表現にタグを対応させ、正解ラベル付きの依頼例で抜けや余分な条件を検証する必要がある。
応用先の候補からNauhに相談できます。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：出張便検索の依頼文、本人が確認した好みの文章、検索APIの仕様を少数集める。期待する関数名・引数名・値を人手で正解ラベルにし、現場のAPI仕様に沿ってタグの対応を定める。センサー入力やモデルの追加学習は想定しない。
同じ依頼を、タグなし、毎回タグ付け、TAPS型の選択方式で処理する。検証例でしきい値を決め、別の例で完全一致率、引数の欠落・余分な追加、タグ付け回数を比べる。API実行前には担当者が引数を確認する。
限界と課題
著者らは、不確実性でタグ付けを選ぶTAPSが、結果を見て有利な方を選ぶOracleに及ばないと報告する。また、タグでは複数の指示のつながりを表しにくく、共有された場所の情報がある例でMistral-3-Instの引数欠落が増えたと述べる。
編集上の検証事項は、古い好みや今回の依頼と衝突する好みをどう扱うか、タグの誤りが引数にどう伝わるかである。実際のAPIに渡す前の引数検査と、本人が好みを更新できる手順も確認したい。
出典
元のタイトル・要旨を確認する（英語）
TAPS: Tool-Augmented Personalisation via Structured Tagging
Recent advancements in tool-augmented large language models have enabled them to interact with external tools, enhancing their ability to perform complex user tasks. However, existing approaches overlook the role of personalisation in guiding tool use. This work investigates how user preferences can be effectively integrated into goal-oriented dialogue agents. Through extensive analysis, we identify key weaknesses in the ability of LLMs to personalise tool use. To this end, we introduce TAPS, a novel solution that enhances personalised tool use by leveraging a structured tagging tool and an uncertainty-based tool detector. TAPS significantly improves the ability of LLMs to incorporate user preferences, achieving the new state-of-the-art for open source models on the NLSI task.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01