การสร้าง AI รีเซปชันนิสต์สำหรับอู่ซ่อมรถหรู - ตอนที่ 1

 (itsthatlady.dev)
1 คะแนน โดย GN⁺ 2026-03-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • พัฒนา AI รีเซปชันนิสต์ ‘Axle’ ที่รับสายโทรศัพท์จริง เพื่อแก้ปัญหา รายได้สูญเสียจากการพลาดรับสาย ของอู่ซ่อมรถระดับพรีเมียม
  • AI ถูกสร้างบนพื้นฐานของ Retrieval-Augmented Generation (RAG) เพื่อให้ตอบได้อย่างแม่นยำโดยอ้างอิงข้อมูลบริการและราคาจริงที่รวบรวมจากเว็บไซต์
  • ผสานการทำงานของ Vapi, Deepgram, ElevenLabs, FastAPI, MongoDB Atlas เป็นต้น เพื่อรองรับการเชื่อมต่อสายโทรศัพท์ การรู้จำและสังเคราะห์เสียง และการจัดเก็บบันทึกบทสนทนา
  • คุณภาพเสียงถูกปรับให้มี น้ำเสียงเป็นธรรมชาติและโครงสร้างประโยคสั้น เพื่อให้ตอบลูกค้าได้อย่างเป็นกันเองแต่ยังคงความเป็นมืออาชีพ
  • ในอนาคตมีแผนขยายไปสู่ ระบบจอง, การแจ้งเตือนผ่าน SMS และแดชบอร์ดจัดการคอลแบ็ก โดยชี้ว่า ฐานความรู้และการออกแบบการเอสคาเลต คือหัวใจของ voice agent ที่เฉพาะทางต่อธุรกิจ

กระบวนการสร้าง AI รีเซปชันนิสต์

  • สร้าง AI รีเซปชันนิสต์ ‘Axle’ แบบปรับแต่งเฉพาะ เพื่อแก้ปัญหาที่พี่ชายซึ่งเปิดอู่ซ่อมรถหรูต้องเผชิญ คือ สูญเสียรายได้หลายพันดอลลาร์ต่อเดือนจากการพลาดรับสาย
  • ไม่ได้ออกแบบเป็นแค่แชตบอต แต่เป็น เอเจนต์แบบเสียงที่รับโทรศัพท์จริงได้ และตอบคำถามลูกค้าโดยอิงข้อมูลจริง เช่น ราคา เวลาทำการ และนโยบายต่าง ๆ
  • โปรเจกต์แบ่งเป็น 3 ขั้น: สร้างฐานความรู้ (RAG pipeline) → เชื่อมต่อโทรศัพท์และเซิร์ฟเวอร์ → ปรับคุณภาพเสียงและโทนการสนทนา

Step 1: สร้างสมอง (RAG pipeline)

  • ใช้วิธี Retrieval-Augmented Generation (RAG) เพื่อให้ออกแบบ AI ให้ตอบบนพื้นฐานของข้อมูลจริง
    • หากใช้ LLM แบบตรง ๆ อาจมีความเสี่ยงเรื่อง ภาพหลอน (hallucination) เช่น ให้ราคาผิด จึงจำกัดให้ตอบได้จากข้อมูลจริงเท่านั้น
  • สแครปข้อมูลจากเว็บไซต์ รวบรวมเอกสารมากกว่า 21 ชิ้น ครอบคลุมประเภทบริการ ราคา ระยะเวลา เวลาทำการ วิธีชำระเงิน การรับประกัน และนโยบายรถทดแทน
  • จัดเก็บ knowledge base ไว้ใน MongoDB Atlas และสร้างเวกเตอร์เอมเบดดิ้งขนาด 1024 มิติด้วยโมเดล Voyage AI (voyage-3-large)
    • ใช้ Atlas Vector Search index สำหรับการค้นหาเชิงความหมาย
  • เมื่อมีคำถามจากลูกค้า ระบบจะแปลงคิวรีด้วยโมเดลเอมเบดดิ้งตัวเดียวกันเพื่อค้นหา เอกสาร 3 อันดับแรกที่ใกล้เคียงกันในเชิงความหมาย
  • ใช้โมเดล Anthropic Claude (claude-sonnet-4-6) สร้างคำตอบโดยใช้เอกสารที่ค้นได้เป็นบริบท
    • ใน system prompt มีการกำหนดกติกาไว้ว่า “ห้ามใช้ข้อมูลนอกฐานความรู้, ตอบให้กระชับและเป็นภาษาพูด, ถ้าไม่รู้ให้เสนอคอลแบ็ก”
  • ผลลัพธ์คือในเทอร์มินัลสามารถตอบคำถามอย่าง “ค่าเปลี่ยนน้ำมันเครื่องเท่าไร?” ได้อย่างถูกต้องด้วยราคาจริงและรายละเอียดบริการ

