PARA/03_Resources/R001_개발_레퍼런스(참고문서)/AI 강의/TelAgentBench – Telco 도메인 사례로 보는 에이전트 성능 평가 (SKT).md

TelAgentBench – Telco 도메인 사례로 보는 에이전트 성능 평가 (SKT)

개요

  • 통신 도메인에 특화된 LLM 에이전트 성능 평가 벤치마크인 Tel Agent Bench 소개
  • 통신 외 도메인에도 적용 가능한 평가 설계 사례로 제시
  • EMNLP 2025 Industry Track 채택 (이전 연도 Tel Bench 후속, 심화 연구)
  • 목적: 단순 언어능력 평가를 넘어, 실제 서비스형 에이전트의 종합 작동 능력 검증

핵심 인사이트

  • 2025년 통신 분야 LLM 활용은 AICC를 넘어 MNO RAG, Telco Agent, BSS API 연동 등 광범위 영역으로 확장
  • 이에 맞춰 평가의 초점도 에이전틱 LLM의 종합 능력(추론, 계획, 도구 사용, RAG, 지시 준수)으로 이동
  • 자동 평가 시스템 도입으로 일관성, 재현성, 효율성 강화
  • 한국어 통신 시나리오 기반의 고품질 데이터셋이 변별력을 좌우

배경과 팀

  • 팀: AI 데이터 엔지니어링 팀 (개발자, 데이터 사이언티스트, 언어학자, 어노테이터로 구성)
  • 역할: 모델 정밀 평가 → 데이터 청사진 설계 → 파운데이션/튜닝용 데이터 구축
  • 산출물: 자동화 평가 시스템, 도메인 맞춤 데이터 구축 기술

기존 대비 진화

  • 2024 Tel Bench: 통신 특화 QnA, MRC, 감성 등 기초 LLM 테스크 중심
  • 2025 Tel Agent Bench: 고객 요청 이해 → 계획 수립 → 도구 호출 → 검색 증강 → 인스트럭션 준수까지 전 과정 평가

평가 범주 요약

범주 의미 예시/요구사항
Reasoning (추론) 다단계 추론, 수치연산 상품 스펙 종합 비교, 약정/할인/요금 누적 계산
Planning (계획) 제약조건 충족 플랜 수립 여행지·숙소·예산·통신제약 동시 만족 플랜
Action (도구 사용) BSS API 정확 호출 청구, 부가서비스, 데이터 조회/가입, 병렬/다단계
RAG 충실성 중심 답변 출처 문서 기반 응답, 환각 차단, 근거 명시
Instruction Following 출력 규칙 준수 존댓말, 단어수 제한, 포맷 준수 일관성

왜 자동화 평가인가

  • 도메인 전문가(상담사) 리소스 제약, 개인적 직관에 따른 편차 발생
  • 자동 평가 시스템 도입으로 신속·일관·효율 평가
  • 정답 매칭을 넘어 추론 과정, 도구 사용 정확성, RAG 충실성, 지시 준수까지 규칙화 채점

한국어 데이터의 필요성과 접근

  • 영문 중심 학술 벤치마크로는 한국어 통신 맥락 반영 한계
  • 기계번역 의존 대신 자연스러운 한국어와 사회문화적 맥락 반영
  • 도메인 문서의 레거시, 규칙 불일치, 문서 구조 난해성 해결 위해 정제·DB화 작업 선행

데이터 프라이버시 대응

  • 고객 정보 포함 가능성으로 실제 로그 직사용 불가
  • 현실성 높은 고품질 생성 데이터로 평가셋 구성해 개인정보 위험 차단
  • 정책/약관, 대량 문의 패턴을 분석해 현실 가능한 시나리오로 커버

Tel Agent Bench 구축 절차

  1. 기획 및 데이터 설계
    • 상용 사례 분석 → 핵심 역량 도출 → 관련 학술 벤치마크 기준 수립
    • 예: 현업에서 필요한 MNO RAG → 충실성/신뢰성 검증 가능한 벤치마크 요소 선별, 한국어 현지화
  2. 도메인 특화 환경 구현
    • 핵심 업무 API 선정, 도구 실행 환경 구성
    • 약관/상품설명 등 내부 문서 정제·DB화, 검색 가능한 RAG 환경 구축
  3. 초기 데이터 생성 및 확장
    • 고품질 시드 데이터 수작업 생성 → 자동 증강
    • 자동/수동 교차 검수로 모호성 제거, 중복 제거
  4. 도메인 전문가 검증 및 고도화
    • 웹 기반 검수 도구 자체 개발
    • 상담사/언어학자/도메인 전문가 검수로 품질 강화

