เราเดินทางจากการทดลองบนคลาวด์ครั้งแรก ๆ มาสู่ระบบงานจริงแบบ “เครื่องมือปิดบังข้อมูล → เอเจนต์เอไอ → การถอดการปิดบังข้อมูล” ได้อย่างไร จากนั้นจึงสร้างระบบสอบสวนแบบออฟไลน์สำหรับทดสอบ และกำลังเตรียมพร้อมสู่ก้าวถัดไป นั่นคือสภาพแวดล้อมเอไอขององค์กรที่ปลอดภัยอย่าง Fire
แนวคิดหลัก: เอไอไม่ควร “ชี้ตัวผู้กระทำผิด” และไม่ได้มาแทนที่คณะกรรมการ บทบาทที่เป็นประโยชน์ของเอไอคือช่วยให้คณะกรรมการรวบรวมเอกสารที่กระจัดกระจายให้เป็นภาพเดียวได้เร็วขึ้น มองเห็นช่องว่างของข้อมูล ตรวจสอบตรรกะเชิงเหตุและผล และจัดทำร่างการสอบสวนฉบับแรกสำหรับใช้ทำงานต่อ
เราเริ่มทดลองใช้เอไอในการสอบสวนอุบัติการณ์ตั้งแต่ปี 2023 ในตอนนั้นแนวคิดดูค่อนข้างเรียบง่าย คือสร้างเอเจนต์ของเราเอง อัปโหลดระเบียบวิธีการสอบสวนและเอกสารของเหตุการณ์ที่เกิดขึ้นจริงเข้าไป แล้วขอให้มันเรียงลำดับเหตุการณ์ หาจุดขัดแย้งในคำให้การเป็นลายลักษณ์อักษร เสนอสาเหตุและมาตรการ
ในปี 2024 ความสามารถของโมเดลขยายตัวขึ้นอย่างเห็นได้ชัด โมเดลเริ่มทำงานได้อย่างมั่นใจไม่เพียงกับข้อความ แต่รวมถึงภาพด้วย การทดลองช่วงแรก ๆ ครั้งหนึ่งไม่ได้เป็นการสอบสวนเต็มรูปแบบเลยด้วยซ้ำ ที่ไซต์งานห่างไกลแห่งหนึ่ง พนักงานหญิงคนหนึ่งหกล้มและได้รับบาดเจ็บที่ขา มีการถ่ายภาพเอกซเรย์ในพื้นที่ แต่ไม่มีผู้เชี่ยวชาญที่จะอ่านผลได้ทันที เราจึงอัปโหลดภาพเอกซเรย์เข้าไปในเอไอ และโมเดลชี้ไปยังบริเวณที่มีลักษณะคล้ายกระดูกฝ่าเท้าชิ้นที่ห้าหัก
ผมขอเน้นย้ำว่า นี่ไม่ใช่การวินิจฉัยทางการแพทย์ และไม่ควรเป็นเช่นนั้น การประเมินภาพทางการแพทย์ขั้นสุดท้ายเป็นหน้าที่ของแพทย์ แต่สำหรับเรา เหตุการณ์ครั้งนั้นเป็นสัญญาณทางเทคนิคที่สำคัญ ว่าโมเดลสามารถสังเกตเห็นรายละเอียดในภาพที่คนซึ่งไม่ใช่ผู้เชี่ยวชาญอาจมองข้ามไป นั่นหมายความว่าในการสอบสวน โมเดลมีศักยภาพที่จะทำงานได้ไม่เพียงกับข้อความ แต่รวมถึงแผนผัง ภาพถ่าย และเอกสารอื่น ๆ ด้วย

เมื่อเอเจนต์แบบกำหนดเองสำหรับผู้ใช้มีความเสถียรมากขึ้น เราก็เริ่มปรับแต่งเอเจนต์ให้สอดคล้องกับระเบียบวิธีขององค์กรโดยตรง เราทำหลายเวอร์ชันบน GPT, Gemini และ Perplexity และในช่วงแรกก็เคยลองใช้ Grok ด้วย เราอัปโหลดระเบียบวิธีเข้าไปในเอเจนต์ ตามด้วยคำให้การ คำบรรยายเหตุการณ์เบื้องต้น เอกสารแต่ละฉบับ และข้อมูลอื่น ๆ
ผลในทางปฏิบัติเห็นได้ทันที เอไอรวบรวมคำให้การได้อย่างรวดเร็ว เสนอลำดับเหตุการณ์ ค้นพบความไม่สอดคล้องกันด้านเวลาและถ้อยคำ และจัดทำรายการคำถามเพิ่มเติม สำหรับคณะกรรมการ เอไอมีประโยชน์ในฐานะ “นักวิเคราะห์คนที่สอง” ที่ไม่รู้จักเหนื่อยกับการอ่านเอกสารซ้ำแล้วซ้ำเล่าหลายสิบหน้า
แต่เวอร์ชันแรกมีจุดบกพร่องที่ชัดเจน นั่นคือในทางปฏิบัติ เรากำลังส่งเอกสารการสอบสวนจริงให้กับบริการภายนอก สำหรับอุบัติการณ์ เรื่องนี้อ่อนไหวเป็นพิเศษ เพราะในเอกสารอาจมีชื่อ-นามสกุล ตำแหน่งงาน ข้อมูลทางการแพทย์ คำให้การ ภาพถ่าย และข้อมูลภายในของสถานประกอบการ
ยิ่งเราใช้เครื่องมือนี้มากเท่าไร ก็ยิ่งเห็นชัดขึ้นว่า ความสะดวกไม่อาจเป็นข้ออ้างในการส่งข้อมูลที่ไม่จำเป็นออกไปภายนอก
ดูภาคผนวกพรอมต์: Prompt 1 — เอเจนต์บนคลาวด์เวอร์ชันที่ปลอดภัย สำหรับทำงานกับเอกสารที่ทำให้ไม่ระบุตัวตนไว้ล่วงหน้าแล้วเท่านั้น

ในขณะเดียวกัน ระเบียบวิธีการสอบสวนภายในขององค์กรเองก็พัฒนาไปด้วย สำหรับผม นี่เป็นประเด็นสำคัญ เราไม่อาจให้สิทธิ์เอไอ “คิดเองว่าจะสอบสวนอย่างไร” ต้องมีระเบียบวิธีก่อน แล้วจึงสร้างเครื่องมือดิจิทัลให้สอดรับกับระเบียบวิธีนั้น
ตามระเบียบวิธีที่ใช้อยู่ในปัจจุบัน เป้าหมายหลักของคณะกรรมการไม่ใช่การหาตัวผู้กระทำผิด แต่คือการพัฒนามาตรการที่มีประสิทธิภาพสูงสุด เพื่อขจัดหรือลดโอกาสที่เหตุการณ์ลักษณะเดียวกันจะเกิดซ้ำ หากในห่วงโซ่เหตุการณ์มีการกระทำของบุคคลเกี่ยวข้อง ก็ต้องวิเคราะห์ลึกลงไปอีกว่า เหตุใดการกระทำนั้นจึงเกิดขึ้นได้หรือถูกมองว่ายอมรับได้
การสอบสวนดำเนินไปตามตรรกะของแนวป้องกัน: แหล่งอันตราย → เหตุการณ์ที่ไม่พึงประสงค์ → ผลที่ตามมา โดยพิจารณาแนวป้องกันเชิงป้องกันเหตุและแนวป้องกันเชิงบรรเทาผลแยกจากกัน ในขั้นวิเคราะห์ข้อมูล จะมีการจัดทำเส้นเวลาลำดับเหตุการณ์และระบุปัจจัยวิกฤต จากนั้นจึงสร้างต้นไม้สาเหตุ ซึ่งต้องนำจากสาเหตุโดยตรงและสาเหตุระดับกลางไปสู่สาเหตุรากเหง้าเชิงระบบ
ในการวิเคราะห์ที่ไม่ซับซ้อน ตรรกะการตั้งคำถาม “ทำไม?” อาจสั้น แต่ในเหตุการณ์ที่ซับซ้อน ตรรกะนี้จะแตกแขนงออกไปจนกลายเป็นต้นไม้สาเหตุที่สมบูรณ์ ตรรกะแนวป้องกันแบบ “โบว์ไท” ช่วยให้ตรวจสอบแยกกันได้ว่า เหตุใดเหตุการณ์จึงเกิดขึ้น และเหตุใดผลที่ตามมาจึงออกมาในลักษณะนั้น
ลำดับขั้นตอนนี้เองที่ต่อมากลายเป็นโครงสร้างหลักของแอปพลิเคชันที่ทำงานภายในเครื่องของเรา
ดู Prompt 2–6: ลำดับเหตุการณ์และปัจจัยวิกฤต → คำถามและข้อขัดแย้ง → แนวป้องกัน → ต้นไม้สาเหตุ → มาตรการ

