Microsoft ทดสอบ 749 งานพิสูจน์ว่า knowledge cutoff ใช้เดาไม่ได้ว่าโมเดลรู้จักผลิตภัณฑ์ของคุณแค่ไหน — GPT-5.6 Luna ผ่านแค่ 15–18% และถูก-ผิดกระจายมั่วทุกเวอร์ชัน

ใครเคยเขียน skill, MCP server หรือไฟล์คำสั่งให้เอเจนต์เขียนโค้ด คงเคยคิดแบบนี้: “โมเดลมี knowledge cutoff เดือนนี้ ฟีเจอร์ที่ออกหลังจากนั้นค่อยป้อนเอกสารเพิ่ม ส่วนของเก่าโมเดลรู้อยู่แล้ว” ฟังดูสมเหตุสมผล และประหยัด context ด้วย

บทความของ Waldek Mastykarz (Principal Developer Advocate ของ Microsoft) ที่เผยแพร่เมื่อ 21 ก.ย. 2026 ทดสอบสมมติฐานนี้ตรง ๆ แล้วพบว่า ใช้ไม่ได้ เขาตั้งใจหา “เวอร์ชันสุดท้ายที่โมเดลรู้จัก” ของผลิตภัณฑ์สองตัว แต่สิ่งที่ได้กลับมาไม่มีรูปแบบอะไรให้จับเลย

การทดลอง: 749 งาน, ปิดเน็ต, ปิดเอกสาร

• โมเดลที่ถูกทดสอบ: GPT-5.6 Luna ผ่าน GitHub Copilot SDK รันใน Vally (เครื่องมือ eval ที่เขาใช้) โดยให้ GPT-5.6 Terra เป็นกรรมการตรวจตาม rubric
• ผลิตภัณฑ์: Dev Proxy และ SharePoint Framework (SPFx) ทั้งคู่เป็นของ Microsoft เอง มี changelog ย้อนหลังครบ
• วิธีสร้างโจทย์: ป้อน changelog/release notes ให้ GPT-5.6 Sol ดึงการเปลี่ยนแปลงออกมา (ตัดเรื่องอัปเดต dependency และ CI ทิ้ง) คัดเฉพาะการเปลี่ยนแปลงที่ต่างจากพฤติกรรมเดิมมากพอจะทดสอบได้ แล้วให้โมเดลเขียนโจทย์กับ rubric ของแต่ละข้อ
• ขอบเขตข้อมูล: ตัดการเข้าถึงเอกสารและเว็บทั้งหมด เพราะอย่างที่เขาเขียนไว้ในบทความก่อนหน้า (เรื่องที่ sandbox รั่วทำให้ eval ใช้ไม่ได้) แค่มีตัวผลิตภัณฑ์ติดตั้งอยู่ในเครื่อง เอเจนต์ก็เปิดดูคำตอบได้แล้ว

ตามที่ผู้เขียนอ้างถึง OpenAI ระบุ cutoff ของ GPT-5.6 Luna ไว้ที่ 16 ก.พ. 2026 ส่วน Dev Proxy 2.1.0 ออกเมื่อ 28 ม.ค. ซึ่งเป็นรุ่นเสถียรล่าสุดก่อนวันนั้น แต่พอถามโมเดลว่าตัวเองรู้จักผลิตภัณฑ์ถึงไหน โมเดลตอบว่าประมาณ Dev Proxy 0.29.0 (ออก 25 มิ.ย. 2025 ห่างจาก cutoff เกือบ 8 เดือน) และ SPFx 1.21.1

ผลลัพธ์: ไม่มีเส้นแบ่ง มีแต่ noise

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

ผลิตภัณฑ์	จำนวนงาน	จำนวนเวอร์ชัน	ผ่าน
Dev Proxy	336	53	61 (18%)
SPFx	413	40	61 (15%)

ข้อที่ผ่านกับข้อที่ตกกระจายอยู่ทั่วประวัติผลิตภัณฑ์ Dev Proxy 0.3.0 ผ่าน 4 จาก 5 ข้อ แต่ 0.4.0 ไม่ผ่านเลยสักข้อ ส่วนรุ่นหลัง ๆ อย่าง 2.3.4, 3.0.0 และ 3.1.0 ผ่านรุ่นละ 1 จาก 2 ข้อ แล้วรุ่นถัดมาก็กลับไปไม่ผ่านอีก

ตัวอย่างความล้มเหลว ก่อน cutoff ที่ผู้เขียนยกมา:

• SPFx 1.11.0 — โจทย์ถามเรื่องใช้ module loader ภายนอกใน local workbench โมเดลอธิบายเรื่อง AMD, webpack, iframe isolation ได้น่าเชื่อ แต่พลาดข้อเท็จจริงข้อเดียวที่สำคัญ คือรุ่นนั้น ถอด SystemJS ออกจาก local workbench ไปแล้ว
• Dev Proxy 0.5.0 — ถามว่าต้องเรียก executable ตัวไหน โมเดลตอบ devproxy อย่างมั่นใจ แต่คำตอบที่ถูกของรุ่นนั้นคือ mgdp เพราะตอนนั้นยังใช้ชื่อ Microsoft Graph Developer Proxy

