Do LLMs Need to See Everything? A Benchmark and Study of Failures in LLM-driven Smartphone Automation using Screentext vs. Screenshots

Probleemstelling

Met de opkomst van Large Language Models (LLMs) zijn mobiele agenten ontwikkeld die complexe taken op smartphones kunnen automatiseren door menselijke interacties te simuleren. Ondanks hun potentie lijden deze agenten echter aan lage nauwkeurigheid, misinterpretatie van gebruikersintenties en frequente mislukkingen bij uitdagende taken.
Er zijn drie kernproblemen geïdentificeerd:

1. Gebrek aan inzicht in falen: Er is weinig onderzoek gedaan naar waarom en waar deze modellen falen in dagelijkse smartphone-scenario's.
2. Privacy en Invasiviteit: Veel agenten vertrouwen op screenshots als input, wat privacyrisico's met zich meebrengt (bijv. het onthullen van gevoelige berichten). Het is onduidelijk of screenshots echt nodig zijn of dat tekstuele representaties (zoals de UI-tree) volstaan.
3. Beperkte HCI-benchmarks: Bestaande benchmarks focussen vaak op reproduceerbaarheid en gecontroleerde omgevingen, maar missen de nuance van "in-the-wild" fouten die voortkomen uit dynamische UI's, ontbrekende toegankelijkheidsmetadata en privacy-beperkingen.

Methodologie

De auteurs introduceerden DailyDroid, een nieuw benchmark- en evaluatiekader om systematisch de prestaties en fouten van LLM-gestuurde mobiele agenten te analyseren.

1. DailyDroid Benchmark:

• Opzet: 75 taken verdeeld over 25 populaire Android-apps.
• Categorieën: Productiviteit & Tools, Nuttige hulpmiddelen & Systeemtaken, Informatie-toegang, Media & Entertainment, en Communicatie.
• Moeilijkheidsgraden: Drie niveaus (Eenvoudig, Middel, Moeilijk) gebaseerd op interactiecomplexiteit (bijv. aantal schermen, besluitvorming, afhankelijkheid van systeemstatus).
• Doel: Het nabootsen van realistische, dagelijkse smartphone-gebruiksscenario's met een focus op HCI-gerelateerde fouten.

2. Experimenteel Ontwerp:

• Modellen: Twee OpenAI-modellen werden getest: GPT-4o (baseline) en o4-mini (geavanceerd redenerend model).
• Input Modaliteiten:
  • Text-only (Screentext): Alleen de gestructureerde UI-tree (HTML-achtige representatie van de Android Accessibility API).
  • Multimodaal (Screentext + Screenshot): Combinatie van de UI-tree en een visuele screenshot van het scherm.
• Framework: Het onderzoek gebruikte een aangepaste versie van AutoTask, een open-source Android-agent framework. De agenten kregen toegang tot een Android-emulator (Pixel XL, Android 11.0).
• Proces: Elke taak werd uitgevoerd in een lus van waarnemen, plannen, handelen en reflecteren, met een maximum van 10 stappen per run. In totaal werden 300 runs uitgevoerd (75 taken × 2 modaliteiten × 2 modellen).

3. Evaluatiemetrics:

• Succes: Binair succes/falen.
• Foutanalyse: Inductieve codering (Grounded Theory) om fouten te categoriseren in Systeem-niveau (infrastructurele blokkades) en Agent-niveau (LLM-redeneringsfouten).
• Efficiëntie: Tijd (totaal, API-wachttijd, effectief), stap-aantal, token-gebruik en kosten.

Belangrijkste Bijdragen

1. DailyDroid Benchmark: Een gestandaardiseerd, herhaalbaar evaluatiekader specifiek ontworpen om dagelijkse mobiele taken en de bijbehorende foutpatronen te bestuderen, inclusief een gedetailleerde "Failure Handbook".
2. Vergelijking van Modaliteiten: Een systematische analyse van de trade-off tussen privacy (text-only) en prestaties (multimodaal), waarbij wordt onderzocht of screenshots echt noodzakelijk zijn voor succes.
3. Foutenhandboek (Failure Handbook): Een gestructureerde taxonomie van fouten die inzicht geeft in waarom agenten falen, onderverdeeld in systeem- en agent-niveau fouten.
4. Ontwerpimplicaties: Aanbevelingen voor app-ontwikkelaars, UI-designers en LLM-architecten om de betrouwbaarheid van mobiele automatisering te verbeteren.

