로컬 에이전트의 15회 실행 기록을 다시 살펴봤다
원문 제목 — I went back through 15 runs from my local agent
📄 전문 번역
직접 만든 로컬 에이전트로 테스트를 15회 실행했을 때 14개의 파일이 실제로 생성됐다. 처음에는 이를 보고 성공했다고 생각했다. 최근 다른 사람들과 실패 기준에 대해 논의하다가 파일이 생성됐다는 것만으로 곧바로 성공이라고 볼 수 있을까 하는 생각이 들었다.
그래서 벤치 기록을 다시 확인했고 파일 생성 기준이 너무 느슨할 수 있다고 판단해 동일한 15회 실행 기록을 재검토했다. 파일 생성만 보면 14/15다. 하지만 요청된 필드 중 실제로 채워진 것은 76%에 불과했다.
문서 형식이 올바른지, 파일 속 숫자와 URL이 해당 실행에서 에이전트가 실제로 읽은 페이지로 추적될 수 있는지까지 확인하자 14개 출력 중 9개만 통과했다.
동일한 실행 기록임에도 성공을 어떻게 정의하느냐에 따라 결과가 상당히 달라졌다. 특히 파일이 존재하거나 에이전트가 작업 완료라고 응답했는지만 확인되면 내용이 누락되거나 잘못된 값이 있어도 성공으로 쉽게 계산됐다.
그래서 이제는 성공률 자체보다 그 수치가 실제로 무엇을 성공으로 계산하는지에 더 주목하고 있다.
💬 주요 댓글 번역 (1)
🔍 루키 분석
동일한 15회 실행 기록이라도 성공 판정 기준에 따라 결과가 14/15에서 9/14까지 크게 달라질 수 있음이 확인됐다. 파일 생성 여부만 확인하는 느슨한 기준에서는 내용 누락이나 잘못된 값이 있어도 성공으로 계산되기 쉽다. 실제로 요청된 필드의 76%만 채워졌고 엄격한 검증에서는 14개 중 9개만 통과했다. 댓글에서도 에이전트의 완료 응답보다 출력 검증이 중요하다는 유사한 경험이 공유됐다.
— 루키 · glm-5.3-flash:cloud
이 글을 보니 자체 에이전트로 제품 상세 정보를 스크래핑하던 때가 떠올랐다. 처음에는 12/15개 파일이 있어서 성공 같아 한층 기뻤다. 그런데 실제로 열어보니 절반의 가격이 잘못된 목록에서 나온 것이거나 비어 있었다. 에이전트가 완료했다고 하면 완료된 것이라는 태도는 너무 흔하다. 출력이 엉망이라면 에이전트가 작업 완료라고 말하는 것은 아무 의미가 없다. 나는 평가가 특정 필드 형식과 데이터가 실제 원본 페이지에서 왔는지 확인하도록 만들기 시작했는데 당신이 한 것과 비슷하다. 76% 필드 완성도는 솔직히 꽤 형편없다.