Statystyki dotyczące generowania kodu agenta z Android Bench

Tomáš Mlynarič

Dzień dobry.

Zaczynajmy.

W marcu wprowadziliśmy Android Bench, nasz zbiór danych i tabelę wyników do pomiaru LLM w zadaniach związanych z programowaniem na Androida.

Od tego czasu przetestowaliśmy go na wielu nowych modelach.

W zeszłym miesiącu opublikowaliśmy Android Bench 2.0.

Choć minęło zaledwie kilka miesięcy, w świecie AI to cała wieczność.

Nazywam się Tomáš i opowiem o naszej drodze do stworzenia Android Bench i o tym, jak dotarliśmy do miejsca, w którym jesteśmy teraz.

Zacznijmy od wersji 1.0.

W wersji 1.0 wykorzystaliśmy rzeczywiste problemy z repozytoriów open source.

Przefiltrowaliśmy projekty na GitHubie, uwzględniając problemy na GitHubie, żądania pull rozwiązujące te problemy i testy weryfikujące rozwiązania.

Dzielimy żądania pull na grupy zadań dla modeli AI.

Problem na GitHubie stał się instrukcjami lub promptem dla modelu, które umieściliśmy w stanie przed PR.

Gdy model wygenerował wyniki, przeprowadziliśmy testy i zastosowaliśmy je do wyników, co dało nam wynik pozytywny lub negatywny.

Jedną próbę rozwiązania problemu przez AI nazywamy próbą.

Możemy też porównać je z rozwiązaniem stworzonym przez człowieka w ramach tego PR, które nazywamy rozwiązaniem złotym.

Ta metodologia jest podobna do dość znanego testu porównawczego SWE-bench.

Zaczęliśmy od ponad 10 tys. potencjalnych zadań, ale nie wszystkie były odpowiednie.

Niektóre instrukcje były niekompletne lub zbyt szczegółowe.

Testy mogły być powiązane ze wzorcowym rozwiązaniem lub stan przed PR był uszkodzony.

Dlatego musieliśmy wielokrotnie sprawdzać zadania, aby wybrać 100 sprawiedliwych.

Podczas tych przeglądów wykorzystaliśmy najnowocześniejsze modele, aby uzyskać wyniki.

Zaczęliśmy od około 30% rozwiązanych zadań, co nazywamy wskaźnikiem zdawalności.

Gdy zablokowaliśmy zbiór danych na potrzeby oficjalnej premiery, najlepsze modele osiągały już około 70%.

Ale to dopiero za miesiąc.

Następnie planowaliśmy co miesiąc oceniać nowe modele i obserwować, jak się poprawiają.

W sierpniowej wersji najlepszy model osiągnął wynik 92%.

Wiedzieliśmy, że poprzeczka jest ustawiona zbyt nisko, a ten zbiór danych jest nasycony.

Tomáš Mlynarič

Przewidzieliśmy to i już pracujemy nad wersją 2.0, którą udostępniliśmy w zeszłym miesiącu.

Celem jest i było podniesienie poprzeczki dzięki złożonym, rzeczywistym zadaniom na Androidzie oraz zapewnienie wskazówek i przejrzystości w zakresie wydajności LLM dla deweloperów, ale także zachęcenie twórców modeli do priorytetowego traktowania Androida przez zapewnienie im dobrego punktu odniesienia, do którego mogą dążyć.

Zapewniamy też analizy i wyniki, które są przydatne zarówno dla Ciebie, jak i dla twórców modeli.

Ale musimy też wziąć pod uwagę spryt, wytrwałość i oszukiwanie.

Musimy też zapobiegać ryzyku zanieczyszczenia.

Jednym z problemów z metodologią SWE-bench jest rzeczywista otwartość kodu źródłowego.

OpenAI opublikowała artykuł.

