เอเจนต์ที่ขับเคลื่อนด้วย LLM ของคุณอาจทำงานได้อย่างสมบูรณ์แบบในการสาธิต (demo) แต่กลับทำงานช้าลงและทำให้ค่าใช้จ่ายพุ่งสูงขึ้นหลังจากใช้งานไปเพียงไม่กี่รอบ ตัวการที่ซ่อนอยู่ไม่ใช่โมเดลที่ไม่เสถียร แต่คือ token drift หรือการบวมขึ้นอย่างช้าๆ ของ prompt ที่โมเดลต้องประมวลผลในทุกๆ ครั้ง
Token drift เกิดขึ้นเมื่อทุกการโต้ตอบมีการเพิ่มข้อความเข้าไปใน context ของ input โมเดลมากขึ้นเรื่อยๆ ทั้งประวัติการสนทนา, tool schemas, การตอบกลับจาก API และเอกสารที่ดึงมา (retrieved documents) ทั้งหมดนี้จะสะสมเพิ่มขึ้น ทำให้การเรียกใช้งานในครั้งต่อๆ ไปมี payload ที่ใหญ่ขึ้น เนื่องจากเวลาในการประมวลผลและราคาของโมเดลจะเพิ่มขึ้นตามจำนวน input tokens ดังนั้นค่าใช้จ่ายจึงเพิ่มขึ้นแบบ ทวีคูณ (quadratically) แทนที่จะเป็นแบบเส้นตรง (linearly)
ทำไมปัญหานี้ถึงปรากฏในขั้นตอนการใช้งานจริง (production) แต่ไม่พบในการสาธิต (demo)
การใช้งานจริงจะเก็บรักษาทุกอย่างไว้ ทั้งคำพูดของผู้ใช้ทุกคำ, ผลลัพธ์จากเครื่องมือทุกอย่าง และข้อมูลความรู้ที่ดึงมาทุกส่วน การสะสมเหล่านี้จะถูกซ่อนไว้จนกว่าค่าความหน่วง (latency) จะพุ่งสูงขึ้นและใบแจ้งหนี้ส่งมาถึง
สาเหตุทั่วไปที่ทำให้เกิด token drift
- การเก็บประวัติการสนทนาซ้ำซ้อน – การเก็บข้อความเก่าทุกข้อความไว้ใน prompt แทนที่จะสรุปหรือลบทิ้ง
- tool schemas ที่หนักเกินไป – การส่งคำจำกัดความ JSON ขนาดใหญ่ของความสามารถของเครื่องมือในทุกๆ รอบการทำงาน
- ผลลัพธ์จากเครื่องมือที่มีขนาดใหญ่ – การรวมการตอบกลับจาก API แบบเต็มรูปแบบหรือแถวในฐานข้อมูลที่มีข้อมูลมากกว่าที่เอเจนต์จำเป็นต้องใช้จริง
- RAG ที่บวมเกินไป – การทำ Retrieval-augmented generation (RAG) ที่เพิ่มชิ้นส่วนเอกสาร (document chunks) จำนวนมาก ซึ่งบางส่วนอาจล้าสมัยหรือไม่เกี่ยวข้อง
- หน่วยความจำที่ซ้ำซ้อน – การใส่ทั้งบทสรุป, state object และประวัติการสนทนาแบบดิบรวมเข้าด้วยกัน ซึ่งเป็นการทำข้อมูลเดิมซ้ำถึงสามครั้ง
สิ่งเหล่านี้ล้วนเพิ่มจำนวน token โดยไม่ได้ช่วยเพิ่มความสามารถในการใช้เหตุผล (reasoning power) แต่กลับทำให้ขนาดของ prompt ใหญ่ขึ้น
วิธีควบคุมงบประมาณ token ให้เหมาะสม
1. ใช้การออกแบบ context แบบแบ่งชั้น (layered context design)
- คำสั่งที่คงที่ (Stable instructions) – เก็บ system prompts และกฎความปลอดภัยไว้ที่ส่วนบนสุดและใช้วิธีอ้างอิงแทนการส่งซ้ำในทุกรอบ
- สถานะที่มีโครงสร้าง (Structured state) – จัดเก็บข้อมูลเป้าหมาย, การตัดสินใจ และตัวระบุ (identifiers) ในรูปแบบที่กระชับเพื่อให้เอเจนต์อ่านได้อย่างรวดเร็ว
- ประวัติที่ถูกบีบอัด (Compressed history) – สรุปการสนทนาในรอบเก่าๆ ให้เป็นย่อหน้าสั้นๆ ที่มนุษย์อ่านเข้าใจ และอัปเดตเฉพาะเมื่อถึงเกณฑ์ที่กำหนดเท่านั้น
- การสนทนารอบล่าสุด (Recent turns) – ใส่ข้อความล่าสุดไม่กี่ข้อความแบบคำต่อคำเพื่อรักษาความต่อเนื่อง
การแยกข้อความที่คงที่ออกจากเนื้อหาที่สรุปได้ จะช่วยป้องกันไม่ให้คุณต้องส่งคำเดิมซ้ำไปซ้ำมา
2. ตัดทอนผลลัพธ์ของเครื่องมือ (Trim tool outputs)
- ดึงเฉพาะฟิลด์ที่เอเจนต์ใช้งานจริง และตัดคำอธิบายที่เยิ่นเย้อออก
- แทนที่ผลลัพธ์ขนาดใหญ่ด้วยบทสรุปที่กระชับหรือ reference ID และเก็บ payload ฉบับเต็มไว้ในฐานข้อมูล, cache หรือ blob store
- เมื่อเครื่องมือส่งคืนรายการ (list) ให้ส่งเฉพาะรายการ N อันดับแรกที่มีความสำคัญต่อการตัดสินใจในขณะนั้น
3. ใช้การสรุปความอย่างชาญฉลาด (Apply smart summarization)
- ไม่ต้องสรุปความหลังจบทุกรอบ เพราะการประมวลผลที่เพิ่มขึ้นจะกลายเป็นภาระ (overhead)
- อัปเดตบทสรุปเฉพาะเมื่อจำนวน token สะสมของการสนทนารอบเก่าๆ เกินขีดจำกัดที่ตั้งไว้เท่านั้น
- เก็บข้อเท็จจริงที่สำคัญ เช่น ID, จำนวนเงิน, หรือ timestamp ไว้ในที่เก็บข้อมูลที่มีโครงสร้าง แทนที่จะฝังไว้ในเนื้อความ เพื่อให้บทสรุปยังคงสั้นกระชับ
4. ติดตามตัวชี้วัดที่ถูกต้อง (Track the right metrics)
- บันทึกการใช้งาน token ต่อการเรียกโมเดลหนึ่งครั้ง (per model call) ไม่ใช่แค่ต่อหนึ่งคำขอของผู้ใช้ วิธีนี้จะช่วยให้เห็นการเติบโตที่ซ่อนอยู่ทางฝั่ง input
- ตรวจสอบจำนวน input tokens ที่เพิ่มขึ้นในแต่ละรอบ หากมีการกระโดดขึ้นอย่างกะทันหัน แสดงว่าพบแหล่งที่มาของ drift แล้ว
- แยก cached tokens (ที่นำกลับมาใช้ใหม่จากการเรียกครั้งก่อน) ออกจาก tokens ที่สร้างขึ้นใหม่ เพราะเฉพาะส่วนแรกเท่านั้นที่เป็นตัวขับเคลื่อน drift
จงมองว่า prompt คือทรัพยากรที่มีจำกัด ไม่ใช่ประวัติการสนทนาที่ไม่มีที่สิ้นสุด การวัดผล, การสรุปความ และการตัดทอนอย่างมีเป้าหมาย จะช่วยให้เอเจนต์ LLM ของคุณทำงานได้รวดเร็ว, ประหยัดค่าใช้จ่าย และพร้อมสำหรับการขยายขนาดในระดับ production
บทสรุป: Token drift แอบเพิ่มค่าใช้จ่ายและทำให้เอเจนต์ทำงานช้าลงโดยไม่รู้ตัว จงระบุส่วนของ prompt ที่กำลังขยายตัวขึ้น แล้วทำการบีบอัดหรือแยกออกไปไว้ภายนอก พร้อมทั้งเฝ้าดูการใช้งาน token ต่อการเรียกใช้งานหนึ่งครั้ง การมีแนวทางที่เคร่งครัดจะเปลี่ยนความตกใจจากค่าใช้จ่ายที่คาดเดาไม่ได้ ให้กลายเป็นการดำเนินงานที่จัดการได้และอยู่ในงบประมาณ