LLM ทำให้เอกสารถูกบิดเบือนเมื่อมอบหมายงานให้จัดการ

 (arxiv.org)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • DELEGATE-52 เป็นเบนช์มาร์กที่ใช้ประเมินว่าเอกสารถูกคงสภาพไว้อย่างซื่อตรงเพียงใดในเวิร์กโฟลว์แบบมอบหมายงาน ซึ่งผู้ใช้ฝากงานแก้ไขเอกสารขนาดยาวให้ LLM จัดการ
  • เบนช์มาร์กนี้ครอบคลุมงานที่ต้องแก้ไขเอกสารเชิงลึกใน 52 สาขาเฉพาะทาง เช่น การเขียนโค้ด ผลึกวิทยา และการเขียนโน้ตดนตรี โดยตัวอย่างการจำลองประกอบด้วยการมอบหมาย 20 งานต่อเนื่อง
  • จากการทดลองกับ LLM 19 รุ่น แม้แต่โมเดลระดับแนวหน้าอย่าง Gemini 3.1 Pro, Claude 4.6 Opus และ GPT 5.4 ก็ยังทำให้เนื้อหาเอกสารถูกบิดเบือนโดยเฉลี่ย 25% เมื่อจบเวิร์กโฟลว์ระยะยาว
  • ความเสียหายของเอกสารปรากฏเป็นข้อผิดพลาดที่พบไม่บ่อยแต่รุนแรง และยิ่ง ขนาดเอกสาร ใหญ่ขึ้น ความยาวของปฏิสัมพันธ์ มากขึ้น รวมถึงมีไฟล์รบกวนเพิ่มขึ้น การเสื่อมก็ยิ่งมากขึ้น อีกทั้งการใช้เครื่องมือแบบเอเจนต์ก็ไม่ได้ช่วยให้ประสิทธิภาพดีขึ้น
  • ปัจจุบัน LLM ยังยากจะมองว่าเป็นตัวแทนที่เชื่อถือได้สำหรับการแก้ไขเอกสารแบบมอบหมายงาน และมีการเปิดเผยข้อมูลที่เกี่ยวข้องกับ DELEGATE-52 ผ่าน microsoft/DELEGATE52 และ datasets/microsoft/DELEGATE52

รูปแบบความล้มเหลวของการแก้ไขแบบมอบหมายงาน

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

การเปลี่ยนแปลงของเอกสารที่ยกเป็นตัวอย่าง

  • เอกสาร Linux Kernel Architecture ในหมวด Graph Diagrams แสดงผลใน Gemini 3.1 Pro ว่าเมื่อเทียบกับต้นฉบับจะเหลือ 79% หลัง 4 ครั้ง, 49% หลัง 10 ครั้ง, 48% หลัง 14 ครั้ง และ 48% หลัง 20 ครั้ง
  • เอกสาร 12-Shaft Twill Diamond ในหมวด Textile Patterns แสดงผลใน Claude 4.6 Opus ว่าเมื่อเทียบกับต้นฉบับจะเหลือ 100% หลัง 4 ครั้ง, 40% หลัง 10 ครั้ง, 27% หลัง 14 ครั้ง และ 34% หลัง 20 ครั้ง
  • เอกสาร ActionBoy Palm Tree ในหมวด 3D Objects แสดงผลใน GPT-5.2 ว่าเมื่อเทียบกับต้นฉบับจะเหลือ 100% หลัง 4 ครั้ง, 31% หลัง 10 ครั้ง, 15% หลัง 14 ครั้ง และ 6% หลัง 20 ครั้ง