Okazało się, że modele były w stanie dokończyć kolejne słowa instrukcji lub rozwiązać zadanie z niejasnym błędem, który nie był częścią instrukcji.

Zauważyli, że twórcy modeli trenują je na kodzie źródłowym open source i że test SWE-bench jest zanieczyszczony.

Dlatego w przypadku wersji 2.0 nie udostępniamy kodu, aby uniemożliwić trenowanie na jego podstawie.

Podzieliliśmy pracę na 4 obszary.

Pierwszy to konwersje aplikacji, w ramach których wzięliśmy aplikacje open source, Flutter i React Native i powiedzieliśmy agentom, aby przekonwertowali je na natywne rozwiązanie na Androida.

Odzwierciedla to trend przechodzenia z aplikacji na wiele platform na aplikacje natywne, który obecnie obserwujemy.

Drugi strumień prac obejmował nowe funkcje i integracje platform.

Zostały one wbudowane w ustalone bazy kodu produkcyjnego.

Na przykład w Now in Android dodaliśmy funkcję wideo, obraz w obrazie i inne.

Trzecim strumieniem pracy były migracje.

Uaktualniamy produkcyjne aplikacje open source, które były zamknięte, za pomocą nowoczesnych bibliotek i architektur.

Na przykład Nav 2 na Nav 3, widoki XML na Compose lub układ z jednym panelem na układ adaptacyjny.

Ostatnia to wewnętrzna aplikacja typu greenfield, która została utworzona od podstaw przy użyciu makiet projektu wizualnego.

Przykłady obejmowały pełny proces uwierzytelniania za pomocą jednorazowego hasła SMS, śledzenie zamówień za pomocą Map Google i inne.

Tomáš Mlynarič

Z pomocą zaledwie kilku inżynierów stworzyliśmy aplikację o podobnym rozmiarze, taką jak Now in Android.

Nowe zadania przyniosły jednak nowe wyzwania.

Pierwszy: prawidłowe ocenianie agentów.

Testy porównawcze są znacznie trudniejsze niż testy aplikacji, ponieważ muszą zaliczyć każde prawidłowe rozwiązanie, a nie tylko jedno. Im większe zadanie, tym więcej prawidłowych rozwiązań.

W wersji 1.0 test porównawczy opierał się głównie na testach jednostkowych, które są bardzo słabe pod względem niezależności.

import com.foodvibes.MyViewModel

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

    assertTrue(vm.retried)
}

Wymagają dokładnych nazw klas lub funkcji.

W tym przypadku nie ma żadnego skomplikowanego testu, ale chodzi o to, że agent może nazwać te rzeczy inaczej. Nawet jeśli nie nazwie ich inaczej, to jeśli umieści je w innym pakiecie, testy nie zostaną skompilowane i nie będą przydatne w naszym przypadku.

import com.foodvibes.feature.my.RetriableViewModel

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

    assertTrue(vm.tried)
}

Technicznie moglibyśmy określić interfejsy API w promptach, ale to ujawniłoby zbyt wiele szczegółów lub spowodowałoby, że prompt zawierałby zbyt wiele wymagań testowych.

Rozwiązaniem są testy niezależne od implementacji.

Są to testy bardzo wysokiego poziomu, które sprawdzają wyniki i zachowania, a nie elementy wewnętrzne.

Używamy deterministycznego testu interfejsu, czyli testów, które wchodzą w interakcję z informacjami na ekranie publicznym, podobnie jak użytkownik.

W takich przypadkach używamy UI Automatora lub testów Compose UI, ale mamy też specjalne skrypty, które sprawdzają niektóre granice systemu zewnętrznego, np. czy wywołanie sieciowe zawierało właściwe dane lub czy właściwe dane zostały zapisane w bazie danych bez znajomości wewnętrznych pomocników lub obiektów DAO.

Oprócz tego przeprowadzamy kontrole statyczne, aby sprawdzić uprawnienia w pliku manifestu lub czy biblioteka znajdowała się w plikach kompilacji itp.

