Context window คืออะไร ขีดจำกัดของ AI ที่อธิบายได้ทุกอย่าง

คำอธิบายแบบตรงไปตรงมา

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

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

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

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

Token คืออะไร และประมาณอย่างไร

Context window วัดกันเป็น token ไม่ใช่จำนวนคำ เพราะโมเดลไม่ได้อ่านเป็นคำ มันอ่านเป็นชิ้น ๆ คำที่ใช้บ่อยมักเป็นหนึ่ง token คำที่ยาวหรือแปลกจะถูกแยกเป็นหลายชิ้น และเครื่องหมายวรรคตอนกับช่องว่างก็นับด้วย

อัตราส่วนคร่าว ๆ ที่ควรจำไว้

• 1 token เท่ากับราว 4 ตัวอักษรภาษาอังกฤษ หรือประมาณสามในสี่ของหนึ่งคำ
• 1,000 token เท่ากับราว 750 คำ หรือประมาณหน้าครึ่งของงานเขียนปกติ
• โค้ดกินพื้นที่มากกว่า ให้คาดไว้ที่ราวหนึ่ง token ต่อสามตัวอักษร เพราะมีสัญลักษณ์ การเว้นย่อหน้า และชื่อตัวแปรที่ไม่ใช่คำปกติ
• ภาษาอื่นใช้ token เปลืองกว่า ข้อความในภาษาที่ตัวแบ่ง token รองรับน้อยกว่าอาจใช้ token มากกว่าสองถึงสามเท่าสำหรับเนื้อความเดียวกัน ซึ่งควรรู้ไว้ถ้าคุณจ่ายเงินตามจำนวน token

ตรงนี้ช่วยให้คุณเห็นภาพตัวเลขที่เจอในสื่อการตลาดได้

Context window	เทียบได้ราว ๆ กับ
8,000 token	บทความยาวหนึ่งชิ้น
32,000 token	งานวิจัยสั้นพร้อมโน้ต
128,000 token	หนังสือหนา 300 หน้า
200,000 token	คู่มือทางเทคนิคที่เนื้อหาแน่น หรือโค้ดเบสขนาดกลาง
1,000,000 token	หนังสือหลายเล่ม หรือบันทึกการประชุมทั้งปี

สิ่งที่ตารางนี้ซ่อนไว้และสำคัญคือ ขีดจำกัดครอบคลุมบทสนทนา ทั้งหมด ไม่ใช่แต่ละข้อความ หน้าต่าง 128,000 token ไม่ได้แปลว่าคุณส่ง 128,000 token ได้ซ้ำ ๆ แต่แปลว่ายอดสะสมของทุกอย่าง รวมถึงคำตอบของโมเดลเอง ต้องอยู่ใต้ตัวเลขนั้น

อะไรกันแน่ที่กินพื้นที่หน้าต่างของคุณ

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

1. System prompt คือคำสั่งที่ผลิตภัณฑ์ส่งไปก่อนที่คุณจะพิมพ์อะไรเลย ทั้งวิธีวางตัว เครื่องมือที่มีให้ใช้ วันที่วันนี้ และกฎด้านความปลอดภัย มักยาวหลายพัน token และคุณไม่เคยเห็นมัน
2. คำสั่งที่คุณตั้งเองหรือความจำ คือทุกอย่างที่ผลิตภัณฑ์เก็บไว้เกี่ยวกับคุณแล้วแทรกเข้ามาอัตโนมัติ
3. ทุกข้อความก่อนหน้า ทั้งของคุณและของโมเดล แบบเต็ม ๆ คำตอบยาว ๆ ของโมเดลก็นับด้วย และมักเป็นตัวกินพื้นที่มากที่สุด
4. ทุกไฟล์ที่อัปโหลด หรือส่วนที่ถูกดึงออกมาจากไฟล์นั้น ไฟล์ PDF 40 หน้าเท่ากับราว 20,000 ถึง 30,000 token
5. ผลลัพธ์จากเครื่องมือและการค้นหา การค้นเว็บที่ดึงมาห้าหน้าอาจกินพื้นที่มากกว่าบทสนทนาทั้งหมดที่ผ่านมา
6. คำตอบที่กำลังถูกสร้าง เพราะผลลัพธ์ใช้งบประมาณก้อนเดียวกับข้อมูลเข้า

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

และเป็นเหตุผลที่วิธีแก้บทสนทนาที่เริ่มมั่วมักเป็น "เปิดแชตใหม่" คุณไม่ได้กำลังรีเซ็ตอารมณ์ของโมเดล คุณกำลังเคลียร์โต๊ะ

