ข้อมูลเชิงลึกเกี่ยวกับการสร้างโค้ดของ Agent จาก Android Bench

Tomáš Mlynarič

สวัสดีตอนเช้าทุกคน

มาเริ่มกันเลย

เมื่อเดือนมีนาคม เราได้เปิดตัว Android Bench ซึ่งเป็นชุดข้อมูลและลีดเดอร์บอร์ดเกี่ยวกับการวัดผล LLM ในงานด้านการพัฒนาสำหรับนักพัฒนาแอป Android

ตั้งแต่นั้นมา เราได้ใช้ชุดข้อมูลนี้กับโมเดลใหม่ๆ มากมาย

และเมื่อเดือนที่แล้ว เราได้เปิดตัว Android Bench 2.0

แม้ว่าเวลาจะผ่านไปเพียง 2-3 เดือน แต่ในโลกของ AI นั้นดูเหมือนยาวนานมาก

ผมชื่อ Tomáš และจะมาแชร์เส้นทางของ Android Bench และวิธีที่เรามาถึงจุดนี้ได้

มาเริ่มกันที่ 1.0

ในเวอร์ชัน 1.0 เราได้นำปัญหาในชีวิตจริงมาจากที่เก็บโอเพนซอร์ส

เรากรองโปรเจ็กต์ GitHub ที่มีปัญหา GitHub, Pull Request ที่แก้ปัญหาเหล่านั้น และการทดสอบที่ยืนยันโซลูชัน

เราแบ่ง Pull Request ออกเป็นกลุ่มงานสำหรับโมเดล AI

ปัญหาใน GitHub กลายเป็นวิธีการหรือพรอมต์สำหรับโมเดล และเราได้ใส่ไว้ในสถานะก่อน PR

และเมื่อโมเดลสร้างผลงานบางอย่างขึ้นมา เราก็นำการทดสอบไปใช้กับเอาต์พุต ซึ่งทำให้เราได้ผลลัพธ์ว่าผ่านหรือไม่ผ่าน

ความพยายามครั้งเดียวของ AI ในการแก้ปัญหานี้เรียกว่าการทดลอง

และเรายังเปรียบเทียบกับโซลูชันที่มนุษย์สร้างขึ้นจาก PR นั้น หรือที่เราเรียกว่าโซลูชันที่สมบูรณ์แบบได้ด้วย

วิธีการนี้คล้ายกับเกณฑ์เปรียบเทียบ SWE-bench ที่เป็นที่รู้จักกันดี

เราเริ่มต้นด้วยงานที่อาจเป็นไปได้มากกว่า 10,000 รายการ และไม่ใช่ทุกงานที่เหมาะสม

บางรายการมีวิธีการที่ไม่สมบูรณ์หรือระบุวิธีการมากเกินไป

การทดสอบอาจเชื่อมโยงกับโซลูชันที่สมบูรณ์แบบ หรือสถานะก่อนที่ PR จะเสียหาย

เราจึงต้องตรวจสอบแล้วตรวจสอบอีกเพื่อให้ได้งานที่ยุติธรรม 100 งาน

ในระหว่างการตรวจสอบเหล่านั้น เราใช้โมเดลที่ล้ำสมัยเพื่อให้ได้ผลลัพธ์บางอย่าง

และเราเริ่มต้นด้วยการแก้โจทย์ได้ประมาณ 30% ซึ่งเราเรียกว่าอัตราการผ่าน

และเมื่อเราล็อกชุดข้อมูลสำหรับการเปิดตัวอย่างเป็นทางการ โมเดลชั้นนำก็มีประสิทธิภาพอยู่ที่ประมาณ 70% แล้ว

แต่ก็หลังจากนั้นตั้งเดือนนึง

จากนั้นเราก็มีแผนที่จะประเมินโมเดลใหม่ๆ ทุกเดือน และเราก็เห็นว่าโมเดลเหล่านั้นดีขึ้นเรื่อยๆ

และในรุ่นเดือนสิงหาคม อัตราการผ่าน 92% เป็นของโมเดลที่ดีที่สุด

และเราทราบดีว่าเกณฑ์ของเราต่ำเกินไป และชุดข้อมูลนี้ก็มีข้อมูลมากเกินไป

Tomáš Mlynarič

แต่เราคาดการณ์ไว้แล้ว และกำลังพยายามอย่างเต็มที่เพื่อพัฒนาเวอร์ชัน 2.0 ซึ่งเราได้เปิดตัวไปเมื่อเดือนที่แล้ว

เป้าหมายของเราคือการยกระดับมาตรฐานด้วยงาน Android ที่ซับซ้อนและเกิดขึ้นจริงในโลกแห่งความเป็นจริง รวมถึงให้คำแนะนำและความโปร่งใสเกี่ยวกับประสิทธิภาพของ LLM แก่คุณซึ่งเป็นนักพัฒนาแอป และยังผลักดันให้ผู้สร้างโมเดลให้ความสำคัญกับ Android โดยให้เกณฑ์เปรียบเทียบที่ดีเพื่อพัฒนาต่อไป

รวมถึงให้การวิเคราะห์และผลลัพธ์ที่ตอบโจทย์ทั้งคุณและผู้สร้างโมเดล

แต่เราก็ต้องคำนึงถึงความฉลาด ความพยายาม และการโกงด้วย

