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

เพื่อสร้างระบบที่ยังคงความน่าเชื่อถือและตอบสนองได้ดี คุณจำเป็นต้องเข้าใจพื้นฐานสามประการ: tokens, context windows และความแตกต่างระหว่าง context และ memory

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

token ไม่ใช่คำ เมื่อคุณส่งข้อความไปยังโมเดล ตัว tokenizer จะย่อยข้อความนั้นออกเป็นชิ้นเล็กๆ คำสั้นๆ ที่ใช้บ่อยอย่าง "cat" หรือ "the" อาจใช้เพียงหนึ่ง token แต่คำศัพท์ทางเทคนิคที่ซับซ้อนอย่าง "internationalization" จะถูกหั่นออกเป็นหลายส่วน เครื่องหมายวรรคตอน ช่องว่าง และอักขระพิเศษทั้งหมดก็นับเป็น token เช่นกัน เรื่องนี้สำคัญเพราะ token เป็นตัวกำหนดทุกอย่าง: ทั้งค่าใช้จ่าย API, ความเร็วในการตอบสนอง และคุณภาพของผลลัพธ์

นักพัฒนาที่วางแผนต้นทุนด้วยการนับจำนวนคำกำลังทำงานแบบไร้ทิศทาง Prompt ความยาวร้อยคำที่เต็มไปด้วยวงเล็บโค้ดและชื่อตัวแปรยาวๆ อาจทำให้ค่าใช้จ่ายพุ่งสูงเกินกว่าที่คาดไว้ นี่คือเหตุผลที่ tokenizer มีอยู่ในฐานะเครื่องมือแยกต่างหาก ก่อนที่คุณจะปล่อยฟีเจอร์ใหม่ ให้ลองนำข้อมูล (payloads) ที่ใช้งานจริงผ่าน tokenizer ดูก่อน คุณมักจะพบว่าคำสั่งระบบ (system instructions), รูปแบบมาตรฐาน (formatting boilerplate) และประวัติการแชท กินงบประมาณของคุณมากกว่าคำถามจริงของผู้ใช้เสียอีก จงปฏิบัติกับ token ในฐานะทรัพยากรที่มีจำกัดตั้งแต่วันแรก

Context Window คือไวท์บอร์ดที่มีพื้นที่จำกัด

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

โมเดลสมัยใหม่โฆษณาว่ามี context windows ตั้งแต่ไม่กี่พัน token ไปจนถึงหลายแสน token มันเป็นเรื่องง่ายที่จะมองว่าหน้าต่างที่ใหญ่กว่าหมายถึงพื้นที่จัดเก็บข้อมูลที่ไม่จำกัด แต่มันไม่ใช่ ไวท์บอร์ดก็ยังมีขอบเขต เมื่อประวัติการสนทนาเกินขีดจำกัด แอปพลิเคชันจะต้องลบข้อความเก่าออกหรือทำการบีบอัดข้อมูล การเข้าใจข้อจำกัดนี้จะช่วยให้คุณเลิกปฏิบัติกับ window เหมือนเป็นฐานข้อมูล และเริ่มปฏิบัติกับมันในฐานะพื้นที่ทำงานที่ใช้งานจริง (active workspace)

Context ไม่ใช่ Memory

นี่คือความแตกต่างที่ทำให้แม้แต่นักพัฒนาที่มีประสบการณ์ยังสับสน ตัวโมเดลเองนั้นเป็นแบบ stateless มันไม่จำคุณจากเมื่อวาน, เมื่อสัปดาห์ที่แล้ว หรือเมื่อสิบนาทีก่อนในเซสชันอื่น เมื่อ AI ดูเหมือนจะจำได้ว่าคุณชอบ Python มากกว่า JavaScript หรือคุณชอบคำตอบที่กระชับ ความจำนั้นอยู่ที่เลเยอร์ของแอปพลิเคชัน (application layer) ไม่ใช่ที่ตัวโมเดล

แอปพลิเคชันจะเก็บข้อเท็จจริงเหล่านั้นไว้ในฐานข้อมูล, cache หรือหน่วยเก็บความจำ (memory store) ในทุกๆ การร้องขอใหม่ แอปพลิเคชันจะฉีด (inject) ข้อมูลโปรไฟล์ที่เกี่ยวข้องกลับเข้าไปใน prompt โมเดลเป็นเพียงผู้อ่านบทละครที่มีบทพูดของมันจากองก์ที่หนึ่งเท่านั้น มันไม่มีตัวตนที่คงอยู่ถาวร เมื่อคุณเข้าใจการแยกส่วนนี้ สถาปัตยกรรมของคุณจะเปลี่ยนไป คุณจะเลิกขอให้โมเดลจำ และเริ่มออกแบบระบบที่ดึง context ที่ถูกต้องมาใช้ในเวลาที่เหมาะสมแทน

