เวิร์กโฟลว์การเขียนโค้ดแบบ Agent ด้วยโมเดลขนาดเล็ก

โอเค

สวัสดีทุกคน

ฉันชื่อ Jose และฉันอยู่กับ Ian และ Zoe

เราทุกคนต่างรู้จัก LLM

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

มี LLM ขนาดใหญ่มาก เช่น โมเดล Gemini ที่สามารถทำสิ่งต่างๆ ได้อย่างน่าทึ่ง แต่ในการพูดคุยครั้งนี้ เราจะพูดถึงโมเดลภาษาขนาดเล็ก

นอกจากนี้ โมเดลเหล่านี้ยังเป็น LLM ด้วย เพราะโมเดลที่มีพารามิเตอร์ 4 พันล้านรายการจะเรียกว่าเล็กไม่ได้ แต่เราจะแยกความแตกต่างระหว่าง Frontier Model กับโมเดลภาษาขนาดเล็กนับจากนี้ไป ซึ่งก็เหมือนกับจรวดและจักรยาน

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

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

สำหรับการพูดคุยครั้งนี้ ผมได้ทำการเปรียบเทียบประสิทธิภาพหลายอย่าง และหนึ่งในนั้นคือชุดข้อมูลของงานระดับปานกลางและยาก 200 งานที่ใช้โทเค็นเกือบ 131 ล้านรายการในราคาไม่ถึง $9

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

แล้ว Frontier Model จะมีค่าใช้จ่ายเท่าใด

ประมาณ 20 ถึง 200 เท่า ทั้งนี้ขึ้นอยู่กับการแคชโทเค็นและปัจจัยอื่นๆ

ดังนั้น จักรยานอาจไม่ใช่วิธีการเดินทางที่เร็วที่สุด แต่เป็นวิธีที่มีประสิทธิภาพมากที่สุดอย่างแน่นอน

ไม่ได้โม้

คำถามที่ชัดเจนในตอนนี้คือคุณภาพและความแม่นยำแตกต่างกันอย่างไร

ในชุดข้อมูลนี้ Gemma 4 สามารถแก้โจทย์ได้ 53%

ซึ่งหมายความว่า

หากคุณใช้ Frontier Model เพื่อเรียกใช้งานเหล่านี้ทางด้านซ้าย อาจเป็นการใช้ทรัพยากรมากเกินไป

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

ในการพูดคุยครั้งนี้ เราต้องการช่วยให้คุณใช้ประโยชน์จากทุกโทเค็นได้มากขึ้น

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

จากนั้นฉันจะแสดงวิธีลองใช้ Gemma 4 ใน Android Studio อย่างรวดเร็ว และสุดท้าย เราจะแสดงวิธีนำโมเดลขนาดเล็กมาใช้ในเวิร์กโฟลว์ประจำวัน รวมถึงการเปรียบเทียบการพัฒนา Android จริงเพื่อช่วยให้คุณเข้าใจสิ่งที่โมเดลเหล่านี้ทำได้

ขอเชิญ Zoe

ขอบคุณมาก Jose

ดังนั้น การใช้โมเดลเดียวสำหรับทุกอย่างจึงเหมือนกับการใช้ค้อนปอนด์ทุบถั่วใช่ไหม

วิธีนี้มีประสิทธิภาพ แต่ก็ไม่สมดุลกันสักเท่าไร

ดังนั้นเมื่อนึกถึงโมเดลขนาดเล็ก ก็เหมือนกับว่าคุณกำลังขยายชุดเครื่องมือของตัวเอง

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

ดังนั้น หากต้องการเลือกโมเดลขนาดเล็ก คุณต้องรู้จักโมเดลขนาดเล็ก

และประเภทของโมเดลที่คนส่วนใหญ่นึกถึงเมื่อพูดถึงโมเดลภาษาคือโมเดลภาษาแบบถดถอยอัตโนมัติ

ซึ่งเป็นแบบถดถอยอัตโนมัติ (Autoregressive) เนื่องจากจะเลือกโทเค็นถัดไปที่มีแนวโน้มมากที่สุดจากรายการตัวเลือก โดยอิงตามอินพุตที่แบ่งเป็นโทเค็น

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

เราจึงทำงานแบบไม่เป็นเส้นตรงได้

โมเดลการแพร่กระจายมีแนวทางเดียวกัน แต่จะทำงานกับบล็อกโทเค็นทีละบล็อก

เหมือนภาพสเก็ตช์ที่ค่อยๆ ชัดเจนขึ้น