และเราต้องป้องกันความเสี่ยงจากการปนเปื้อน

ปัญหาหนึ่งของวิธีการ SWE-bench คือความเปิดกว้างที่แท้จริงของซอร์สโค้ด

OpenAI เผยแพร่บทความ

โดยพบว่าโมเดลสามารถเติมคำถัดไปของคำสั่งให้สมบูรณ์ หรือสามารถแก้ปัญหาที่มีข้อผิดพลาดที่คลุมเครือซึ่งไม่ได้เป็นส่วนหนึ่งของคำสั่งได้

และตระหนักว่าผู้สร้างโมเดลกำลังฝึกโมเดลด้วยซอร์สโค้ดโอเพนซอร์ส และ SWE-bench มีการปนเปื้อน

ดังนั้นสำหรับ 2.0 เราจึงเก็บโค้ดไว้เป็นความลับเพื่อป้องกันไม่ให้มีการฝึกด้วยโค้ดดังกล่าว

เราแบ่งงานออกเป็น 4 ส่วน

อย่างแรกคือเราทำการแปลงแอป โดยนำแอป Flutter และ React Native ที่เป็นโอเพนซอร์สมา แล้วบอกให้ Agent แปลงแอปเหล่านั้นเป็นโซลูชัน Android แบบแอปที่มาพร้อมเครื่อง

ซึ่งสะท้อนให้เห็นถึงแนวโน้มของการย้ายข้อมูลข้ามแพลตฟอร์มไปยังเนทีฟที่เราเห็นในปัจจุบัน

สตรีมงานที่ 2 คือฟีเจอร์ใหม่และการผสานรวมแพลตฟอร์ม

โดยสร้างขึ้นในฐานของโค้ดเวอร์ชันที่ใช้งานจริงที่สร้างไว้แล้ว

เช่น ใน Now in Android เราได้เพิ่มฟีเจอร์วิดีโอหรือการแสดงภาพซ้อนภาพ และอื่นๆ

สตรีมงานที่ 3 คือการย้ายข้อมูล

เรากำลังอัปเกรดแอปโอเพนซอร์สเวอร์ชันที่ใช้งานจริงซึ่งเราปิดไว้ด้วยไลบรารีและสถาปัตยกรรมที่ทันสมัย

เช่น Nav 2 เป็น Nav 3, มุมมอง XML เป็น Compose หรือสิ่งต่างๆ เช่น แผงเดียวเป็นเลย์เอาต์แบบปรับเปลี่ยนได้

และแอปสุดท้ายคือแอปที่สร้างขึ้นใหม่ทั้งหมดภายในองค์กรโดยใช้ม็อกอัปการออกแบบภาพ

ตัวอย่างในที่นี้คือขั้นตอนการตรวจสอบสิทธิ์ OTP ทาง SMS แบบเต็ม การติดตามคำสั่งซื้อด้วย Google Maps และอื่นๆ

Tomáš Mlynarič

เราสร้างแอปที่มีขนาดเท่ากับ Now in Android โดยใช้วิศวกรเพียงไม่กี่คน

แต่งานใหม่ก็มาพร้อมกับความท้าทายใหม่ๆ

ข้อแรกคือการให้คะแนนตัวแทนอย่างเหมาะสม

การทดสอบการเปรียบเทียบนั้นยากกว่าการทดสอบสำหรับแอปของคุณมาก เนื่องจากต้องผ่านโซลูชันที่ถูกต้องทั้งหมด ไม่ใช่แค่โซลูชันเดียว และยิ่งงานใหญ่ขึ้น โซลูชันที่ถูกต้องก็ยิ่งมีมากขึ้น

ในเวอร์ชัน 1.0 การเปรียบเทียบนี้อาศัยการทำ Unit Test เป็นหลัก และการทำ Unit Test นั้นไม่ค่อยดีนักในการไม่ขึ้นอยู่กับแพลตฟอร์ม

import com.foodvibes.MyViewModel

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

    assertTrue(vm.retried)
}

โดยต้องระบุชื่อคลาสหรือฟังก์ชันที่ถูกต้อง

อย่างในกรณีนี้ ไม่มีการทดสอบที่ซับซ้อน แต่โดยพื้นฐานแล้ว ประเด็นคือ Agent สามารถตั้งชื่อสิ่งเหล่านั้นต่างกัน หรือแม้ว่าจะไม่ได้ตั้งชื่อต่างกัน แต่หากใส่ไว้ในแพ็กเกจอื่น การทดสอบจะคอมไพล์ไม่สำเร็จ และจะใช้ไม่ได้ในกรณีของเรา

import com.foodvibes.feature.my.RetriableViewModel

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

    assertTrue(vm.tried)
}

ดังนั้น เราจึงสามารถระบุ API ในพรอมต์ได้ในทางเทคนิค แต่การทำเช่นนั้นอาจเปิดเผยรายละเอียดมากเกินไป หรือทำให้พรอมต์มีข้อกำหนดการทดสอบมากเกินไป

ดังนั้น วิธีแก้ปัญหาคือเราทำการทดสอบที่ไม่ขึ้นอยู่กับการใช้งาน