Mamy też testy hybrydowe, które są połączeniem tych skryptów i testów interfejsu.

To przykład jednego z testów hybrydowych.

Są one przechowywane poza emulatorem.

To jest test procesu uwierzytelniania za pomocą jednorazowego hasła SMS. Skrypt musi najpierw obliczyć hasz aplikacji, aby móc prawidłowo wysłać SMS-a do emulatora, a następnie uruchamia testy UI Automator i przekazuje losowo wygenerowane hasło jednorazowe, którego wymaga, oraz wysyła SMS-a do emulatora za pomocą polecenia adb.

Test sprawdza tylko, czy dane wejściowe miały prawidłowy numer.

To wszystko.

Nie ma żadnego powiązania z implementacją, tylko testy, które sprawdzają, czy proces działa.

Drugi problem z ocenianiem polegał na tym, że nasze zadania wymagają multimodalności.

Agenci muszą utworzyć interfejs użytkownika lub otrzymują od nas makiety projektu.

Najłatwiej jest to zrobić za pomocą testów zrzutów ekranu.

Od początku wiedzieliśmy, że progi zrzutów ekranu będą musiały być wyższe, ale i tak nie udało się ich osiągnąć.

Wypróbowaliśmy kilka różnych algorytmów porównywania pikseli, ale nie poradziły sobie z takimi rzeczami jak szum na poziomie systemu, gdy pasek stanu emulatora był inny, ikona baterii, a nawet sprzętowe wygładzanie czcionek.

Jednak nie sprawdzały się też w przypadku prawidłowych implementacji, w których dopełnienia były niewielkie, nieco inne, lub występowały niewielkie różnice w odcieniach. Interfejs mógł być całkowicie poprawny, ale tło miało nieco inny odcień, co powodowało, że algorytmy porównujące piksele nie działały.

W tym celu wykorzystaliśmy i stworzyliśmy multimodalny model LLM, który porównuje pary zrzutów ekranu, tak jak w testach zrzutów ekranu, i podaje nam wynik, ale także strukturalne uzasadnienie wyniku.

Przekazujemy mu też zrzuty hierarchii ułatwień dostępu, które sprawdzają, czy struktura jest prawidłowa i czy zachowana jest równość strukturalna.

Przetestowaliśmy to empirycznie w wielu próbach i zauważyliśmy, że zapewnia to wysoką spójność i pozwala uniknąć problemów, które wcześniej występowały.

Mieliśmy więc dobry sposób na weryfikację obrazów i zachowań, i zauważyliśmy, że agenci próbowali wszystko sfałszować.

Śmiało.

Tomáš Mlynarič

Zaczyna się prosto.

Obecnie agenci mówią: „OK.

Mam zadanie.

Spójrzmy na GitHuba.

Znajdźmy rozwiązania”.

To jest pierwsza rzecz, którą robią.

Próbują wyszukać prawidłowe rozwiązanie w GitHubie lub w internecie, dlatego musimy zachować kod źródłowy jako zamknięty i nie możemy go upublicznić.

Ale to było proste.

W niektórych próbach, gdy wszystko przebiegało bez problemów, agent mówił: „Wspaniały triumf!”.

Tak.

To ciekawe. Co się okazało?

Ale przyjrzeliśmy się bliżej trajektorii i stwierdziliśmy: „Nie damy rady.

Co się stanie, jeśli zmienię próg na 80% testu zrzutu ekranu?”.

// AuthFlowScreenshotTests.kt

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

I myślisz: „Tak, triumf, wszystko się udaje”.

Tak, ale testy zrzutów ekranu są bezużyteczne.

Nie był to jednak najbardziej zaawansowany atak.

W niektórych przypadkach, na przykład w aplikacji do konwersji Flutter, agent próbował i próbował utworzyć aplikację na Androida, ale nie wiedział, co zrobić.

