teach-me-ai / sources / HO-4
⟵ กลับหน้าแทร็กเสริม
HO-4 · Hands-On AI Engineering

Audio — pipeline เสียง 3 ท่อน: ฟัง → คิด → พูด

⏱️ ~18 นาที 🎯 เห็นว่างานเสียงคือการต่อ service เป็นท่อ + รู้จัก 3 สถาปัตยกรรม (DIY / native / managed) 📦 ต้นทาง: audio/ (3 โปรเจกต์)

หมวด Audio เล็ก (3 ตัว) แต่สอน pattern ที่ชัดและใช้ได้จริง งานเสียงเกือบทั้งหมดคือการต่อ 3 ท่อน: STT → LLM → TTS (ฟัง → คิด → พูด) สิ่งที่น่าเรียนคือ 3 โปรเจกต์นี้ เลือก สถาปัตยกรรมคนละแบบ เพื่อประกอบท่อนเหล่านี้ — ซึ่งสะท้อนการตัดสินใจจริงในงาน backend

pipeline พื้นฐาน: STT → LLM → TTS

🎤 เสียงเข้า อัด/อัปโหลด 1. STT เสียง → ข้อความ (Whisper) 2. LLM แปล/สรุป/ตอบ 3. TTS ข้อความ → เสียง (Kokoro) 🔊
3 ท่อนของงานเสียง — แต่ละท่อนคือ "service" หนึ่งตัวที่เรียกผ่าน API/โมเดล

multilingual_audio_translator คือตัวอย่างเต็มท่อชัดที่สุด: อัปเสียง → faster-whisper ถอดเสียง + เดาภาษาอัตโนมัติ → Gemini แปล → Kokoro TTS สังเคราะห์เสียงกลับ (ทำในเครื่อง) แล้วคืนทั้ง transcript, คำแปล, ภาษาที่ตรวจได้ และไฟล์เสียง — เห็น 3 ท่อนครบ

3 สถาปัตยกรรม — เลือกยังไง

ทั้ง 3 โปรเจกต์เลือกวิธีประกอบท่อนต่างกัน สะท้อน trade-off จริงในงาน:

สถาปัตยกรรมทำงานยังไงโปรเจกต์ · เหมาะเมื่อ
DIY pipeline ต่อ 3 ท่อนเอง (Whisper + LLM + Kokoro) คุมได้ทุกจุด รันเองได้ multilingual_audio_translator · อยากคุม/ทำ offline/ลดค่าใช้จ่าย
Native audio model โมเดลเดียว "ฟังเสียงเข้าใจเลย" ไม่ต้องแยกท่อน STT music_explorer (Gemini อ่านเสียงตรงผ่าน Files API) · งานเข้าใจเสียงเชิงลึก (แยกเครื่องดนตรี/อารมณ์)
Managed platform แพลตฟอร์มจัด STT/LLM/TTS/สายโทรให้หมด โค้ดคุณแค่ป้อน context customer_support_voice_agent (Telnyx) · voice real-time รับสายโทรศัพท์

เคสน่าสนใจ: voice agent real-time (Telnyx)

customer_support_voice_agent สอนบทเรียนสำคัญสำหรับ backend dev: งาน voice real-time (รับสายโทรศัพท์) ยากที่จะทำเองทุกท่อน (ต้อง low-latency มาก) โปรเจกต์นี้เลยให้ Telnyx จัดการ STT/LLM/TTS/routing ทั้งหมด (no-code ในพอร์ทัล) ส่วนโค้ดที่เขียนเองมีแค่ชิ้นเดียว: Dynamic Variables webhook — FastAPI endpoint ที่ Telnyx เรียกตอนเริ่มสาย เพื่อ "inject real-time context into every call"

💡

pattern พกพา: สำหรับงาน real-time หนัก ๆ (voice/สตรีม) มักคุ้มกว่าที่จะใช้แพลตฟอร์ม managed แล้วให้ งานของคุณ = webhook ที่ป้อน context จากระบบจริง (query ลูกค้าจาก DB ส่งกลับไป) — นี่คืองาน NestJS controller ธรรมดา ๆ ที่คุณทำได้ทันที ไม่ต้องแตะเรื่องเสียง

map ลงงาน NestJS/Go ของคุณ

  • แต่ละท่อน = service call: STT/TTS มองเป็น external service (เรียก API หรือ self-host โมเดล) — controller ของคุณแค่ร้อยลำดับ
  • ไฟล์ใหญ่/ช้า → ใช้ queue: ถอดเสียงไฟล์ยาวเป็นงาน async — โยนเข้า BullMQ/worker แล้วแจ้งผลเมื่อเสร็จ (อย่า block request)
  • Real-time → webhook + inject context: ตรงกับ pattern Telnyx — controller รับ webhook, query DB, ส่ง context กลับ
  • Native model ลดความซับซ้อน: ถ้าโมเดลรับเสียงตรงได้ (เช่น Gemini) อาจข้ามท่อน STT ไปเลย โค้ดสั้นลง
⚠️

ระวัง: งานเสียงมักไฟล์ใหญ่และช้า — อย่าประมวลผลใน request หลัก (timeout ง่าย); เสียงเป็นข้อมูลอ่อนไหว (PII/บทสนทนา) ต้องระวังเรื่อง retention/ความยินยอม; และ real-time voice latency เป็นตัวตัดสิน — วัดให้ครบท่อ (STT+LLM+TTS) ไม่ใช่แค่ท่อนเดียว

🎯 แบบฝึกหัด
  1. เปิด README ของ audio/multilingual_audio_translator/ แล้วไล่ให้เจอว่า ท่อน STT / LLM / TTS ใช้เครื่องมืออะไรตามลำดับ
  2. customer_support_voice_agent — "โค้ดที่เขียนเอง" ทำหน้าที่อะไรเพียงอย่างเดียว และทำไมถึงไม่ต้องเขียนส่วน STT/LLM/TTS เอง
  3. นึกงาน voice ในบริษัทคุณ (เช่น สรุป voice note ของลูกค้า) แล้วเลือกว่าจะใช้สถาปัตยกรรมไหน (DIY / native / managed) พร้อมเหตุผล 1 ประโยค

เมื่อทำเสร็จ พิมพ์ /quiz HO-4 เพื่อทดสอบความเข้าใจ