เรียนรู้จากสาเหตุและกรณีศึกษาความล้มเหลวของ PoC: ออกแบบการนำ AI มาใช้ด้วย Specification-Driven Development (SDD) และ Acceptance Test-Driven Development (ATDD)

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

บทความนี้จัดทำขึ้นสำหรับผู้รับผิดชอบการวางแผน PoC ของการนำ AI มาใช้งานและผู้จัดการโครงการ โดยจะสรุปรูปแบบของกรณีความล้มเหลวที่พบบ่อย พร้อมทั้งอธิบายวิธีการกำหนดขอบเขตการตรวจสอบไว้ล่วงหน้าด้วย Specification-Driven Development (SDD) และการเปลี่ยนเกณฑ์การตัดสินให้เป็นแบบทดสอบก่อนเริ่มงานด้วย Acceptance Test-Driven Development (ATDD) ในตอนท้ายจะมีรายการตรวจสอบ (Checklist) และตารางการตัดสินใจที่ควรตรวจสอบก่อนเริ่มดำเนินการให้ด้วย

การทำ PoC สำหรับการพัฒนาระบบแบบดั้งเดิมมักจบลงเพียงแค่การยืนยันว่า "สามารถสร้างได้หรือไม่" และการที่หน้าจอทำงานได้ก็ถือว่าการตรวจสอบส่วนใหญ่เสร็จสิ้นแล้ว แต่สิ่งที่ต้องยืนยันในการทำ PoC สำหรับ AI คือ "จะเกิดข้อผิดพลาดในรูปแบบใดและในสัดส่วนเท่าใด" หากดำเนินการโดยไม่สะท้อนความแตกต่างนี้ลงในแผนงาน การตัดสินใจจะขึ้นอยู่กับเพียงความประทับใจจากการสาธิต (Demo) เท่านั้น

ใน 3 ส่วนถัดไป เราจะมาดูกันว่าความแตกต่างนี้จะนำไปสู่การมองข้ามประเด็นใดบ้างในขั้นตอนการวางแผน

Generative AI อาจให้คำตอบที่เปลี่ยนไปทั้งในแง่ของถ้อยคำและเนื้อหา แม้จะเป็นคำถามเดิมก็ตาม ดังนั้น การที่ระบบทำงานได้ดีในการสาธิต (Demo) เพียงไม่กี่ครั้ง ไม่ได้หมายความว่าจะทำงานได้ดีในสัดส่วนที่เท่ากันเมื่อใช้งานจริง คำถามที่เลือกมาใช้ในการสาธิตมักเป็นคำถามที่ตอบได้ง่าย

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

วิธีรับมือคือการระบุในแผนงานว่าจะทำการประเมินโดยใช้จำนวนและสัดส่วนที่ชัดเจน เช่น จะเตรียมคำถามประเภทใดไว้กี่ข้อ จะทดสอบคำถามเดิมซ้ำกี่ครั้ง และต้องผ่านเกณฑ์กี่เปอร์เซ็นต์จึงจะดำเนินการในขั้นตอนถัดไป หากกำหนดสิ่งเหล่านี้ไว้ก่อนเริ่มงาน การสาธิตจะไม่ใช่การประเมินผล แต่จะเป็นเวทีสำหรับอธิบายผลลัพธ์การประเมินแทน สำหรับวิธีการสร้างที่ชัดเจนจะกล่าวถึงในบท "การพัฒนาโดยเน้นการทดสอบการยอมรับ" (Acceptance Test-Driven Development: ATDD) ต่อไป

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

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

ในขั้นตอนการวางแผน ให้ระบุรายละเอียดเกี่ยวกับข้อมูลที่ใช้ตรวจสอบ (Validation Data) 3 ประการ ดังนี้: จะนำข้อมูลมาจากไหนจำนวนเท่าใด, มีความเป็นไปได้ที่จะแตกต่างจากคำถามในหน้างานจริงอย่างไร และจะรวมกรณีที่ตอบได้ยากไว้มากน้อยเพียงใด หากไม่ตั้งใจใส่กรณีที่ตอบได้ยากเข้าไป ผลการทดสอบ PoC ก็จะออกมาสูงกว่าความเป็นจริงในหน้างาน นอกจากนี้ ควรคำนวณงบประมาณสำหรับขั้นตอนการดึงข้อมูลและการทำเซ็นเซอร์ข้อมูลส่วนบุคคล (Anonymization) ไว้ตั้งแต่ในขั้นตอนนี้ด้วย