และในกรณีนี้ DiffusionGemma จะทำงานกับกลุ่มโทเค็นขนาด 256 รายการพร้อมกัน

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

ชุดเครื่องมือของเรามีโมเดลที่เขียนได้ใช่ไหม

ผิด

โดยพื้นฐานแล้ว โมเดลการฝังจะเปลี่ยนออบเจ็กต์ เช่น รูปภาพ ข้อความ หรือแนวคิดอื่นๆ ให้เป็นเวกเตอร์

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

ตัวอย่างเช่น หากฮอตดอกเป็นแซนด์วิช ก็มีแนวโน้มที่จะอยู่ใกล้กันหรืออยู่ในพื้นที่ใกล้เคียงกัน

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

และยังมีโมเดลขนาดเล็กและโมเดลเฉพาะทางที่ทำงานได้เพียงอย่างเดียว แต่ทำได้ดีมาก

ตัวอย่างเช่น เรามีโมเดลฟังก์ชันที่เปลี่ยนภาษาธรรมชาติเป็นการเรียก API, โมเดลการมองเห็นที่ชื่อก็บอกอยู่แล้วว่าทำอะไรได้บ้าง หรือตัวแยกประเภทที่ให้คะแนนอินพุตตามพารามิเตอร์บางอย่าง

มีตัวเลือกมากมายให้เลือกใช่ไหม

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

แล้วคุณจะเลือกโมเดลขนาดเล็กได้อย่างไร

มาเริ่มกันที่การเปิดกล่องเครื่องมือของโมเดลขนาดเล็กแบบเปิดที่ทำงานในเครื่องได้ ซึ่งก็คือโมเดล Gemma

ขอเชิญ Ian

ขอบคุณ Zoe

ดังนั้น อย่างที่ Jose พูดถึงในตอนต้น โมเดลภาษาขนาดเล็กอาจทำงานได้ประมาณ 50% ของงานทั้งหมดโดยไม่ต้องปรับแต่ง

แต่เหตุใดคุณจึงควรเลือกโมเดลในเครื่องโดยเฉพาะ

สรุปได้ว่ามี 4 สิ่งที่ต้องพิจารณา

ข้อแรกคือความเป็นส่วนตัว

ตัวอย่างเช่น คุณอาจมีคีย์ API, โค้ดที่เป็นกรรมสิทธิ์ หรือสิ่งต่างๆ ที่ไม่สามารถออกจากแล็ปท็อปของคุณได้

ปัจจัยที่ 2 คือเวลาในการตอบสนอง

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

ดังนั้นจึงไม่มี Round-trip time (RTT) ไปยังเซิร์ฟเวอร์ และไม่มีเวลาในการตอบสนองเพิ่มเติม

ถัดไปคือต้นทุนส่วนเพิ่มเป็นศูนย์

ดังนั้น โมเดลจึงคุ้มค่าเมื่อคุณควบคุมตำแหน่งที่โมเดลทำงานได้

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

คุณไม่ต้องเสียค่าใช้จ่ายใดๆ และจะไม่มีค่าใช้จ่าย API ที่ไม่คาดคิดสำหรับส่วนนั้น

และสุดท้ายคือการเข้าถึงแบบออฟไลน์

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

ฟังดูดีใช่ไหม แต่มีปัจจัยสำคัญ 2 ประการที่เราต้องพิจารณาเมื่อทำการตัดสินใจเหล่านี้

อย่างแรกคือหน่วยความจำ และอย่างที่ 2 คือความเร็ว

ดังนั้น หากคุณดูแผนภาพนี้ หากคุณดูโมเดล 2 โมเดลด้านล่าง ได้แก่ 26B และ 31B ทั้ง 2 โมเดลใช้ Video RAM มากกว่า 50 GB เพื่อรันใน BF16 ซึ่งเป็นการ Quantization แบบ 16 บิต

ดังนั้น ความท้าทายในที่นี้คือโมเดลดังกล่าวจะไม่พอดีกับฮาร์ดแวร์จำนวนมาก

สิ่งที่เราทำคือกระบวนการที่เรียกว่าการควอนไทเซชัน ซึ่งจะลดความแม่นยำลงเหลือ 4 บิตเป็นแบบ Float

ตอนนี้ก็ดูสมเหตุสมผลขึ้นมาหน่อย

เรากำลังพูดถึง 14 GB และ 17 GB ใช่ไหม

ซึ่งตอนนี้สามารถใส่ลงในอุปกรณ์อย่าง Mac ที่มีหน่วยความจำแบบรวมได้แล้ว

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

