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

นี่คือ "กับดักบริบท" (context trap) นักพัฒนาส่วนใหญ่มักทึกทักเอาเองว่าการป้อนข้อมูลให้ AI มากขึ้นจะช่วยให้ได้ผลลัพธ์ที่ดีขึ้นโดยอัตโนมัติ แต่ในความเป็นจริงมักจะตรงกันข้าม การสร้างแอปพลิเคชัน AI ที่เชื่อถือได้จำเป็นต้องเข้าใจกลไกหลัก 3 ประการ ได้แก่: วิธีที่โมเดลใช้ในการนับข้อความ, ปริมาณข้อมูลที่โมเดลสามารถรับได้ในคราวเดียว และจะเกิดอะไรขึ้นกับข้อมูลเมื่อการสนทนาสิ้นสุดลง

Tokens: สกุลเงินที่แท้จริง

Token คือหน่วยที่เล็กที่สุดที่โมเดลภาษาใช้ในการประมวลผล มันอาจจะเป็นตัวอักษรเพียงตัวเดียว, ส่วนหนึ่งของคำ หรือคำทั่วไปทั้งคำเลยก็ได้ เช่น คำว่า “purchase” มักจะถูกแบ่งออกเป็นสอง tokens ในขณะที่คำสั้นๆ อย่าง “cat” จะถูกนับเป็นหนึ่ง token ทั้งคำ เครื่องหมายวรรคตอนและช่องว่างก็ใช้ tokens เช่นกัน โดยเฉพาะโค้ดนั้น "กิน" tokens มากเป็นพิเศษ บล็อกของ Python ที่มีการย่อหน้าซ้อนกันและมีตัวอักษรพิเศษอาจทำให้จำนวน token พุ่งสูงขึ้นถึงสามหรือสี่เท่าของจำนวนที่คุณคาดการณ์ไว้จากการมองด้วยตาเปล่า

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

Context Window คือไวท์บอร์ด

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

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

Memory คือการแก้ปัญหาเฉพาะหน้า ไม่ใช่ฟีเจอร์

ไม่มีความจำแบบถาวร (persistent memory) อยู่ภายในน้ำหนักของโมเดล (model weights) ระหว่างการประมวลผล (inference) เลยแม้แต่น้อย เมื่อคุณปิดแท็บไปแล้วกลับมาใหม่ในวันพรุ่งนี้ โมเดลจะไม่รู้จักคุณ การเรียกใช้ API แต่ละครั้งคือการเริ่มต้นใหม่จากศูนย์ (cold start)

สิ่งที่ให้ความรู้สึกเหมือนความจำ แท้จริงแล้วเป็นเพียงการจัดการข้อมูลอย่างชาญฉลาดโดยเลเยอร์ของแอปพลิเคชัน (application layer) ฝั่ง frontend จะเก็บข้อความของคุณไว้ในฐานข้อมูล เมื่อคุณส่งคำถามใหม่ ซอฟต์แวร์จะดึงประวัติที่เกี่ยวข้องมาประกอบเข้ากับพรอมต์ใหม่ แล้วส่งแพ็กเกจทั้งหมดนั้นไปยังโมเดล ตัวโมเดลเองไม่ได้รับรู้ถึงเรื่องนี้เลย

ความแตกต่างนี้สำคัญมากสำหรับทีมพัฒนาผลิตภัณฑ์ หากคุณฝากความหวังไว้กับโมเดลเพื่อให้ "จำ" ความชอบของผู้ใช้ คุณกำลังสร้างบ้านบนพื้นทราย คุณจำเป็นต้องสร้างระบบจัดการสถานะ (state management) ด้วยตัวเอง ตัดสินใจว่าจะเก็บข้อมูลอะไรไว้ในแคช (cache) ตัดสินใจว่าจะรีเฟรชข้อมูลอย่างไร และต้องตระหนักว่าทุกๆ ไบต์ของประวัติที่คุณส่งกลับไปใหม่ จะไปแย่งพื้นที่บนไวท์บอร์ดของคุณ

เมื่อบริบทกลายเป็นสัญญาณรบกวน

การอัดข้อมูลใส่พรอมต์มากเกินไปจะส่งผลเสียในรูปแบบที่คาดเดาได้

สัญญาณรบกวนจะทำลายสัญญาณสำคัญ หากคุณเทโค้ดทั้งโปรเจกต์ลงไปเพื่อถามเกี่ยวกับบั๊กเพียงจุดเดียว โมเดลจะต้องเผชิญกับปัญหา "งมเข็มในมหาสมุทร" (needle-in-a-haystack) มันอาจจะอ้างอิงไฟล์ผิดไฟล์ แนะนำให้แก้ไขโค้ดที่ไม่ได้ใช้งานแล้ว หรือให้คำตอบแบบกว้างๆ ทั่วไป เพราะมันไม่สามารถ