Step 2: เชื่อมต่อกับหมายเลขโทรศัพท์จริง

  • ใช้แพลตฟอร์ม Vapi เพื่อเชื่อมสมอง AI เข้ากับระบบโทรศัพท์จริง
    • รองรับการซื้อหมายเลขโทรศัพท์, การรู้จำเสียงด้วย Deepgram, การสังเคราะห์เสียงด้วย ElevenLabs และฟังก์ชันเรียกใช้แบบเรียลไทม์
  • สร้าง FastAPI webhook server
    • Vapi จะส่งคำถามของลูกค้ามาที่เอ็นด์พอยต์ /webhook ในรูปคำขอ tool-calls
    • เซิร์ฟเวอร์จะส่งต่อไปยัง RAG pipeline เพื่อรับคำตอบจาก Claude แล้วส่งกลับไปยัง Vapi
    • จำเป็นต้อง ลด latency ให้ต่ำที่สุด เพื่อรักษาความเร็วการสนทนาให้เป็นธรรมชาติ
  • ใช้ Ngrok เปิดเผยเซิร์ฟเวอร์ภายในเครื่องเป็น URL แบบ HTTPS จากภายนอก ทำให้ทดสอบแบบเรียลไทม์ได้ระหว่างพัฒนา

  • การตั้งค่า Vapi Assistant

    • เชื่อมคำทักทายและเครื่องมือ 2 ตัว (answerQuestion, saveCallback) เข้ากับ webhook
    • สามารถตอบคำถาม หรือถ้าไม่รู้ก็รับชื่อและเบอร์โทรเพื่อบันทึกคอลแบ็ก
    • ใช้ ฟีเจอร์หน่วยความจำบทสนทนา เพื่อคงบริบทจากการคุยก่อนหน้า
    • รองรับคำถามต่อเนื่องแบบ “เปิดกี่โมง?” → “ถ้าอย่างนั้น เปลี่ยนยางราคาเท่าไร?”

  • บันทึกล็อกการโทรลง MongoDB

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

Step 3: ปรับคุณภาพเสียง

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

  • การเลือกเสียงจาก ElevenLabs

    • หลังทดสอบเสียงราว 20 แบบ พบว่าเสียง ‘Christopher’ ฟังเป็นธรรมชาติที่สุดและเหมาะกับบรรยากาศของอู่
    • เสียงที่ฟังดูเป็นหุ่นยนต์เกินไปหรือสดใสเกินไปไม่เหมาะ

  • การปรับ system prompt

    • ใช้ประโยคสั้น ลบ Markdown และตัดวลีที่ไม่จำเป็นอย่าง “เป็นคำถามที่ดีมาก!”
    • ราคาให้อ่านออกเสียงเป็นภาษาธรรมชาติ (“forty-five dollars”)
    • จำกัดคำตอบไว้ที่ 2–4 ประโยค
    • เป้าหมายคือทำให้ได้ เสียงมนุษย์ที่เป็นมิตรและเป็นมืออาชีพ

  • ทดสอบโฟลว์การเอสคาเลต (คอลแบ็ก)

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

  • เขียนการทดสอบแบบบูรณาการ

    • ตรวจสอบทั้ง RAG pipeline, การจัดการ webhook และฟลोว์โดยรวม
    • รวมถึงการจัดการ edge case เช่น คำขอที่ไม่ถูกต้อง ไม่มีผลการค้นหา หรือไม่มีหมายเลขคอลแบ็ก

โครงสร้างเทคโนโลยีที่ใช้

  • Vapi (ผสาน Deepgram & ElevenLabs) — หมายเลขโทรศัพท์, การรู้จำเสียง, การสังเคราะห์เสียง, การเรียกใช้ฟังก์ชัน
  • Ngrok — HTTPS tunnel สำหรับการพัฒนาบนเครื่อง
  • FastAPI + Uvicorn — webhook server
  • MongoDB Atlas — knowledge base, vector search, ล็อกการโทร, คิวคอลแบ็ก
  • Voyage AI (voyage-3-large) — text embedding สำหรับการค้นหาเชิงความหมาย
  • Anthropic Claude (claude-sonnet-4-6) — สร้างคำตอบจากฐานความรู้
  • Python — ใช้ pymongo, voyageai, anthropic, fastapi
  • Copilot CLI — เครื่องมืออัตโนมัติสำหรับการบิลด์

