Component Evaluation - 답변에 필요한 도구를 순서대로 활용했는가? (Trajectory)
개요
•
이번 강의는 에이전트가 답변에 도달하는 과정에서 도구를 올바른 순서로 사용했는지를 평가하는 Trajectory Evaluation을 다룹니다.
•
여기서 trajectory(트라젝토리) 는 원래 궤적/경로라는 뜻으로, 에이전트가 사용자 질문 → 도구 호출 → 최종 답변에 이르는 과정을 의미합니다.
•
핵심은 답변 결과만 보는 것이 아니라, 답변을 만드는 과정이 의도대로 동작했는지를 확인하는 것입니다.
Trajectory Evaluation의 목적
무엇을 평가하나?
•
에이전트가 정해진 도구를 올바른 순서로 사용했는지
•
불필요한 도구를 먼저 쓰거나, 필요한 도구를 누락하지는 않았는지
•
예:
◦
논문 검색 → 이메일 전송이 기대되는데
◦
실제로는 검색 없이 바로 이메일 전송하거나
◦
엉뚱한 도구만 실행하는 경우를 탐지
다른 평가 방식과의 차이
•
정확성 평가: LLM-as-a-judge 등으로 최종 답변이 맞는지 확인
•
도구 선택 평가: 특정 타겟 툴 하나를 썼는지 확인
•
Trajectory Evaluation: 도구들의 전체 시퀀스(sequence) 가 기대한 흐름과 같은지 확인
평가 방식
데이터셋 구성
•
평가용 데이터셋에는 보통 다음이 포함됩니다.
◦
질문(question)
◦
정답 답변(answer)
◦
타겟 툴 시퀀스(target tool sequence)
▪
기대하는 도구 호출 순서
▪
예: web_search -> arxiv_search -> gmail_send
평가 절차
1.
래퍼(wrapper) 로 에이전트를 실행
2.
실제 발생한 도구 호출 순서를 수집
3.
이를 골든 데이터셋의 타겟 툴 시퀀스와 비교
4.
일치 여부에 따라 점수를 부여
Trajectory 평가 함수의 핵심 로직
기본 아이디어
•
평가는 주로 실제 도구 호출 순서(raw sequence) 와 정답 시퀀스를 비교합니다.
•
단, 실제 에이전트는 retry(재시도) 때문에 같은 도구를 여러 번 호출할 수 있습니다.
중복 제거가 필요한 이유
•
예를 들어 에러로 인해 table_search를 여러 번 호출한 뒤 gmail_send를 했다면:
◦
실제 시퀀스: table_search, table_search, table_search, gmail_send
◦
기대 시퀀스: table_search, gmail_send
•
단순 비교하면 실패로 처리되므로, 중복 제거 후 비교합니다.
길이 비교
•
중복 제거 후에도 시퀀스 길이가 다르면 즉시 0점 처리합니다.
•
길이가 같을 때만 각 위치를 하나씩 비교합니다.
비교 방식
•
리스트 두 개를 동시에 순회하며 각 도구 이름이 같은지 확인합니다.
•
파이썬에서는 zip() 같은 방식을 활용합니다.
실습에서 관찰한 결과
첫 실행 결과
•
여러 번 실행했을 때 대부분은 잘 맞았지만, 일부 케이스는 실패했습니다.
•
실패 원인:
◦
기대한 것은 arxiv 검색 후 이메일 전송
◦
실제로는 중간에 web search가 끼어들어감
•
이 경우 답변은 맞더라도 도구 시퀀스 관점에서는 0점이 됩니다.
실패 케이스의 해석
•
에이전트가 최종적으로는 올바른 답변을 했더라도,
•
불필요한 도구를 추가로 사용하면 trajectory 평가에서는 실패로 간주될 수 있습니다.
•
즉, 결과의 정확성과 과정의 효율성/정합성은 별개입니다.
개선 방법
1. 프롬프트 수정
•
시스템 프롬프트에 다음과 같은 제약을 추가:
◦
arxiv 검색과 web search를 같이 하지 말 것
◦
특정 상황에서는 한 도구만 사용하도록 지시
•
수정 후에는:
◦
불필요한 web search가 사라지고
◦
기대한 시퀀스에 더 잘 맞게 동작
2. 비용과 시간 최적화
•
trajectory를 개선하면 단순히 평가 점수만 좋아지는 것이 아니라:
◦
토큰 비용 절감
◦
응답 시간 단축
•
강의에서는 예시로:
◦
비용이 0.22 → 0.19로 감소
◦
처리 시간도 약 10% 수준으로 줄어듦
•
작은 차이처럼 보여도, 대규모 누적 시 상당한 절감 효과가 있습니다.
LangGraph / LangSmith 지원 방식
지원하는 평가 유형
•
강의에서는 LangGraph 기반의 trajectory evaluation 지원을 소개했습니다.
•
대표적인 비교 방식은 4가지입니다.
1. Strict
•
실제 시퀀스와 기대 시퀀스가 완전히 동일해야 함
•
중복 제거를 하지 않는 방식에 가깝지만,
•
retry를 인정하지 않아서 실무에선 다소 엄격함
2. Unordered
•
도구를 사용하기만 하면 순서는 상관없음
•
실제 에이전트의 작업 흐름 평가에는 부적절할 수 있음
3. Subset
•
기대 도구 일부만 사용해도 통과시키는 방식
•
예측된 행동이 불완전해도 봐주는 셈이라,
•
평가 의미가 약함
4. Superset
•
기대 도구보다 더 많이 사용해도,
•
기대 도구를 포함하면 통과시키는 방식
•
불필요한 도구 사용을 제대로 잡아내기 어렵습니다.
실무적 주의사항
LangGraph 방식의 한계
•
각 콜마다 마킹(marking) 을 맞춰줘야 해서 번거롭습니다.
•
특히:
◦
AI 메시지 ID
◦
tool call ID
◦
이 둘이 맞아야 동작하는 경우가 있어, 설정이 까다롭습니다.
•
강의에서는 이 때문에 에러가 자주 나서 실사용이 어렵다고 언급했습니다.
실무 권장
•
가능하면 LangGraph에서 제공하는 기능을 활용하되,
•
에러나 제약이 많다면 직접 평가 로직을 작성하는 것도 좋은 선택입니다.
•
팀 상황에 맞게 도입 여부를 결정하는 것이 중요합니다.
핵심 정리
•
Trajectory Evaluation은 에이전트가 답변까지 가는 도구 사용 경로를 평가한다.
•
최종 답변이 맞아도 도구 순서가 틀리면 실패할 수 있다.
•
중복 호출(retry) 을 고려해 중복 제거 후 시퀀스 비교가 필요하다.
•
평가 결과가 좋지 않다면:
◦
프롬프트를 수정하거나
◦
도구 사용 정책을 명확히 해서 개선할 수 있다.
•
이 평가는 정확성뿐 아니라 비용 절감과 시간 최적화에도 도움된다.
