สร้าง Siri ของคุณเองแบบโลคัลและบนอุปกรณ์ โดยไม่พึ่งคลาวด์
(thehyperplane.substack.com)- วิธีสร้าง ผู้ช่วยเสียงส่วนตัวที่รันบนอุปกรณ์ ด้วยตัวเอง โดยไม่ต้องพึ่ง LLM API หรือคลาวด์
- ผู้ช่วยนี้ เข้าใจภาษาธรรมชาติ, เรียกใช้ฟังก์ชันส่วนตัวได้, และ ทำงานเฉพาะในเครื่อง จึง รับประกันความเป็นส่วนตัวได้อย่างสมบูรณ์
- สำหรับงานนี้ มีการ ปรับจูนละเอียดโมเดล LLaMA 3.1 ด้วยวิธี LoRA และใช้ Whisper เพื่อ แปลงเสียงเป็นข้อความ ก่อนตีความเป็นคำสั่งและสั่งงานบนอุปกรณ์โดยตรง
- โปรเจกต์ประกอบด้วย การสร้างชุดข้อมูล → การทำฟाइनจูน → การเชื่อมต่ออินเทอร์เฟซเสียง → การทดสอบและดีพลอย และจัดทำเป็นมินิคอร์สฟรี 5 ตอนที่ครอบคลุมแต่ละขั้นตอน
- เตือนให้ระวังความเข้าใจผิดว่า “การรันบนอุปกรณ์ = เรียบง่าย” โดยเน้นว่า แม้จะเป็นโลคัลก็ยังต้องมีแนวคิดแบบ MLOps และการควบคุมคุณภาพอย่างเข้มงวด
ทำไมตอนนี้จึงควรสร้างผู้ช่วยเสียงแบบโลคัล?
- การคุยกับ ChatGPT มีประโยชน์ แต่จำเป็นไหมที่จะต้องส่งแม้แต่คำสั่งง่าย ๆ ขึ้นคลาวด์?
- หากติดตั้งโมเดลไว้บนอุปกรณ์ของตัวเองโดยตรง ก็จะได้ทั้ง ความเร็ว, ความเป็นส่วนตัว, และ สิทธิ์ควบคุม
- มีประโยชน์อย่างยิ่งในสภาพแวดล้อมที่อ่อนไหว เช่น การแพทย์, กฎหมาย, เครื่องมือภายในองค์กร
ภาพรวมสถาปัตยกรรมทั้งหมด
องค์ประกอบของโปรเจกต์
- การรู้จำเสียง (Whisper) → แปลงเป็นข้อความ
- LLM (LLaMA 3.1) → ตีความคำสั่ง
- ตัวเรียกใช้ฟังก์ชัน → สั่งงานฟังก์ชันจริง เช่น
lock_screen()
Part 1: สถาปัตยกรรมและแนวคิดแบบ MLOps
ทำไมโลคัลก็ยังต้องมี MLOps
- มีปัญหาเรื่อง model drift, การเปลี่ยนแปลงของพรอมป์ต์, ความน่าเชื่อถือของชุดข้อมูล, และ การขาด logging สำหรับดีบัก
- แนวคิดว่า “แค่โลคัลก็พอแล้ว” เป็นเรื่องอันตราย และจำเป็นต้องมีแนวทางที่เป็นระบบ
การพัฒนาออนไลน์ vs การรันออฟไลน์
- งานพัฒนา (ฟाइनจูน, สร้างข้อมูล) ทำใน คลาวด์ ส่วนการใช้งานจริง รันแบบโลคัล
- หัวใจของ MLOps คือการ แยกสองส่วนนี้ให้ชัดเจน และบริหารจัดการอย่างเป็นระบบ
การสร้างชุดข้อมูล (Dataset Generation Flow)
- ไม่ใช่แค่การรวบรวมพรอมป์ต์แบบง่าย ๆ แต่เป็นการ ออกแบบแพตเทิร์นการเรียกฟังก์ชันแบบมีโครงสร้าง และโครงสร้างคำขอเชิงสนทนา
- สร้างชุดข้อมูลคุณภาพสูงที่ครอบคลุม รูปแบบการพูดที่หลากหลาย, เจตนา, และกรณีล้มเหลว
จุดสำคัญ
lock_screen()→ รวมการแสดงภาษาธรรมชาติหลากหลายแบบ เช่น “ล็อกหน้าจอให้หน่อย”- ตรวจสอบว่าผลลัพธ์มีรูปแบบตามที่ตั้งใจไว้หรือไม่ผ่านเอนจินตรวจสอบอัตโนมัติ
การฟाइनจูน (Instruction Tuning for Function Calling)
- ปรับจูนละเอียดโมเดลขนาดเล็ก (แบบ SFT) เพื่อให้ แมปคำสั่งได้อย่างแม่นยำ
- ใช้เครื่องมือทำงานจริง เช่น Unsloth, W&B, การส่งออกเป็นฟอร์แมต GGUF
เป้าหมาย
- แปลง LLaMA 3.1 8B ให้เป็นโมเดล 4bit ที่สามารถรันแบบโลคัลได้
- มุ่งทำให้เบาพอสำหรับอุปกรณ์เป้าหมายอย่าง Raspberry Pi
การเชื่อมต่อโมเดลและการทำงานจริง
- ใช้ Whisper แปลงอินพุตเสียงเป็นข้อความ
- LLM ที่ผ่านการฟाइनจูนแล้วจะตีความคำสั่ง
- เชื่อมต่อกับตัวเรียกใช้ฟังก์ชันของโลคัล API เช่น
lock_screen(),get_battery_status()เป็นต้น
ผลลัพธ์
- ทำงานเป็น ผู้ช่วยเสียงแบบเรียลไทม์ ได้
- ไม่ต้องใช้เครือข่าย, ไม่มีการรั่วไหลของข้อมูลส่วนตัว, และ ผู้ใช้ควบคุมได้อย่างสมบูรณ์
การจัดการความเสี่ยงในขั้นตอนออฟไลน์
- ต้องทดสอบกับอุปกรณ์และระบบปฏิบัติการที่หลากหลาย
- จำเป็นต้องสร้าง ระบบ logging (ให้ผู้ใช้เลือกส่งด้วยตนเองแบบ opt-in)
- ก่อนปล่อยใช้งานจริง ควรทำ stress test และรับฟัง feedback จากผู้ใช้ เพื่อจับปัญหาได้ตั้งแต่เนิ่น ๆ
แผนต่อจากนี้
- บทถัดไปจะเป็น ภาคปฏิบัติการสร้างชุดข้อมูลสำหรับ function calling
- จะสร้าง ชุดข้อมูลเฉพาะทางอย่างเป็นโครงสร้าง เพื่อสอนการแมประหว่างคำสั่งภาษาธรรมชาติกับการเรียก API
- ห้าม scraping และใช้เฉพาะ ข้อมูลจากการจำลองด้วยพรอมป์ต์และการตรวจสอบอัตโนมัติเท่านั้น
บทสรุป
- ระบบ AI แบบโลคัลอาจดูเรียบง่าย แต่ ด้านเสถียรภาพและคุณภาพกลับต้องการการจัดการในระดับที่สูงกว่า
- เพราะไม่สามารถพึ่ง cloud log หรือ hotfix ได้ จึงต้องการความน่าเชื่อถือและความรับผิดชอบที่สูงกว่า
- ด้วยเหตุนี้จึงควรนำ แนวคิดแบบ MLOps และการออกแบบเชิงโครงสร้าง มาใช้ตั้งแต่ต้น
> “ยุคของผู้ช่วย AI ที่แท้จริง ซึ่งให้ความสำคัญกับความเป็นส่วนตัวและยึดโลคัลเป็นหลัก มาถึงแล้ว”
> ตอนถัดไปจะเริ่ม ภาคปฏิบัติการสร้างชุดข้อมูลสำหรับการแมประหว่างคำสั่งจริงกับฟังก์ชัน
2 ความคิดเห็น
3.1 ใช้งานยากสำหรับผู้ใช้ที่ไม่ได้ใช้ภาษาอังกฤษเป็นหลัก และถ้าเป็น 3.3 หรือ 4 ก็น่าจะรองรับภาษาเกาหลีได้ แต่ถ้าจะรันแบบ on-device แล้ว สำหรับภาษาที่ไม่ใช่อังกฤษ อย่างน้อยก็น่าจะต้องใช้ 32b ขึ้นไปถึงจะมีความหมาย เมื่อคำนึงถึงจุดนั้นแล้วก็ดูเหมือนว่ายังยากอยู่...
ความคิดเห็นบน Hacker News