Component Evaluation - 답변에 필요한 도구를 활용했는가?
개요
이번 강의에서는 멀티툴 에이전트(Multi-tool Agent) 가 질문에 맞는 도구를 올바르게 선택했는지를 평가하는 방법을 다룹니다.
이 평가는 앞선 문서 검색 기반 Component Evaluation과 유사하며, 이번에는 “필요한 문서를 가져왔는가?” 대신 “필요한 도구를 사용했는가?”를 확인합니다.
평가 대상: 멀티툴 에이전트의 도구 선택 능력
핵심 아이디어
•
에이전트에 여러 도구를 제공하고,
•
그중 정답에 필요한 도구를 실제로 사용했는지 평가합니다.
•
즉, 도구 사용 여부를 하나의 컴포넌트 평가(Component Evaluation) 지표로 보는 방식입니다.
강의에서 사용한 도구들
에이전트에는 총 4가지 도구가 포함됩니다.
•
Gmail Toolkit: 이메일 관련 작업
•
Tavily Search: 웹 검색
•
Python REPL: 코드 실행
•
ArXiv: 논문 검색
구현 환경과 도구 구성
사용된 모델과 프레임워크
•
모델: OpenAI 대신 Opus 4.6
•
도구 구성: LangChain에서 제공하는 도구들 사용
•
기존과 달리, 사내 문서를 직접 만든 것이 아니라 기성 도구들을 조합해 에이전트를 구성함
Gmail Toolkit 설정
Gmail 관련 기능을 사용하려면 Google Cloud에서 인증 정보를 준비해야 합니다.
1.
GCP Console 접속
2.
API 서비스 > Credentials 이동
3.
Create Credential
4.
OAuth Client ID 생성
5.
Desktop App 선택
6.
JSON 키 다운로드
7.
파일명을 아래처럼 저장:
credentials.json
Bash
복사
Gmail Toolkit에 포함된 도구
Gmail Toolkit 안에는 다음과 같은 기능들이 포함됩니다.
•
Draft 작성
•
이메일 보내기
•
검색
•
메시지 상세 조회
•
스레드 전체 조회
Tavily Search 설정
개요
•
웹 검색을 위한 도구로 Tavily를 사용합니다.
•
API 키가 필요합니다.
환경 변수 설정
.env 파일에 다음과 같이 추가합니다.
TAVILY_API_KEY=...
Bash
복사
선택 이유
•
무료 할당량이 있어 테스트에 충분함
•
설정이 비교적 간단함
•
LangChain과의 호환성이 좋음
Python REPL 도구 처리
특징
•
Python REPL은 Tavily처럼 직접 바로 호출되는 형태가 아니라,
•
외부 클래스 형태로 선언한 뒤 툴로 감싸서 사용합니다.
방식
•
REPL 클래스를 인스턴스화
•
이를 tool decorator로 감싸서 에이전트 도구로 등록
ArXiv 도구 설정
역할
•
논문 검색 및 논문 정보 조회
구현 포인트
•
load_tools 함수를 사용해 미리 불러올 수 있음
•
여러 개의 도구가 반환되므로 리스트 형태로 추가
•
Gmail Toolkit도 여러 도구를 포함하므로, 도구 리스트에 계속 추가하는 방식으로 구성
에이전트 생성
에이전트 구성 방식
•
create_agent 함수를 사용
•
입력으로 다음을 전달:
◦
LLM
◦
도구 리스트
◦
시스템 프롬프트
시스템 프롬프트
•
각 도구의 용도를 자세히 설명
•
에이전트가 어떤 상황에 어떤 도구를 써야 하는지 안내
평가 준비: Wrapper 작성
왜 Wrapper가 필요한가?
evaluate를 바로 실행하면 전체 실행 흐름이 맞지 않을 수 있으므로,
에이전트를 호출하는 Wrapper 함수를 만들어 평가에 사용합니다.
평가 흐름
•
Golden Dataset의 질문을 입력
•
Wrapper가 에이전트를 실행
•
출력 결과를 평가
LangSmith를 이용한 Component Evaluation
평가 대상
이번 평가는 Target Tool을 기준으로 합니다.
•
Inputs: 질문 자체
•
Outputs: 에이전트 응답
•
Reference / Example Metadata: 정답 도구 정보
데이터셋 구조
CSV 데이터셋에는 다음이 포함됩니다.
•
질문
•
정답 답변
•
target tool 메타데이터
예시 도구 유형:
•
Calculate: 코드 실행
•
Web Search: 웹 검색
•
ArXiv: 논문 검색
•
Email: 이메일 도구
평가 로직: 사용한 도구가 정답 도구와 일치하는가?
핵심 판단 방식
에이전트 출력의 messages를 순회하면서:
•
메시지가 Tool Message인지 확인
•
Tool Message라면 tool name을 수집
•
수집한 도구 목록에 정답 도구(target tool) 가 포함되어 있으면 1
•
포함되지 않으면 0
개념 정리
•
Tool Message: 에이전트가 실제로 도구를 호출한 기록
•
tool name: 실제 사용된 도구 이름
•
target tool: 데이터셋에서 기대하는 정답 도구
평가 함수의 논리
•
도구를 전혀 안 썼다면 0
•
정답 도구를 사용했다면 1
실습 절차
1.
Wrapper 함수 작성
2.
LangSmith Client 선언
3.
Target Tool 평가 함수 작성
4.
데이터셋에서 target tool 메타데이터 확인
5.
에이전트 실행 결과(messages)에서 tool name 추출
6.
정답 도구 사용 여부를 0/1로 평가
7.
LangSmith Experiment 실행
8.
결과 확인
실행 설정
•
데이터가 적기 때문에 Concurrency = 1
•
반복 평가 없이 한 번씩 순차 실행
•
평가 시에는 큰 모델을 사용하는 것이 좋음
◦
정확도가 중요
◦
평가 품질이 중요
◦
비용은 높지만 더 신뢰할 수 있음
평가 결과와 해석
결과
•
4개 샘플 모두 1점을 획득
•
즉, 모든 예시에서 에이전트가 정답 도구를 사용한 것으로 평가됨
강의자의 관점
강의자는 “도구를 어떤 것을 썼는지까지 꼭 평가해야 하는가?” 에 대해 의문을 제기합니다.
이유 1: 사용자가 원하는 것은 최종 답변
•
예를 들어 논문 요약 요청이 들어오면,
◦
웹 검색으로 요약 자료를 찾든
◦
ArXiv로 논문을 찾든
•
사용자 입장에서는 좋은 답변만 나오면 충분할 수 있습니다.
이유 2: 도구 강제는 프롬프트 낭비일 수 있음
•
“논문이면 반드시 ArXiv를 써라” 같은 규칙을 강하게 넣으면
•
불필요한 프롬프트 토큰이 늘어날 수 있음
이유 3: 도구가 중요하다면 아예 제거하는 것이 낫다
•
특정 도구가 항상 우수하다면
•
에이전트에게 다른 도구를 주지 않으면 됨
•
그러면 “어떤 도구를 썼는지”를 평가할 필요가 줄어듦
멀티에이전트 시스템으로의 확장
단일 에이전트 vs 멀티에이전트
이번 예시는 하나의 에이전트에 여러 도구를 제공한 경우입니다.
하지만 실제로는 멀티에이전트 구조를 사용할 수도 있습니다.
멀티에이전트에서도 같은 방식으로 평가 가능
•
메인 에이전트가 어떤 서브 에이전트를 호출할지 결정
•
이 서브 에이전트 호출도 결국 도구(tool) 로 감싸서 구현 가능
•
따라서 “올바른 에이전트를 호출했는가?” 도 같은 방식으로 평가할 수 있음
핵심 연결
•
서브 에이전트 = 도구처럼 다룰 수 있음
•
따라서 이번의 Tool Selection Evaluation은
멀티에이전트 시스템의 라우팅 평가에도 그대로 확장 가능
정리
이번 강의의 핵심
•
Component Evaluation의 한 형태로서,
•
에이전트가 정답에 필요한 도구를 사용했는지 평가하는 방법을 소개함
•
LangSmith의 dataset + metadata + evaluator 구조를 활용해 구현함
핵심 메시지
•
Tool use evaluation은 가능하다
•
하지만 실제로 꼭 필요한지는 설계 목적에 따라 달라질 수 있다
•
멀티에이전트 환경에서도 동일한 방식으로 확장 가능하다
핵심 용어 정리
•
Component Evaluation: 에이전트의 특정 구성요소만 따로 평가하는 방식
•
Golden Dataset: 정답이 포함된 평가용 데이터셋
•
Target Tool: 해당 질문에서 기대되는 정답 도구
•
Tool Message: 도구 호출 기록을 담은 메시지
•
LangSmith: 에이전트/LLM 실험 및 평가를 위한 플랫폼
•
Wrapper: 평가 가능하도록 에이전트 호출을 감싼 함수