ส่วนความสำเร็จ หลัง cutoff: Dev Proxy 2.3.4 (23 เม.ย. 2026), 3.0.0 (28 พ.ค.) และ 3.1.0 (1 ก.ค.) ออกหลังวันที่ 16 ก.พ. ทั้งหมด แต่โมเดลก็ยังผ่านรุ่นละหนึ่งข้อ ผู้เขียนระวังไม่สรุปเกินหลักฐาน โดยบอกว่าอาจเป็นเพราะโมเดลอนุมานจากแพตเทิร์นที่คุ้น หรือแนวคิดนั้นเคยถูกพูดถึงก่อนวันออกรุ่น หรือแค่เดาถูก จากภายนอกเราแยกไม่ออกเลยว่าเป็นทางไหน

ข้อเสนอ: เลิกหา “เวอร์ชัน” แล้ววัดจากงาน

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

1. เอางานที่คาดว่าจะให้เอเจนต์ทำจริงมาทำเป็นชุดโจทย์ตัวแทน (ถ้าไม่มีงานประจำ ก็ใช้ปัญหาเฉพาะที่ต้องแก้เป็นชุด eval)
2. รันโมเดล โดยไม่ให้ข้อมูลผลิตภัณฑ์เพิ่ม เพื่อเก็บ baseline
3. เปรียบเทียบแบบควบคุมตัวแปร: ใส่เอกสาร skill หรือ extension แล้ววัดใหม่ จะได้รู้ว่าข้อมูลเสริมช่วยตรงไหนจริง

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

มุมมอง AI Curator

ผมว่านี่เป็นหนึ่งในบทความสาย “Agent Experience” ที่มีประโยชน์ที่สุดในรอบหลายสัปดาห์ เพราะมันล้มสมมติฐานที่คนเขียน skill ใช้กันโดยไม่รู้ตัว ไฟล์ SKILL.md หรือ AGENTS.md หลายตัวที่ผมเห็นเขียนทำนองว่า “โมเดลรู้จัก X อยู่แล้ว ขอเล่าแค่ของใหม่” ซึ่งการทดลองนี้บอกว่าเป็นการเดาล้วน ๆ ตัวอย่าง mgdp กับ devproxy เป็นข้อผิดพลาดที่เจอกันบ่อยมาก คือโมเดลรู้โครงสร้างกว้าง ๆ แต่พลาด ข้อเท็จจริงเล็ก ๆ เฉพาะรุ่น ไม่ว่าจะเป็นชื่อคำสั่ง ชื่อ flag หรือ API ที่ถูกถอดออก และนี่แหละคือที่ที่เอเจนต์พังในงานจริง

แต่ต้องอ่านข้อจำกัดด้วย: นี่คือโมเดลเดียว (GPT-5.6 Luna) ผลิตภัณฑ์สองตัวที่ค่อนข้างเฉพาะกลุ่ม และสร้างโจทย์กับตรวจคำตอบด้วย LLM ทั้งกระบวนการ อัตราผ่าน 15–18% จึงสะท้อนคุณภาพของโจทย์และกรรมการด้วย ไม่ใช่ความรู้ของโมเดลอย่างเดียว ถ้ากรรมการเข้มหรือหละหลวมไม่สม่ำเสมอ ก็อาจเป็นที่มาของ noise บางส่วนได้ ผมจึงอ่านว่า “ไม่มีเส้นแบ่งที่เชื่อถือได้” มากกว่า “ความรู้ของโมเดลสุ่มจริง ๆ”

สำหรับทีมไทยที่ทำเครื่องมือหรือแพลตฟอร์มภายใน เช่น SDK ของธนาคาร, ระบบ ERP ที่ปรับแต่งเอง หรือเฟรมเวิร์กของบริษัท ข้อนี้ยิ่งสำคัญ เพราะของพวกนี้แทบไม่มีอยู่ในข้อมูลเทรนเลย โมเดลจะ “เติมช่องว่าง” ด้วยแพตเทิร์นจากของสาธารณะที่คล้ายกันเสมอ ทางที่ถูกคือทำชุดโจทย์ 20–50 ข้อจากงานจริง แล้ววัดก่อน-หลังใส่เอกสาร แทนการยัด wiki ทั้งก้อนเข้า context งานแบบนี้ใช้เวลาไม่กี่วัน แต่จะบอกได้ชัดว่าเอกสารหน้าไหนช่วยจริง และหน้าไหนแค่กินโทเคน

แหล่งข่าว

• Knowledge cutoff is a poor proxy for model capability — Microsoft for Developers (21 ก.ย. 2026)
• Your AI coding agent evaluation is only as good as its sandbox — Microsoft for Developers (16 ก.ย. 2026)