세부 평가 설계 예시

  • 추론
    • 다단계 비교: 최상급 모델 식별을 위해 무게/스펙/출고가 등 다중 속성 연쇄 추론
    • 수치 연산: 약정/할인/프로모션 순차 적용해 최종 청구 금액 산출
  • 계획
    • 일반 여행 제약(예산, 일정, 숙소 규칙) + 통신 제약(로밍, 요금제) 통합
    • 난이도 증가에 따라 제약 수·상호의존성 확대
  • 도구 사용
    • 6개 카테고리, 23개 API 경로, 10개 하위 테스크
    • 단순 조회 → 병렬 호출 → 다단계 실행까지 정확성 평가
  • RAG
    • 충실성 중심 평가: 응답 각 문장이 출처 문서에 근거하는지 정교히 검증
    • 허위 정보 검출 시 페이스풀 실패로 판정
  • 인스트럭션 준수
    • 존댓말, 길이 제한, 포맷 등 시스템/사용자 지시 일관 준수 여부
    • 다수 모델이 길이 제한 등을 자주 위반하는 경향 관찰

평가 결과 요약

  • 상용(프로프라이어터리) vs 오픈소스
    • RAG를 제외하면 상용 모델이 전반 우위
    • 특히 Reasoning, Action에서 격차 큼
    • 유사 요금제 명칭 구분 실패, 요구 숫자 미포착 등에서 성능 차 발생
  • Thinking vs Non-thinking
    • 전반적으론 Thinking 우위
    • 추론·도구 사용 같이 명시적 다단계 추론이 필요한 경우 Thinking이 더 안정적·정확
    • 오픈소스만 놓고 보면, Planning·RAG·Instruction에서는 Non-thinking이 근소 우위 사례도 관찰
    • 시사점: 서비스 핵심 요구사항(정확 포맷, 지시 준수, 정보 추출)에 따라 모델 아키텍처를 상황별로 신중히 선택

활용 계획과 공개 범위

  • 사내 활용: 현실성 있는 내부 평가 도구로 채택, 파운데이션 모델의 에이전트 능력 평가에 사용
  • 대외 공유: 비즈니스 로직 제외 범용 한국어 데이터 공개 계획 (법무 검토 중)
  • 파트너 협력: SelectStar 등과 함께 우선 적용
  • 지속 연구: 멀티모달 확장, 제조 등 도메인 확장, 변별력 높은 고난도 문항 개발

결론

  • 통신 도메인의 에이전트 평가에는 다단계 추론, 제약 기반 계획, API 도구 사용, RAG 충실성, 지시 준수가 모두 필수
  • 자동 평가 체계와 한국어 도메인 데이터 품질이 실제 서비스 성숙도와 직결
  • 모델 선택은 단일 지표가 아닌, 서비스 핵심 요구와 운영 제약을 기준으로 한 다기준 의사결정이 필요

적용 체크리스트 (내 프로젝트 관점)

  • 현행 서비스 시나리오에서 반드시 충족해야 할 제약 조건 목록화 (요금정책, 약정, 프로모션, 예외 규정)
  • 필수 API 라우트 인벤토리 작성 (파라미터 스키마, 병렬/다단계 호출 패턴 포함)
  • 내부 문서 정제·DB화 파이프라인 수립 (버전/유효기간/정책 변경 추적)
  • 평가 자동화 규칙 정의 (Reasoning, Action, RAG 충실성, IF 규칙 위반 채점 기준)
  • Thinking/Non-thinking, 상용/오픈소스의 조합별 A/B 평가 계획 수립
  • 개인정보 포함 리스크 점검 및 생성 데이터 대체 전략 확정
  • 고난도 문항 세트 설계로 모델 간 변별력 확보

빠른 시작 템플릿

  • 시나리오 소스
    • 고객 요청 유형: 청구, 부가서비스, 로밍, 데이터 추가, 약정 변경
    • 제약 변수: 예산, 일정, 기존 요금제, 디바이스 조건, 약관 예외
  • 평가 규칙 초안
    • Reasoning: 중간 근거 단계 누락 시 감점, 수치 계산 오차 허용 범위 지정
    • Planning: 모든 제약 충족 여부, 우선순위 충돌 시 해결 전략 점수화
    • Action: API 경로 정확성, 파라미터 정합성, 병렬/다단계 최적화
    • RAG: 문장별 근거 매핑 비율, 허위 정보 0건 기준
    • Instruction: 어체, 길이, 포맷 정확 준수율

개인 메모

  • 통신 도메인 특성상 약관/상품·정책의 빈번한 변경이 평가 난이도와 실전성 모두를 좌우
  • 레거시 문서 정제와 버전 관리 자동화가 장기적으로 가장 큰 투자 대비 효과를 낼 가능성 높음
  • 모델 선택은 단순 벤치마크 스코어가 아니라 운영 목적(정확 포맷, 응답일관성, 도구 안정성)에 맞춘 다축 기준 필요

댓글

첫 번째 댓글을 남겨보세요.