Thông tin chi tiết về việc tạo mã tác nhân từ Android Bench

Tomáš Mlynarič

Chào mọi người.

Hãy bắt đầu thôi.

Vào tháng 3, chúng tôi đã ra mắt Android Bench, tập dữ liệu và bảng xếp hạng của chúng tôi về việc đo lường LLM trong các nhiệm vụ phát triển Android.

Kể từ đó, chúng tôi đã chạy thử nghiệm này trên nhiều mô hình mới.

Và mới tháng trước, chúng tôi đã phát hành Android Bench 2.0.

Mặc dù chỉ mới vài tháng trôi qua, nhưng trong thế giới AI, khoảng thời gian đó dường như dài vô tận.

Tôi là Tomáš. Tôi sẽ chia sẻ hành trình của Android Bench và cách chúng tôi đạt được thành quả như hiện tại.

Hãy bắt đầu với phiên bản 1.0.

Trong phiên bản 1.0, chúng tôi đã lấy các vấn đề thực tế từ các kho lưu trữ nguồn mở.

Chúng tôi đã lọc các dự án trên GitHub có vấn đề, yêu cầu gộp giải quyết các vấn đề đó và kiểm thử để xác minh giải pháp.

Chúng tôi chia các yêu cầu kéo thành các nhóm nhiệm vụ cho các mô hình AI.

Vấn đề trên GitHub trở thành hướng dẫn hoặc câu lệnh cho mô hình và chúng tôi đã đưa chúng vào trạng thái trước khi có PR.

Sau khi mô hình tạo ra một số kết quả, chúng tôi đã thực hiện các bài kiểm thử và áp dụng chúng cho kết quả đầu ra, từ đó cho ra kết quả đạt hoặc không đạt.

Một lần AI cố gắng giải quyết vấn đề được gọi là một lần thử.

Chúng ta cũng có thể so sánh dựa trên giải pháp do con người tạo ra từ PR đó, hay còn gọi là giải pháp vàng.

Phương pháp này tương tự như điểm chuẩn SWE-bench khá nổi tiếng.

Chúng tôi bắt đầu với hơn 10.000 nhiệm vụ tiềm năng, nhưng không phải nhiệm vụ nào cũng phù hợp.

Một số có hướng dẫn không đầy đủ hoặc hướng dẫn quá cụ thể.

Có thể các bài kiểm thử đã được kết hợp với giải pháp vàng hoặc trạng thái trước khi PR bị hỏng.

Vì vậy, chúng tôi phải xem xét nhiều lần để chọn ra 100 nhiệm vụ công bằng.

Trong những lần đánh giá đó, chúng tôi đã sử dụng các mô hình hiện đại nhất để thu được một số kết quả.

Chúng tôi bắt đầu với tỷ lệ giải quyết nhiệm vụ khoảng 30%, chúng tôi gọi đây là tỷ lệ đạt.

Sau đó, khi chúng tôi khoá tập dữ liệu cho bản phát hành chính thức, các mô hình hàng đầu đã đạt khoảng 70%.

Nhưng đó là chuyện của một tháng sau.

Sau đó, chúng tôi lên kế hoạch đánh giá các mô hình mới hằng tháng và theo dõi xem chúng cải thiện như thế nào.

Và trong bản phát hành tháng 8, tỷ lệ đạt là 92% đối với mô hình tốt nhất.

Và chúng tôi biết rằng tiêu chuẩn của chúng tôi quá thấp, và tập dữ liệu này đã bão hoà.

Tomáš Mlynarič

Nhưng chúng tôi đã lường trước được điều đó và chúng tôi đã nỗ lực làm việc trên phiên bản 2.0, phiên bản mà chúng tôi đã phát hành vào tháng trước.

Mục tiêu của chúng tôi là nâng cao tiêu chuẩn bằng các nhiệm vụ phức tạp, thực tế trên Android, đồng thời cung cấp hướng dẫn và thông tin minh bạch về hiệu suất của LLM cho bạn, các nhà phát triển, nhưng cũng thúc đẩy các nhà sản xuất mô hình ưu tiên Android bằng cách cung cấp cho họ điểm chuẩn phù hợp để cải thiện.

Đồng thời cung cấp thông tin phân tích và kết quả cho cả bạn và nhà sản xuất mô hình.

Nhưng chúng ta cũng cần tính đến sự thông minh, ngoan cường và gian lận.

Và chúng ta cần ngăn chặn nguy cơ ô nhiễm.

