วิธีหยุดยั้ง “ภัยคุกคามสามประสานร้ายแรง” ของ AI

 (economist.com)
8 คะแนน โดย GN⁺ 2025-10-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • LLM มีปัญหาเชิงโครงสร้างที่ไม่สามารถแยกโค้ดออกจากข้อมูลได้ จึงเปราะบางต่อการโจมตีแบบ prompt injection
  • โดยเฉพาะเมื่อมีการให้สิทธิ์เข้าถึงข้อมูลภายนอก อ่านความลับภายใน และสื่อสารกับภายนอกพร้อมกัน จะเกิดสิ่งที่เรียกว่า lethal trifecta ซึ่งอาจนำไปสู่ความเสียหายร้ายแรง
  • วิศวกร AI ควรคิดแบบวิศวกรเครื่องกล และยอมรับความไม่แน่นอนของระบบเชิงความน่าจะเป็นแทนแนวทางแบบกำหนดตายตัว พร้อมเผื่อระยะความปลอดภัยไว้
  • เช่นเดียวกับที่วิศวกรยุควิกตอเรียเผื่อส่วนเกินในการออกแบบเพื่อรับมือกับความไม่แน่นอนของวัสดุ ระบบ AI ก็ควรนำแนวคิดเรื่องขีดจำกัดความปลอดภัย ระดับความเสี่ยงที่ยอมรับได้ และอัตราความผิดพลาดมาใช้
  • ถึงเวลาที่ระบบ AI ต้องมีบรรทัดฐานเรื่องขีดจำกัดที่ชัดเจนและระยะเผื่อด้านความปลอดภัย เหมือนกับสะพานในโลกจริงที่มีข้อจำกัดด้านน้ำหนักบรรทุก

ปัญหาความปลอดภัยโดยเนื้อแท้ของ LLM

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

ชุดสามประสานร้ายแรง (Lethal Trifecta)

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

จำเป็นต้องเปลี่ยนวิธีคิดของวิศวกร AI

คิดแบบวิศวกรเครื่องกล

  • วิศวกรรม AI ที่ดีกว่าคือแนวป้องกันด่านแรก
  • วิศวกร AI ควรคิดแบบวิศวกรที่สร้างโครงสร้างอย่างสะพาน
    • ตระหนักว่างานที่หละหลวมอาจคร่าชีวิตผู้คนได้

บทเรียนจากวิศวกรรมยุควิกตอเรีย

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

ปัญหาของอุตสาหกรรมความปลอดภัย AI ในปัจจุบัน

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

แนวทางที่เหมาะกับระบบเชิงความน่าจะเป็น

ข้อจำกัดของข้อมูลฝึกและพรอมป์ต์

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

เลียนแบบวิศวกรรมในโลกกายภาพ

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

กลยุทธ์การออกแบบเผื่อเกินในยุค AI

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