ซึ่งเรียกว่าการฝึกที่คำนึงถึงการแปลงค่าต่อเนื่องเป็นค่าแบบไม่ต่อเนื่อง (Quantization-Aware Training)

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

ดังนั้น เราจึงลดความต้องการ RAM ลงได้ 75% และตอนนี้ก็สามารถติดตั้งในอุปกรณ์เหล่านั้นได้แล้ว

และเรายังก้าวไปอีกขั้น

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

เราจึงมี Quantization แบบผสม

ดังนั้นเราจึงลดขนาด Gemma E2B จาก 11.4 GB เหลือ 1.1 GB

ดังนั้นตอนนี้จึงสมเหตุสมผลมากขึ้นสำหรับโทรศัพท์ระดับกลางถึงระดับไฮเอนด์

ปัจจัยถัดไปคือความเร็ว

ดังนั้นเมื่อคุณใช้โมเดลแบบถดถอยอัตโนมัติอย่างที่ Zoe พูดถึง คุณกำลังคาดการณ์ชุดโทเค็นถัดไป

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

สิ่งที่คุณทำได้คือใช้เทคนิคที่เรียกว่า Speculative Decoding

ซึ่งจะใช้โมเดลร่างขนาดเล็กเพื่อคาดการณ์จำนวนโทเค็นที่โมเดลขนาดใหญ่จะตรวจสอบความถูกต้อง

และเหตุผลที่วิธีนี้ใช้ได้ในสถาปัตยกรรม Gemma 4 ก็คือโมเดลเหล่านี้ใช้แคช KV ร่วมกัน

ดังนั้น ให้คิดว่านี่เป็นเหมือนหน่วยความจำระยะสั้นของโมเดล

ดังนั้น สิ่งที่จะเกิดขึ้นคือโมเดลร่างขนาดเล็กจะคาดการณ์โทเค็น 3 หรือ 4 รายการล่วงหน้า จากนั้นโมเดลขนาดใหญ่จะดูแคช KV เดียวกันนั้นและตรวจสอบความถูกต้องของเอาต์พุต

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

ดังนั้นจึงขึ้นอยู่กับงานที่คุณทำอยู่ด้วย

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

แล้วคุณจะประเมินโมเดลเหล่านี้อย่างไร

ดังนั้น สิ่งที่ชัดเจนที่สุดที่คุณอาจทำคือไปดูการเปรียบเทียบ เช่น LiveCodeBench หรือ MMLU แล้วดูคะแนน

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

สิ่งที่คุณต้องทำจริงๆ คือประเมินสแต็กทั้งหมดที่โค้ดทำงานอยู่

ซึ่งก็คือโมเดลที่คุณใช้ น้ำหนัก และแนวทางการทำ Quantization ซึ่งเป็นการอนุมานของรันไทม์ ดังนั้นคุณอาจใช้บางอย่าง เช่น llama.cpp, Ollama หรือ LiteRT, ระบบควบคุมการทำงานของ Agent ที่คุณใช้ ไม่ว่าจะเป็น Pi, OpenCode หรือ Antigravity และหน้าต่างบริบท ซึ่งเป็นพื้นที่สำหรับข้อมูลทั้งหมดที่คุณต้องการให้โมเดลประมวลผลได้

และปัจจัยทั้งหมดนี้รวมกันจะส่งผลต่อความเป็นไปได้ของช่อง

ขอยกตัวอย่างสั้นๆ เราได้ทำการทดสอบ Gemma 4 ใน Android Bench และใช้ Ollama เวอร์ชันที่มีบริบท 32k เริ่มต้น

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

ดังนั้น เพียงแค่เพิ่มบริบทจาก 32,000 เป็น 256,000 ตอนนี้โมเดลก็สามารถเก็บข้อมูลนั้นไว้ในหน่วยความจำ และผ่านการทดสอบนั้นได้

และเราพบว่าอัตราความสำเร็จของงานนั้นเพิ่มขึ้นเป็น 2 เท่า

ดังนั้นจึงแสดงให้เห็นว่าแม้แต่ปัจจัยเล็กๆ เพียงปัจจัยเดียวก็อาจส่งผลอย่างมากต่อความเหมาะสมของรูปแบบนี้

แล้วคุณจะประเมินด้วยตนเองได้อย่างไร

เราจึงมีคำแนะนำสั้นๆ 3 ข้อมาฝาก

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

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

เรามีตัวอย่างดีๆ 2 ตัวอย่างที่แสดงให้เห็นถึงเรื่องนี้

