- Zed เป็นเอดิเตอร์ที่ออกแบบมาเพื่อความเร็ว และมุ่งเป้ามอบประสบการณ์การแก้ไขแบบ
instant มาโดยตลอด
- เพื่อให้เร็วกว่า
instant ไปอีก จึงนำแนวทาง "คาดการณ์การแก้ไขถัดไปของผู้ใช้" มาใช้
- ด้วยเหตุนี้ Zed จึงเปิดตัวฟีเจอร์ edit prediction ใหม่ ซึ่งทำงานบนพื้นฐานของโมเดลโอเพนซอร์สชื่อ Zeta
- ระหว่างใช้งานสามารถกดปุ่ม
tab เพื่อยืนยันการแก้ไขที่คาดการณ์ไว้ได้ทันที และยังทำการแก้ไขต่อเนื่องหลายขั้นได้
- เป็นฟีเจอร์ที่มีผู้ร้องขอเข้ามามาก และถูกพัฒนาให้ผสานเข้ากับสภาพแวดล้อมการแก้ไขของ Zed อย่างเป็นธรรมชาติที่สุด
- ขณะนี้ในช่วง public beta หากดาวน์โหลด Zed แล้วล็อกอินด้วยบัญชี GitHub ก็สามารถใช้ Zeta ได้ฟรี
- อย่างไรก็ตาม edit prediction อาจไม่ได้ฟรีตลอดไปในอนาคต แต่ตอนนี้เปิดให้ใช้งานเพื่อทดลองและเรียนรู้ร่วมกัน
Thoughtful Integration
- เมื่อเพิ่มฟีเจอร์ edit prediction เข้ามาแล้ว ปุ่ม
tab ก็ทรงพลังขึ้นมาก
- แต่ก็อาจชนกับการใช้งานเดิม เช่น การเยื้องบรรทัดด้วย
tab หรือการดูคำแนะนำจาก language server (LS)
- หากมีคำแนะนำโค้ดจาก language server แสดงอยู่ ต้องกดปุ่ม
option/alt ก่อน จึงจะแสดงตัวอย่างการแก้ไขที่คาดการณ์ไว้
- บน macOS สามารถกด
tab เพื่อยืนยันการแก้ไขที่คาดการณ์ไว้ได้ และเมื่อปล่อย option ก็จะกลับไปยังหน้าคำแนะนำเดิมของ language server
- บน Linux นั้น
alt-tab มักถูกจองไว้โดย window manager จึงตั้งค่าเริ่มต้นเป็น alt-l
- หากในสภาพแวดล้อม Linux ของคุณ
alt-tab ไม่ชนกับอะไร ก็ยังสามารถใช้ได้ตามเดิม
Introducing Zeta: Zed's Open Source Edit Prediction Model
- Zeta เป็นโมเดลโอเพนซอร์สที่พัฒนาบนพื้นฐานของ Qwen2.5-Coder-7B
- มีการเปิดเผยชุดข้อมูลแบบเปิดด้วย(ลิงก์)
- หากคุณทำงานบนรีโพซิทอรีโอเพนซอร์ส ก็หวังว่าจะช่วยมีส่วนร่วมกับชุดข้อมูลเพื่อปรับปรุง Zeta
- ในช่วงแรก ข้อมูลจะถูกนำมาใช้หลังผ่านการตรวจสอบด้านความปลอดภัยและความเป็นส่วนตัว
- ต้องการร่วมกันทำให้ edit prediction กลายเป็นฟีเจอร์ที่ดีขึ้นโดยรวม
- ลิงก์วิดีโอ: How Zed’s Open-Source Edit Predictions Work
Editing By Rewriting
- โมเดลสำหรับการเขียนโค้ดส่วนใหญ่ถูกฝึกด้วยแนวทาง “fill in the middle”
- โครงสร้างคือให้ prefix และ suffix แล้วให้โมเดลสร้างสิ่งที่อยู่ตรงกลาง
- แต่ Zeta จำเป็นต้องคาดการณ์การแก้ไขในตำแหน่งใดก็ได้ จึงเป็นโจทย์ที่ไม่สอดคล้องกับโครงสร้างเดิม
- ทีมสังเกตว่าโมเดลทำได้ดีในการเขียนโค้ดก้อนที่ค่อนข้างใหญ่ใหม่ มากกว่าการแก้ไขแบบละเอียดทีละจุด
- จึงเลือกวิธีรับประวัติการแก้ไขล่าสุดและตำแหน่งเคอร์เซอร์เป็นอินพุต แล้วให้เขียนโค้ดชิ้นนั้นใหม่
Evaluating Predictions
- ผลลัพธ์ของโมเดลภาษาขนาดใหญ่ไม่ได้เหมือนกันทุกครั้ง จึงทำให้การทดสอบเป็นเรื่องยาก
- สามารถควบคุมความผันผวนได้ระดับหนึ่งด้วยการตั้งค่าอุณหภูมิ(
temperature) เป็น 0 หรือระบุ RNG seed
- แต่โค้ดนั้นมีคำตอบที่ถูกต้องได้หลายแบบ ดังนั้นแม้ผลลัพธ์จะไม่ตรงกับคำตอบที่คาดไว้ก็อาจยังถูกต้อง
- เนื่องจากการทำ unit test แบบดั้งเดิมทำได้ยาก จึงลองใช้ LLM ที่ใหญ่กว่าเพื่อตรวจผลลัพธ์ของ Zeta ด้วยภาษาธรรมชาติ
- ตัวอย่างเช่น กำหนดเงื่อนไขว่า “มีการเรียกฟังก์ชัน quicksort แบบ recursive สำหรับอาร์เรย์ด้านซ้ายและขวาหรือไม่” แล้วให้ Claude ตัดสินว่าตรงตามเจตนาหรือไม่
Prompt Engineering
- ในช่วงแรก ใช้โมเดล Qwen2.5-Coder-32B เพื่อสร้างพรอมป์ที่สั่งอย่างชัดเจนว่าควรคาดการณ์การแก้ไขแบบใด
- แม้จะผ่านการทดสอบชุดแรก ๆ (eval) ได้ แต่เมื่อจำนวนการทดสอบเพิ่มขึ้น ก็ยากที่จะได้ผลลัพธ์สม่ำเสมอด้วยการเปลี่ยนแค่พรอมป์
- โมเดล 32b ยังมีความหน่วงในการตอบสนองสูงเกินไป จึงไม่ผ่านเกณฑ์ประสิทธิภาพที่เข้มงวดของ Zed
Supervised Fine-Tuning
- หลังจากลองหลายแนวทาง จึงเปลี่ยนมาใช้ supervised fine-tuning ด้วย Unsloth และ LoRA
- เป้าหมายคือสอนให้โมเดลอนุมานการเปลี่ยนแปลงที่ผู้ใช้ต้องการจากประวัติการแก้ไขล่าสุด และเขียนโค้ดชิ้นนั้นได้ดีโดยไม่แทรกสิ่งที่ไม่ถูกต้อง
- แต่ในช่วงแรกยังมีข้อมูลผู้ใช้จริงไม่เพียงพอ จึงใช้ Claude สร้างตัวอย่างสังเคราะห์ราว 50 รายการแล้วเพิ่มเข้าไปในชุดข้อมูล
- จากนั้นจึงปล่อยเวอร์ชันแรกให้ใช้ใน Zed ผ่าน feature flag เพื่อให้ทีมภายในสร้างตัวอย่างการใช้งานจริงและขยายชุดข้อมูล
- ด้วยตัวอย่างราว 400 รายการ ความแม่นยำของโมเดลดีขึ้น แต่ยังเหลือปัญหาที่เมื่อแก้ไขเพียงบางส่วนของไฟล์ โมเดลอาจทำการเปลี่ยนแปลงที่ไม่จำเป็น
Direct Preference Optimization
- เพื่อแก้ปัญหานี้ จึงนำเทคนิค DPO (Direct Preference Optimization) มาใช้
- ไม่ได้แค่แสดง “ตัวอย่างที่ดี” เท่านั้น แต่ยังระบุ “ตัวอย่างที่ควรหลีกเลี่ยง” ด้วย เพื่อฝึกให้โมเดลแยกแยะการแก้ไขที่ไม่เหมาะสมได้
- เพียงตัวอย่างที่คัดสรรอย่างรอบคอบราว 150 รายการ ก็ช่วยให้พฤติกรรมของโมเดลดีขึ้นมากในกรณีที่ยาก
- คาดว่าหากเก็บตัวอย่างที่หลากหลายมากขึ้น ก็จะปรับปรุงได้อีก
Minimizing Latency: Speculative Decoding
- เช่นเดียวกับทุกฟีเจอร์ของ Zed หัวใจสำคัญของ edit prediction คือการลดความหน่วง (latency) ให้ต่ำที่สุด
- เป้าหมายคือ p50 ต่ำกว่า 200ms และ p90 ต่ำกว่า 500ms
- การเขียนโค้ดบางส่วนใหม่ต้องสร้างโทเค็นจำนวนมาก จึงอาจช้ากว่าวิธี fill-in-the-middle ทั่วไป
- แต่เพราะในกระบวนการ rewrite ยังมีส่วนที่คล้ายกับโค้ดต้นฉบับอยู่มาก จึงนำเทคนิค speculative decoding มาใช้
- กลยุทธ์นี้อ้างอิงอินพุตแล้วใช้การค้นหา n-gram เพื่อสร้างโทเค็นแบบขนาน ช่วยเพิ่มความเร็วโดยไม่ลดคุณภาพ
Minimizing Latency: Serving The Model
- นอกเหนือจากความเร็วในการอนุมานของโมเดลแล้ว วิธีการเสิร์ฟโมเดลในสภาพแวดล้อมเซิร์ฟเวอร์ก็เป็นความท้าทายใหญ่เช่นกัน
- นี่คือปัญหาที่ใช้ทรัพยากรประมวลผลมากที่สุดเท่าที่ทีมเคยทำมา
- ในช่วงเปิดตัว หลังผ่านกระบวนการตรวจสอบอย่างรวดเร็ว ก็เลือกใช้ Baseten
- วิศวกรของ Baseten ช่วยปรับแต่งโมเดล Zeta และทำให้บรรลุเกณฑ์ความหน่วงตามที่ต้องการ
- เนื่องจากเวลาในการส่งผ่านเครือข่ายก็เป็นปัจจัยสำคัญ จึงวาง GPU ไว้ในสหรัฐอเมริกาและยุโรป เพื่อประมวลผลคำขอจากตำแหน่งที่ใกล้ทางกายภาพ
- ใช้ Cloudflare Workers เพื่อรีเลย์คำขอจากดาต้าเซ็นเตอร์ที่อยู่ใกล้ผู้ใช้
Conclusion
- ต่อจากนี้มีแผนสำรวจหลายทิศทางเพื่อทำให้ edit prediction ทรงพลังยิ่งขึ้น
- จะเพิ่มปริมาณคอนเท็กซ์ที่โมเดลได้รับ ทำ fine-tuning เพิ่มเติม และขยายชุดข้อมูล Zeta เพื่อพัฒนาอย่างต่อเนื่อง
- นับตั้งแต่เปิดตัว Zed AI เมื่อฤดูใบไม้ร่วงปีที่แล้ว ทีมได้เรียนรู้อะไรมากมาย
- เพราะโลกเปลี่ยนเร็วมาก จึงยังคงทดลองและสร้างฟีเจอร์ที่ผู้ใช้น่าจะชื่นชอบอย่างต่อเนื่อง
- และอยากพัฒนา AI ไปพร้อมกับจิตวิญญาณโอเพนซอร์สที่ Zed ยึดถือมาโดยตลอด
- ไม่ว่าคุณจะเข้าร่วมในฐานะผู้ใช้ ผู้มีส่วนร่วม หรือสมาชิกทีม ก็หวังว่าจะได้ร่วมกันเปิดอนาคตที่ยอดเยี่ยมยิ่งกว่าเดิม
2 ความคิดเห็น
เอดิเตอร์ใหม่ที่สร้างโดยนักพัฒนา Atom เริ่มโอเพ่นเบตา
เอดิเตอร์โค้ดสำหรับการทำงานร่วมกัน 'Zed' ตอนนี้เปลี่ยนเป็นโอเพ่นซอร์สแล้ว
เปิดตัว Zed AI (with Anthropic)
ความคิดเห็นจาก Hacker News