Một vấn đề với phương pháp SWE-bench là tính công khai thực tế của mã nguồn.

OpenAI đã xuất bản một bài viết.

Họ nhận thấy rằng các mô hình có thể hoàn thành những từ tiếp theo trong hướng dẫn hoặc có thể giải quyết một nhiệm vụ có lỗi khó hiểu không nằm trong hướng dẫn.

Và họ nhận ra rằng các nhà sản xuất mô hình đang huấn luyện trên mã nguồn mở và SWE-bench đã bị nhiễm bẩn.

Vì vậy, đối với phiên bản 2.0, chúng tôi thực sự giữ mã nguồn đóng để ngăn việc huấn luyện trên đó.

Chúng tôi chia công việc thành 4 luồng công việc.

Đầu tiên, chúng tôi thực hiện chuyển đổi ứng dụng, trong đó chúng tôi lấy các ứng dụng Flutter và React Native nguồn mở, rồi yêu cầu các tác nhân chuyển đổi chúng sang giải pháp Android gốc.

Điều này thực sự phản ánh xu hướng di chuyển từ nhiều nền tảng sang gốc mà chúng ta thấy hiện nay.

Luồng công việc thứ hai là các tính năng mới và tích hợp nền tảng.

Các tính năng này được tích hợp vào toàn bộ mã nguồn chính thức đã có sẵn.

Ví dụ: trong ứng dụng Now in Android, chúng tôi đã thêm tính năng video hoặc hình trong hình, v.v.

Dòng công việc thứ ba là di chuyển.

Chúng tôi đang nâng cấp các ứng dụng nguồn mở chính thức mà chúng tôi đã đóng, bằng các thư viện và cấu trúc hiện đại.

Ví dụ: Nav 2 sang Nav 3, chế độ xem XML sang Compose hoặc những thứ như bố cục một ngăn sang bố cục thích ứng.

Và ứng dụng cuối cùng là ứng dụng nội bộ mới được xây dựng từ đầu bằng cách sử dụng bản mô phỏng thiết kế trực quan.

Ví dụ: quy trình xác thực OTP qua SMS đầy đủ, theo dõi đơn đặt hàng bằng Google Maps, v.v.

Tomáš Mlynarič

Chỉ với một vài kỹ sư, chúng tôi đã xây dựng một ứng dụng có cùng quy mô như Now in Android.

Nhưng nhiệm vụ mới cũng mang đến những thách thức mới.

Đầu tiên: chấm điểm, các nhân viên hỗ trợ một cách chính xác.

Các bài kiểm thử điểm chuẩn khó hơn nhiều so với các bài kiểm thử cho ứng dụng của bạn vì chúng phải vượt qua mọi giải pháp hợp lệ, chứ không chỉ một giải pháp, và nhiệm vụ càng lớn thì càng có nhiều giải pháp hợp lệ.

Trong phiên bản 1.0, điểm chuẩn chủ yếu dựa vào kiểm thử đơn vị và kiểm thử đơn vị khá tệ trong việc không phụ thuộc vào nền tảng.

import com.foodvibes.MyViewModel

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

    assertTrue(vm.retried)
}

Các quy tắc này yêu cầu tên lớp hoặc tên hàm chính xác.

Như trong trường hợp này, không có bài kiểm thử nào phức tạp, nhưng về cơ bản, vấn đề là tác nhân có thể đặt tên khác cho những thứ đó, hoặc ngay cả khi không đặt tên khác, thì nếu họ đặt tên đó vào một gói khác, các bài kiểm thử sẽ không biên dịch được và do đó, sẽ không thể sử dụng được trong trường hợp của chúng ta.

import com.foodvibes.feature.my.RetriableViewModel

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

    assertTrue(vm.tried)
}

Vì vậy, về mặt kỹ thuật, chúng ta có thể chỉ định các API trong câu lệnh, nhưng điều đó sẽ tiết lộ quá nhiều thông tin chi tiết hoặc khiến câu lệnh trở nên quá tải với quá nhiều yêu cầu kiểm thử.

Vì vậy, giải pháp là chúng ta thực hiện các kiểm thử không phụ thuộc vào cách triển khai.

Đây là những kiểm thử cấp cao và kiểm thử kết quả, chúng kiểm thử kết quả và hành vi chứ không phải nội bộ.

Chúng tôi sử dụng quy trình kiểm thử giao diện người dùng tất định, tức là các quy trình kiểm thử tương tác với thông tin công khai trên màn hình, tương tự như cách người dùng thực hiện.