เรามีคอมไพเลอร์และ Unit Test

ไม่ว่าจะสร้างอะไรขึ้นมา คุณก็สามารถนำไปทดสอบผ่านเครื่องมือดังกล่าวได้ ซึ่งจะบอกว่าผ่านหรือไม่ผ่าน เพื่อให้ทราบว่าคุณทำภารกิจนั้นสำเร็จหรือไม่

และส่วนที่ 3 คือวิถีการบันทึก

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

และผมอยากให้คุณลองเปลี่ยนกรอบคำถามจาก "โมเดลนี้ฉลาดเท่ากับ Frontier Model ขนาดใหญ่นี้ไหม"

ไปจนถึง "งานนี้สามารถทำได้บนฮาร์ดแวร์นี้ด้วยการกำหนดค่านี้หรือไม่"

และเพื่อหาคำตอบนั้น เราได้คิดค้นเฟรมเวิร์กที่เรียกว่า "เราถึงจุดหมายหรือยัง"

หรือ AWTY

และหลักการทั้งหมดของเฟรมเวิร์กนี้คือการให้คะแนนบนแกนนั้นสำหรับงานต่างๆ เหล่านี้ในแง่ของความพร้อม

ซึ่งก็คือตัวโมเดลเอง เครื่องมืออนุมานที่คุณใช้ ชุดทดสอบ และการกำหนดค่าฮาร์ดแวร์

ซึ่งจะบอกให้คุณทราบว่าคุณพร้อมแล้วหรือยัง

ตัวอย่างเช่น คุณอาจดูว่างานนั้นๆ มีความน่าเชื่อถือเพียงใด

ถ้าคุณรันมัน 10 ครั้งติดต่อกัน มันจะทำแบบเดิมทุกครั้งไหม

คุณอาจกำลังดูเวลาในการตอบสนอง

คุณอาจต้องการให้เป็นการตอบกลับแบบเรียลไทม์

คุณมีเกณฑ์อะไรบ้างสำหรับความเร็วในการทำงาน

จากนั้นคุณอาจต้องดูข้อกำหนดเกี่ยวกับ RAM ด้วย

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

คุณใช้ RAM ได้ 50% หรือใช้ได้แค่ 10%

และคุณจะได้รับคะแนนความพร้อมขั้นสุดท้ายนี้

ดังนั้น หากเป็นสีเขียว แสดงว่าการกำหนดค่าพร้อมใช้งานแล้ว

หากเป็นสีส้ม สีเหลือง หรือสีแดง แสดงว่าคุณอาจต้องเปลี่ยนแปลงบางอย่างเกี่ยวกับการกำหนดค่า

คุณอาจต้องใช้ตัวเร่งที่เร็วขึ้นเพื่อให้เวลาในการตอบสนองต่ำลง หรืออาจต้องใช้โมเดลที่ใหญ่ขึ้นซึ่งมีความสามารถมากกว่า

เราจึงขอแนะนำให้คุณลองดูรายงานนี้

ตอนนี้เรามีเวอร์ชันตัวอย่างและอยากทราบความคิดเห็นของคุณเกี่ยวกับประโยชน์ของเครื่องมือนี้

Zoe จะอธิบายเพิ่มเติมเกี่ยวกับวิธีที่เราตั้งค่าการประเมินบางอย่างในภายหลัง แต่ตอนนี้ฉันจะส่งต่อให้ Jose ซึ่งจะแสดงวิธีเริ่มต้นใช้งาน Gemma 4 อย่างรวดเร็ว

ขอบคุณ Ian

ดังนั้น วิธีที่เร็วที่สุดในการลองใช้ Gemma 4 ในปัจจุบันน่าจะเป็นผ่าน Android Studio

มาดูวิธีกันเลย

โปรดเปลี่ยนไปใช้แล็ปท็อป

นั่นไงล่ะ

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

ฉันแค่ต้องดาวน์โหลดโมเดลลงในฮาร์ดไดรฟ์

ซึ่งจะเปิดหรือเริ่มเซิร์ฟเวอร์ llama.cpp และกำหนดค่าอย่างถูกต้องให้คุณตั้งแต่เริ่มต้น

แต่คุณก็สามารถใช้เซิร์ฟเวอร์ llama.cpp ของคุณเอง หรือ Ollama หรือ LM Studio ได้ตามต้องการ

คุณเพียงแค่มาที่นี่และเพิ่มผู้ให้บริการในพื้นที่

