AI 에이전트를 평가하기 위한 재사용 가능한 프레임워크 구축 방법

AI 에이전트 개발팀이 시스템이 제대로 작동하는지 파악하려면 최종 답변을 확인하는 것 이상의 작업이 필요하다. 검색, 생성, 도구 호출을 결합한 애플리케이션에서는 최종 텍스트에만 문제가 있는 것처럼 보여도 실제로는 잘못된 데이터베이스를 선택했거나 부적절한 문서를 검색한 결과일 수 있다. InfoQ를 통해 진행한 발표에서 Elastic의 수석 데이터 과학자인 Susan Chang은 회사가 사이버 보안과 기업용 챗봇에 사용하는 에이전트를 평가하기 위한 공통 프레임워크를 어떻게 개발했는지 설명했다.

분리된 평가에서 공통 도구로

Elastic의 팀들은 각 에이전트마다 별도의 데이터 세트, 평가자, 추적 프로세스를 구축하는 것에서 시작했다. 공격 탐지 에이전트의 경우 테스트에는 분석가와 보안 연구원이 작성한 공격 및 정상 시나리오가 포함되었으며, 정확도와 재현율, 사실성, 유사도, MITRE 전술 분류와 같은 지표가 사용되었다. 기업 데이터에 기반한 챗봇은 문서에서 질문과 검색을 테스트했으며, 답변의 관련성과 완전성, 제품 식별자의 정확성, ES|QL 쿼리 작성에 중점을 두었다.

이러한 사례의 차이로 인해 작업이 크게 중복되었다. 이에 Elastic은 다양한 유형의 데이터 세트를 통합 스키마로 가져오고, 실행 트레이스에 기반한 평가를 수행하며, RAG 애플리케이션을 위한 공통 평가자와 각 제품에 특화된 구성 요소를 함께 사용할 수 있는 공통 프레임워크를 구축했다. 이 프로세스는 로컬에서 실행할 수 있으며, 데이터를 불러오고, 에이전트를 실행하고, 결과를 수집한 뒤 개발자에게 점수를 표시할 수 있다.

실패 원인을 파악하기 위한 추적

이 경험은 에이전트 추적이 최종 출력에만 국한되어서는 안 된다는 점을 보여준다. 호출한 도구, 벡터 및 키워드 검색 작업, 검색된 데이터, 토큰 사용량, 응답 시간, 의사 결정의 순서를 기록해야 한다. 이러한 수준의 세부 정보가 있으면 특정 도구 호출을 평가하거나 최종 답변에 문제가 나타나기 전에 에이전트가 잘못된 출처를 사용했다는 사실을 발견할 수 있다.

또한 부정적인 평가와 같이 사용자가 보고한 실패 사례를 테스트 세트의 새로운 예시로 변환할 수 있다. 이렇게 하면 프로덕션 피드백이 수작업으로 작성된 별도의 메모로 남지 않고, 이후 버전의 회귀 테스트 일부가 된다.

LLM-as-a-judge만으로는 충분하지 않은 이유

Elastic은 스타일, 일관성, 문맥에 대한 답변의 적합성과 같이 개방적이거나 모호한 작업에서 다른 모델의 출력을 평가하기 위해 언어 모델을 사용했다. 이 접근 방식은 긴 텍스트를 판단하기 위한 정확한 규칙을 작성하기 어려울 때 평가를 확장할 수 있게 해준다. 그러나 실행마다 결과가 달라질 수 있고, 존재하지 않는 제품 식별자나 유효하지 않은 쿼리 작성과 같은 특정 오류를 발견하지 못할 수 있다.

따라서 Elastic은 LLM-as-a-judge와 규칙 및 프로그래밍에 기반한 결정론적 평가를 결합했다. 이러한 평가는 JSON 또는 YAML 구조, 구문의 유효성, 필수 엔티티의 존재 여부, 코드 또는 쿼리의 실행 가능성을 검사하며, 정확도, 재현율, 사실성과 같은 지표도 확인한다. 이 결합 방식은 명확한 답변이 있는 경우 평가 비용과 시간을 줄이고, 규칙으로 축약하기 어려운 작업은 의미론적 판단에 맡긴다.

일반화할 수 없는 것은 무엇인가?

Elastic은 전문적인 테스트 데이터의 구축을 완전히 자동화할 수 있는 부분으로 보지 않았다. 사이버 보안에서는 무엇이 실제 공격에 해당하는지, 최종 사용자에게 허용 가능한 행동이 무엇인지 팀이 판단하려면 분석가와 연구원이 필요하다. 또한 회귀의 정의는 에이전트마다 다르다. 특정 업데이트 이후 보안 에이전트가 정상적인 데이터를 입력했을 때도 공격이 있다고 선언하는 경향이 강해질 수 있다.

평가자의 보정 역시 각 팀의 책임으로 남는다. 언어 평가자가 동일한 사례에 서로 다른 점수를 부여하거나 목표로 삼은 인간의 판단과 일치하지 않는다면, 소프트웨어 구조의 품질이 아무리 높아도 공통 프레임워크는 오해를 불러일으키는 수치를 산출하게 된다. Chang은 생성과 평가에 동일한 모델 계열의 구성원을 사용할 때 평가자 편향이 발생할 위험도 지적했다. 이 경우 평가자가 해당 모델의 성능을 과대평가할 수 있다.

팀에 실질적으로 달라지는 점은 무엇인가?

Elastic의 경험은 완벽한 세트를 기다리기보다 20~50개 사례로 구성된 소규모 테스트 예시부터 시작할 것을 권장한다. 초기 단계에서는 특히 사용 사례와 지표를 아직 발견하는 중일 때 학습을 가속하기 위해 분산된 작업을 진행하는 것도 허용될 수 있다. 그러나 여러 에이전트가 프로덕션에 진입하면 성능에 관한 질문에 답하고 사용자 문제를 진단하기 위해 기본적인 추적과 평가가 필수적이 된다.

Elastic은 또한 일부 평가 도구를 Python에서 TypeScript로 옮겼다. TypeScript로 작성된 프로덕션 코드에 맞추고 Playwright와 Scout라는 내부 맞춤형 도구를 사용하기 위해서였다. 이 단계가 모든 데이터 과학 평가를 옮겨야 한다는 의미는 아니며, 팀이 테스트하는 것과 시스템이 실제로 실행하는 것 사이의 간극을 줄여야 한다는 특정한 필요를 반영한다. 실질적인 결론은 공통 프레임워크가 스키마, 실행, 일반적인 지표를 통일할 수는 있지만, 도메인 전문성이나 무엇을 성공과 실패로 간주해야 하는지에 대한 판단을 대신할 수는 없다는 것이다.