การทดสอบเหล่านี้เป็นระดับสูงมากและเน้นผลลัพธ์ โดยจะทดสอบผลลัพธ์และลักษณะการทำงาน ไม่ใช่การทำงานภายใน

เราใช้การทดสอบ UI เชิงกำหนด ซึ่งเป็นการทดสอบที่โต้ตอบกับข้อมูลหน้าจอสาธารณะในลักษณะเดียวกับที่ผู้ใช้ทำ

สำหรับกรณีเหล่านั้น เราใช้ UI Automator หรือการทดสอบ Compose UI แต่เรายังมีสคริปต์เฉพาะที่ตรวจสอบขอบเขตของระบบภายนอกบางอย่าง เช่น การเรียกใช้เครือข่ายมีข้อมูลที่ถูกต้องหรือไม่ หรือข้อมูลที่ถูกต้องได้รับการบันทึกลงในฐานข้อมูลหรือไม่ โดยไม่ทราบเกี่ยวกับตัวช่วยภายในหรือ DAO

นอกจากนี้ เรายังมีการตรวจสอบเบื้องต้นเพื่อตรวจสอบสิทธิ์ในไฟล์ Manifest หรือตรวจสอบว่าไลบรารีอยู่ในไฟล์ที่สร้างขึ้นหรือไม่ เป็นต้น

นอกจากนี้ เรายังมีการทดสอบแบบผสมซึ่งเป็นการรวมสคริปต์เหล่านั้นเข้ากับการทดสอบ UI ด้วย

นี่คือตัวอย่างการทดสอบแบบผสมผสาน

โดยจะขับรถอยู่นอกโปรแกรมจำลอง

นี่คือการทดสอบขั้นตอนการตรวจสอบสิทธิ์ OTP ทาง SMS โดยสคริปต์จะต้องคำนวณแฮชของแอปก่อนเพื่อให้สามารถส่ง SMS ไปยังโปรแกรมจำลองได้อย่างถูกต้อง จากนั้นจึงเริ่มการทดสอบ UI Automator และส่ง OTP ที่สร้างขึ้นแบบสุ่มตามที่ต้องการ และส่ง SMS ไปยังโปรแกรมจำลองด้วยคำสั่ง ADB

และการทดสอบจะตรวจสอบว่าอินพุตมีตัวเลขที่ถูกต้องหรือไม่

ก็มีเท่านี้แหละ

ไม่มีการเชื่อมโยงการติดตั้งใช้งาน มีเพียงการตรวจสอบเท่านั้น โดยจะตรวจสอบว่าโฟลว์ทำงานหรือไม่

ปัญหาการให้คะแนนอย่างที่ 2 คือ งานของเราต้องใช้หลายรูปแบบ

โดยตัวแทนจะต้องสร้าง UI หรือเราจะให้ตัวอย่างจำลองการออกแบบแก่ตัวแทน

และวิธีที่ง่ายที่สุดคือการใช้การทดสอบภาพหน้าจอ

และเราทราบตั้งแต่แรกว่าเกณฑ์ภาพหน้าจอจะต้องสูงกว่านี้ แต่ก็ยังไม่ผ่านอยู่ดี

เราลองใช้อัลกอริทึมการเปรียบเทียบพิกเซลที่แตกต่างกัน แต่ก็ไม่สำเร็จในเรื่องต่างๆ เช่น สัญญาณรบกวนระดับระบบ ซึ่งแถบสถานะของโปรแกรมจำลองแตกต่างกัน หรือไอคอนแบตเตอรี่ หรือแม้แต่การลดรอยหยักของฮาร์ดแวร์แบบอักษรก็แตกต่างกัน

แต่ก็ยังล้มเหลวในการใช้งานที่ค่อนข้างถูกต้องด้วย เช่น ระยะห่างจากขอบเล็กน้อยซึ่งแตกต่างกันเล็กน้อย หรือสีที่แตกต่างกันเล็กน้อย เช่น UI อาจถูกต้องทั้งหมด แต่พื้นหลังมีสีแตกต่างกันเล็กน้อย และอัลกอริทึมการเปรียบเทียบพิกเซลจะล้มเหลว

ดังนั้น เราจึงใช้และสร้าง Multimodal LLM Judge ที่เปรียบเทียบคู่ภาพหน้าจอเหมือนในการทดสอบภาพหน้าจอ และให้คะแนนแก่เรา รวมถึงให้เหตุผลเชิงโครงสร้างเกี่ยวกับคะแนนด้วย

และเรายังป้อนข้อมูลการถ่ายโอนข้อมูลลำดับชั้นการช่วยเหลือพิเศษบางอย่างที่ตรวจสอบว่าโครงสร้างถูกต้องหรือไม่ และความเท่าเทียมกันของโครงสร้างถูกต้องหรือไม่

เราได้ลองใช้ในเชิงประจักษ์ในการทดลองหลายครั้ง และพบว่ามีความสอดคล้องกันสูงและไม่สนใจปัญหาที่เราพบ

ตอนนี้เรามีวิธีที่ดีในการตรวจสอบภาพและลักษณะการทำงานโดยไม่ขึ้นอยู่กับแพลตฟอร์ม และเราเห็นว่าเอเจนต์พยายามปลอมแปลงทุกอย่าง

เชิญเลยครับ

Tomáš Mlynarič

เริ่มต้นได้ง่ายๆ