แม้ผลลัพธ์จะออกมาว่า "มีอัตราความถูกต้อง 90%" แต่ก็ไม่ได้เป็นตัวตัดสินว่าจะสามารถนำไปใช้งานจริงได้หรือไม่ เพราะผลกระทบต่อการดำเนินงานนั้นแตกต่างกันอย่างสิ้นเชิง ขึ้นอยู่กับว่าอีก 10% ที่เหลือนั้นเป็นข้อผิดพลาดประเภทใด เราไม่ควรนับคำตอบที่ใช้สำนวนไม่เป็นธรรมชาติ กับคำตอบที่ให้ข้อมูลกฎการคืนเงินที่ไม่มีอยู่จริงว่าเป็นข้อผิดพลาดประเภทเดียวกัน

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

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

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

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

ทั้ง 3 กรณีมีสาเหตุมาจากช่องว่างในขั้นตอนการวางแผน ไม่ใช่ที่การนำไปใช้งานจริง วิธีการ "Specification-Driven Development (SDD)" และ "Acceptance Test-Driven Development (ATDD)" ในบทถัดไป คือแนวทางในการเติมเต็มช่องว่างเหล่านี้ก่อนเริ่มดำเนินการ

Specification-Driven Development (SDD) คือแนวทางการพัฒนาที่เน้นการเขียนเอกสารข้อกำหนด (Specification) ก่อนเริ่มการลงมือเขียนโค้ด โดยให้เอกสารดังกล่าวเป็นจุดเริ่มต้นและเป็นแหล่งอ้างอิงหลัก (Source of Truth) ของการพัฒนา แนวทางนี้กำลังได้รับความสนใจอีกครั้งพร้อมกับการแพร่หลายของ AI ช่วยเขียนโค้ด โดยมีเครื่องมือที่ช่วยสร้างเอกสารข้อกำหนด การออกแบบ และการแบ่งงานก่อนเริ่มลงมือจริงออกมามากมาย เช่น "Spec Kit" ที่เผยแพร่โดย GitHub หรือสภาพแวดล้อมการพัฒนา "Kiro" ของ AWS

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

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

เอกสารข้อกำหนดสำหรับ PoC ไม่จำเป็นต้องละเอียดเท่ากับเอกสารข้อกำหนดสำหรับการพัฒนาจริง อย่างไรก็ตาม ต้องระบุข้อมูลในหัวข้อต่อไปนี้ให้ครบถ้วนก่อนเริ่มดำเนินการ

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

การพัฒนาโดยใช้การทดสอบยอมรับเป็นตัวนำ (Acceptance Test-Driven Development: ATDD) คือวิธีการทำงานที่ฝ่ายธุรกิจ ฝ่ายพัฒนา และฝ่ายทดสอบ ร่วมกันกำหนดเกณฑ์การยอมรับ (Acceptance Criteria) และเขียนออกมาเป็นชุดการทดสอบที่สามารถรันได้จริงก่อนที่จะเริ่มลงมือพัฒนา โดยเกณฑ์ดังกล่าวมักเขียนในรูปแบบ "เงื่อนไขเริ่มต้น-การกระทำ-ผลลัพธ์ที่คาดหวัง" (Given/When/Then) และการพัฒนาจะดำเนินไปโดยมีเป้าหมายเพื่อให้ผ่านการทดสอบเหล่านั้น

ในการทำ PoC ของ AI การทดสอบยอมรับนี้จะอยู่ในรูปแบบของชุดข้อมูลประเมินผล (Evaluation Dataset) และเงื่อนไขการผ่าน (Pass Criteria) โดยการรวบรวมกรณีตัวอย่างว่า "หากมีคำถามแบบนี้เข้ามา ควรตอบกลับอย่างไร" และกำหนดว่าต้องผ่านเงื่อนไขใดบ้างจึงจะถือว่าผ่านเกณฑ์ วิธีนี้จะช่วยให้เมื่อจบช่วง PoC เราสามารถตัดสินผลลัพธ์ได้จาก "จำนวนที่ผ่านจากทั้งหมดกี่รายการ" แทนที่จะใช้ความรู้สึกว่า "ดูเหมือนจะไปได้สวย"

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

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