ความจำเป็นของการกำหนดขีดจำกัดความปลอดภัย

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

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

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

 
GN⁺ 2025-10-02
ความคิดเห็นใน Hacker News
  • ลิงก์บทความฉบับเก็บถาวร
  • นี่เป็นบทความที่สองของ Economist ในสัปดาห์นี้ที่พูดถึง lethal trifecta บทความแรกคือ ระบบ AI จะไม่มีวันปลอดภัยได้อย่างสมบูรณ์ — ‘ภัยคุกคามสามประสานร้ายแรง’ ที่ต้องรับมือ ซึ่งอธิบายได้ชัดเจนที่สุดในสื่อว่า prompt injection คืออะไรและทำไมถึงอันตราย มีส่วนที่อ้างถึงผมอยู่ด้วยเลยอาจลำเอียงนิดหน่อย แต่เป็นบทความที่อยากแนะนำให้ผู้บริหารอ่านจริงๆ ส่วนบทความใหม่นี้ผมไม่ค่อยชอบนัก เพราะมันพูดว่า LLM เป็นระบบไม่กำหนดแน่นอน จึงแก้ช่องโหว่ด้านความปลอดภัยได้ยาก แล้วจึงยกอุปมาให้ “ออกแบบเกินความจำเป็น” และเผื่อค่าคลาดเคลื่อนเหมือนสะพาน ถ้าเป็นสะพานก็อาจพอเข้าใจได้ แต่สำหรับช่องโหว่ความปลอดภัย ผมไม่คิดว่านี่เป็นทางแก้ที่รากฐาน หากระบบโดน prompt injection ได้แค่ 1 ครั้งจาก 100 ครั้ง ผู้โจมตีก็จะพยายามดัดแปลงการโจมตีต่อไปจนสำเร็จ ถ้าตัดองค์ประกอบใดองค์ประกอบหนึ่งของ lethal trifecta (การเข้าถึงข้อมูลที่ไม่เปิดเผย, การเปิดรับคำสั่งที่ไม่น่าเชื่อถือ, ช่องทางรั่วไหลออกภายนอก) ได้ การโจมตีก็จะเกิดขึ้นไม่ได้
    • โดยทั่วไปคนสร้างสะพานไม่ได้ออกแบบเพื่อรับมือการโจมตีแบบปรปักษ์ ถึงจะเตรียมไว้บ้าง ก็มักเน้นให้ย้ายง่ายและตั้งใหม่ได้เร็ว มากกว่าจะทำให้แข็งแกร่งสุดๆ สะพานที่แข็งแรงจนทนระเบิดได้ ไม่คุ้มเท่ากับการสร้างสะพานชั่วคราวเพิ่มอีกหนึ่งอันที่เร็วและถูกกว่า ดู ตัวอย่างรูปธรรม
    • LLM ก็ไม่กำหนดแน่นอนเหมือนมนุษย์ ดังนั้นการดูแลความปลอดภัยก็ควรเข้าหาแบบเดียวกับมนุษย์ ให้สิทธิ์เท่าที่จำเป็นด้วยการควบคุมการเข้าถึงตามบทบาท และให้งานที่เสี่ยงหรือมีต้นทุนสูงต้องผ่านกระบวนการอนุมัติ สำหรับองค์กรสำคัญอย่างเทคโนโลยี โครงสร้างพื้นฐาน การป้องกันประเทศ การเงิน ฯลฯ การตั้ง threat model บนสมมติฐานว่ามีเจ้าหน้าที่จากรัฐบาลต่างชาติอย่างรัสเซีย จีน อิสราเอล เกาหลีเหนือ ฯลฯ ปะปนอยู่ในทีม ควรเป็นพื้นฐานอยู่แล้ว
    • ที่จริงสองบทความนี้คือบทความเดียวกัน ใน Economist จะมีซีรีส์บทความชื่อ “Leaders” อยู่ช่วงต้นฉบับรายสัปดาห์ ซึ่งเป็นการย่อและทำให้เป็นภาพรวมของบทความเชิงลึกที่อยู่ในฉบับเดียวกัน กล่าวได้ว่าเป็นการใช้โครงสร้างแบบพีระมิดกลับหัวกับทั้งฉบับหนังสือพิมพ์ (คำอธิบายพีระมิดกลับหัว) คราวนี้บทความที่ลิงก์มาก็ทำหน้าที่คล้ายฉบับสรุปของบทความปัญหาหลักนั้นเอง
    • ผมมองปัญหาความปลอดภัยของ LLM ว่าเป็นคำถามว่า “ถ้าโค้ดของฉันอาจโดน social engineering เจาะได้ล่ะ?” LLM ก็เหมือนมนุษย์ ตราบใดที่เป็นแบบนี้ ต่อให้ฝึกมาดีแค่ไหนก็ยังโดนหลอกได้อยู่ดี ถ้าคุณให้สิทธิ์ root กับคอมพิวเตอร์แล้วเปิดให้ใครก็ได้ทั่วโลกคุยกับ LLM สุดท้ายมันก็ต้องมีช่องโหว่ เช่นเดียวกับที่เราไม่มอบอำนาจไม่จำกัดให้มนุษย์ เราก็ไม่ควรอนุญาตให้ LLM เข้าถึงข้อมูลที่ไม่เกี่ยวกับผู้ร้องขอ หรือแก้ไขข้อมูลผู้ใช้ได้ตามใจ
    • ปัญหาคือแค่ตัด lethal trifecta ด้านเดียวก็พอ แต่ในความเป็นจริงองค์ประกอบทั้งสามนี้พันกันอยู่ เช่น คอนเทนต์ภายนอกอย่างอีเมลก็อาจเป็นข้อมูลส่วนตัวได้ และถ้าส่งอีเมลออกไป เนื้อหาในกล่องขาเข้าของฉันก็อาจรั่วไปถึงผู้โจมตีได้ อีกทั้งบริการอย่างอีเมลหรือ GitHub จะมีประโยชน์ที่สุดเมื่อทั้งรับและส่งได้ครบ การแยกเซิร์ฟเวอร์เฉพาะให้แต่ละหน้าที่จึงไม่มีประสิทธิภาพ
  • ในมุมของคนพื้นฐานวิศวกรรมเครื่องกล ผมรู้สึกว่าบทความนี้ยังไม่เพียงพอ คำพูดว่า “เพิ่มความแข็งแรงก็พอ” ได้ยินกันบ่อย แต่ในทางปฏิบัติต้องเข้าใจ failure mode หลายแบบอย่างละเอียดก่อนถึงจะใช้ได้ lethal trifecta ก็เป็นแค่หนึ่งใน failure mode แล้วจึงค่อยใส่ “ความแข็งแรง” เพื่อป้องกันมัน ไม่ใช่คิดว่า “สะพานนี้สั่นมากเกินไป → งั้นมาหาวิธีเดินข้ามสะพานสั่นๆ ให้ปลอดภัยกัน” แต่ควรเปลี่ยนสะพานไม่ให้สั่นเกินเหตุไปเลย
    • ผมรู้สึกว่าโลกมันบ้าไปแล้ว ถ้าจะใช้อุปมาสะพานนั้น ก็เหมือนเรามีเทคโนโลยีสร้างสะพานมานานแล้ว แต่บางครั้งพื้นสะพานกลับหายไปเฉยๆ คนตกลงแม่น้ำ แล้วแทนที่จะคุยกันเรื่อง “ลองหาวิธีอื่นกันเถอะ” เรากลับพูดกันว่า “ขึงตาข่ายข้างล่างไว้ แล้วถ้าทุกคนตกลงมาก็ค่อยจับ” เรากำลังทุ่มเงินนับพันล้านลงบนเทคโนโลยีที่คาดเดาไม่ได้โดยเนื้อแท้ แล้วก็แค่เพิ่ม guardrail เข้าไปอีกหน่อย มันไร้สาระจริงๆ
    • พอเห็นคำว่า “coders need to” ในบทความ ผมก็หมดความสนใจทันที อุปมาทั้งหมดดูผิดตั้งแต่ต้น และฟังดูแปลกแม้แต่กับคนที่ทำงานในสาขานั้นจริงๆ เงื่อนไขตัวอย่างที่นักข่าวยกมาว่า “ถ้าในบริษัทเปิดให้ LLM ทำได้ทั้งอ่านข้อมูลที่ไม่น่าเชื่อถือ เข้าถึงข้อมูลสำคัญ และสื่อสารกับภายนอกพร้อมกัน” นั่นแหละคือปัญหา บริษัทจำนวนมากสร้างความเสี่ยงนี้ขึ้นมาเองเพราะให้ความสำคัญกับฟีเจอร์มากกว่าความปลอดภัย ข้ออ้างว่า “LLM ไม่เป็นเชิงความน่าจะเป็นจึงใช้แนวทางเชิงกำหนดไม่ได้” เป็นการกระโดดข้ามเหตุผล แม้จะไม่กำหนดแน่นอน ตรรกะแบบ sandbox ก็ยังใช้ได้อยู่ และพูดอีกแบบคือ ถ้าฝืนลากอุปมาไปไกลเกินไป มันยิ่งไม่ช่วยวงการนั้น คงดีกว่าถ้าใช้ศัพท์และความรู้เฉพาะทางโดยตรง แต่ถ้าทำแบบนั้นก็คงไม่ดึงดูดในฐานะบทความข่าวเท่าไร
  • หรือว่าบทความนั้นเสนอเพียงการจำกัดความเร็วกับใช้โมเดลที่ดีกว่าเป็นทางแก้จริงๆ? วิศวกรซอฟต์แวร์ศึกษาของแบบนี้กันมาตั้งแต่หลายสิบปีก่อนแล้ว อุตสาหกรรมนี้รู้คำตอบเรื่องความปลอดภัยอยู่แล้ว ปัญหาคือท่าทีปัจจุบันที่เร่งรีบปล่อยผลิตภัณฑ์ AI มันไม่สอดคล้องกับสิ่งนั้น
    • ตอนนี้ AI ก็เป็นสาขา IT แบบเดียวกันแล้ว ถ้าอย่างนั้นข้อสรุปจริงๆ คือ “เราไม่ได้เข้าใจความปลอดภัย” การบอกว่า AI ประมาทจึงไม่ตรงกับข้อเท็จจริง การไม่มีวิธีแยก data token กับ instruction token ออกจากกันได้อย่างสมบูรณ์ เป็นข้อจำกัดเชิงรากฐาน ไม่ใช่เรื่องความสะเพร่า การพูดว่า “เรารู้หมดแล้วตั้งแต่หลายสิบปีก่อน” จึงฟังหยิ่งเกินไป
    • คำพูดทำนอง “เราแก้เรื่องความปลอดภัยได้หมดแล้วตั้งแต่หลายสิบปีก่อน” มักเกิดขึ้นตอนอุตสาหกรรมใหม่รีบสร้างมาตรฐานแย่ๆ แบบเดิมขึ้นมาอีกเพื่อปล่อย “ผลิตภัณฑ์ AI” แค่ดูกรณีอย่างมาตรฐาน MCP ที่มีช่องโหว่ตั้งแต่แรก ก็ทำให้แนวทางแบบ “เขียนพรอมป์ต์ให้ดี” ดูน่าขันแล้ว ปัญหาใหญ่ที่สุดคือแทบทุกคนในอุตสาหกรรม AI ออกแบบให้ MCP server เข้าถึง DB โดยตรงแบบไม่เอะใจเลย นี่เป็นตัวอย่างชัดว่าทำได้ ไม่ได้แปลว่าควรทำ และเพราะความปลอดภัยที่หละหลวมแบบนี้ ผลิตภัณฑ์ AI จำนวนมากจึงถูกเจาะจริงอยู่ทุกวันนี้
    • ข้ออ้างว่า “เราเข้าใจความปลอดภัยอยู่แล้ว” เอาเข้าจริงก็ไม่จริง ยิ่งเมื่อเป็นปัญหาเกี่ยวกับมนุษย์ก็ยิ่งใช่ ต่อให้ทุ่มเงินหลายพันล้านไปกับการฝึกซ้ำๆ ประสิทธิภาพก็ยิ่งลดลงเรื่อยๆ ช่วงหลังยังมีกรณีที่แม้แต่ผู้เชี่ยวชาญด้านความปลอดภัยระดับเก่งมากก็ยังโดนฟิชชิงง่ายๆ บน YouTube
  • โพสต์ต้นฉบับของ @simonw: The lethal trifecta for AI agents, และดู โพสต์เพิ่มเติมที่เกี่ยวข้อง ได้ด้วย ฝากลิงก์ การถกเถียงที่เกี่ยวข้องใน HN ไว้ด้วย
  • lethal trifecta คือปัญหาที่เกิดเมื่อ LLM ทำได้พร้อมกันทั้งเข้าถึงข้อมูลที่ไม่น่าเชื่อถือ เปิดดูข้อมูลสำคัญ และสื่อสารออกภายนอก ทางแก้คือจัดการขอบเขตสิทธิ์เพื่อลดความเสี่ยง ซึ่งเป็นความปลอดภัยระดับพื้นฐานมากๆ แบบ Security 101
    • ใช่ แต่ในทางปฏิบัติจะเกิดความตึงเครียดสูงระหว่างความปลอดภัยกับการใช้งาน ถ้าจะทำงานที่มีประโยชน์กับข้อมูลส่วนตัว ก็ย่อมเปิดช่องให้เกิดช่องโหว่ prompt injection อีกทั้งการรวมบริบทที่เกี่ยวข้องกันให้มากที่สุดก็ช่วยให้เอเจนต์มีประสิทธิภาพ แต่ถ้าแยก/กักเอเจนต์ที่อ่านอินพุตไม่น่าเชื่อถือออกจนหมด ประโยชน์ใช้งานก็จะลดลงแทน ดู บล็อกที่เกี่ยวข้อง
    • พูดให้เคร่งครัด นี่ก็เป็นแค่การควบคุมการเข้าถึง (Access Control) ขั้นพื้นฐานเท่านั้น ทันทีที่เชื่อมต่ออินเทอร์เน็ต ความเสี่ยงจะพุ่งสูงมาก ถ้ามีนักวิจัยความปลอดภัยที่เก่งจริง แค่ prompt injection เพียงครั้งเดียวก็อาจยึดทั้งระบบได้ ทำให้เงื่อนไขอย่างน้อยหนึ่งข้อสำเร็จทันที
  • LLM ไม่แยกระหว่าง prompt กับข้อมูล มันไม่มีแนวคิดแบบ NX bit (บิตห้ามรัน) และก็ยังไม่มีใครทำสิ่งที่คล้ายกันขึ้นมา แน่นอนว่าต่อให้มี NX bit ก็ไม่ได้หยุด remote code execution ได้สมบูรณ์อยู่ดี ดังที่เคยเห็นมาแล้ว ดังนั้นสิ่งนี้อย่างเดียวก็ไม่ใช่ทางแก้ครบถ้วน วิธีที่สมจริงที่สุดตอนนี้คือจัดการโปรเซสของ LLM agent ด้วยกลไกความปลอดภัยแบบเดิม เช่น รันด้วยบัญชีผู้ใช้แยกต่างหากเพื่อจำกัดการเข้าถึงไฟล์ และเพิ่มข้อจำกัดผ่านเครือข่าย ฮาร์ดแวร์ และ cgroups ด้วย ถึงอย่างนั้น หากมีคำสั่งแฝงอยู่ในข้อมูลที่ไม่น่าเชื่อถือ ก็ยังมีความเสี่ยงที่ LLM จะส่งข้อมูลลับออกไปอยู่ดี และหากผู้ใช้ไม่ทันสังเกตแล้วคัดลอกผลลัพธ์ของ LLM ออกไปภายนอก ช่องทางรั่วไหลก็จะเปิดขึ้นอีกครั้ง
    • พอมีคนบอกว่า “ยังไม่มีใครสร้างอะไรคล้ายแบบนี้” ผมก็สงสัยว่าจริงๆ แล้วมีใครเคยลองบ้างไหม หรืออย่างน้อยมีข้อมูลฝึกที่เกี่ยวข้องหรือเปล่า สัตว์สังคมจะทำ compartmentalization กันโดยธรรมชาติ แม้แต่สุนัขยังดูท่าทีคนแล้วซ่อนการมีอยู่ของอาหารได้ ผมเองตอนเลี้ยงลูกก็ต้องแยกจัดการข้อมูลทั้งหมดตามบริบท เช่น เรื่องสังคม ความรู้ที่เป็นความลับ ข้อมูลส่วนตัวของลูก ข้อมูลที่ลูกยังรับมือยาก ความคิดในใจของผมเอง และข้อมูลที่เรียนมาจากแหล่งที่ไม่น่าเชื่อถือ ความฉลาดก็สำคัญ แต่ wisdom ต่างหากที่ยังไม่ถูกยกเป็นประเด็นระดับหนึ่งในโลก LLM ตอนนี้ แม้แต่ลูกสุนัขและเด็กเล็กก็ยังนำหน้าเรื่องความสามารถในการแบ่งเขตข้อมูล
  • ผมเห็นประโยคอ้างอิงที่น่าสนใจในบทความเชิงลึกที่เกี่ยวข้อง: ระบบ CaMeL ที่ Google เสนอ ใช้ LLM สองตัวเพื่อหลีกเลี่ยงความเสี่ยงบางส่วนของ lethal trifecta ตัวหนึ่งเข้าถึงได้เฉพาะข้อมูลที่ไม่น่าเชื่อถือ อีกตัวจัดการข้อมูลอื่นทั้งหมด โมเดลที่เชื่อถือได้จะแปลงคำสั่งภาษาของผู้ใช้เป็นโค้ดในขอบเขตจำกัด ส่วนโมเดลที่รับข้อมูลไม่น่าเชื่อถือจะคอยเติมช่องว่างในโค้ดนั้น สถาปัตยกรรมนี้ให้หลักประกันด้านความปลอดภัย แต่ก็แลกมาด้วยข้อจำกัดอย่างมากต่อขอบเขตงานที่ LLM ทำได้ ผมเพิ่งเคยได้ยินเรื่องนี้และสงสัยว่ามันได้ผลแค่ไหน รับประกันความปลอดภัยแบบ “เด็ดขาด” ได้จริงหรือไม่ มีข้อจำกัดอะไรบ้าง และจะเป็นทางเลือกที่ใช้งานได้จริงไหม ที่มาบทความ
    • ผมเคยคิดเรื่องบทความวิจัย CaMeL นี้อยู่นานพอสมควร มันเป็นแนวทางที่ค่อนข้างดี แต่ทำจริงยากมาก และระบบก็ทำงานได้แค่ในขอบเขตที่จำกัดพอสมควร ผมสรุปไว้ใน บทวิเคราะห์ของผม
  • มีอุปมาว่า “วิศวกร AI ก็ต้องคิดเหมือนวิศวกรจริงในสาขาอย่างการสร้างสะพาน ที่ความผิดพลาดอาจทำให้มีคนตายได้” พร้อมแนวคิดทำนองว่า “วิศวกร AI ถูกหล่อหลอมมาตั้งแต่สมัยเรียนให้เชื่อว่า แค่มีข้อมูลฝึกมากขึ้นและพรอมป์ต์ที่ฉลาดขึ้นก็แก้ปัญหาได้”
    • คำว่า “วิศวกร AI ต้องคิดเหมือนวิศวกรจริง” ตรงนี้หมายถึงไม่ใช่แค่วิศวกรซอฟต์แวร์ แต่เป็นวิศวกรจริงๆ เพราะตอนนี้ซอฟต์แวร์ก็อยู่ในสะพานและรถยนต์แล้ว อย่างน้อยจึงควรมีวิธีคิดแบบวิศวกรของโลกกายภาพ
    • มันชวนให้นึกถึงข้อเสนอว่าควรต้องมีใบอนุญาตวิศวกรรมซอฟต์แวร์ หรือการรับรองจริยธรรมด้วยซ้ำ แต่เพราะซอฟต์แวร์ที่ไร้จริยธรรมแต่ถูกกฎหมายสามารถสร้างกำไรมหาศาลได้ ผมจึงรู้สึกว่าไอเดียแบบนี้ยากจะนำไปใช้จริง
    • ถ้าคิดว่า “ขอแค่มีข้อมูลฝึกที่ดีกว่านี้ก็แก้ได้” บทสรุปก็คือ สุดท้ายโศกนาฏกรรมเหล่านี้เองจะกลายเป็นข้อมูลฝึก
    • อย่าลืมบทบาทของ “สถาปนิก” ควบคู่กับ “วิศวกร” ซอฟต์แวร์ด้วย
  • ผมคิดว่าน่าจะมีโอกาสทางธุรกิจ ถ้าทำซอฟต์แวร์สำหรับมอนิเตอร์บัญชี LLM แบบอัตโนมัติ พร้อมกรองอินพุต/ทำ pipeline ให้ แล้วขายเป็นบริการสมัครสมาชิกในราคาพอเหมาะ