ขั้นต่อมาปลอดภัยกว่ามาก แม้จะค่อนข้างไม่สะดวก ก่อนอัปโหลดเอกสารเข้าเอเจนต์บนคลาวด์ เราแทนที่นามสกุลและข้อมูลอ่อนไหวอื่น ๆ ด้วยมือ เช่น “พนักงาน 1” “พนักงาน 2” “หัวหน้างาน 1” “หน่วยงาน 1” เป็นต้น
ในแง่การรักษาความลับ นี่ถือเป็นก้าวหน้าแล้ว เอเจนต์มองเห็นตรรกะของอุบัติการณ์ แต่ไม่เห็นชื่อ-นามสกุลจริง เมื่อวิเคราะห์เสร็จ เราต้องเปลี่ยนรหัสแทนเหล่านั้นกลับคืนด้วยมือ ซึ่งมักทำผ่านการค้นหาด้วย Ctrl+F
หากมีผู้เกี่ยวข้องเพียงสองสามคน กระบวนการแบบนี้ยังพอรับได้ แต่เมื่อการสอบสวนมีคำให้การ พยาน เอกสาร และนามสกุลที่ปรากฏซ้ำจำนวนมาก การปิดบังข้อมูลด้วยมือและการกู้คืนย้อนกลับจะกลายเป็นงานอีกชิ้นหนึ่ง และเพิ่มความเสี่ยงที่จะผิดพลาด
เมื่อเรามีทักษะไวบ์โค้ดดิง เราจึงแทนที่งานที่ทำด้วยมือด้วยเครื่องมือปิดบังข้อมูลที่ทำงานภายในเครื่อง ซึ่งผมเคยเขียนถึงไว้ในบทความแรกของซีรีส์นี้ เอกสาร Word จะถูกประมวลผลบนคอมพิวเตอร์และได้รับรหัสแทน ส่วนกุญแจถอดการปิดบังข้อมูลจะถูกบันทึกแยกไว้ต่างหาก กุญแจนี้ป้องกันด้วยรหัสผ่านและจะไม่ถูกส่งให้เอเจนต์
หลังจากนั้น เราสามารถส่งเฉพาะคำให้การและเอกสารอื่น ๆ ที่ปิดบังข้อมูลแล้วเข้าไปในเอไอบนคลาวด์ ผลลัพธ์ที่ได้จะถูกนำกลับมายังคอมพิวเตอร์และกู้คืนข้อมูลภายในเครื่อง ระบบงานนี้เองที่เราใช้งานจริงในปัจจุบัน: เครื่องมือปิดบังข้อมูลในเครื่อง → เอเจนต์สอบสวนที่ปรับแต่งแล้ว → การถอดการปิดบังข้อมูลในเครื่อง ระบบนี้ช่วยให้เราใช้จุดแข็งของโมเดลบนคลาวด์ได้ โดยไม่ต้องส่งชื่อ-นามสกุลต้นฉบับและกุญแจกู้คืนข้อมูลให้โมเดล
แต่ยังเหลือจุดเปราะบางอีกจุดหนึ่ง นั่นคือไฟล์บันทึกเสียง การบันทึกคำให้การและการสัมภาษณ์ด้วยเสียงนั้นสะดวก แต่ก่อนจะวิเคราะห์ได้ต้องแปลงเป็นข้อความก่อน เดิมเราใช้บริการออนไลน์และแอปมือถือแยกต่างหากสำหรับงานนี้ ต่อมาฟังก์ชันถอดเสียงก็มีให้ใช้ในบริการเอไอรายใหญ่โดยตรง ซึ่งสะดวก แต่ไฟล์เสียงต้นฉบับที่มีเสียงของบุคคลยังคงถูกส่งออกไปภายนอกอยู่ดี
ด้วยเหตุนี้ เราจึงสร้างเครื่องมืออีกตัวหนึ่ง คือเครื่องมือถอดเสียงที่ทำงานภายในเครื่อง ซึ่งใช้ Whisper บนคอมพิวเตอร์โดยตรง จากการทดสอบของเรา คุณภาพการถอดเสียงเทียบเคียงได้กับบริการบนคลาวด์ที่เราคุ้นเคย โดยที่ไฟล์เสียงต้นฉบับไม่ออกไปจากคอมพิวเตอร์เลย หลังถอดเสียงในเครื่องแล้ว ก็สามารถนำข้อความไปปิดบังข้อมูล แล้วจึงส่งต่อให้เอเจนต์สอบสวนที่ใช้งานจริงเมื่อจำเป็น
ลำดับการเชื่อมต่อของขั้นนี้: การถอดเสียงในเครื่อง → เครื่องมือปิดบังข้อมูลในเครื่อง → เอเจนต์บนคลาวด์ สำหรับการวิเคราะห์เอกสาร ดู Prompt 1–6


ถึงจุดนี้ ก็เกิดคำถามใหม่ขึ้น หากการถอดเสียง การอ่านเอกสาร และตัวโมเดลทำงานภายในเครื่องได้แล้ว ทำไมไม่รวมทุกอย่างไว้ในระบบที่ปลอดภัยเพียงระบบเดียว นี่คือที่มาของระบบสอบสวนแบบออฟไลน์เชิงทดลอง ระบบนี้พัฒนาเสร็จและใช้งานได้แล้ว แต่ในวันนี้เราตั้งใจถือว่ายังเป็นระบบทดสอบ เรากำลังทดลองกับกรณีศึกษาเพื่อการฝึกอบรมและกรณีที่ทำให้ไม่ระบุตัวตนแล้ว เปรียบเทียบผลลัพธ์กับงานของคณะกรรมการ และมองหาการพัฒนารอบถัดไปที่จะทำให้กระบวนการเร็วขึ้น สะดวกขึ้น และมีเสถียรภาพมากขึ้น
โจทย์คือการสร้างพื้นที่ทำงานเดียวสำหรับคณะกรรมการ ที่สามารถอัปโหลดคู่มือระเบียบวิธี ข้อมูลเบื้องต้น คำให้การ ไฟล์ Word และ PDF ไฟล์บันทึกเสียง ภาพถ่าย และแผนผังได้ ถอดเสียงพูดและอ่านเอกสารภายในเครื่อง ดำเนินการไปตามขั้นตอนของระเบียบวิธี และได้ร่างรายงานฉบับแรกในรูปแบบ Word ที่แก้ไขได้
ฟังดูง่ายก็เพียงเมื่อเขียนเป็นประโยคเดียว ในทางปฏิบัติ เราต้องปรับแก้ซ้ำหลายรอบมาก การรู้จำเสียงพูดภายในเครื่องไม่ได้ทำงานได้ตั้งแต่แรก จากนั้นเรายังต้องจัดการกับไฟล์สแกน PDF ภาพ เอกสารขนาดใหญ่ โมเดลในเครื่อง ลำดับเหตุการณ์ สาเหตุ และเอกสารฉบับสุดท้าย รูปแบบการพัฒนาเหมือนกับโครงการอื่น ๆ ของเรา คือ แก้ไขหนึ่งจุด → รัน → ผลลัพธ์หรือภาพหน้าจอข้อผิดพลาด → รอบถัดไปกับ ChatGPT
ท้ายที่สุด เราได้ระบบที่ทำงานภายในเครื่องพร้อมอินเทอร์เฟซผ่านเบราว์เซอร์ และมีสภาพแวดล้อมเอไอภายในเครื่องเป็นของตัวเอง ระบบนี้ถอดเสียงได้ดีแล้ว อ่านเอกสารที่เตรียมไว้ได้ และจัดทำร่างการสอบสวนที่มีโครงสร้างชัดเจน ตอนนี้ภารกิจของเราไม่ใช่การประกาศว่าเป็น “ผลิตภัณฑ์สำเร็จรูป” แต่เป็นการทดสอบอย่างใจเย็น เปรียบเทียบผลลัพธ์ และปรับปรุงตรรกะการทำงาน หากต้องการใช้โมเดลภายในเครื่องเต็มรูปแบบและประมวลผลข้อมูลปริมาณมากได้รวดเร็ว ควรใช้คอมพิวเตอร์ที่มีประสิทธิภาพสูงพอสมควร
ดู Prompt 8 — มาสเตอร์พรอมต์สำหรับไวบ์โค้ดดิงพื้นที่ทำงานภายในเครื่องของคณะกรรมการ