ทางฝ่ายปฏิบัติการควรเลือกกรณีจากคำถามจริง และเขียนคำตอบที่ถูกต้องหรือเงื่อนไขที่ต้องทำให้สำเร็จ เนื่องจากคำตอบของ AI จะมีการเปลี่ยนสำนวนไปทุกครั้ง จึงไม่ใช้การตรวจสอบแบบตรงตัว (Exact Match) แต่จะตัดสินด้วยเงื่อนไข เช่น "ขั้นตอนถูกต้อง" หรือ "ไม่ได้ระบุจำนวนเงินที่แน่ชัด" เป็นต้น สำหรับคำถามที่ไม่ควรตอบและคำถามที่ไม่มีหลักฐานอ้างอิง ควรจัดเตรียมให้พร้อมก่อนคำถามที่พบบ่อย เนื่องจากเป็นสิ่งที่มักถูกมองข้ามในช่วง PoC และมักจะกลายเป็นปัญหาในการใช้งานจริง

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

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

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

ในการทำ PoC ของ AI เราจำเป็นต้องปรับเปลี่ยน Prompt, เอกสารอ้างอิง และโมเดลอยู่หลายครั้ง หากให้คนมาคอยตรวจสอบทุกกรณีในทุกครั้งที่มีการเปลี่ยนแปลง การประเมินผลย่อมทำได้ไม่ทันท่วงที ดังนั้น การทดสอบการยอมรับ (Acceptance Test) จึงควรจัดทำให้อยู่ในรูปแบบที่สามารถรันซ้ำโดยอัตโนมัติด้วยชุดข้อมูลประเมินผลชุดเดิมได้ทุกครั้งที่มีการเปลี่ยนแปลง

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

ผลการประเมินควรถูกบันทึกไว้พร้อมกับรายละเอียดของการเปลี่ยนแปลง หากมีการเก็บข้อมูลไว้ว่า "การเปลี่ยนแปลงใดทำให้เปอร์เซ็นต์ความสำเร็จเพิ่มขึ้นกี่รายการ และกรณีใดบ้างที่กลายเป็นไม่ผ่าน" เมื่อจบขั้นตอน PoC เราจะสามารถอธิบายได้ว่าสิ่งใดที่ได้ผล และสามารถใช้การตั้งค่าเดิมในการใช้งานจริงได้หรือไม่ บันทึกนี้ยังถือเป็นรากฐานสำหรับการทำ Regression Test หลังจากก้าวเข้าสู่ขั้นตอนการพัฒนาจริงต่อไปอีกด้วย

ตารางต่อไปนี้สรุปเนื้อหาที่ผ่านมาเป็นรายการที่ควรตรวจสอบก่อนเริ่มดำเนินการ หากรายการในช่องขวาสุด "สิ่งที่ต้องบันทึกเป็นลายลักษณ์อักษร" ปรากฏอยู่ในเอกสารข้อกำหนด (Specification), เอกสารแผนงาน (Proposal) หรือเอกสารแนบ (Appendix) ถือว่ารายการนั้นได้รับการตรวจสอบแล้ว

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

แม้จะกำหนดเกณฑ์การยอมรับ (Acceptance Criteria) ไว้แล้ว แต่หากไม่มีการกำหนดผู้มีอำนาจตัดสินใจ PoC ก็จะหยุดชะงัก โดยควรแบ่งบทบาทออกเป็นอย่างน้อย 4 ส่วน ได้แก่ ผู้รับผิดชอบฝั่งธุรกิจที่กำหนดเกณฑ์การยอมรับ, ผู้รับผิดชอบฝั่งพัฒนาที่ดำเนินการประเมิน, ผู้รับผิดชอบการประเมินที่รายงานผล และผู้มีอำนาจตัดสินใจที่จะเลือกว่าจะดำเนินการต่อหรือหยุด ทั้งนี้ ผู้มีอำนาจตัดสินใจและผู้รับผิดชอบการประเมินควรเป็นคนละคนกัน เนื่องจากหากผู้ประเมินผลเป็นผู้ตัดสินใจเอง ความต้องการที่จะทำต่ออาจส่งผลต่อความเป็นกลางในการประเมินได้