ข้อมูลที่เปิดเผย

  • microsoft/DELEGATE52
  • datasets/microsoft/DELEGATE52

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

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

 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • ยังสงสัยผลลัพธ์ของการใช้เครื่องมือ

    ถ้าเอาข้อความยาว ๆ ส่งผ่าน LLM ไปกลับหลายรอบแล้วมันเสียหาย ก็ไม่ใช่เรื่องน่าแปลกใจ คนที่ใช้ LLM บ่อย ๆ รู้กันอยู่แล้วว่าไม่ควรทำแบบนั้น

    ที่น่าแปลกใจในงานวิจัยคือเขาบอกว่าการใช้เครื่องมือไม่ได้ช่วย แต่ในขณะเดียวกันก็ระบุว่าพวกเขาแค่ทำ “agent harness แบบพื้นฐาน” และไม่ใช่ระบบที่ปรับแต่งตามแนวทางล่าสุด

    จริง ๆ แล้ว harness มีแค่ read_file() กับ write_file() เท่านั้น เลยแทบจะเป็นแค่ การเพิ่มอีกหนึ่งขั้นในกระบวนการส่งข้อความไปกลับ มากกว่า ทุกวันนี้ harness ของ coding agent ลงแรงกับการออกแบบเครื่องมือแก้ไขไฟล์กันมาก เช่นชุดเครื่องมือแก้ไขของ Claude: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

    คำสั่ง str_replace และ insert เป็นหัวใจสำคัญในการหลีกเลี่ยงการแก้ไขแบบเสี่ยงที่ต้องเขียนไฟล์ทั้งไฟล์ใหม่

    อย่างน้อยพวกเขาก็มีเครื่องมือ run_python() ให้ใช้ ดังนั้นโมเดลที่ดีกว่าน่าจะใช้มันเพื่อทำ string replacement ได้ อยากเห็นว่าระบบพรอมป์ตแนะนำให้จัดการด้วย Python หรือชี้นำให้มันอ่านไฟล์แล้วเขียนกลับใหม่

    โค้ดของ harness อยู่ที่นี่: https://github.com/microsoft/delegate52/blob/main/model_agen...

    ส่วนหนึ่งของพรอมป์ตที่เกี่ยวข้องคือ “สามารถเลือกวิธีที่คิดว่ามีประสิทธิภาพที่สุดได้ ไม่ว่าจะเป็นการเขียนแบบโปรแกรมหรือเขียนไฟล์โดยตรง”

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

    • เห็นด้วยเกือบทั้งหมด ยกเว้นตรงที่บอกว่า “คนที่ใช้ LLM บ่อย ๆ รู้กันอยู่แล้วว่าไม่ควรทำแบบนั้น”

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

      สำหรับคนพวกนั้น พฤติกรรมแบบที่พูดถึงตรงนี้เป็นปัญหาใหญ่

    • พอเกี่ยวกันนิดหน่อย แต่อยากเห็น harness ที่ใช้ ed เป็นเครื่องมือหลักสำหรับแก้ไข/อ่านไฟล์ ครึ่งหนึ่งของ bash ที่ Claude รันก็หน้าตาเหมือน sed อยู่แล้ว ถ้า ed มีสถานะคงอยู่ก็น่าจะช่วยได้

      จะทำยังไงเวลา editor เต็มรูปแบบกินแบนด์วิดท์^Hโทเค็นมากเกินไป? ก็ใช้ ed ซึ่งเป็น editor มาตรฐานไง

    • อันนี้ค่อนข้างเหมือนการสร้างภาพฟางให้กับงาน LLM

      สำหรับงานแก้ไข ควรอนุญาตแค่ คำสั่งแก้ไขแบบเป็นโปรแกรม เท่านั้น และไม่ควรให้ข้อความไหลผ่าน LLM ตัว LLM ควรทำหน้าที่วิเคราะห์ข้อความ แล้วส่งออกคำสั่งเพื่อบรรลุเป้าหมายตาม feedback

    • ใน HN มีแนวโน้มจะตีความผลลัพธ์ในแง่ลบที่สุดเท่าที่จะทำได้ เพราะรู้สึกว่ามันคุกคามทั้งงานและอัตลักษณ์ของตัวเอง

      เอาจริง ๆ ถ้าให้คนอ่านเอกสารแล้วแก้ไขด้วยการพูดทั้งเอกสารใหม่ทั้งหมดหลังใส่การเปลี่ยนแปลงเข้าไป มนุษย์ก็อาจทำได้แย่กว่าเสื่อมลง 25% เสียอีก มนุษย์จะทำให้เสื่อมลง 0% ได้ก็จริง แต่ต้องอยู่ในสภาวะที่รับข้อความเดิมเข้าไปหลายร้อยครั้งจน ท่องจำ ได้ สำหรับ LLM สิ่งที่เทียบกันได้ก็คือการฝึก และถ้าฝึกเอกสารนั้นเข้าไปใน LLM ก็อาจเทียบได้กับการแก้ไขของคนที่ท่องจำเอกสารมา

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

    • ไม่ว่าจะเพราะข้อจำกัดด้านทรัพยากรหรือเพราะต้องการทำให้ง่าย วิธีวิทยาที่เข้าใจยากแบบนี้ทำให้งานวิจัยแนวนี้น่าเสียดายที่มูลค่าลดลง

  • อย่างที่พูดมานานแล้ว ข้อความอะไรก็ตามที่ เอา AI มาเคลือบทับ คุณภาพจะลดลง และยิ่งทำซ้ำก็ยิ่งสะสม

    คำที่ผมชอบใช้เรียกเรื่องนี้คือ “semantic ablation”: https://www.theregister.com/software/2026/02/16/semantic-abl...

    • ผมเรียกมันว่า การถดถอยกลับสู่สติปัญญาเฉลี่ย มาตลอด
    • สงสัยว่าคำว่า “ยิ่งทำซ้ำ” หมายถึงทำซ้ำใน session เดียวกัน หรือทุกครั้งเป็น session ใหม่หรือ context window ใหม่

  • ใจความคือ “การมอบหมายงานต้องอาศัยความไว้วางใจ ต้องคาดหวังได้ว่า LLM จะทำงานตามหน้าที่โดยไม่ใส่ข้อผิดพลาดลงไปในเอกสาร” และนี่แหละคือเหตุผลที่ harness แบบใช้ไฟล์ Markdown หลายสิบไฟล์กับพิธีกรรมพรอมป์ตไม่ได้ทำงานดีอย่างที่โฆษณาไว้ จริง ๆ แล้วมันแทบจะเป็นลัทธิเทียมภายใต้ชื่อ agent engineering

    agent engineering เองสุดท้ายก็แทบไม่ต่างจากสิ่งที่เรียกว่า prompt engineering เท่าไรนัก แค่ตอนนี้พรอมป์ตไปกระจายอยู่ตามไฟล์ Markdown และไดเรกทอรีหลายสิบแห่งเท่านั้น

  • นี่เป็นเรื่องเกี่ยวกับ LLM ที่อ่านมาไม่น่าประหลาดใจน้อยที่สุดในช่วงหลัง

    LLM คล้ายมีม JPEG เวลาบันทึกเป็น JPEG ซ้ำ ๆ คุณภาพจะลดลงทีละนิดจนสุดท้ายจำไม่ได้ มันทำงานคล้ายกัน

    เพียงแต่สำหรับ LLM จุดเริ่มต้นคือ เจตนา ทุกครั้งที่ผ่าน LLM เจตนาจะค่อย ๆ เสื่อมลง และในกรณีอย่างบทความวิทยาศาสตร์ที่ต้องการความแม่นยำสูง ความละเอียดอ่อนและความเที่ยงตรงจะค่อย ๆ หายไประหว่างการเรียบเรียงใหม่

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

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

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

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

    • กรณีที่ผลนี้น่าสนใจและเกี่ยวข้องจริง ๆ คือเวลาที่ coding agent แยก source file ใหญ่หนึ่งไฟล์ออกเป็นหลายไฟล์เล็ก Opus และ Claude Code มีแนวโน้มจะพยายามท่องช่วงโค้ดยาว ๆ จากความจำแล้วใส่ลงไฟล์ใหม่ แทนที่จะใช้การคัดลอก/วางแบบที่มนุษย์ทำ

      การย้ายไฟล์ง่ายกว่านิดหน่อย ถึง LLM จะพยายามพูดไฟล์นั้นใหม่จากความจำบ้างเป็นครั้งคราว แต่ถ้าสั่งให้ใช้ git mv แล้วไปแก้ compiler error มักจะทำได้ดีพอสมควร

      ในทางกลับกัน งานแก้ไขทั่วไปมักทำงานได้ดีอยู่แล้วถ้ามีโมเดลและชุดเครื่องมือที่สมเหตุสมผล แม้แต่ Qwen3.6 27B ก็ยังโอเคระดับนี้ และการแก้ไขแบบอยู่กับที่ก็สามารถใช้ git diff ตรวจดูการเปลี่ยนแปลงที่ไม่คาดคิดได้

    • มีเกมเด็กที่สาธิตเรื่องนี้ได้เหมือนกัน: https://en.wikipedia.org/wiki/Telephone_game

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

      มันคล้ายกับฟังคนที่ดื่มมาสองสามแก้วเล่าข้อมูลออนไลน์ที่เขาบอกว่าเคยเห็นมา อาจถูกก็ได้ แต่อาจผิดก็มีความเสี่ยงสูงพอตัว

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

      เคยเห็นเพื่อนร่วมงานให้ LLM สรุปข้อมูลสำคัญที่มาจาก API แล้วรายงานก็พลาดหนักพอ ๆ กับครั้งที่มันถูกต้อง ซึ่งขึ้นกับว่าคุณกำลังดูอะไรอยู่ เรื่องนี้อาจกลายเป็นความเสี่ยงระดับหายนะได้

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

      แน่นอนว่าผมไม่ได้ใช้ผลลัพธ์นั้น แต่สิ่งที่น่าหงุดหงิดมากคือ LLM ยังยืนกรานว่ามันดีกว่าของเดิม

      LLM มีประโยชน์กว่ามากถ้าใช้กับชิ้นเล็ก ๆ เช่นขอให้ช่วยแก้เพียงหนึ่งประโยคหรือสามประโยค มากกว่าจะให้มันกำหนดทิศทางทั้งเรซูเม่

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

    • ใครก็ตามที่พยายามทำอะไรซับซ้อนเกินนิดหน่อยจะเห็นชัดเลย ถ้าสร้าง pipeline ที่รวม pre-processing flow, semantic targeting และการดึงบริบทเท่าที่จำเป็นเข้ากับ LLM API คุณจะได้ขั้นตอนอัตโนมัติที่ทรงพลัง

      พอรวมกับขั้นตอนตรวจสอบแยกต่างหาก LLM ก็จะเปลี่ยนจากของเล่นเป็นเครื่องมือที่ใช้งานได้จริง

    • ถ้ายังมีมนุษย์เข้าไปอยู่ในวงจรซ้ำระดับนี้ มันก็ยังไม่ใช่กระบวนการอัตโนมัติจริง ๆ

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

    วิธีที่ใช้แล้วเวิร์กจริงคือให้ agent มีไดเรกทอรีหนึ่ง แล้วสำหรับข้อเท็จจริงหรือสิ่งค้นพบแต่ละอย่างที่เจอ ให้สร้างไฟล์ Markdown แยกอิสระ พร้อม metadata ด้านหน้าเพื่อให้ค้นหาได้ง่าย

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

    มันไม่ใช่คำตอบสมบูรณ์ แต่เหมือนเวลามนุษย์ทำงานคือช่วยให้สิ่งที่ค้นพบถูกนำกลับมาใช้ซ้ำได้ดีขึ้น

  • เรื่องนี้ใช้กับมนุษย์ด้วยไม่ใช่เหรอ? ก็เลยมีเกม “กระซิบส่งสาร” ของเด็ก ๆ ให้เห็นว่าข้อความเสียหายได้อย่างไร ทางแก้คือมี single source of truth

  • กำลังสร้างเครื่องมือไว้ต่อสู้กับการเสื่อมสภาพแบบนี้อยู่: https://github.com/JigSpec/JigSpec

  • ชอบวิธีประเมินตรงนี้มาก เป็นการทดสอบ ความซื่อตรงต่อข้อมูลต้นฉบับ โดยให้ชุดของขั้นตอนที่ย้อนกลับได้วิ่งไปกลับหลายรอบ

    น่าประทับใจที่แม้ในงานซึ่งดูเผิน ๆ เหมือนคอมพิวเตอร์น่าจะจัดการได้ง่าย โมเดลระดับแนวหน้าก็ยังสะสมข้อผิดพลาด

    สงสัยว่าผลที่แข็งแรงกว่าใน Python เป็นเพียงผลของ benchmark ที่เฉพาะทางกับ Python หรือจะขยายไปยังภาษาทั่วไปอื่น ๆ ที่ใช้กันบ่อยได้ด้วย และเกี่ยวข้องกับองค์ประกอบเฉพาะบางอย่างของกระบวนการฝึกหรือไม่

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

    เช่นเดียวกัน การเสื่อมของโมเดลที่อ่อนกว่ามักมาจากการลบเนื้อหา ส่วนการเสื่อมของโมเดลระดับแนวหน้ามักมาจากการบิดเบือนเนื้อหา นี่จึงเป็นเหตุผลที่เราคอยปรับแต่งพวก harness, temperature และอย่างอื่นไปมา