ขั้นตอนถัดไป

  • ขณะนี้ AI ทำงานได้ถึงขั้นตอบคำถามและเก็บข้อมูลคอลแบ็กแล้ว
  • เป้าหมายถัดไปคือ เชื่อมปฏิทิน สำหรับการจองแบบเรียลไทม์, การแจ้งเตือนทาง SMS, แดชบอร์ดจัดการคอลแบ็ก, เสริมความปลอดภัย และ deploy บน Railway
  • เมื่อเสร็จสมบูรณ์จะเปิดให้บริการได้ตลอด 24 ชั่วโมง และ ป้องกันการสูญเสียรายได้จากการพลาดรับสาย
  • ส่วนที่ยากที่สุดไม่ใช่เรื่องโค้ด แต่คือ การทำโทนเสียงให้เหมาะกับอู่ซ่อมรถ
  • บทเรียนสำคัญคือ อย่านำ LLM ดิบมาใช้ตรง ๆ กับ voice agent ที่เฉพาะทางต่อธุรกิจ
    • ต้องอิงกับฐานความรู้จริง และต้องออกแบบ โฟลว์รับมือเมื่อไม่รู้คำตอบ (เอสคาเลต) ไว้เสมอ
    • สิ่งนี้ไม่ใช่ข้อยกเว้น แต่เป็น ฟีเจอร์หลัก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-25