ระหว่างการดำเนินงาน ควรมีการกำหนดช่วงเวลาเพื่อจัดประชุมทบทวนเป็นระยะ เช่น ทุก 2 สัปดาห์ถึง 1 เดือน โดยให้ผู้มีอำนาจตัดสินใจเข้าร่วมด้วย สิ่งที่ต้องตรวจสอบมี 3 ประการ คือ ผลลัพธ์ล่าสุดของการทดสอบการยอมรับ (Acceptance Test) และความแตกต่างจากรอบก่อนหน้า, ประวัติการเปลี่ยนแปลงข้อกำหนด (Specification) และการตรวจสอบว่ามีงานที่อยู่นอกขอบเขตปะปนเข้ามาหรือไม่ หากการทดสอบการยอมรับเป็นแบบอัตโนมัติ การประชุมทบทวนจะสามารถใช้เวลาไปกับการตัดสินใจก้าวต่อไปแทนที่จะเป็นการอธิบายผลลัพธ์เพียงอย่างเดียว

การตัดสินใจไม่ได้มีเพียงแค่ "สำเร็จ" หรือ "ล้มเหลว" เท่านั้น แต่ให้แบ่งออกเป็น 3 ระดับ โดยเงื่อนไขการตัดสินจะสร้างขึ้นจากเกณฑ์การยอมรับ ดังนี้:

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

คำตอบสำหรับ 3 คำถามที่ผู้รับผิดชอบด้านการวางแผนมักจะสับสน เมื่อนำ Specification-Driven Development และ Acceptance Test-Driven Development มาใช้ใน PoC

แม้จะเริ่มไปแล้ว ก็สามารถแก้ไขสถานการณ์ได้ตามลำดับดังนี้:

1. เขียนสิ่งที่กำลังทำอยู่ให้เป็น "คำถามเพื่อการตรวจสอบ" (Verification Question) เพียง 1 ประโยค เพื่อยืนยันกับผู้มีอำนาจตัดสินใจ
2. เขียนรายการสิ่งที่อยู่นอกเหนือขอบเขต (Out of scope) และหยุดงานที่กำลังทำอยู่ซึ่งเข้าข่ายดังกล่าว
3. รวบรวมข้อมูลสำหรับการประเมินร่วมกับผู้รับผิดชอบฝั่งธุรกิจโดยแบ่งตามประเภทของกรณี (Case) โดยเริ่มจากคำถามที่ไม่ควรตอบและคำถามที่ไม่มีหลักฐานอ้างอิง
4. กำหนดและบันทึกเกณฑ์อัตราการผ่าน (Pass rate) และเกณฑ์ข้อผิดพลาดร้ายแรง (Critical error) ก่อนที่จะดูผลลัพธ์
5. ดำเนินการประเมินด้วยข้อมูลที่มีอยู่กับระบบในปัจจุบัน และหลังจากนี้ให้เปรียบเทียบการเปลี่ยนแปลงทั้งหมดกับผลลัพธ์นี้

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

ปัญหาไม่ได้อยู่ที่ตัวระยะเวลา แต่เป็นเหตุผลที่ทำให้ระยะเวลาต้องยืดออกไปต่างหาก

หากยืดเวลาออกไปเพราะยอมรับคำขอที่อยู่นอกเหนือขอบเขตของข้อกำหนด (Specification) แสดงว่าคุณกำลังก้าวเข้าสู่กับดักของ PoC ที่ไม่มีวันสิ้นสุด แต่หากยืดเวลาออกไปเพื่อประเมินผลใหม่โดยเปลี่ยนเงื่อนไข 1 ประการหลังจากเห็นผลการทดสอบการยอมรับ (Acceptance Test) นั่นถือเป็นการขยายเวลาที่จำเป็นต่อการตัดสินใจ ทั้งนี้ เมื่อมีการขยายเวลา ต้องมีการตกลงและบันทึก 3 ประเด็นร่วมกับผู้ตัดสินใจ ได้แก่ เหตุผลที่ขยายเวลา, วันที่ตัดสินใจหลังขยายเวลา และการยุติโครงการหากผลลัพธ์ยังไม่ถึงเกณฑ์แม้จะขยายเวลาแล้วก็ตาม