นอกจากนี้ การใช้โมเดลขนาดเล็กผ่านผู้ให้บริการระยะไกลก็เป็นเรื่องที่สมเหตุสมผลอย่างยิ่ง

คุณจึงเพิ่มคีย์ได้ที่นี่ ตราบใดที่คีย์นั้นเข้ากันได้กับ OpenAI หรือ Anthropic คุณก็เชื่อมต่อได้

เอาล่ะ มาดูกัน

ตอนนี้คุณเลือกโมเดลใน Android Studio ได้ผ่านเมนูแบบเลื่อนลงนี้

ฉันเลือก Gemma 4 26B ไว้ และสามารถถามว่า "ViewModel คืออะไร"

ตกลง

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

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

ตอนนี้เรากลับไปที่สไลด์และ Zoe เพื่อดูเวิร์กโฟลว์ต่างๆ ที่คุณเรียกใช้ด้วยโมเดลขนาดเล็กได้

ขอบคุณมาก Jose และขอบคุณ Ian สำหรับภาพรวมเกี่ยวกับโมเดล Gemma และเรามาถึงจุดนั้นแล้วหรือยัง

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

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

ถูกต้องไหม

นี่คือสิ่งที่เราค่อนข้างมั่นใจว่าทุกคนทำอยู่แล้ว แม้ว่าอาจจะไม่รู้ตัวก็ตาม

แต่เราอยากกระตุ้นให้คุณคิดนอกกรอบ

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

ถูกต้องไหม

เรากำลังพูดถึงการไม่ใช้จรวด แล้วทำไมเราจึงใช้สมองแทนล่ะ

ดังนั้น หากเราก้าวข้ามขีดจำกัดนั้นไปได้ โมเดลขนาดเล็กจะทำอะไรได้บ้าง

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

ตัวอย่างเช่น การตรวจสอบว่าเอกสารประกอบเป็นปัจจุบันอยู่เสมอตามการเปลี่ยนแปลงที่คุณทำ หรือการตรวจสอบว่าคุณมีการทดสอบการถดถอยอัตโนมัติซึ่งเป็นส่วนหนึ่งของ Pre-commit Hook หรือแม้แต่การตรวจสอบว่าบริบทที่ Agent อาจได้รับซึ่งเป็นส่วนหนึ่งของเวิร์กโฟลว์ได้รับการเพิ่มประสิทธิภาพแล้ว และทำงานได้เร็วยิ่งขึ้น

นี่เป็นเพียงตัวอย่างบางส่วนเท่านั้น

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

แต่ถึงแม้จะมีข้อกำหนด เครื่องมือ และเวิร์กโฟลว์แล้ว คุณก็ยังไม่แน่ใจว่าจะเริ่มจากตรงไหนใช่ไหม

การเปรียบเทียบจะช่วยคุณได้ในเรื่องนี้

และอย่างที่ Ian กล่าวไว้ ตารางอันดับทั่วไป โดยเฉพาะตารางอันดับสำหรับ Python จะบอกคุณได้เพียงเล็กน้อยว่าโมเดลขนาดเล็กจะเป็นประโยชน์ต่อเวิร์กโฟลว์ Android ของคุณหรือไม่

เช่นเดียวกับที่สว่านเจาะผนังเบาอาจบอกอะไรคุณไม่ได้มากนักเกี่ยวกับสว่านเจาะคอนกรีต

แต่คุณควรลงทุนในการประเมินของคุณเอง

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

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

และมี 3 สิ่งที่คุณควรพิจารณาเมื่อประเมินการเปรียบเทียบ

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

มีความเจาะจงเพียงใด

ดูเหมือนงานประเภทที่คุณจะมอบหมายให้ทำไหม

ส่วนที่ 2 คือขอบเขตของงาน

เช่น การเขียนเอกสาร การแก้ไข PR หรืออะไรที่ดูเหมือนงานที่คุณทำอยู่

และสุดท้าย ความซับซ้อนของระบบคล้ายกับความซับซ้อนที่คุณจะมอบให้หรือไม่

และนี่คือจุดที่เราจะเห็นว่าเหตุใดการเปรียบเทียบ Python จึงไม่สามารถเป็นตัวแทนของ Android ได้มากนัก

เราจึงสร้าง Android Bench ซึ่งเป็นเกณฑ์มาตรฐานที่บันทึกระบบนิเวศของ Android และการทำงานของ Android

เวอร์ชันแรกมีงาน Android ขนาด PR 100 รายการ และคุณสามารถเรียกใช้ด้วยตนเองได้ตั้งแต่วันนี้ผ่าน Harbor เพื่อตรวจสอบชุดค่าผสมของ Agent, โมเดล และทักษะต่างๆ

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

