เมื่อ AI ตอบหลุดเรื่องหรือจำสิ่งที่คุยก่อนหน้าไม่ได้ เราอาจคิดว่าต้องเปลี่ยนโมเดลให้เก่งกว่า แต่ Louis-François Bouchard เสนอให้ตรวจข้อมูลที่โมเดลเห็นก่อนตอบด้วย บทเรียนจากงานทดลองของ Towards AI คือ วิธีจัดการ context หรือข้อมูลประกอบคำตอบ อาจเปลี่ยนทั้งความจำ ต้นทุน และความเร็วของระบบได้
คลิปจากช่อง AI Engineer โดย Louis-François Bouchard, Omar Solano และ Samridhi Vaid นำ AI tutor หรือผู้ช่วยสอนที่ทีมพัฒนามาเปรียบเทียบวิธีจัดการประวัติการสนทนา 11 แบบ ทีมรายงานว่า การไม่ย่อและเก็บประวัติเดิมไว้ให้ผลด้านความจำ ต้นทุน และความเร็วดีกว่าหลายวิธีในเงื่อนไขที่ทดสอบ ส่วนหนึ่งมาจาก prompt caching ซึ่งนำข้อมูลที่เคยประมวลผลแล้วกลับมาใช้ได้
สำหรับคนทำ chatbot หรือผู้ช่วยตอบลูกค้า บทเรียนนี้เป็นเหตุผลให้ทดสอบการสรุปประวัติก่อนเปิดใช้จริง การลดจำนวนข้อความอาจประหยัดพื้นที่ แต่ก็อาจทำรายละเอียดหายหรือเสียประโยชน์จาก cache ได้ ผลของทีมนี้จึงเป็นจุดตั้งต้นสำหรับทดลองกับระบบของเราเอง
แยกให้ออกว่า AI ตอบพลาดเพราะโมเดลหรือข้อมูลที่เห็น
Context คือข้อมูลทั้งหมดที่ AI ได้เห็นก่อนตอบ ไม่ใช่แค่คำถามล่าสุด แต่รวมถึง system prompt หรือคำสั่งหลัก กติกาการทำงาน ประวัติแชต เอกสารที่ดึงจากฐานความรู้ ผลลัพธ์จากเครื่องมือ และไฟล์หรือบันทึกการทำงานที่ผู้ใช้ส่งเข้ามา
AI tutor ของ Towards AI ต้องตอบจากเนื้อหาคอร์สที่ถูกต้อง รองรับบทสนทนายาว ช่วยแก้โค้ดได้ และตอบเร็วพอที่จะไม่ทำให้การใช้งานสะดุด แต่ทุกองค์ประกอบต้องแย่งพื้นที่ใน context window หรือขนาดข้อมูลสูงสุดที่โมเดลรับได้ในแต่ละครั้ง การสะสมผลลัพธ์จากเครื่องมือและเอกสารยาวจึงเป็นสิ่งที่ทีมต้องวัดผลต่อคุณภาพ ต้นทุน และเวลารอตอบ
อย่างไรก็ตาม context ยาวไม่ได้ทำให้ผลแย่ลงในทุกการทดสอบของทีม โดยเฉพาะการค้นข้อเท็จจริงที่แยกแยะได้ชัด ผลนี้ยังไม่ยืนยันว่าแชตยาวจะทำงานดีในทุกกรณี สิ่งที่ควรวัดคือ AI ยังตอบโจทย์ได้หรือไม่ จำรายละเอียดสำคัญได้หรือไม่ และต้นทุนต่อคำตอบเปลี่ยนไปอย่างไร
ตัวอย่างการนำไปคิดต่อคือผู้ช่วยรับเรื่องลูกค้า หากระบบตัดประวัติเร็วเกินไป มันอาจไม่เหลือรุ่นสินค้า สิ่งที่ลูกค้าลองแก้ไปแล้ว หรือเงื่อนไขที่คุยกันไว้ นี่เป็นสถานการณ์สมมติเพื่อออกแบบการทดสอบ ไม่ใช่ผลที่ Towards AI ทดสอบกับงานบริการลูกค้า
เริ่มจากโจทย์ธุรกิจ ไม่ใช่เริ่มจากเทคนิค compaction
Context engineering คือการตัดสินใจว่า ในแต่ละครั้งที่เรียกโมเดล เราจะให้ AI เห็นอะไร เก็บอะไร ตัดอะไร สรุปอะไร และดึงอะไรกลับมาเมื่อจำเป็น ส่วน compaction คือการทำข้อมูลให้สั้นลง เช่น ตัดข้อความเก่า เก็บเฉพาะช่วงท้าย สรุปบทสนทนา หรือให้โมเดลเลือกข้อมูลที่ควรเก็บ
เทคนิคพื้นฐานที่ไม่ต้องเรียกโมเดลภาษาเพิ่ม ได้แก่ การตัดผลลัพธ์จากเครื่องมือที่ยาวผิดปกติ โดยเก็บส่วนต้นและท้ายแล้วระบุว่าตัดข้อมูลแล้ว การใช้ sliding window หรือเก็บเฉพาะจำนวนรอบสนทนาล่าสุด และการลบผลลัพธ์จากเครื่องมือที่ไม่จำเป็นแล้ว
ส่วนเทคนิคที่ใช้โมเดลภาษา ได้แก่ การสรุปเป็นระยะ selective retention ที่ให้โมเดลเลือกว่าจะจำอะไร และ delta summarization ที่ค่อย ๆ อัปเดตบทสรุปเดิม ผู้พูดอธิบายว่าแต่ละวิธีควรถูกเลือกตามงานและข้อจำกัด ไม่ใช่เปิดทุกวิธีเป็นค่าเริ่มต้น
เมื่อนำไปใช้กับธุรกิจ ควรระบุข้อจำกัดที่ต้องแก้ให้ชัดก่อน เช่น
- ค่า API ต่อเดือนเกินงบที่ตั้งไว้
- ขนาดข้อมูลที่โมเดลหรือเครื่องที่ใช้รองรับไม่พอ
- เวลารอคำตอบยาวเกินมาตรฐานบริการ
- AI ดึงข้อมูลที่จำเป็นไม่พบในฐานความรู้
- มีเงื่อนไขการเก็บข้อมูลของระบบที่ต้องพิจารณาก่อนเลือก cloud หรือ local
ข้อเสนอหลักของทีม Towards AI คือ อย่า compact เพียงเพราะคิดว่าระบบ AI ควรทำแบบนั้น ให้เริ่มจากข้อจำกัดที่วัดได้ แล้วเปรียบเทียบวิธีแก้
เข้าใจ prompt caching ก่อนรีบสรุปแชต
Prompt caching คือการนำส่วนของข้อมูลที่เคยประมวลผลและส่งซ้ำกลับมาใช้ ผู้พูดอธิบายว่าข้อมูลที่ใช้ cache ได้อาจมีต้นทุนต่ำกว่า และช่วยลดเวลาจนเริ่มได้คำตอบ โดยรายละเอียดขึ้นกับผู้ให้บริการและการตั้งค่าระบบ
จุดที่ต้องระวังคือ เมื่อสรุปหรือเขียนข้อมูลเดิมใหม่ ส่วนที่เปลี่ยนไปอาจใช้ cache เดิมไม่ได้ การสรุปจึงอาจมีทั้งค่าเรียกโมเดลเพื่อสรุป และค่าประมวลผลข้อความใหม่ในรอบถัดไป ต้องวัดผลรวมก่อนสรุปว่า token ที่น้อยลงทำให้ต้นทุนลดลง
ทีมรายงานว่า ในเงื่อนไข API ที่ใช้ทดลอง token ที่ใช้ cache ได้มีต้นทุนต่ำกว่าถึงประมาณ 50 เท่า ตัวเลขนี้เป็นสิ่งที่ทีมเล่าในวิดีโอ ไม่ใช่ราคาปัจจุบันที่ตรวจสอบใหม่ในบทความนี้ เมื่อส่วนลด cache สูง การย่อข้อมูลจึงต้องประหยัดพอชดเชยต้นทุนที่เพิ่มจากข้อความใหม่ด้วย
ผลที่ทีมรายงานทำให้การดูจำนวน token เพียงอย่างเดียวอาจไม่พอ ระบบที่ส่งข้อมูลมากกว่าอาจมีต้นทุนต่ำกว่าได้ หากส่วนใหญ่ใช้ cache เดิม การเปรียบเทียบจึงควรดูต้นทุนต่อบทสนทนาและสัดส่วนข้อมูลที่ใช้ cache ได้ควบคู่กัน
รายละเอียดการรองรับ cache ต่างกันตามผู้ให้บริการและโมเดล ควรตรวจเอกสารของ API ที่ใช้อยู่และทดลองกับการใช้งานจริงของเราเอง
สร้างฐานความรู้ด้วย retrieval แบบผสม
ทีมระบุว่า AI tutor มีคลังเนื้อหามากกว่า 8 ล้าน token ซึ่งเกินขนาดที่ส่งเข้าโมเดลได้ในครั้งเดียว ระบบจึงใช้ hybrid search หรือการค้นหาแบบผสม โดยรวม semantic search ที่ค้นตามความหมายกับ BM25 ที่ค้นตามคำสำคัญ จากนั้นรวมผล จัดอันดับใหม่ และส่งเฉพาะเนื้อหาที่เกี่ยวข้องกลับเข้าไป
ตัวอย่างการประยุกต์คือการนำคู่มือสินค้า FAQ และเอกสารอบรมเข้า knowledge base หรือฐานความรู้ แล้วให้ AI ดึงเฉพาะส่วนที่เกี่ยวข้องกับคำถาม แทนการแนบเอกสารทั้งหมดทุกครั้ง นี่เป็นข้อเสนอให้ทดลองต่อจากวิธีของทีม
ในการทดลองค้นข้อเท็จจริงที่ฝังอยู่ในเอกสารยาว ทีมรายงานว่า เมื่อข้อมูลเพิ่มถึง 400,000 token การค้นตามความหมายอย่างเดียวมี recall หรือสัดส่วนข้อมูลที่ค้นพบ ลดลงเหลือ 0% ขณะที่ BM25 ยังพบครบในการทดลองนั้น ผลนี้เป็นเหตุผลให้ทดสอบการค้นแบบผสมกับข้อมูลที่มีคำเฉพาะ ไม่ใช่หลักประกันว่า BM25 จะพบครบในทุกฐานความรู้
ทีมยังทดลองให้ agent เปิดอ่านไฟล์ในฐานความรู้เอง ผลที่รายงานจากคำถามของนักเรียนคือ recall ไม่ดีขึ้นจากเครื่องมือค้นเดิม แต่ช้าลงประมาณ 50% ทีมคาดว่าคำถามชุดนี้อาจยังไม่ซับซ้อนพอที่จะได้ประโยชน์จากเครื่องมือเพิ่ม จึงควรวัดผลกับชนิดคำถามที่จะใช้งานจริง
บทเรียนจากกรณีนี้คือ ก่อนเพิ่มเครื่องมือ ควรวัดว่าคำตอบดีขึ้นพอชดเชยเวลา ต้นทุน และความซับซ้อนที่เพิ่มหรือไม่
วัดผลด้วยเคสจริงก่อนเปลี่ยนระบบที่ใช้งานอยู่
ทีมประเมินทั้งการดึงเอกสารถูกหรือไม่ ข้อเท็จจริงในคำตอบ ความสามารถในการจำข้อมูลหลังคุยหลายรอบ ต้นทุน token ที่ใช้ cache ได้ เวลาเริ่มได้คำตอบ และจำนวนครั้งที่เรียกเครื่องมือ ชุดคำถามครั้งเดียวใช้ 60 คู่คำถามและคำตอบจริงที่คัดแล้ว ส่วนการทดสอบความจำหลายรอบมีข้อเท็จจริงและข้อความคั่นที่สร้างขึ้นเพื่อทดสอบโดยเฉพาะ
ผลแรกจากการตั้งค่า 11 แบบใช้โมเดล คำสั่ง เครื่องมือ และชุดข้อมูลเดียวกัน ทีมรายงานว่า การเก็บประวัติทั้งหมดให้ recall ดีกว่า ต้นทุนต่ำกว่า และเร็วกว่าในการสนทนาที่ทดสอบราว 11–13 รอบ เหตุผลที่ทีมเสนอคือ การลบผลลัพธ์จากเครื่องมือทำให้ AI ต้องค้นข้อมูลเดิมซ้ำ อย่างไรก็ตาม ผู้พูดระบุว่ารอบทดลองแรกมีเพียงหนึ่งและสองครั้ง ตัวเลขจึงยังมีข้อจำกัด
ในการทดลองต่อยอดที่ถามรายละเอียดเฉพาะจากบทสนทนา Samridhi Vaid รายงานว่า การเก็บประวัติทั้งหมดตอบถูกประมาณ 95% เทียบกับประมาณ 32% เมื่อสรุปหรือ compact ก่อน ทีมอธิบายว่ารายละเอียดเล็ก ๆ ถูกตัดจากบทสรุป ตัวเลขนี้เป็นผลที่ผู้พูดรายงานในชุดทดลองของตน ยังไม่ได้ตรวจซ้ำอย่างอิสระหรือยืนยันว่าจะได้ผลเดียวกันในทุกระบบ
ทีมรายงานด้วยว่า การค้นข้อเท็จจริงที่แยกแยะได้ชัดยังให้ผลสม่ำเสมอเมื่อข้อมูลยาวถึง 800,000 token แต่ข้อเท็จจริงที่กำกวมให้ผลแย่ลง การค้นรายละเอียดเดี่ยวได้จึงไม่ใช่หลักฐานว่าโมเดลจะเข้าใจข้อมูลทั้งชุดหรือทำงานทุกชนิดได้ดีเมื่อข้อมูลยาว
เลือกทางต่างกันสำหรับ cloud และ local
ในงานของทีม การเก็บประวัติบน cloud ที่ใช้ cache ได้ดีเป็นทางเลือกที่ให้ทั้งความจำและต้นทุนตามที่ต้องการ Samridhi Vaid ระบุว่าเลือก DeepSeek V4 Flash สำหรับระบบของตน ในผลทดลองหนึ่งมี token ประมาณ 97% ที่ใช้ cache ได้ จึงทำให้การส่งประวัติทั้งหมดมีต้นทุนต่ำกว่าการย่อ แม้ส่ง token มากกว่า
การเลือกสุดท้ายของทีมยังมีเงื่อนไข: ใช้ hybrid retrieval และเก็บประวัติไว้ก่อนถึงเกณฑ์ 30,000 token จากนั้นจึง compact ตามการตั้งค่าที่ผู้พูดเล่าช่วงท้าย ไม่ใช่ปล่อยประวัติให้โตโดยไม่มีขีดจำกัด
แต่ข้อจำกัดเปลี่ยนเมื่อรัน local หรือรันโมเดลบนเครื่องของทีมเอง ในการตั้งค่าที่ทดลองบน MacBook ทีมใช้ขนาดข้อมูลสูงสุดราว 32K token ขณะที่เนื้อหาบางบทเกินขนาดนี้ ผู้พูดระบุว่าการเปลี่ยนจากโมเดล 7B หรือ 8B ไปเป็น 32B ไม่ได้แก้ข้อจำกัดนั้น จึงต้องย่อข้อมูลหรือดึงเฉพาะส่วนที่จำเป็น
เมื่อเก็บข้อมูลทั้งหมดไม่ได้ retrieval หรือการดึงเฉพาะส่วนที่เกี่ยวข้องกลายเป็นทางเลือกสำคัญ ในการทดลองเอกสารบนเครื่องของทีม วิธีนี้ให้ผลดีกว่าการพยายามใส่ข้อมูลเกินขนาดที่รองรับ ซึ่งครั้งหนึ่งใช้เวลาราว 340 วินาทีแล้วได้ผลลัพธ์เพียง token เดียว นี่เป็นผลของการตั้งค่าที่ทีมทดลอง
สิ่งที่นำไปใช้ต่อคือการแยกชนิดงานก่อนเปรียบเทียบ cloud กับ local ทั้งแชตที่ต้องจำรายละเอียด เอกสารที่ผู้ใช้วางเข้ามา และผลลัพธ์จากเครื่องมือ ต้องดูขนาดข้อมูล ต้นทุน และเวลาตอบของระบบจริง ไม่จำเป็นต้องใช้วิธีเดียวกับทุกงาน
สิ่งที่ควรวัดก่อนปรับระบบ
- เก็บบันทึกก่อนปรับคำสั่ง: ดู token ที่ส่งเข้าและตอบออก สัดส่วนที่ใช้ cache ได้ ค่าใช้จ่าย เวลาเริ่มได้คำตอบ จำนวนครั้งที่เรียกเครื่องมือ และความเห็นจากผู้ใช้
- ทดสอบการเก็บประวัติทั้งหมดเป็นตัวเปรียบเทียบ: วัดความจำและต้นทุนก่อนตั้งให้สรุปอัตโนมัติ
- ทดสอบการค้นแบบผสมกับเอกสารธุรกิจ: รวมการค้นตามความหมายและ BM25 แล้วลองคำถามที่มีชื่อสินค้า รหัส รุ่น หรือเงื่อนไขเฉพาะ
- ตัดเฉพาะข้อมูลที่ตรวจแล้วว่าไม่จำเป็น: เช่น บันทึกที่ยาวผิดปกติหรือผลลัพธ์จากเครื่องมือที่ไม่ใช้ต่อ พร้อมวัดว่าการตัดทำให้ต้องค้นซ้ำหรือไม่
- สร้างชุดประเมินจากคำถามที่จะใช้งานจริง: ให้การตั้งค่าแต่ละแบบตอบชุดเดียวกัน แล้วเทียบคุณภาพ ต้นทุน และเวลา
สิ่งที่ควรตรวจเมื่อ AI เริ่มตอบไม่ตรงใจ
ปัญหา: AI ถามข้อมูลเดิมซ้ำหลังคุยนาน
สิ่งที่ควรตรวจ: ระบบตัดประวัติหรือผลลัพธ์จากเครื่องมือจนรายละเอียดเดิมหายไปหรือไม่ เทียบกับบันทึกจริงก่อนสรุปสาเหตุ
แนวทางทดสอบ: เปรียบเทียบกับการเก็บประวัติทั้งหมด วัดความจำในหลายรอบสนทนา แล้วค่อยทดสอบการตัดข้อมูลที่ไม่เกี่ยวข้อง ภายในขนาดที่โมเดลรองรับ
ปัญหา: สรุปแชตแล้วค่า API กลับสูงขึ้น
สิ่งที่ควรตรวจ: ข้อความที่เขียนใหม่ใช้ cache เดิมได้น้อยลงหรือไม่ และค่าเรียกโมเดลเพื่อสรุปเพิ่มเท่าไร
แนวทางทดสอบ: ตรวจสัดส่วนที่ใช้ cache ได้ก่อนและหลังสรุป เปรียบเทียบต้นทุนต่อบทสนทนา แล้วเลือกจังหวะย่อข้อมูลให้เหมาะกับข้อจำกัดที่พบ
ปัญหา: AI หาเงื่อนไขในเอกสารไม่เจอ
สิ่งที่ควรตรวจ: การค้นตามความหมายเพียงแบบเดียวพลาดข้อมูลที่มีคำเฉพาะหรือไม่
แนวทางทดสอบ: เปรียบเทียบกับการค้นแบบผสมที่เพิ่ม BM25 โดยใช้คำถามที่มีชื่อ รหัส รุ่น และข้อความที่อยู่กลางเอกสาร
ปัญหา: เพิ่มเครื่องมือให้ AI เปิดไฟล์เองแล้วตอบช้าลง
สิ่งที่ควรตรวจ: agent เรียกเครื่องมือเพิ่มโดยไม่ทำให้คำตอบดีขึ้นหรือไม่ และคำถามชนิดใดได้ประโยชน์จากการเปิดไฟล์
แนวทางทดสอบ: เปรียบเทียบสัดส่วนข้อมูลที่ค้นพบและเวลาตอบเมื่อเปิดหรือปิดเครื่องมือ แล้วเลือกเส้นทางที่เหมาะกับคำถามจริง
การต่อยอดหลังวางระบบพื้นฐาน
- บันทึกผลการใช้งานและเทียบคุณภาพก่อนเปลี่ยนวิธีจัดการข้อมูล เพื่อให้เห็นทั้งต้นทุน ความเร็ว และคำตอบที่ได้
- พิจารณาเก็บข้อมูลเป็น chunks หรือส่วนย่อยที่เชื่อมกลับไปยังไฟล์ต้นทาง พร้อมดัชนีให้เลือกอ่านเฉพาะข้อมูลที่จำเป็น ตามแนวทางที่ผู้พูดอธิบาย การทดลองหลักในคลิปนี้ยังเน้นการจัดการข้อมูลภายในบทสนทนา
- พิจารณา model routing หรือเลือกโมเดลให้เหมาะกับงาน แล้ววัดต้นทุนและคุณภาพของแต่ละเส้นทาง แทนการคาดว่าโมเดลที่ใหญ่กว่าจะคุ้มกว่าเสมอ
แก่นของ context engineering ในกรณีนี้คือการให้ AI เห็นข้อมูลที่จำเป็นในต้นทุนและเวลาที่รับได้ ข้อสรุปของทีมคืออย่า compact เป็นค่าเริ่มต้นโดยไม่รู้ข้อจำกัด ทั้งนี้ ระบบที่ทีมเลือกสุดท้ายยังตั้งให้ compact เมื่อถึง 30,000 token และเก็บประวัติไว้ก่อนถึงจุดนั้น ผลทดลองจึงเป็นเหตุผลให้วัดก่อนเลือก ไม่ใช่คำแนะนำให้เก็บทุกอย่างไปตลอด
ที่มา: Context Engineering in 2026 โดย Louis-François Bouchard, Omar Solano และ Samridhi Vaid จาก Towards AI บนช่อง AI Engineer วิดีโอเผยแพร่วันที่ 17 สิงหาคม 2569 บทความนี้สรุปจาก transcript ที่บันทึกไว้ช่วง 00:13–1:03:15 ผลและตัวเลขเป็นสิ่งที่ทีมรายงาน ณ เวลานั้น ตัวอย่างธุรกิจและแนวทางทดสอบเป็นข้อเสนอให้ผู้อ่านนำไปทดลอง ไม่ใช่ผลทดสอบเพิ่มเติมของทีม
