เมื่อเปิด bozo bit การเรียนรู้ก็จะปิดลง

 (surfingcomplexity.blog)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • bozo bit คือท่าทีที่มองว่าไม่ควรรับฟังหรือให้คุณค่ากับวิจารณญาณและคำพูดของคนบางคนอีกต่อไป
  • เมื่อตัดแยกผู้เกี่ยวข้องกับอุบัติเหตุว่าไร้ความสามารถ โอกาสที่องค์กรจะเรียนรู้จากอุบัติเหตุก็ลดลง
  • การรับมือเหตุการณ์ AI ของ PocketOS เข้าข่าย distancing through differencing ตามที่ Cook และ Woods อธิบาย
  • โรงงานในสหรัฐฯ ที่มองเหตุไฟไหม้โรงงานต่างประเทศว่าเป็นเรื่องของคนอื่น ทำให้มองข้าม ความเหมือนร่วมกันของระบบ
  • หากปิดท้ายอุบัติเหตุ AI แค่ว่า “พวกเขาควรรู้อยู่แล้ว” ก็ยากจะนำไปสู่การปรับปรุงด้านความปลอดภัย

เมื่อมองว่าอุบัติเหตุเป็นเรื่องของคนอื่น การเรียนรู้ก็หยุดลง

  • bozo bit เป็นคำในวงการซอฟต์แวร์ที่หมายถึงการเลิกให้ความเคารพต่อวิจารณญาณของใครบางคน และมองว่าไม่คุ้มค่าที่จะฟังสิ่งที่คนนั้นพูดอีกต่อไป
  • เมื่อได้ยินข่าวอุบัติเหตุแล้วพูดว่า “ทำไมถึงไม่ทำ X?” เรามักจะมองผู้เกี่ยวข้องกับอุบัติเหตุว่าไร้ความสามารถ และแยกพวกเขาออกจากองค์กรของตัวเอง
  • โพสต์บน X ของ Jer Crane ผู้ก่อตั้ง PocketOS An AI Agent Just Destroyed Our Production Data. It Confessed in Writing ได้รับความสนใจอย่างมากในฐานะอุบัติเหตุเกี่ยวกับ AI และบนโลกออนไลน์ก็มีหลายโพสต์ที่มองว่า PocketOS ไร้ความสามารถ
  • ท่าทีแบบนี้ทำให้โอกาสในการเรียนรู้จากอุบัติเหตุลดลง และเข้าข่าย distancing through differencing ตามที่ Cook และ Woods อธิบาย

  • การเว้นระยะด้วยการเน้นความแตกต่าง (distancing through differencing)

    • Richard Cook และ David Woods ใช้คำนี้ในบทความปี 2006 Distancing Through Differencing: An Obstacle to Organizational Learning Following Accidents
    • บทความนี้ถูกรวมอยู่เป็นบทหนึ่งใน Resilience Engineering: Concepts and Precepts
    • หากมัวแต่โฟกัสที่ความแตกต่างระหว่างฝ่ายที่เกิดอุบัติเหตุกับตัวเรา เราก็จะสรุปว่าไม่มีบทเรียนอะไรที่นำกลับมาปรับใช้กับการปฏิบัติงานของเราได้
    • ข้อสรุปว่า “อุบัติเหตุแบบนั้นเกิดขึ้นที่นี่ไม่ได้” คือรูปแบบตัวอย่างของปรากฏการณ์นี้