Resultaten

1. Prestaties en Succespercentages:

• De succespercentages waren over het algemeen laag (rond de 30%), wat aangeeft dat mobiele automatisering nog in een vroeg stadium verkeert.
• o4-mini presteerde iets beter dan GPT-4o (31,3% vs 29,3% succes), maar was aanzienlijk goedkoper in tokens.
• Multimodale input leverde slechts een marginaal hoger succespercentage op (ongeveer 4-5% verbetering ten opzichte van text-only), maar veroorzaakte een aanzienlijke stijging in kosten (tot 26x duurder) en API-wachttijden door de extra tokens van screenshots.

2. Foutanalyse (Failure Handbook):

• Systeem-niveau fouten (ca. 40-43%): Dit was de belangrijkste oorzaak van mislukkingen.
  • UI Retrieval: De agent kon de volledige UI niet ophalen (bijv. ontbrekende elementen in de Accessibility API).
  • UI Parsing: De agent kon de UI wel ophalen maar niet interpreteren (bijv. verborgen zoekbalken, onduidelijke labels).
  • UI Logic: De interface was onlogisch of verwarrend, zelfs voor mensen.
• Agent-niveau fouten (ca. 25-30%):
  • LLM Predictie: De agent begreep het scherm maar voerde de verkeerde actie uit (bijv. verwarren van velden).
  • Reflectie: De agent herkende niet dat een taak voltooid was of faalde bij het corrigeren van eerdere fouten.
  • Maximale stappen: Geavanceerde modellen (o4-mini) bereikten vaker de staplimiet omdat ze vaker terugkeerden (backtracking) om fouten te corrigeren, wat leidde tot inefficiëntie.

3. Modaliteit en Privacy:

• Soms was de screenshot cruciaal voor het herkennen van visuele cues (bijv. een rode "hang-up" knop, leesvoortgang in een boek-app, of AI-overzichten in Chrome) die ontbraken in de tekstuele UI-tree.
• Echter, in veel gevallen (vooral bij systeemfouten) hielp de screenshot niet omdat de onderliggende UI-elementen simpelweg niet toegankelijk waren via de API. Dit suggereert dat het verbeteren van UI-toegankelijkheid belangrijker is dan het toevoegen van screenshots.

Betekenis en Conclusie

Het paper concludeert dat LLMs niet per se "alles" (screenshots) hoeven te zien om effectief te zijn, maar dat de huidige beperkingen in UI-toegankelijkheid de grootste bottleneck vormen.

• UI-toegankelijkheid is kritiek: Als de UI-tree onvolledig is of elementen ontbreken, faalt de agent ongeacht of er een screenshot is. De kloof tussen visuele realiteit en geparseerde data is het grootste probleem.
• Privacy-afweging: Gezien de marginale prestatiewinst van screenshots en de hoge kosten/privacyrisico's, zou text-only input (via Accessibility API) de voorkeur moeten krijgen, tenzij visuele cues essentieel zijn voor de taak.
• Toekomstige richtingen:
  • App-ontwikkelaars moeten stabiele locators (android:id) en duidelijke labels implementeren.
  • Er is behoefte aan nieuwe standaarden (zoals Model Context Protocol) voor de communicatie tussen apps en LLMs.
  • Frameworks moeten de staplimieten aanpassen voor redenerende modellen om hun zelf-correctiecapaciteiten te benutten zonder voortijdig te stoppen.

Kortom, de studie verschuift de focus van het "slimmer maken" van de LLM naar het "toegankelijker maken" van de mobiele interface en het begrijpen van de fundamentele beperkingen van huidige input-modaliteiten.