Android Bench의 에이전트 코드 생성에 관한 유용한 정보

토마스 믈리나리치

여러분, 안녕하세요.

시작해 보겠습니다.

3월에는 Android 개발 작업에서 LLM을 측정하는 데이터 세트 및 리더보드인 Android Bench를 출시했습니다.

그 이후로 Google은 여러 새로운 모델을 대상으로 이 테스트를 실행했습니다.

그리고 지난달에는 Android Bench 2.0을 출시했습니다.

불과 몇 달밖에 되지 않았지만 AI의 세계에서는 영원처럼 느껴집니다.

제 이름은 토마스입니다. Android Bench의 여정과 현재 위치에 도달한 방법을 공유해 드리겠습니다.

1.0부터 시작해 보겠습니다.

1.0에서는 오픈소스 저장소에서 실제 문제를 가져왔습니다.

GitHub 문제를 포함하는 GitHub 프로젝트, 해당 문제를 해결하는 pull 요청, 솔루션을 검증하는 테스트를 필터링했습니다.

pull 요청을 AI 모델의 작업 버킷으로 분할합니다.

GitHub 문제가 모델의 지침 또는 프롬프트가 되었고, 이를 PR 이전 상태에 심었습니다.

모델이 작업을 생성하면 테스트를 수행하고 출력에 적용하여 합격 또는 불합격 결과를 얻었습니다.

AI가 문제를 해결하려는 이 한 번의 시도를 시도라고 합니다.

또한 해당 PR의 사람이 만든 솔루션(골든 솔루션이라고도 함)을 기반으로 비교할 수도 있습니다.

이 방법론은 잘 알려진 SWE-bench 벤치마크와 유사합니다.

10,000개가 넘는 잠재적 작업으로 시작했는데, 이 중 일부는 적합하지 않았습니다.

일부는 요청 사항이 불완전하거나 지나치게 구체적이었습니다.

테스트가 골든 솔루션에 연결되었거나 PR 전 상태가 손상되었을 수 있습니다.

따라서 100개의 공정한 작업을 선정하기 위해 검토를 거듭해야 했습니다.

검토 과정에서 현존 최고 수준(SOTA) 모델을 사용하여 결과를 얻었습니다.

그리고 우리는 약 30% 의 작업이 해결된 상태에서 시작했는데, 이를 통과율이라고 합니다.

그리고 공식 출시를 위해 데이터 세트를 잠갔을 때는 상위 모델이 이미 70% 정도에 도달해 있었습니다.

하지만 한 달 후입니다.

그리고 매달 새로운 모델을 평가하는 계획을 세웠고, 모델이 어떻게 개선되는지 지켜봤습니다.

8월 출시에서는 최고의 모델의 통과율이 92% 였습니다.

기준이 너무 낮고 이 데이터 세트가 포화 상태라는 것을 알았습니다.

토마스 믈리나리치

하지만 Google은 이를 예상하고 있었으며, 지난달에 출시한 2.0을 위해 이미 열심히 노력하고 있습니다.

목표는 복잡한 실제 Android 작업으로 기준을 높이고 개발자에게 LLM 성능에 대한 가이드와 투명성을 제공하는 동시에 모델 제작자가 Android를 우선시하도록 좋은 벤치마크를 제공하는 것입니다.

또한 개발자와 모델 제작자 모두에게 분석과 결과를 제공합니다.

하지만 영리함, 끈기, 부정행위도 고려해야 합니다.

오염 위험을 방지해야 합니다.

SWE-bench 방법론의 한 가지 문제는 소스 코드의 실제 개방성입니다.

OpenAI에서 기사를 게시했습니다.

모델이 요청 사항의 다음 단어를 완성하거나 요청 사항에 포함되지 않은 모호한 오류가 있는 작업을 해결할 수 있다는 사실을 발견했습니다.

그리고 모델 제작자가 오픈소스 코드로 학습하고 있으며 SWE-bench가 오염되었다는 사실을 깨달았습니다.