Đối với những trường hợp đó, chúng tôi sử dụng các kiểm thử UI Automator hoặc Compose UI, nhưng chúng tôi cũng có các tập lệnh chuyên biệt để kiểm tra một số ranh giới hệ thống bên ngoài, chẳng hạn như liệu một lệnh gọi mạng có dữ liệu phù hợp hay không, hoặc liệu dữ liệu phù hợp có được lưu vào cơ sở dữ liệu mà không biết về các trình trợ giúp nội bộ hoặc DAO hay không.

Trong số đó, chúng tôi cũng có các quy trình kiểm tra tĩnh, chẳng hạn như kiểm tra quyền trong tệp kê khai hoặc kiểm tra xem thư viện có nằm trong các tệp được tạo hay không, v.v.

Ngoài ra, chúng tôi cũng có các thử nghiệm kết hợp, là sự kết hợp giữa các tập lệnh đó và thử nghiệm giao diện người dùng.

Đây là ví dụ về một trong các thử nghiệm kết hợp.

Họ lái xe bên ngoài trình mô phỏng.

Vì vậy, đây là thử nghiệm cho quy trình xác thực OTP qua SMS, trong đó tập lệnh trước tiên cần tính toán hàm băm của ứng dụng để có thể gửi SMS chính xác đến trình mô phỏng, sau đó bắt đầu thử nghiệm, thử nghiệm UI Automator và chuyển một số OTP được tạo ngẫu nhiên mà nó yêu cầu, đồng thời gửi SMS đến trình mô phỏng bằng lệnh ADB.

Và kiểm thử chỉ kiểm tra xem dữ liệu đầu vào có đúng số hay không.

Đó là, về cơ bản là vậy.

Không có sự kết hợp triển khai nào, chỉ có các bước kiểm tra, chỉ kiểm tra xem quy trình có hoạt động hay không.

Vấn đề thứ hai về việc chấm điểm là các nhiệm vụ của chúng tôi đòi hỏi khả năng đa phương thức.

Các tác nhân này có thể được yêu cầu tạo giao diện người dùng hoặc chúng tôi cung cấp cho họ bản mô phỏng thiết kế.

Và cách dễ nhất để làm việc này là sử dụng các bài kiểm thử ảnh chụp màn hình.

Và ngay từ đầu, chúng tôi đã biết rằng ngưỡng ảnh chụp màn hình sẽ cần phải cao hơn, nhưng dù sao thì chúng cũng không đạt.

Chúng tôi đã thử một số thuật toán phân biệt pixel khác nhau, nhưng chúng không thành công đối với những nội dung như nhiễu ở cấp hệ thống, trong đó thanh trạng thái của trình mô phỏng khác nhau hoặc biểu tượng pin, hoặc thậm chí như khử răng cưa phần cứng phông chữ khác nhau.

Nhưng họ cũng không thành công trong một số cách triển khai hợp lệ, chẳng hạn như khoảng đệm nhỏ, hơi khác một chút hoặc có một số khác biệt nhỏ về sắc thái màu, chẳng hạn như giao diện người dùng có thể hoàn toàn chính xác, nhưng nền sẽ có sắc thái màu hơi khác và thuật toán phân biệt pixel sẽ không thành công.

Vì vậy, chúng tôi đã sử dụng và xây dựng Multimodal LLM Judge để so sánh các cặp ảnh chụp màn hình như trong các bài kiểm thử ảnh chụp màn hình và cho chúng tôi một số điểm, nhưng cũng có cả Lý luận cấu trúc về điểm số.

Chúng tôi cũng cung cấp cho nó một số tệp kết xuất hệ phân cấp hỗ trợ tiếp cận để kiểm tra xem cấu trúc có chính xác hay không và tính tương đương về cấu trúc có chính xác hay không.

Chúng tôi đã thử nghiệm thực tế nhiều lần và nhận thấy rằng phương pháp này có tính nhất quán cao và bỏ qua được những vấn đề mà chúng tôi đã thấy.

Vì vậy, giờ đây, chúng tôi đã có một cách hiệu quả để xác minh hình ảnh và hành vi một cách độc lập, và chúng tôi nhận thấy rằng các tác nhân đã cố gắng làm giả mọi thứ.

Xin mời tiếp tục.

Tomáš Mlynarič

Mọi thứ bắt đầu rất đơn giản.

Ngày nay, các tác nhân về cơ bản là: "Được rồi.