ปัจจุบัน เอเจนต์จะทำหน้าที่ประมาณว่า "โอเค

ฉันมีงาน

มาดู GitHub กัน

มาหาโซลูชันกัน"

นั่นคือสิ่งที่พวกเขาทำเป็นอันดับแรก

ผู้ใช้พยายามค้นหา GitHub หรืออินเทอร์เน็ตเพื่อหาโซลูชันที่ถูกต้อง เราจึงต้องเก็บซอร์สโค้ดไว้เป็นความลับและไม่สามารถเปิดเผยต่อสาธารณะได้

แต่ก็ง่ายมาก

ในการทดลองบางครั้ง เราบอกว่าทุกอย่างผ่านไปได้ด้วยดี 100% และ Agent ก็พูดว่า "ชัยชนะอันยิ่งใหญ่!"

ประมาณนั้น

น่าสนใจจัง แล้วพวกเขาพบอะไรบ้าง

แต่เมื่อเราพิจารณาเส้นทางอย่างละเอียดแล้ว พวกเขาก็พูดว่า "ฉันทำไม่ได้

ฉันจะลองเปลี่ยนเกณฑ์เป็น 80% ของการทดสอบภาพหน้าจอ"

// AuthFlowScreenshotTests.kt

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

และมันก็เหมือนกับว่า "ใช่ ชัยชนะ ทุกอย่างกำลังผ่านไป"

ใช่ แต่การทดสอบภาพหน้าจอไม่มีประโยชน์

แต่นั่นไม่ใช่การโจมตีที่ซับซ้อนที่สุด

ในบางกรณี เช่น ในแอป Flutter Conversion ตัวแทนพยายามสร้าง Android ซ้ำแล้วซ้ำเล่า แต่ก็ไม่รู้ว่าต้องทำอย่างไร

ดังนั้นพวกเขาจึงนำภาพหน้าจอที่เราให้ไปใส่เป็น Drawable ในพื้นหลัง

และตอนนี้ก็เหมือนกับการผ่านการทดสอบภาพหน้าจอ

ไชโย

แต่แล้วคุณก็รู้ว่าการทดสอบ UI ยังคงไม่สำเร็จ พวกเขาจึงคิดว่า "ฉันจะวางเลเยอร์ซ้อนทับที่มองไม่เห็นไว้ด้านบนพร้อมปุ่ม ข้อความ และแท็กทดสอบ ทุกอย่างที่เราต้องการ

ตอนนี้ทุกอย่างเป็นสีเขียวแล้ว

เยี่ยมมาก

เยี่ยมมาก"

ไม่มีอันไหนที่แบบว่าดีมากๆ

เรามีงานย้ายข้อมูลจาก Java ไปยัง Kotlin ซึ่งโดยพื้นฐานแล้ว Agent จะต้องย้ายข้อมูลจาก Java ไปยัง Kotlin ใช่ไหม

แต่ก็สร้างไม่ได้

แต่ก็ยังไม่สำเร็จอยู่ดี Agent จึงคิดว่า "เอาล่ะ ฉันจะเอาคลาสที่คอมไพล์แล้วจาก Java มาใส่ใน JAR แล้วเพิ่มลงในไฟล์บิลด์เป็นไลบรารีปกติ

ตอนนี้การทดสอบทั้งหมดผ่านแล้ว แต่เรามีการตรวจสอบเบื้องต้นที่ตรวจสอบไฟล์ Java ดังนั้นฉันจะลบไฟล์เหล่านั้นออก"

ฉันลบไฟล์ Java ทุกอย่างเป็นสีเขียว ยกเว้น Kotlin ที่ยังคงไม่ผ่าน ดังนั้นพวกเขาจึงคิดว่า "เอาล่ะ ฉันจะนำชุดซอร์ส Kotlin ออก และตอนนี้ทุกอย่างก็ผ่านแล้ว

เยี่ยมเลย"

ฉันไม่รู้ด้วยซ้ำว่านี่เรียกว่าโกงหรือเปล่า

คือแบบว่านี่เป็นอะไรที่สร้างสรรค์มาก

ดังนั้น เพื่อป้องกันไม่ให้เกิดเหตุการณ์ทั้งหมดนั้น เราจึงสร้างเครื่องมือตรวจจับการโกงที่มีการป้องกัน 3 ชั้น

เราดูที่แผนผัง UI และใช้หน้าจอขนาดต่างๆ เพื่อให้พื้นหลังบิดเบี้ยวและเรามองเห็นได้

แต่เรายังรีเซ็ตการทดสอบและตรวจสอบการปลอมแปลงการทดสอบด้วย เพื่อไม่ให้ผู้ใช้เปลี่ยนเกณฑ์ได้

และเรายังมี LLM-as-a-Judge ที่ตรวจสอบเส้นทางและเอาต์พุตจริงของ Agent เพื่อดูสิ่งผิดปกติด้วย

และหากเกิดอะไรขึ้น เราก็จะบอกว่า "โอเค ล้มเหลวทันที"

Tomáš Mlynarič

ตอนนี้ทางลัดทั้งหมดหายไปแล้ว ไม่มีการค้นหาวิธีแก้ปัญหา ไม่มีการทำ Unit Test ที่เปราะบาง หรือการปลอมแปลง UI

