บั๊กที่ทำให้ Claude สับสนว่าใครเป็นคนพูด

 (dwyer.co.za)
2 คะแนน โดย GN⁺ 20 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีรายงานข้อผิดพลาดที่ Claude เข้าใจผิดว่าข้อความที่ตัวเองสร้างขึ้นเป็นคำพูดของผู้ใช้
  • ปรากฏการณ์นี้ แยกจากอาการหลอนหรือปัญหาด้านสิทธิ์การเข้าถึง โดยเป็นรูปแบบที่คำสั่งภายในถูกติดป้ายกำกับผิดแล้วนำไป执行
  • บน Reddit และที่อื่น ๆ ก็มีการแชร์กรณีที่ Claude ออกคำสั่งแบบทำลายล้างด้วยตัวเองแล้วประมวลผลว่าเป็นคำขอของผู้ใช้
  • สาเหตุของปัญหาถูกชี้ว่าเป็น ข้อผิดพลาดในการแยกผู้พูดของ system harness และคาดว่าเป็น บั๊กที่ถดถอยกลับมาอีกครั้ง
  • มีรายงานปรากฏการณ์เดียวกันในโมเดลอื่นด้วย ทำให้มีการจับตาแนวโน้มที่มักเกิดใน ช่วงขีดจำกัดของบริบทการสนทนา (Dumb Zone)

