Context Rot: เมื่อโทเค็นอินพุตมากขึ้น ประสิทธิภาพของ LLM เปลี่ยนไปอย่างไร

• แม้ว่า ขีดจำกัดโทเค็นอินพุต (context window) ของ LLM รุ่นใหม่จะขยายไปถึงระดับหลายล้านโทเค็นแล้ว แต่แม้จะได้คะแนนสูงในเบนช์มาร์กการค้นหาแบบง่าย (Needle in a Haystack, NIAH) ก็ยัง พบการเสื่อมลงของประสิทธิภาพอย่างชัดเจนเมื่อใช้อินพุตยาวจริง
• นักวิจัยทำการทดลองหลากหลายรูปแบบกับ โมเดล 18 รุ่น และพบซ้ำ ๆ ว่าแม้จะควบคุมให้เปลี่ยนแค่ความยาวอินพุต ก็ยังเกิด ประสิทธิภาพที่ลดลงและรูปแบบที่ไม่สม่ำเสมอ
• ปรากฏการณ์ที่เด่นชัดคือ เมื่อ ความคล้ายกันระหว่างคำถามกับคำตอบลดลง, มีการ เพิ่มประโยครบกวน (distractor) หรือเกิด การเปลี่ยนแปลงโครงสร้างของข้อความต้นทาง อัตราการเสื่อมของประสิทธิภาพจะยิ่งเร็วขึ้นหรือเปลี่ยนไปแบบคาดเดาไม่ได้
• แม้แต่การ คงบริบทเชิงโครงสร้างไว้ (ลำดับย่อหน้าที่ไหลตามตรรกะ) ก็กลับส่งผลลบต่อประสิทธิภาพได้ สะท้อนว่าการจัดเรียงและวิธีป้อนข้อมูลมีผลอย่างมากต่อประสิทธิภาพของ LLM
• แม้แต่งานที่ง่ายมากอย่างการคัดลอกข้อความซ้ำ ๆ ก็ยังเผยให้เห็นข้อจำกัดว่า เมื่อความยาวอินพุตเพิ่มขึ้น โมเดลไม่สามารถให้ผลลัพธ์ที่สม่ำเสมอได้ จึงย้ำความสำคัญของ การออกแบบบริบท (context engineering) ในการใช้งานจริง

---

ที่มาและวัตถุประสงค์ของงานวิจัย

• ช่วงหลังมานี้ context window ของ LLM ขยายไปถึง 1–10 ล้านโทเค็น ทำให้เกิดความเชื่อแพร่หลายว่า “ประสิทธิภาพยังคงรับประกันได้” แม้ใช้อินพุตยาว
  • ตัวอย่างที่เด่นคือ Gemini 1.5 Pro, GPT-4.1, Llama 4
• เบนช์มาร์กที่ใช้กันอย่างแพร่หลายอย่าง Needle in a Haystack (NIAH) เป็นเพียงการค้นหาประโยคอย่างง่าย จึง ไม่สามารถสะท้อนการเสื่อมของประสิทธิภาพได้อย่างเหมาะสม ในงานที่ซับซ้อนจริง เช่น การสรุปเอกสารยาวหรือถาม-ตอบจากข้อความยาว
• งานวิจัยนี้จึงตรวจสอบการเปลี่ยนแปลงของประสิทธิภาพอย่างเป็นระบบ ด้วยวิธี ปรับเฉพาะความยาวอินพุตโดยคงระดับความยากของงานไว้เท่าเดิม

การทดลองหลักและผลลัพธ์

• ออกแบบการทดลองทั้งหมด 4 แบบกับ LLM รุ่นใหม่ 18 รุ่น (Anthropic Claude, OpenAI GPT-4.1/4o/3.5, Gemini, Qwen ฯลฯ):
  • การเปลี่ยนแปลงของความคล้ายกันเชิงความหมายระหว่างคำถาม-คำตอบ (Needle-Question)
  • การเพิ่มประโยครบกวน (distractor)
  • การเปลี่ยนหัวข้อ/โครงสร้างของข้อความต้นทาง (haystack)
  • การคัดลอกคำซ้ำ (ขยายทั้งความยาวเอาต์พุตและอินพุตพร้อมกัน)