ตอนนี้ฉันขอส่งต่อให้ Jose เพื่อแสดงผลลัพธ์ที่เราได้รับจากวิธีนี้และวิธีที่คุณสามารถเพิ่มประสิทธิภาพการทำงานกับโมเดลขนาดเล็ก

โอเค ขอบคุณนะ Zoe

เอาล่ะ มาดูงานที่โมเดลขนาดเล็กสามารถแก้ปัญหาได้ และจุดที่โมเดลเริ่มมีปัญหา

และเราจะกำหนดงาน 4 หมวดหมู่ตามอำเภอใจ ได้แก่ งานขนาดเล็ก ขนาดกลาง ขนาดใหญ่ และงานระยะยาว

งานระยะยาวเป็นงานที่อาจใช้เวลาหลายวันหรือหลายสัปดาห์กว่าที่มนุษย์จะทำเสร็จ

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

อย่างน้อยก็ในครั้งเดียว

เราจะพูดถึงเรื่องนั้นในภายหลัง

โอเค งานเล็กๆ

งานเหล่านี้เป็นงานที่ต้องอ่านและเขียนไฟล์ 1 หรือ 2 ไฟล์ และไม่จำเป็นต้องมีความรู้มากนัก

ตัวอย่างเช่น โมเดลขนาดเล็กค่อนข้างเก่งในเรื่อง Compose อย่างน้อยก็พื้นฐานของ Compose

เช่น ต้องมีระยะห่าง 8 dp ระหว่างองค์ประกอบ หรือใช้ธีมแทนสีที่ฮาร์ดโค้ด หรือแยกสตริง

ซึ่งเป็นเรื่องง่ายมากสำหรับโมเดลขนาดเล็ก

อย่างไรก็ตาม งานนี้ครอบคลุมหัวข้อขั้นสูงกว่า แต่งานก็ยังคงง่ายอยู่

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

ความยากในกรณีนี้คือเรื่องของขอบเขต ไม่ใช่เรื่องของความรู้

ดังนั้น พรอมต์จึงบอกเราว่าควรเพิ่มประสิทธิภาพ Composable ใดและมีปัญหาอะไร นั่นคือมีการจัดองค์ประกอบใหม่ในทุกเฟรม

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

ในกรณีนี้ใช้เวลา 3 นาที และเป็นการเปลี่ยนแปลงเพียงบรรทัดเดียว

โอเค

เราจึงคิดว่าเราเข้าใจโมเดลขนาดเล็กเป็นอย่างดี

มาดูตัวอย่างของงานขนาดเล็กกัน

มาดูงานที่มีความยากปานกลางกัน

โมเดลขนาดเล็กควรจะทำงานส่วนใหญ่ได้

ในงานนี้ จากแอป Pocket Casts, User Agent หายไปจากคำขอ และยังมีข้อผิดพลาดในตรรกะการลองใหม่ด้วย

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

แต่ก็ผ่านไปได้

ซึ่งใช้เวลา 10 นาที

โดยได้แก้ไขไฟล์ 3 ไฟล์

และค่าใช้จ่ายในการดำเนินการผ่าน OpenRouter อยู่ที่ 6 เซนต์

ทีนี้มาดูงานที่ล้มเหลวจากชุดข้อมูลเดียวกันบ้าง

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

ทุกอย่างได้รับการติดตั้งใช้งานอย่างถูกต้องเกือบทั้งหมด แต่ระบบถือว่าค่าของการซิงค์ครั้งแรกจะเป็น -1 แต่จริงๆ แล้วคือ 0

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

เท่านี้เอง

ข้อบกพร่องนี้จะได้รับการตรวจจับหาก Agent เพิ่งเรียกใช้ Unit Test ซึ่งเป็น Unit Test ที่มีอยู่

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

เราเพียงขอให้ตัวแทนแก้ไขปัญหา ไม่ใช่ยืนยันปัญหา

ดังนั้น เราอาจต้องแก้ไขงานเพื่อให้มีขั้นตอนการยืนยัน

เดี๋ยวเราจะพูดถึงเรื่องนี้กันในอีกสักครู่

เอาล่ะ มาพูดถึงงานใหญ่ๆ กันบ้าง

ประมาณครึ่งหนึ่งของงานขนาดใหญ่ตามคำจำกัดความนี้จะผ่านทุกครั้ง

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

