ตามรอยคำว่า "แคชพัง" ของ Claude Code กลับไปยังแหล่งข้อมูลปฐมภูมิ — รายงานบั๊กบน Reddit, postmortem ทางการ และงานวิจัย arXiv 2 ฉบับ
บทนำ
ใช้ผู้ช่วย AI เขียนโค้ดยาว ๆ แล้วคุณอาจเริ่มรู้สึกว่า “ยิ่งบทสนทนายาว คุณภาพยิ่งตก” ความรู้สึกนี้ไม่ใช่เรื่องแปลก ลองค้นดูก็จะเจอคำบ่นแบบเดียวกันจำนวนมาก “แคชพัง” “บริบทพัง” — อ่านแค่หัวข้อก็เหมือนเป็นปรากฏการณ์เดียวกัน แต่พอเปิดดูทีละอัน คุณจะสังเกตว่า ใครเป็นคนพูด และมันถูกยืนยันไปถึงไหนแล้ว นั้นไม่เท่ากันเลยแม้แต่น้อย
บทความนี้เป็นบันทึกของวิธีจัดการกับความไม่เท่ากันนั้นโดยไม่ทำให้มันแบนราบ แทนที่จะรีบวิ่งไปหาข้อสรุป ให้ จัดระดับแหล่งข้อมูลเป็น 4 ชั้น แล้วตรวจสอบไขว้โดยรักษาการจัดระดับนั้นไว้ หัวข้อไม่ใช่ข้อสรุปที่ว่า “มีบั๊กหรือไม่มี” แต่คือ วิธีจัดการกับแหล่งข้อมูลก่อนจะไปถึงตรงนั้น
จัดระดับแหล่งข้อมูลเป็น 4 ชั้น
ก่อนเริ่มยืนยันอะไรก็ตาม ฉันตรึงน้ำหนักของแหล่งข้อมูลแต่ละชนิดไว้ก่อน
| ระดับ | เนื้อหา | วิธีจัดการ |
|---|---|---|
| ปฐมภูมิทางการ | เอกสารและบล็อกวิศวกรรมของ Anthropic เอง | ให้น้ำหนักมากที่สุด แต่ต้องยืนยันรุ่นที่กำลังพูดถึงเสมอ (โมเดล, เวอร์ชัน) |
| ปฐมภูมิ แต่ผู้ให้บริการไม่ได้เกี่ยวข้อง | เนื้อหาของ GitHub issue, ความเห็นของผู้ปฏิบัติงาน | เป็นการสังเกตของจริงที่เกิดขึ้น แต่ไม่ใช่ข้อเท็จจริงที่ Anthropic ยืนยัน อาจถูกถือไว้ ในสถานะข้อพิพาท |
| งานวิชาการ | งานวิจัยบน arXiv | ตัวเลขมีน้ำหนัก แต่ ต้องยืนยันก่อนว่าโมเดล ภาษา และงานที่ศึกษาตรงกับสถานการณ์ปัจจุบัน ก่อนหยิบตัวเลขใด ๆ มาใช้ |
| ตติยภูมิ | บล็อกเทคนิคส่วนบุคคล, บทอธิบายมือสอง | มีประโยชน์สำหรับกลไก (ภาพรวมว่ามันทำงานอย่างไร) แต่ อย่าหยิบตัวเลขจากมัน |
มีเหตุผลที่ต้องตรึงตารางนั้นไว้ก่อน สำหรับประโยคเดียวกันว่า “แคชพัง” ระดับที่ต่างกันหมายถึงการจัดการที่ต่างกัน ชั้นที่สองคือชั้นที่อันตราย สำหรับผู้โพสต์มันคือการสังเกตมือหนึ่งอย่างไม่ต้องสงสัย แต่ด้วยประเด็นเดียวที่ว่า Anthropic ยังไม่ได้ยืนยัน ความน่าเชื่อถือของมันจึงเป็นคนละเรื่องกับปฐมภูมิทางการโดยสิ้นเชิง ทำให้เส้นนั้นเบลอ แล้วข่าวลือก็จะแทรกเข้ามาโดยสวมหน้ากากของข้อเท็จจริง
จุดตั้งต้น — โพสต์ Reddit ที่ได้โหวตสูง
การสืบสวนเริ่มจากโพสต์ Reddit ที่ได้โหวตเกิน 900 ผู้โพสต์อ้างว่าได้แกะไฟล์รันแล้วชี้ไปที่บั๊ก 2 จุด ข้ออ้างเชิงเทคนิคเองไม่ใช่หัวข้อในที่นี้ สิ่งที่สำคัญคือโพสต์นี้ควรถูกจัดการอย่างไรต่อจากนั้น
โพสต์มีข้อความเพิ่มเติมจากผู้โพสต์เอง
Issues linked in the description have been closed as resolved. Unfortunately I can’t verify those claims as I’m away from my PC.
ในความเห็นก็มีการอ้างคำปฏิเสธจากพนักงาน Anthropic
Confirming this post isn’t the problem.
ผู้โพสต์สงวนการตัดสิน — “can’t verify” — และคนจาก Anthropic ระบุว่า “this isn’t the problem” ณ จุดนั้นฉันตรวจสถานะจริงของ GitHub issue ที่โพสต์ระบุถึง ทั้งสองรายการที่สอดคล้องกันถูก ปิดในฐานะแก้ไขแล้ว (2026-04-04 และ 2026-04-01)
ต้องมีครบทั้งสาม — การสงวนท่าทีของผู้โพสต์เอง คำปฏิเสธของ Anthropic และสถานะของ issue ที่วัดจริง — จึงจะตัดสินได้ว่า ไม่รับโพสต์นี้เป็นข้อเท็จจริง ตัวเลขโหวตเกิน 900 ไม่ได้ถูกใช้เป็นหลักฐาน จำนวนโหวตแสดงว่าคนจำนวนมากสงสัยอาการเดียวกัน มันไม่ได้แสดงว่าคำอธิบายสาเหตุนั้นถูกต้อง
อ่านแหล่งข้อมูลปฐมภูมิที่ผู้ให้บริการยังไม่แตะโดยตรง
แยกจากโพสต์ Reddit ฉันเปิด GitHub issue อีกอันโดยตรง อ่านทั้งเนื้อหาและความเห็นทั้งหมด กลไกที่ถูกอ้างคือ:
Because many of CC’s own built-in reminders carry dynamic values … the smoosh produces different byte output turn-over-turn. The resulting byte drift in historical user messages breaks the prompt cache prefix …
issue นี้อยู่ในสถานะ CLOSED แต่การตรวจว่าทำไมมันถูกปิด ได้ความเห็นอัตโนมัติว่า:
Closing for now — inactive for too long.
นั่นไม่ใช่ “CLOSED เพราะถูกแก้แล้ว” บอตแค่ปิดมันเพราะไม่มีความเคลื่อนไหวมาสักพัก คำว่า CLOSED คำเดียวกันมีความหมายต่างจากสองอันข้างบนโดยสิ้นเชิง (ปิดในฐานะแก้ไขแล้ว) ถ้าสรุปโดยไม่แยกความต่างนั้น — “issue ถูกแก้แล้ว” — คุณก็อ่านข้ออ้างที่แค่ถูกปล่อยทิ้งไว้ผิดเป็นข้ออ้างที่ถูกจัดการไปแล้ว
ใน issue นี้ผู้รายงานเขียนซ้ำ ๆ ว่า:
Still zero @anthropic.com green-badge engagement.
ข้ออ้างนั้นเจาะจงและมีรูปแบบที่อาจกระทบการทำงานของเราโดยตรง แต่ ระดับของมันยังคงเป็น “ปฐมภูมิ แต่ผู้ให้บริการไม่ได้เกี่ยวข้อง” และไม่มีการยืนยันจาก Anthropic เอง ข้อสรุปจึงไม่ใช่ทั้ง “ปฏิเสธ” และ “รับ” แต่ ถูกถือไว้ในสถานะข้อพิพาท
ไปที่ postmortem ทางการ — แต่คนละรุ่น
ต่อมาฉันอ่าน postmortem ที่ Anthropic เผยแพร่เอง เกี่ยวกับรายงานคุณภาพที่ตกลง ข้อความทางการระบุชัดเจน:
To state it plainly: We never reduce model quality due to demand, time of day, or server load. The problems our users reported were due to infrastructure bugs alone.
มีการอธิบายสาเหตุ 3 ข้ออย่างเป็นรูปธรรม: ความผิดพลาดของการกำหนดเส้นทางเซิร์ฟเวอร์, เอาต์พุตที่เสียหาย และบั๊กของคอมไพเลอร์ นี่คือแหล่งปฐมภูมิทางการของแท้ และเป็นบรรทัดฐานในตัวมันเองสำหรับ “คุณภาพที่ตกลงมีจริง และสาเหตุอยู่ฝั่งโครงสร้างพื้นฐาน”
แต่เมื่อยืนยันรุ่นของโมเดลที่กำลังพูดถึง ปรากฏว่ามันเก่ากว่ารุ่นปัจจุบัน แม้แต่แหล่งข้อมูลที่ถูกจัดระดับสูงที่สุด ก็นำมาใช้กับปัจจุบันตรง ๆ ไม่ได้เมื่อคนละรุ่น ที่นี่ฉันจึงแยกข้อเท็จจริงที่ว่า “มีกรณีคุณภาพตกจริง” ออกจากการอนุมานที่ว่า “สาเหตุนั้นใช้กับสภาพแวดล้อมของฉันด้วย” อย่างตั้งใจ
จากแหล่งตติยภูมิ ให้หยิบมาแค่กลไก
ระหว่างการยืนยัน ฉันยังอ่านบทความเทคนิคส่วนบุคคลที่วาดแผนภาพว่าแคชทำงานอย่างไร บทความนั้นมีคำปฏิเสธความรับผิดของตัวเองอยู่ท้ายบท (ต้นฉบับเป็นภาษาจีน)
数据来源说明：本文价格和机制数据来自多个 AI 的网络调研结果交叉验证，部分数据可能随时间变化，请以各家官方文档为准。
ใจความคือ ข้อมูลราคาและกลไกในบทความมาจากการตรวจสอบไขว้ผลการค้นเว็บของ AI หลายตัว และควรยึดเอกสารทางการของแต่ละเจ้าเป็นหลัก ผู้เขียนระบุตรง ๆ ว่ามันไม่ใช่แหล่งปฐมภูมิ
จากบทความนั้นฉันหยิบมาแค่ภาพรวมของกลไก — ว่า แคชถูกจัดเป็นชั้น “tools → system → messages” และการเปลี่ยนที่ต้นน้ำจะทำให้ทุกอย่างที่ปลายน้ำใช้ไม่ได้ตามไปด้วย ส่วนตัวเลขประมาณการราคาและตัวคูณที่วางเรียงอยู่ข้าง ๆ ฉัน ไม่หยิบมา แหล่งตติยภูมิมีประโยชน์ในฐานะแผนที่ว่าอะไรทำงานอย่างไร มันไม่ใช่หลักฐานยืนยันตัวเลข
การอ่านเอกสารทางการซ้ำล้มสมมติฐานไปหลายข้อ
เมื่อการยืนยันคืบไปได้ประมาณหนึ่ง ฉันกลับไปอ่านสเปกแคชทางการที่ควรจะเคยอ่านไปแล้วซ้ำอีกครั้ง อ่านใหม่ภายใต้ความสงสัยเฉพาะเรื่องนี้ ปรากฏว่ามี ประโยคที่ฉันเคยมองข้ามไป
Skills, commands, agents, hooks, LSP servers, monitors, and themes never invalidate the cache: anything they add to the request is appended after the existing conversation, so the next request pays for the new content but still reads everything before it from the cache.
ความสงสัยที่การสืบสวนนี้เริ่มต้นขึ้นมาเอง — “หรือยิ่งมีฮุกมาก แคชก็ยิ่งพัง” — ถูก ปฏิเสธโดยแหล่งข้อมูลปฐมภูมิทางการ ฮุกและส่วนขยายถูกต่อท้ายและไม่ทำให้แคชพัง สิ่งที่ทำให้มันพังตามที่ข้อความระบุชัดเจน มีเพียงชุดปฏิบัติการตายตัวที่เอกสารระบุไว้: การสลับโมเดล, การเปลี่ยนการเชื่อมต่อเซิร์ฟเวอร์ MCP, การบีบอัดบทสนทนา
แม้แต่เอกสารที่คุณเคยอ่านแล้ว ก็ยังให้ประโยคที่คุณเก็บไม่ได้ในครั้งก่อน เมื่อคุณอ่านซ้ำโดยถือความสงสัยคนละแบบ นั่นคือการปรับทิศทางครั้งใหญ่ที่สุดของการสืบสวนนี้ “อ่านแล้ว” กับ “อ่านดีพอที่จะใช้ตรวจสอบไขว้ได้” เป็นคนละเรื่องกัน — ยืนยันด้วยวิธีที่เจ็บตัว
งานวิจัย 2 ฉบับ — อย่านำเข้าตัวเลขจากคนละรุ่น คนละภาษา คนละงาน
สุดท้ายฉันไปที่งานวิจัย arXiv 2 ฉบับ ฉบับหนึ่งวัดโมเดลรุ่นใกล้เคียงกับปัจจุบันกับข้อมูลเซสชันจริง และรายงานว่า:
Opus 4.6 … recall drops from 99.7% when such an attack is inserted in a 100K transcript to 69% when the same attack is inserted in an 800K transcript.
ทั้งโมเดลและชุดข้อมูลใกล้เคียงกับปัจจุบัน ตัวเลขนี้จึงนำเข้ามาเป็นค่าอ้างอิงได้ อีกฉบับเก่าราวสามปี ครอบคลุมกลุ่มโมเดลคนละรุ่น คนละภาษา คนละงาน มันแสดง รูปร่าง แบบเดียวกัน — ว่าข้อมูลที่อยู่กลางบริบทยาว ๆ ถูกหยิบขึ้นมาได้ยากกว่า — แต่ ตัวเลขของมัน (ค่าความแม่นยำสัมบูรณ์) ไม่ถูกนำเข้ามาสู่รุ่นปัจจุบัน สิ่งเดียวที่ฉันหยิบมาคือข้อเท็จจริงว่ารูปร่างที่มันแสดงนั้นเกิดซ้ำได้ข้ามงานวิจัย 2 ฉบับและหลายรุ่น
เส้นทางย้อนกลับผ่านแหล่งข้อมูล
เริ่ม: โพสต์ Reddit ↑955 (ปฐมภูมิแต่ผู้ให้บริการไม่เกี่ยว; ผู้โพสต์เพิ่มทีหลังว่า "can't verify")
│
├─▶ วัดสถานะของ GitHub issue ที่สอดคล้องกัน
│ └─ ทั้งคู่ CLOSED ในฐานะ "แก้ไขแล้ว" (2026-04-04 / 2026-04-01)
│ └─ ยืนยันคำปฏิเสธของพนักงาน Anthropic ด้วย
│ └─ ⇒ ไม่รับเป็นข้อเท็จจริง (ยุติ)
│
├─▶ อ่าน GitHub issue อีกอันโดยตรงในฐานะแหล่งปฐมภูมิ
│ └─ ตรวจว่าทำไมถึง CLOSED ── ไม่ใช่การแก้ แต่เป็นการปิดอัตโนมัติเพราะ "ไม่มีความเคลื่อนไหว"
│ └─ ⚠️ ไม่ปฏิเสธและไม่รับ ถือไว้ในสถานะข้อพิพาท
│
├─▶ ไปที่ postmortem ทางการ (Anthropic เอง, ปฐมภูมิทางการ)
│ └─ ยืนยันรุ่น ── เก่ากว่ารุ่นปัจจุบัน
│ └─ ⇒ รับไว้เป็นบรรทัดฐาน แต่การนำมาใช้กับปัจจุบันถูกถือไว้
│
├─▶ เรียบเรียงเฉพาะกลไก จากแหล่งตติยภูมิ (บล็อกเทคนิคส่วนบุคคล)
│ └─ ยืนยันคำปฏิเสธความรับผิดของแหล่งเอง (งานค้นคว้ามือสองที่ไม่มีการยืนยัน)
│ └─ ⇒ อ้างอิงเฉพาะภาพรวมของกลไก ไม่หยิบตัวเลข
│
└─▶ "อ่านซ้ำ" แหล่งปฐมภูมิทางการ ★ สมมติฐานถูกล้มตรงนี้
└─ พบประโยค "ส่วนขยายไม่เคยทำให้แคชใช้ไม่ได้"
└──(เส้นย้อนกลับ)──▶ ถอนความสงสัยตั้งต้นทิ้งไปเอง
│
└─▶ ยืนยันตัวเลขกับงานวิจัย 2 ฉบับ
├─ รุ่นใกล้ปัจจุบัน ── หยิบตัวเลขมา
└─ เก่าสามปี ── หยิบมาแค่รูปร่าง (ไม่เอาตัวเลข)
ข้อสรุป โดยรักษาการจัดระดับไว้
สิ่งที่เหลืออยู่ในมือตอนจบ ไม่ใช่ “ปริศนาที่ถูกไข” แต่คือ รายการที่แยกสิ่งที่ยุติแล้วออกจากสิ่งที่ยังเป็นข้อพิพาท
| ข้ออ้าง | สถานะ |
|---|---|
| บั๊ก 2 จุดที่โพสต์ Reddit ระบุ | ไม่รับเป็นข้อเท็จจริง (ยุติด้วย 3 ประเด็น: การสงวนท่าทีของผู้โพสต์, คำปฏิเสธทางการ, สถานะ issue ที่วัดจริง) |
| การพาแคชเสียจาก reminder แบบไดนามิกที่ GitHub issue อีกอันอ้าง | ถือไว้ในสถานะข้อพิพาท (ไม่ปฏิเสธและไม่รับ) |
| ความสงสัยที่ว่าส่วนขยาย (เช่นฮุก) ทำให้แคชพัง | ถูกปฏิเสธโดยแหล่งปฐมภูมิทางการ (จุดตั้งต้นของการสืบสวนนี้ถูกถอนทิ้งเอง) |
| “รูปร่าง” ที่ข้อมูลกลางบริบทยาวถูกหยิบขึ้นมาได้ยากกว่า | ยืนยันการเกิดซ้ำข้ามงานวิจัย 2 ฉบับและหลายรุ่น (ใช้ตัวเลขแยกตามรุ่น) |
แม้แต่สิ่งที่ดูเหมือนแหล่งปฐมภูมิก็ต้องตรวจทุกครั้ง: ใครเผยแพร่ มันบรรยายช่วงเวลาไหน และคุณพอใจแค่ที่ได้อ่านมันครั้งเดียวหรือเปล่า สิ่งที่ทำงานหนักที่สุดในครั้งนี้คือ ไม่ใช่การเพิ่มแหล่งข้อมูลใหม่ แต่คือการอ่านเอกสารทางการที่ควรจะเคยอ่านไปแล้วซ้ำ โดยถือความสงสัยคนละแบบ
พอถึงตอนจบของการสืบสวน ความสงสัยตั้งต้นก็หายไปเอง มันยุติลงไม่ใช่ในฐานะ “หาแล้วไม่เจอ” แต่ในฐานะ “เหตุผลที่จะหานั้นไม่มีอยู่อีกต่อไป” — ไม่ใช่ความสูญเปล่า แต่เป็นผลของการไม่ปล่อยการจัดระดับหลุดมือ