[Paper] Contact Center AI에서 Tool-Aware Planning: Lineage-Guided Query Decomposition을 통한 LLM 평가

Source: arXiv - 2602.14955v1

Overview

이 논문은 콜센터 환경에서 대형 언어 모델(LLM)이 툴‑인식 실행 계획을 얼마나 잘 생성할 수 있는지를 평가하기 위한 도메인‑특화 벤치마크를 소개한다. 비즈니스‑인텔리전스 질문을 구조화된 도구(예: Snowflake의 Text‑to‑SQL)와 비구조화된 도구(예: 통화 전사에 대한 Retrieval‑Augmented Generation)를 호출하는 구체적인 단계들의 순서로 분해함으로써, 저자들은 LLM이 자율 에이전트로 작동할 때 현재의 강점과 약점을 드러낸다.

주요 기여

• Reference‑based evaluation framework
  • 두 가지 평가 모드: 일곱 차원을 포괄하는 metric‑wise 스코어러(툴‑프롬프트 정렬, 쿼리 준수, 단계 실행 가능성 등)와 one‑shot 인간‑유사 매치 평가자.
• Iterative data‑curation pipeline
  • evaluator → optimizer 루프를 통해 원시 LLM‑생성 플랜을 자동으로 고품질 plan lineages (순서가 있는 수정본)로 정제, 수동 주석 작업을 크게 감소.
• Large‑scale empirical study
  • 14 LLM(Claude, GPT‑4, Llama, Mistral 등) 모델 크기와 패밀리를 대상으로 plan lineage 프롬프트 사용 여부에 따라 벤치마크 수행.
  • 체계적인 실패 모드 발견: 복합 쿼리와 4단계보다 긴 플랜(실제 쿼리 대부분은 5‑15단계 필요).
  • 최고 전체 metric 점수: 84.8 % (Claude‑3‑7‑Sonnet).
  • 최고 one‑shot “A+” 매치 비율: 49.75 % (o3‑mini).

방법론

1. 작업 정의 – 목표 사용 사례는 컨택센터 분석가가 데이터 기반 질문을 하는 경우(예: “지난 분기에 청구 관련 전화를 건 고객의 이탈률은 얼마였나요?”)입니다. 답변은 다음을 조정하여 구성해야 합니다:
   • 구조화된 도구: Snowflake 데이터 웨어하우스에 대해 실행되는 Text‑to‑SQL 생성.
   • 비구조화된 도구: 통화 기록 임베딩에 대한 RAG.
2. 계획 표현 – 계획은 각 단계가 다음과 같이 주석된 단계 목록입니다:
   • 호출할 도구,
   • 해당 도구에 전달되는 프롬프트(또는 쿼리),
   • 병렬 실행을 가능하게 하는 선택적 depends_on 링크.
3. 참조 기반 평가 – 생성된 각 계획에 대해 프레임워크는 금본위 기준(gold‑standard reference)과 7가지 차원에서 비교합니다:
   • 도구‑프롬프트 정렬(프롬프트가 도구의 예상 입력과 일치하는가?)
   • 쿼리 준수(계획이 주제에 머무르는가?)
   • 단계 완전성, 순서 정확성, 병렬성 타당성, 실행 가능성, 그리고 전체 일관성.
4. 계획 계통 생성 – 원시 LLM 계획에서 시작해 평가자가 결함을 표시하고, 옵티마이저(두 번째 LLM 또는 규칙 기반 시스템)가 계획을 재작성합니다. 이 루프는 계획이 사전 정의된 품질 임계값에 도달할 때까지 반복되어 *계통(lineage)*을 형성합니다.
5. 실험 설정 – 14개의 LLM 각각을 두 가지 방식으로 프롬프트합니다:
   • 제로샷(계통(context) 없이).
   • 계통 인식(모델이 이전 개정본을 보고 개선하도록 요청).
     성능은 모델별·지표별로 집계되며, 일회성 평가자에 대해 “A+” 등급(매우 좋음/좋음)이 보고됩니다.

결과 및 발견

