
Google Cloud 공식 블로그에 따르면 회사는 2026년 7월 10일 데이터 에이전트의 평가 신뢰성을 점검하기 위한 Discovery Bench 접근을 공개했다. 이번 글은 에이전트가 정답을 맞혔는지 여부만 보는 방식으로는 실제 운영 환경의 실패 지점을 충분히 파악하기 어렵다는 문제의식에서 출발한다.
Google Cloud가 주목한 영역은 데이터 검색과 검색 증강 생성의 첫 단계다. 기업 데이터 환경에서 에이전트는 사용자의 불완전한 질문을 받아 수천 개의 테이블과 파일 가운데 필요한 데이터를 찾아야 한다. 이 과정은 모델의 추론 능력뿐 아니라 질의가 얼마나 구체적인지, 데이터셋을 가리키는 단서가 충분한지에 크게 영향을 받는다.
Discovery Bench의 핵심은 같은 평가 사례를 고정된 한 문장으로만 시험하지 않는 데 있다. Google Cloud는 정보이론의 surprisal 개념을 활용해 질의 속 단어나 구문이 정답 데이터셋을 얼마나 잘 구분하는지 측정하고, 이를 바탕으로 쉬운 표현과 어려운 표현을 만들어 평가 난이도를 조절한다고 설명했다. 회사는 이 반복 과정을 iSQR, 즉 iterative surprisal-based query refinement라고 부른다.
이 방식은 기존 정적 벤치마크가 놓치는 급격한 실패 지점을 드러낸다. Google Cloud는 공개 벤치마크인 KramaBench 사례를 들어, 특정 위성 데이터 질의에서 구분력이 큰 용어가 빠지면 같은 정답을 요구하는 질문이라도 에이전트가 완전히 다른 데이터 테이블을 찾을 수 있다고 설명했다. 단일 문장 평가에서는 해결된 문제처럼 보이지만, 표현이 조금 모호해지는 순간 실패하는 지점이 숨겨질 수 있다는 뜻이다.
Google Cloud는 Gemini 3.1 Pro 기반 Discovery Agent를 대상으로 한 실험도 소개했다. 블로그에 따르면 이 에이전트는 높은 모호성 조건에서는 F1 0.34, 중립 조건에서는 0.76, 중간 모호성에서는 0.81을 기록했다. 특정 사례에서는 중립 표현에서 F1 1.00을 보였지만 높은 모호성 표현에서는 0.00으로 떨어졌다. 회사는 이 결과가 단순 통과·실패 점수보다 에이전트의 취약 구간을 더 선명하게 보여준다고 해석했다.
이번 글은 벤치마크 자체도 검증 대상이라는 점을 강조한다. Google Cloud는 실제로 팀들이 쓰는 평가 데이터를 검토하는 과정에서 정답 테이블이 질문에 맞지 않거나, 일부 검색 API가 반환할 수 있는 범위를 넘어서는 샤딩 테이블 문제가 있거나, 월 단위 조건이 필요한데 날짜 단위 조건이 빠진 사례를 발견했다고 밝혔다. 에이전트 평가가 잘못된 기준을 신뢰하면 모델 개선 방향도 잘못될 수 있다는 지적이다.
이 접근은 기업의 AI 에이전트 도입에도 시사점이 있다. 에이전트 품질 평가는 데모 수준의 정답률보다 실제 사용자의 모호한 요청, 데이터 구조 변화, 검색 범위 제한, 장기 검색 체인에서의 실패를 함께 확인해야 한다. 특히 데이터 분석과 업무 자동화 에이전트는 잘못된 테이블을 찾고도 그럴듯한 답변을 만들 수 있어, 평가 문항과 정답 근거를 함께 관리하는 체계가 필요하다.
다만 Discovery Bench는 Google Cloud가 현재 반복 개발 중이라고 밝힌 메타 벤치마크 접근이다. 제품 기능의 일반 제공이나 독립 표준으로 확정된 것은 아니며, 실제 조직에 적용하려면 데이터셋 특성, 평가 지표, 사용자 질의 유형에 맞춘 별도 검증이 필요하다.
출처: Google Cloud Blog https://cloud.google.com/blog/products/data-analytics/evaluate-agent-performance · Google Cloud Documentation https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/evaluate-agents