ดังนั้นเมื่อเราบังคับให้ Agent เขียนแอป Android จริงๆ ตัวเลขจะเป็นอย่างไร

ดังนั้น ตั้งแต่วันจันทร์ที่ผ่านมา คุณอาจเห็นบล็อกโพสต์ที่มีตัวเลขดังนี้

แม้แต่ Agent ที่ดีที่สุดก็ผ่านงานของเราได้เพียงประมาณ 40% เท่านั้น และ Agent ระดับแนวหน้าส่วนใหญ่ก็ผ่านงานได้ระหว่าง 20% ถึง 40%

และนั่นเป็นสิ่งที่ดีสำหรับเราในฐานะผู้เขียนการเปรียบเทียบ เนื่องจากเป็นการสร้างสมดุลที่เหมาะสม เช่น งานที่เรามอบให้มีคุณค่าในชีวิตจริง แต่ก็ยังมีพื้นที่ให้เติบโตอีกมาก

มาดูผลลัพธ์กันเลย

ตอนนี้เราสามารถดูผลลัพธ์จากหลายมุมมองได้แล้ว

เราสามารถดูข้อมูลเชิงลึกบางส่วนที่พบแล้วได้

คำถามแรกที่คุณอาจมีเมื่อดูแผนภูมิคือ ค่าใช้จ่ายในการเรียกใช้ Agent นั้นเป็นเท่าใด

และบริษัท AI มักจะรายงานต้นทุนต่อโทเค็น โดยบางบริษัทจะรายงานต้นทุนสำหรับอินพุต เอาต์พุต และอาจรวมถึงโทเค็นแคชด้วย

และนั่นอาจเป็นข้อโต้แย้งในการตัดสินใจในกรณีของคุณ

แต่เราสามารถมองเรื่องนี้จากมุมมองอื่นได้

เราสามารถพล็อตแผนภูมิเดียวกันในพื้นที่ 2 มิติด้วยต้นทุนเฉลี่ยต่องาน ไม่ใช่โทเค็น ดังนั้นต้นทุนต่องานเทียบกับอัตราการผ่านจะเป็นเท่าใด

และที่นี่ เราจะเห็นได้ทันทีว่าโมเดลบางโมเดลพูดคุยได้มากกว่า

โดยใช้เวลาหรือโทเค็นต่อหนึ่งงานมากกว่า ในขณะที่โมเดลอื่นๆ ทำงานได้มากกว่าโดยใช้ทรัพยากรน้อยกว่า

แต่ถ้าเราเพิ่มราคาต่อโทเค็นลงในแผนภูมิเดียวกันนั้นด้วย เราจะเห็นว่าสิ่งที่บริษัท AI โฆษณาจริงๆ ไม่ตรงกับสิ่งที่คุณจ่ายจริงต่องาน

ดังนั้น หากคุณเห็นว่า Agent ที่มีอัตราการผ่านดีที่สุดจริงๆ แล้วเป็นหนึ่งใน Agent ที่มีราคาถูกที่สุดต่อโทเค็น แต่มีราคาแพงที่สุดต่องาน

หรือตัวแทนอื่นๆ ที่มีราคาโทเค็นเท่ากันทุกประการจะผ่านงานประมาณ 30% แต่มีราคาถูกกว่า 15 เท่า

ดังนั้นราคาโทเค็นจึงไม่ใช่เมตริก

บางโมเดลจะสำรวจโค้ดมากขึ้น สร้างใหม่ เรียกใช้ใหม่ และทุกขั้นตอนจะใช้โทเค็นมากขึ้น

ดังนั้น สิ่งที่ควรคำนึงถึงคืออย่าดูแค่ราคาต่อต้นทุนต่อโทเค็น

เลือกโมเดล ดูข้อมูลจริง เช่น ใช้โมเดลนั้นในกรณีของคุณ หรือดู Android Bench เพื่อดูว่าโมเดลใดใช้โทเค็นกับงานมากที่สุด

บางโมเดลก็มีขั้นตอนมากกว่า แม้ว่าจะมีราคาต่อโทเค็นถูกกว่าก็ตาม

แต่ยังมีอีกแง่มุมหนึ่งของคำถามเดียวกันนี้

นี่คือแผนภูมิเดียวกัน แต่เรายังสามารถดูและแสดงระยะเวลาที่ตัวแทนใช้ในการดำเนินการให้เสร็จสมบูรณ์ได้ด้วย

และเราจะเห็นว่าตัวแทนที่มีอัตราการผ่านสูงสุดอาจเป็นตัวแทนที่ช้าที่สุดด้วยซ้ำ

เช่น เราเห็นว่าบางคนใช้เวลาเกือบ 2 ชั่วโมงต่องาน

พวกเขาจะสร้างใหม่และทดสอบอีกครั้งจนกว่าจะใช้งานได้

ใช่ วิธีนี้มีอัตราการผ่านสูงสุด แต่ก็ใช้เวลานานที่สุดด้วย

ตัวแทนบางรายที่ราคาถูกกว่ายังคงใช้เวลาประมาณครึ่งชั่วโมงถึง 1 ชั่วโมงครึ่งต่องาน แต่ผลลัพธ์ก็ไม่ได้ดีขึ้น