ขนาดที่โฆษณากับขนาดที่ใช้ได้จริง

นี่คือส่วนที่สำคัญที่สุดและถูกพูดถึงน้อยที่สุด คุณภาพของโมเดลไม่ได้คงที่ไปจนถึงเพดานแล้วค่อยดิ่งลง แต่มันค่อย ๆ ลดลง และเริ่มลดตั้งแต่ก่อนถึงเพดานมาก

เวอร์ชันที่มีเอกสารรองรับดีที่สุดของเรื่องนี้มักถูกเรียกว่าปรากฏการณ์หายไปตรงกลาง (lost in the middle) ถ้าคุณวางข้อเท็จจริงหนึ่งไว้ต้นเอกสารยาว โมเดลหาเจอ วางไว้ท้ายเอกสาร โมเดลก็หาเจอ แต่ถ้าฝังไว้กลางเอกสาร 200 หน้า ความแม่นยำในการดึงข้อมูลจะลดลงอย่างเห็นได้ชัด ความสนใจของโมเดลไม่ได้กระจายเท่ากันตลอดข้อมูลเข้าที่ยาว และส่วนหัวกับส่วนท้ายได้ไปมากกว่า

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

ดังนั้นให้มองตัวเลขที่โฆษณาว่าเป็นความจุสูงสุด ไม่ใช่ช่วงที่ทำงานได้สบาย กฎคร่าว ๆ จากการใช้งานจริงคือ คุณจะได้พฤติกรรมที่เชื่อถือได้ราวครึ่งหนึ่งของหน้าต่างที่โฆษณาไว้ และอะไรที่เกินจากนั้นควรตรวจสอบมากกว่าจะเชื่อ ถ้าโมเดลบอกคุณว่าสัญญา 300 หน้าไม่มีข้อบอกเลิกสัญญา ให้ไปเช็ก โดยเฉพาะถ้าข้อนั้นน่าจะอยู่ตรงกลาง

นัยต่อการเปรียบเทียบคือ โมเดลที่มีหน้าต่างหนึ่งล้าน token ไม่ได้เก่งเรื่องเอกสารยาวกว่าโมเดลที่มี 200,000 โดยอัตโนมัติ มันแค่รับเข้าไปได้มากกว่า ส่วนที่ว่ามันคิดวิเคราะห์ได้ดีตลอดทั้งก้อนหรือไม่เป็นคนละคำถาม และวิธีเดียวที่จะรู้คือทดสอบด้วยเอกสารที่คุณรู้คำตอบอยู่แล้ว

เกิดอะไรขึ้นเมื่อพื้นที่หมด

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

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

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

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

กลยุทธ์ที่ใช้ได้ผลจริง

เรียงตามผลลัพธ์ที่ได้เทียบกับแรงที่ลงไป

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

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

ย้ำข้อจำกัดสำคัญเป็นระยะ ในบทสนทนาที่ยาวเกินราวสิบห้ารอบ ให้พูดกฎที่สำคัญซ้ำในข้อความที่กฎนั้นสำคัญ เช่น "ขอย้ำว่าใช้ภาษาอังกฤษแบบบริติช ไม่ใช้หัวข้อย่อย ไม่เกิน 400 คำ" เสียแค่บรรทัดเดียวและมันรอดจากการถูกตัดทิ้ง

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

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

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

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

จริง ๆ แล้วคุณต้องการหน้าต่างใหญ่แค่ไหน

จับคู่ขนาดหน้าต่างกับงานที่ทำ แทนที่จะเลือกตัวเลขที่ใหญ่ที่สุด

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

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

ถ้าคุณอยากทดสอบเรื่องนี้ด้วยตัวเอง วิธีที่ทำได้จริงคือรันเอกสารยาวชุดเดียวกันผ่านสองหรือสามโมเดล แล้วเทียบคำตอบกับสิ่งที่คุณรู้อยู่แล้ว พื้นที่ทำงานอย่าง Whizi ทำให้เรื่องนี้ง่าย เพราะ GPT, Claude, Gemini, Grok และ DeepSeek อยู่หลังค่าสมาชิกเดียว หน้าต่างขนาดใหญ่มากของ Gemini จึงอยู่ห่างจากการสังเคราะห์อย่างละเอียดของ Claude เพียงคลิกเดียว ดู การเปรียบเทียบโมเดลแบบเคียงข้างกัน หรืออ่าน วิธีเลือกโมเดล AI สำหรับการตัดสินใจในภาพกว้าง