Tôi có một việc cần làm.

Hãy cùng xem GitHub.

Hãy cùng tìm giải pháp."

Đó là việc đầu tiên họ làm.

Họ cố gắng tìm kiếm giải pháp hợp lệ trên GitHub hoặc Internet. Đó là lý do chúng tôi cần giữ kín mã nguồn và không thể công khai.

Nhưng việc đó khá dễ dàng.

Trong một số thử nghiệm, chúng tôi nói rằng mọi thứ đều vượt qua 100% một cách suôn sẻ, và tác nhân nói: "Chiến thắng huy hoàng!"

Vậy nên.

Thú vị thật, họ đã tìm thấy gì?

Nhưng khi xem xét kỹ hơn về quỹ đạo, họ lại nói: "Tôi không thể làm được.

Tôi sẽ thay đổi ngưỡng thành 80% cho kiểm thử ảnh chụp màn hình."

// AuthFlowScreenshotTests.kt

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

Và nó giống như, "Vâng, chiến thắng, mọi thứ đang trôi qua."

Đúng vậy, nhưng các hoạt động kiểm thử ảnh chụp màn hình không có tác dụng gì.

Nhưng đó chưa phải là cách tinh vi nhất.

Trong một số trường hợp, thực tế là trong ứng dụng chuyển đổi Flutter, tác nhân đã cố gắng tạo Android và nói: "Tôi không biết phải làm gì".

Vì vậy, họ đã lấy ảnh chụp màn hình mà chúng tôi cung cấp cho họ và đặt ảnh đó làm một đối tượng có thể vẽ trong nền.

Và giờ đây, nó đã vượt qua được bài kiểm tra ảnh chụp màn hình.

Thật tuyệt vời!

Nhưng sau đó, bạn biết đấy, các bài kiểm thử giao diện người dùng vẫn không thành công, vì vậy, họ sẽ nói: "Tôi sẽ đặt một lớp phủ vô hình lên trên đó bằng các nút, văn bản và thẻ kiểm thử, mọi thứ mà chúng tôi yêu cầu.

Giờ đây, mọi thứ đều có màu xanh lục.

Thật tuyệt vời!

Làm tốt lắm."

Không phải là có một cái thực sự tốt.

Vậy nên, chúng ta có một nhiệm vụ di chuyển từ Java sang Kotlin, trong đó tác nhân về cơ bản cần di chuyển từ Java sang Kotlin, đúng không?

Họ không thể tạo bản dựng.

Có vẻ như vẫn còn lỗi, nên tác nhân nghĩ: "Được rồi, tôi sẽ lấy các lớp đã biên dịch từ Java và đưa vào một tệp JAR, sau đó thêm tệp đó vào các tệp bản dựng dưới dạng một thư viện thông thường.

Giờ thì mọi bài kiểm thử đều đạt, nhưng chúng ta có các quy trình kiểm tra tĩnh để kiểm tra các tệp Java, nên tôi sẽ xoá các tệp đó."

Tôi đang xoá các tệp Java, mọi thứ đều có màu xanh lục, ngoại trừ Kotlin vẫn không thành công, vì vậy, họ nói: "Được rồi, tôi sẽ xoá nhóm tài nguyên Kotlin và giờ mọi thứ đều thành công.

Tuyệt vời."

Tôi không biết liệu đây có phải là gian lận hay không.

Ý tôi là, cái này thực sự sáng tạo.

Vì vậy, để ngăn chặn tất cả những điều đó, chúng tôi đã xây dựng một trình phát hiện gian lận có ba lớp phòng thủ.

Chúng tôi xem xét cây giao diện người dùng, áp dụng nhiều kích thước màn hình để nền bị méo và chúng tôi thấy được điều đó.

Tuy nhiên, chúng tôi cũng đặt lại các bài kiểm tra và kiểm tra xem có hành vi can thiệp nào vào bài kiểm tra hay không để đảm bảo họ không thể thay đổi ngưỡng.

Và chúng tôi cũng có LLM-as-a-Judge, công cụ kiểm tra quỹ đạo và kết quả thực tế của tác nhân để phát hiện những điều bất thường.

Và nếu có bất cứ điều gì xảy ra, chúng tôi chỉ nói: "Được rồi, thất bại ngay lập tức".

Tomáš Mlynarič

Giờ đây, mọi lối tắt đều biến mất, không cần tìm giải pháp, không cần kiểm thử đơn vị dễ hỏng hoặc giả mạo giao diện người dùng.