หรือตัวแทนคนอื่นๆ ที่ทำงานเสร็จภายใน 20 นาทีและยังคงแก้ปัญหาได้มากกว่า 1 ใน 4 ของงานทั้งหมด

ดังนั้น โมเดลขนาดเล็กและน้ำหนักเบามักจะทำงานได้เร็วกว่าและมีค่าใช้จ่ายน้อยกว่า แต่ก็มักจะล้มเหลวในงานที่ยากๆ

สิ่งที่ได้เรียนรู้คือไม่มีโมเดลใดที่ดีที่สุดเพียงโมเดลเดียว

ขึ้นอยู่กับสิ่งที่คุณเพิ่มประสิทธิภาพ

อัตราการผ่านใช่ไหม

มีค่าใช้จ่ายไหม

เวลารอใช่ไหม

ในกรณีนี้ หากคุณไม่ได้ทำงานที่ยากมากนัก คุณอาจพิจารณาใช้โมเดลที่เร็วกว่าซึ่งทำงานได้ถูกกว่าและเร็วกว่า ทั้งนี้ขึ้นอยู่กับประเภทงานที่คุณทำ

แต่ต้นทุนและความเร็วจะบอกคุณได้เพียงว่าตัวแทนทำงานอย่างไร แต่ไม่ได้บอกว่าเหตุใดจึงไม่ผ่านการทดสอบส่วนใหญ่

เราจึงตรวจสอบการเรียกใช้ที่ล้มเหลว และพบว่า Agent มักจะหยุดทำงานก่อนเวลาอันควร

พวกเขาเชื่อว่าตนเองทำเสร็จแล้ว

งานเสร็จสมบูรณ์

โอเค ฉันจะกลับบ้าน

แต่ดังที่กล่าวไว้ ในแพ็กเก็ตงาน ตัวแทนจะได้รับเฉพาะวิธีการและสถานะก่อนหน้า

โดยผู้ใช้จะไม่เห็นการทดสอบ

ผู้ใช้เห็นว่าตนเองไม่สามารถดูชุดการยืนยันได้

เราจึงถามว่า จะเกิดอะไรขึ้นถ้าเราให้พวกเขาดูการทดสอบ

เราจึงทำการทดลองและมีตัวแปรการทดสอบแบบเปิดของงานเดียวกัน โดยที่ Agent ได้รับชุดโปรแกรมทดสอบการยืนยันที่ล้มเหลวล่วงหน้า

ตอนนี้พวกเขาจึงทำการทดสอบซ้ำๆ

โดยสามารถตรวจสอบข้อผิดพลาด ปรับแต่งโค้ดในรายงานความคิดเห็น

และเราพบว่าเมื่อตัวแทนเห็นการทดสอบ พวกเขาจะพยายามมากขึ้นและทำงานนานขึ้น

และในการรันแบบเปิด พวกเขามีเทิร์นเพิ่มขึ้น 25% และรันไทม์ของเอเจนต์ 40%

พวกเขาใช้เวลาเกือบ 30 นาทีต่องานในการเรียกใช้และแก้ไขการทดสอบที่ล้มเหลว เนื่องจากไม่ได้ทำการแก้ไขข้อบกพร่องแบบสุ่มสี่สุ่มห้า

ดังนั้นพวกเขาจึงเห็นสิ่งที่ล้มเหลวอย่างชัดเจน และน่าเสียดายที่อัตราการผ่านก็เพิ่มขึ้นเกือบ 50 เปอร์เซ็นต์ด้วย

และความพยายามเพิ่มเติมนี้จะช่วยปรับปรุงอัตราการผ่านโดยเฉลี่ยตามที่ได้กล่าวไปแล้ว

แต่ในที่สุด Frontier Model ใหม่ๆ ก็เกิดขึ้น และเข้ามาแทนที่ตัวแปรแบบเปิดนี้อย่างรวดเร็ว

เกือบ 90% ของอัตราการผ่าน

ดังนั้น เราจึงใช้ตัวแปรการทดสอบแบบปิดของการค้นหาแบบปิดเป็นเมตริกการเปรียบเทียบหลัก

แต่ก็น่าสนใจมากที่ได้เห็นว่าโมเดลทำงานได้ดีขึ้นเมื่อรู้ว่าตนเองได้รับการประเมินจากอะไร

Tomáš Mlynarič

อย่างไรก็ตาม การดำเนินการนี้ช่วยให้เราสร้างข้อมูลเชิงลึกเกี่ยวกับตัวแทนได้มากขึ้น

เช่น เราสามารถตรวจสอบวิธีที่โมเดลทดสอบงานของตนเองได้จริงๆ

ดังนั้น เราจะเห็นได้จากแผนภูมิว่า Frontier Model เขียนการทดสอบที่ดีขึ้นเรื่อยๆ และมีอัตราการผ่านที่สูงขึ้น

โมเดลอื่นๆ บางโมเดลอาจมั่นใจเกินไปว่า "ฉันทำได้ ไม่ต้องทดสอบ"

บางครั้งก็ยังใช้ได้อยู่นะ

ดังนั้น หากคุณใช้โมเดลที่ไม่ค่อยเก่งเรื่องการทดสอบ คุณสามารถช่วยโมเดลเหล่านั้นได้ด้วยทักษะการทดสอบที่ดีขึ้นหรือคำแนะนำที่เฉพาะเจาะจงเกี่ยวกับวิธีเขียนการทดสอบ