ทำไมการมี Context มากเกินไปอาจส่งผลเสีย

สามัญสำนึกบอกเราว่าข้อมูลพื้นฐานที่มากขึ้นควรจะให้คำตอบที่ดีขึ้น แต่บ่อยครั้งที่ผลลัพธ์กลับตรงกันข้าม Context ที่มากเกินไปจะสร้างสัญญาณรบกวน (noise) หากคุณส่งโค้ดทั้งโปรเจกต์ให้โมเดลในขณะที่คุณต้องการแค่การแก้ไขฟังก์ชันเดียว คุณกำลังบังคับให้มันต้องควานหาสัญญาณท่ามกลางเสียงรบกวน นักวิจัยได้ระบุถึงปรากฏการณ์ "Lost in the Middle" ซึ่งโมเดลมักจะให้ความสำคัญกับรายละเอียดที่ต้นและท้ายของ prompt มากกว่า ในขณะที่ข้อมูลที่ถูกฝังไว้ตรงกลางจะถูกลดความสำคัญหรือถูกละเลย นี่ไม่ใช่บั๊กที่คุณจะแก้ไขได้ด้วยการใช้คำพูดที่ฉลาด แต่มันคือพฤติกรรมเชิงโครงสร้างที่มีอยู่ในสถาปัตยกรรมแบบ transformer

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

วิธีการทำ Context Engineering ให้ดียิ่งขึ้น

การทำ context engineering ที่ดีคือการฝึกฝนการตัดทอนอย่างเด็ดขาด และนี่คือวิธีนำไปปฏิบัติจริง

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

ใช้ RAG เพื่อดึงเอกสารที่เกี่ยวข้อง Retrieval-Augmented Generation ช่วยให้คุณค้นหาฐานความรู้ขนาดใหญ่และใส่เฉพาะข้อความที่ตรงกันมากที่สุดลงใน prompt แทนที่จะเทคู่มือหนาพันหน้าลงในหน้าต่างแชท คุณสามารถทำ embedding เอกสารของคุณ รัน semantic search เพื่อค้นหาตามคำถามของผู้ใช้ และใส่เฉพาะย่อหน้าที่เกี่ยวข้องที่สุดสามย่อหน้าลงไป วิธีนี้จะทำให้โมเดลได้รับสิ่งที่ต้องการพอดี และช่วยรักษาจำนวน token ให้อยู่ในงบประมาณที่กำหนด

สรุปบทสนทนาเก่า ประวัติการแชทแบบเต็มรูปแบบนั้นมีราคาแพงและสร้างสัญญาณรบกวน (noise) ให้เปลี่ยนประวัติข้อความที่ยาวเหยียดให้เป็นสรุปแบบต่อเนื่อง ตัวอย่างเช่น แทนที่จะป้อนข้อความโต้ตอบกันไปมาถึงสามสิบข้อความให้โมเดล ให้เก็บเป็นย่อหน้าเดียวแทน เช่น: "ผู้ใช้ถามเกี่ยวกับการ deploy Django, พบข้อผิดพลาดเรื่อง static files และแก้ไขเรื่อง permissions แล้ว ปัญหาปัจจุบันคือการทำ database migration ล้มเหลวบน Postgres 14" การสรุปแบบนี้จะช่วยรักษาข้อมูลสถานะ (state) ไว้ได้โดยไม่ทำให้ข้อมูลรกจนเกินไป

แยกหน่วยความจำระยะยาวออกจากแชทที่กำลังใช้งาน ความชอบของผู้ใช้ การตั้งค่าโปรเจกต์ และประวัติบัญชี ควรถูกเก็บไว้ในหน่วยความจำภายนอก (external memory store) และทำการ query ข้อมูลจากที่นั่นอย่างเฉพาะเจาะจง หน้าต่าง context ที่ใช้งานอยู่ควรมีเพียงงานที่กำลังทำอยู่และบริบทส่วนตัวที่สั้นที่สุดเท่าที่จำเป็นเพื่อรักษาความต่อเนื่อง

ตรวจสอบการใช้งาน token ในระบบ production การที่ latency พุ่งสูงขึ้นมักมีสาเหตุโดยตรงมาจาก context ที่บวมเกินไป (context bloat) ควรตั้งการแจ้งเตือนเมื่อคำขอเข้าใกล้ขีดจำกัดของโมเดล ตรวจสอบ log เพื่อระบุ prompt ที่มีข้อมูลส่วนเกินที่ไม่จำเป็น การเพิ่มประสิทธิภาพเริ่มต้นด้วยคำถามเดิมเสมอคือ: เราสามารถตัดอะไรออกได้บ้างโดยไม่ทำให้งานเสีย?

บทสรุปที่แท้จริง

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

Source: AI Context Engineering: Tokens, Context Windows, & Memory

Community: GyaanSetu AI on Telegram