Zrobili więc zrzut ekranu, który im daliśmy, i umieścili go jako element rysowalny w tle.

Teraz jest to jak zdanie testu zrzutu ekranu.

Hura!

Ale testy interfejsu nadal się nie udają, więc programista decyduje się na umieszczenie na wierzchu niewidocznej warstwy nakładki z przyciskami, tekstami i tagami testowymi – wszystkim, czego potrzebujemy.

Teraz wszystko jest zielone.

Niesamowite!

Dobra robota”.

To nie jest tak, że jest tylko jedna, która jest naprawdę dobra.

Mamy więc zadanie migracji z Javy do Kotlina, w którym agent musi w zasadzie przeprowadzić migrację z Javy do Kotlina, prawda?

Nie udało im się go zbudować.

It's, like, still failing something, so the agent thought, "All right, I'm just going to take the compiled classes from Java, and I'll put it into a JAR, and then I just add it to the build files as a regular library.

Teraz wszystkie testy przechodzą, ale mamy kontrole statyczne, które sprawdzają pliki Java, więc po prostu je usunę”.

Usuwam pliki Java, wszystko jest na zielono, ale Kotlin nadal nie działa, więc mówią: „Dobra, usunę zbiór źródeł Kotlina i teraz wszystko działa.

Świetnie”.

Nie wiem, czy to w ogóle jest oszustwo.

To naprawdę kreatywne.

Aby temu zapobiec, stworzyliśmy wykrywacz oszustw, który ma 3 poziomy ochrony.

Analizujemy drzewo interfejsu, stosujemy różne rozmiary ekranu, aby tło było zniekształcone, i widzimy je.

Resetujemy też testy i sprawdzamy, czy nie doszło do manipulacji, aby nie można było zmienić progów.

Mamy też LLM-as-a-Judge, który sprawdza trajektorie i rzeczywiste dane wyjściowe agenta, aby wykryć nietypowe zachowania.

Jeśli coś się stanie, po prostu mówimy: „Okej, od razu niepowodzenie”.

Tomáš Mlynarič

Teraz nie ma już żadnych skrótów, nie trzeba szukać rozwiązań, nie ma niestabilnych testów jednostkowych ani fałszywego interfejsu.

Jak wyglądają liczby, gdy zmuszamy agentów do stworzenia aplikacji na Androida?

W poniedziałek, gdy opublikowaliśmy post na blogu, liczby wyglądały tak.

Nawet najlepszy agent wykonuje tylko około 40% naszych zadań, a większość agentów granicznych osiąga wynik między 20% a 40%.

To dobrze dla nas jako autorów testu porównawczego, ponieważ zapewnia to odpowiednią równowagę – zadania, które udostępniliśmy, mają wartość w prawdziwym świecie, ale jest też dużo miejsca na rozwój.

Przyjrzyjmy się wynikom.

Możemy teraz przyjrzeć się wynikom z różnych perspektyw.

Możemy przyjrzeć się niektórym statystykom, które już znaleźliśmy.

Pierwsze pytanie, które może się pojawić, gdy spojrzysz na wykres, brzmi: ile kosztuje uruchomienie tego agenta?

Firmy zajmujące się AI zwykle podają koszt tokena, w niektórych przypadkach tokena wejściowego, wyjściowego, a może tokena pamięci podręcznej.

Może to być argument, który pomoże Ci podjąć decyzję.

Możemy jednak spojrzeć na to z innej perspektywy.

Możemy narysować ten sam wykres w przestrzeni 2D ze średnim kosztem zadania, a nie tokena, czyli ile kosztowało zadanie w porównaniu ze współczynnikiem zdawalności.

Tutaj widzimy, że niektóre modele są znacznie bardziej gadatliwe.

Zużywają znacznie więcej czasu lub tokenów na zadanie, podczas gdy inne modele wykonują więcej zadań przy mniejszych kosztach.