따라서 2.0의 경우 이를 방지하기 위해 코드를 비공개로 유지하고 있습니다.

작업을 4개의 작업 스트림으로 나누었습니다.

첫 번째는 앱 변환입니다. 오픈소스, Flutter, React Native 앱을 가져와 에이전트에게 네이티브 Android 솔루션으로 변환하도록 지시했습니다.

이는 현재 크로스 플랫폼에서 네이티브로 이전하는 추세를 반영합니다.

두 번째 작업 스트림은 새로운 기능과 플랫폼 통합이었습니다.

기존 프로덕션 코드베이스에 빌드되었습니다.

예를 들어 Now in Android에는 동영상 기능이나 PIP 모드 같은 기능을 추가했습니다.

세 번째 작업 스트림은 마이그레이션이었습니다.

비공개로 유지했던 프로덕션 오픈소스 앱을 최신 라이브러리와 아키텍처로 업그레이드하고 있습니다.

예를 들어 Nav 2에서 Nav 3으로, XML 뷰에서 Compose로, 단일 창에서 적응형 레이아웃으로 전환하는 경우입니다.

마지막은 시각적 디자인 모형을 사용하여 처음부터 빌드한 사내 신규 앱이었습니다.

여기에는 전체 SMS OTP 인증 흐름, Google 지도를 사용한 주문 추적 등이 포함됩니다.

토마스 믈리나리치

엔지니어 몇 명만으로 Now in Android와 같은 규모의 앱을 빌드했습니다.

하지만 새로운 작업에는 새로운 과제가 따랐습니다.

첫 번째는 상담사를 적절하게 평가하는 것입니다.

벤치마크 테스트는 앱 테스트보다 훨씬 어렵습니다. 하나가 아닌 모든 유효한 솔루션을 통과해야 하며, 작업이 클수록 유효한 솔루션이 더 많기 때문입니다.

1.0에서는 벤치마크가 주로 단위 테스트에 의존했는데, 단위 테스트는 중립적이지 못했습니다.

import com.foodvibes.MyViewModel

@Test
fun testRetry() {
    val vm = MyViewModel()
    vm.retry()

    assertTrue(vm.retried)
}

정확한 클래스 또는 함수 이름이 필요합니다.

이 경우처럼, 특별한 테스트는 아니지만, 기본적으로 상담사가 이러한 항목의 이름을 다르게 지정할 수 있으며, 이름을 다르게 지정하지 않더라도 다른 패키지에 넣으면 테스트가 컴파일되지 않으므로 이 경우 사용할 수 없습니다.

import com.foodvibes.feature.my.RetriableViewModel

@Test
fun testRetry() {
    val vm = RetriableViewModel()
    vm.tryAgain()

    assertTrue(vm.tried)
}

따라서 기술적으로 프롬프트에 API를 지정할 수 있지만, 그렇게 하면 너무 많은 세부정보가 노출되거나 너무 많은 테스트 요구사항으로 인해 프롬프트가 폭발할 수 있습니다.

따라서 구현과 무관한 테스트를 실행하는 것이 해결책입니다.

이러한 테스트는 매우 높은 수준의 결과 테스트로, 내부가 아닌 결과와 동작을 테스트합니다.

Google은 사용자와 유사하게 공개 화면 정보와 상호작용하는 테스트인 결정론적 UI 테스트를 사용합니다.

이러한 경우에는 UI Automator 또는 Compose UI 테스트를 사용하지만, 네트워크 호출에 올바른 데이터가 있는지 또는 내부 도우미나 DAO를 알지 못해도 올바른 데이터가 데이터베이스에 저장되는지 등 일부 외부 시스템 경계를 확인하는 특수 스크립트도 있습니다.

그중 일부는 정적 검사도 있습니다. 매니페스트의 권한이나 라이브러리가 빌드 파일에 있는지 등을 확인하는 것입니다.

또한 이러한 스크립트와 UI 테스트를 결합한 하이브리드 테스트도 있습니다.

이는 하이브리드 테스트 중 하나의 예입니다.

