09. Agent 품질을 어떻게 평가하려 했는가

Agent 평가는 정답률 하나로 끝나지 않는다. Lumi_agent처럼 페르소나, 기억, 도구 호출, 승인 경계가 섞인 시스템은 무엇을 평가할지부터 나눠야 한다.

현재 확인 가능한 자료에는 평가 결과표나 성능 의사결정 문서가 남아 있지 않다. 그래서 이 글은 성능 결과가 아니라, 설계 메모에 남아 있는 평가 방향을 기준으로 작성한다.

평가해야 할 것

Lumi_agent의 품질은 최소 네 가지로 나눠 봐야 한다.

평가 축	질문
Persona 유지	도구 호출 후에도 말투와 관계 상태가 유지되는가
Context 활용	관련 과거 기억을 응답에 적절히 반영하는가
Tool Call 적합성	요청에 맞는 도구와 인자를 선택하는가
Safety Boundary	민감 작업을 사용자 승인 없이 실행하지 않는가

이 축을 섞으면 평가가 흐려진다. 예를 들어 응답 말투가 자연스러워도 메시지 전송 도구를 잘못 호출하면 Agent 품질은 낮다.

평가 설계

설계 메모 기준으로 평가 방향은 다음 세 가지로 정리된다.

평가	기준
프롬프트 품질 비교	ArenaGEval 기반 8개 메트릭
Tool Call 적합성	33개 시나리오
A/B 테스트	동일 입력에 대한 prompt 전략 비교, 10 rounds

이 숫자는 평가 결과가 아니라 평가 설계의 범위다. 점수, 향상률, 통과율은 확인 가능한 결과표가 없으므로 작성하지 않는다.

Tool Call 시나리오 예시

평가 시나리오는 다음처럼 나눌 수 있다.

요청 유형	기대 동작
단순 검색	search 계열 도구 호출
일정 조회	Calendar 조회 도구 호출
일정 생성	승인 후 Calendar 생성 도구 호출
메시지 전송	승인 후 Messenger 전송 도구 호출
기억 회상	Memory 검색 결과를 context에 반영

중요한 것은 “도구를 호출했다”가 아니라 “맞는 도구를 맞는 인자로 호출했는가”다.

Prompt 평가 관점

프롬프트 품질은 단순한 문장 자연스러움만 보면 부족하다.

메트릭 예시	의미
Persona 유지	호감도와 관계 상태에 맞는 말투 유지
맥락 활용	과거 기억을 무리 없이 반영
도구 지침 준수	요청한 도구만 사용
안전 경계 준수	민감 도구 실행 전 승인
응답 완결성	실행 결과를 사용자가 이해할 수 있게 설명

이런 평가 설계는 Agent 프로젝트에서 중요하다. 모델 답변이 자연스러운 것과 실행 가능한 Agent로서 안전한 것은 다른 문제이기 때문이다.

결과를 단정하지 않는 이유

현재 확인 가능한 범위에서는 평가 코드와 결과표가 함께 남아 있지 않다. 그래서 이 글은 결과 주장이 아니라 평가 설계의 범위를 남기는 데 초점을 둔다.

정확한 표현은 다음과 같다.

표현	판단
Agent 평가 축을 prompt, tool call, safety로 나누려 했다	사용 가능
8개 메트릭, 33개 시나리오, 10 rounds 설계가 언급된다	사용 가능
평가 결과 수치	기재하지 않음
재현 로그 없는 통과 주장	기재하지 않음

다음 글

다음 글에서는 자체 평가와 Tool Call 불안정성, 그리고 후속 개선 방향을 정리한다.

10. Tool Call 불안정성, 평가 한계, 그리고 Lumi_agent 회고