ในเวอร์ชันออฟไลน์สำหรับทดสอบ วงจรการทำงานทั้งหมดถูกออกแบบโดยยึดระเบียบวิธีเป็นแกนกลาง ไม่ใช่การแชตกับเอไอแบบทั่วไป
ขั้นแรก คณะกรรมการบันทึกข้อมูลเบื้องต้น ได้แก่ เกิดอะไรขึ้น แหล่งอันตราย เหตุการณ์ที่ไม่พึงประสงค์ ผลที่ตามมา ผู้เกี่ยวข้อง และผลการตรวจสถานที่เกิดเหตุ จากนั้นจึงจัดทำแผน ว่ามีคำถามใดที่ต้องหาคำตอบ ต้องสัมภาษณ์ใคร และต้องขอเอกสารและผลการตรวจพิสูจน์ใดบ้าง
ในส่วนเอกสาร สามารถอัปโหลดไฟล์ DOCX และ PDF ที่มีข้อความได้ ไฟล์สแกนและภาพถ่ายสามารถรู้จำข้อความได้ภายในเครื่อง แผนผังและภาพจะถูกจัดเก็บไว้ในแฟ้มการสอบสวน และโมเดลสามารถเสนอคำบรรยายรายละเอียดที่มองเห็นได้ ไฟล์เสียงและวิดีโอถอดความได้ภายในเครื่อง นอกจากนี้ยังบันทึกการสัมภาษณ์ผ่านไมโครโฟนได้โดยตรง แล้วจึงได้บทถอดเสียงออกมา
หลังตรวจสอบเอกสารแล้ว แอปพลิเคชันจะช่วยจัดทำเส้นเวลาลำดับเหตุการณ์ เอไอเสนอเหตุการณ์และข้อความที่ยกมาอ้างอิง แต่การตัดสินใจว่าจะรวมรายการใดไว้เป็นหน้าที่ของคณะกรรมการ ส่วนปัจจัยวิกฤตจะถูกทำเครื่องหมายแยกไว้ต่างหาก
ส่วนถัดไปคือแนวป้องกันและสาเหตุ คณะกรรมการตรวจสอบแนวป้องกันเชิงป้องกันเหตุและเชิงบรรเทาผล และสร้างกิ่งเริ่มต้นสองกิ่ง ได้แก่ เหตุใดเหตุการณ์ที่ไม่พึงประสงค์จึงเกิดขึ้น และเหตุใดจึงเกิดผลที่ตามมาเช่นนั้น สาเหตุที่เอไอเสนอยังคงเป็นเพียงสมมติฐานจนกว่าคณะกรรมการจะยืนยัน
หลังจากระบุสาเหตุแล้ว จึงกำหนดมาตรการ ได้แก่ มาตรการนั้นเกี่ยวข้องกับสาเหตุใด ใครเป็นผู้รับผิดชอบ กำหนดเวลา ผลลัพธ์ใดที่ตรวจสอบได้ จำเป็นต้องมีแนวป้องกันชั่วคราวหรือไม่ และควรขยายมาตรการไปใช้กว้างกว่าพื้นที่เดียวหรือไม่
และหลังจากนั้นเท่านั้น จึงจัดทำร่างรายงาน แอปพลิเคชันสามารถรวบรวมร่างแรกในรูปแบบ Word ตามโครงสร้างของคู่มือระเบียบวิธี โดยรวมลำดับเหตุการณ์ ต้นไม้สาเหตุ แนวป้องกัน ทะเบียนเอกสาร และภาคผนวกไว้ด้วย
ดู Prompt 2 — ลำดับเหตุการณ์; Prompt 3 — ข้อขัดแย้งและข้อมูลที่ขาดหาย; Prompt 4 — แนวป้องกัน; Prompt 5 — ต้นไม้สาเหตุ; Prompt 6 — มาตรการ; Prompt 7 — ร่างรายงานฉบับสุดท้าย