แต่ก็มีบางกรณีที่เมื่อคุณดูสิ่งที่เกิดขึ้นจริง คุณจะตระหนักได้ว่าโมเดลนั้นถูกต้องถึง 90%

เรามาเลือกกันสักรายการ

ฉันเลือกอันนี้เพราะมันเป็นแบบร่วนๆ

โดยจะผ่านประมาณครึ่งหนึ่งของเวลาที่เรียกใช้

ดังนั้น ฉันจึงถือว่านี่เป็นขีดจำกัดสูงสุดของสิ่งที่โมเดลขนาดเล็กทำได้

หรืออย่างน้อยก็เป็นโมเดลจากเดือนเมษายน

เกี่ยวกับวิธีแยกวิเคราะห์ URL ที่มีรูปแบบไม่ถูกต้องในไลบรารี Coil

อย่างที่คุณเห็น คำอธิบาย PR ค่อนข้างครอบคลุม ซึ่งเป็นเรื่องดี แต่ก็ยังขาดข้อกำหนดไปข้อหนึ่ง

มาดูเรื่องนี้กันแบบเร็วๆ

การรันทั้งหมดตรวจสอบการเข้ารหัส URL และข้อผิดพลาดทั่วไป แต่มีเพียงบางส่วน (ครึ่งหนึ่ง) ที่เพิ่มการทดสอบสำหรับอักขระที่เข้ารหัสไม่ถูกต้อง ดังนั้นจึงมีกรอบการทดสอบนั้น

ส่วนแอปที่ไม่ผ่านการประเมินจะถูกปฏิเสธ

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

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

คุณทราบไหมว่าปัจจุบันคุณสามารถตั้งค่าความพยายามใน Agent ได้

เพียงพิจารณาว่ามีการตั้งค่าไว้ต่ำเกินไปเมื่อคุณใช้โมเดลขนาดเล็ก

ดังนั้น เรามากำหนดให้งานขนาดใหญ่เป็นงานที่โมเดลขนาดเล็กอาจทำเสร็จประมาณ 50% ของเวลาทั้งหมด ซึ่งเป็นสิ่งที่ Gemma 4 31B สามารถทำได้เมื่อเทียบกับชุดข้อมูล Android Bench v1 ซึ่งเป็นสิ่งที่ Zoe พูดถึงก่อนหน้านี้

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

แน่นอน และคุณไม่ต้องใช้ความพยายามใดๆ เลย

ก่อนอื่น หากคุณใช้โมเดลอย่าง Gemma 4 ในเครื่องตามที่ Ian พูดถึง ให้ตรวจสอบว่าได้กำหนดค่าอย่างถูกต้อง

ตัวอย่างเช่น หากคุณใช้ Ollama เพื่อแสดง Gemma 4 ระบบจะใช้หน้าต่างบริบทขนาด 32,000 โทเค็นโดยค่าเริ่มต้น ทั้งที่จริงๆ แล้วรองรับได้มากกว่านั้นถึง 8 เท่า

แน่นอนว่าหากคุณใช้ Gemma 4 ผ่าน Android Studio คุณไม่จำเป็นต้องกำหนดค่า

ซึ่งจะได้รับการกำหนดค่าอย่างถูกต้องโดยค่าเริ่มต้น

ในชุดการประเมินของเรา การเปิดใช้บริบททั้งหมดทำให้ผลลัพธ์เพิ่มขึ้นจาก 26% เป็น 53%

จากนั้นใช้ Android CLI ซึ่งเป็นเครื่องมือ Android CLI โดยเฉพาะสำหรับการค้นหาเอกสารประกอบ

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

ซึ่งดีกว่าการใช้เครื่องมือค้นหาเว็บมากจากประสบการณ์ของเรา

ถัดไป ให้เพิ่มคำแนะนำในการยืนยัน

เราได้พูดถึงเรื่องนี้แล้ว

บอกโมเดลว่าจะทำการทดสอบอย่างไร มีการทดสอบประเภทใดบ้าง วิธีจัดการโปรแกรมจำลอง ฯลฯ คุณสามารถทำได้ในไฟล์ AGENTS.md ซึ่งจะทำให้คำสั่งพร้อมใช้งานสำหรับ Agent ทั้งหมด แต่ก็ถือเป็นเรื่องดีอยู่แล้ว

คุณควรมีไว้

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

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

ถัดไป ให้เพิ่มทักษะและนำทักษะออกด้วย