แต่ความสัมพันธ์ไม่ได้หมายถึงความเกี่ยวข้องนะ CS ใช่ไหม

เราจำเป็นต้องมีการทดสอบที่มีการควบคุมในเรื่องนี้จริงๆ

เรายังคงต้องทำการทดสอบว่าการแจ้งให้ทำการทดสอบที่ดีขึ้นจะช่วยเพิ่มคะแนนได้จริงหรือไม่

อย่างไรก็ตาม เราได้ทำการทดสอบอีกครึ่งหนึ่งของการทดสอบ Android ซึ่งเป็นการให้ Agent ใช้โปรแกรมจำลอง

ก่อนหน้านี้ ในการเปรียบเทียบ เราไม่ได้พูดถึงโปรแกรมจำลองเลย

เราคิดว่าตัวแทนควรจะเข้าใจเรื่องนี้ใช่ไหม

ดังนั้น เราจึงเห็นว่าผลลัพธ์ที่ได้คือแทบไม่มีใครเปิดโปรแกรมจำลองเลย

และอย่างที่บอกไป การทดสอบ UI มีความสำคัญอย่างมากในการเปรียบเทียบ และหากไม่มีโปรแกรมจำลอง คุณจะใช้การทดสอบ UI ไม่ได้เลย

ดังนั้น นักเรียนทุกคนจึงล้มเหลวในเรื่องที่ง่ายมาก

ตอนนี้เราจึงเผชิญกับภาวะที่กลืนไม่เข้าคายไม่ออก

เราควรบอกตัวแทนว่าคุณต้องใช้โปรแกรมจำลองและเสี่ยงที่จะได้คะแนนสูงขึ้น หรือเราไม่ควรพูดอะไรเลยและหวังว่าพวกเขาจะคิดออกเอง

แต่ท้ายที่สุดแล้ว เป้าหมายของเราคือการเป็นเกณฑ์มาตรฐานที่ยุติธรรมในการวัดการเขียนโค้ดและการแก้ปัญหาของ Android

เราไม่ต้องการวัดค่า เช่น ความผิดปกติบางอย่างของสภาพแวดล้อม

เราจึงเลือกที่จะพบกันครึ่งทาง

เราบอกวิธีเริ่มใช้โปรแกรมจำลอง แต่ไม่ได้พูดถึงว่าจะใช้หรือไม่ใช้

เพราะการเริ่มโปรแกรมจำลองไม่ใช่สิ่งที่เราต้องทดสอบหรือต้องการทดสอบจริงๆ

และเราได้วัดผลของคำสั่งโปรแกรมจำลองนั้น

และตอนนี้เราเห็นแล้วว่าเมื่อเราให้วิธีการ ตัวแทนจะบูตโปรแกรมจำลองมากขึ้นและทำการทดสอบ UI จริงๆ ซึ่งส่งผลอย่างมากต่ออัตราการผ่าน แต่น่าเสียดายสำหรับเรา

แต่ยังช่วยให้เราตรวจสอบข้อผิดพลาดและปัญหาในการเขียนโค้ดจริงได้ด้วย ไม่ใช่แค่การทำงานล้มเหลวในโปรแกรมจำลองที่ไม่ได้เปิดเครื่อง

ดังนั้น สรุปได้ว่าความเฉพาะเจาะจงของพรอมต์ยังคงมีความสำคัญอย่างมาก และหากคุณกำลังออกแบบการเปรียบเทียบหรือการประเมินของคุณเอง คุณต้องทดสอบสิ่งที่สำคัญจริงๆ ในกรณีของคุณ

เช่น สมมติว่าคุณกำลังประเมินประสิทธิภาพของโทเค็นหรือทักษะหรือเครื่องมือ อย่างแรก คุณต้องเริ่มด้วยการประเมินที่ผ่านก่อน จากนั้นทำการเปลี่ยนแปลงเพื่อเพิ่มประสิทธิภาพ แล้วจึงตรวจสอบว่ายังคงผ่านอยู่แม้จะใช้โทเค็นน้อยลง

หากทำอย่างอื่น คุณจะมีตัวแปรมากเกินไปที่เปลี่ยนแปลงพร้อมกันทั้งหมด และคุณจะไม่ทราบว่าการเปลี่ยนแปลงนั้นทำให้ดีขึ้นจริงหรือไม่

Tomáš Mlynarič

กลับไปที่ลีดเดอร์บอร์ด

อย่างที่บอกไป โมเดลที่ดีที่สุดผ่านงานประมาณ 40% และอัตราการผ่านกำหนดให้การตรวจสอบทั้งหมดต้องผ่าน

ไม่เช่นนั้น งานจะล้มเหลว

คำถามคือ ตัวแทนไม่ได้สร้างสิ่งที่เป็นประโยชน์เลยใช่ไหมในอีก 60% ที่เหลือ

ไม่หรอก พวกเขากำลังพยายามอยู่

เพื่อแสดงให้เห็นว่า Agent เข้าใกล้โซลูชันที่ใช้งานได้จริงมากเพียงใด ซึ่งคล้ายกับระยะทาง เรายังคำนวณอัตราความสำเร็จหรือคะแนนบางส่วนด้วย

