บทที่ 69: เวอร์ชัน ประวัติ การตรวจย้อนหลัง และการเก็บรักษา

สถานการณ์ใกล้ตัว

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

AI เลือกฉบับที่อยู่บนสุดของรายการ ทีมจึงตอบตามกติกาเก่า เมื่อเจ้าของถามว่าข้อความมาจากไหน ทุกคนรู้เพียงว่า “ระบบสรุปให้” ไม่มีใครตามกลับไปถึงต้นทางหรือรู้ว่าเหตุใดกติกาจึงเปลี่ยน

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

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

ผลลัพธ์ของบทนี้

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

คำใหม่ในบทนี้:

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

ภาพเปรียบเทียบและขอบเขตของภาพ

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

บัตรประวัติผลงานทำหน้าที่คล้ายกัน

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

แก่นของเรื่องแบบเป็นชั้น

ชั้นที่ 1: ทำให้ผลงานตามกลับไปถึงต้นทางได้

สำหรับผลงานหนึ่งชิ้น ให้บันทึกอย่างน้อย:

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

สายที่มาไม่จำเป็นต้องเก็บเนื้อหาทุกคำซ้ำกัน หากการเก็บนั้นไม่จำเป็น ให้เก็บตัวระบุ อธิบายการเปลี่ยน และหลักฐานเท่าที่นโยบายอนุญาต

ชั้นที่ 2: เวอร์ชันต้องบอกความหมาย ไม่ใช่แค่เลข

ชื่อ final-v7-new-really-final ไม่ช่วยให้คนรู้ว่าสิ่งใดเปลี่ยน บัตรเวอร์ชันควรมี:

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

เลขเวอร์ชันเป็นเพียงป้าย ความหมายอยู่ที่ประวัติและสถานะ

ชั้นที่ 3: แยก “บันทึกว่าเปลี่ยน” ออกจาก “พิสูจน์ว่าถูก”

ประวัติการเปลี่ยนแปลงบอกว่าเกิดอะไรขึ้น แต่ไม่ได้รับรองว่าการเปลี่ยนนั้นถูกต้อง ถ้า AI เขียนบันทึกเองว่า “แก้ครบแล้ว” นั่นยังเป็นข้อกล่าวอ้างของกระบวนการเดียวกัน ต้องมีหลักฐานตรวจ เช่น ชุดทดสอบ ผู้ตรวจมนุษย์ หรือการเทียบกับแหล่งอนุมัติ

ชั้นที่ 4: วางทางถอยก่อนเปิดใช้เวอร์ชันใหม่

การถอยกลับที่ดีตอบได้ว่า:

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

ในภารกิจหนังสือ เราเพียงออกแบบบัตรและจำลองการเลือกเวอร์ชัน ไม่สั่งเปลี่ยนระบบหรือลบไฟล์จริง

ชั้นที่ 5: เขียนกติกาเก็บและลบจากวัตถุประสงค์

แบ่งผลงานเป็นหมวด เช่น

คำขวัญว่า “ไม่มีอะไรถูกลบ” เป็นภาพทางปรัชญา ไม่ใช่ข้อยกเว้นจากความยินยอม นโยบาย ความเป็นส่วนตัว สิทธิ์ลบ หรือหน้าที่ตามกฎหมายของบริบทจริง

ชั้นที่ 6: แยกป้ายความจริงห้าชนิด

หยุดก่อน

ถ้าคุณต้องเก็บไฟล์หนึ่งชิ้นไว้ “เผื่อวันหน้า” คุณตอบได้หรือไม่ว่าวันหน้าหมายถึงเหตุการณ์ใด ใครจะใช้ และเมื่อไรเหตุผลนั้นสิ้นสุด

กรณีศึกษาหรือตัวอย่างจำลองที่ปลอดภัย

“ร้านอุปกรณ์เดินทางเมฆขาว” เป็นธุรกิจสมมติ มีคำตอบมาตรฐานเรื่องการคืนสินค้า ทีมสร้างคู่มือจำลองสามเวอร์ชัน:

• เวอร์ชัน A: ร่างแรก อิงกติกาสังเคราะห์ชุดที่ 1
• เวอร์ชัน B: แก้ภาษาหลังผู้ตรวจพบว่าคำหนึ่งกำกวม
• เวอร์ชัน C: รอตรวจ เพราะเพิ่มเงื่อนไขใหม่ที่ยังไม่มีหลักฐานอนุมัติ

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

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

กิจกรรมทดลองอย่างปลอดภัย

ภารกิจ: สร้างบัตรประวัติผลงานและซ้อมถอยหนึ่งครั้ง

สร้างเอกสารสังเคราะห์สั้น ๆ สามเวอร์ชัน แล้วเติม:

จากนั้นสมมติว่าเวอร์ชันล่าสุดมีข้อความผิดหนึ่งจุด แล้วเขียนขั้นตอนถอยบนกระดาษ โดยไม่แตะไฟล์หรือระบบจริง

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

ผลที่คาด: บัตรที่ตามกลับถึงแหล่งได้ รู้สถานะและจุดปลอดภัย พร้อมทางถอยและคำถาม retention ที่ต้องให้เจ้าของตอบ

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

วิธีกู้คืน: เก็บงานไว้ในพื้นที่จำลอง ติดป้าย “ห้ามใช้จริง” ลดเหลือบันทึกโครงสร้าง และส่งคำถามให้เจ้าของข้อมูล/ระบบก่อนกำหนด retention หรือ deletion จริง

ระวังความเข้าใจผิด

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

สามเรื่องที่ควรจำ

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

คำถามชวนคิด

หากพรุ่งนี้มีคนถามว่าเหตุใดคู่มือฉบับปัจจุบันจึงต่างจากเดือนก่อน คุณมีหลักฐานพออธิบายโดยไม่ต้องพึ่งความจำของคนใดคนหนึ่งหรือไม่

สะพานไปบทถัดไป

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