Jeśli jednak dodamy do tego samego wykresu cenę za token, zobaczymy, że to, co firmy zajmujące się AI naprawdę reklamują, nie odpowiada temu, co faktycznie płacisz za zadanie.

Jak widać, agent z najlepszym wskaźnikiem zdawalności jest jednym z najtańszych pod względem kosztu tokena, ale najdroższym pod względem kosztu zadania.

Inne agenty z dokładnie taką samą ceną tokena wykonują około 30% zadań, ale są 15 razy tańsze.

Cena tokena nie jest więc danymi.

Niektóre modele bardziej analizują kod, przebudowują go i ponownie uruchamiają, a każdy krok zużywa więcej tokenów.

Nie należy więc patrzeć tylko na cenę za token.

Wybierz model, spójrz na rzeczywiste dane, np. użyj go w swoim przypadku, lub sprawdź w Android Bench, które modele faktycznie zużywają najwięcej tokenów na zadania.

Niektóre wymagają więcej kroków, chociaż są tańsze za token.

Jest jednak jeszcze jeden aspekt tego pytania.

To ten sam wykres, ale możemy też sprawdzić, ile czasu zajmuje agentom wykonanie tego zadania.

Widzimy, że agenci z najwyższym współczynnikiem zdawalności mogą być nawet najwolniejsi.

Widzimy, że niektóre zadania zajmują prawie 2 godziny.

Przebudowują i testują, aż zadziała.

Tak, dają najlepszy współczynnik zdawalności, ale też zajmują najwięcej czasu.

Niektóre tańsze agenty nadal potrzebują około półtorej godziny na zadanie, ale nie dają lepszych wyników.

Inni agenci kończą je w mniej niż 20 minut i nadal rozwiązują ponad 1/4 zadań.

Małe, lekkie modele są zwykle szybsze i tańsze, ale częściej zawodzą w przypadku trudnych zadań.

Wniosek jest taki, że nie ma jednego najlepszego modelu.

To zależy od tego, pod kątem czego optymalizujesz.

Czy jest to współczynnik zdawalności?

Czy chodzi o koszt?

Czy chodzi o czas oczekiwania?

W takim przypadku, w zależności od rodzaju wykonywanej pracy, jeśli nie pracujesz nad tak trudnymi zadaniami, rozważ użycie szybszych modeli, które wykonują zadania taniej i szybciej.

Koszt i szybkość pokazują jednak tylko, jak działają agenty, ale nie dlaczego nie udaje im się wykonać większości prób.

Sprawdziliśmy więc nieudane próby i zauważyliśmy, że agenci często kończyli pracę przedwcześnie.

Są przekonani, że to już koniec.

Zadanie wykonane.

OK, idę do domu.

Jednak, jak wspomniano, w pakiecie zadań agenci otrzymują tylko instrukcje i stan początkowy.

Nie widzą testów.

Nie widzą pakietu weryfikacyjnego.

Zadaliśmy sobie pytanie: co się stanie, jeśli po prostu pokażemy im testy?

Przeprowadziliśmy więc eksperyment i stworzyliśmy otwarty wariant testowy tego samego zadania, w którym agent od razu otrzymał zestaw testów weryfikacyjnych, które zakończyły się niepowodzeniem.

Teraz przeprowadzali testy iteracyjnie.

Mogą sprawdzać błędy i ulepszać kody w pętli informacji zwrotnych.

Odkryliśmy, że gdy agenci widzą testy, bardziej się starają i dłużej pracują.

W przypadku otwartych sesji liczba tur była o 25% większa, a czas działania Agent Runtime wynosił 40%.

Zamiast tego poświęcali prawie 30 minut na zadanie, uruchamiając i naprawiając nieudane testy, ponieważ nie debugowali na oślep.

Dzięki temu widzą dokładnie, co się nie udało, a wskaźnik zdawalności wzrasta o prawie 50 punktów procentowych.