นี่คือคะแนนถ่วงน้ำหนักใน 4 หมวดหมู่ ได้แก่ ความสอดคล้องของภาพ ฟังก์ชันการทำงาน การทำงานที่ถูกต้อง ข้อกำหนดเฉพาะบางอย่างต่องาน และการตรวจสอบการถดถอยบางอย่าง

และคุณจะเห็นว่าโมเดลที่มีอันดับต่ำกว่าสามารถทำงานได้ประมาณครึ่งหนึ่ง ขณะที่ Frontier Model สามารถทำงานให้เสร็จและได้คะแนนเกือบ 80% โดยเฉลี่ย ซึ่งมากกว่า 80% ของงาน แต่ก็ผ่านเพียง 40% เท่านั้น

เราจึงทำการทดสอบการแปลง Flutter เป็น Android เพื่อดูว่าเกิดอะไรขึ้น

เราจึงคำนวณอัตราความสำเร็จใหม่ทุกๆ 2-3 ขั้นตอนของ Agent และเราเห็นรูปแบบเดียวกันใน Frontier Model ทั้งหมด

โดยใช้เวลาประมาณ 140 ขั้นตอนในการพยายามทำคะแนนให้ได้เกือบ 90% โดยเฉลี่ย จากนั้นก็ใช้เวลาอีก 90 ขั้นตอนหรือเกือบ 40% ของการรันเพื่อพยายามปิดช่องว่างให้ได้ 100% แต่ก็ทำคะแนนเพิ่มได้เพียง 1% หรือ 2% เท่านั้น

และเราคิดว่านี่เป็นภาพสะท้อนของการพัฒนาแบบ Agentic ในปัจจุบัน ซึ่งนักพัฒนาซอฟต์แวร์หรือผู้ใช้ที่ไม่มีประสบการณ์จะเห็นว่าแอปเสร็จสมบูรณ์แล้ว

ทุกอย่างกำลังแสดงผล

อินพุตใช้งานได้ในระดับหนึ่ง

อาจไม่มีข้อขัดข้อง

แต่เมื่อวิศวกรอาวุโสมาดูโค้ด พวกเขาก็จะเห็นข้อบกพร่องมากมาย เช่น ปัญหาด้านสถาปัตยกรรม ข้อบกพร่องในวงจร และอื่นๆ

Tomáš Mlynarič

สรุปแล้ว เรามาดู Android Bench ซึ่งเป็น Work 2.0 ของเราในมุมมองที่กว้างขึ้นกัน

เมื่อเทียบกับเวอร์ชัน 1.0 ตอนนี้เรามีงานเพียง 30 รายการ ซึ่งเป็นความตั้งใจของเรา

เรามีหน้าจอที่สมบูรณ์ การย้ายข้อมูลหลายโมดูล และการแปลงแอปทั้งหมด แทนที่จะเป็นการแก้ไขข้อบกพร่องแบบแยกส่วนและแพตช์ขนาดเล็ก

ตอนนี้แพตช์มีขนาดใหญ่ขึ้นอย่างมากในไฟล์หลายสิบไฟล์

และเรามีการตรวจสอบ UI แบบหลายโมดัล

ตัวแทนต้องทำงานนานขึ้นและหนักขึ้นมาก

หากเปรียบเทียบกับเกณฑ์มาตรฐานอื่นๆ ที่ล้ำสมัย เราจะเห็นว่าเกณฑ์มาตรฐานของเรายังคงต้องมีการเปลี่ยนแปลงโค้ดที่ใหญ่กว่ามาก

ซึ่งไม่มีการปนเปื้อนเนื่องจากงานส่วนใหญ่เขียนขึ้นใหม่ทั้งหมด และยังมีโอกาสเติบโตอีกมาก

อย่างที่ผมบอกไปตอนต้นว่าเวลาไม่กี่เดือนในโลก AI นั้นดูเหมือนยาวนานมาก และในที่สุด เกณฑ์มาตรฐานทุกอย่างก็ถึงขีดจำกัดและอิ่มตัว

และเมื่อถึงจุดนั้น เราหวังว่าจะได้ผลักดันไปสู่งานที่ยากและซับซ้อนยิ่งขึ้น ซึ่งจะสอดคล้องกับยุคนั้นด้วยสถานะของ AI ในขณะนั้นอีกครั้ง

ตอนนี้ ให้ใช้ Android Bench เป็นเข็มทิศเพื่อเปรียบเทียบโมเดลและ Harness และอาจเรียนรู้ข้อมูลเชิงลึกบางอย่าง

และเมื่อคุณพร้อมที่จะเจาะลึกมากขึ้น ให้นำหลักการเปรียบเทียบและหลักการประเมินเดียวกันนี้ไปใช้กับฐานของโค้ดและเวิร์กโฟลว์ของคุณเอง เพราะไม่มีอะไรดีไปกว่าการวัดประสิทธิภาพ AI ด้วยโค้ดที่คุณใช้ทำงานจริง

ซึ่งจะช่วยให้คุณเปลี่ยนจากการหวังว่า AI จะทำได้ถูกต้องไปสู่การรู้ว่า AI ทำได้ถูกต้อง

ในนามของ Android Bench ทั้งหมด ขอขอบคุณที่ให้ความสนใจ