AI ไปยังการผลิต ไม่ใช่แค่เพิ่มความเร็วแต่ต้องเพิ่มความไว้ใจ
AI ไปยังการผลิต หมายถึงกระบวนการเปลี่ยนต้นแบบหรือโปรโตไทป์ที่สร้างด้วยโมเดลและเอเจนต์ ให้กลายเป็นระบบซอฟต์แวร์ระดับองค์กรที่ทำงานในสภาพแวดล้อมจริง มีผู้ใช้จำนวนมาก มีข้อกำหนดด้านความปลอดภัย การตรวจสอบย้อนหลัง ข้อมูล provenance และเวิร์กโฟลว์อนุมัติที่ชัดเจน โดยต้องควบคุมความเสี่ยงจากโค้ดที่สร้างอัตโนมัติและบริบทข้อมูลที่อาจล้าสมัยหรือไม่มีที่มา
ประเด็นคืออุตสาหกรรมกำลังกระโดดจากการเติมโค้ดอัตโนมัติไปสู่การพัฒนาแบบกึ่งอัตโนมัติ แต่ความไว้ใจตามไม่ทัน ผู้บรรยายจากบริษัทหนึ่งอธิบายว่าพวกเขาพัฒนาโครงการ Prompt to Prod เพื่อให้เอเจนต์พาโค้ดจากพรอมป์ต์ไปถึงการผลิตโดยไม่ต้องมีมนุษย์แทรกแซง ทว่าเขายอมรับตรงๆ ว่าเราก้าวหน้าเรื่องการพิมพ์โค้ด แต่ยังไม่เก่งเรื่องการย่อยและตรวจสอบ ทำให้วิศวกรต้องรับแรงกดดันและหนี้เทคนิคสะสม
ในอีกด้าน ทีมหนึ่งใช้คนเพียง 5 คนพาโปรโตไทป์สุดสัปดาห์ไปเป็นผลิตภัณฑ์ระดับองค์กรภายในประมาณ 5 เดือน ด้วยผลงานต่อวิศวกรสูงกว่าการพัฒนาแบบเดิมราว 5 เท่า นี่พิสูจน์ว่าการพัฒนา AI ไปยังการผลิตทำได้ แต่ต้องมีวิธีทำงานที่ต่างจากการลองของในห้องทดลอง
โปรโตไทป์ AI ที่ไม่มี sandbox และความรู้สถาบัน คือระเบิดเวลาความปลอดภัย
โปรโตไทป์ส่วนใหญ่เน้นให้ของทำงาน ไม่ได้ออกแบบให้ปลอดภัย เมื่อเอเจนต์เริ่มแตะระบบจริง ความเสี่ยงจึงพุ่งสูง ผู้บรรยายรายหนึ่งถามตรงๆ ว่าใครรันเอเจนต์ใน sandbox บ้าง และเตือนว่าถ้าไม่ทำ คุณกำลังรับความเสี่ยงจำนวนมาก เพราะเมื่อเอเจนต์เข้าถึงระบบไฟล์ เครือข่าย และซีเคร็ตโดยตรง สิ่งที่เอเจนต์ทำผิดเพียงครั้งเดียวอาจกลายเป็นเหตุการณ์ด้านความปลอดภัยที่ต้องปลุกคนขึ้นมาดูแลกลางดึก
องค์กรที่คิดจะทำ AI ไปยังการผลิตอย่างจริงจังจึงต้องเพิ่มชั้นป้องกัน เช่น การ sandbox เอเจนต์ การจำกัดสิทธิ์ การหลีกเลี่ยงซีเคร็ตระยะยาว และการแยกตัวตนเอเจนต์ออกจากมนุษย์บนระบบตรวจสอบ นี่ไม่ใช่ความระแวงเกินเหตุ แต่เป็นข้อจำเป็นเมื่อคุณเริ่มปล่อยเอเจนต์ให้แตะเวิร์กโฟลว์จริง
อีกจุดอ่อนที่โปรโตไทป์มองข้ามคือความรู้สถาบัน ความเชี่ยวชาญขององค์กรไม่ได้นอนอยู่ในเอกสารสวยๆ แต่ซ่อนอยู่ในโค้ดรีวิวและข้อคิดเห็นสะสมเป็นแสนรายการ วิศวกรกลุ่มหนึ่งจึงดึงข้อมูลจากรีวิวกว่า 700,000 PR ในรอบ 3 ปี ที่เฉลี่ยแล้วมีคอมเมนต์รีวิวประมาณ 1.75 รายการต่อ PR เพื่อนำมาคลัสเตอร์เป็นกฎตัวอย่างหรือ exemplar ที่สะท้อนความรู้สถาบันของทีม ถ้าไม่ดึงความรู้เหล่านี้ออกมา AI จะเขียนโค้ดได้ แต่จะไม่รู้ว่าบริษัทคุณถืออะไรเป็นกติกาทอง
ข้อมูล provenance ที่หายไปกับการ ingest คือสาเหตุหลักที่ RAG พัง
ระบบ retrieval ในองค์กรจำนวนมากแปลงเอกสารเป็นข้อความยาว แตกเป็นชิ้น สร้าง embedding แล้วทิ้งทุกอย่างที่เหลือ ผลคือข้อมูล provenance หายเกลี้ยง ทั้งผู้เขียน เวอร์ชัน สถานะ และวันที่แก้ไขล่าสุด เมื่อข้อมูลเดินทางไปถึงฐานเวกเตอร์แล้ว จึงไม่เหลือเบาะแสว่าคำตอบมาจากนโยบายฉบับไหนและยังใหม่พอหรือไม่
กรณีศึกษาหนึ่งเล่าว่าพนักงานถามสิทธิ์ลาคลอด ระบบตอบตัวเลขชัดเจน มีเอกสารอ้างอิงจริง แต่ตัวเลขมาจากนโยบายปี 2021 ที่ถูกแก้สองครั้งภายหลัง และไม่มีใครรู้เป็นเวลาถึงสามสัปดาห์ เมื่อตรวจสอบย้อนหลังจึงพบว่าช่วง ingest ได้ทิ้งข้อมูลวันแก้ไขไว้ตั้งแต่ขั้นตอนแรก และทิ้งซ้ำอีกครั้งตอนเขียนลงฐานข้อมูล มีเพียงเนื้อหากับ embedding เท่านั้นที่รอด
คำเตือนที่ควรจำคือ ถ้าข้อมูลสำคัญ เช่น วันที่หรือเวอร์ชัน ไม่อยู่ในชิ้นข้อมูลตั้งแต่ต้น ต่อให้ใช้ embedding ดีแค่ไหนก็ช่วยไม่ได้ คุณกำลังเพิ่มประสิทธิภาพการค้นหาเหนือคลังที่ไม่มีคำตอบตั้งแต่แรก ทีมที่จริงจังกับความปลอดภัย AI ระบบ จึงต้องออกแบบสคีมาข้อมูลให้พก provenance ติดตัวเสมอ ไม่ว่าจะเป็นเวอร์ชันเอกสาร ผู้เขียน เส้นทางไฟล์ หรือสถานะการอนุมัติ
ทำไม “ให้ AI เขียน PRD” ถึงกลายเป็นเอกสารสวยแต่โกหก และวิธีคอมไพล์ข้อกำหนดแบบองค์กร
หลายทีมหวังให้โมเดลเขียน PRD ให้จบในครั้งเดียว ผลลัพธ์มักเป็นเอกสารที่หัวข้อครบ น้ำเสียงมืออาชีพ แต่เต็มไปด้วยตัวเลขและกฎที่ไม่มีที่มา ผู้เขียนคนหนึ่งจึงสรุปแรงว่า PRD ที่ให้โมเดลเขียนมักกลายเป็น “คำโกหกที่สวยงาม” เพราะทุกประโยคดูสมบูรณ์ แต่ไม่มีใครบอกได้ว่ามาจากสัมภาษณ์ เอกสารเก่า หรือถูกแต่งขึ้นเพื่อให้เนื้อเรื่องลื่นไหล
ทางออกไม่ใช่การหาพรอมป์ต์วิเศษ แต่คือเลิกปฏิบัติต่อร่าง PRD เป็นระบบอ้างอิงหลัก แล้วหันมาสร้างระบบข้อกำหนดที่ทำงานเหมือนคอมไพเลอร์ ตั้งแต่รับคำขอและหลักฐาน แปลงเป็น claim แบบ typed ตรวจหาความขัดแย้ง ผูกกับแบบจำลองโดเมน ไปจนถึงสร้างซอฟต์แวร์ย่อย เช่น การเปลี่ยน API การจัดประเภทข้อมูล การปรับสิทธิ์ การทดสอบรับงาน และเมทริกซ์การตามรอย
หัวใจคือกราฟข้อกำหนดที่มีเวอร์ชันและแหล่งหลักฐานชัดเจน ระบบกำหนดจะใช้โมเดลช่วยดึง claim แต่ใช้โค้ดกำหนดตรวจฟิลด์ที่จำเป็น ความสัมพันธ์ที่อนุญาต การอ้างอิงหลักฐาน เจ้าของ และเวอร์ชัน นี่คือการสร้างข้อมูล provenance สำหรับข้อกำหนดเอง เพื่อให้เมื่อ AI ไปยังการผลิต ทีมจะรู้เสมอว่ากฎแต่ละข้อเกิดจากอะไรและเปลี่ยนเมื่อไร ลดโอกาสให้เอเจนต์สร้างข้อกำหนดขัดแย้งกันโดยไม่มีใครสังเกต
บทเรียนจากโปรโตไทป์สู่สเกลองค์กร: ความท้าทายการปรับขนาด คือบริบทมนุษย์ไม่ใช่ความเร็วของโค้ด
เคสทีมที่พาโปรโตไทป์สุดสัปดาห์ไปเป็นผลิตภัณฑ์ระดับองค์กรภายในประมาณ 5 เดือน ด้วยผลงานต่อวิศวกรราว 5 เท่า แสดงให้เห็นว่าการพึ่งเอเจนต์หลายตัวสามารถเพิ่มผลผลิตได้มหาศาล พวกเขาเริ่มจาก PRD ระดับสูง สร้างเอเจนต์วางแผน เอเจนต์เขียนโค้ด เอเจนต์รีวิว และมนุษย์คอยตัดสินเมื่อเอเจนต์ขัดแย้งกัน
แต่เมื่อกระโจนสู่การผลิตแบบเต็มที่ ทีมพบว่าไม่มีสถาปัตยกรรมให้ยึด ไม่มีความเห็นร่วมว่าระบบควรหน้าตาอย่างไร โค้ดจึงซับซ้อนขึ้น เอเจนต์เชื่อมโดเมนแปลกๆ และเกิด dependency วนซ้ำเรื่อยๆ เมื่อผสานกับบทเรียนจากอีกองค์กรหนึ่งที่ชี้ว่าถ้าเพิ่มความเร็วของความเป็นอัตโนมัติโดยไม่ใส่ใจความปลอดภัย ก็เท่ากับสร้างหนี้เทคนิคที่ไม่มีคนเข้าใจในโค้ด ภาพชัดเจนคือความท้าทายการปรับขนาดไม่ได้อยู่ที่โมเดล แต่อยู่ที่โครงสร้างงาน
แนวโน้มต่อไปคือการออกแบบวงจรพัฒนาซอฟต์แวร์อัตโนมัติให้มีตัวป้องกันชัดเจน ทั้ง sandbox การรีวิวโค้ด การตรวจวัดผลผลิตรูปแบบใหม่ และการยืนยันว่ามนุษย์ยังเป็นคนตัดสินในจุดสำคัญ ทีมหนึ่งสรุปว่า “เราพบว่ารูปแบบที่ดีที่สุดคือให้มนุษย์ยังเป็นคนตัดสิน” และสิ่งนี้คือเส้นแบ่งระหว่างโปรโตไทป์ที่ดูฉลาดกับระบบองค์กรที่อยู่รอดในระยะยาว