อุบัติเหตุที่เกิดซ้ำและจุดร่วมที่ถูกมองข้าม

  • Cook และ Woods ยกกรณีไฟไหม้สารเคมีในโรงงานผลิตของสหรัฐฯ มาเป็นตัวอย่าง
  • ก่อนหน้านั้นเคยมีเหตุไฟไหม้ลักษณะคล้ายกันในโรงงานต่างประเทศของบริษัทเดียวกัน และพนักงานในสหรัฐฯ ก็รู้เรื่องนี้อยู่แล้ว
  • แต่พนักงานในสหรัฐฯ มองว่าพนักงานต่างประเทศมีทักษะน้อยกว่า แรงจูงใจน้อยกว่า และระมัดระวังน้อยกว่า จึงตัดสินว่าไม่มีอะไรที่พวกเขาต้องเรียนรู้
  • แม้หลังจากเกิดไฟไหม้ในโรงงานสหรัฐฯ คนงานกะอื่นในโรงงานเดียวกันก็ยังโทษว่าสาเหตุเกิดจากทักษะต่ำของกะที่เกิดเหตุ
  • การแบ่งแยกเช่นนี้ทำให้มองไม่เห็น ความเหมือนร่วมกันของระบบ ที่ผู้ประสบเหตุกับตัวเราใช้ร่วมกัน
  • Cook และ Woods เห็นว่าเราไม่ควรละทิ้งเหตุการณ์ที่ดูแตกต่างกันเพียงผิวเผิน เพราะแม้ทุกเหตุการณ์จะมีลักษณะเฉพาะในระดับหนึ่ง แต่ในอีกระดับหนึ่งก็อาจเผยให้เห็นรูปแบบร่วมกันได้
  • หากสรุปเหตุการณ์ของ PocketOS แบบง่าย ๆ ว่า “ใช้ AI อย่างไม่รับผิดชอบ” ก็จะไม่เหลือบทเรียนอะไรให้เรียนรู้
  • Railway ซึ่ง PocketOS ใช้งาน เป็นเวนเดอร์ที่เปิดเผย delete API และภายหลังได้ประกาศใน Your AI wants to nuke your database. Guardrails fix that ว่าได้ปรับเปลี่ยนเพื่อยกระดับความปลอดภัยของระบบโดยรวมแล้ว
  • ต่อจากนี้ อุบัติเหตุที่เกี่ยวข้องกับ AI ในอุตสาหกรรมก็จะยังเกิดขึ้นต่อไป และท่าทีแบบ “พวกเขาควรรู้อยู่แล้วว่าไม่ควรทำ X” ก็คือการตกอยู่ในกับดักของ distancing through differencing
  • กรณีที่ใครบางคนจงใจรับความเสี่ยงเกินควร กับกรณีที่รับความเสี่ยงเกินควรโดยไม่รู้ตัวนั้นต่างกัน และก็ยากจะกล่าวโทษปัจเจกเพียงเพราะพวกเขาไม่รู้ในสิ่งที่ตัวเองไม่รู้
  • เมื่อก้าวข้าม distancing through differencing ได้ การตอบสนองขององค์กรก็อาจเปลี่ยนไป

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

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

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

  • คุณค่าของ bozo bit อยู่ที่คนบางประเภทเป็น แหล่งข้อมูลย้อนกลับที่เชื่อถือได้ในทางกลับกัน
    คนแบบนี้มักจะสรุปผิดซ้ำๆ เป็นนิสัย, เข้าใจเอกสารที่เขียนไว้อย่างตรงไปตรงมาผิด, และเสนอการออกแบบที่แก้เป้าหมายไม่ได้แถมสร้างปัญหาใหม่
    การ “เปิด bozo bit” ให้ใครสักคนหมายถึงตัดสินแล้วว่าเวลาที่พยายามเอาความรู้จากการสื่อสารของคนนั้นเป็นเวลาที่สูญเปล่า
    บทความนี้เอา bozo bit ไปปนกับปรากฏการณ์อีกแบบหนึ่ง คือการเชื่ออย่างหนักแน่นว่าปัญหาบางอย่างไม่มีทางเกิดขึ้นได้ แล้วค่อยหาเหตุผลมาย้อนรับความเชื่อนั้น
    คำที่เคยได้ยินสำหรับสิ่งนี้คือ การหาเหตุผลภายหลัง และมีการพูดกันมาหลายศตวรรษหรืออาจหลายพันปีแล้วว่าควรหลีกเลี่ยงมัน
    ถ้าย้อนกลับไปที่ตัวอย่างบริษัทซึ่งให้ LLM มีสิทธิ์ผู้ดูแลฐานข้อมูลโปรดักชัน ปฏิกิริยาแบบ “นั่นจะไม่เกิดกับฉันเพราะ X” ก็สมเหตุสมผล ถ้า X ใกล้เคียงกับ “ฉันจะไม่ให้สิทธิ์แอดมินฐานข้อมูลโปรดักชันกับ LLM ตั้งแต่แรกอยู่แล้ว เพราะมันประหลาดและเสี่ยงแบบบ้าคลั่งเกินไป”
    มันคล้ายกับคนที่กินของอันตรายแล้วเกิดโศกนาฏกรรม ขณะอ่านข่าวว่ามีคนกินทากแล้วตายเพราะพยาธิในสมอง ฉันก็มั่นใจได้ว่าฉันจะไม่ตายด้วยสาเหตุเฉพาะแบบนั้น
    ผู้เขียนจินตนาการว่านั่นเป็นเพราะฉันเชื่อว่าตัวเองดีกว่าหรือฉลาดกว่าคนที่ตายไป แต่กระบวนการคิดจริงๆ ใกล้กับ “ฉันมั่นใจ 100% ว่าต่อให้หิวอยู่บนเกาะร้างที่เต็มไปด้วยทากฉ่ำๆ ฉันก็จะไม่สมัครใจกินทาก ดังนั้นพยาธิที่มากับทากจึงไม่อยู่ในแบบจำลองความเสี่ยงของฉัน” มากกว่า
    ส่วนที่บอกว่า “พวกเขาน่าจะรู้” เป็นคำพูดที่ไม่สมเหตุสมผลนั้น ฉันก็เห็นด้วยยากเหมือนกัน คนเราถูกตำหนิเรื่องที่ไม่รู้อยู่ตลอด และนั่นก็เป็นส่วนหนึ่งของการเป็นผู้ใหญ่
    ถ้าเด็ก 3 ขวบกินทาก ฉันคงไม่โทษ แต่ถ้าเพื่อนร่วมงานอายุ 30 กินทาก ฉันก็จะโทษตามปกติ พฤติกรรมที่โง่ชัดเจนเกินไปแบบนี้ โทษกันได้

    • สำหรับคำพูดที่ว่าเราจะโทษใครเพราะ “ไม่รู้อะไรบางอย่าง” ได้อย่างไรนั้น ก็มีคำว่า ความไม่รู้โดยเจตนา อยู่แล้ว
      ฉันคิดว่าบทความนี้มีประเด็นที่ดีที่ฉันไม่เคยคิดมาก่อน แต่สำหรับฉันมันก็มีข้อบกพร่องชัดๆ อยู่หลายข้อ และนี่คือข้อแรก
      ข้อที่สองคือ ตอนอ่านเรื่องของคนอเมริกัน ฉันก็ถามตัวเองว่า “การเว้นระยะด้วยการเน้นความแตกต่างของพวกเขา มันเหมือนกับสิ่งที่ฉันทำตอนเมินอุบัติเหตุลบระบบโปรดักชันด้วย AI จริงหรือ?”
      กล่าวคือ ถ้าพวกเขาไม่รู้เลยว่าความเสี่ยงเกิดขึ้นในโรงงานอื่นได้อย่างไร แต่กลับปัดทิ้งว่ามันจะไม่มาถึงตัวเอง แบบนั้นก็ไม่สมเหตุสมผล
      แต่ถ้าได้ยินว่าผู้จัดการเอาหุ่นยนต์มนุษย์ทดลองแบบใหม่ที่ไม่เป็นเชิงกำหนดเข้าไปในพื้นที่โรงงาน เพื่อช่วยให้คนงานฝีมือทำงานได้เร็วขึ้นอย่างอิสระ การเมินของพวกเขาก็ไม่อาจมองในแง่เดียวกันได้
      ถึงอย่างนั้นฉันก็รับข้อสรุปนะ เพราะความมักมากไม่ใช่เรื่องแบบสองค่า
      ครั้งหน้าถ้าได้ยินเรื่องเหลือเชื่อ ฉันคงหยุดคิดสักนิดว่า “ถึงฉันจะไม่ประมาทเท่าที่พวกเขาทำ แต่มีอะไรในสิ่งที่ฉันทำอยู่บ้างที่ควรระวังและใส่กลไกป้องกันเพิ่ม?”
    • ฉันคงไม่ถามว่าเด็ก 3 ขวบทำไมถึงกินทาก
      แต่ถ้าเพื่อนร่วมงานอายุ 30 กินทาก ฉันจะสืบอย่างละเอียดว่าเขาไปอยู่ในสถานการณ์นั้นได้อย่างไร
      ถ้าฉันเริ่มอยาก “โทษ” คนนั้น ฉันคงถามก่อนว่าทำไมเราถึงจ้าง คนที่กินทาก เข้ามา และตอนนี้ยังทำแบบนั้นอยู่หรือเปล่า
    • ประเด็นสำคัญที่ฉันได้จากบทความนี้คือ ผู้เขียน ไม่รู้ว่า bozo bit คืออะไร

  • มีอยู่หลายจุดที่สมเหตุสมผล
    ตรงที่บอกว่า “ฉันอยากอธิบายว่าทำไมปฏิกิริยานี้ถึงให้ผลย้อนกลับ และอยากชี้คำศัพท์เชิงเทคนิคของปรากฏการณ์ญาติใกล้ชิดกับการเปิด bozo bit นี้ มันเรียกว่า distancing through differencing” นั้น ปฏิกิริยานี้ ทั้งมีประโยชน์และให้ผลย้อนกลับ
    มันมีประโยชน์เพราะในโลกที่มีเหตุการณ์ถาโถมเกินจะรับมืออยู่แล้ว การไม่ต้องประเมินทุกอินพุตเป็นการปรับให้เหมาะสมครั้งใหญ่
    และในขณะเดียวกันมันก็ให้ผลย้อนกลับด้วยเหตุผลที่บทความยกมา
    เคล็ดลับจริงๆ คือการรู้ว่าอะไรควรรับอย่างจริงจังและควรใส่ใจ ถ้าฉันฝึกเคล็ดลับนั้นได้แล้วจะมาบอกอีกที

  • จากเรื่องที่มีคนให้ AI เข้าถึงระบบโปรดักชันโดยตรง ฉันควรเรียนรู้อะไร?

    • ถ้าตีความเหตุการณ์ LLM แบบใจกว้างหน่อย บทเรียนอาจเป็นว่า การเข้าถึงโปรดักชันควรถูกควบคุมด้วย access control และงานที่ทำลายล้างได้ควรต้องมีการอนุมัติจาก 2 คน
      ฉันเคยทำงานที่บริษัทหนึ่งซึ่งกำลังเติบโตเร็ว และแนวปฏิบัติทางวิศวกรรมหลายอย่างยังใกล้กับสตาร์ตอัปในโรงรถมากกว่าบริษัทข้ามชาติพันคน
      ตอนนั้นมี 3 อย่างที่เป็นจริง อย่างแรก การ deploy service ทำโดย cd ไปยังไดเรกทอรี Git checkout บนโน้ตบุ๊กแล้วรัน <tool> deploy <service-name> และ Git commit ที่ checkout อยู่ตอนนั้นจะถูกนำไป deploy ตรงๆ
      อย่างที่สอง เพราะวัฒนธรรมความไว้ใจเพื่อนร่วมงาน ระบบ deploy จึงแทบไม่มี access control มีรายชื่อคนที่ deploy ได้ และถ้าคุณอยู่ในนั้น คุณจะ deploy service ไหนก็ได้
      อย่างที่สาม Git repository หลักมีขนาดใหญ่ และ Wi‑Fi ในออฟฟิศก็หนาแน่น ทำให้ clone ใช้เวลานาน เพื่อให้พนักงานใหม่เริ่มงานได้เร็วขึ้น image สำหรับ provision โน้ตบุ๊กจึงรวม Git checkout ของ repository หลักไว้ด้วย
      แล้ววันหนึ่งทีมฐานข้อมูลได้อินเทิร์นใหม่มา และระหว่างทำตามบทเรียนในวิกิ Database Team 101 เขาก็รันคำสั่งแนะนำเพื่อตรวจว่าการ deploy ใช้งานได้หรือไม่: <tool> deploy --prod <database>
      ปรากฏว่า image provision โน้ตบุ๊กนั้นเก่าแล้ว และอินเทิร์นคนนั้นยังไม่ได้เข้าอบรม onboarding ตอน git pull origin master เลย
      เรื่อง “LLM ทำระบบโปรดักชันพัง” กับเรื่อง “อินเทิร์นทำระบบโปรดักชันพัง” คล้ายกัน แต่แบบหลังเรียนรู้อะไรได้ง่ายกว่า เพราะความผิดพลาดแต่ละจุดเล็กกว่า

  • ถ้ามองจากมุมการวิเคราะห์เหตุขัดข้อง การ เปิด bozo bit แล้วหยุดเรียนรู้ คือการหยุดอยู่ที่ปัจจัยร่วมเพียงจุดเดียวในทั้ง fault tree นั่นคือ “human error!”
    ในตัวอย่างที่ยกมา โหนด “ให้วงจร LLM เข้าถึงโปรดักชัน” ใน fault tree กระตุ้นฮิวริสติก “พวกโง่นี่ไม่ต้องสนใจ” ของผู้อ่าน
    แต่โหนดพี่น้องอย่าง “ระบบอนุญาตให้ลบโดยไม่ยืนยันผ่าน API” เป็นบทเรียนที่มีค่า และถ้าหยุดที่โหนดแรกที่เห็น ก็อาจพลาดมันไป
    นอกจากนี้ fault tree ควรมีโหนดย่อยที่ขุดต่อว่าทำไมงานอันตรายนั้นจึงถูกเอาออกจาก GUI แต่ยังคงอยู่ใน API และทำไม LLM ถึงได้สิทธิ์เข้าถึงโปรดักชัน

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

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

  • มีสิ่งที่ได้เรียนรู้อยู่: อย่าใช้ เครื่องมือ AI