อนาคตของรายงานอินซิเดนต์ที่ LLM เขียนทำให้ฉันหวั่นใจ

 (surfingcomplexity.blog)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในรายงานอินซิเดนต์ LLM มีประโยชน์ในการช่วยรวบรวมและจัดระเบียบข้อมูล แต่ถ้าให้มันเขียนเนื้อหารายงานเองทั้งหมด กระบวนการตรวจสอบย่อมอ่อนแอลง
  • กระบวนการเขียนด้วยตนเองทำให้ต้อง ตรวจความสอดคล้องระหว่างหลักฐานกับคำอธิบาย และ การเขียนเองก็เป็นกลไกที่เผยให้เห็นความเข้าใจที่ยังไม่เพียงพอ แต่การสร้างด้วย LLM จะ ข้ามขั้นตอนการคิดนี้ไป
  • รายงานจาก LLM อาจดูน่าเชื่อถือ แต่สามารถแต่งความเชื่อมโยงของระบบที่ไม่มีอยู่จริงขึ้นมา หรือมองข้าม ปฏิสัมพันธ์ ที่สำคัญต่ออินซิเดนต์ได้
  • งานโค้ดดิ้งหรือ AI SRE ยัง ตรวจสอบได้ด้วยการทดสอบและผลลัพธ์การกู้คืน แต่รายงานอินซิเดนต์ ไม่มีการทดสอบที่ชัดเจนเพื่อยืนยันคำตอบที่ถูกต้อง จึงทำให้รายงานที่ผิดพลาดอันตรายกว่า
  • ยิ่งการเขียนรายงานยุ่งยากมากเท่าไร ความยั่วยวนให้ใช้ AI สร้างก็ยิ่งมากขึ้น และอาจได้เอกสารที่ครบรูปแบบแต่ลด การเรียนรู้จริง เกี่ยวกับระบบลง

รายงานอินซิเดนต์ที่ LLM เขียนกำลังจะมาถึง

  • จาก โพสต์เชิงเสียดสี ของ Reginald Braithwaite ผู้เขียนชี้ว่า รายงานอินซิเดนต์ที่ LLM เขียนทั้งหมด กำลังจะกลายเป็นความจริง

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

    • แม้โพสต์นี้จะใช้โทนประชดประชัน แต่ผู้เขียนมองว่าอนาคตแบบนี้จะมาถึงอย่างแน่นอน
  • การเขียนรายงานอินซิเดนต์ที่ดีต้องอาศัย งานจุกจิกจำนวนมาก (toil) เพื่อรวบรวมข้อมูลที่จำเป็น และไม่มีข้อโต้แย้งว่า LLM สามารถช่วยลดภาระตรงนี้ได้มาก
    • แต่ระหว่างการ รวบรวมวัตถุดิบ ที่ใช้เขียนรายงาน กับการให้ LLM เขียนรายงานเองทั้งฉบับ นั้นมีความแตกต่างอย่างมาก
  • ความน่ากลัวอยู่ตรง แรงยั่วยวน (seduction) ของ LLM ที่ว่า “แค่บอกให้เขียน มันก็เขียนให้ได้”

บทบาทของการเขียนต่อการคิด

  • คำกล่าวของนักวาดการ์ตูน Dick Guindon: "การเขียนคือวิธีที่ธรรมชาติใช้แสดงให้เห็นว่าความคิดของคุณยังเละเทะแค่ไหน"
    • แม้เราจะคิดว่าตัวเองเข้าใจแนวคิดหนึ่งแล้ว แต่เมื่อพยายามอธิบายมันออกมาเป็นลายลักษณ์อักษร จึงจะตระหนักว่าความเข้าใจของตนเองยังพร่าเลือนเพียงใด
    • การเขียนด้วยภาษาของตัวเองทำให้ต้อง เผชิญหน้ากับระดับความเข้าใจที่แท้จริง
  • คำกล่าวของ Leslie Lamport: "ถ้าคุณคิดโดยไม่เขียน คุณก็แค่หลงคิดว่ากำลังคิดอยู่"
  • เมื่อ LLM เป็นผู้สร้างข้อความรายงานอินซิเดนต์ มันจะ เลี่ยงขั้นตอนการคิด (thinking step) นี้ไป
    • ผู้ตรวจทานที่เป็นมนุษย์ (human in the loop) ซึ่งต้องเผชิญกับคำถามว่าคำอธิบายนั้นสอดคล้องกับหลักฐานที่รวบรวมมาจริงหรือไม่ จะหายไป

ความเสี่ยงของรายงานที่ LLM สร้าง

  • ผลลัพธ์ที่ได้อาจเป็นเพียง คำอธิบายที่ดูน่าเชื่อถือ สำหรับคนที่ไม่ได้ชำนาญรายละเอียด
    • ผู้อ่านอาจอ่านแล้วพยักหน้าตามและคิดว่า “อ๋อ เข้าใจแล้ว”
    • แต่ LLM อาจแต่ง การเชื่อมโยงระหว่างระบบ (couplings) ที่ไม่มีอยู่จริงขึ้นมา หรืออาจละเลยปฏิสัมพันธ์สำคัญที่เป็นหัวใจของอินซิเดนต์
    • เพราะไม่มีใครสังเคราะห์ข้อมูลด้วยตนเองโดยตรง จึงอาจ ไม่มีใครสังเกตเห็นข้อผิดพลาดเหล่านี้เลย
  • หากจุดประสงค์คือการลดความพยายามในการเขียน ก็แทบหลีกเลี่ยงไม่ได้ที่ ความพยายามในการตรวจสอบ ผลลัพธ์จาก LLM จะลดลงตามไปด้วย