• ทุกการทดลองพบว่า ยิ่งความยาวอินพุตเพิ่มขึ้น ประสิทธิภาพยิ่งลดลงอย่างรวดเร็ว โดยเฉพาะเมื่อความคล้ายกันเชิงความหมายต่ำหรือมีประโยครบกวนมาก การลดลงจะยิ่งรุนแรง
• ยิ่งความคล้ายกันระหว่างคำถามกับคำตอบต่ำ อัตราคำตอบผิดในอินพุตยาวก็ยิ่งพุ่งสูง
• เพียงเพิ่มประโยครบกวนแค่หนึ่งประโยค อัตราความถูกต้องก็ลดลงทันที และเมื่อเพิ่มเกิน 4 ประโยค จะเกิด ความสับสนและอาการหลอน (hallucination) เพิ่มขึ้นมากในแต่ละโมเดล
  • ตัวอย่าง: ตระกูล Claude มีแนวโน้มหลีกเลี่ยงด้วยการตอบว่า “ไม่พบคำตอบ” แทนการตอบผิด ขณะที่ตระกูล GPT มักสร้างคำตอบผิดอย่างมั่นใจมากกว่า
• ยังพบปรากฏการณ์แปลกที่ประสิทธิภาพกลับด้านตาม โครงสร้างของข้อความต้นทาง (ลำดับเชิงตรรกะ/การจัดเรียงแบบสุ่ม)
  • ในข้อความต้นฉบับ (Original) ที่คงลำดับเชิงตรรกะไว้ กลับพบว่าโมเดลทำผลงานได้แย่ลง
  • ในข้อความที่สลับประโยคแบบสุ่ม (Shuffled) กลับมีประสิทธิภาพในการค้นหาสูงกว่า
• แม้แต่ในการ ทดลองคัดลอกคำซ้ำ เมื่อจำนวนโทเค็นอินพุตและเอาต์พุตเพิ่มขึ้น ก็พบรูปแบบที่คาดเดาไม่ได้มากขึ้น เช่น อัตราคำตอบผิดสูงขึ้น การปฏิเสธงาน หรือการสร้างคำขึ้นมาเอง
  • ตัวอย่าง: หลัง 2,500–5,000 คำ ในบางโมเดลพบผลลัพธ์ผิดปกติพุ่งสูง เช่น ปฏิเสธการคัดลอกหรือสร้างข้อความตามอำเภอใจ

LongMemEval: การประเมินบทสนทนายาวแบบใกล้เคียงการใช้งานจริง

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

การวิเคราะห์เพิ่มเติมและนัยสำคัญ

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

บทสรุป

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

[ididid393939]

2.5 ออกมานานมากแล้ว แต่ทำไมยังใช้ 1.5 อยู่

[GN⁺]

ความเห็นจาก Hacker News

• ผมเองก็มีประสบการณ์คล้ายกัน โดยเฉพาะตอนใช้ Gemini Pro ถ้าให้เอกสารอ้างอิงที่ยาวมาก การสรุปแต่ละเอกสารก่อนแล้วค่อยถาม จากนั้นถ้าจำเป็นค่อยป้อนรายละเอียดทั้งเอกสารในสไตล์ RAG หรือผ่าน agent loop แบบง่าย ๆ จะให้คำตอบที่ดีกว่าการยัดหลายเอกสารเข้าไปใน context window พร้อมกันมาก เช่นเดียวกัน ตอนใช้ Claude Code ร่วมกับ Opus หรือ Sonnet ผมก็เจอเองว่าพอมีการ compaction เกิดขึ้นมาก ผลลัพธ์จะยิ่งแย่ลง ยังไม่แน่ใจว่าเป็นเพราะคุณภาพของสรุปตกลง หรือเพราะสัดส่วนของข้อมูลที่เกี่ยวข้องน้อยใน context window สูงขึ้น แต่พอล้าง context แล้วสั่งให้อ่านเฉพาะไฟล์ที่เกี่ยวข้องใหม่อีกครั้ง (แม้จะถูกพูดถึงไปแล้วในสรุปก่อนหน้า) ผลลัพธ์กลับดีขึ้นมาก

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

  • "compaction" ก็คือการย่อ transcript ให้กลายเป็นสรุปไม่ใช่หรือ? ถ้าอย่างนั้นประสิทธิภาพที่แย่ลงก็เป็นเรื่องปกติ เพราะข้อมูลหายไปจริง ๆ แต่นี่ไม่ใช่เพราะ context rot สัญญาณของ context rot ที่แท้จริงควรจะเริ่มเห็นตอนเข้าใกล้จุด threshold ของ auto-compact ผมเข้าใจถูกไหม?

  • ถ้าเป็น coding agent ที่เหมาะสม มันน่าจะทำกระบวนการนี้ให้อัตโนมัติได้ เช่น รวบรวมโค้ดที่จำเป็น, คำตอบจาก MCP, repo map ฯลฯ แล้วคอยสรุปเป็นระยะ ๆ จากนั้นรวมทั้งหมดเป็นข้อความแชตใหม่โดยเหลือไว้เฉพาะส่วนที่จำเป็นจริง ๆ ตอนนี้ผมก็ใช้สไตล์นี้อยู่แล้วกับเครื่องมือชื่อ aider และมันให้ผลดีกว่า workflow แบบ agentic หรือแบบอัตโนมัติมาก ในกรณีที่ต้องใช้ context เยอะ ๆ แต่ก็แลกกับการลงแรงเยอะ

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

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

  • การทำงานตาม flow แบบ "Explore → plan → code → test → commit" ช่วยได้มากกว่าเยอะ และถ้าจำเป็นก็ล้าง context ในแต่ละขั้นเพื่อเพิ่มประสิทธิภาพได้

  • พอมีข้อมูลมากพอสำหรับงานเฉพาะอย่างแล้ว ผมจะเซฟ context ตอนนั้นไว้ ถ้าเริ่มเห็นว่าคุณภาพตก ก็จะสรุปงานที่ทำมาจนถึงตอนนี้ใหม่ แล้วเติมกลับเข้าไปใน checkpoint ก่อนหน้า

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