ตรงนี้สำคัญที่จะต้องไม่ประเมินระบบอัตโนมัติสูงเกินจริง เอไออ่านข้อความที่ผ่านการตรวจสอบแล้วทีละส่วน เสนอลำดับเหตุการณ์ คำถาม แนวป้องกัน สมมติฐานของสาเหตุ และทางเลือกของมาตรการ เอไออาจพบข้อขัดแย้งระหว่างคำให้การสองฉบับ หรือสังเกตเห็นว่าลำดับเหตุการณ์ยังขาดช่วงเวลาที่สำคัญ
แต่ข้อความที่ยกมาจากเอกสารยืนยันได้เพียงว่า มีถ้อยคำเหล่านั้นอยู่ในเอกสารจริง ไม่ได้พิสูจน์ว่าคำให้การนั้นเป็นความจริง ข้อความที่ได้จากการรู้จำอาจมีข้อผิดพลาด แผนผังอาจถูกตีความผิด ความสัมพันธ์เชิงเหตุและผลอาจเป็นเพียงสมมติฐาน
ดังนั้น แอปพลิเคชันจึงวางหลักการไว้ว่า เอไอเสนอ คณะกรรมการยอมรับ ปฏิเสธ หรือแก้ไข สาเหตุจะไม่กลายเป็นสาเหตุที่ได้รับการยืนยันโดยอัตโนมัติ โมเดลไม่ได้เป็นผู้กำหนดผู้รับผิดชอบและกำหนดเวลา ร่าง Word เป็นเพียงร่างแรกสำหรับใช้ทำงานต่อ ไม่ใช่เอกสารแบบ “หยิบไปเซ็นได้เลย”
เรื่องนี้สำคัญเป็นพิเศษ เพราะรายงานภายในไม่ได้ใช้แทนเอกสารที่กฎหมายและขั้นตอนที่กำหนดไว้บังคับให้ต้องจัดทำ ความรับผิดชอบต่อการสอบสวนยังคงอยู่ที่คณะกรรมการ
ดู Prompt 9 — การควบคุมคุณภาพ การรักษาความลับ และขอบเขตของระบบอัตโนมัติ ก่อนนำผลลัพธ์ไปใช้
ในงานสอบสวน เรื่องการรักษาความลับไม่อาจปล่อยไว้ “ทำทีหลัง” ตัวระเบียบวิธีเองก็จัดให้เอกสารการสอบสวนภายในเป็นเอกสารสำหรับใช้ภายในองค์กรเท่านั้น และกำหนดไว้โดยเฉพาะให้ต้องคุ้มครองข้อมูลส่วนบุคคลเมื่อสร้างและส่งต่อไฟล์
ในเวอร์ชันออฟไลน์สำหรับทดสอบ เอกสารในแฟ้มการสอบสวน บทถอดเสียง ผลการวิเคราะห์ และไฟล์ Word จะอยู่บนคอมพิวเตอร์เท่านั้น โมเดลภายในเครื่องทำงานผ่านที่อยู่ loopback และหลังจากเตรียมโมเดลที่จำเป็นเรียบร้อยแล้ว ก็สามารถทำงานกับแฟ้มการสอบสวนได้โดยไม่ต้องเชื่อมต่ออินเทอร์เน็ตภายนอก
แต่ตรงนี้ก็ไม่มีเวทมนตร์ การทำงานภายในเครื่องไม่ได้หมายความว่าข้อมูลจะถูกทำให้ไม่ระบุตัวตนโดยอัตโนมัติ หากอัปโหลดชื่อ-นามสกุลและข้อมูลทางการแพทย์เข้าไปในแฟ้มการสอบสวน ข้อมูลเหล่านั้นก็จะอยู่บนคอมพิวเตอร์เครื่องนี้และในภาคผนวกของแฟ้ม ดังนั้นจึงยังต้องมีมาตรการรักษาความปลอดภัยสารสนเทศตามปกติ ได้แก่ บัญชีผู้ใช้ที่มีการป้องกัน สิทธิ์การเข้าถึง กฎการจัดเก็บ การสำรองข้อมูล และหากจำเป็น การปิดบังข้อมูลเพิ่มเติม
กล่าวคือ วิวัฒนาการของเราไม่ได้จบลงด้วยสโลแกน “ทุกอย่างออฟไลน์ แปลว่าทุกอย่างปลอดภัย” ที่ถูกต้องกว่าคือ เราตัดการส่งเอกสารออกไปภายนอกโดยไม่จำเป็น และคงการควบคุมข้อมูลไว้ในที่ที่ควรอยู่ นั่นคือภายในสถานประกอบการ
ทุกวันนี้ เรามีระบบงานสองระบบ ระบบแรกคือระบบที่ใช้งานจริง เราปิดบังข้อมูลในเอกสารภายในเครื่อง ส่งสำเนาที่ทำให้ไม่ระบุตัวตนแล้วเข้าไปในเอเจนต์สอบสวนที่ปรับแต่งไว้ จากนั้นจึงถอดการปิดบังข้อมูลของผลลัพธ์ภายในเครื่อง รูปแบบนี้เองที่สามารถใช้ในงานจริงได้แล้ว
ระบบที่สองคือระบบทดสอบ เป็นระบบออฟไลน์เต็มรูปแบบที่ถอดเสียงจากไฟล์เสียงภายในเครื่องได้เอง อ่านเอกสาร ช่วยสร้างลำดับเหตุการณ์ แนวป้องกัน และสาเหตุ และจัดทำร่างรายงานฉบับแรก ระบบนี้ใช้งานได้แล้ว แต่เรายังคงตรวจสอบและปรับปรุงต่อไป สำหรับเรา นี่เป็นหลักการสำคัญ เราไม่อาจนำเสนอโครงการนำร่องว่าเป็นระบบที่พร้อมใช้งานจริงในการผลิต เพียงเพราะมันดูสวยงาม
ระบบที่ใช้งานจริง: เครื่องมือปิดบังข้อมูล → เอเจนต์เอไอสอบสวนที่ปรับแต่งแล้ว → การถอดการปิดบังข้อมูล
ระบบทดสอบ: พื้นที่ทำงานของคณะกรรมการที่ทำงานภายในเครื่องทั้งหมด → การตรวจสอบและการพัฒนารอบถัดไป
ในขณะเดียวกัน ฝ่ายไอทีของกลุ่มบริษัทกำลังพัฒนาเอไอภายในชื่อ Fire บนสภาพแวดล้อมองค์กร Collab สำหรับเรา นี่คือขั้นต่อไปที่สมเหตุสมผล คือการย้ายตรรกะเชิงระเบียบวิธีของผู้ช่วยคณะกรรมการไปไว้ในสภาพแวดล้อมเซิร์ฟเวอร์ขององค์กรที่ปลอดภัย ซึ่งไม่ต้องเลือกระหว่างพลังของโมเดลขนาดใหญ่กับข้อกำหนดด้านการรักษาความลับ
เราไม่ได้มอง Fire ว่าเป็น “ผู้สอบสวนอัตโนมัติ” แต่เป็นอีกสภาพแวดล้อมหนึ่งสำหรับหลักการเดิม คือ เอกสารยังคงอยู่ภายในโครงสร้างพื้นฐานที่ปลอดภัย เอไอช่วยคณะกรรมการวิเคราะห์ลำดับเหตุการณ์ แนวป้องกัน ข้อขัดแย้ง และสาเหตุ ส่วนการตัดสินใจยังคงเป็นของมนุษย์
ก่อนย้ายระบบ ต้องตรวจสอบความสามารถทางเทคนิคของ Fire ก่อน ได้แก่ การทำงานกับเอกสารและไฟล์เสียง ขนาดของบริบท การแบ่งสิทธิ์การเข้าถึง บันทึกการใช้งาน การจัดเก็บข้อมูล และการส่งออกผลลัพธ์ กล่าวคือ ในที่นี้เราก็เริ่มจากระเบียบวิธีและการคุ้มครองข้อมูลอีกเช่นเคย ไม่ใช่จากความอยากใช้โมเดลใหม่ล่าสุดไม่ว่าจะต้องแลกด้วยอะไรก็ตาม