คำตอบจะเปลี่ยนไปตามสิ่งที่จะนำกลับมาใช้ใหม่

เอกสารข้อกำหนด (Specification) และชุดข้อมูลสำหรับการประเมิน (Evaluation Dataset) เป็นสิ่งที่คุ้มค่าที่สุดที่จะนำไปใช้ต่อ เอกสารข้อกำหนดจะเป็นจุดเริ่มต้นของข้อกำหนดในการพัฒนาจริง ส่วนชุดข้อมูลสำหรับการประเมินและเกณฑ์การยอมรับ (Acceptance Criteria) จะถูกนำไปใช้ต่อเนื่องในฐานะการทดสอบถดถอย (Regression Test) ในการพัฒนาจริง ทั้งสองอย่างนี้คือผลลัพธ์จาก PoC ที่ควรเก็บรักษาไว้มากที่สุด

วิธีการเตรียม Prompt และเอกสารอ้างอิง รวมถึงการตั้งค่าโมเดล (Model Settings) สามารถนำกลับมาใช้ใหม่ได้หากมีการบันทึกไว้พร้อมกับบันทึกการทดสอบการยอมรับ (Acceptance Test) หากไม่ทราบว่าการตั้งค่าใดให้ผลลัพธ์อย่างไร ก็ไม่มีการรับประกันว่าผลลัพธ์จะเหมือนเดิมในการใช้งานจริง

ในส่วนของโค้ด PoC นั้น ปลอดภัยกว่าหากคิดบนสมมติฐานว่าจะต้องเขียนขึ้นใหม่ทั้งหมด เนื่องจาก PoC มักถูกสร้างขึ้นโดยให้ความสำคัญกับความรวดเร็วในการตรวจสอบ จึงมักละเลยโครงสร้างที่จำเป็นสำหรับการใช้งานจริง เช่น การยืนยันตัวตน (Authentication), สิทธิ์การเข้าถึง (Authorization), การจัดการเมื่อเกิดข้อผิดพลาด (Error Handling) และการตรวจสอบระบบ (Monitoring) หากจะนำกลับมาใช้ใหม่ ควรตรวจสอบส่วนที่ขาดหายไปโดยเทียบกับเอกสารข้อกำหนดของการพัฒนาจริงเสียก่อน

สาเหตุที่ PoC ของ AI มักจบลงโดยไม่ได้ข้อสรุป เป็นเพราะไม่ได้จัดการกับคุณสมบัติเฉพาะของ AI ตั้งแต่ขั้นตอนการวางแผน ได้แก่ ผลลัพธ์ที่ไม่คงที่, ประสิทธิภาพที่ขึ้นอยู่กับข้อมูล และความแม่นยำเพียงอย่างเดียวไม่สามารถตัดสินความพร้อมในการใช้งานจริงได้ การกำหนดขอบเขตที่ต้องตรวจสอบลงในเอกสารด้วย Specification-Driven Development (SDD) และการสร้างเกณฑ์การตัดสินผ่านชุดข้อมูลประเมิน (Evaluation Dataset) และเกณฑ์การผ่านด้วย Acceptance Test-Driven Development (ATDD) ก่อนเริ่มงาน จะช่วยให้เมื่อสิ้นสุด PoC คุณสามารถตัดสินได้ว่า "ผ่านกี่รายการจากทั้งหมดกี่รายการ"

ก่อนอื่น โปรดตรวจสอบแผนงาน PoC ที่อยู่ในมือว่ามี 4 หัวข้อนี้ครบถ้วนหรือไม่ ได้แก่ คำถามสำหรับการตรวจสอบ (Verification Questions), ขอบเขตที่ไม่ครอบคลุม (Out of Scope), ชุดข้อมูลประเมินที่รวมคำถามที่ไม่ควรตอบ (Evaluation Data including questions that should not be answered) และเกณฑ์สำหรับข้อผิดพลาดร้ายแรง (Criteria for Critical Errors) หากหัวข้อใดว่างอยู่ นั่นคือส่วนที่คุณต้องเริ่มเติมให้เต็มเป็นอันดับแรก