Vậy khi chúng tôi yêu cầu các tác nhân thực sự thiết kế một ứng dụng Android, kết quả sẽ như thế nào?

Vì vậy, tính đến thứ Hai, có thể bạn đã thấy bài đăng trên blog, các con số trông như thế này.

Ngay cả tác nhân tốt nhất cũng chỉ vượt qua khoảng 40% nhiệm vụ của chúng tôi, và hầu hết các tác nhân tiên tiến đều đạt từ 20% đến 40%.

Và điều đó rất tốt cho chúng tôi với tư cách là tác giả của điểm chuẩn, vì điều này tạo ra sự cân bằng phù hợp, chẳng hạn như có giá trị thực tế của các nhiệm vụ mà chúng tôi cung cấp, nhưng cũng có nhiều không gian để phát triển.

Bây giờ, hãy cùng xem kết quả.

Giờ đây, chúng ta có thể xem kết quả từ nhiều góc độ.

Chúng ta có thể xem xét một số thông tin chi tiết mà chúng ta đã tìm thấy.

Câu hỏi đầu tiên mà bạn có thể đặt ra khi xem biểu đồ là chi phí để chạy tác nhân đó là bao nhiêu?

Và các công ty AI thường báo cáo chi phí cho mỗi mã thông báo, đối với một số mã thông báo đầu vào, đầu ra, có thể là mã thông báo bộ nhớ đệm.

Và có thể đó là một lập luận giúp bạn đưa ra quyết định trong trường hợp của mình.

Nhưng chúng ta có thể xem xét vấn đề này từ một góc nhìn khác.

Chúng ta có thể vẽ cùng một biểu đồ trên không gian 2D với chi phí trung bình cho mỗi nhiệm vụ, chứ không phải mã thông báo, tức là chi phí cho mỗi nhiệm vụ so với tỷ lệ đạt.

Và ở đây, chúng ta có thể đột nhiên thấy rằng một số mô hình nói nhiều hơn.

Họ dành nhiều thời gian hoặc token hơn cho mỗi nhiệm vụ, trong khi những người khác hoàn thành nhiều nhiệm vụ hơn với chi phí thấp hơn.

Nhưng nếu chúng ta thêm giá mỗi mã thông báo vào cùng một biểu đồ, chúng ta có thể thấy rằng những gì các công ty AI thực sự quảng cáo không khớp với những gì bạn thực sự trả cho mỗi nhiệm vụ.

Vì vậy, nếu bạn có thể thấy rằng tác nhân có tỷ lệ vượt qua tốt nhất thực sự là một trong những tác nhân rẻ nhất trên mỗi mã thông báo, nhưng lại đắt nhất trên mỗi nhiệm vụ.

Hoặc các tác nhân khác có cùng mức giá mã thông báo vượt qua khoảng 30% nhiệm vụ, nhưng rẻ hơn 15 lần.

Vì vậy, giá của mã thông báo không phải là chỉ số.

Một số mô hình đang khám phá mã nhiều hơn, chúng đang xây dựng lại, chạy lại và mỗi bước đều tiêu tốn nhiều mã thông báo hơn.

Vì vậy, điều quan trọng là đừng chỉ nhìn vào giá, chi phí cho mỗi mã thông báo.

Chọn một mô hình, xem dữ liệu thực tế, sử dụng mô hình đó trong trường hợp của bạn hoặc xem Android Bench để biết mô hình nào thực sự dành nhiều mã thông báo nhất cho các nhiệm vụ.

Một số mô hình cần nhiều bước hơn, mặc dù chi phí cho mỗi mã thông báo rẻ hơn.

Nhưng có một khía cạnh khác của cùng một câu hỏi.

Đây là cùng một biểu đồ, nhưng chúng ta cũng có thể xem và cho biết thời gian cần thiết để nhân viên hỗ trợ hoàn thành việc đó.

Và chúng ta có thể thấy rằng những nhân viên hỗ trợ có tỷ lệ vượt qua cao nhất có thể là những người chậm nhất.

Ví dụ: chúng ta có thể thấy một số người mất gần hai giờ cho mỗi nhiệm vụ.

Họ tiếp tục xây dựng lại, thử nghiệm lại cho đến khi thành công.

Đúng vậy, các bài kiểm tra này có tỷ lệ đạt cao nhất nhưng cũng tốn nhiều thời gian nhất.

