ทำระบบ AI สำหรับธุรกิจ มีค่า⁠ใช้⁠จ่ายอะไรนอกจากค่า​พั⁠ฒ⁠น⁠า

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

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

ทุกขั้นมีรูป⁠แบบใช้ทรัพยากรต่างกัน จึงไม่ควรนำ “จำนวนผู้ใช้ × ราคาเรียก​โ⁠ม⁠เ⁠ด⁠ล​หนึ่งครั้ง” มาเป็นค่า⁠ใช้⁠จ่ายทั้งหมด โดยไม่ดูจำนวนรอบ ขนาดข้อมูล และงานที่ส่ง⁠ต่อให้คน

สูตรสำหรับเตรียมประมาณการอาจเขียนได้ว่า ต้นทุนต่อรอบ = ค่าระบบพื้น⁠ฐาน + ปริมาณงาน × ต้นทุนเฉลี่ยต่อหนึ่งงาน + งานดูแลและตรวจ⁠ทาน โดยต้องระบุให้ชัดว่าปริมาณงานนับจากอะไร และรวมงานที่ล้มเหลวหรือลองใหม่ไว้ตรงไหน

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

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

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

ช่วงงานหนาแน่น: มีคำ⁠ขอพร้อมกันมาก⁠ขึ้น ต้องดูทั้งยอดค่า⁠ใช้⁠งาน ข้อจำกัดความจุ และเวลารอ การเฉลี่ยทั้งเดือนอาจซ่อนช่วงที่บริการรองรับไม่ทัน

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

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

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

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

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

ขอให้ระบุว่าราคารวมอะไร อะไรเป็นบริการภายนอก ใครเป็นเจ้าของบัญชี และประมาณการตั้งอยู่บนปริมาณงานแบบไหน หากมีวงเงินหรือปริมาณรวมใน​แ⁠พ็⁠ก⁠เ⁠ก⁠จ ต้องรู้ว่าถ้าเกินแล้วเกิดอะไรขึ้นและใครเป็นผู้⁠อนุ⁠มัติการใช้เพิ่ม

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

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

หากต้นทุนยังประเมินยากเพราะไม่ชัดว่า AI ต้องทำอะไร เริ่มจาก การเลือก Chatbot หรือ AI Agent ให้ตรงงาน เพื่อกำหนดขอบเขตและภาระตรวจ⁠ทานก่อนตั้งสมมติฐานค่า⁠ใช้⁠งาน