Proposal
| ชื่อ-สกุล | รหัสนักศึกษา | GitHub Account | Role |
|---|---|---|---|
| กิตติธัช เด่นสกุลประเสริฐ | 6609650079 | @Kittithatdensakulprasert | Backend Developer |
| พิรญาณ์ เอนอ่อน | 6609650087 | @Creampiraya | Security Lead |
| กิตติภณ คำนวล | 6609650186 | @KittiphonKamnuan | Project Manager |
| ณัฏฐ์ ศรีสุวรรณกุล | 6609650327 | @Nattsrisuwankul | DevOps Engineer |
| ธนกฤต พิบูลย์สวัสดิ์ | 6609650400 | @Thanakritpiboonsawat | DevOps Engineer |
| พชร พรพงศ์ | 6609650509 | @Phachara6609650509 | Frontend Developer |
ปัจจุบันรายการ สถานีประชาชน ของ ThaiPBS ได้รับเรื่องร้องเรียนเกี่ยวกับกลโกงจากประชาชนผ่านช่องทาง Line Official Account (Line OA) เป็นจำนวนมาก ซึ่งข้อความที่ส่งเข้ามามีทั้งความยาว เนื้อหา และรายละเอียดที่หลากหลาย ทำให้แอดมินผู้ดูแลต้องรับภาระในการคัดกรองข้อความจำนวนมาก นำมารวมเรียบเรียงเป็นพารากราฟสำหรับจัดเก็บลงฐานข้อมูลและไฟล์ Excel รวมถึงต้องจัดลำดับความสำคัญของเรื่องราวเพื่อส่งต่อให้นักข่าวนำไปสืบค้นและผลิตรายการ
กระบวนการดังกล่าวใช้เวลานาน มีความซ้ำซ้อน และเสี่ยงต่อการตกหล่นของข้อมูลสำคัญ ส่งผลให้การตอบสนองต่อปัญหาของประชาชนล่าช้าและไม่ทันต่อสถานการณ์
ความต้องการหลักของโครงการ คือการพัฒนาระบบหรือแนวทางที่ช่วยสนับสนุนการคัดกรองและจัดการข้อมูลร้องเรียนให้มีความถูกต้อง รวดเร็ว และลดภาระงานของแอดมิน เพื่อให้นักข่าวและทีมงานสามารถนำข้อมูลไปใช้ได้อย่างมีประสิทธิภาพและทันเวลา
- ระบบ AI/Rule-based ในการจัดหมวดหมู่คดี (เช่น ฉ้อโกง, ปัญหากฎหมาย, แจ้งเบาะแส)
- มีระบบตรวจจับ Pattern ที่ซ้ำบ่อย
- ลดภาระงานแอดมิน โดยให้ระบบช่วยคัดกรองเบื้องต้น
- ลดเวลาเฉลี่ยในการตรวจสอบเรื่องร้องเรียน จากหลายนาทีให้น้อยลงเป็นวินาที
- มี Dashboard รวมสถิติ เช่น จำนวนเคส, หมวดหมู่, ความเร่งด่วน
- ได้รับข้อมูลที่คัดกรองแล้ว มีความถูกต้อง/น่าเชื่อถือมากขึ้น
- ข้อมูลที่พร้อมนำไปทำข่าวได้ทันที
- ลดความล่าช้าในการนำเสนอข่าวจากการคัดกรอง
- เพิ่มความถูกต้อง (Accuracy) ของการคัดกรองข่าว/คดี
- รองรับการใช้งานพร้อมกันของผู้ใช้จำนวนมาก (Scalability)
- ลด Delay ในการส่งต่อข้อมูลจากประชาชน → แอดมิน → นักข่าว/หน่วยงาน
- ต้องการช่องทางที่ใช้ง่ายในการแจ้งปัญหากลโกง
- คาดหวังให้เรื่องราวของตนถูกคัดเลือกและนำเสนอ
- เป็นผู้รับผิดชอบตรวจสอบและคัดกรองข้อความ
- ต้องการเครื่องมือช่วยลดภาระงานและเพิ่มประสิทธิภาพ
- ต้องการข้อมูลที่ถูกคัดกรองแล้ว พร้อมสรุปเนื้อหาเพื่อใช้ทำข่าว
- ต้องได้รับข้อมูลอย่างรวดเร็วและครบถ้วน
- ต้องการสร้างความเชื่อมั่นและตอบสนองต่อปัญหาสังคมได้ทันท่วงที
- ต้องรักษาภาพลักษณ์และความน่าเชื่อถือของสื่อสาธารณะ
- ได้รับข้อมูลข่าวสารเกี่ยวกับกลโกงที่ถูกต้องและเป็นประโยชน์
- เพิ่มการรับรู้เพื่อป้องกันตนเองไม่ให้ตกเป็นเหยื่อ
- ระบบ AI/Rule-based ในการจัดหมวดหมู่คดี (เช่น ฉ้อโกง, ปัญหากฎหมาย, แจ้งเบาะแส)
- มีระบบตรวจจับ Pattern ที่ซ้ำบ่อย
- ลดภาระงานแอดมิน โดยให้ระบบช่วยคัดกรองเบื้องต้น
- ลดเวลาเฉลี่ยในการตรวจสอบเรื่องร้องเรียน จากหลายนาทีให้น้อยลงเป็นวินาที
- มี Dashboard รวมสถิติ เช่น จำนวนเคส, หมวดหมู่, ความเร่งด่วน
- ได้รับข้อมูลที่คัดกรองแล้ว มีความถูกต้อง/น่าเชื่อถือมากขึ้น
- ข้อมูลที่พร้อมนำไปทำข่าวได้ทันที
- ลดความล่าช้าในการนำเสนอข่าวจากการคัดกรอง
- เพิ่มความถูกต้อง (Accuracy) ของการคัดกรองข่าว/คดี
- รองรับการใช้งานพร้อมกันของผู้ใช้จำนวนมาก (Scalability)
- ลด Delay ในการส่งต่อข้อมูลจากประชาชน → แอดมิน → นักข่าว/หน่วยงาน
- ต้องมีอินเตอร์เน็ตและมีแอพพลิเคชั่น Line เพื่อแจ้งเบาะแสหรือข้อมูลผ่าน Line OA ได้
- การดำเนินการงานต้องมีเครดิตสำหรับใช้ AWS service เพียงพอ
- ผู้ใช้ยินยอมให้เผยแพร่ข้อมูลให้สามารถนำไปทำข่าวได้ และเป็นไปตามกฎหมาย PDPA
- นำ AI เข้ามาช่วยในการแบ่งแยก case (การฉ้อโกง, ปัญหาทางกฎหมาย) และหา pattern ที่ซ้ำเพื่อช่วยประหยัดเวลาในการดำเนินการ
- สามารถนำข้อความของผู้ใช้งานมาสรุปและจัดรูปแบบเป็นรายงานสำหรับนักข่าวได้ เพื่อช่วยลดประหยัดแรงในการทำงานของแอดมิน
- ต้องสอดคล้องกับ PDPA/กฎหมายคุ้มครองข้อมูลส่วนบุคคล (ข้อมูลผู้ร้องเรียนต้องปลอดภัยและไม่รั่วไหล)
- ทีมพัฒนามีจำนวนจำกัดและงบประมาณสำหรับ AWS มีไม่มากและมีจำกัด
- ระบบต้องเสร็จภายในกรอบเวลาที่กำหนด (เสร็จภายใน 1 เทอม)
- เริ่มแรกอาจจะรองรับแค่ภาษาไทยเท่านั้น ภาษาถิ่นอาจจะต้องพัฒนาเพิ่ม
- ข้อมูลที่ส่งมาอาจไม่ครบถ้วน, มีการสะกดผิด, หรือเป็นข้อมูลเท็จ
- ระบบต้องสามารถ validate และ flag ข้อมูลที่น่าสงสัยได้
แนวทาง: พัฒนาระบบ Automation เพื่อลดงานซ้ำซ้อนของแอดมิน
ตัวอย่าง:
- ระบบมอนิเตอร์ริ่ง (Monitoring): ติดตามสถานะการทำงานของระบบแบบเรียลไทม์ และแจ้งเตือนทันทีเมื่อเกิดข้อผิดพลาด
- แดชบอร์ด: แสดงผลการทำงาน เช่น จำนวนข้อความที่เข้ามาในแต่ละวัน, ประเภทกลโกงที่พบบ่อย
แนวทาง: ปกป้องข้อมูลส่วนบุคคลของประชาชน และป้องกันการเข้าถึงจากบุคคลทั่วไป
ตัวอย่าง:
- การจัดการสิทธิ์ (IAM): ใช้บริการอย่าง IAM เพื่อกำหนดและจัดการสิทธิ์ให้แก่แอดมินและทีมงาน เช่น กำหนดให้แอดมินสามารถดูและแก้ไขข้อมูลได้ แต่ให้นักข่าวสามารถดูได้อย่างเดียว
- การยืนยันตัวตน (Authentication): ใช้บริการอย่าง Amazon Cognito หรือระบบที่คล้ายกัน เพื่อยืนยันตัวตนของผู้ใช้งาน (Admin) ที่ได้รับอนุญาตเท่านั้น
- การเข้ารหัส: ใช้การเข้ารหัสแบบ SSL/TLS เพื่อปกป้องข้อมูลระหว่างการส่ง (Data in Transit) และใช้ AES-256 เพื่อเข้ารหัสข้อมูลที่จัดเก็บ (Data at Rest) ในฐานข้อมูล
แนวทาง: ทำให้ระบบทำงานได้ต่อเนื่องและข้อมูลไม่สูญหาย
ตัวอย่าง:
- ความพร้อมใช้งานสูง (High Availability): ติดตั้งระบบบน Availability Zones (AZs) ที่แตกต่างกันใน Cloud เพื่อให้หาก AZ หนึ่งล่ม ระบบจะยังคงทำงานได้ตามปกติใน AZ อื่น
- การสำรองข้อมูล (Backup): สำรองข้อมูลอย่างสม่ำเสมอ และมี แผนกู้คืนระบบฉุกเฉิน (Disaster Recovery Plan) ที่ชัดเจน
แนวทาง: ประมวลผลข้อความจำนวนมากได้อย่างรวดเร็ว
ตัวอย่าง:
- การปรับขนาดอัตโนมัติ (Autoscaling): ใช้เทคโนโลยี Serverless Architecture (เช่น AWS Lambda) ที่จะเพิ่มหรือลดกำลังประมวลผลให้โดยอัตโนมัติตามปริมาณข้อความ
แนวทาง: ใช้ทรัพยากรอย่างคุ้มค่า
ตัวอย่าง:
- จ่ายตามการใช้งานจริง (Pay-as-you-go): เลือกใช้บริการ Cloud ที่คิดค่าใช้จ่ายตามปริมาณที่ใช้จริง (เช่น Serverless) เพื่อลดต้นทุน
- การจัดการพื้นที่จัดเก็บข้อมูล: ย้ายข้อมูลเก่าที่ไม่ค่อยได้ใช้งานไปเก็บใน Storage Tier ที่มีราคาถูกกว่า
Focus: การทดสอบความสามารถของ AI และฐานข้อมูล (Database)
Development:
- สร้าง Prototype เชื่อมต่อ Database (RDS/DynamoDB) กับระบบรับข้อความจาก Line OA
- พัฒนา AI Model (NLP / Rule-based) สำหรับคัดกรองข้อความร้องเรียน → แยกหมวดหมู่ (ฉ้อโกง, ปัญหากฎหมาย, ฯลฯ)
- ทำ Performance Testing เบื้องต้น → วัด Response Time / Throughput
Improvement:
- Optimize Query และ Index Database ให้รองรับข้อความมากขึ้น
- ปรับ AI ให้รองรับข้อความที่เป็นภาษาไทยผสมภาษาอังกฤษ (Code-switching)
- Benchmark → ตั้ง KPI: Response Time ≤ 15 วินาที, Accuracy ≥ 80%
Pillar ที่ตอบโจทย์: Performance Efficiency, Operational Excellence
Focus: สร้างระบบติดตาม (Monitoring) และปรับปรุงคุณภาพระบบให้โปร่งใส
Development:
- ติดตั้ง CloudWatch Dashboard → แสดง Metric เช่น Latency, Error Rate, Throughput
- ใช้ CloudWatch Logs + Alarms เพื่อตรวจสอบปัญหาแบบ Real-time
- เพิ่ม Cost Explorer เพื่อติดตามค่าใช้จ่ายจาก AI และ Database
Improvement:
- สร้างระบบ Well-Architected Checklist → ตรวจสอบ Pillars: Security, Reliability, Performance, Cost
- ทำ Load Test → วัด Scalability รองรับข้อความ 1,000–1,500 เรื่อง/วัน
- Optimize ค่าใช้จ่าย → ใช้ Serverless (Lambda + SQS) และจัดเก็บ Log ใน Storage Tier ที่ราคาถูก
Pillar ที่ตอบโจทย์: Reliability, Security, Cost Optimization
Focus: ทำให้ระบบเสถียร พร้อมใช้งานจริง และรองรับการปรับปรุงต่อเนื่อง
Development:
- จัดทำ CI/CD Pipeline (CodePipeline + CodeBuild + CodeDeploy) → Auto Deployment
- กำหนด IAM Role & Access Control (Admin แก้ไขได้, นักข่าวอ่านอย่างเดียว)
- วาง Disaster Recovery Plan และ Backup Policy สำหรับ Database
Improvement:
- ทำ Auto Scaling เพื่อรองรับ Peak Load แบบอัตโนมัติ
- เพิ่ม Automated Testing (Unit + Integration Test) ใน Pipeline
- ทำ UAT (User Acceptance Test) กับแอดมินและนักข่าวจริง → เก็บ Feedback
Pillar ที่ตอบโจทย์: Operational Excellence, Reliability, Security, Performance Efficiency
-
ประสิทธิภาพการคัดกรอง: ระบบสามารถจัดกลุ่ม/จัดลำดับความสำคัญของข้อความร้องเรียนได้อย่างถูกต้อง ≥ 90% เมื่อเทียบกับการคัดกรองของแอดมิน
-
ลดเวลาในการทำงานแอดมิน: เวลาเฉลี่ยในการคัดกรองและสรุปเรื่องราวต่อเคส ลดลง ≥ 50% จากกระบวนการเดิม
-
ความครบถ้วนของข้อมูล: อัตราการตกหล่นของข้อความร้องเรียน ≤ 5%
-
ความพึงพอใจของผู้ใช้งาน (แอดมิน/นักข่าว): ได้คะแนน ≥ 80% จากแบบสอบถามหลังการใช้งานระบบ
-
ความรวดเร็วในการส่งต่อข้อมูลให้นักข่าว: นักข่าวสามารถเข้าถึงข้อมูลสรุปที่พร้อมใช้งานภายใน ≤ 1 ชั่วโมงหลังจากมีการส่งเรื่องร้องเรียน
-
การเข้าถึงง่ายของผู้ร้องเรียน: ผู้ร้องเรียนสามารถส่งข้อมูลผ่าน Line OA ได้โดยไม่ซับซ้อน (จำนวนข้อความที่ไม่สมบูรณ์ < 10%)
-
การสนับสนุนองค์กร: ThaiPBS สามารถใช้ข้อมูลจากระบบนี้เพื่อผลิตเนื้อหาได้จริง และเพิ่มความเร็วในการนำเสนอข่าว ≥ 30% เมื่อเทียบกับก่อนมีระบบ
-
Availability (Uptime): ระบบต้องทำงานได้ต่อเนื่อง ≥ 99.5% ต่อเดือน (Downtime ไม่เกิน ~3.6 ชั่วโมง/เดือน)
-
Response Time: ระบบต้องประมวลผลข้อความร้องเรียนและส่งผลลัพธ์การคัดกรองเบื้องต้น ≤ 15 วินาที ต่อเคส
-
Throughput: รองรับข้อความร้องเรียนอย่างน้อย 500 เรื่อง/วัน โดยไม่ทำให้ระบบล่าช้า
-
Scalability: หากมีปริมาณข้อความเพิ่มขึ้น 2 เท่า (เช่น 1,000 เรื่อง/วัน) ระบบยังคงทำงานได้โดย response time ไม่เกิน 15 วินาที
-
Data Consistency: ข้อมูลทุกเรื่องร้องเรียนต้องถูกจัดเก็บในฐานข้อมูลครบถ้วน โดยมี error rate ≤ 1%
-
Recovery: หากระบบล่ม ต้องสามารถกู้คืนการทำงาน (Recovery Time Objective: RTO) ได้ภายใน ≤ 2 ชั่วโมง