• เราจำเป็นต้องมีวิธีตัด context ทิ้งได้ง่าย ๆ มาก ถ้าผมจัดการทั้งโมเดลและบทสนทนาทั้งหมดได้เอง ผมน่าจะรีดประสิทธิภาพจาก coding session ขนาดราว 200,000 token ได้มากกว่านี้เยอะ แต่ในความเป็นจริง ต่อให้ใช้ instance ที่ดี พอผ่านไปราว 20,000 token โมเดลก็เริ่มเพี้ยนแล้ว และ session ก็ rot ไปหมด ถ้าตัดส่วนนี้ทิ้งได้ตรง ๆ ก็คงดีมาก

  • local LLM ให้คุณแก้ไข context ได้ตามใจ ดังนั้นถ้าคุณแก้คำตอบของ LLM เอง โมเดลก็อาจเข้าใจผิดภายหลังว่ามันเคยพูดแบบนั้นจริง ๆ ซึ่งเลยเป็นข้อได้เปรียบในการชี้นำมันไปในทิศทางที่ต้องการ ในทางกลับกัน โมเดลแบบ LLM-as-a-service ไม่เปิดฟีเจอร์แบบนี้ เพราะมันจะทำให้การหลบเลี่ยง censorship ง่ายเกินไป

  • ผมเคยลองขอว่า "เฮ้ Claude ผมจะรีเซ็ต context แล้ว ช่วยสร้าง prompt หนึ่งชุดให้ผมทำงานต่อได้หน่อย" จากนั้นก็ตรวจ prompt ที่ Claude เสนอมาไว้ล่วงหน้า ปรับแต่ง แล้วค่อยป้อนกลับเข้าไปใหม่

  • ถ้าย้อนกลับไป checkpoint ก่อนหน้าได้ง่าย ๆ น่าจะเป็นฟีเจอร์ที่ดีที่สุดเลย

  • ใน CLI agent ส่วนใหญ่ คุณทำอะไรแบบนี้ได้ด้วยคำสั่ง /compress

• พอใช้ Claude code ไปเรื่อย ๆ มันยิ่งแยกไม่ออกระหว่างความผิดพลาดของตัวเองกับคำสั่งของผม พอมันเริ่มสับสน ทางออกคือเปิด session ใหม่ ยิ่ง session ยาว มันก็ยิ่งวนลูปเดิม หรือยืนกรานว่าเทสต์พังอยู่แล้วเลยเมินมันไป (ทั้งที่จริง ๆ มันเพิ่งพังใน session นี้) อาจจะเป็นเพราะผมเขียน prompt ไม่ดีเอง แต่ช่วงนี้เหมือน Claude IQ ลดลงไปสัก 30 โดยไม่รู้ตัว

  • ผมก็รู้สึกเหมือนกัน ถึงจะเป็นแผน Max ก็ยังมีช่วงที่ผลงานดีมากกับช่วงที่ไม่ดีชัดเจน

  • ความคิดแบบ "คงเป็นเพราะ prompt กับ context ของฉันเองแหละ" นี่ให้ความรู้สึกเหมือนพวกเราทุกคนโดน gaslighting จนซึมซับไปแล้ว

