สรุปสาระสำคัญของสัญญา
อ้างอิง TOR: ข้อ 4.6.1, 5, 6, 7.1–7.5, 10.1–10.2, 11.1–11.2, 12.1–12.6
สถานะเอกสาร: เอกสารนี้สรุปเงื่อนไขเชิงสัญญาจากขอบเขตงาน (TOR) เพื่อประกอบระบบสาธิต (Demo) ไม่ใช่สัญญาและไม่มีผลผูกพันทางกฎหมาย ยังไม่มีการลงนามสัญญาระหว่างมหาวิทยาลัยกับผู้รับจ้าง ตัวเลขค่าปรับที่คำนวณเป็นจำนวนเงินเป็นตัวอย่างการคำนวณเพื่อความเข้าใจ ฐานการคำนวณและถ้อยคำที่มีผลบังคับให้ยึดตามสัญญาฉบับลงนามและ TOR ต้นฉบับ
1. ข้อมูลทั่วไปของสัญญา
| รายการ | สาระสำคัญ | TOR |
|---|
| ชื่องาน | จ้างพัฒนาระบบแชตบอตปัญญาประดิษฐ์เฉพาะทางพระพุทธศาสนาและเว็บไซต์ | — |
| ผู้ว่าจ้าง | มหาวิทยาลัยมหามกุฏราชวิทยาลัย (มมร.) | — |
| ผู้รับจ้าง | (ระบุเมื่อทำสัญญา) | — |
| วงเงิน | 5,000,000 บาท (ห้าล้านบาทถ้วน) | 5 |
| ระยะเวลาส่งมอบ | ภายใน 365 วัน | 6 |
| จำนวนงวด | 3 งวด | 7.1–7.3 |
| ระยะเวลารับประกัน | ไม่น้อยกว่า 365 วัน | 11.1 |
| ค่าบริการ Cloud และ LLM API | แยกจากวงเงินโครงการ มหาวิทยาลัยเป็นผู้จัดหา | 4.6.1 |
| สถานที่ติดต่อ | ฝ่ายพัสดุ กองบริหารกลาง มหาวิทยาลัยมหามกุฏราชวิทยาลัย 248 หมู่ 1 ถนนศาลายา-นครชัยศรี ตำบลศาลายา อำเภอพุทธมณฑล จังหวัดนครปฐม 73170 โทร. 02 444 6000 ต่อ 1117–1119 | 17 |
2. งวดงานและการจ่ายเงิน (ข้อ 7.1–7.5)
| งวด | กำหนดส่งมอบ | สัดส่วน | จำนวนเงิน (บาท) | ผลผลิตที่ต้องส่งมอบ |
|---|
| 1 | ภายใน 60 วัน | ร้อยละ 10 | 500,000 | 7.1.1 แผนดำเนินงาน โครงสร้างทีมงาน แผนบริหารความเสี่ยง / 7.1.2 SRS / 7.1.3 User Flow, Wireframe, Prototype / 7.1.4 Master Test Plan, Test Case, Checklist / 7.1.5 รายงานการประชุม รายงานความก้าวหน้า รายงานสรุปงวด |
| 2 | ภายใน 240 วัน | ร้อยละ 60 | 3,000,000 | 7.2.1 Frontend บน Production / 7.2.2 Backend และ AI Engine บน Production / 7.2.3 ระบบประเมินผล ชุด Benchmark ครบ และ Baseline Report / 7.2.4 Data Ingestion Plan / 7.2.5 รายงานนำเข้าข้อมูลไม่น้อยกว่าร้อยละ 20 / 7.2.6 รายงาน Vulnerability Scan และ Penetration Test / 7.2.7 รายงาน AI Security และ Guardrail Testing / 7.2.8 Production Beta การสาธิต และบัญชีสำหรับคณะกรรมการ / 7.2.9 รายงานการประชุมและรายงานความก้าวหน้า |
| 3 | ภายใน 365 วัน | ร้อยละ 30 | 1,500,000 | 7.3 ส่งมอบระบบครบถ้วน นำเข้าข้อมูลครบ ฝึกอบรม และถ่ายโอนระบบ |
| รวม | ร้อยละ 100 | 5,000,000 | |
เงื่อนไขการจ่ายเงิน (ข้อ 7.4): มหาวิทยาลัยจ่ายเงินแต่ละงวดเมื่อผู้รับจ้างส่งมอบงานของงวดนั้นครบถ้วน และคณะกรรมการตรวจรับพัสดุได้ตรวจรับเรียบร้อยแล้ว
รูปแบบเอกสารส่งมอบ (ข้อ 7.5): เอกสารทุกฉบับจัดทำ 2 ชุด พร้อมไฟล์ PDF และไฟล์ต้นฉบับที่แก้ไขได้ ในระบบนี้ไฟล์ต้นฉบับคือไฟล์ Markdown ในหน้า /documents ซึ่งดาวน์โหลดและพิมพ์เป็น PDF ได้ทุกฉบับ
เงื่อนไขด้านคุณภาพที่ผูกกับการตรวจรับ: ผลการประเมิน AI ต้องไม่ต่ำกว่าเกณฑ์ขั้นต่ำตามภาคผนวก ก ข้อ 5.3 (หากต่ำกว่าเกณฑ์จะไม่ตรวจรับ ตามข้อ ก.5.3.1) ไม่มีช่องโหว่ระดับ High/Critical คงค้าง (ข้อ 4.8.1) และไม่มี Defect ระดับ High/Critical คงค้างจาก UAT (ข้อ 4.7.8)
3. ค่าใช้จ่ายที่อยู่นอกวงเงิน (ข้อ 4.6.1)
- ค่าบริการ Cloud (เครื่องแม่ข่าย ฐานข้อมูล พื้นที่จัดเก็บ เครือข่าย) และค่าใช้บริการ LLM API ไม่รวมอยู่ในวงเงิน 5,000,000 บาท
- มหาวิทยาลัยเป็นผู้จัดหาบัญชี Cloud และคีย์ LLM API (API Key) และเป็นผู้รับผิดชอบค่าใช้จ่ายดังกล่าว
- ผู้รับจ้างมีหน้าที่ออกแบบระบบให้มหาวิทยาลัยใส่คีย์ของตนเองผ่านการตั้งค่า โดยไม่ฝังคีย์ในซอร์สโค้ด และจัดให้มีเครื่องมือควบคุมค่าใช้จ่าย ได้แก่ เพดานโทเคนรวมต่อ 24 ชั่วโมง การจำกัดโทเคนต่อคำถาม โหมดไม่พร้อมให้บริการอัตโนมัติ การแจ้งเตือนเมื่อเกินเกณฑ์ และ Dashboard ประมาณการค่าใช้จ่ายตามอัตราที่กำหนดเอง
- ในระบบสาธิต: โมเดลภาษาที่ใช้คือ Typhoon ของ SCB 10X เชื่อมต่อผ่าน API แบบ OpenAI-compatible คีย์และที่อยู่ของบริการกำหนดในไฟล์
.env ซึ่งไม่ถูกบันทึกลง Repository (มีเฉพาะ .env.example ที่ไม่มีค่าคีย์) การเปลี่ยนไปใช้ผู้ให้บริการรายอื่นทำได้ผ่านการตั้งค่าโดยไม่แก้โค้ด (ข้อ 4.4.6)
4. ค่าปรับ (ข้อ 10)
| ข้อ | กรณี | อัตรา | ตัวอย่างการคำนวณ (ฐานวงเงิน 5,000,000 บาท) |
|---|
| 10.1 | ส่งมอบงานล่าช้ากว่ากำหนด | ร้อยละ 0.10 ต่อวัน | 5,000 บาทต่อวัน เช่น ล่าช้า 10 วัน = 50,000 บาท |
| 10.2 | แก้ไขข้อบกพร่องล่าช้ากว่าเวลาที่กำหนดใน SLA | ร้อยละ 0.025 ต่อชั่วโมง | 1,250 บาทต่อชั่วโมง เช่น เกินกำหนด 8 ชั่วโมง = 10,000 บาท |
หมายเหตุ: ตัวอย่างข้างต้นคำนวณจากวงเงินตามสัญญาทั้งจำนวน ซึ่งเป็นฐานเดียวกับที่หน้า /admin/defect-log ของระบบใช้ประมาณการค่าปรับตามข้อ 10.2 (ค่า contract.value ปรับได้ในการตั้งค่า) ฐานการคำนวณ เพดานค่าปรับ และข้อยกเว้นที่มีผลบังคับจริงให้เป็นไปตามสัญญาฉบับลงนาม
5. การรับประกันผลงาน (ข้อ 11)
| ข้อ | สาระสำคัญ |
|---|
| 11.1 | ผู้รับจ้างรับประกันผลงานไม่น้อยกว่า 365 วัน โดยแก้ไขข้อบกพร่องของระบบโดยไม่คิดค่าใช้จ่าย (วันเริ่มนับระยะเวลารับประกันให้เป็นไปตามสัญญาฉบับลงนาม โดยทั่วไปนับถัดจากวันที่มหาวิทยาลัยตรวจรับงานงวดสุดท้าย) |
| 11.2 | ผู้รับจ้างจัดให้มีช่องทางติดต่อในช่วงรับประกัน ได้แก่ อีเมล โทรศัพท์ และช่องทางเร่งด่วน ช่องทางแสดงในหน้า /help และในเอกสารโครงสร้างทีมงาน |
6. ข้อตกลงระดับการให้บริการ (SLA) (ข้อ 12)
6.1 ความพร้อมใช้งานและประสิทธิภาพ
| ข้อ | ตัวชี้วัด | ค่าเป้าหมาย | วิธีวัดในระบบ |
|---|
| 12.1 | ความพร้อมใช้งาน (Availability) | ไม่น้อยกว่าร้อยละ 95 ต่อเดือน | /admin/sla-report |
| 12.2 | First Contentful Paint (FCP) | ไม่เกิน 5 วินาที ที่ p95 | รายงานประสิทธิภาพ |
| 12.2 | Time to First Token (TTFT) | ไม่เกิน 15 วินาที ที่ p95 | บันทึกคำขอและรายงาน SLA |
| 12.2 | อัตราข้อผิดพลาด (Error Rate) | ไม่เกินร้อยละ 5 | บันทึกคำขอและรายงาน SLA |
ร้อยละ 95 ต่อเดือนเทียบเท่าเวลาหยุดให้บริการรวมไม่เกินประมาณ 36 ชั่วโมงในเดือนที่มี 30 วัน (720 ชั่วโมง × ร้อยละ 5)
6.2 ระยะเวลาแก้ไขข้อบกพร่อง
| ข้อ | ระดับความรุนแรง | ระยะเวลาแก้ไข |
|---|
| 12.3 | สูง | ภายใน 24 ชั่วโมง |
| 12.3 | กลาง | ภายใน 48 ชั่วโมง |
| 12.3 | ต่ำ | ภายใน 10 วันทำการ |
การนับเวลา (ข้อ 12.4): นับตั้งแต่มหาวิทยาลัยแจ้งข้อบกพร่อง จนถึงเวลาที่มหาวิทยาลัยยืนยันว่าการแก้ไขเรียบร้อย ระบบบันทึกเวลาแจ้ง เวลาแก้ไขเสร็จ และเวลาที่มหาวิทยาลัยยืนยัน ในหน้า /admin/defect-log พร้อมคำนวณกำหนดเวลาตามระดับความรุนแรงโดยอัตโนมัติ
6.3 การรายงานและสิทธิเรียกค่าปรับ
| ข้อ | สาระสำคัญ |
|---|
| 12.5 | ผู้รับจ้างส่งรายงาน SLA รายเดือนภายในวันที่ 15 ของเดือนถัดไป ประกอบด้วยค่า Availability ค่าประสิทธิภาพ รายการข้อบกพร่อง เวลาที่ใช้แก้ไข และมาตรการป้องกันการเกิดซ้ำ |
| 12.6 | มหาวิทยาลัยมีสิทธิเรียกค่าปรับกรณีผู้รับจ้างไม่ปฏิบัติตาม SLA |
7. เงื่อนไขอื่นที่เกี่ยวข้อง (สรุปโดยย่อ)
| หัวข้อ | สาระสำคัญ | เอกสารรายละเอียด |
|---|
| การรักษาความลับ (ข้อ 13) | ผู้รับจ้างต้องเก็บรักษาข้อมูลของมหาวิทยาลัยเป็นความลับ | confidentiality-statement |
| ข้อมูลส่วนบุคคล (ข้อ 14) | มหาวิทยาลัยเป็นผู้ควบคุมข้อมูล ผู้รับจ้างเป็นผู้ประมวลผลข้อมูล | pdpa-dpa |
| ทรัพย์สินทางปัญญา (ข้อ 15) | กรรมสิทธิ์ในผลงานตกเป็นของมหาวิทยาลัย | ip-statement |
| ข้อกำหนดทั่วไป (ข้อ 16) | ห้ามจ้างช่วง ค่าเป้าหมายและ SLA เป็นส่วนหนึ่งของสัญญา ลำดับความสำคัญของเอกสาร | general-terms |
| การลบทำลายข้อมูลเมื่อสิ้นสุดสัญญา (ข้อ 4.11.3) | ลบหรือทำลายข้อมูลพร้อมออกหนังสือรับรอง | /admin/data-destruction |
8. ตารางสรุปวันสำคัญ (วันที่สมมติ เริ่มสัญญา 1 ตุลาคม พ.ศ. 2569)
| เหตุการณ์ | นับจากวันเริ่มสัญญา | วันที่สมมติ |
|---|
| ส่งมอบงวดที่ 1 | วันที่ 60 | 30 พฤศจิกายน พ.ศ. 2569 |
| ส่งมอบงวดที่ 2 | วันที่ 240 | 29 พฤษภาคม พ.ศ. 2570 |
| ส่งมอบงวดที่ 3 | วันที่ 365 | 1 ตุลาคม พ.ศ. 2570 |
| รายงานความก้าวหน้า | ทุก 30 วัน | ดูเอกสาร progress-report-template |
| รายงาน SLA รายเดือน | ภายในวันที่ 15 ของเดือนถัดไป | — |
| สิ้นสุดการรับประกัน | ไม่น้อยกว่า 365 วันนับจากวันเริ่มรับประกันตามสัญญา | ขึ้นกับวันตรวจรับจริง |
9. สิ่งที่ระบบสาธิตรองรับเงื่อนไขสัญญา
| เงื่อนไข | กลไกในระบบ | ข้อจำกัดของระบบสาธิต |
|---|
| ค่าปรับแก้ไขล่าช้า (10.2) | Defect Log คำนวณชั่วโมงที่เกินกำหนดและค่าปรับประมาณการ | เป็นการประมาณการเพื่อการติดตาม ไม่ใช่การเรียกเก็บ |
| Availability (12.1) | รายงาน SLA คำนวณจากบันทึกการทำงานของระบบ | คำนวณจากช่วงเวลาที่รันสาธิต ไม่ใช่ข้อมูลย้อนหลังเต็มเดือนบน Production |
| FCP/TTFT/Error Rate (12.2) | วัดจากการทดสอบโหลดและบันทึกคำขอ | วัดที่ระดับโหลดของเครื่องสาธิต |
| เวลาแก้ไข (12.3–12.4) | กำหนดเวลาอัตโนมัติและบันทึกเวลายืนยันของมหาวิทยาลัย | — |
| รายงาน SLA รายเดือน (12.5) | ส่งออกรายงานจากหน้า /admin/sla-report | ข้อมูลจากช่วงสาธิต |
| คีย์ LLM ของมหาวิทยาลัย (4.6.1) | กำหนดคีย์ผ่านไฟล์ .env และเลือกโมเดลในหน้า /admin/ai-config | ระบบสาธิตใช้ Typhoon ผ่าน API แบบ OpenAI-compatible |