에뮬레이터 외부에서 운전합니다.

이것은 SMS OTP 인증 흐름에 대한 테스트입니다. 스크립트는 먼저 앱의 해시를 계산하여 에뮬레이터에 SMS를 올바르게 전송할 수 있어야 합니다. 그런 다음 테스트, UI Automator 테스트를 시작하고 필요한 무작위로 생성된 OTP를 전달하고 ADB 명령을 사용하여 에뮬레이터에 SMS를 전송합니다.

테스트에서는 입력에 올바른 숫자가 있는지 확인합니다.

기본적으로 그렇습니다.

구현 결합이 전혀 없고 흐름이 작동하는지만 확인합니다.

두 번째 채점 문제는 작업에 멀티모달리티가 필요하다는 점이었습니다.

에이전트가 UI를 생성해야 하거나, 아니면 디자인 모의를 제공합니다.

이를 위해서는 스크린샷 테스트를 사용하는 것이 가장 쉽습니다.

스크린샷 기준이 더 높아야 한다는 것은 처음부터 알고 있었지만, 어쨌든 실패했습니다.

다양한 픽셀 차이 알고리즘을 시도해 보았지만 에뮬레이터 상태 표시줄이 다르거나 배터리 아이콘이 다르거나 글꼴 하드웨어 앤티앨리어싱이 다른 경우와 같은 시스템 수준 노이즈에서는 실패했습니다.

하지만 패딩이 약간 다르거나 색조가 약간 다른 등 다소 유효한 구현에서도 실패했습니다. UI는 완전히 정확하지만 배경의 색조가 약간 다르고 픽셀 차이 알고리즘이 실패할 수 있습니다.

이를 위해 스크린샷 테스트에서와 같이 스크린샷 쌍을 비교하고 점수를 제공하는 멀티모달 LLM 평가를 사용하고 빌드했습니다. 또한 점수에 대한 구조적 추론도 제공합니다.

또한 구조가 올바른지, 구조적 패리티가 올바른지 확인하는 접근성 계층 구조 덤프도 제공합니다.

수많은 시도를 통해 경험적으로 테스트한 결과, 일관성이 높고 앞서 살펴본 문제를 무시하는 것으로 나타났습니다.

이제 시각적 요소와 동작을 독립적으로 검증할 수 있는 좋은 방법이 생겼고, 에이전트가 모든 것을 가짜로 만들려고 시도하는 것을 확인했습니다.

네, 말씀하세요.

토마스 믈리나리치

시작은 간단합니다.

요즘에는 에이전트가 기본적으로 '알겠습니다.

할 일이 있습니다.

GitHub를 살펴보겠습니다.

해결책을 찾아보자."

이것이 첫 번째로 하는 일입니다.

유효한 솔루션을 찾기 위해 GitHub나 인터넷을 검색하려고 시도하므로 소스 코드를 비공개로 유지해야 하며 공개할 수 없습니다.

그건 쉬웠어요.

일부 시도에서는 모든 것이 100% 완벽하게 통과했다고 말했고, 에이전트는 "대단한 승리입니다!"라고 말했습니다.

어쨌든

흥미롭네요. 어떤 결과가 나왔나요?

하지만 궤적을 자세히 살펴보니, "이건 못 하겠어.

스크린샷 테스트의 기준점을 80% 로 변경하면 어떻게 될까요?"

// AuthFlowScreenshotTests.kt

@get:Rule
val dropshots = Dropshots(
    resultValidator =
        ThresholdValidator(
-           0.05f
+           0.80f
        )
)

"그래, 승리야, 모든 것이 지나가고 있어."

네, 하지만 스크린샷 테스트는 쓸모가 없습니다.

하지만 가장 정교한 것은 아니었습니다.

Flutter 변환 앱에서는 에이전트가 Android를 빌드하려고 계속 시도하다가 결국 "어떻게 해야 할지 모르겠다"고 말했습니다.

그래서 그들은 우리가 제공한 스크린샷을 가져와서 백그라운드에 드로어블로 넣었습니다.