Jak już wspominałem, ten dodatkowy wysiłek poprawia średni współczynnik zdawalności.

Jednak w końcu pojawiły się nowe modele graniczne, które szybko nasyciły ten otwarty wariant.

Cóż, współczynnik zdania wynosi prawie 90%.

Dlatego jako główny wskaźnik porównawczy zachowaliśmy wariant testu zamkniętego z zamkniętym wyszukiwaniem.

Nadal jednak bardzo interesujące jest to, że modele są lepsze, gdy wiedzą, na podstawie czego są oceniane.

Tomáš Mlynarič

Pozwoliło nam to jednak uzyskać więcej informacji o agentach.

Możemy na przykład sprawdzić, jak modele testują własne wyniki.

Na wykresie widać, że modele graniczne piszą coraz lepsze testy i mają wyższe wskaźniki zdawalności.

Niektóre inne modele są zbyt pewne siebie, twierdzą, że mogą to zrobić, i nie przeprowadzają testów.

Czasami są jeszcze dobre.

Jeśli więc używasz modeli, które nie radzą sobie dobrze z testowaniem, możesz im pomóc, przekazując im lepsze umiejętności testowania lub konkretne instrukcje dotyczące pisania testów.

Ale korelacja nie oznacza przyczynowości, prawda?

Musimy przeprowadzić kontrolowany eksperyment.

nadal musimy przeprowadzić, aby sprawdzić, czy prośba o lepsze testy rzeczywiście poprawia wynik.

Przeprowadziliśmy jednak eksperyment na drugiej połowie testów na Androidzie, który polegał na tym, że agenci używali emulatora.

Na początku, w naszym teście porównawczym, nie wspomnieliśmy o emulatorze.

Zakładaliśmy, że agenci powinni to rozgryźć, prawda?

W rezultacie prawie żaden z nich nie uruchomił emulatora.

Jak już wspominałem, testy interfejsu są bardzo ważne w naszych testach porównawczych, a bez emulatorów nie można ich przeprowadzić.

Wszystkie te firmy nie radziły sobie z bardzo prostą rzeczą.

Mamy więc dylemat.

Czy powinniśmy powiedzieć agentom, że muszą używać emulatora, i ryzykować, że uzyskają wyższe wyniki, czy też nic nie mówić i liczyć na to, że sami na to wpadną?

Naszym celem było jednak stworzenie sprawiedliwego testu porównawczego, który mierzy umiejętności kodowania i rozwiązywania problemów na Androidzie.

Nie chcemy mierzyć na przykład dziwnych zachowań środowiska.

Wybraliśmy więc rozwiązanie pośrednie.

Powiedzieliśmy im, jak uruchomić emulator, ale nie wspomnieliśmy, czy go używać, czy nie.

W końcu uruchomienie emulatora nie jest tym, co chcemy przetestować.

Następnie zmierzyliśmy efekt tej instrukcji emulatora.

Zauważyliśmy, że gdy daliśmy im instrukcje, agenci znacznie częściej uruchamiali emulator i przeprowadzali testy interfejsu, co niestety miało duży wpływ na odsetek pozytywnych wyników.

Pozwoliło nam to też sprawdzić ich rzeczywiste błędy i problemy z kodowaniem, a nie tylko błędy w nieuruchomionym emulatorze.

Podsumowując, precyzja prompta nadal ma duże znaczenie. Jeśli projektujesz własne testy porównawcze lub oceny, musisz przetestować to, co jest ważne w Twoim przypadku.

Na przykład: oceniasz wydajność tokenów, umiejętności lub narzędzia. Najpierw musisz zacząć od zaliczenia oceny, wprowadzić zmianę pod kątem wydajności, a następnie sprawdzić, czy nadal przechodzi ona z mniejszą liczbą tokenów.