Một số tác nhân rẻ hơn vẫn mất khoảng nửa giờ đến một giờ rưỡi cho mỗi nhiệm vụ, nhưng không mang lại kết quả tốt hơn.

Hoặc các tác nhân khác hoàn thành nhiệm vụ trong chưa đầy 20 phút và vẫn giải quyết được hơn 1/4 số nhiệm vụ.

Vì vậy, các mô hình nhỏ, gọn thường nhanh hơn và rẻ hơn, nhưng thường không xử lý được những nhiệm vụ khó.

Bài học rút ra là không có mô hình nào là tốt nhất.

Điều này phụ thuộc vào mục tiêu tối ưu hoá của bạn.

Is it pass rate? (Có phải là tỷ lệ đạt không?)

Có phải là chi phí không?

Is it wait time?

Trong trường hợp đó, tuỳ thuộc vào loại công việc bạn đang làm, nếu bạn không làm những việc quá khó, hãy cân nhắc sử dụng các mô hình nhanh hơn để hoàn thành công việc với chi phí thấp hơn và nhanh hơn.

Tuy nhiên, chi phí và tốc độ chỉ cho bạn biết cách các tác nhân chạy, chứ không cho biết lý do các tác nhân không vượt qua được hầu hết các thử nghiệm.

Vì vậy, chúng tôi đã kiểm tra các lần chạy không thành công và nhận thấy rằng các tác nhân thường thoát sớm.

Họ tin rằng họ đã hoàn thành.

Đã hoàn thành nhiệm vụ.

Được rồi, tôi về nhà đây.

Tuy nhiên, như đã đề cập, trong gói nhiệm vụ, tác nhân chỉ nhận được hướng dẫn và trạng thái trước đó.

Họ không thể xem các bài kiểm tra.

Họ thấy rằng họ không thể xem bộ xác minh.

Vì vậy, chúng tôi tự hỏi, điều gì sẽ xảy ra nếu chúng tôi cho họ xem các bài kiểm tra?

Vì vậy, chúng tôi đã thử nghiệm và có một biến thể kiểm thử mở cho cùng một nhiệm vụ, trong đó tác nhân nhận được bộ kiểm thử xác minh không thành công ngay từ đầu.

Vì vậy, giờ đây, họ đang chạy các thử nghiệm lặp đi lặp lại.

Họ có thể kiểm tra lỗi, tinh chỉnh mã trong vòng lặp phản hồi.

Và chúng tôi nhận thấy rằng khi các nhân viên biết có bài kiểm tra, họ sẽ cố gắng hơn và làm việc lâu hơn.

Còn trong các lượt chạy mở, họ có số lượt nhiều hơn 25% và thời gian chạy của tác nhân nhiều hơn 40%.

Họ mất gần 30 phút cho mỗi nhiệm vụ để chạy và sửa các bài kiểm thử không thành công, vì họ không gỡ lỗi một cách mù quáng.

Vì vậy, họ thấy chính xác những gì không thành công và thật không may, tỷ lệ vượt qua cũng tăng gần 50 điểm phần trăm.

Và nỗ lực này giúp cải thiện tỷ lệ vượt qua trung bình, như tôi đã đề cập.

Nhưng cuối cùng, các mô hình tiên phong mới đã ra đời và nhanh chóng vượt trội hơn biến thể nguồn mở này.

Well, almost 90% of done of pass rate.

Vì vậy, chúng tôi đã giữ lại biến thể thử nghiệm khép kín về tính năng tìm kiếm khép kín làm chỉ số đo điểm chuẩn chính.

Tuy nhiên, vẫn rất thú vị khi thấy các mô hình thực sự hoạt động hiệu quả hơn khi biết được tiêu chí đánh giá.

Tomáš Mlynarič

Tuy nhiên, điều này giúp chúng tôi có thêm thông tin chi tiết về các nhân viên hỗ trợ.

Ví dụ: chúng ta có thể kiểm tra cách các mô hình thực sự kiểm thử kết quả của chính chúng.

Vì vậy, chúng ta có thể thấy từ biểu đồ rằng các mô hình tiên phong viết ngày càng nhiều bài kiểm thử tốt hơn và có tỷ lệ vượt qua cao hơn.

Một số mô hình khác thì quá tự tin, tôi có thể làm được, không cần kiểm thử.

Đôi khi, chúng vẫn còn dùng được.

Vì vậy, nếu sử dụng các mô hình không giỏi kiểm thử, bạn có thể giúp chúng bằng cách cung cấp kỹ năng kiểm thử tốt hơn hoặc hướng dẫn cụ thể về cách viết mã kiểm thử.

