인터페이스가 바뀌어도 LLM 도구 호출을 검증과 재시도로 복구한다

무엇인가

이 논문은 도구를 쓰는 LLM 에이전트가 배포 후 겪는 인터페이스 드리프트를 다룬다. 에이전트는 도구 설명, 인자 스키마, 추론 시점에 보이는 후보 도구 목록 같은 텍스트 인터페이스에 의존하는데, 도구의 의미가 그대로여도 설명 예시가 낡거나 파라미터 이름이 바뀌거나 후보 목록에 방해 도구가 추가되면 함수 호출이 실패할 수 있다. 저자들은 이를 설명 드리프트, 스키마 드리프트, 후보 집합 드리프트로 나누고, 기반 모델을 재학습하지 않고 추론 시점의 가벼운 복구 계층이 원래 성능을 되찾을 수 있는지 묻는다.

어떻게 동작하나

제안 방법 SchemaShield-Lite는 세 부분으로 구성된다. 먼저 각 도구를 이름, 설명, 필수 필드, 필드 타입만 담은 간결한 정규 도구 카드로 렌더링한다. 기반 모델이 도구 호출을 내면 검증기가 도구 이름, 필수 필드, 인자 구조를 확인하고 단순 실패 신호가 아니라 구조화된 오류 보고서를 만든다. 호출이 유효하지 않으면 과제 맥락, 정규 도구 카드, 잘못된 호출, 검증 오류를 담은 복구 프롬프트로 한 번의 제한된 복구를 수행한다. 비오라클 프로토콜에서는 모델이 보이는 도구 이름을 냈으면 그 도구에 대해 검증하고 같은 도구로 제한 복구를 하고, 도구 이름을 빼먹으면 보이는 도구들만 대상으로 후보 집합 재시도를 해 구체적인 호출을 만든 뒤 선택된 도구로 제한 복구를 한다. 제공자 지원이 있으면 강제 도구 복구를 쓰고 없으면 비제한 도구 호출이나 JSON 복구로 대체한다. 복구 프롬프트는 빈 호출이어도 대화에서 필수 필드를 추론하라고 지시하며, 복구 단계 토큰 예산을 512로 늘려 긴 DICE 대화의 잘린 복구 출력을 고쳤다.

무엇과 다른가

실험은 Qwen3.5-9B를 주 모델로 DICE-300과 BFCL-200에서 진행됐다. DICE-300은 단일 함수 1라운드 대화에서 뽑은 300개, BFCL-200은 simple Python, multiple-function, live-simple, live-multiple에서 균등하게 뽑은 200개다. DICE는 온건한 드리프트로 설명 2종, 스키마 2종, 방해 도구 1개를, BFCL은 더 공격적인 중간 강도로 설명 3종, 스키마 3종, 방해 도구 3개를 적용했다. 주 평가는 비오라클 복구 프로토콜이며, 오라클 제약 결과는 상한 참고용으로만 쓴다.

어떻게 쓰나

Qwen3.5-9B에서 SchemaShield-Lite는 DICE-300 정확도를 0.717에서 0.813으로 올리고 원래 맞던 예시에서 생긴 드리프트 실패 22개 중 19개를 복구했으며 관찰된 복구 피해는 없었다. BFCL-200은 0.580에서 0.805로 올라가고 45개 중 33개를 복구했다. DICE의 오라클 상한 0.827과의 격차는 작고, BFCL에서는 비오라클 최종 실행 0.805가 이전 오라클식 실행 0.795를 약간 웃돈다. 후보 집합 재시도는 비오라클 설정의 핵심으로, 이를 빼면 DICE 0.780, BFCL 0.725에 그쳤고 미해결 복구 대상이 DICE 35개에서 15개, BFCL 34개에서 9개로 줄었다. 복구는 DICE 300개 중 48개 16.0%, BFCL 200개 중 64개 32.0%에서 발동됐고, 토큰 오버헤드는 각각 32.6%, 47.1%였다. BFCL 재실행에서 원본 호출 8.8초, 드리프트 호출 9.3초, 복구 호출 13.0초, 복구 발동률 27.0%로 예상 추가 지연은 약 3.5초였다.

전제와 한계