ในบทความนี้ ผมตั้งใจไม่ใส่ภาพหน้าจอที่คล้ายกันหลายสิบภาพจนเนื้อหาแน่นเกินไป วิดีโอบันทึกหน้าจอความยาวสามนาทีแสดงให้เห็นได้ดีกว่าว่าองค์ประกอบต่าง ๆ เชื่อมโยงกันอย่างไร อะไรที่มนุษย์ทำจริง และอะไรที่โปรแกรมทำ
ภาพหน้าจอจำเป็นเฉพาะในจุดที่ต้องหยุดอธิบายสถาปัตยกรรม ได้แก่ ประเภทของเอกสาร ลำดับเหตุการณ์ สาเหตุ มาตรการ และไฟล์ Word ฉบับสุดท้าย กลไกส่วนที่เหลือดูจากวิดีโอจะดีกว่า ซึ่งอยู่ท้ายบทความ
การสอบสวนอุบัติการณ์ยังคงต้องใช้คน ทั้งการตรวจสถานที่เกิดเหตุ การสัมภาษณ์ผู้เกี่ยวข้อง การขอรับเอกสาร การหารือข้อเท็จจริง และการตัดสินใจ แก่นแท้ของงานคณะกรรมการนั้นทำให้เป็นอัตโนมัติไม่ได้
แต่เราสามารถตัดงานเอกสารที่ซ้ำซากจำเจออกไปได้เป็นส่วนสำคัญ เช่น การพิมพ์ถอดเสียงจากไฟล์เสียง การรวบรวมคำให้การ การค้นหาความไม่สอดคล้องด้านเวลาด้วยมือ การนำข้อความอ้างอิงไปใส่ในลำดับเหตุการณ์ การจัดวางแนวป้องกันเบื้องต้น การจัดทำต้นไม้สาเหตุ การเตรียมร่างรายการมาตรการ และการรวบรวมร่างรายงานฉบับแรก
และสำหรับผม ผลลัพธ์หลักตรงนี้ไม่ใช่การลดจำนวนผู้เชี่ยวชาญ ตรงกันข้าม หากผู้เชี่ยวชาญใช้เวลากับงานเอกสารเชิงกลไกน้อยลง ก็จะมีเวลามากขึ้นสำหรับสิ่งที่เป็นเหตุผลของการสอบสวนตั้งแต่แรก นั่นคือการพูดคุยกับผู้คน การทำงานในพื้นที่จริง การตรวจสอบแนวป้องกัน และการช่วยผู้บริหารไม่ให้เหตุการณ์เกิดซ้ำ
ตลอดหลายปีที่ผ่านมา เส้นทางนี้สะท้อนภาพได้ชัดเจน: เอเจนต์บนคลาวด์แบบเปิด → การปิดบังข้อมูลด้วยมือ → เครื่องมือปิดบังและถอดการปิดบังข้อมูลภายในเครื่อง → การถอดเสียงภายในเครื่อง → ระบบออฟไลน์สำหรับทดสอบ → ก้าวต่อไปสู่ Fire เอไอขององค์กรที่ปลอดภัย
อย่างไรก็ตาม เครื่องมือที่ใช้งานจริงในวันนี้ไม่ใช่เวอร์ชันออฟไลน์เชิงทดลอง แต่เป็นระบบงานที่ผ่านการพิสูจน์แล้วซึ่งมีการปิดบังข้อมูล เอกสารต้นฉบับยังอยู่กับเรา เวอร์ชันที่ไม่ระบุตัวตนเท่านั้นที่ถูกส่งเข้าเอเจนต์ และการกู้คืนข้อมูลทำภายในเครื่อง ส่วนระบบออฟไลน์นั้น ขณะนี้เรากำลังทดสอบและปรับปรุงไปทีละขั้นอย่างต่อเนื่อง
การเปลี่ยนแปลงที่สำคัญที่สุดไม่ได้อยู่ที่เทคนิคด้วยซ้ำ เราเลิกถามเอไอว่า “ใครผิด?” และหันมาถามอีกคำถามหนึ่งแทน: “ข้อมูลใดยังขาดอยู่ แนวป้องกันใดล้มเหลว เหตุใดจึงล้มเหลว และมาตรการใดที่จะลดความเสี่ยงของการเกิดซ้ำได้จริง?”
บทบาทนี้เองที่ทำให้เอไอมีประโยชน์ในการสอบสวน ไม่ใช่ผู้พิพากษาหรือประธานคณะกรรมการ แต่เป็นนักวิเคราะห์คนที่สองที่ทำงานรวดเร็ว และช่วยให้ผู้คนทำงานกับข้อเท็จจริงได้ลึกซึ้งยิ่งขึ้น
ยิ่งโมเดลเก่งขึ้นเท่าไร ก็ยิ่งสำคัญที่จะไม่มอบความคิดของตนเองให้กับโมเดล ปัญญาประดิษฐ์มีประโยชน์เมื่อช่วยเสริมปัญญาธรรมชาติ คือช่วยให้มองเห็นความเชื่อมโยงได้เร็วขึ้น ตรวจสอบสมมติฐาน รวบรวมฉบับร่าง และทำให้มีเวลามากขึ้นสำหรับการพูดคุยกับผู้คนและการทำงานในพื้นที่จริง
ดังนั้น สำหรับผม เส้นทางที่ถูกต้องคือการไม่เป็นเพียงผู้ใช้ปุ่มสำเร็จรูป แต่เป็นผู้สร้างทางออกใหม่ ๆ ทำความเข้าใจระเบียบวิธี กำหนดสถาปัตยกรรม ตรวจสอบผลลัพธ์ แก้ไขข้อผิดพลาด และเติบโตแข็งแกร่งขึ้นไปพร้อมกับเครื่องมือ
เราต้องใช้เอไอ แต่ก็ต้องใช้และพัฒนาปัญญาธรรมชาติของตนเองไม่น้อยไปกว่ากัน และหากการผสานกันนี้ช่วยให้สอบสวนเหตุการณ์ได้ลึกซึ้งขึ้น เรียนรู้จากเหตุการณ์ได้ดีขึ้น และป้องกันไม่ให้เกิดซ้ำ ก็หมายความว่าเทคโนโลยีกำลังทำงานเพื่อประโยชน์ของความปลอดภัยอย่างแท้จริง
ระบบงานจริงที่มีการปิดบังข้อมูล → ระบบออฟไลน์สำหรับทดสอบ → ก้าวต่อไปสู่ Fire เอไอขององค์กรที่ปลอดภัย
สถานะปัจจุบัน: ในงานจริงใช้ระบบ “เครื่องมือปิดบังข้อมูลภายในเครื่อง → เอเจนต์บนคลาวด์ที่ปรับแต่งแล้ว → การถอดการปิดบังข้อมูลภายในเครื่อง” ระบบออฟไลน์เต็มรูปแบบพัฒนาเสร็จแล้ว แต่ยังอยู่ในขั้นทดสอบและปรับปรุง ส่วน Fire ถูกมองว่าเป็นขั้นต่อไปในระดับองค์กรที่ปลอดภัย
ความเชื่อมโยงกับบทความ: หัวข้อ “เวอร์ชันที่สาม” และ “สิ่งที่เราใช้อยู่ในวันนี้” นี่คือระบบงานที่ใช้งานจริงหลังจากปิดบังข้อมูลภายในเครื่องแล้ว
คุณคือผู้ช่วยวิเคราะห์ของคณะกรรมการสอบสวนภายในสำหรับอุบัติการณ์ด้านอาชีวอนามัยและความปลอดภัยในงานอุตสาหกรรม
ระบบการทำงาน:
เอกสารต้นฉบับจะถูกปิดบังข้อมูลภายในเครื่องก่อน คุณจะได้รับเฉพาะสำเนาที่ทำให้ไม่ระบุตัวตนแล้วเท่านั้น หลังจากคุณทำงานเสร็จ ผลลัพธ์จะถูกถอดการปิดบังข้อมูลภายในเครื่องด้วยกุญแจและรหัสผ่านแยกต่างหาก ซึ่งคุณไม่มี
สิ่งสำคัญ:
- ทำงานกับเอกสารที่ทำให้ไม่ระบุตัวตนไว้ล่วงหน้าแล้วเท่านั้น
- อย่าพยายามกู้คืนชื่อ-นามสกุล หน่วยงาน ที่อยู่ หรือค่าอื่นที่ถูกซ่อนไว้
- อย่าใช้อินเทอร์เน็ตหรือข้อเท็จจริงภายนอก เว้นแต่จะได้รับมาให้โดยเฉพาะ
- อย่าระบุตัวผู้กระทำผิด
- อย่าเรียกสมมติฐานว่าเป็นข้อเท็จจริงที่พิสูจน์แล้ว
- อย่าตัดสินใจแทนคณะกรรมการ
เป้าหมาย: ช่วยคณะกรรมการจัดโครงสร้างเอกสาร และตรวจสอบความครบถ้วนของการสอบสวน
สำหรับข้อสรุปแต่ละข้อ ให้แยกประเภทดังนี้:
FACT — ยืนยันได้โดยตรงจากเอกสาร
ASSUMPTION — ข้อสันนิษฐานที่มีเหตุผลรองรับ
CONFLICT — ข้อขัดแย้งระหว่างเอกสาร
GAP — ข้อมูลที่ขาดหายไป
QUESTION — คำถามที่ต้องหาคำตอบให้ได้
HYPOTHESIS — สาเหตุที่เป็นไปได้ซึ่งต้องได้รับการยืนยัน
ลำดับการทำงาน:
1. จัดทำทะเบียนเอกสารที่ได้รับ
2. ดึงเฉพาะข้อเท็จจริงที่ยืนยันได้ พร้อมระบุแหล่งที่มา
3. จัดทำลำดับเหตุการณ์เบื้องต้น
4. แสดงข้อขัดแย้งและช่องว่างของข้อมูล
5. จัดทำคำถามเพิ่มเติมสำหรับคณะกรรมการ
6. หลังจากลำดับเหตุการณ์ได้รับการยืนยันแล้ว ให้เสนอการวิเคราะห์แนวป้องกัน
7. กำหนดสาเหตุในรูปของสมมติฐานเท่านั้น จนกว่าคณะกรรมการจะตัดสิน
8. เชื่อมโยงมาตรการกับสาเหตุที่ได้รับการยืนยันแล้วเท่านั้น
ในทุกตาราง ให้ระบุแหล่งที่มา ได้แก่ หมายเลขเอกสาร เอกสาร/ไฟล์ และข้อความอ้างอิงสั้น ๆ หรือตำแหน่งที่แน่นอนซึ่งเป็นฐานของข้อสรุปความเชื่อมโยงกับบทความ: ส่วนที่ว่าด้วยลำดับเหตุการณ์ในเอเจนต์ที่ใช้งานจริงและในระบบออฟไลน์สำหรับทดสอบ
ต่อไปนี้คือข้อความจากเอกสารของอุบัติการณ์ที่ผ่านการตรวจสอบแล้ว
จัดทำ “ร่าง” เส้นเวลาลำดับเหตุการณ์
กฎ:
1. อย่าเพิ่มเหตุการณ์ที่ไม่มีอยู่ในเอกสาร
2. หากเวลาแน่นอน ให้ระบุว่าเป็นเวลาที่แน่นอน
3. หากเวลาเป็นค่าประมาณ ให้กำกับว่า “โดยประมาณ”
4. หากแหล่งข้อมูลสองแห่งระบุเวลาหรือลำดับต่างกัน อย่าเลือกข้อมูลใดข้อมูลหนึ่งไปเงียบ ๆ ให้แสดงเป็น CONFLICT
5. สำหรับแต่ละแถว ให้ระบุ วันที่/เวลา เหตุการณ์หรือสภาพการณ์ แหล่งที่มา สถานะ FACT / ASSUMPTION / CONFLICT และเหตุใดจึงสำคัญ
6. เสนอรายการปัจจัยวิกฤตแยกต่างหาก ได้แก่ เหตุการณ์/สภาพการณ์ที่หากไม่มีแล้ว เหตุการณ์ที่ไม่พึงประสงค์หรือความรุนแรงของผลที่ตามมาน่าจะแตกต่างออกไป
7. ไม่ถือว่าปัจจัยวิกฤตได้รับการรับรองแล้ว จนกว่าคณะกรรมการจะตัดสิน
ในตอนท้าย ให้ส่งผลลัพธ์ดังนี้:
A. ร่างลำดับเหตุการณ์
B. รายการข้อขัดแย้ง
C. รายการข้อมูลที่ขาดหาย
D. ร่างปัจจัยวิกฤตสำหรับให้คณะกรรมการพิจารณาความเชื่อมโยงกับบทความ: ส่วนที่ว่าด้วยการวางแผน การรวบรวมเอกสาร และบทบาทของเอไอในฐานะนักวิเคราะห์คนที่สอง
จากเอกสารและร่างลำดับเหตุการณ์ ให้จัดทำใบงานสำหรับคณะกรรมการ
สิ่งที่ต้องทำ:
1. ค้นหาข้อขัดแย้งระหว่างคำให้การ เอกสาร เวลา และข้อมูลทางเทคนิค
2. อย่าตีความความแตกต่างของถ้อยคำว่าเป็นการโกหก หากไม่มีหลักฐาน
3. สำหรับข้อขัดแย้งแต่ละข้อ ให้ระบุ แหล่งที่มา A แหล่งที่มา B ความแตกต่างอยู่ที่ใดกันแน่ และสิ่งที่ต้องตรวจสอบ
4. จัดทำคำถามสำหรับการสัมภาษณ์เพิ่มเติม
5. คำถามต้องเป็นคำถามปลายเปิดและเป็นกลาง ไม่ชี้นำคำตอบ
6. จัดทำรายการเอกสาร ผลการตรวจวัด ผลการตรวจพิสูจน์ ภาพถ่าย หรือแผนผังที่อาจช่วยเติมช่องว่างของข้อมูลแยกต่างหาก
7. ระบุว่าคำถามใดมีความสำคัญอย่างยิ่งต่อการหาข้อเท็จจริงเกี่ยวกับสถานการณ์ แนวป้องกัน สาเหตุ และความรุนแรงของผลที่ตามมา
อย่าสรุปว่าคำให้การไม่น่าเชื่อถือเพียงเพราะมีข้อขัดแย้งความเชื่อมโยงกับบทความ: ส่วนที่ว่าด้วยตรรกะแนวป้องกันและการต่อยอดไปสู่การวิเคราะห์สาเหตุ
ใช้ลำดับเหตุการณ์และปัจจัยวิกฤตที่คณะกรรมการยืนยันแล้ว
จัดทำ “ร่าง” การวิเคราะห์แนวป้องกัน
1. แหล่งอันตราย
2. เหตุการณ์ที่ไม่พึงประสงค์
3. ผลที่ตามมา
4. แนวป้องกันเชิงป้องกันเหตุ: แนวป้องกันใดควรป้องกันไม่ให้เกิดเหตุการณ์/การสัมผัส มีอยู่จริงหรือไม่ พร้อมใช้งานหรือไม่ ถูกนำมาใช้หรือไม่ ทำงานได้ผลหรือไม่ และแหล่งที่มาที่ยืนยัน
5. แนวป้องกันเชิงบรรเทาผล: แนวป้องกันใดควรป้องกันผลที่ตามมาหรือลดความรุนแรง มีอยู่จริงหรือไม่ ทำงานได้ผลหรือไม่ และแหล่งที่มาที่ยืนยัน
6. สำหรับแนวป้องกันแต่ละรายการที่ไม่มีอยู่หรือไม่มีประสิทธิภาพ ให้ตั้งคำถาม “ทำไม?”
อย่าถือว่าการไม่มีแนวป้องกันเป็นสาเหตุรากเหง้าโดยอัตโนมัติ
อย่าคิดแนวป้องกันขึ้นเองหากไม่มีอยู่ในระเบียบวิธี เอกสาร หรือตรรกะทางเทคโนโลยี เว้นแต่จะกำกับว่า HYPOTHESIS
ผลลัพธ์คือตารางสำหรับให้คณะกรรมการพิจารณา ไม่ใช่ข้อสรุปที่ได้รับการรับรองแล้วความเชื่อมโยงกับบทความ: หัวข้อ “ระเบียบวิธีเข้มงวดขึ้น” และส่วนที่ว่าด้วยสาเหตุ
ข้อมูลนำเข้า:
- ลำดับเหตุการณ์ที่ได้รับการยืนยันแล้ว
- ปัจจัยวิกฤต
- การวิเคราะห์แนวป้องกัน
- มติของคณะกรรมการเกี่ยวกับข้อเท็จจริงที่ได้รับการยืนยันแล้ว
สร้าง “ร่าง” ต้นไม้สาเหตุ
จุดตั้งต้น: “เหตุการณ์ที่ไม่พึงประสงค์ + ผลที่ตามมา”
สองกิ่งแรก:
A. เหตุใดเหตุการณ์ที่ไม่พึงประสงค์จึงเกิดขึ้น?
B. เหตุใดจึงเกิดผลที่ตามมาเช่นนี้ / เหตุใดความรุนแรงจึงอยู่ในระดับนี้?
จากนั้น:
1. สำหรับแต่ละโหนด ให้ถาม “ทำไม?” ซ้ำหลายครั้งเท่าที่จำเป็นจนกว่าจะถึงสาเหตุเชิงระบบ
2. เชื่อมโยงสาเหตุแต่ละข้อกับคำถามแม่ในระดับบน
3. ปัจจัยวิกฤตแต่ละข้อต้องปรากฏในต้นไม้ หรือต้องอธิบายแยกต่างหากว่าเหตุใดจึงถูกตัดออก
4. ห้ามถือว่าการกระทำ/ความผิดพลาดของบุคคลเป็นสาเหตุรากเหง้า ให้วิเคราะห์ต่อว่า เหตุใดการกระทำนั้นจึงเกิดขึ้นได้หรือถูกมองว่ายอมรับได้
5. เสนอสาเหตุรากเหง้าเฉพาะเมื่อสาเหตุนั้นอธิบายจุดบกพร่องที่เฉพาะเจาะจงของกระบวนการ/ระบบ แก้ไขได้ อยู่ในขอบเขตที่สถานประกอบการ/กลุ่มบริษัทควบคุมได้ และทำให้เสนอมาตรการที่เป็นรูปธรรมได้
6. ห้ามใช้ถ้อยคำกว้าง ๆ โดยไม่ขยายความ เช่น “วัฒนธรรมความปลอดภัยต่ำ” “ความประมาทส่วนบุคคล” “การจัดการงานไม่ดี” “การฝึกอบรมบกพร่อง”
สำหรับแต่ละโหนด:
- ถ้อยคำ
- ประเภท: สาเหตุโดยตรง / สาเหตุระดับกลาง / ตัวเลือกสาเหตุรากเหง้า
- แหล่งที่มาที่ยืนยัน
- ปัจจัยวิกฤตที่เกี่ยวข้อง
- สถานะ FACT / HYPOTHESIS / CONFIRMED_BY_COMMISSION
อย่ายืนยันสาเหตุรากเหง้าแทนคณะกรรมการความเชื่อมโยงกับบทความ: ส่วนที่ว่าด้วยมาตรการและการประหยัดเวลาในการจัดทำร่างฉบับแรก
ใช้เฉพาะสาเหตุที่คณะกรรมการมีมติให้รวมไว้ในรายการสำหรับพัฒนามาตรการ
สำหรับแต่ละสาเหตุ ให้เสนอทางเลือกของมาตรการ 2–4 ทาง
สำหรับแต่ละทางเลือก ให้ระบุ:
- ขจัดสาเหตุเฉพาะข้อใด หรือเสริมความแข็งแรงให้แนวป้องกันใด
- ประเภท: ด้านเทคนิค / ด้านการบริหารจัดการ / การฝึกอบรม / การควบคุมกำกับ / อื่น ๆ
- ผลลัพธ์ที่คาดหวังซึ่งตรวจสอบได้
- วิธีตรวจสอบประสิทธิผล
- ขอบเขตการขยายผล: สถานที่เกิดเหตุ / สถานที่ที่มีลักษณะคล้ายกัน / สถานประกอบการ / กลุ่มบริษัท
- จำเป็นต้องมีมาตรการป้องกันชั่วคราวก่อนดำเนินมาตรการถาวรหรือไม่
- ความเสี่ยงข้างเคียงที่อาจเกิดขึ้น
- ต้องใช้ข้อมูลใดบ้างในการกำหนดระยะเวลาและผู้รับผิดชอบ
อย่าใส่ชื่อ-นามสกุลของผู้รับผิดชอบและกำหนดเวลาที่เจาะจง หากคณะกรรมการยังไม่ได้ตัดสิน
อย่าเสนอมาตรการประเภท “จัดการอบรมชี้แจงความปลอดภัยนอกแผน” เป็นทางออกสำเร็จรูปสำหรับทุกกรณี หากมาตรการนั้นไม่ได้ขจัดสาเหตุที่ระบุได้
ระบุแยกต่างหากถึงมาตรการที่เพียงเพิ่มการควบคุม แต่ไม่ได้ขจัดสาเหตุรากเหง้าความเชื่อมโยงกับบทความ: ส่วนที่ว่าด้วยการจัดทำไฟล์ Word และหลักการ “ร่างแรก ไม่ใช่เอกสารสำหรับลงนาม”
จัดทำ “ร่าง” เนื้อหารายงานภายใน โดยอิงเฉพาะองค์ประกอบที่คณะกรรมการรับรองแล้วเท่านั้น
ใช้:
- บัตรข้อมูลอุบัติการณ์
- ลำดับเหตุการณ์ที่ได้รับการยืนยันแล้ว
- รายการปัจจัยวิกฤต
- การวิเคราะห์แนวป้องกันที่ได้รับการรับรองแล้ว
- ต้นไม้สาเหตุฉบับสุดท้าย
- รายการสาเหตุที่ได้รับการรับรองแล้ว
- มาตรการที่ได้รับความเห็นชอบแล้ว
- ทะเบียนเอกสาร
อย่าใส่สมมติฐานที่ยังไม่ได้รับการยืนยัน คำอธิบายเหตุการณ์ที่ยังเป็นที่ถกเถียงโดยไม่มีการกำกับไว้ และข้อสรุปที่ไม่มีแหล่งที่มา ลงในผลสรุปในฐานะข้อเท็จจริง
โครงสร้าง:
1. ข้อมูลโดยย่อและสถานการณ์แวดล้อม
2. เอกสารและวิธีการรวบรวมข้อมูล
3. ลำดับเหตุการณ์
4. ปัจจัยวิกฤต
5. แนวป้องกัน
6. การวิเคราะห์สาเหตุ
7. สาเหตุรากเหง้า
8. มาตรการแก้ไขและป้องกัน
9. ภาคผนวก / ทะเบียนเอกสาร
หากเป็นไปได้ ให้คงการอ้างอิงถึงเอกสารที่เป็นฐานไว้ข้างข้อสรุปที่สำคัญ
ที่ส่วนบนของเอกสาร ให้ระบุว่า: “ร่าง ต้องได้รับการตรวจสอบและความเห็นชอบจากคณะกรรมการ”
อย่าเขียนข้อสรุปเกี่ยวกับความผิดของบุคคลใดความเชื่อมโยงกับบทความ: หัวข้อ “ระบบออฟไลน์สร้างเสร็จแล้ว ตอนนี้เรากำลังทดสอบ”
ฉันไม่ใช่โปรแกรมเมอร์ ช่วยสร้างแอปพลิเคชัน “สำหรับทดสอบ” ที่ทำงานภายในเครื่อง เพื่อใช้สอบสวนอุบัติการณ์ภายในตามระเบียบวิธีขององค์กร เป้าหมายของขั้นนี้คือโครงการนำร่องและการตรวจสอบคุณภาพ ไม่ใช่การนำไปใช้งานจริงในการผลิตโดยอัตโนมัติ
ทำงานทีละขั้น ในแต่ละขั้น:
1. อธิบายว่าเรากำลังทำอะไรและทำไปเพื่ออะไร
2. ให้การดำเนินการเพียงหนึ่งอย่าง หรือไฟล์/แพตช์ที่พร้อมใช้หนึ่งชุด
3. รอผลลัพธ์หรือภาพหน้าจอจากฉัน
4. ตรวจสอบผลนั้น
5. จากนั้นจึงไปยังขั้นถัดไป
สถาปัตยกรรมเป้าหมาย
- Windows 10/11
- backend ภายในเครื่องที่ 127.0.0.1 และอินเทอร์เฟซผ่านเบราว์เซอร์
- หลังจากเตรียมโมเดลเพียงครั้งเดียว ต้องทำงานกับเอกสารในแฟ้มการสอบสวนได้โดยไม่ต้องใช้อินเทอร์เน็ตภายนอก
- รองรับการทำงานบนคอมพิวเตอร์ทำงานที่มีประสิทธิภาพสูง สำหรับเครื่องสเปกต่ำ ให้เสนอโมเดลขนาดเล็กกว่า แต่อย่าปิดบังว่าคุณภาพ/ความเร็วจะลดลง
- จัดเก็บแฟ้มการสอบสวนภายในเครื่อง
- ไฟล์เก็บถาวรของแฟ้มการสอบสวนพร้อมค่าตรวจสอบความถูกต้องของไฟล์
- ประวัติเวอร์ชัน
- ไม่มีการบังคับส่งเอกสารไปยัง API ภายนอกใด ๆ ทั้งสิ้น
เอกสาร
- DOCX: ย่อหน้า ตาราง หัวกระดาษและท้ายกระดาษ
- PDF ที่มีข้อความ
- PDF ที่เป็นไฟล์สแกน / ภาพ — รู้จำข้อความภายในเครื่อง
- แผนผัง / ภาพถ่าย — เก็บต้นฉบับไว้ และเสนอคำบรรยายในฐานะร่างเท่านั้น
- เสียง / วิดีโอ — ถอดเสียงภายในเครื่อง
- การบันทึกจากไมโครโฟน
- การป้อนและแก้ไขด้วยตนเอง
- ต้องทำเครื่องหมาย “ตรวจทานกับต้นฉบับแล้ว” ก่อนนำข้อความไปใช้ในการวิเคราะห์ด้วยเอไอ
โมเดลภายในเครื่อง
- LLM ผ่านเอนจินภายในเครื่อง (เช่น Ollama)
- โมเดลเสียงพูดหลายภาษา Whisper
- หากจำเป็น ให้ใช้ vision-โมเดลภายในเครื่อง
- แอปพลิเคชันต้องไม่แอบดาวน์โหลดโมเดลระหว่างการสอบสวน
ระเบียบวิธี / ขั้นตอน
1. ข้อมูลเบื้องต้น
2. แผนของคณะกรรมการ
3. การรวบรวมเอกสาร
4. ลำดับเหตุการณ์และปัจจัยวิกฤต
5. แนวป้องกันและสาเหตุ
6. มาตรการ
7. รายงาน
กฎของเอไอ
- เอไอทำได้เพียงเสนอ
- ข้อสรุปทุกข้อต้องเก็บแหล่งที่มาและข้อความอ้างอิงไว้
- แยกแยะ FACT / ASSUMPTION / CONFLICT / GAP / HYPOTHESIS
- สาเหตุเป็นเพียงสมมติฐานจนกว่าคณะกรรมการจะยืนยัน
- โมเดลไม่กำหนดผู้รับผิดชอบและกำหนดเวลาเอง
- คณะกรรมการต้องสามารถยอมรับ ปฏิเสธ หรือแก้ไขข้อเสนอแต่ละข้อได้
- ไฟล์ Word ฉบับสุดท้ายเป็นร่างที่แก้ไขได้
- รายงานต้องมีต้นไม้สาเหตุ แนวป้องกัน ทะเบียนเอกสาร และภาคผนวก
ความปลอดภัย
- ไม่ใช้ CDN และไม่มีเทเลเมทรีส่งออกภายนอก
- การเชื่อมต่อเครือข่ายของการสอบสวนใช้ loopback เท่านั้น
- แจ้งให้ผู้ใช้ทราบว่า การทำงานภายในเครื่องไม่เท่ากับการทำให้ข้อมูลไม่ระบุตัวตนโดยอัตโนมัติ
- ห้ามเก็บข้อมูลลับไว้ในโค้ดฝั่งไคลเอนต์ที่เปิดเผย
- รองรับการลบแฟ้มการสอบสวน การสำรองข้อมูล และการย้ายข้อมูล
เริ่มจากโครงสร้างโฟลเดอร์ รูปแบบข้อมูลของแฟ้มการสอบสวน และแบบจำลองภัยคุกคาม อย่าเพิ่งเขียนโค้ดจนกว่าฉันจะยืนยัน
สถานะนำร่อง
- ระบุเวอร์ชันให้ชัดเจนว่า “ทดสอบ / นำร่อง”
- เพิ่มชุดกรณีฝึกหัดสำหรับใช้เป็นกรณีทดสอบเทียบ
- สำหรับแต่ละกรณี ให้เปรียบเทียบผลลัพธ์ของเอไอกับข้อสรุปของมนุษย์/คณะกรรมการ
- จดบันทึกข้อบกพร่องที่พบและรอบการพัฒนาแต่ละรอบ
- อย่าเรียกระบบว่าพร้อมใช้งานจริงในการผลิต จนกว่าการทดสอบจะเสร็จสิ้นความเชื่อมโยงกับบทความ: ส่วนที่ว่าด้วยขอบเขตของระบบอัตโนมัติ การรักษาความลับ และสถานะการทดสอบในปัจจุบัน
ตรวจประเมินแอปพลิเคชันที่พัฒนาเสร็จแล้วและร่างการสอบสวน ก่อนส่งมอบให้คณะกรรมการ
ตรวจสอบด้านเทคนิค
1. มีการเชื่อมต่อเครือข่ายภายนอกระหว่างทำงานกับแฟ้มการสอบสวนหรือไม่
2. มีการใช้ CDN ฟอนต์ภายนอก speech-to-text บนคลาวด์ หรือ API ภายนอกหรือไม่
3. ไฟล์ต้นฉบับ บทถอดเสียง โมเดลภายในเครื่อง และไฟล์สำรองถูกจัดเก็บไว้ที่ใด
4. เกิดอะไรขึ้นเมื่อลบแฟ้มการสอบสวน
5. เอกสารต้นฉบับหลุดเข้าไปอยู่ในบันทึกการวินิจฉัยระบบหรือไม่
6. เนื้อหาในแฟ้มการสอบสวนถูกส่งออกไปเมื่อเกิดข้อผิดพลาดหรือไม่
ตรวจสอบด้านระเบียบวิธี
7. ข้อสรุปที่สำคัญทุกข้อมีแหล่งที่มาหรือไม่
8. ข้อเท็จจริงถูกแยกออกจากสมมติฐานหรือไม่
9. ปัจจัยวิกฤตทุกข้อปรากฏในการวิเคราะห์สาเหตุหรือไม่
10. มีการระบุการกระทำของบุคคลเป็นสาเหตุรากเหง้าโดยไม่วิเคราะห์เงื่อนไขเชิงระบบหรือไม่
11. มาตรการเชื่อมโยงกับสาเหตุ/แนวป้องกันที่เฉพาะเจาะจงหรือไม่
12. โมเดลกำหนดผู้รับผิดชอบและกำหนดเวลาโดยที่คณะกรรมการยังไม่ได้ตัดสินหรือไม่
13. ร่างรายงานถูกนำเสนอว่าเป็นเอกสารที่ได้รับการรับรองแล้วหรือไม่
ตรวจสอบการรักษาความลับ
14. มีข้อมูลส่วนบุคคล/ข้อมูลทางการแพทย์ใดบ้างในแฟ้มการสอบสวนภายในเครื่อง
15. จำเป็นต้องปิดบังข้อมูลเพิ่มเติมสำหรับการสาธิต การเผยแพร่ หรือการส่งต่อหรือไม่
16. ชื่อไฟล์และภาพหน้าจอมีชื่อ-นามสกุลที่ไม่จำเป็นปรากฏอยู่หรือไม่
สรุปผลเป็นตาราง:
การตรวจสอบ | สถานะ | ความเสี่ยงที่พบ | สิ่งที่ต้องแก้ไข | ผู้ที่ต้องยืนยัน
อย่าแก้ไขข้อสรุปเชิงเนื้อหาของการสอบสวนโดยอัตโนมัติ
ตรวจสอบสถานะความพร้อม
17. มีชุดกรณีทดสอบเทียบและผลการเปรียบเทียบหรือไม่
18. ฟังก์ชันใดเสถียรแล้ว และฟังก์ชันใดยังอยู่ในขั้นทดลอง
19. ข้อผิดพลาด/ข้อจำกัดใดต้องแก้ไขก่อนนำไปใช้งานจริงในการผลิต
20. อินเทอร์เฟซทำให้เกิดความเข้าใจผิดหรือไม่ว่า ผลลัพธ์ของเอไอคือการตัดสินใจของคณะกรรมการหลักการพื้นฐานของซีรีส์นี้ยังคงเหมือนเดิม: ปกป้องข้อมูลและกำหนดระเบียบวิธีก่อน แล้วจึงทำให้เป็นอัตโนมัติ เอไอช่วยเสริมการทำงานของคณะกรรมการ แต่ไม่ได้มาแทนที่การคิดอย่างมืออาชีพ การตรวจสอบข้อเท็จจริง และความรับผิดชอบของมนุษย์