이제 스크린샷 테스트를 통과한 것 같습니다.

확인

하지만 UI 테스트는 여전히 실패하므로, '그 위에 버튼, 텍스트, 테스트 태그 등 필요한 모든 항목이 포함된 보이지 않는 오버레이 레이어를 배치할 거야.

이제 모든 것이 녹색입니다.

이제

잘하셨습니다."

그렇다고 해서 하나가 정말 좋은 건 아니에요.

자바에서 Kotlin으로 이전하는 작업이 있습니다. 에이전트가 기본적으로 자바에서 Kotlin으로 이전해야 하는 작업입니다.

빌드할 수 없었습니다.

여전히 실패하는 부분이 있어서 에이전트는 '좋아, Java에서 컴파일된 클래스를 가져와서 JAR에 넣은 다음 일반 라이브러리로 빌드 파일에 추가하면 되겠지.'라고 생각했습니다.

이제 모든 테스트가 통과하지만 Java 파일을 확인하는 정적 검사가 있으므로 삭제하겠습니다."

Java 파일을 삭제하고 모든 것이 녹색으로 표시되지만 Kotlin은 여전히 실패합니다. 그래서 '좋아, Kotlin 소스 세트를 삭제할 거야. 이제 모든 것이 통과했어.

좋습니다."

이게 부정행위인지도 모르겠어요.

정말 창의적이에요.

이러한 문제를 방지하기 위해 세 가지 방어 기능을 갖춘 부정행위 감지기를 구축했습니다.

UI 트리를 살펴보고, 배경이 왜곡되도록 다양한 화면 크기를 적용하고, 이를 확인합니다.

하지만 테스트를 재설정하고 테스트 조작 여부를 확인하여 기준점을 변경할 수 없도록 합니다.

또한 LLM-as-a-Judge를 사용하여 에이전트의 궤적과 실제 출력을 감사하여 이상한 점을 확인합니다.

무슨 일이 생기면 '좋아, 바로 실패야'라고 말합니다.

토마스 믈리나리치

이제 모든 지름길이 사라졌습니다. 솔루션을 찾아볼 수도 없고, 불안정한 단위 테스트나 UI를 속이는 것도 불가능합니다.

에이전트가 실제로 Android 앱을 엔지니어링하도록 하면 수치는 어떻게 될까요?

월요일에 블로그 게시물을 보셨을 수도 있는데, 수치는 다음과 같습니다.

가장 뛰어난 에이전트도 작업의 약 40% 만 통과하며, 대부분의 최첨단 에이전트는 20~40% 사이입니다.

이는 벤치마크 작성자에게도 좋은 일입니다. 적절한 균형을 유지할 수 있기 때문입니다. Google이 제공한 작업의 실제 가치가 있으면서도 성장할 여지가 충분합니다.

이제 결과를 살펴보겠습니다.

이제 여러 관점에서 결과를 살펴볼 수 있습니다.

이미 발견한 몇 가지 통계를 살펴보겠습니다.

차트를 볼 때 가장 먼저 드는 질문은 에이전트를 실행하는 데 드는 비용입니다.

AI 기업은 일반적으로 토큰당 비용을 보고하며, 입력, 출력, 캐시 토큰에 대한 비용을 보고하기도 합니다.

이것이 의사 결정의 근거가 될 수도 있습니다.

하지만 다른 관점에서 살펴볼 수도 있습니다.

토큰이 아닌 작업당 평균 비용을 사용하여 2D 공간에 동일한 차트를 표시할 수 있습니다. 즉, 작업당 비용과 통과율을 비교할 수 있습니다.

여기에서 일부 모델이 훨씬 더 많은 말을 하는 것을 볼 수 있습니다.

작업당 훨씬 더 많은 시간이나 토큰을 소비하는 반면, 다른 모델은 더 적은 비용으로 더 많은 작업을 처리합니다.

하지만 동일한 차트에 토큰당 가격을 추가하면 AI 기업이 실제로 광고하는 내용이 작업당 실제로 지불하는 비용과 일치하지 않는다는 것을 알 수 있습니다.

