บริบทหน้าต่างคืออะไร และทำไมมันถึงเต็ม?
ช่วงความยาวของบริบทคือสิ่งที่โมเดลสามารถมองเห็นได้ในครั้งเดียว — คำอธิบายของคุณ, การสนทนา, เอกสารที่ดึงมาและคำตอบของมันเอง การวัดช่วงความยาวของบริบททำอย่างไร ทำไมความยาวที่มากขึ้นไม่จำเป็นจะทำให้ผลลัพธ์ดีขึ้นเสมอไป, และทำอย่างไรเมื่อคุณถึงขีดจำกัด
คำตอบโดยย่อ
ช่วงบริบทในโมเดล AI คืออะไร?
ขนาดหน้าต่างบริบทคือปริมาณข้อความสูงสุดที่วัดเป็นโทเคน ที่โมเดลสามารถพิจารณาในคำขอหนึ่งเดียวได้ มันเก็บคำสั่งระบบ คำสนทนาไปแล้ว เอกสารที่คุณวางไว้ และคำตอบที่กำลังสร้าง เมื่อรวมทั้งหมดเกินขีดจำกัด จะต้องทิ้งหรือสรุปบางส่วน
ประเด็นสำคัญ
- หน้าต่างวัดเป็นโทเคน ไม่ใช่คำ โดยประมาณ 0.75 คำต่อโทเคนในภาษาอังกฤษ และมีจำนวนอักขระน้อยกว่ามากต่อโทเคนในภาษาเกาหลีหรือญี่ปุ่น
- ทุกอย่างใช้งบประมาณเดียวกัน: คำสั่ง, ประวัติ, ไฟล์ที่แนบมา, การกำหนดค่าเครื่องมือและผลลัพธ์
- โมเดลใช้ส่วนเริ่มต้นและส่วนปลายของบริบทยาวได้ดีกว่าส่วนกลาง ดังนั้นการจัดวางจึงมีความสำคัญ
- ค่าและความล่าช้าขึ้นอยู่กับจำนวนโทเคนที่คุณส่งจริง ๆ ทำให้การแคชและการเรียกคืนข้อมูลมักจะดีกว่าการวางข้อมูลทั้งหมดไว้ในข้อความ
ทุกการสนทนากับโมเดลภาษาจะมีข้อจำกัดสูงสุดในการมองเห็นข้อมูลในครั้งเดียว ข้อจำกัดนั้นคือหน้าต่างบริบท (context window) และพฤติกรรมที่แปลกประหลาดเกือบทั้งหมดที่ผู้คนรายงาน เช่น โมเดล "ลืม" สิ่งที่คุณพูด ไม่สนใจไฟล์ที่แนบมา หรือหลงประเด็นกลางคัน ล้วนมีสาเหตุมาจากสิ่งนี้
โทเค็น ไม่ใช่คำ
โมเดลไม่ได้อ่านตัวอักษรหรือคำ ข้อความจะถูกแบ่งออกเป็น โทเค็น ก่อน ซึ่งเป็นส่วนย่อยที่พบบ่อยซึ่งตัวแบ่งโทเค็นได้เรียนรู้ ในภาษาอังกฤษ โทเค็นโดยเฉลี่ยมีประมาณสี่ตัวอักษร ดังนั้น 1,000 โทเค็นจึงเท่ากับประมาณ 750 คำ
อัตราส่วนนี้ไม่สากล สคริปต์ที่อยู่นอกเหนือการกระจายการฝึกของตัวแบ่งโทเค็นจะถูกแบ่งย่อยมากขึ้น:
| ข้อความ | โทเค็นโดยประมาณ |
|---|---|
The quick brown fox (19 ตัวอักษร, ภาษาอังกฤษ) | ~4 |
안녕하세요 반갑습니다 (11 ตัวอักษร, ภาษาเกาหลี) | ~10 |
こんにちは、はじめまして (12 ตัวอักษร, ภาษาญี่ปุ่น) | ~11 |
| บรรทัดโค้ดที่เว้นวรรค 4 ช่อง | 1 โทเค็นต่อระดับการเว้นวรรค |
ผลที่ตามมาในทางปฏิบัติ: เอกสารภาษาเกาหลีหรือญี่ปุ่นจะใช้พื้นที่ในหน้าต่างมากกว่าเอกสารภาษาอังกฤษที่มีความยาวที่มองเห็นได้เท่ากันอย่างเห็นได้ชัด และมีค่าใช้จ่ายตามสัดส่วนที่สูงขึ้นต่อคำขอ
อะไรคือสิ่งที่แข่งขันกันเพื่อพื้นที่
เป็นเรื่องง่ายที่จะคิดว่าหน้าต่างนี้คือ "เอกสารยาวแค่ไหนที่ฉันสามารถวางได้" จริงๆ แล้วมันคือ งบประมาณที่ใช้ร่วมกัน:
- พรอมต์ระบบ (system prompt) — คำแนะนำที่กำหนดพฤติกรรมของผู้ช่วย
- คำจำกัดความของเครื่องมือ (tool definitions) หากโมเดลสามารถเรียกใช้เครื่องมือได้ เครื่องมือหลายสิบรายการที่มีสคีมาโดยละเอียดอาจมีโทเค็นหลายพันรายการก่อนที่คุณจะพูดอะไรเลย
- ประวัติการสนทนา (conversation history) โดยปกติจะส่งซ้ำทั้งหมดในทุกเทิร์น
- เอกสารที่แนบมาหรือเรียกค้น (attached or retrieved documents)
- ผลลัพธ์ (output) โทเค็นที่สร้างขึ้นจะถูกหักออกจากงบประมาณเดียวกันใน API ส่วนใหญ่ นี่คือเหตุผลว่าทำไมอินพุตที่ยาวมากจึงอาจไม่เหลือพื้นที่สำหรับคำตอบที่ยาว
หากคุณเคยแนบ PDF ขนาดใหญ่และได้รับคำตอบที่ถูกตัดทอน นี่คือเหตุผล
ยาว ไม่ได้หมายถึงดีสม่ำเสมอ
งานวิจัยเกี่ยวกับพฤติกรรมของบริบทที่ยาว — ที่มีอิทธิพลมากที่สุดคือ Lost in the Middle — พบรูปแบบที่สอดคล้องกัน: โมเดลจะเรียกค้นข้อเท็จจริงที่วางไว้ใกล้กับ จุดเริ่มต้น หรือ จุดสิ้นสุด ของอินพุตที่ยาวได้น่าเชื่อถือกว่าข้อเท็จจริงที่ฝังอยู่ตรงกลางมาก เส้นโค้งเป็นรูปตัว U และไม่ราบเรียบอย่างสมบูรณ์เมื่อหน้าต่างใหญ่ขึ้น
สามกฎที่ตามมาโดยตรง:
- วางคำแนะนำไว้ก่อนและคำถามทันทีไว้สุดท้าย ตำแหน่งทั้งสองที่โมเดลให้ความสนใจได้ดีที่สุด
- อย่าเติมข้อมูล ยี่สิบหน้าที่เกี่ยวข้องดีกว่าสองร้อยหน้าที่บรรจุข้อมูลยี่สิบหน้าเดียวกัน
- ทดสอบที่ความยาวจริง พรอมต์ที่ใช้งานได้ที่ 5,000 โทเค็นอาจเสื่อมถอยลงอย่างเงียบๆ ที่ 100,000 โทเค็น
เกณฑ์มาตรฐาน "เข็มในกองฟาง" (needle in a haystack) ของผู้ให้บริการ — การซ่อนประโยคเดียวในเอกสารยาวและขอให้โมเดลค้นหา — วัดกรณีที่ง่าย การเรียกค้นข้อเท็จจริงที่โดดเด่นเพียงอย่างเดียวง่ายกว่าการให้เหตุผลเกี่ยวกับเนื้อหาที่กระจายอยู่ทั่วทั้งอินพุต
ค่าใช้จ่าย ความหน่วงแฝง และการแคช
คุณจ่ายค่าโทเค็นที่คุณส่งไปในทุกคำขอ บริบท 100,000 โทเค็นที่ส่งซ้ำตลอดการสนทนา 20 เทิร์น คือ 2 ล้านโทเค็นอินพุต แม้ว่าผู้ใช้จะพิมพ์คำถามสั้นๆ ยี่สิบคำก็ตาม
สองกลไกช่วยลดผลกระทบ:
- การแคชพรอมต์ (Prompt caching) ผู้ให้บริการสามารถแคชส่วนหน้าของคำขอที่ไม่เปลี่ยนแปลง — พรอมต์ระบบ คำจำกัดความของเครื่องมือ เอกสารยาว — และคิดค่าบริการน้อยลงมากสำหรับการเข้าถึงแคช มันทำงานได้ก็ต่อเมื่อส่วนหน้า เหมือนกันทุกประการ ดังนั้นให้วางเนื้อหาที่เสถียรไว้ก่อนและเนื้อหาที่ผันผวน (เวลา, ชื่อผู้ใช้) ไว้สุดท้าย
- การจัดกลุ่ม (Batching) สำหรับงานที่ไม่โต้ตอบ API แบบจัดกลุ่มมักมีค่าใช้จ่ายน้อยลงอย่างมาก แลกกับการได้ผลลัพธ์ที่ล่าช้า
ความหน่วงแฝงมีลักษณะคล้ายกัน: เวลาในการสร้างโทเค็นแรกจะเพิ่มขึ้นตามความยาวของอินพุต ดังนั้นการแชทที่รู้สึกทันทีด้วยพรอมต์สั้นๆ จะรู้สึกช้าลงเมื่อคุณแนบไฟล์ขนาดใหญ่
จะทำอย่างไรเมื่อถึงขีดจำกัด
เรียกค้นแทนการวาง (Retrieve instead of paste) จัดทำดัชนีเอกสารของคุณ ดึงย่อหน้าที่เกี่ยวข้องกับคำถาม และส่งสิ่งเหล่านั้น คำขอจะยังคงเล็ก ราคาถูก และแม่นยำ นี่คือเหตุผลทั้งหมดสำหรับ การสร้างข้อความเสริมการเรียกค้น (retrieval-augmented generation)
สรุปประวัติการสนทนา (Summarise the history) แทนที่เทิร์นเก่าด้วยบทสรุปที่กระชับของการตัดสินใจและข้อเท็จจริงที่กำหนดไว้จนถึงตอนนี้ เก็บเทิร์นล่าสุดไว้ตามเดิม — นั่นคือที่ที่หัวข้อทันทีอยู่
แบ่งงาน (Split the task) สองคำขอที่เน้นมักจะดีกว่าหนึ่งคำขอขนาดใหญ่ การสกัดแล้ววิเคราะห์; ต่อเอกสารแล้วรวม
ตัดแต่งเครื่องมือของคุณ (Trim your tools) หากโมเดลต้องการเพียงสามเครื่องมือสำหรับงานนี้ อย่าส่งสามสิบเครื่องมือ
วัดผลก่อนปรับปรุง (Measure before optimising) นับโทเค็นในคำขอจริง ทีมต่างๆ มักจะประหลาดใจที่พบว่าพรอมต์ระบบหรือสคีมาเครื่องมือที่ไม่ได้ใช้ ไม่ใช่เอกสารของผู้ใช้ คือสิ่งที่ใช้พื้นที่ส่วนใหญ่ในหน้าต่าง
หน้าต่างบริบทไม่ใช่คุณสมบัติที่จะเพิ่มให้สูงสุด แต่เป็นงบประมาณที่จะใช้จ่ายอย่างมีสติ
คำถามที่พบบ่อย
- 200,000 โทเคน คอนเท็กซ์ วินโดว์ สามารถใส่คำได้กี่คำ?
- โดยประมาณ 150,000 คำของภาษาอังกฤษ หรือประมาณ 500 หน้าของเนื้อหาแบบปกติ หนังสือภาษาเกาหลี ญี่ปุ่น และจีนใช้โทเคนต่ออักษรมากกว่า ดังนั้นคุณควรคาดหวังว่าจะมีจำนวนหน้าที่น้อยลงอย่างมากสำหรับขีดจำกัดเดียวกัน
- การขยายขนาดหน้าต่างบริบททำให้ไม่จำเป็นต้องใช้ RAG หรือไม่?
- ไม่. หน้าต่างขนาดใหญ่ทำให้การเรียกข้อมูลทำได้ง่ายขึ้น แต่การส่ง 500 หน้าทุกครั้งทำให้ช้าและมีค่าใช้จ่ายสูง และความแม่นยำยังคงลดลงในส่วนกลางของข้อมูลที่ยาวมาก การเรียกข้อมูลช่วยให้การร้องขอเล็กและเจาะจง
- เมื่อการสนทนาเกินขอบเขตจะเกิดอะไรขึ้น?
- แอปพลิเคชันต้องทำการแทรกแซง — โดยปกติทำโดยการลบการสนทนาที่เก่าที่สุด สรุปสาระสำคัญของมัน หรือย้ายไปเก็บในสโตร์การเรียกคืน ขณะที่โมเดลเองก็ไม่สามารถมองเห็นอะไรที่อยู่นอกหน้าต่างได้
- ทำไมการสนทนาที่ยาวนานของฉันถึงมีค่าใช้จ่ายเพิ่มขึ้นตามเวลา?
- ส่วนใหญ่ของอินเทอร์เฟซ API จะส่งข้อความทั้งหมดของการสนทนาทุกครั้ง ทำให้ข้อมูลป้อนเข้าเพิ่มขึ้นเรื่อย ๆ เมื่อมีการแลกเปลี่ยนแต่ละครั้ง การใช้การเก็บชั่วคราวของคำสั่ง (prompt caching) ช่วยลดค่าใช้จ่ายของคำนำที่ซ้ำกัน แต่โทเคนยังคงถูกประมวลผลต่อไป