ความคิดเห็นจาก Hacker News

  • ฉันเคยทำงานเป็น service advisor (เจ้าหน้าที่รับรถ/รับงานซ่อม) มาก่อน ระบบที่บทความพูดถึงดูแล้วไม่น่าจะใช้งานได้จริง

    1. ถ้าไม่มีประวัติการซ่อมแบบเดียวกัน โอกาสที่ใบประเมินราคาจะผิดพลาดก็สูงมาก ในบางรัฐ การประเมินราคาผิดอาจมีปัญหาทางกฎหมายได้
    2. สต็อกอะไหล่และราคามีการเปลี่ยนแปลงตลอดเวลา ถ้าระบบสะท้อนไม่ได้ก็จะยิ่งสร้างความสับสน
    3. งานใหม่มีความซับซ้อนตั้งแต่ขั้นตอนการเลือกอะไหล่ และยิ่งเป็นรถหรูยิ่งยุ่งยาก
    4. ส่วนที่พอมีประโยชน์คงมีแค่ การแจ้งเตือนให้มารับรถ เท่านั้น ใช้สำหรับแจ้งอัตโนมัติเมื่อเสร็จงานหรืออัปเดตความคืบหน้า
      การพัฒนาแบบนี้ไม่ใช่แค่ ความหยิ่งผยอง แต่ยังอันตรายด้วย ถ้าสร้างจากสมมติฐานโดยไม่มีการตรวจสอบ ก็เท่ากับทำให้ปากท้องของคนอื่นตกอยู่ในความเสี่ยง
    • ฉันเองก็ไม่ใช่ผู้เชี่ยวชาญ แต่ก็เห็นด้วยกับความ วางท่าอวดรู้ แบบนี้ ถ้าต้องการ receptionist การจ้างคนก็ดูเป็นทางเลือกที่ธรรมชาติที่สุด เอาธุรกิจไปฝากไว้กับโซลูชัน AI ที่ยังไม่ผ่านการพิสูจน์มันเข้าใจได้ยาก ไม่รู้ว่าแค่ไม่อยากบริหารคน หรือแค่ไล่ตามกระแส
    • จริง ๆ มีวิธีที่ง่ายกว่านั้น แค่ทำให้คนที่กำลังทำงานอยู่ใต้ท้องรถสามารถรับสายผ่าน ลำโพงโทรศัพท์แบบแฮนด์ฟรี ได้ ถ้าใช้โมเดลรู้จำเสียงแบบรันในเครื่องก็ยังพูดได้ว่าใช้เทคโนโลยีโครงข่ายประสาท และต้นทุนรวมไมค์แล้วแค่ 200~300 ดอลลาร์ก็พอ
    • แต่ถ้าดูต้นฉบับ อู่แห่งนี้มี บริการและตารางราคาที่ตายตัว อยู่แล้ว ดังนั้นถ้าไม่ใช่กรณีที่ต้องตีราคาตามสภาพ ปัญหาข้างต้นก็อาจไม่เกี่ยว
    • คำว่า “อันตราย” น่าจะรุนแรงไปหน่อย นักพัฒนาก็กำลังช่วยธุรกิจของพี่ชายตัวเองอยู่ ต่อให้ไม่สมบูรณ์แบบ ถ้าช่วยเพิ่ม conversion ได้แค่ 10% ก็ถือว่าคุ้มมากแล้ว
    • การแจ้งว่ารถเสร็จแล้วหรืออัปเดตความคืบหน้า ทำได้ด้วย ระบบ TTS มาหลายปีแล้ว ไม่จำเป็นต้องใช้ LLM ด้วยซ้ำ

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

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

    • จริง ๆ ปัญหาแบบนี้แก้ได้ด้วย บริการเลขานุการเสมือน มาตั้งแต่ก่อนมี AI แล้ว เดือนละ 200~1000 ดอลลาร์ก็พอ เท่ากับแค่ดึงยอดขายที่เคยหลุดมือกลับคืนมา AI ก็เป็นเพียงกับดักหนูที่ซับซ้อนขึ้นเท่านั้น และถ้าเป็น บริการระดับพรีเมียม การตอบรับโดยมนุษย์ให้ความน่าเชื่อถือมากกว่าเยอะ
    • คิดว่าน่าจะยังไม่ได้มี การทดสอบใช้งานจริง มากพอ เรื่องอย่างที่อยู่อีเมล LLM ยังจดตามได้ยาก สำหรับการตอบโต้ด้วยเสียงแบบเรียลไทม์ Anthropic ช้า ส่วน Groq เร็วมาก ต่ำกว่า 200ms
    • ก่อนหน้านี้ฉันต้องรีบ เปลี่ยนกระจกรถยนต์ แต่ระบบเสียงอัตโนมัติกลับถามข้อมูลที่ไม่จำเป็นไม่หยุด สุดท้ายฉันวางสาย ถ้าเป็นการนัดหมายง่าย ๆ ก็คงพอไหว แต่ในสถานการณ์พิเศษก็ต้องคุยกับคนอยู่ดี
    • ความพยายามแบบนี้ถือว่าสมเหตุสมผล เพียงแต่ประสิทธิภาพจริงยังไม่แน่นอน มันเหมือนกระดาษลิตมัสที่ใช้แยก คนมองโลกในแง่ดีเรื่อง AI กับคนมองโลกในแง่ร้าย

  • ช่วงนี้ฉันมอง ผู้ช่วยรับโทรศัพท์ที่ใช้ LLM ในแง่บวกพอสมควร ตอนโทรหาศูนย์บริการลูกค้า Mint Mobile, LLM เข้าใจได้เป็นธรรมชาติและแก้ปัญหาให้เสร็จใน 1 นาที ทั้งที่เมื่อก่อนอาจต้องรอสายเกิน 20 นาที

    • LLM ออกเสียงชัด ไม่มีเสียงรบกวนจากเฮดเซ็ต และเข้าใจง่าย แน่นอนว่าก็มีกรณีพัง ๆ แบบแชตบอต LLM ของ eBay แต่ ระบบที่ทำมาดี นั้นใช้งานได้ยอดเยี่ยม
    • ระบบแชตซัพพอร์ตของ Amazon ก็คล้ายกัน LLM ช่วยจัดข้อมูลคำสั่งซื้อล่วงหน้า แล้วให้คนมาทำแค่ขั้นอนุมัติสุดท้าย ซึ่งมีประสิทธิภาพดี
    • แต่ก็ยังสงสัยว่าทำไมถึงแก้ผ่านแอปไม่ได้จนต้อง ใช้ LLM สุดท้ายมันดูเหมือนความล้มเหลวของกระบวนการพัฒนามากกว่า
    • ฉันก็มีประสบการณ์คล้ายกัน เคยถามคำถามเชิงเทคนิคแล้ว LLM ตอบได้ตรงมาก จากนั้นพนักงานจริงมารับช่วงต่อแต่กลับดูเชี่ยวชาญน้อยกว่า อย่างน้อยก็ช่วยประหยัดเวลาได้
    • มันดีกว่าระบบหุ่นยนต์สมัยก่อนมาก และ แชตบอตที่ใช้ RAG ก็มีประโยชน์มากจนแทบแทนการค้นหาเอกสารได้ เช่น แชตบอตของ manager.io ตอบตรง ๆ ได้เลยโดยไม่ต้องไปเปิดเอกสาร สะดวกมาก

  • ตามบทความ อู่แห่งนี้กำลังเสียรายได้ หลายพันดอลลาร์ต่อเดือน เพราะรับโทรศัพท์ไม่ทัน ถ้าอย่างนั้นจ้าง receptionist แบบ outsourced เดือนละราว 500 ดอลลาร์น่าจะให้ ROI ดีกว่ามาก

    • จริง ๆ แค่ voicemail ก็ช่วยแก้ปัญหาได้บางส่วนแล้ว ไม่ว่าจะ AI หรือ voicemail ลูกค้าบางคนก็ตัดสายอยู่ดี
    • แถมถ้างานล้นจนรับโทรศัพท์ไม่ได้อยู่แล้ว ก็มีโอกาสสูงว่าต่อให้ได้ลูกค้าเพิ่มก็อาจไม่มีศักยภาพพอจะรับงานเพิ่ม
    • เพื่อนของฉันใช้ บริการรับสาย outsourced อยู่ เดือนละ 150 ปอนด์ ครอบคลุมเวลา 9 โมงถึง 5 โมงเย็น ส่วนเจ้าตัวค่อยไปจัดตารางตอนเย็น ถ้าสิ่งที่บทความเขียนเป็นจริง ตอนนี้อู่ก็น่าจะทำงานเต็ม 100% ของกำลังการผลิต อยู่แล้ว
    • service writer ที่ดีค่าตัวแพง แต่ก็คุ้มค่า เพราะช่วยสร้างความเชื่อมั่นให้ลูกค้า และต่อไปอาจถึงขั้นรับช่วงกิจการได้
    • สุดท้าย ROI ก็อาจเป็นแค่ผลด้านการตลาดของ คอร์สสอน AI ที่บล็อกนี้พยายามโปรโมตเท่านั้น

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

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

  • เขาบอกว่า “นี่ไม่ใช่แชตบอตแบบทั่วไป” แต่เอาเข้าจริงมันก็แทบไม่ต่างจาก แชตบอตแบบทั่วไปฉบับปี 2026

  • ฉันไปดูหน้า “About” ของบล็อกแล้ว ผู้เขียนบอกว่าได้แรงบันดาลใจจากอินฟลูเอนเซอร์ที่ ร่ำรวยจากการเรียนเขียนโค้ด แต่ท่าทีแบบนี้มันห่างไกลจาก ทิศทางของวัฒนธรรมวิศวกรรม ที่ฉันอยากเห็น

  • รู้สึกหดหู่นิดหน่อยที่คนเริ่ม เขียนบล็อกส่วนตัวด้วย AI

    • แต่ก็ชื่นชมที่อย่างน้อยเขาพูดตรง ๆ คนส่วนใหญ่ไม่ได้มีประสบการณ์ในการเขียนมากนัก และคิดว่า LLM ช่วยให้ได้ “งานเขียนที่ดี” สำหรับพวกเขาแล้ว ข้อความที่ AI เขียนอาจไม่ได้ดูแย่เลยก็ได้

  • ที่นี่จำเป็นต้องใช้ RAG จริงหรือ? ถ้ามีแค่ตารางราคาและเวลาทำการ มันก็ใส่ไว้ใน context window ได้หมด

    • น่าจะเป็นโปรเจกต์เพื่อการเรียนรู้มากกว่า ฉันเองก็เคยลองใช้ สถาปัตยกรรมที่เกินความจำเป็น ในโปรเจกต์ส่วนตัวเพื่อเรียนรู้เหมือนกัน
    • สำหรับบทสนทนาด้วยเสียง latency เป็นปัญหาที่ใหญ่กว่า ถ้าในเว็บมีหลายหน้า การใช้ RAG เพื่อดึงมาแค่บางส่วนอย่างรวดเร็ว แล้วให้ LLM สร้างคำตอบละเอียดต่อ น่าจะมีประสิทธิภาพกว่า
    • เอาเว็บไซต์ทั้งเว็บกับตารางราคาทั้งหมดใส่ใน context ไปเลยน่าจะง่ายกว่า
    • ฉันก็เห็นด้วย ข้อมูลระดับนี้ประมวลผลทีเดียวได้สบาย
    • โดยรวมแล้ว สถาปัตยกรรมนี้ซับซ้อนเกินไป