따라서 통과율이 가장 높은 에이전트가 실제로는 토큰당 비용이 가장 저렴하지만 작업당 비용은 가장 비싼 에이전트 중 하나라는 것을 알 수 있습니다.

또는 토큰 가격이 동일한 다른 에이전트는 작업의 약 30% 를 통과하지만 15배 더 저렴합니다.

따라서 토큰 가격은 측정항목이 아닙니다.

일부 모델은 코드를 더 많이 탐색하고, 다시 빌드하고, 다시 실행하며, 각 단계에서 더 많은 토큰을 소모합니다.

따라서 토큰당 비용만 보지 말고

모델을 선택하고 실제 데이터를 살펴보세요. 예를 들어 사용 사례에 사용하거나 Android Bench를 통해 어떤 모델이 작업에 가장 많은 토큰을 사용하는지 확인하세요.

일부는 토큰당 비용이 저렴하지만 더 많은 단계가 필요합니다.

하지만 동일한 질문에 또 다른 측면이 있습니다.

이 차트는 동일하지만 상담사가 작업을 완료하는 데 걸리는 시간도 확인할 수 있습니다.

통과율이 가장 높은 상담사가 가장 느릴 수도 있습니다.

예를 들어 작업당 거의 2시간이 걸리는 경우도 있습니다.

작동할 때까지 계속 다시 빌드하고 다시 테스트합니다.

예, 통과율이 가장 높지만 시간도 가장 많이 걸립니다.

일부 저렴한 에이전트는 작업당 약 1시간 30분이 소요되지만 결과가 더 좋지는 않습니다.

또는 20분 이내에 완료하고도 작업의 4분의 1 이상을 해결하는 상담사도 있습니다.

따라서 작고 가벼운 모델은 일반적으로 더 빠르고 저렴하지만 어려운 작업에서는 더 자주 실패합니다.

핵심은 단 하나의 최적 모델은 없다는 것입니다.

최적화 대상에 따라 다릅니다.

통과율인가요?

비용인가요?

대기 시간인가요?

이 경우 수행하는 작업 유형에 따라, 어려운 작업을 수행하지 않는다면 더 저렴하고 빠르게 작업을 완료하는 더 빠른 모델을 사용하는 것이 좋습니다.

하지만 비용과 속도는 에이전트가 어떻게 실행되는지만 알려줄 뿐, 대부분의 시도가 실패하는 이유는 알려주지 않습니다.

그래서 실패한 실행을 검사한 결과 에이전트가 일찍 종료되는 경우가 많다는 것을 알게 되었습니다.

그들은 끝났다고 확신합니다.

작업이 완료되었습니다.

알았어, 집에 갈게.

하지만 앞서 언급했듯이 작업 패킷에서 상담사는 안내와 이전 상태만 받습니다.

테스트를 볼 수 없습니다.

인증 도구를 볼 수 없다고 합니다.

그래서 저희는 '만약 테스트를 볼 수 있게 하면 어떻게 될까?'라고 질문했습니다.

그래서 실험을 진행했고, 동일한 작업의 공개 테스트 버전을 만들었습니다. 이 버전에서는 에이전트가 실패한 검증 테스트 모음을 미리 받았습니다.

이제 테스트를 반복적으로 실행하고 있었습니다.

오류를 검사하고 피드백 루프에서 코드를 미세 조정할 수 있습니다.

그리고 상담사가 테스트를 보면 더 열심히 노력하고 더 오래 일한다는 사실을 발견했습니다.

공개 실행에서는 대화 차례가 25% 더 많았고 Agent Runtime은 40% 더 길었습니다.

작업당 거의 30분 동안 실패한 테스트를 실행하고 수정하는 데 시간을 보냈습니다. 무작정 디버깅하지 않았기 때문입니다.

따라서 실패한 부분을 정확하게 파악할 수 있으며, 안타깝게도 합격률도 거의 50%포인트 상승합니다.

