พัฒนา AI ราคาเท่าไร: ปัจจัยที่กำหนดงบประมาณ

ทำไมงาน AI ไม่มีราคากลาง

ราคารับพัฒนาซอฟต์แวร์ AI ไม่มีตัวเลขเดียวที่ใช้ได้กับทุกโครงการ เพราะงบประมาณขึ้นอยู่กับคุณภาพข้อมูล ระบบเดิมที่ต้องเชื่อม และระดับความแม่นที่ธุรกิจยอมรับ บทความนี้แยกปัจจัยเหล่านั้นออกเป็นข้อ ๆ เพื่อให้คุณเปรียบเทียบข้อเสนอของผู้รับงานบนเหตุผลชุดเดียวกัน

ห้าปัจจัยที่กำหนดงบประมาณ

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

1) ขอบเขตข้อมูล

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

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

2) คุณภาพเอกสาร

เอกสารที่สแกนเอียง มีตราประทับทับข้อความ หรือเขียนด้วยลายมือ ต้องผ่านขั้นทำความสะอาดภาพและแก้ข้อความก่อนนำไปใช้ งานส่วนนี้กินแรงคนมากกว่าที่หลายคนคาด และเป็นสาเหตุอันดับต้น ๆ ที่กำหนดเวลาบานปลาย

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

3) การเชื่อมระบบเดิม

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

คำถามที่ควรถามคือ ระบบปลายทางมี API ที่เสถียรหรือยัง ต้องซิงก์ข้อมูลสองทางไหม ถ้าอีกฝั่งล่มกลางทางข้อมูลจะค้างหรือหาย และการทดสอบต้องทำบนสภาพแวดล้อมแบบไหน

4) ระดับความแม่นที่ต้องการ

"พอใช้ได้" กับ "ใช้ตัดสินใจได้" เป็นสองระดับงานที่ต่างกันมาก ระดับแรกอาจยอมให้คนตรวจแก้ก่อนใช้ ระดับหลังต้องมีชุดทดสอบ เกณฑ์ผ่าน และหลักฐานว่าผลลัพธ์ตรวจสอบย้อนกลับได้ทุกครั้ง

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

5) การดูแลหลังส่งมอบ

โมเดล ข้อมูล และพฤติกรรมผู้ใช้เปลี่ยนตลอดเวลา ระบบที่ไม่มีคนดูแลจะเสื่อมคุณภาพอย่างเงียบ ๆ โดยไม่มีใครรู้ว่าจุดไหนเริ่มเพี้ยน งานดูแลจึงควรถูกคิดเป็นรายการแยก ตั้งแต่การเฝ้าดูระบบ การเก็บ log การอัปเดตฐานความรู้ ไปจนถึงรอบปรับปรุงตามข้อผิดพลาดที่พบจริง

ช่วงงานกับสิ่งที่ต้องตัดสินใจ

การแบ่งงานเป็นช่วงช่วยให้เห็นว่างบประมาณผูกกับอะไร และช่วยให้หยุดได้ในจังหวะที่สมมติฐานไม่เป็นจริง

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

วิธีประเมินผู้รับงาน 5 ข้อ

1. ถามถึงกระบวนการ ไม่ใช่แค่ผลงานที่โชว์ ขอดูว่าทีมจะเริ่มจากสำรวจข้อมูลอย่างไร และจะรายงานสิ่งที่ทำไม่ได้เมื่อไร
2. ขอดูวิธีวัดผล ระบบนี้จะถูกตัดสินด้วยชุดทดสอบอะไร ใครสร้าง และเกณฑ์ผ่านคืออะไร
3. ถามเรื่องข้อมูลและ PDPA ข้อมูลจะถูกเก็บที่ไหน ใครเข้าถึงได้ และจะลบเมื่อเลิกสัญญาอย่างไร
4. ถามถึงสิ่งที่ส่งมอบ โค้ด เอกสาร ชุดทดสอบ และสิทธิ์ในบัญชีคลาวด์เป็นของใครหลังจบงาน
5. ถามความเห็นตรงข้าม ผู้รับงานที่ดีควรบอกได้ว่าส่วนไหนของโจทย์ไม่ควรใช้ AI และควรใช้วิธีอื่นแทน

สัญญาณเตือน 3 ข้อ

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

คำถามที่พบบ่อย

ควรเริ่มโครงการด้วยงบประมาณเท่าไร

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

ใช้เวลานานแค่ไหนกว่าจะใช้งานได้

ขึ้นกับคุณภาพข้อมูลและจำนวนระบบที่ต้องเชื่อม งานที่ข้อมูลสะอาดและมี API พร้อมจะใช้เวลาสั้นกว่างานที่ต้องเก็บเอกสารจากหลายแหล่งมาก ผู้รับงานควรอธิบายได้ว่าอะไรทำให้กำหนดเวลาขยับ

ควรสร้างโมเดลเองหรือใช้บริการสำเร็จรูป

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

ถ้าอยากรู้ว่าโจทย์ของคุณมีปัจจัยใดที่ทำให้งบประมาณขยับ ส่งโจทย์และตัวอย่างเอกสาร (ปกปิดข้อมูลจริงได้) มาคุยกับทีมเราได้ที่หน้า /contact/