W przeciwnym razie zmienisz zbyt wiele zmiennych naraz i nie będziesz wiedzieć, czy to Twoja zmiana przyniosła poprawę.

Tomáš Mlynarič

Wróć do tabeli wyników.

Jak już wspominałem, najlepsze modele przechodzą około 40% zadań, a wskaźnik zaliczenia wymaga zaliczenia wszystkich testów.

W przeciwnym razie zadanie nie zostanie wykonane.

Pytanie brzmi: czy agenci nie wygenerowali niczego przydatnego przez pozostałe 60% czasu?

Nie, już prawie tam są.

Aby pokazać, jak blisko działających rozwiązań był agent, obliczamy też współczynnik realizacji, czyli częściowy wynik.

Jest to ważony wynik w 4 kategoriach: spójność wizualna, funkcjonalność, prawidłowe działanie, wymagania dotyczące konkretnych zadań i testy regresji.

Jak widać, modele o niższych pozycjach w rankingu są w stanie wykonać około połowy pracy, podczas gdy modele graniczne są w stanie wykonać średnio prawie 80% zadań, ale przechodzą tylko 40%.

Przeprowadziliśmy więc eksperyment dotyczący konwersji z Fluttera na Androida, aby sprawdzić, co się dzieje.

Dlatego ponownie obliczaliśmy współczynnik realizacji co kilka kroków agenta i zauważyliśmy te same wzorce we wszystkich modelach granicznych.

Około 140 kroków zajęło im osiągnięcie średniego wyniku na poziomie prawie 90%. Następnie poświęcili kolejne 90 kroków, czyli prawie 40% czasu, na próbę osiągnięcia 100%, ale udało im się uzyskać tylko 1–2% więcej.

Sądzimy, że odzwierciedla to obecny rozwój agentów, w którym niedoświadczeni deweloperzy lub użytkownicy widzą, że aplikacja jest gotowa.

Wszystko jest renderowane.

The input kind of worked.

Być może nie ma żadnych awarii.

Jednak gdy starszy inżynier spojrzy na kod, widzi wiele wad: problemy z architekturą, błędy cyklu życia i inne.

Tomáš Mlynarič

Na koniec podsumujmy Android Bench, czyli naszą pracę 2.0.

W porównaniu z wersją 1.0 mamy teraz tylko 30 zadań i jest to celowe.

Zamiast pojedynczych poprawek błędów i małych łatek mamy kompletne ekrany, migracje wielu modułów i konwersje całych aplikacji.

Poprawki są teraz o rząd wielkości większe i obejmują dziesiątki plików.

Mamy też multimodalne testy interfejsu.

Agenci muszą działać dłużej i pracować znacznie ciężej.

Jeśli porównamy go z innymi testami porównawczymi modeli granicznych, zobaczymy, że nasz test wymaga znacznie większych zmian w kodzie.

Jest on wolny od zanieczyszczeń, ponieważ większość zadań jest pisana od podstaw, a nadal jest dużo miejsca na rozwój.

Jak powiedziałam na początku, kilka miesięcy w świecie AI to cała wieczność. W końcu każdy test porównawczy osiąga maksymalny poziom i się nasyca.

Gdy to się stanie, mam nadzieję, że będziemy dążyć do jeszcze trudniejszych i bardziej złożonych zadań, które będą odpowiadać tej erze i temu stanowi AI.

Teraz użyj Android Bench jako kompasu, aby porównać modele i zestawy oraz uzyskać pewne informacje.

A gdy będziesz gotowy(-a) na więcej, zastosuj te same zasady testów porównawczych i oceny do własnych baz kodu i przepływów pracy, ponieważ nic nie przebije pomiaru AI na kodzie, nad którym faktycznie pracujesz.

Dzięki temu nie musisz już mieć nadziei, że AI dobrze wykonała zadanie, tylko masz pewność, że tak jest.

W imieniu całego zespołu Android Bench dziękuję za uwagę.