24 คะแนน โดย GN⁺ 2025-05-14 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • วิธีสร้าง ผู้ช่วยเสียงส่วนตัวที่รันบนอุปกรณ์ ด้วยตัวเอง โดยไม่ต้องพึ่ง LLM API หรือคลาวด์
  • ผู้ช่วยนี้ เข้าใจภาษาธรรมชาติ, เรียกใช้ฟังก์ชันส่วนตัวได้, และ ทำงานเฉพาะในเครื่อง จึง รับประกันความเป็นส่วนตัวได้อย่างสมบูรณ์
  • สำหรับงานนี้ มีการ ปรับจูนละเอียดโมเดล LLaMA 3.1 ด้วยวิธี LoRA และใช้ Whisper เพื่อ แปลงเสียงเป็นข้อความ ก่อนตีความเป็นคำสั่งและสั่งงานบนอุปกรณ์โดยตรง
  • โปรเจกต์ประกอบด้วย การสร้างชุดข้อมูล → การทำฟाइनจูน → การเชื่อมต่ออินเทอร์เฟซเสียง → การทดสอบและดีพลอย และจัดทำเป็นมินิคอร์สฟรี 5 ตอนที่ครอบคลุมแต่ละขั้นตอน
  • เตือนให้ระวังความเข้าใจผิดว่า “การรันบนอุปกรณ์ = เรียบง่าย” โดยเน้นว่า แม้จะเป็นโลคัลก็ยังต้องมีแนวคิดแบบ MLOps และการควบคุมคุณภาพอย่างเข้มงวด

ทำไมตอนนี้จึงควรสร้างผู้ช่วยเสียงแบบโลคัล?

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

ภาพรวมสถาปัตยกรรมทั้งหมด

องค์ประกอบของโปรเจกต์

  1. การรู้จำเสียง (Whisper) → แปลงเป็นข้อความ
  2. LLM (LLaMA 3.1) → ตีความคำสั่ง
  3. ตัวเรียกใช้ฟังก์ชัน → สั่งงานฟังก์ชันจริง เช่น 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 ความคิดเห็น

 
asheswook 2025-05-15