• นี่เป็นปัญหาประเภทหนึ่งของ information retrieval แต่ผมคิดว่าความเสื่อมของประสิทธิภาพจากการเปลี่ยนความยาวของ context อาจทำงานไม่เหมือนกับคำตอบแบบดึงข้อมูลอย่างเดียว ตัวอย่างเช่น คำถามอย่าง “จะเปลี่ยนปุ่มนี้ให้เป็นสีแดงได้อย่างไร?” หรือโจทย์อย่าง “ประโยคด้านบนอยู่ในหมวดหมู่ไหน?” อาจมีพฤติกรรมต่างออกไป มีงานวิจัยที่ผมประทับใจมาก่อนคือ Many-Shot In-Context Learning งานนี้แสดงให้เห็นว่าพอเติมตัวอย่างเข้าไปใน context มากขึ้น ประสิทธิภาพกลับดีขึ้นมาก สุดท้ายแล้วแต่ละปัญหาต้องลองทดสอบเองจริง ๆ ถึงจะรู้ว่า LLM เปลี่ยนพฤติกรรมอย่างไรตามเนื้อหาและความยาวของ context อย่าตั้งสมมติฐานว่าพอ context ยาวขึ้นแล้วประสิทธิภาพต้องลดลงเสมอ

  • ตามสัญชาตญาณของผม คำถามที่ต้องใช้เหตุผลจะให้ผลแย่กว่าคำถามแบบดึงข้อมูลอย่างเดียวเสมอ โดยเฉพาะถ้าเป็นคำถามเชิงปฏิเสธหรือมีข้อมูลที่เกี่ยวข้องน้อยปนอยู่ด้วย แต่สัญชาตญาณก็คือไม่ใช่ข้อมูลจริง ๆ เลยอยากเห็นตัวเลขเหมือนกัน ปรากฏการณ์ in-context learning เป็นคนละเรื่องกับประสิทธิภาพที่ลดลงเพราะ context ยาว ทั้งสองอย่างเกิดพร้อมกันได้ เช่นเดียวกับปัญหา 'lost-in-the-middle' ที่ประสิทธิภาพอาจเปลี่ยนไปตามตำแหน่งของตัวอย่าง

• เป็นบทความที่เจ๋งและมี insight มาก เพียงแต่อยากให้เผื่อมุมมองด้าน media literacy ไว้ด้วยว่า Chroma เป็นบริษัท vectorDB

  • Chroma รองรับทั้ง vector, full-text และ regex search และยังเหมาะกับสภาพแวดล้อม workload แบบ multi-tenant ที่พบได้บ่อยในแอป AI ด้วย ไม่ใช่บริษัทที่ทำแค่ vectorDB อย่างเดียว

• ช่วงนี้ผมเขียนนิยายยาวหลายเรื่องด้วย Gemini 2.5 Flash และรู้สึกถึง context rot ชัดเจนเหมือนกัน แต่จะเกิดช้ากว่าที่บทความนี้เสนอไว้มาก สำหรับผม ต้องผ่านไปราว 50,000~100,000 token ก่อนที่มันจะเริ่มละเลย context ตอนต้น ๆ (เช่น ภาษาที่ให้ตอบ) อาจเป็นไปได้ว่างานซับซ้อนอย่างงานสร้างสรรค์วัดผลกระทบได้ยากกว่า หรือผลอาจไม่ชัดเท่า ไม่ว่าอย่างไร ถ้าคอยเติม context ที่หล่นหายไปเป็นครั้งคราว มันก็ยังอยู่ในระดับที่ใช้งานได้

  • อยากฟังเรื่องนิยายต่อเลย ฟังดูน่าสนใจและอยากรู้ว่าออกมาสนุกไหม มีแผนจะตีพิมพ์หรือเปล่า

• ผมก็เจอคล้ายกัน ตอนพัฒนาฟีเจอร์ค้นหา transcript วิดีโอในโปรเจกต์หนึ่ง ข้อความยาวมาก เดิมคิดว่าโมเดลอย่าง GPT 4.1 มี context window ใหญ่ เลยน่าจะไม่ต้องใช้ RAG แต่กลับเจอพฤติกรรมแปลก ๆ บ่อย โดยเฉพาะในโมเดลเล็ก มันไม่ตอบคำถามตรง ๆ แล้วไปสรุปทั้งคอนเทนต์แทน

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