วิธีทำ AI Pilot: ขั้นตอนทดลองก่อนลงทุน

ทำไมต้องเป็นไพลอต ไม่ใช่การซื้อ

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

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

ขั้นตอน 1: เลือกงานเดียว ไม่ใช่ทั้งแผนก

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

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

ขั้นตอน 2: เก็บตัวอย่างจริง 20 ถึง 50 ตัวอย่าง

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

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

ขั้นตอน 3: เขียนมาตรฐานการผ่าน ก่อนเห็นผลลัพธ์ใดๆ

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

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

ขั้นตอน 4: ทดสอบคู่กับวิธีเดิม

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

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

ขั้นตอน 5: ทวนความผิดพลาดกับพนักงานที่ทำงานนี้

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

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

ขั้นตอน 6: ตัดสินใจ go, no-go หรือแคบลง

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

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

ขั้นตอน 7: ต่อจากนี้ จึงคิดเรื่องเซิร์ฟเวอร์

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

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

ความผิดพลาดที่เราเจอบ่อย

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

จุดเริ่มต้น

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