論文の概要: AppEval: A Unified Benchmark for LLM-Based Mobile Application Repair in ArkTS, Swift, and Kotlin
- arxiv url: http://arxiv.org/abs/2608.18588v1
- Date: Wed, 19 Aug 2026 06:30:34 GMT
- ステータス: 翻訳完了
- システム内更新日: 2026-08-20 20:13:55.306417
- Title: AppEval: A Unified Benchmark for LLM-Based Mobile Application Repair in ArkTS, Swift, and Kotlin
- Title（参考訳）: AppEval: ArkTS、Swift、KotlinのLLMベースのモバイルアプリケーション修正のための統一ベンチマーク
- Abstract要約: AppEvalは、モバイルアプリケーションの修復のためのベンチマークとネイティブツールチェーン評価フレームワークである。
私たちは、HarmonyOS/ArkTS、iOS/Swift、Android/Kotlinにわたるモバイルアプリケーションの修復のための、ベンチマークとネイティブツールチェーン評価フレームワークであるAppEvalを紹介します。
- 参考スコア（独自算出の注目度）: 25.775485279136763
- License: http://creativecommons.org/licenses/by/4.0/
- Abstract: Repository-level LLM agents are typically evaluated on projects whose tests run on the build host. It remains unclear whether their repairs survive the mobile build-install-launch-test boundary, where a missing SDK, offline device, or pre-assertion crash can be mistaken for a program failure. We present AppEval, a benchmark and native-toolchain evaluation framework for mobile application repair across HarmonyOS/ArkTS, iOS/Swift, and Android/Kotlin. Each task separates a hidden behavior test from the reference production fix and is accepted only when the same installed-app target reaches an assertion failure on the defective revision and passes after the fix; infrastructure failures remain a distinct outcome. A common schema maps this contract to each platform's build system, runtime, and test runner. The audited Android partition contains 200 accepted instrumentation tasks from 24 independently buildable repositories. On these tasks, five agents achieve Pass@1 between 22.00% and 90.50%, a 68.50-percentage-point spread under the same dynamic oracle. These results show that mobile repair performance depends strongly on the evaluated agent while demonstrating why runtime-aware acceptance is necessary for meaningful comparison. The quantitative findings in this paper are Android-specific; audited iOS and HarmonyOS results are required before drawing cross-platform generalization conclusions.
- Abstract（参考訳）: リポジトリレベルのLLMエージェントは通常、ビルドホスト上でテストを実行するプロジェクトで評価される。
修正がモバイルビルド-インストール-起動-テストバウンダリを生き残るかどうかは不明だが、SDKの欠如、オフラインデバイス、あるいは事前起動時のクラッシュがプログラムの失敗と誤認される可能性がある。
私たちは、HarmonyOS/ArkTS、iOS/Swift、Android/Kotlinにわたるモバイルアプリケーションの修復のための、ベンチマークとネイティブツールチェーン評価フレームワークであるAppEvalを紹介します。
各タスクは、隠れた動作テストと参照されたプロダクション修正を分離し、同じインストール済みのアプリケーションターゲットが欠陥修正のアサーション障害に達した場合にのみ受け入れ、修正後にパスする。
一般的なスキーマは、このコントラクトを各プラットフォームのビルドシステム、ランタイム、テストランナにマップする。
監査済みのAndroidパーティションには、24の独立したビルド可能なリポジトリから200の承認されたインスツルメンテーションタスクが含まれている。
これらのタスクでは、5つのエージェントが22.00%から90.50%の間でPass@1を達成する。
これらの結果から,モバイル補修性能は評価エージェントに強く依存し,実行時認識の受け入れが意味のある比較になぜ必要かを示した。
監査されたiOSとHarmonyOSの結果は、クロスプラットフォームの一般化の結論を出す前に必要である。
関連論文リスト
- SWE-Gate: Passing Functional Tests Is Not Enough for Software Engineering Agents [63.65682461568621]
ソフトウェアエンジニアリングエージェントのためのリポジトリレベルのベンチマークであるSWE-Gateを導入し、機能的正当性とともにレビュー制約コンプライアンスを明示的に評価する。
SWE-Gateは、実際のプルリクエストレビューコメントからレビュー制約を導き、これらの制約に関するリポジトリレベルの修復インスタンスを合成する。
各インスタンスは、非準拠およびゴールドパッチとともに、機能テストと制約テストの分離を提供し、イシュー解決能力とレビュー制約コンプライアンスの明確な分離を可能にする。
論文 参考訳（メタデータ） (2026-09-03T17:53:34Z) - DragonCrawl: A Generative, Intent-Based Framework for Scalable Mobile End-to-End Testing [3.0812793454543375]
DragonCrawlは、継続的回帰テストのためのAI駆動のモバイルテストシステムである。
コードの変更毎に特定のユーザフローを検証し、重要な機能を壊すコミットをブロックする。
iOSで91.6%、Androidで92.2%、CI/CDパイプラインで継続的に実行される1013の自動化テストで91.6%のパスレートを達成した。
論文 参考訳（メタデータ） (2026-07-30T18:17:31Z) - PhyAgentOS: A Self-Evolving Operating System for Embodied Agents with Decoupled Cognitive Planning and Physical Execution [49.776611937968]
我々は、スケジューリング、検証、メモリ、ベンチマーク、安全性をシステムレベルのサービスとして提供するPhyAgentOSを紹介します。
セッション中心のセッションは、スケジューリング、互換性、監督された実行、エビデンス収集、受け入れの最小単位として、アクションではなくセッションを扱う。
SessionVerifierは、実行終了とセマンティックタスク完了を、成功、失敗、または再計画のエビデンスに基づいて判断する。
ベンチマークはデプロイメントセッションと検証パスを再利用するので、結果は実際の実行に遡る。
論文 参考訳（メタデータ） (2026-07-18T04:46:53Z) - DebugRepair: Enhancing LLM-Based Automated Program Repair via Self-Directed Debugging [20.747648291211338]
DebugRepairは自動プログラム修復のためのセルフダイレクトフレームワークである。
中間ランタイムエビデンスによるパッチ改善を改善する。
15のアプローチに対して最先端のパフォーマンスを達成する。
論文 参考訳（メタデータ） (2026-04-21T10:11:59Z) - Android Instrumentation Testing in Continuous Integration: Practices, Patterns, and Performance [0.0]
オープンソースAndroidアプリが継続的インテグレーションでインスツルメンテーションテストを実行する方法について検討する。
CIでインスツルメンテーションテストを実行するのは10人に1人だけです。
テストカバレッジを拡大するために、しばしばアプローチを変更します。
論文 参考訳（メタデータ） (2026-04-03T20:24:19Z) - Runtime Execution Traces Guided Automated Program Repair with Multi-Agent Debate [8.424102114588559]
自動プログラム修復(APR)は複雑なロジックエラーとサイレント障害に悩まされる。
現在のLLMベースのAPRメソッドは主に静的であり、ソースコードと基本的なテスト出力に依存している。
我々は、パッチ検証のための共有制約としてランタイム事実を活用するマルチエージェントフレームワークであるTraceRepairを提案する。
論文 参考訳（メタデータ） (2026-04-03T02:23:25Z) - MobileDev-Bench: A Comprehensive Benchmark for Evaluating Language Models on Mobile Application Development [1.4302803674538154]
Android Native(Java/Kotlin)、React Native(TypeScript)、Flutter(Dart)にまたがる18のプロダクションモバイルアプリケーションから収集された384の現実世界の課題解決タスクからなるベンチマークであるMobileDev-Benchを紹介した。
各タスクは、実行可能テストパッチと開発者が報告した問題にペアリングし、モバイルビルド環境内でモデル生成の修正を完全に自動検証することを可能にする。
GPT-5.2, Claude Sonnet 4.5, Gemini Flash 2.5, Qwen3-Coder の4つの最先端コード対応LCMの評価
論文 参考訳（メタデータ） (2026-03-26T02:31:03Z) - DEP: A Decentralized Large Language Model Evaluation Protocol [51.3646001384887]
分散評価プロトコル(Decentralized Evaluation Protocol, DEP)は、分散化されているが統一され、標準化された評価フレームワークである。
ユーザ、LLM、ベンチマークを分離することで、DEPはモジュラー、プラグ・アンド・プレイの評価を可能にする。
我々は,ブレークポイントの再開,同時要求,混雑制御などの機能をサポートするプロトコル互換ツールキットであるDEP Toolkitを開発した。
論文 参考訳（メタデータ） (2026-03-01T16:10:16Z) - Outrunning LLM Cutoffs: A Live Kernel Crash Resolution Benchmark for All [57.23434868678603]
Live-kBenchは、新たに発見されたカーネルバグのエージェントをスクラップし、評価するセルフ進化ベンチマークの評価フレームワークである。
kEnvは、カーネルのコンパイル、実行、フィードバックのためのエージェントに依存しないクラッシュ解決環境である。
kEnvを用いて3つの最先端エージェントをベンチマークし、最初の試行で74%のクラッシュを解決したことを示す。
論文 参考訳（メタデータ） (2026-02-02T19:06:15Z) - DoVer: Intervention-Driven Auto Debugging for LLM Multi-Agent Systems [48.971606069204825]
DoVerは、大規模言語モデル(LLM)ベースのマルチエージェントシステムのための介入駆動デバッグフレームワークである。
ターゲットの介入を通じて、アクティブな検証によって仮説生成を増強する。
DoVerは失敗試験の18～28%を成功させ、最大16%のマイルストーンを達成し、失敗仮説の30～60%を検証または否定する。
論文 参考訳（メタデータ） (2025-12-07T09:23:48Z) - Where LLM Agents Fail and How They can Learn From Failures [62.196870049524364]
大規模言語モデル(LLM)エージェントは、複雑なマルチステップタスクの解決において有望であることを示す。
単一ルート原因エラーがその後の決定を通じて伝播する、障害のカスケードに対する脆弱性を増幅する。
現在のシステムは、モジュール的で体系的な方法でエージェントエラーを包括的に理解できるフレームワークを欠いている。
AgentErrorTaxonomyは、メモリ、リフレクション、計画、アクション、システムレベルの操作にまたがる障害モードのモジュール分類である。
論文 参考訳（メタデータ） (2025-09-29T18:20:27Z) - ProjectTest: A Project-level LLM Unit Test Generation Benchmark and Impact of Error Fixing Mechanisms [48.43237545197775]
単体テスト生成はLLMの有望かつ重要なユースケースとなっている。
ProjectTestは、Python、Java、JavaScriptをカバーするユニットテスト生成のためのプロジェクトレベルのベンチマークである。
論文 参考訳（メタデータ） (2025-02-10T15:24:30Z)
関連論文リストは本サイト内にある論文のタイトル・アブストラクトから自動的に作成しています。
指定された論文の情報です。
本サイトの運営者は本サイト（すべての情報・翻訳含む）の品質を保証せず、本サイト（すべての情報・翻訳含む）を使用して発生したあらゆる結果について一切の責任を負いません。