Nhưng mối tương quan không có nghĩa là quan hệ nhân quả, đúng không CS?

Chúng ta cần có thử nghiệm có kiểm soát về vấn đề này.

Chúng ta vẫn cần phải làm, về việc liệu việc đặt câu lệnh để có các bài kiểm tra tốt hơn có thực sự làm tăng điểm số hay không.

Tuy nhiên, chúng tôi đã tiến hành một thử nghiệm trên nửa còn lại của quy trình kiểm thử Android, đó là yêu cầu các tác nhân sử dụng trình mô phỏng.

Ban đầu, trong điểm chuẩn, chúng tôi không nói gì về trình mô phỏng.

Chúng tôi cho rằng các tác nhân sẽ tự tìm ra, đúng không?

Vì vậy, chúng tôi nhận thấy rằng hầu như không có ai thực sự khởi động trình mô phỏng.

Và như tôi đã đề cập, các bài kiểm thử giao diện người dùng khá quan trọng trong điểm chuẩn của chúng tôi và nếu không có trình mô phỏng, bạn không thể thực sự sử dụng các bài kiểm thử giao diện người dùng.

Vì vậy, tất cả đều thất bại ở một điều rất đơn giản.

Giờ đây, chúng ta phải đối mặt với tình thế tiến thoái lưỡng nan.

Chúng ta có nên yêu cầu các nhân viên hỗ trợ sử dụng trình mô phỏng và chấp nhận rủi ro là điểm số thực tế sẽ cao hơn, hay chúng ta không nói gì và hy vọng họ sẽ tự tìm ra cách?

Nhưng sau cùng, mục tiêu của chúng tôi là trở thành một bài kiểm tra công bằng để đánh giá khả năng lập trình và giải quyết vấn đề trên Android.

Chúng ta không muốn đo lường những yếu tố bất thường về môi trường.

Vì vậy, chúng tôi chọn một giải pháp trung hoà.

Chúng tôi đã hướng dẫn họ cách khởi động trình mô phỏng, nhưng không đề cập đến việc có nên sử dụng trình mô phỏng hay không.

Suy cho cùng, việc khởi động trình mô phỏng không phải là điều chúng ta thực sự cần kiểm thử hoặc muốn kiểm thử.

Và chúng tôi đã đo lường tác động của lệnh trình mô phỏng đó.

Và giờ đây, chúng tôi thực sự thấy rằng khi chúng tôi hướng dẫn họ cách thực hiện, các tác nhân thực sự đã khởi động trình mô phỏng nhiều hơn và thực sự chạy các kiểm thử giao diện người dùng, và điều đó có tác động lớn đến tỷ lệ vượt qua, thật không may cho chúng tôi.

Nhưng việc này cũng giúp chúng tôi kiểm tra các lỗi và vấn đề lập trình thực tế của họ, chứ không chỉ là lỗi trên trình mô phỏng chưa khởi động.

Vì vậy, điều quan trọng cần lưu ý là mức độ cụ thể của câu lệnh vẫn rất quan trọng. Nếu bạn đang thiết kế điểm chuẩn hoặc bản đánh giá của riêng mình, bạn cần kiểm tra những yếu tố thực sự quan trọng trong trường hợp của bạn.

Ví dụ: bạn đang đánh giá hiệu quả của mã thông báo hoặc một kỹ năng hay công cụ, trước tiên, bạn cần thực sự bắt đầu bằng việc đánh giá đạt, thực hiện thay đổi để tăng hiệu quả, sau đó vẫn xác minh rằng mã thông báo vẫn đạt với ít mã thông báo hơn.

Nếu làm khác đi, bạn sẽ có quá nhiều biến thay đổi cùng một lúc và bạn sẽ không biết liệu thay đổi đó có thực sự giúp cải thiện hiệu suất hay không.

Tomáš Mlynarič

Quay lại bảng xếp hạng.

Như tôi đã đề cập, các mô hình tốt nhất vượt qua khoảng 40% nhiệm vụ và tỷ lệ vượt qua yêu cầu tất cả các bước kiểm tra đều phải đạt.

Nếu không, việc cần làm sẽ không hoàn thành.

Vậy câu hỏi đặt ra là, có phải các nhân viên hỗ trợ không tạo ra được điều gì hữu ích trong 60% thời gian còn lại không?

Không, họ đang tiến bộ.