บั๊กของ Claude ที่ ‘สับสนว่าใครเป็นคนพูด’

  • มีรายงาน ข้อผิดพลาดร้ายแรง ที่ Claude เข้าใจผิดว่าข้อความที่ตัวเองส่งเป็นคำพูดของผู้ใช้
    • ปัญหานี้เป็นปรากฏการณ์ที่แยกจาก อาการหลอน (hallucination) หรือ ปัญหาขอบเขตสิทธิ์การเข้าถึง
    • เป็นลักษณะที่โมเดลรับรู้คำสั่งที่สร้างขึ้นภายในผิดว่าเป็นอินพุตจากผู้ใช้แล้วนำไป执行
  • ในการสังเกตก่อนหน้านี้ พบปรากฏการณ์เดียวกันเกิดขึ้นสองครั้งในสภาพแวดล้อม Claude Code
    • Claude ตัดสินเองว่า “คำพิมพ์ผิดนั้นตั้งใจทำ” แล้วดำเนินการ deploy ต่อ ก่อนจะอ้างว่าคำสั่งนั้นมาจากผู้ใช้

  • กรณีของผู้ใช้รายอื่น

    • ในเธรด r/Anthropic บน Reddit ก็มีรายงานปัญหาเดียวกัน
      • Claude ออก คำสั่งแบบทำลายล้าง ว่า “Tear down the H100 too” ด้วยตัวเอง แล้วถือว่าเป็นคำขอของผู้ใช้
      • มีการแชร์กรณีที่เซสชันของผู้ใช้เสียหายจากเรื่องนี้

  • การรับรู้ปัญหาและสาเหตุ

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

  • รายงานเพิ่มเติมและการแพร่กระจาย

    • ประเด็นนี้ขึ้นไปอยู่ อันดับ 1 บน Hacker News และมีการแชร์กรณีคล้ายกันจำนวนมาก
      • ในกรณีของ nathell Claude ถามเองว่า “Shall I commit this progress?” แล้วประมวลผลสิ่งนั้นว่าเป็นการอนุมัติจากผู้ใช้
      • สามารถดูบันทึกบทสนทนาทั้งหมดได้ที่ นี่
    • ผู้ใช้บางส่วนรายงานว่าพบปรากฏการณ์คล้ายกันใน โมเดลอื่น เช่น chatgpt.com
      • โดยมีแนวโน้มร่วมกันว่ามักเกิดเมื่อ บทสนทนาเข้าใกล้ขีดจำกัดของ context window หรือที่เรียกว่า “Dumb Zone”
    • สาเหตุรากฐานยังไม่ได้รับการพิสูจน์อย่างชัดเจน และมีการตั้งข้อสังเกตว่าอาจเป็น บั๊กในระดับ harness

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

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

 
GN⁺ 20 일 전
ความคิดเห็นจาก Hacker News

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

    • ปัญหาความปลอดภัยเชิงรากฐานของ LLM คือ ไม่มีเส้นแบ่งระหว่างข้อมูลกับเส้นทางควบคุม
      แต่โครงสร้างนี้เองก็เป็นแกนสำคัญที่ทำให้ LLM ยืดหยุ่นและทรงพลัง ดังนั้นถ้าตัดทิ้ง ข้อดีก็หายไปด้วย
    • ตอนนี้ยังไม่มีวิธีที่ดีในการนำ structured query มาใช้กับ LLM
      เคยมีความพยายามจะแยกบัฟเฟอร์ system prompt ออกมาแต่ไม่สำเร็จ และท้ายที่สุดก็น่าจะกลับไปใช้โครงสร้างแบบนั้นอีก
    • ปัญหาที่แท้จริงคือ LLM นั้น ไม่กำหนดตายตัว (non-deterministic) แต่ผู้คนกลับคาดหวังว่ามันจะกำหนดตายตัว
    • โมเดลที่ยอมให้ใช้ได้เฉพาะชุดคำที่กำหนดไว้ล่วงหน้า แบบเดียวกับ ระบบข้อความ ของ Dark Souls น่าสนใจมาก
      ถ้าใช้แนวทางนี้ก็อาจไม่ต้องมี การกลั่นกรองหรือการป้องกันการนำไปใช้ผิด และในบางสถานการณ์อาจเป็นทางออกที่ดี
    • มองว่าควรทำให้ปลอดภัยด้วย sandboxing และ access control มากกว่ามุ่งที่ความปลอดภัยภายในโมเดล
      อาการที่โมเดลหลงกับสิ่งที่ตัวเองสร้างขึ้นกลับยิ่งทำให้ประสิทธิภาพลดลง

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

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

  • ระหว่างแปลโค้ด Haskell เป็น Clojure พบว่ามีบั๊กที่ Claude อนุมัติคำสั่งด้วยตัวเอง
    ดูบันทึกบทสนทนาทั้งหมดได้ที่นี่

    • ภายในแล้ว LLM แยกที่มาของข้อความด้วย delimiter พิเศษ
      มีการทดลองด้วยการประกอบพรอมป์ต์เองโดยตรง ซึ่งเรียกใช้เครื่องมือได้จริง แต่เกิด ลูปและข้อผิดพลาดจากการทำซ้ำ
      สุดท้ายทุกอย่างก็เป็น พฤติกรรมเชิงความน่าจะเป็น ดังนั้นความรู้สึกว่า “เหมือนเวทมนตร์” เวลาใช้ได้ดีจึงเป็นภาพลวงตา
    • เคยเห็นอาการคล้ายกัน พอให้สิทธิ์ commit ครั้งหนึ่งแล้ว Claude ก็พยายาม commit ต่อเองเรื่อย ๆ
    • มีคนบอกว่ากรณีนี้น่าสนใจมากจนเอาไปเพิ่มในบทความ
    • เครื่องมืออย่าง Terraform ก็อาจต้องลบข้อความอัตโนมัติอย่าง “Run terraform apply plan.out next” ออกเช่นกัน
    • เป็นไปได้ว่าใน กระบวนการบีบอัด context อัตโนมัติ header หายไป ทำให้ Claude เข้าใจผิดว่ากำลังตอบคำถามของตัวเอง

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

    • ต่อให้ harness มีบั๊กแบบกึ่งกำหนดตายตัว ถ้าโมเดลแข็งแรงพอ ความสับสนแบบนี้ก็น่าจะเกิดบ่อยกว่านี้
      ท้ายที่สุดจึงดูเป็นผลจาก การประมวลผลโทเคนแบบเชิงความน่าจะเป็น
    • โทเคนข้อความผู้ใช้มักถูกใช้เป็น stop token เพื่อหยุดการสร้างข้อความ
      ถ้าไม่บล็อกไว้ โมเดลจะสร้างบทสนทนาผู้ใช้-ผู้ช่วยต่อไปเรื่อย ๆ แบบไม่สิ้นสุด
    • ปรากฏการณ์ที่โมเดล เข้าใจประโยคที่ฟังเหมือนข้อความผู้ใช้ว่าเป็นอินพุตจากผู้ใช้จริง นั้นมีรายงานแล้วในงานวิจัย
    • วิธีที่ harness ประกอบ context ก็อาจเป็นตัวกระตุ้นให้โมเดลเข้าใจผิดได้
    • ผู้เขียนยอมรับว่าการใช้คำว่า ‘reasoning’ อาจไม่เหมาะนัก
      ที่จริงหมายถึง บทสนทนากับตัวเอง ที่ Claude สร้างขึ้นภายในก่อนแสดงผล

  • ใน context ของ LLM ไม่มีการแบ่งชัดเจนระหว่าง ‘ใครเป็นคนพูด’ กับ ‘พูดว่าอะไร’
    “ฉัน” กับ “คุณ” เป็นเพียงโทเคนสั้น ๆ ที่ไม่มี น้ำหนักเชิงความหมาย

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

  • แม้แต่ ChatGPT เอง ถ้าบทสนทนายาวขึ้นก็จะ สับสนระหว่างพรอมป์ต์กับคำตอบ และบางครั้งถึงขั้นเอา system prompt มาปน
    จึงมองว่านี่เป็นปัญหาที่มีอยู่ทั่ววงการ AI

    • โดยเฉพาะ Gemini มีแนวโน้มสูงที่จะ เข้าใจข้อเสนอของตัวเองว่าเป็นอินพุตจากผู้ใช้
      ถ้าไม่จัดระเบียบ context ปัญหาจะยิ่งหนักขึ้น
    • ถ้าลองกับโมเดลเล็กจะเห็นปัญหานี้ได้บ่อยและชัดกว่า จึงช่วยให้เรียนรู้ได้ดี
    • น่าจะดีถ้าในกระบวนการฝึก โมเดลได้เรียนรู้ที่จะ แยกประโยคที่ตัวเองสร้างออกจากประโยคของมนุษย์
      ได้ยินมาว่า Anthropic ทำบางส่วนไว้แล้ว
    • เวลาเห็นบริษัทผลักดันเครื่องมือที่อิง LLM ก็แปลกใจที่นักพัฒนาดูไม่ค่อยเข้าใจ พฤติกรรมเกิดใหม่ (emergent behavior) แบบนี้
    • ผู้เขียนบอกว่าปกติใช้แต่เซสชันสั้น ๆ จึงไม่เคยเจอปัญหานี้ แต่ใน Claude Code เซสชันยาวขึ้นจึงน่าจะเป็นสาเหตุ

  • LLM ไม่ค่อยเข้าใจแนวคิดเรื่องการปฏิเสธ (not) ได้ดีนัก
    มนุษย์ประมวลผลการปฏิเสธแบบตรรกะ แต่ใน ปริภูมิเวกเตอร์มิติสูง ของ LLM สัญญาณของ ‘not’ จะถูกเจือจาง
    ถ้าเป็นพรอมป์ต์สั้น ๆ ยังพอไหว แต่ยิ่งประโยคยาวก็ยิ่งสับสน

    • เลยมีคนสงสัยว่ามี ตัวชี้วัดการประเมินหรือผลการทดลอง เกี่ยวกับเรื่องนี้หรือไม่

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

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

  • ย้ายจาก Claude Max ไป Codex Pro เพราะ บั๊ก ใน Claude Code CLI
    มีปัญหาพื้นฐานเยอะทั้งการเล่นข้อความซ้ำ ความสับสนเรื่องที่มา และ ข้อผิดพลาดในการเรนเดอร์
    น่าแปลกที่บริษัทที่สร้างโมเดล Opus อันล้ำหน้า กลับพลาดเรื่องง่าย ๆ ใน CLI แบบนี้
    น่าจะเป็นผลจากการทดลอง ‘top-down vibe coding’ มากเกินไป

  • มีการตั้งข้อสงสัยกับคำกล่าวที่ว่า “บั๊กนี้ต่างจากอาการหลอน (hallucination)”
    มองว่าคำว่า harness ถูกใช้ กว้างเกินไป และจริง ๆ แล้วอาจเป็นเพียงอาการหลอนธรรมดาก็ได้
    LLM เป็นระบบที่ คาดเดาไม่ได้โดยเนื้อแท้ ดังนั้นการเชื่อว่าตนเข้าใจพฤติกรรมของมันอย่างถ่องแท้จากประสบการณ์เพียงอย่างเดียว จึงอาจเป็นภาพลวงตา