Robust Function Calling for LLM Agents Under Interface Drift
- 게시일: 2026-10-19
- arXiv: 2610.23342v1 · PDF
- 저자: Aniruddha Chattopadhyay, Kanishka Halder, Partha Sarathi Roy
- 분야: cs.AI, cs.CL, cs.SE
- 선정 점수: 4.83
- 선정 이유: 최근성 0.4, 인용 영향 0.0 (인용 0회), 저자 영향 0.0 (최고 h-index 0), AI 주제 적합성 3.0, 개발자 관심 1.1, 학술 신호 0.3, 오픈 웨이트·주요 연구조직 신호 0.0
← 2026-10-19 목록으로 돌아가기
한 문장 요약
배포 후 도구 인터페이스의 표면적 변경(설명·스키마·후보 리스트)으로 인한 함수 호출 실패(인터페이스 드리프트)를, 재학습 없이 추론 시점에서 스키마 검증·후보 재시도·한번의 제약된 수리로 복구하는 경량 레이어(SchemaShield-Lite)를 제안하고 평가했다.
해결하려는 문제
도구 사용을 텍스트 인터페이스(도구 설명, 인자 스키마, 모델에 보이는 후보 도구 리스트)를 통해 수행하는 LLM 에이전트는 배포 후 인터페이스의 표면적 변경(이름 변경, 설명 수정, 후보 도구 추가 등)으로 인해 도구 의미가 유지되더라도 함수 호출이 실패하는 실무적 신뢰성 문제에 취약하다. 본문은 이 ‘인터페이스 드리프트’가 모델의 도구 선택·인자 생성에 미치는 민감도를 정량화하고, 기본 모델을 재학습하지 않고 추론 단계에서의 경량 검증·수리 레이어로 손실을 회복할 수 있는지를 묻는다.
핵심 기여
- 인터페이스 드리프트(설명 편집·스키마 표면형 변경·후보집 확장)를 현실적 배포 시나리오로 규정하고 DICE-BENCH와 BFCL에서 정량적으로 평가했다.
- 경량의 비학습적 추론-시점 수리 파이프라인 SchemaShield-Lite을 제안(정규화된 도구 카드, 구조적 스키마 검증, 후보-집 재시도, 한 번의 제약된 수리 호출 결합).
- 배포지향의 비-오라클(비상식적) 프로토콜에서 주요 모델(Qwen3.5-9B) 기준 DICE-300 정확도를 0.717→0.813, BFCL-200을 0.580→0.805로 회복했고 드리프트로 인한 원래-정답 실패 중 각각 19/22 및 33/45를 복구했다고 보고했다.
- 단순 재시도(naive retry)로는 회복을 설명할 수 없음을 보이고, 구성요소·드리프트유형 소거실험을 통해 후보집(딱히 유사한 방해 도구)의 증가가 실제 피해의 주원인임을 규명했다.
- 코드·드리프트 생성 스크립트·실험 아티팩트(예: 프롬프트, 검증 로그, 복구 대상)를 공개하여 재현 가능성을 제공함).
접근 방법
- SchemaShield-Lite는 추론-시점의 세 부분으로 구성된다.
- (1) ‘정규화된 도구 카드’: 각 도구를 도구명·설명·필수 필드·필드 타입 정보를 포함한 표준 카드로 렌더링하여 인터페이스 표현을 정규화하고 초기 예측 단계의 드리프트 예방을 돕는다.
- (2) ‘검증(Validation)’: 기본 모델이 응답한 도구 호출을 받아 도구명 존재 여부, 필수 필드 충족 여부, 인자 구조 유효성 등을 검사하고 이진 신호가 아닌 구조화된 오류 리포트를 출력한다.
- (3) ‘한-샷 수리(One-shot constrained repair)’: 검증이 실패하면 수리 프롬프트(대화 문맥, 정규화 카드, 유효하지 않은 호출, 검증 오류)를 모델에 제공해 제약된 수리 호출을 한 번 수행한다.
- 비-오라클(운영 현실적) 프로토콜에서는 모델이 도구명을 누락한 경우 먼저 보이는 후보들에 대해 후보집 재시도(candidate-set retry)를 실행해 실제 보이는 도구를 확정한 뒤, 확정된 도구에 대해 강제-도구 제약(forced-tool) 또는 제약된 JSON 수리를 시도한다.
- 수리 프롬프트는 (i) 누락 시 대화에서 모든 필수 필드를 추론하라는 지시를 명시하고, (ii) 초깃값보다 큰 토큰 예산(예: 512)으로 수리 호출을 실행한다.
- 실험은 Original→Drifted→Repaired의 per-example 루프로 평가하며, 드리프트는 설명·스키마·후보집 세 연산자(δd,δs,δc)의 조합으로 합성해서 주입한다.
주요 결과
- 주요 비-오라클(Qwen3.5-9B, 후보 재시도 포함) 결과: DICE-300: Original 0.757 → Drifted 0.717 → Repaired 0.813(회복: 19/22 drift-induced failures on originally-correct slice; repair harms 0). BFCL-200: Original 0.790 → Drifted 0.580 → Repaired 0.805(회복: 33/45 on originally-correct slice; repair harms 0). (Table 1)
- 나이브 재시도·tool-list 리프롬프트 대비 우위: DICE-300에서 Drifted 0.713, Naive Retry 0.727, Tool-List Re-prompt 0.753, SchemaShield-Lite 0.813; BFCL-200에서 Drifted 0.590, Naive Retry 0.610, Tool-List Re-prompt 0.625, SchemaShield-Lite 0.795으로 구조적 검증·수리의 기여를 확인함(Table 2).
- 드리프트 유형 소거실험(DICE-300, Qwen3.5-9B): 설명 드리프트만 −0.013, 스키마 드리프트만 −0.007의 작은 영향, 후보집(딱지 도구) 추가가 −0.047로 손실의 대부분을 차지해 후보집 확장이 주된 손상 요인임을 보임(Table 4).
- 구성요소 소거(오라클 상한): 정규 카드 단독은 초기 예측에서 드리프트 예방을 제공하지만 수리 경로를 트리거하지 않아 복구를 못함; 검증+재시도(카드 제외)가 복구의 핵심이며, 정규 카드는 초기 예측 예방에는 유용하나 수리 컨텍스트에서는 필수 아님(Table 5).
- 운영 비용·지연: DICE 비-오라클 최종 런에서 수리 트리거 48/300(16.0%), 수리 토큰 103,221 vs 드리프트 토큰 316,185 → 32.6% 토큰 오버헤드. BFCL 수리 트리거 64/200(32.0%), 수리 토큰 154,249 vs 드리프트 327,289 → 47.1% 오버헤드. 지연 계측(예: BFCL 재실행): 원콜 평균 8.8s, 드리프트 9.3s, 수리시 13.0s; 27.0% 수리 트리거 가정 시 예측당 기대 추가 지연 약 3.5s(Section 6.1).
한계
- (저자가 명시한 한계) 모델·프로토콜 범위 제한: 가장 깨끗한 비-오라클 성공 증거는 Qwen3.5 계열에 집중되어 있으며 다모델 비-오라클 복제는 제한적이다. 드리프트 연산자는 저자 설계의 합성적·합성적 유사성에 기반한 합성 변형(설명 예시, 필드명 변경, 후보 도구 추가)으로 실제 벤더 변경 분포에서 표집된 것은 아니며 일부 드리프트 유형(타입 축소, enum 교체, 대규모 리팩터 등)은 미검증이다. 구성요소·드리프트 유형 소거 실험의 많은 부분이 오라클-제약 상한으로 수행되어 비-오라클 환경으로 직접 이식될 때 메커니즘이 변할 수 있다. 또 호스팅된 추론을 사용했으므로 제공자별 동작이 실험에 포함될 수 있다. 또한 엄격한 문자열 일치 평가는 포맷·패러프레이즈 차이로 진짜 회복을 과소평가하며(검사 결과에서 13개 미회복 사례 중 11개가 포맷/패러프레이즈 아티팩트), 전체 지연·운영 비용에 대한 더 넓은 실험은 부족하다(Section 8).
- (본 실험에서 합리적으로 확인되는 제약) 비-오라클 수리 성능은 기본 모델이 ‘사용 가능한 도구명’을 먼저 내놓을 수 있는지에 크게 의존한다(예: Llama-4-Scout에서는 도구명을 자주 누락해 미해결 수리 대상이 많아 회복이 제한됨). 보고된 회복률은 엄격 매칭 정책으로 계산된 하한이므로 실무적 평가는 더 관대할 경우 개선되어 보일 수 있다(Section 6.6).
개발자 관점
- 간단한 배포 조치로 실효적 회복 가능: 정규화된 도구 카드 렌더링 + 구조적 스키마 검증(도구명·필수필드·인자 구조) + 후보집 재시도(모델이 도구명을 누락한 경우 보이는 후보들에 대해 재시도) + 도구-제약 수리 호출을 구현하면 대부분의 드리프트 손실을 복구할 수 있다.
- 프롬프트·수리 정책 세부: 수리 프롬프트에 (i) 유효하지 않은 호출과 검증 오류를 포함하고 (ii) ‘대화에서 모든 필수 필드를 추론하라’는 명시적 지시를 포함하며 (iii) 수리 단계에 더 큰 토큰 예산(예: 512)을 할당하면 잘린 출력을 방지하고 필드 보완을 개선한다.
- 강제-도구 제약(forced-tool) 지원이 가능하면 수리 품질이 높아짐: 프로바이더가 허용하면 수리 호출을 특정 도구로 강제할 것(없으면 제약 없는 JSON 수리로 폴백).
- 모니터링과 안전: 운영에서는 도구 카탈로그 확장(신규 후보 도구 추가)을 특별히 모니터링할 것. 수리 레이어는 악성 후보 주입(adversarial tool injection)을 마스킹할 수 있으므로 신규 도구의 출처·증거(provenance) 검증을 병행해야 함(Discussion·Limitations).
- 비용·지연 고려: 수리은 유효하지 않은 경우에만 트리거되므로 전체 오버헤드는 수리 트리거율에 의존함(예: 본 논문 실험 DICE 트리거 16.0%, BFCL 32.0%로 토큰 오버헤드 각각 약 32.6%·47.1%). 수리로 인한 평균 추가 지연(예: ~3.5s)은 서비스 품질에 영향이므로 SLO와 비용 예측에 반영해야 한다(Section 6.1).
근거 범위: 분석은 제공된 논문 PDF 본문 전체 텍스트에 기반한 요약·정리임. 본문 내 표와 문장(예: 표 1–5의 수치, 회복·트리거 카운트, 토큰·지연 수치)을 그대로 인용했으며, 저자가 별도로 공개한 실험 아티팩트(리포지토리) 참조를 권장함. 일부 수치(예: 표의 Drifted 값과 별도 베이스라인 표의 값)는 서로 다른 별도 런에서 나왔기 때문에 본문도 해당 차이를 명시하고 있으며, 재현성은 저자 공개 코드를 통해 확인 가능함.