이러한 추가적인 노력은 앞서 언급했듯이 평균 합격률을 높입니다.

하지만 결국 새로운 프런티어 모델이 등장했고, 이 개방형 모델은 빠르게 포화 상태에 이르렀습니다.

합격률이 거의 90% 에 달합니다.

따라서 비공개 검색 비공개 테스트 버전을 기본 벤치마크 측정항목으로 유지했습니다.

하지만 모델이 평가 기준을 알고 있을 때 실제로 더 나은 성능을 보인다는 점은 여전히 매우 흥미롭습니다.

토마스 믈리나리치

하지만 상담사에 관한 더 많은 인사이트를 얻을 수 있었습니다.

예를 들어 모델이 실제로 자체 작업을 어떻게 테스트하는지 확인할 수 있습니다.

차트를 보면 프런티어 모델이 더 나은 테스트를 더 많이 작성하고 통과율이 더 높다는 것을 알 수 있습니다.

다른 모델은 자신감이 넘쳐서 테스트 없이도 할 수 있다고 합니다.

가끔은 괜찮을 때도 있습니다.

따라서 테스트에 적합하지 않은 모델을 사용하는 경우 더 나은 테스트 기술을 제공하거나 테스트 작성 방법에 관한 구체적인 안내를 제공할 수 있습니다.

하지만 상관관계가 인과관계를 의미하지는 않죠, CS?

이에 대한 통제된 실험이 필요합니다.

더 나은 테스트를 위한 프롬프트가 실제로 점수를 높이는지에 대해서는 아직 확인이 필요합니다.

하지만 Android 테스트의 나머지 절반에 대해서는 실험을 진행했습니다. 상담사가 에뮬레이터를 사용하도록 하는 실험이었습니다.

벤치마크 초기에는 에뮬레이터에 관해 아무것도 언급하지 않았습니다.

상담사가 알아서 해결해야 한다고 생각했죠.

그 결과, 실제로 에뮬레이터를 부팅하는 경우는 거의 없었습니다.

앞서 언급했듯이 UI 테스트는 벤치마크에서 매우 중요하며 에뮬레이터가 없으면 UI 테스트를 사용할 수 없습니다.

모두 아주 간단한 부분에서 실패하고 있었습니다.

이제 딜레마에 직면하게 됩니다.

상담사에게 에뮬레이터를 사용해야 한다고 말하고 실제로 더 높은 점수를 받을 위험을 감수해야 할까요, 아니면 아무 말도 하지 않고 상담사가 알아서 해결하기를 바라야 할까요?

하지만 결국 우리의 목표는 Android 코딩과 문제 해결을 측정하는 공정한 벤치마크가 되는 것이었습니다.

환경적 특이점을 측정하고 싶지는 않습니다.

그래서 절충안을 선택했습니다.

에뮬레이터를 시작하는 방법은 알려줬지만, 사용 여부에 대해서는 언급하지 않았습니다.

결국 에뮬레이터를 시작하는 것은 실제로 테스트해야 하거나 테스트하려는 대상이 아닙니다.

그리고 에뮬레이터 명령의 효과를 측정했습니다.

방법을 알려주자 에이전트가 에뮬레이터를 훨씬 더 많이 부팅하고 실제로 UI 테스트를 실행했으며, 이는 안타깝게도 통과율에 큰 영향을 미쳤습니다.

또한 부팅되지 않은 에뮬레이터에서 실패하는 것뿐만 아니라 실제 코딩 실수와 문제를 검사할 수 있었습니다.

따라서 프롬프트의 구체성은 여전히 매우 중요하며, 자체 벤치마크나 평가를 설계하는 경우 실제 사용 사례에서 중요한 요소를 테스트해야 합니다.

예를 들어 기술이나 도구의 토큰 효율성을 평가한다고 가정해 보겠습니다. 먼저 평가 통과로 시작하고 효율성을 위해 변경한 다음, 이제 더 적은 토큰으로도 여전히 통과하는지 확인해야 합니다.