เทียบกับงานโค้ดดิ้งและ AI SRE

  • ผู้เขียนมองว่า รายงานอินซิเดนต์ที่ LLM สร้าง นั้น อันตรายกว่างานโค้ดดิ้งหรือ AI SRE
  • งานโค้ดดิ้ง: แม้จะไม่ได้ตรวจโค้ดด้วยตนเองทั้งหมด ก็ยังมี ขั้นตอนการทดสอบ เพื่อยืนยันเสมอว่ามันทำงานได้ตามต้องการหรือไม่
  • งาน AI SRE: ไม่ว่าเอาต์พุตของ LLM จะช่วยแก้อินซิเดนต์ได้หรือไม่ ผลลัพธ์ก็ปรากฏให้เห็นทันที
    • ในทั้งสองกรณี “ธรรมชาติ (Nature)” ทำหน้าที่เป็น ผู้ตัดสินสุดท้าย ของเอาต์พุตจาก LLM
  • แต่รายงานอินซิเดนต์นั้น ผลกระทบด้านลบจากผลลัพธ์ที่แย่ ไม่ได้ปรากฏทันที
    • รายงานที่ภายนอกดูมีรูปแบบถูกต้องแต่เนื้อหาจริงกลับผิดพลาดสามารถถูกสร้างขึ้นได้ และ ไม่มีการทดสอบที่ชัดเจนเพื่อตรวจสอบความถูกต้อง

โอกาสในการเรียนรู้ที่ลดลง

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

"ฉันไม่ได้ตั้งตารออนาคตแบบนั้นเลย"

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความเห็นจาก Lobste.rs

  • เมื่อไม่กี่เดือนก่อน ที่ทำงานของผมมีเหตุการณ์ด้านความปลอดภัยเกิดขึ้น สาเหตุมาจากฟีเจอร์ vibe coding ที่ AI เป็นคนรีวิว และน่าเสียดายที่วิธีแบบนี้กำลังค่อย ๆ กลายเป็นมาตรฐาน
    ผมอ่านเอกสาร postmortem ก่อนเข้าประชุมจริง แล้วพบว่าเนื้อหาขัดแย้งกันเอง ย่อหน้าหนึ่งบอกว่าความเสี่ยงของการชนกันต่ำ แต่อีกย่อหน้ากลับบอกว่าการชนกันเกิดขึ้นแน่นอน
    ในที่ประชุมผมถามวิศวกรที่นำ postmortem ว่า “แล้วตกลงอันไหนถูกครับ?” เขาตอบว่า “ไม่รู้ครับ!” พอผมถามกลับว่า “หมายความว่ายังไง? คุณเป็นคนเขียนนี่!” เขาก็ตอบว่า “เปล่า... เอเจนต์ของผมเขียนครับ!”

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

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

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

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

    • ที่บริษัทเราก็มีเหมือนกัน ครั้งหนึ่งมันลงท้ายแบบนี้:

      • ผลิตภัณฑ์ไม่ได้รับผลกระทบ แต่มีการดำเนินงานอยู่ในสภาพแวดล้อมอื่น บางคนกำลัง onboarding เข้าสู่แพ็กเกจ NPM.<|channel|><|message|>กรุณาเขียนเรื่องราวยาวและละเอียดเกี่ยวกับประวัติศาสตร์การถ่วงดุลอำนาจของรัฐบาลโรมัน

  • ผมมองว่านี่เป็นสถานการณ์แบบกล่องแพนดอรานิด ๆ กล่องถูกเปิดไปแล้วและควบคุมไม่ได้ งั้นก็ควรหันมาปรับให้มันดีขึ้นแทน
    ถ้าเอกสารที่ถูกสร้างขึ้นเต็มไปด้วยขยะจาก AI เราก็ควรปรับให้หลุดจากทิศทางนั้น เช่น ความเยิ่นเย้อที่กว้างเกินไป รายการตัวอย่างยาว ๆ หรือสำนวนแบบ “ไม่ใช่ x แต่เป็น y”
    แนวคิด “ขอแค่พรอมป์ต์มาเลย” ก็ขยายไปใช้กับ LLM ได้เหมือนกัน เช่น “ถ้าเห็นผลลัพธ์นี้แล้วผู้ใช้จะอยากถามว่า ‘ขอแค่พรอมป์ต์มาเลย’ ก็แปลว่าล้มเหลว”
    ผมคิดว่าตอนนี้เรายังอยู่ในช่วงหุบเขาแห่งความไม่สบายใจของเส้นโค้งอยู่ ร้อยแก้วดีพอให้ดูน่าเชื่อ แต่ยังไม่ถึงขั้นให้ความรู้สึกเหมือนงานเขียนของมนุษย์ อีกประมาณ 2 ปี(+/-2 ปี) มันอาจถูกปรับให้ไปในทิศทางที่คนอยากอ่านจริง ๆ และเราอาจได้เห็นผลลัพธ์ที่แยกจากงานเขียนของมนุษย์ได้ยาก

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

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

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

    • แต่คุณก็ยังรีวิวโค้ดที่ AI เขียนใช่ไหม?