• 복합 쿼리는 어렵다 – 질문에 여러 데이터 소스를 결합하거나 구조화된 증거와 비구조화된 증거를 혼합해야 할 경우, LLM은 종종 단계를 놓치거나 도구를 잘못 사용합니다.
• 계획 길이가 중요하다 – 네 번째 단계 이후 정확도가 급격히 떨어지며, 대부분의 모델은 그 이후의 의존성을 추적하는 데 어려움을 겪습니다.
• 라인지(이전 버전 정보)가 선택적으로 도움이 된다 – 이전 수정본을 제공하면 최고 성능 모델(Claude, GPT‑4)의 실행 가능성이 약 5–7 % 향상되지만, 작은 모델에서는 그 효과가 미미합니다.
• 도구‑프롬프트 정렬이 가장 약한 영역이다 – 최고의 모델조차도 종종 하위 도구가 기대하는 스키마와 일치하지 않는 프롬프트를 생성하여 실행 중 오류를 일으킵니다.

실용적 시사점

1. Designing AI‑augmented contact‑center agents – Developers should limit plan depth (prefer 3–4 steps) or decompose long queries into multiple, smaller sub‑queries that can be solved independently.
   → AI‑보강 컨택센터 에이전트 설계 – 개발자는 플랜 깊이를 제한해야 합니다(3–4단계 선호) 또는 긴 질의를 여러 개의 작은 하위 질의로 분해하여 독립적으로 해결할 수 있도록 합니다.

2. Prompt engineering for tool use – Explicitly include tool schemas and example prompts in the system prompt; this mitigates mis‑alignment observed in the study.
   → 도구 사용을 위한 프롬프트 엔지니어링 – 시스템 프롬프트에 tool schemas와 example prompts를 명시적으로 포함시켜야 합니다; 이는 연구에서 관찰된 정렬 오류를 완화합니다.

3. Leveraging plan lineage – When building a production pipeline, incorporate an iterative refinement loop (evaluator → optimizer) to automatically polish LLM‑generated plans before execution, especially for high‑value queries.
   → 플랜 라인리지 활용 – 프로덕션 파이프라인을 구축할 때, iterative refinement loop (evaluator → optimizer)를 도입하여 실행 전에 LLM‑generated plans를 자동으로 다듬습니다, 특히 고가치 질의에 대해.

4. Model selection – For mission‑critical analytics, opting for larger, instruction‑tuned models (Claude‑3, GPT‑4) yields better overall plan quality, but the cost‑benefit trade‑off must be weighed against the modest one‑shot success rates.
   → 모델 선택 – 미션 크리티컬 분석의 경우, 더 크고 instruction‑tuned 모델(Claude‑3, GPT‑4)을 선택하면 전반적인 플랜 품질이 향상되지만, 비용‑편익 트레이드오프를 낮은 원샷 성공률과 비교해 평가해야 합니다.

5. Tool‑wrapper APIs – Expose a standardized “plan execution” API that validates each step’s prompt against the tool’s contract before dispatch, catching alignment errors early and providing feedback to the LLM for the next refinement pass.
   → Tool‑wrapper API – 각 단계의 프롬프트를 도구 계약과 비교 검증하는 표준화된 “plan execution” API를 제공하여 전송 전에 정렬 오류를 조기에 포착하고, 다음 정제 단계에 LLM에 피드백을 제공합니다.

Limitations & Future Work

• Domain confinement – The benchmark focuses on contact‑center data‑analysis; results may not transfer directly to other domains (e.g., code generation, medical QA).
• Evaluation reliance on reference plans – While the metric‑wise scorer is comprehensive, it still depends on human‑crafted gold references, which could embed bias.
• Scalability of lineage generation – The optimizer loop reduces manual effort but still incurs extra compute; future work could explore self‑critiquing LLMs that internalize the evaluator’s feedback.
• Tool diversity – Only Text‑to‑SQL and RAG were examined; extending to more heterogeneous tools (e.g., dashboards, external APIs) would test the generality of the framework.
• Real‑time constraints – The study does not measure latency; integrating plan validation and refinement into a low‑latency production system remains an open challenge.

Bottom line: The paper provides a concrete, reproducible methodology for measuring how well LLMs can act as autonomous planners in a tool‑rich environment. For developers building AI‑driven contact‑center assistants, the findings underscore the importance of short, well‑structured plans, explicit tool schemas, and iterative refinement to bridge the gap between LLM reasoning and reliable tool execution.

저자

• Varun Nathan
• Shreyas Guha
• Ayush Kumar

논문 정보

• arXiv ID: 2602.14955v1
• Categories: cs.CL, cs.SE
• Published: 2026년 2월 16일
• PDF: PDF 다운로드