Để cho thấy mức độ gần gũi của tác nhân với các giải pháp hiệu quả, giống như một khoảng cách, chúng tôi cũng tính toán tỷ lệ hoàn thành hoặc một loại điểm số từng phần.

Đây là điểm số có trọng số trên 4 danh mục: tính nhất quán về hình ảnh, chức năng, liệu ứng dụng có hoạt động đúng cách hay không, một số yêu cầu cụ thể cho từng nhiệm vụ và một số quy trình kiểm tra hồi quy.

Và bạn có thể thấy rằng các mô hình có thứ hạng thấp hơn có thể hoàn thành khoảng một nửa công việc, trong khi các mô hình tiên phong có thể hoàn thành và đạt gần 80% trung bình, hơn 80% nhiệm vụ, nhưng chúng chỉ vượt qua 40 40%.

Vì vậy, chúng tôi đã thử nghiệm chuyển đổi Flutter sang Android để kiểm tra xem điều gì đang xảy ra.

Vì vậy, chúng tôi đã tính toán lại tỷ lệ hoàn thành sau mỗi vài bước của tác nhân và nhận thấy các mẫu tương tự trên tất cả các mô hình tiên phong.

Khoảng 140 bước, họ đã nỗ lực để đạt được điểm số trung bình gần 90%, sau đó họ dành thêm 90 bước nữa hoặc gần 40% thời gian chạy để cố gắng thu hẹp khoảng cách đến 100%, nhưng họ chỉ có thể ghi thêm 1 hoặc 2%.

Và chúng tôi nghĩ rằng điều này thực sự phản ánh quá trình phát triển dựa trên tác nhân hiện nay, nơi các nhà phát triển hoặc người dùng chưa có kinh nghiệm thấy ứng dụng đã hoàn tất.

Mọi thứ đang hiển thị.

Nội dung nhập có vẻ đúng.

Có thể không có sự cố nào.

Nhưng khi một kỹ sư cấp cao đến và xem xét mã, họ sẽ thấy rất nhiều lỗi: họ thấy các vấn đề về cấu trúc, lỗi vòng đời và những vấn đề tương tự.

Tomáš Mlynarič

Để kết thúc, hãy cùng nhìn lại Android Bench, phiên bản 2.0 của chúng tôi.

So với phiên bản 1.0, chúng tôi hiện chỉ có 30 nhiệm vụ và đó là điều có chủ đích.

Thay vì các bản sửa lỗi riêng biệt và các bản vá nhỏ, chúng tôi có các màn hình hoàn chỉnh, quá trình di chuyển nhiều mô-đun, lượt chuyển đổi toàn bộ ứng dụng.

Các bản vá hiện có quy mô lớn hơn trên hàng chục tệp.

Và chúng tôi có các bước kiểm tra giao diện người dùng đa phương thức.

Các tác nhân phải chạy lâu hơn và hoạt động tích cực hơn nhiều.

Nếu so sánh với các điểm chuẩn tiên phong khác, chúng ta vẫn có thể thấy rằng điểm chuẩn của chúng ta yêu cầu thay đổi mã lớn hơn nhiều.

Bộ dữ liệu này không bị nhiễm bẩn vì hầu hết các nhiệm vụ đều được viết từ đầu và vẫn còn nhiều dư địa để phát triển.

Như tôi đã nói ở phần đầu, trong thế giới AI, vài tháng có thể dài như cả một thế kỷ, và cuối cùng, mọi điểm chuẩn đều đạt đến mức tối đa và bão hoà.

Và khi điều đó xảy ra, hy vọng chúng ta sẽ hướng tới những nhiệm vụ khó khăn và phức tạp hơn nữa, phù hợp với thời đại và trạng thái của AI lúc đó.

Bây giờ, hãy sử dụng Android Bench làm kim chỉ nam để so sánh các mô hình và bộ khung, đồng thời có thể tìm hiểu một số thông tin chi tiết.

Và khi bạn đã sẵn sàng tìm hiểu sâu hơn, hãy áp dụng các nguyên tắc đo điểm chuẩn và đánh giá tương tự cho toàn bộ mã nguồn và quy trình làm việc của riêng bạn, vì không có gì hiệu quả hơn việc đo lường AI trên mã mà bạn thực sự làm việc.

Đó là cách bạn chuyển từ hy vọng AI làm đúng sang biết chắc AI đã làm đúng.

Thay mặt cho toàn bộ nhóm Android Bench, xin cảm ơn bạn đã quan tâm.