วิเคราะห์อย่างละเอียด: แผนการดำเนินงานระยะที่ 2 (TaijiFlow AI Phase 2)

เอกสารฉบับนี้ทำการวิเคราะห์จุดเด่น ความท้าทายทางเทคนิค ข้อจำกัด และข้อเสนอแนะสำหรับการยกระดับสถาปัตยกรรมระบบ TaijiFlow AI จาก Client-side สู่ Client-Server (3-Tier) ตามแผน [phase2_plan.md](file:///Users/yut/TaijiFlow/phase2_plan.md)

---

1. การประเมินโครงสร้างสถาปัตยกรรม (Architectural Evaluation)

การเปลี่ยนผ่านจาก Pure Client-side (HTML/JS + MediaPipe) ไปสู่ Client-Server (FastAPI + Supabase) มีข้อดีและข้อจำกัดที่ต้องนำมาพิจารณาเปรียบเทียบดังนี้:

มิติการเปรียบเทียบ	สถาปัตยกรรมเดิม (Client-side)	สถาปัตยกรรมใหม่ (Client-Server / 3-Tier)	การประเมินสำหรับการนำไปใช้
การประมวลผล (Compute)	ทำงานบนเบราว์เซอร์ของผู้ใช้ทั้งหมด (ลดภาระเซิร์ฟเวอร์)	แบ่งส่วน: ย้าย Heuristics ไปรันบน Python Backend	ดีสำหรับการเตรียมความพร้อมสู่ AI Phase 3 (Deep Learning) ซึ่งจำเป็นต้องใช้ทรัพยากรบนฝั่ง Server
ความหน่วง (Latency)	ต่ำมาก (Real-time feedback แทบจะเป็นศูนย์วินาที)	สูงขึ้นเล็กน้อย หากเป็นการส่งพิกัดแบบจบเซสชันจะไม่มีความหน่วงระหว่างรำ	การส่งแบบ Post-Session (จบแล้วค่อยวิเคราะห์) ดีต่อเสถียรภาพ แต่ผู้ใช้จะไม่ได้รับ Real-time feedback ระหว่างฝึก
การปกป้อง IP/Algorithm	ต่ำ (เนื่องจากโค้ด Heuristics ใน JS สามารถถูกตรวจพบได้ในฝั่ง Client)	สูง (โค้ดคำนวณไทเก๊กทั้งหมดอยู่บน Backend)	ป้องกันตรรกะทางธุรกิจและการคำนวณที่สำคัญได้เป็นอย่างดี
การรวบรวมข้อมูล (Data Gathering)	ทำไม่ได้ (ไม่มีฐานข้อมูลกลาง)	สูงมาก (บันทึกข้อมูลพิกัดลง Supabase เป็น Dataset ทันที)	ตอบโจทย์วัตถุประสงค์หลักของ Phase 2 เพื่อสะสม Dataset

WARNING

การสูญเสีย Real-time Feedback:
ในโครงสร้างเดิมของ [heuristics_engine.js](file:///Users/yut/TaijiFlow/src/js/core/heuristics_engine.js) ระบบจะให้เสียงหรือแจ้งเตือนทันทีขณะผู้ฝึกทำผิด (เช่น ศอกลอย หรือเคลื่อนไหวเร็วเกินไป) หากย้ายกฎทั้งหมดไปไว้ฝั่ง Backend และส่งแบบ Post-session ผู้ใช้จะไม่ได้รับเสียงเตือนระหว่างฝึก จะได้เพียงคะแนนและสถิติตอนรำเสร็จเท่านั้น

💡 ข้อเสนอแนะ: สถาปัตยกรรมแบบไฮบริด (Hybrid Architecture)

เพื่อให้ได้ประโยชน์สูงสุดทั้งสองทาง ควรแบ่ง Heuristics ออกเป็น 2 ระดับ:

1. Client-side (Lite Heuristics): ใช้โค้ด JS ชุดเดิมสำหรับตรวจสอบเบื้องต้นที่ต้องการการตอบสนองทันที เช่น ศอกลอย (RuleElbowSinking), ความเร็วและความต่อเนื่อง (RuleSmoothness / RuleContinuity)
2. Server-side (Deep Heuristics & Dataset Ingestion): ใช้ Python Backend วิเคราะห์การเคลื่อนไหวภาพรวมของเซสชันที่ซับซ้อน เช่น ความสัมพันธ์ของสองมือ (RuleCoordination), ความแม่นยำของวิถีวงโคจร 8 ท่า (RulePathShape), การประเมินคะแนนเชิงลึก และทำหน้าที่บันทึกพิกัดทั้งหมดลง Database

---

2. การวิเคราะห์ราย Sprint (Sprint-by-Sprint Analysis)

Sprint 1: Infrastructure & Authentication

• วิเคราะห์ความพร้อม: Supabase เหมาะสมอย่างยิ่งสำหรับโปรเจกต์นี้เนื่องจากรวมทั้ง Postgres DB, Auth (JWT), และ Storage ไว้ในที่เดียว
• ความท้าทายด้านความปลอดภัย (Security Gotchas):
  • เมื่อเปิดใช้งานระบบ Auth จำเป็นต้องตั้งค่า Row Level Security (RLS) บน Supabase เพื่อความปลอดภัย ป้องกันไม่ให้ User A สามารถเข้าไปดูข้อมูลการฝึกหรือลบไฟล์ JSON ของ User B ได้
  • ต้องออกแบบการเชื่อมต่อระหว่าง Frontend -> FastAPI -> Supabase ให้รองรับการตรวจสอบสิทธิ์ผ่าน JWT (Bearer Token)
• ข้อเสนอแนะด้าน DB Schema:
  • ตาราง users: ควรผูกกับ auth.users ของ Supabase ผ่าน UUID และมีฟิลด์ role (เช่น 'trainee', 'expert', 'admin') เพื่อนำมาใช้ในการระบุสิทธิ์และควบคุมการเข้าถึงหรือแสดงผลแดชบอร์ดให้ตรงกับบทบาทของผู้ใช้แต่ละประเภท
  • ตาราง training_sessions: ควรมีคอลัมน์เก็บ Metadata ที่จำเป็นต่อการพัฒนา AI เช่น:
    • exercise_id (ท่าที่ฝึก เช่น 2h_cw_cw หรือ 2h_ccw_ccw)
    • device_info (ชนิดกล้องหรือประเภทอุปกรณ์ เพื่อคัดกรอง Dataset ที่มี Noise สูง)
    • fps_average (อัตราเฟรมเฉลี่ยของเซสชันนั้น ๆ)
    • coordinate_file_url (ลิงก์ไปยังไฟล์ JSON ใน Supabase Storage)

---

Sprint 2: Data Pipeline & Backend Setup

• วิเคราะห์ขนาดของข้อมูล (Payload Size & Optimization):
  • พิกัดจาก MediaPipe ประกอบด้วย 33 Landmarks โดยแต่ละจุดมีค่า x, y, z, visibility (4 floats)
  • หากฝึก 1 นาทีที่ 30 FPS:
    30 เฟรม/วินาที * 60 วินาที = 1,800 เฟรม
1,800 เฟรม * 33 จุด * 4 ค่า = 237,600 ค่าตัวเลข
  • ในรูปแบบ JSON ปกติ ขนาดไฟล์อาจมีขนาดถึง 3MB - 6MB ต่อการรำ 1 นาที ซึ่งเป็นภาระในการอัปโหลดทางฝั่ง Client (โดยเฉพาะกรณีใช้เน็ตมือถือ)
• 💡 วิธีแก้ปัญหาเพื่อลดขนาดไฟล์ (Optimization Strategies):
  1. ลดพิกัดที่ไม่จำเป็น: หากเน้นการวิเคราะห์ม้วนไหม 2 มือ อาจไม่ต้องบันทึกพิกัดของใบหน้าหรือเท้าอย่างละเอียด (ลดจุดลงเหลือเฉพาะ Upper Body + สะโพก + ข้อเท้า รวม 15-20 จุด)
  2. ลดทศนิยม (Decimal Precision): ปรับทศนิยมพิกัดให้อยู่ที่ 4 ตำแหน่ง (เช่น 0.1234) แทนที่จะเป็น float64 เต็มรูปแบบ ซึ่งลดขนาดไฟล์ JSON ได้มากกว่า 50%
  3. โครงสร้างแบบแบน (Flat Structure): แทนที่จะเก็บเป็น {"x": 0.12, "y": 0.34} ทุกจุด ให้เก็บเป็น Array ราบ เช่น [0.12, 0.34, 0.56, 0.99]
  4. การบีบอัดข้อมูล (Compression): บีบอัดไฟล์ JSON ด้วย GZIP บนเบราว์เซอร์ก่อนทำการส่งขึ้น FastAPI Backend

---

Sprint 3: Two-Hand Heuristics Engine

• การแปลงโค้ดจาก JS เป็น Python:
  • เนื่องจากใน Python มีไลบรารีทางวิทยาศาสตร์ที่มีประสิทธิภาพสูง เช่น NumPy และ SciPy การแปลตรรกะเชิงเรขาคณิต (Vector math) เช่น ผลคูณไขว้ (Cross Product) ใน [rule_path_shape.js](file:///Users/yut/TaijiFlow/src/js/rules/rule_path_shape.js) หรือ จุดศูนย์ถ่วงใน [rule_weight_shift.js](file:///Users/yut/TaijiFlow/src/js/rules/rule_weight_shift.js) จะสามารถเขียนได้กระชับและรวดเร็วกว่าใน JS มาก
• การพัฒนาตรรกะสำหรับท่าม้วนไหม 2 มือ (8 ท่า):
  • เมื่อขยับมาทำท่า 2 มือ กฎความสัมพันธ์ (Symmetry & Coordination) จะมีความสำคัญมาก
  • ต้องพัฒนา RuleCoordination (ความสัมพันธ์ส่วนบนและส่วนล่าง) ให้ครอบคลุม:
    • ความสัมพันธ์ของสองมือ (Hand-to-Hand Coordination): เช่น มือหนึ่งผลักออก มือหนึ่งดึงกลับ (ต้องมีทิศทางของเวกเตอร์สวนทางกันอย่างสัมพันธ์กัน)
    • การประสานงานของเอวและมือ (Waist-Hand Coordination): การเคลื่อนไหวของมือทั้งสองต้องเริ่มเคลื่อนจากศูนย์กลาง (เอว/สะโพก) ไม่ใช่เคลื่อนเฉพาะแขน
  • จำเป็นต้องมีการเตรียมไฟล์อ้างอิงเชิงตำแหน่ง (Reference Paths) สำหรับท่า 2 มือ ทั้ง 8 ท่า ไว้บนฝั่ง Python Backend ด้วย

---

Sprint 4: Testing, Integration & Deployment

• ระบบการ Deploy ที่มีประสิทธิภาพ:
  • Frontend: สามารถนำขึ้น Vercel ได้อย่างรวดเร็ว (ตามเวิร์กโฟลว์ที่มีอยู่ [deploy_to_vercel.md](file:///Users/yut/TaijiFlow/.agent/workflows/deploy_to_vercel.md))
  • Backend (FastAPI): แนะนำให้ใช้ Render หรือ Railway เนื่องจากตั้งค่า Docker หรือ Python Environment ได้สะดวกและมีค่าบริการเริ่มต้นต่ำ (หรือฟรี)
  • ประเด็นเรื่อง CORS: ต้องตั้งค่า FastAPI CORS Middleware ให้รับทราฟฟิกจากโดเมนของ Frontend บน Vercel เท่านั้นเพื่อความปลอดภัย
• ผลลัพธ์การพัฒนาจริง (Actual Implementation):
  • Python Data Validation: พัฒนาสคริปต์ research/validate_dataset.py พร้อม dependencies ใน research/requirements.txt รองรับการรันตรวจสอบความเสถียรข้อมูลพิกัด (Local JSON/Directory หรือ Cloud Supabase Storage & DB Query) วิเคราะห์ Schema, 33 Landmarks, ความละเอียดทศนิยม 4 ตำแหน่ง, ตรวจสอบ NaN/null และความราบรื่นในการนำไปแปลงเป็น NumPy matrix รูปทรง (frames_count, 33, 4) และ Pandas DataFrame เพื่อพร้อมใช้ในการเทรนโมเดล Deep Learning ในเฟสถัดไป
  • Supabase Client Resiliency: ปรับปรุงกลไกตรวจสอบและเชื่อมต่อ SDK ผ่านตัวตรวจจับ CDN สำรอง (Dynamic CDN Fallbacks: jsDelivr -> UNPKG -> CDNJS) และอัปเดตระบบสมาชิกให้เรียกใช้งาน Client แบบ On-demand ป้องกันปัญหา "Supabase client not ready" เมื่อกดปุ่มฟังก์ชันต่าง ๆ

---

3. ข้อเสนอแนะในการปรับปรุงแผนงาน (Proposed Enhancements)

เพื่อให้แผนระยะที่ 2 สมบูรณ์ยิ่งขึ้น ขอเสนอให้เพิ่มรายละเอียดต่อไปนี้เข้าไปในแผนการดำเนินงาน:

1. การยืนยันตัวตนบน Backend (Backend JWT Verification):
   • กำหนดให้ API ทุกจุดที่ต้องบันทึกประวัติ (เช่น /session/save) ต้องดักจับ Authorization: Bearer <JWT> เพื่อถอดรหัสความปลอดภัยและยืนยันว่าผู้ใช้คือเจ้าของข้อมูลจริง
2. การทำ Data Versioning & Labeling:
   • เนื่องจากเป้าหมายคือการสร้าง Dataset เพื่อใช้ฝึก AI ในเฟสถัดไป ไฟล์ JSON ที่บันทึกขึ้น Supabase Storage ควรมีการตั้งชื่อและแนบ Metadata เพื่อทำความสะอาดข้อมูล (Data Cleaning) ได้ง่าย เช่น: {user_id}/{exercise_id}_L{level}_{timestamp}_score{score}.json
3. การวางแผนความท้าทายด้านการตรวจจับ (Skeleton Occlusion):
   • ท่าม้วนไหมแบบ 2 มือ จะมีการทับซ้อนกันของมือและแขน (Occlusion) บ่อยครั้งเมื่อมองผ่านกล้องเว็บแคม 2D ซึ่งมักทำให้ MediaPipe หาจุดข้อมือผิดพลาดชั่วขณะ
   • แนะนำให้เขียนตรรกะช่วยแก้ปัญหาในท่อส่งข้อมูลฝั่ง Python เช่น การกรองข้อมูลแบบ Kalman Filter หรือการใช้ค่าเฉลี่ยเคลื่อนที่ (Moving Average) เพื่อเกลี่ยจุดที่กระโดดเนื่องจากกล้องจับไม่ทัน

---

สรุปคำถามสำคัญสำหรับการตัดสินใจเชิงออกแบบ (Key Design Questions)

เพื่อให้ทิศทางการพัฒนาชัดเจนยิ่งขึ้น มีประเด็นสำคัญที่ต้องเลือกแนวทางดังนี้:

1. เรื่อง Real-time Feedback: จะเลือกแนวทางใด?
   • แนวทาง A: ยกเลิกการวิเคราะห์ระหว่างรำ เน้นแสดงผลคะแนนรวมหลังรำเสร็จเท่านั้น (ตามแผน Sprint 2-3 เดิม)
   • แนวทาง B (แนะนำ): ใช้สถาปัตยกรรมแบบไฮบริด (Hybrid) ให้เบราว์เซอร์ทำตรรกะ Heuristics ง่าย ๆ แบบสด ๆ ส่วนเซิร์ฟเวอร์เก็บข้อมูลดิบเพื่อวิเคราะห์สรุปผลภาพรวม
2. เรื่องคุณภาพของ Dataset: จะเปิดให้ผู้ใช้อัปโหลดวิดีโอ (.mp4) ด้วยหรือไม่?
   • ข้อดี: มีวิดีโอจริงเพื่อใช้ตรวจเช็คความถูกต้องเทียบกับพิกัดโครงกระดูก (Ground Truth Labeling) ได้แม่นยำยิ่งขึ้นในระยะที่ 3
   • ข้อเสีย: อัตราการใช้พื้นที่เก็บข้อมูล (Storage Cost) จะสูงขึ้นมาก และผู้ใช้ต้องรออัปโหลดนานขึ้น