3.1 ใช้งานยากสำหรับผู้ใช้ที่ไม่ได้ใช้ภาษาอังกฤษเป็นหลัก และถ้าเป็น 3.3 หรือ 4 ก็น่าจะรองรับภาษาเกาหลีได้ แต่ถ้าจะรันแบบ on-device แล้ว สำหรับภาษาที่ไม่ใช่อังกฤษ อย่างน้อยก็น่าจะต้องใช้ 32b ขึ้นไปถึงจะมีความหมาย เมื่อคำนึงถึงจุดนั้นแล้วก็ดูเหมือนว่ายังยากอยู่...

 
GN⁺ 2025-05-14
ความคิดเห็นบน Hacker News
  • ชอบไอเดียแบบนี้มากจนอยากลองทำเอง แต่ประสบการณ์ที่เคยใช้โมเดลขนาดเล็กของ whisper แบบโลคัลนั้นต่ำกว่าที่คาดไว้ เลยสงสัยว่ามีใครได้ผลลัพธ์ที่ดีพอสำหรับกรณีใช้งานระดับนี้บ้างไหม หรืออาจเป็นเพราะไมค์ของฉันไม่ดีก็ได้
    • ควรเช็กสภาพไมโครโฟนอีกครั้งจริง ๆ ที่บริษัทเราใช้ Whisper ถอดเสียงและแปลการประชุมทั้งวงแบบเรียลไทม์ และมันทำงานได้ยอดเยี่ยมมาก
    • อยากรู้ว่าใช้โมเดลไหนอยู่ ปกติฉันใช้โมเดล large บน GPU ซึ่งเร็วและทำงานได้ดีมาก แต่ต้องระวังว่ามันรู้จำได้ทีละภาษาเดียว ถ้าไม่ระบุไว้ก็จะใช้การตรวจจับอัตโนมัติ โมเดลเล็ก ๆ ประสิทธิภาพก็จะด้อยลงตามนั้นและมักรองรับแค่อังกฤษเป็นหลัก สำหรับฉัน large ให้ผลดีที่สุด แต่ถ้าจะให้ได้ความเร็วที่ใช้งานได้จริงก็ต้องมีฮาร์ดแวร์ GPU ไม่ว่าจะใช้ร่วมกับ faster-whisper หรือ insanely-fast-whisper ก็เหมือนกัน
  • ถ้ามีเป็นผลิตภัณฑ์หรือแอปที่ติดตั้งแล้วใช้ได้เลยก็คงดีมาก อยากตั้งค่าและเทรนผ่าน UI แบบง่าย ๆ ถึงอย่างนั้นก็ต้องขอบคุณมาก เพราะไกด์นี้ดูเหมือนจะช่วยให้ฉันสร้างสิ่งที่ต้องการได้
  • เป็นข้อมูลที่ยอดเยี่ยมมาก แค่อยากมาบอกว่าขอบคุณ ยังไม่ได้ลองทำตามทั้งหมด แต่สงสัยว่าโมเดลนี้รันบน iPhone ได้ดีจริงไหม ลูกอายุ 9 ขวบที่บ้านเคยรัน Qwen 0.6B ผ่าน ollama ได้ดี แต่โมเดลอื่นช้าเกินไปจนประสบการณ์ใช้งานไม่ไหว
    • อ้อ หมายถึงโทรศัพท์อายุ 9 ปีนี่เอง ฉันนึกว่าเด็กประถมกำลัง deploy โมเดลเองถึงกับตกใจเลย ตอนฉันอายุเท่านั้นยังท่องสูตรคูณอยู่เลย
    • ตามข้อมูลของ MLC บอกว่าโมเดลขนาดถึง 8B ก็รันบน iOS ได้ แต่ขนาดประมาณ 1-3B น่าจะสมจริงกว่า มีข้อมูลอ้างอิงนี้: https://llm.mlc.ai/docs/deploy/ios.html#bring-your-own-model
  • ทำไมต้องเป็นบทความที่ LLM เขียนด้วย? งงอยู่
    • สไตล์แบบสรุปย่อแนวนี้ คือมีการฟอร์แมตหนัก ๆ และ (!) ทุกย่อหน้ากลายเป็น bullet list ทำให้งงมาก โดยเฉพาะเวลาเป็นบทความยาว หน้าจอดูรกและแบน ๆ จนรู้สึกว่าอ่านยากลง
  • ไม่นานมานี้ (อาจเป็นไปได้ว่าฉันพลาดประกาศ) ฉันเพิ่งสังเกตว่า Siri ทำงานแบบโลคัลได้อย่างน้อยกับคำสั่งบางอย่าง เช่น ลองเปิดโหมดเครื่องบินบน Apple Watch แล้วขอตั้งเวลาเตือนหรือเตือนความจำดู
    • Siri มีความสามารถออฟไลน์แบบจำกัดอย่างน้อยตั้งแต่ iOS 15 แล้ว แต่ผู้ใช้ส่วนใหญ่แทบไม่ทันสังเกต เพราะคำสั่ง Siri ส่วนมากยังต้องพึ่งการเชื่อมต่อเครือข่าย
  • สงสัยว่าทำไม Apple ไม่วิเคราะห์ข้อมูลแล้วทำ handler แบบฮาร์ดโค้ดสำหรับกรณีใช้งานยอดนิยมสักประมาณ 1000 อันดับแรก
    • จริง ๆ ก็ทำอยู่แล้ว แต่ช้ามาก มีการเพิ่มฟีเจอร์พวกความสว่างกับพลังงานเข้ามา แต่ไม่ได้บอกให้ชัดว่ามีอะไรใช้แบบออฟไลน์ได้บ้าง ผู้ใช้ต้องสลับไปโหมดเครื่องบินแล้วลองเองทีละอย่างถึงจะรู้ ประสบการณ์ใช้งานแย่มาก
  • เป็นโปรเจกต์ที่เจ๋งและสรุปได้ดี
  • สงสัยว่า Apple อนุญาตให้แทนที่ Siri ด้วยผู้ช่วยตัวอื่นไหม บน Android ผู้ช่วยที่ไม่ใช่ของ Google ถูกจำกัดเรื่องการฟังอยู่เบื้องหลัง หรือการใช้ปุ่มฮาร์ดแวร์ ท่าทาง และคีย์ลัดมานานแล้ว ไม่แน่ใจว่า Google Assistant ยังได้อภิสิทธิ์อยู่ไหม แต่ถ้ายังอยู่ก็ไม่ได้น่าแปลกใจนัก
    • ปัญหาส่วนหนึ่งมาจากการมี coprocessor แยกต่างหาก (AOP) สำหรับจัดการ wake word “hey siri” โดยตัวโมเดลก็ถูกคอมไพล์ไว้ในเฟิร์มแวร์ด้วย ในทางเทคนิคไม่ถึงกับเป็นไปไม่ได้ แต่จะทำไม่ได้ด้วยการแค่ปล่อยให้แอป Google รันอยู่เบื้องหลัง เพราะท่าทางต่าง ๆ เกิดขึ้นตอนที่ AP หลับอยู่ คุณอาจเรียกแอปผู้ช่วยผ่านปุ่ม Action ด้านข้างได้ แต่ประสบการณ์คงไม่น่าพอใจนัก (เช่น แอปอาจไม่ได้เปิดอยู่) รายละเอียดดูได้จากลิงก์นี้: https://machinelearning.apple.com/research/hey-siri
    • ปุ่ม Action ที่เพิ่งเพิ่มเข้ามาทำให้เปิดแอปผู้ช่วยทางเลือกผ่านคัสตอมชอร์ตคัตได้ค่อนข้างง่าย
    • Perplexity ก็ทำงานด้วยวิธีนี้
  • ตลอดปีครึ่งที่ผ่านมา ฉันใช้ chatGPT บน iPhone อย่างจริงจัง ความน่าอึดอัดของ Siri ทำให้ยิ่งไม่ชอบมันมากขึ้นเรื่อย ๆ สงสัยว่า OpenAI จะออก GPT phone มาแข่งกับ iPhone เมื่อไหร่ โดยมี Microsoft ช่วยอยู่ ฉันเบื่อ iPhone ที่น่าเบื่อแล้ว อยากได้ GPT phone ที่ให้ GPT ทำทุกอย่างแทนได้ตั้งแต่หน้าจอล็อก รอให้มันออกมาแทบไม่ไหว และหวังว่ามันคงกำลังพัฒนาแบบลับ ๆ อยู่