단순 재시도가 이득을 설명하지는 못한다. 같은 드리프트 프롬프트를 다시 실행하는 순진한 재시도는 DICE 0.727, BFCL 0.610이었고, 호출이 유효하지 않다고 알려주고 도구 이름만 나열하는 도구 목록 재프롬프트도 DICE 0.753, BFCL 0.625에 머물렀다. 구조화된 검증 오류 피드백과 도구 제약 복구가 성능을 끌어올리는 핵심이라는 뜻이다. 드리프트 유형 절제에서는 설명만 바꾼 경우 정확도가 0.013, 스키마만 바꾼 경우 0.007 떨어졌지만 방해 도구를 넣은 후보 집합 드리프트는 0.047 떨어져 전체 결합 드리프트의 0.050에 가까웠다. 이 슬라이스에서는 후보 도구 목록 확장과 설명 중첩이 가장 큰 피해 원인이다.

구성 요소 절제는 검증 오류 피드백과 도구 제약 복구가 복구 단계의 핵심임을 보여준다. 오라클 제약 BFCL에서 정규 도구 카드만 초기 프롬프트에 넣으면 드리프트 점수가 0.640에서 0.810으로 오르는 예방 효과가 있었지만 검증기를 발동하지 않아 드리프트 실패 복구는 0건이었다. 복구 시점에 카드 없이 검증과 재시도만 쓰는 변형은 BFCL 0.820, 복구 26/34로 전체 파이프라인 0.795, 23/35보다 높았다. 카드는 초기 예측의 드리프트 예방에는 유용하지만, 대상 도구가 이미 정해진 복구 단계에서는 검증 오류와 제한 복구가 더 중요하다. 오류 분석에서 원래 맞던 예시의 드리프트 실패는 DICE 22개 중 20개, BFCL 45개 전부가 검증기에 보였고, 검증기에 안 보이는 유효하지만 틀린 출력은 DICE 2개, BFCL 0개였다.

다른 모델에서도 효과가 일부 재현됐다. Qwen3.5-35B-A3B는 BFCL-200 비오라클에서 0.635에서 0.845로 올라가고 38개 중 33개를 복구했으며 관찰된 피해와 미해결 복구 대상이 각각 없음과 1개였다. Llama-4-Scout는 0.635에서 0.665로 소폭 개선되고 피해는 없었지만 도구 이름 누락이 많아 미해결 복구 대상이 43개, 원래 맞던 드리프트 실패 복구는 11개 중 1개에 그쳤다. GPT-4o-mini는 BFCL에서 드리프트 피해 자체가 0.865에서 0.840으로 작았고 복구 후 0.860이었으며 피해와 미해결 대상은 없었지만 200개 슬라이스에서 유의하지 않았다. 가장 깨끗한 비오라클 증거는 여전히 Qwen3.5 계열에 집중돼 있다.

개발자 관점에서 이 논문은 배포된 에이전트에 무거운 도구별 정규화 파이프라인 없이도 보이는 도구 검증기, 도구 이름 누락 시 후보 집합 재시도, 도구가 정해진 뒤의 제한 복구를 조합하는 실용적 완화책을 제시한다. 다만 기반 모델이 쓸 만한 도구 이름을 자주 내지 못하면 복구 품질이 급락하므로 도구 이름 생성 안정성을 먼저 확인해야 한다. 또한 후보 도구 목록 확장과 설명 중첩 방해 도구를 설명 문구 수정보다 더 주의 깊게 모니터링할 필요가 있으며, 악성 방해 도구가 후보에 추가되는 공격을 복구 계층이 가릴 수 있으므로 새로 추가된 도구에는 출처 확인을 함께 붙여야 한다.

저자들이 밝힌 한계도 분명하다. 비오라클 성공 증거가 Qwen3.5 계열에 치우쳐 있고 다른 모델 결과는 대부분 오라클 제약 상한이거나 도구 이름 누락에 막힌다. 드리프트 연산은 실제 API 변경 로그에서 뽑은 분포가 아니라 저자 설계한 낡은 설명, 필드 이름 변경, 방해 도구에 한정되며 타입 축소, 열거값 교체, 다중 도구 리팩터링은 시험하지 않았다. 드리프트 유형과 구성 요소 절제는 오라클 제약 상한이라 비오라클 도구 해석 실패 시 메커니즘 결론이 그대로 전이되지 않을 수 있다. 호스팅 추론의 제공자별 도구 호출 동작이 섞일 수 있고, 복구가 원래부터 틀린 예시도 고쳐서 드리프트 복구 기여를 깨끗하게 분리하기 어렵다. 엄격한 문자열 일치 채점은 실제 복구를 과소집계하며, 벤치마크·제공자·모델 전반의 지연 시간 측정도 아직 넓지 않다.