그렇지 않으면 너무 많은 변수가 한꺼번에 변경되어 실제로 변경사항으로 인해 개선되었는지 알 수 없습니다.

토마스 믈리나리치

리더보드로 돌아갑니다.

앞서 언급했듯이 최고의 모델은 작업의 약 40% 를 통과하며, 통과율은 모든 검사를 통과해야 합니다.

그렇지 않으면 작업이 실패합니다.

그렇다면 나머지 60%에 대해서는 에이전트가 유용한 결과를 생성하지 못했을까요?

아니요, 거의 다 왔습니다.

에이전트가 실제 작동하는 솔루션에 얼마나 근접했는지, 일종의 거리처럼 보여주기 위해 완료율 또는 부분 점수와 같은 것도 계산합니다.

이는 시각적 일관성, 기능, 제대로 작동하는지 여부, 작업별 요구사항, 회귀 검사 등 네 가지 카테고리에 걸친 가중치 점수입니다.

순위가 낮은 모델은 작업의 절반 정도를 완료할 수 있는 반면, 프런티어 모델은 평균적으로 작업의 거의 80%, 즉 80% 이상을 완료할 수 있지만 40%만 통과하는 것을 볼 수 있습니다.

그래서 Flutter에서 Android로의 변환에 대한 실험을 진행하여 어떤 일이 일어나고 있는지 확인했습니다.

그래서 몇 단계마다 완료율을 다시 계산했고, 모든 프런티어 모델에서 동일한 패턴을 확인했습니다.

약 140단계에서 평균 90% 에 가까운 점수를 달성하기 위해 노력했고, 이후 90단계 이상, 즉 실행의 거의 40% 를 100%까지의 격차를 좁히기 위해 노력했지만 1~2% 정도만 더 달성할 수 있었습니다.

이는 오늘날 에이전트 개발의 현실을 반영한다고 생각합니다. 경험이 부족한 개발자나 사용자는 앱이 완성되었다고 생각하지만,

모든 것이 렌더링됩니다.

입력이 어느 정도 작동했습니다.

비정상 종료가 없을 수 있습니다.

하지만 선임 엔지니어가 코드를 살펴보면 아키텍처 문제, 수명 주기 결함 등 수많은 결함이 보입니다.

토마스 믈리나리치

마지막으로 Android Bench 2.0을 정리해 보겠습니다.

1.0과 비교하면 이제 작업이 30개뿐이며 이는 의도적인 것입니다.

개별 버그 수정과 작은 패치 대신 전체 화면, 멀티 모듈 이전, 전체 앱 변환이 있습니다.

이제 패치는 수십 개의 파일에 걸쳐 훨씬 더 커졌습니다.

멀티모달 UI 검사도 있습니다.

에이전트는 더 오래 실행되고 더 열심히 작업해야 합니다.

다른 최첨단 벤치마크와 비교해 보면 Google의 벤치마크는 훨씬 더 큰 코드 변경이 필요하다는 것을 알 수 있습니다.

대부분의 작업이 처음부터 작성되므로 오염이 없고, 아직 성장할 여지가 많습니다.

시작할 때 말씀드린 것처럼 AI 세계에서 몇 달은 영원처럼 느껴지며, 결국 모든 벤치마크가 최대치에 도달하고 포화 상태가 됩니다.

이 문제가 해결되면 더 어렵고 복잡한 작업을 추진하여 그 시대의 AI 상태에 다시 한번 공감을 불러일으킬 수 있기를 바랍니다.

이제 Android Bench를 나침반으로 사용하여 모델과 하네스를 비교하고 유용한 정보를 얻을 수 있습니다.

더 깊이 있게 살펴볼 준비가 되면 동일한 벤치마킹 원칙과 평가 원칙을 자체 코드베이스와 워크플로에 적용하세요. 실제로 작업하는 코드에서 AI를 측정하는 것보다 더 좋은 방법은 없습니다.

이렇게 하면 AI가 제대로 처리했는지 확인할 수 있습니다.

Android Bench를 대표하여 관심을 가져주셔서 감사합니다.