โมเดลขนาดเล็กอาจต้องได้รับการกระตุ้นเมื่อใช้ API ใหม่และ API เฉพาะกลุ่ม แต่ไม่ควรใส่บริบทด้วยทักษะ Compose ทั่วไป เป็นต้น

แล้วงานระยะยาวล่ะ

งานเหล่านี้เป็นงานที่ครอบคลุมไฟล์หลายสิบไฟล์ ต้องมีการตัดสินใจด้านสถาปัตยกรรมที่จริงจัง และโดยปกติแล้วจะจัดการโดยโมเดลการคิดที่สร้างแผนและเริ่มกลุ่ม Agent ย่อย ที่ทำงานต่างๆ

ตัวอย่างงานระยะยาว ได้แก่ การย้ายข้อมูลทั้งแอปจาก XML ไปยัง Compose, การสร้างแอปที่ซับซ้อนตั้งแต่ต้น หรือการแปลงแอปข้ามแพลตฟอร์มเป็น Android แบบเนทีฟ

หากดูผลลัพธ์จาก Android Bench V2 ซึ่งมุ่งเน้นที่ระยะยาวโดยเฉพาะ เราจะเห็นว่า Frontier Model ได้คะแนน 3% ถึง 40%

ดังนั้นสำหรับโมเดลขนาดเล็ก เราพูดได้อย่างเต็มปากว่างานนี้เกินความสามารถของโมเดลเหล่านั้น

อย่างไรก็ตาม การกำหนดเส้นทางการวิเคราะห์เบื้องต้นผ่าน Frontier Model แล้วส่งต่อ (Cascade) งานที่ง่ายกว่าไปยังโมเดลขนาดเล็กกว่าจะช่วยประหยัดโทเค็นและเครดิตได้มากกว่า

มาดูวิธีดำเนินการกัน

กลับไปที่ Zoe

ขอบคุณมาก Jose

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

ดังนั้น การจัดการจึงช่วยให้คุณไม่ถูกบล็อกได้ เป็นต้น ใช่ไหม

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

อีกสิ่งหนึ่งที่คุณทำได้ผ่านการจัดการก็คือการได้คำตอบที่ดีขึ้น

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

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

คุณยังสามารถใช้โมเดลแยกต่างหากเป็นโมเดลทดสอบได้ด้วย

ดังนั้นจึงเหมือนกับการตรวจสอบโดยผู้ทรงคุณวุฒิ

และคุณจะเห็นได้ผ่านสิ่งนี้

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

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

ซึ่งทำได้หลายวิธี ไม่ว่าจะทำในระบบคลาวด์หรือตั้งค่าพร็อกซี LiteLLM เพื่อทำในเครื่องก็ได้

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

เรามาสรุปด้วยการกลับไปที่คำถามที่ Jose ถามไว้ตอนต้นของการพูดคุยกัน ซึ่งก็คือคุณภาพและความแม่นยำระหว่างโมเดลขนาดเล็กกับ Frontier Model แตกต่างกันอย่างไร

คำตอบก็เหมือนกับหลายๆ เรื่องในวิทยาการคอมพิวเตอร์ นั่นคือขึ้นอยู่กับสถานการณ์

อย่างไรก็ตาม สิ่งที่ฉันอยากจะบอกคุณก็คือ คุณสามารถออกแบบสิ่งนี้ได้

คุณสามารถสร้างความแตกต่างได้โดยขึ้นอยู่กับวิธีตั้งค่าและวิธีเล่นกับองค์ประกอบต่างๆ

ดังนั้นสิ่งแรกที่ต้องทำคือเลือกเครื่องมือที่เหมาะสม

เครื่องมือมีหลายประเภท

ทำความรู้จักและสำรวจสิ่งต่างๆ ใช่ไหม

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

ข้อที่ 2 คือตรวจสอบว่าได้ปรับขอบเขตที่โมเดลได้รับเพื่อทำงาน

ตัวอย่างเช่น คำสั่งสำหรับงาน การให้บริบทที่ถูกต้องสำหรับงานและเฉพาะบริบทที่ถูกต้องสำหรับงานเท่านั้น และวิธีตรวจสอบงานของตัวเอง

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

และสุดท้าย คุณต้องตั้งค่าหรือสร้างการประเมินของคุณเอง

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

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

และคุณสามารถเริ่มดำเนินการได้ตั้งแต่วันนี้โดยการตั้งค่ารายการโมเดลที่คัดสรรผ่าน Android Bench และผลการค้นหาที่คุณมี หรือจะเริ่มด้วย Gemma 4 ใน Android Studio วันนี้เลยก็ได้

ขอบคุณมากครับ