Token Trap คืออะไร? วิธีจัดการการใช้งานเพื่อป้องกันค่าใช้จ่ายพุ่งสูงใน AI Agent

Token Trap คือกับดักที่เกิดจากการที่ AI Agent ใช้โทเค็นมากเกินไป จนทำให้ค่าใช้จ่ายแบบ Pay-as-you-go ของ LLM พุ่งสูงขึ้นจนควบคุมไม่ได้ ขีดจำกัดอัตราการใช้งาน (Rate Limit) ของ Cloud LLM เช่น จำนวนโทเค็นที่ประมวลผลได้ต่อนาที มักถูกตั้งค่าไว้สูงมาก และยิ่งขีดจำกัดสูงเท่าใด การใช้งานจำนวนมหาศาลโดยไม่ตั้งใจก็จะยิ่งสังเกตเห็นได้ยากเท่านั้น มีรายงานกรณีที่ค่าใช้จ่ายพุ่งสูงกว่าที่คาดการณ์ไว้หลายสิบเท่า เพียงเพราะเงื่อนไขการหยุดทำงานของ Agent Loop ไม่ชัดเจน หรือมีการสะสมข้อมูลที่ไม่จำเป็นไว้ใน Context Window

บทความนี้มุ่งเน้นไปที่ผู้พัฒนาและผู้ดูแลระบบที่ใช้ LLM โดยเฉพาะ เราจะอธิบายกลไกที่ทำให้เกิดค่าใช้จ่ายพุ่งสูง (Cost Explosion) พร้อมทั้งแนะนำขั้นตอนการจัดการการใช้งานจริง เช่น การตั้งค่าเพดานงบประมาณ (Budget Cap), การทำ Throttling และการทบทวนการออกแบบ Loop

API ของ LLM (Large Language Model) จะคิดค่าบริการตามจำนวนโทเค็นที่ใช้งาน แม้จะดูเป็นกลไกที่เรียบง่าย แต่ก็มีกับดักที่อาจทำให้ต้นทุนพุ่งสูงขึ้นอย่างคาดไม่ถึง ขึ้นอยู่กับการออกแบบ AI Agent ซึ่งความเสี่ยงเชิงโครงสร้างนี้เรียกว่า "Token Trap"

Agent ไม่ได้ทำงานเพียงแค่การอนุมานในครั้งเดียว แต่จะทำงานโดยทำซ้ำหลายขั้นตอน ในกระบวนการดังกล่าว Agent จะต้องดึงการสนทนาที่ผ่านมามาเป็นบริบท (Context) หรือต้องนำผลลัพธ์จากการเรียกใช้เครื่องมือ (Tool) มาฝังลงใน Prompt ซ้ำแล้วซ้ำเล่า เพียงแค่มีจุดบอดในการออกแบบเพียงจุดเดียว ก็อาจทำให้การทำงานของงานหนึ่งชิ้นใช้โทเค็นมากกว่าที่คาดการณ์ไว้หลายเท่า ต่อจากนี้เราจะมาดูกลไกดังกล่าวไปทีละขั้นตอน

ค่าบริการ API ของ LLM จะถูกคำนวณแบบ "จ่ายตามการใช้งานจริงต่อโทเค็น" (Token-based usage billing) โทเค็นคือหน่วยย่อยที่สุดที่เกิดจากการแบ่งข้อความโดย BPE Tokenizer (Byte-Pair Encoding Tokenizer) ซึ่งในภาษาอังกฤษ 1 โทเค็นมีค่าประมาณ 4 ตัวอักษรหรือ 0.75 คำ ส่วนในภาษาญี่ปุ่น 1 ตัวอักษรมักจะมีค่าเทียบเท่ากับ 1-2 โทเค็น

โครงสร้างพื้นฐานของการคิดค่าบริการประกอบด้วย 3 ส่วนดังนี้:

• Input Token: ผลรวมของ Prompt, System Prompt และประวัติการสนทนา
• Output Token: ความยาวของข้อความที่โมเดลสร้างขึ้น
• Rate Limit: มีการกำหนดขีดจำกัดในหลายแกน เช่น RPM, TPM, TPD เมื่อใช้งานเกินขีดจำกัดจะได้รับ Error 429

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

ระดับค่าบริการจะแตกต่างกันไปตามโมเดลและผู้ให้บริการ แต่ในหลายโมเดลนั้น ราคาต่อหน่วยของ Output Token จะถูกตั้งไว้สูงกว่า Input Token หลายเท่า ดังนั้นในเอเจนต์ที่สร้างข้อความยาวๆ ซ้ำๆ ต้นทุนทางฝั่ง Output จึงเป็นสิ่งที่มองข้ามไม่ได้เช่นกัน สำหรับราคาต่อหน่วยล่าสุด โปรดตรวจสอบจากตารางราคาอย่างเป็นทางการของโมเดลที่ใช้งานเสมอ

ยิ่งจำนวนรอบการสนทนา (Conversation Turns) เพิ่มมากขึ้นเท่าใด Context Window ก็จะยิ่งขยายตัวขึ้นอย่างไม่มีที่สิ้นสุด ในการใช้งาน API ส่วนใหญ่ ประวัติข้อความทั้งหมดที่ผ่านมาจะถูกนำไปต่อท้ายในคำขอถัดไปโดยตรง ส่งผลให้จำนวนโทเค็นต่อรอบมีการสะสมเพิ่มขึ้นเรื่อยๆ ตามจำนวนรอบที่ผ่านไป

กลไกการขยายตัวแบบลูกโซ่

• รอบที่ 1: System Prompt + อินพุตของผู้ใช้ = หลายร้อยโทเค็น
• รอบที่ 5: ข้อมูลข้างต้น + ประวัติการสนทนา 4 รอบก่อนหน้า = หลายพันโทเค็น
• รอบที่ 20: ผลลัพธ์จากการเรียกใช้เครื่องมือ (Tool calls) และเอาต์พุตระหว่างทางจะถูกสะสมเพิ่มขึ้น จนในบางกรณีอาจสูงถึงหลายหมื่นโทเค็น

โมเดลส่วนใหญ่มีการตั้งค่าจำนวนโทเค็นขาออกสูงสุด (Default Max Output Tokens) ไว้ หากส่งประวัติการสนทนาที่ยาวทั้งหมดเข้าไป พื้นที่ว่างที่ใช้สำหรับเอาต์พุตจะถูกเบียดบังอย่างรวดเร็ว แม้ขีดจำกัดเอาต์พุตจะสามารถปรับได้ด้วยพารามิเตอร์ในบางกรณี แต่ทางฝั่ง Input นั้น Rate Limit (เช่น TPM) มักถูกตั้งค่าไว้สูงมาก และยิ่งขีดจำกัดสูงเท่าใด การใช้งานจำนวนมากโดยไม่ตั้งใจก็จะยิ่งเกิดขึ้นได้ง่ายเท่านั้น จึงเป็นจุดที่ต้องระมัดระวัง

เมื่อบริบทใกล้ถึงขีดจำกัด ความเสี่ยงที่จะเกิด Hallucination ซึ่งเป็นภาวะที่โมเดล "หลงลืม" ข้อมูลพื้นฐานที่สำคัญก็จะเพิ่มสูงขึ้นด้วย

ผลกระทบโดยตรงต่อต้นทุน

ทั้งโทเค็นขาเข้า (Input tokens) และโทเค็นขาออก (Output tokens) ต่างมีค่าใช้จ่ายในการเรียกใช้งานทั้งสิ้น การออกแบบที่ส่งประวัติการสนทนาทั้งหมดไปพร้อมกันจะทำให้ต้นทุนในการตอบคำถามเดิมเพิ่มขึ้นในทุกๆ รอบที่ผ่านไป

「การรวมเอเจนต์หลายตัวเข้าด้วยกันน่าจะทำให้ระบบทำงานได้ฉลาดกว่าการใช้เอเจนต์เดี่ยว」— ด้วยความคาดหวังเช่นนี้ หลายโครงการที่ออกแบบระบบ Multi-Agent System จึงมักต้องเผชิญกับยอดค่าใช้จ่ายที่พุ่งสูงเกินคาดโดยไม่รู้ตัว

ในระบบ Multi-Agent System การใช้โทเค็นไม่ได้จำกัดอยู่แค่เพียง "จำนวนเอเจนต์ × ปริมาณการใช้ต่อตัว" เท่านั้น แต่ทุกครั้งที่มีการส่งข้อความระหว่างเอเจนต์ ประวัติการสนทนาจะถูกสะสมไว้ใน Context Window ของแต่ละตัว ทำให้ปริมาณการใช้โทเค็นมีแนวโน้มที่จะเพิ่มขึ้นแบบทวีคูณ

ช่องทางหลักที่ทำให้เกิดการขยายตัวของค่าใช้จ่ายมีดังนี้:

• การส่งต่อคำสั่งจาก Orchestrator ไปยัง Sub-agent: หากส่ง Context ทั้งหมดที่เอเจนต์หลัก (Parent Agent) มีไปยัง Sub-agent โดยตรง ข้อมูลชุดเดียวกันจะถูกสะสมซ้ำซ้อนกันใน Prompt ของเอเจนต์หลายตัว
• การแชร์ผลลัพธ์ระหว่างทางผ่าน A2A (Agent-to-Agent Protocol): หากเกิดลูปที่เอเจนต์อ้างอิงผลลัพธ์ระหว่างทางของกันและกัน จำนวนครั้งในการเรียก API จนกว่างานจะเสร็จสิ้นจะเพิ่มขึ้นอย่างรวดเร็ว
• Context ซ้ำซ้อนจากการประมวลผลแบบขนาน (Parallel Execution): เนื่องจากเอเจนต์แต่ละตัวเก็บ System Prompt หรือผลลัพธ์จากการค้นหา RAG แยกกัน ทำให้เกิดการสะสมของโทเค็นที่ซ้ำซ้อนกันอย่างเงียบๆ

สิ่งที่ต้องระวังคือการตั้งค่าขีดจำกัดทางฝั่งแพลตฟอร์มด้วยเช่นกัน ใน Cloud LLM นั้น Rate Limit จะถูกจัดการในหน่วย TPM (Tokens Per Minute) และขีดจำกัดดังกล่าวมักถูกตั้งค่าไว้สูงมาก จึงทำให้การใช้งานที่เพิ่มขึ้นจาก Context ซ้ำซ้อนถูกมองข้ามได้ง่าย

บทสรุป: การใช้โทเค็นเกินความจำเป็นของ AI Agent เกิดจากปัญหาเชิงโครงสร้างในการออกแบบ โดยมีปัจจัยสามประการที่ส่งผลร่วมกันจนทำให้เกิดค่าใช้จ่ายโดยไม่ตั้งใจ ได้แก่ ลูปที่ไม่มีเงื่อนไขหยุดทำงาน, การขยายกระบวนการคิดภายในของโมเดลการอนุมาน (Inference Model) และการที่บริบทบวมขึ้นจากการใช้ RAG ต่อไปนี้คือการสรุปกลไกแต่ละส่วนตามลำดับ

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

สภาวะนี้เรียกว่า "การใช้ทรัพยากรแบบไม่จำกัด (Unbounded Consumption)" โดย AI Agent จะทำการเรียกใช้เครื่องมือหรือสอบถาม LLM ซ้ำๆ อย่างอิสระจนกว่าจะบรรลุเป้าหมาย หากการออกแบบเงื่อนไขการหยุดทำงานยังมีความคลุมเครือ จะเกิดเหตุการณ์ต่อเนื่องดังนี้:

• เอเจนต์ตัดสินว่า "ยังได้ข้อมูลไม่เพียงพอ" จึงทำการค้นหาและสรุปผลซ้ำๆ
• ผลลัพธ์ของแต่ละขั้นตอนจะถูกสะสมไปเป็นอินพุตของขั้นตอนถัดไป ทำให้ Context Window ขยายใหญ่ขึ้น
• ยิ่งจำนวน Token เพิ่มขึ้น ต้นทุนต่อการเรียกใช้ API 1 ครั้งก็จะสูงขึ้น และเมื่อคูณกับจำนวนรอบของลูปที่เพิ่มขึ้น ค่าใช้จ่ายก็จะบานปลาย

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

ประเด็นสำคัญในการรับมือมี 3 ข้อดังนี้:

CoT (Chain of Thought) และโมเดลการใช้เหตุผล (Reasoning Models) แม้จะช่วยเพิ่มความแม่นยำของคำตอบ แต่ก็มีโครงสร้างต้นทุนที่มักถูกมองข้าม นั่นคือกระบวนการคิดเองก็ถูกนับเป็นโทเค็นที่ต้องเสียค่าใช้จ่ายด้วยเช่นกัน

ในการเรียกใช้งาน Prompt ปกติ จำนวนโทเค็นขาเข้า (Input) และขาออก (Output) จะเป็นหน่วยพื้นฐานในการคิดค่าบริการ แต่สำหรับโมเดลการใช้เหตุผล "ขั้นตอนกลางสำหรับการคิด" จะสร้างโทเค็นขาออกจำนวนมหาศาล มีรายงานว่าในกรณีที่สั่งให้แก้โจทย์คณิตศาสตร์ที่ซับซ้อนหรือวางแผนหลายขั้นตอน โทเค็นที่ใช้ในการคิดอาจมีจำนวนมากกว่าคำตอบสุดท้ายหลายเท่าตัว

การเลือกโมเดลที่เหมาะสมจะแตกต่างกันอย่างมากตามลักษณะของงาน:

• สำหรับงานจำแนกประเภทหรือสรุปความทั่วไป: โมเดลมาตรฐานมักจะมีความคุ้มค่าด้านต้นทุนมากกว่าโมเดลการใช้เหตุผล
• สำหรับงานที่ต้องใช้การใช้เหตุผลหลายขั้นตอนที่ซับซ้อน: ความแม่นยำที่เพิ่มขึ้นของโมเดลการใช้เหตุผลอาจช่วยลดจำนวนครั้งในการลองใหม่ (Retry) ซึ่งส่งผลให้ประหยัดต้นทุนได้ในท้ายที่สุดในบางกรณี

ควรระมัดระวังเป็นพิเศษเมื่อเรียกใช้โมเดลการใช้เหตุผลภายใน Agent Loop หากลูปมีการทำงานซ้ำ 10 ครั้ง โทเค็นที่ใช้ในการคิดในแต่ละครั้งจะถูกทวีคูณและส่งผลโดยตรงต่อยอดค่าใช้จ่าย

หลายหน้างานมักพบปัญหาหลังจากเริ่มใช้งาน RAG (Retrieval-Augmented Generation) ว่า "ทำไมปริมาณการใช้โทเค็นถึงพุ่งสูงกว่าที่คาดการณ์ไว้เกินสองเท่า"

ต้นทุนโทเค็นของ RAG เกิดจากโครงสร้างที่นำผลลัพธ์การค้นหาไปใส่ไว้ใน Context Window โดยตรง ซึ่งมีขั้นตอนทั่วไปดังนี้:

• แปลงคำถามของผู้ใช้เป็น Embedding เพื่อค้นหาใน Vector Database
• นำ Chunk ลำดับบนสุด K รายการ มาเชื่อมต่อเข้ากับ System Prompt
• ส่ง Prompt ทั้งหมดที่เชื่อมต่อกันไปยัง LLM (Large Language Model)

ปัญหาอยู่ที่การตั้งค่า "ลำดับบนสุด K รายการ" หากตั้งค่า K=5 และขนาด Chunk อยู่ที่ 512 โทเค็น เฉพาะผลลัพธ์การค้นหาก็จะใช้โทเค็นไปแล้วถึง 2,560 โทเค็นต่อครั้ง เมื่อรวมกับ System Prompt เดิมและประวัติการสนทนา จำนวนโทเค็นต่อ 1 คำขอจึงสามารถทะลุ 5,000 - 8,000 โทเค็นได้อย่างง่ายดาย

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

ประเด็นสำคัญในการลดต้นทุนมี 3 ข้อดังนี้:

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

ในตอนแรก เรามักจะคิดว่า "ค่อยมาดูบันทึก (log) ย้อนหลังเอาก็ได้" แต่ในความเป็นจริง การเตรียมเครื่องมือสำหรับแสดงผลการใช้โทเค็นแบบเรียลไทม์ไว้ก่อนนั้นมีประสิทธิภาพในการตรวจจับค่าใช้จ่ายที่พุ่งสูงขึ้นแต่เนิ่นๆ ได้ดีกว่า

เครื่องมือ AI Observability จะทำหน้าที่รวบรวมจำนวนโทเค็นที่ใช้, ค่าความหน่วง (latency) และค่าใช้จ่ายของแต่ละคำขอ (request) ที่ส่งไปยัง LLM โดยอัตโนมัติ และแสดงผลผ่านแดชบอร์ด โดยมีเกณฑ์การเลือกที่สำคัญดังนี้:

• รองรับหลายโมเดล (Multi-model support): สามารถวัดผลข้ามผู้ให้บริการหลายรายได้หรือไม่
• การติดตามลูปของเอเจนต์ (Agent loop tracking): สามารถเชื่อมโยงการเรียกใช้งานแบบต่อเนื่องของ Multi-step reasoning หรือ Multi-agent System ด้วย Trace ID ได้หรือไม่
• การเชื่อมต่อระบบแจ้งเตือน (Alert integration): สามารถส่งการแจ้งเตือนไปยัง Slack หรือช่องทางอื่นๆ ได้หรือไม่เมื่อการใช้โทเค็นเกินเกณฑ์ที่กำหนด
• การคำนวณต้นทุนอัตโนมัติ (Automated cost conversion): สามารถแปลงจำนวนโทเค็นเป็นราคาจริงโดยอัตโนมัติ และแสดงแนวโน้มค่าใช้จ่ายรายวันหรือรายเดือนได้หรือไม่

อนึ่ง ขีดจำกัดอัตราการใช้งานของ Cloud LLM มักถูกตั้งค่าไว้สูงมาก และยิ่งขีดจำกัดสูงเท่าใด การใช้งานจำนวนมากโดยไม่ตั้งใจก็จะยิ่งเกิดขึ้นได้ง่ายเท่านั้น ดังนั้นการเฝ้าติดตามตลอดเวลาด้วยเครื่องมือ Observability จึงเป็นสิ่งที่ขาดไม่ได้

สำหรับขั้นตอนการนำไปใช้งาน ให้เริ่มจากการติดตั้งไลบรารีสำหรับการติดตาม (tracing library) ลงใน SDK หรือเลเยอร์มิดเดิลแวร์ และกำหนดสแปน (span) ให้กับการเรียกใช้ API แต่ละครั้ง

การวัดค่า Baseline เริ่มต้นจากการทำความเข้าใจตัวเลขว่า "มีการใช้โทเค็นไปเท่าใดในสภาวะปกติที่ไม่มีการดำเนินการใดๆ" หากปราศจากค่ามาตรฐานนี้ คุณจะไม่สามารถกำหนดเกณฑ์สำหรับระบบแจ้งเตือน (Alert) หรือการจำกัดปริมาณการใช้งาน (Throttling) ที่จะกล่าวถึงในภายหลังได้อย่างเหมาะสม

ขั้นตอนการวัดผลมีดังนี้:

• เลือกรูปแบบ Use Case ที่เป็นตัวแทน 3-5 รูปแบบ: เลือกโฟลว์ที่เกิดขึ้นบ่อยในการใช้งานจริง เช่น การตอบแชท, การค้นหาด้วย RAG, หรือการเรียกใช้เครื่องมือ (Tool calling)
• บันทึกแยกโทเค็นขาเข้า (Input), โทเค็นขาออก (Output) และโทเค็นรวมของแต่ละโฟลว์: อัตราส่วนระหว่างขาเข้าและขาออกเป็นตัวชี้วัดสำคัญในการกำหนดทิศทางการปรับปรุงประสิทธิภาพ
• คำนวณค่าเฉลี่ย, ค่าสูงสุด และค่า P95 ต่อหนึ่งคำขอ: ใช้ค่าเปอร์เซ็นไทล์ในการประเมินเพื่อไม่ให้ถูกรบกวนจากค่าที่ผิดปกติ (Outliers)
• สร้างกราฟแสดงปริมาณการใช้งานสะสมรายวันและรายสัปดาห์: เพื่อทำความเข้าใจความผันผวนตามช่วงเวลา แทนที่จะวัดผลเพียงครั้งเดียว

การเลือกเครื่องมือวัดผลมีเงื่อนไขที่แตกต่างกัน หากคุณใช้ Cloud API ของโมเดลเดียว วิธีที่สั้นที่สุดคือการบันทึกฟิลด์ usage (prompt_tokens, completion_tokens) ที่รวมอยู่ใน API Response ลงใน Log โดยตรง ในทางกลับกัน หากเป็นระบบ Multi-agent ที่ใช้หลายโมเดลร่วมกัน การใช้เครื่องมือ AI Observability เพื่อรวบรวมข้อมูลไว้ที่จุดเดียวจะช่วยลดต้นทุนในการบริหารจัดการได้มากกว่า

หากคุณใช้งาน Cloud LLM อยู่ การตรวจสอบค่าขีดจำกัดอัตราการใช้งาน เช่น TPM (Tokens Per Minute) ควบคู่ไปด้วย จะช่วยให้เงื่อนไขเบื้องต้นของการวัดผลชัดเจนยิ่งขึ้น

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

การแจ้งเตือนเพดานค่าใช้จ่าย (Cost limit alerts) และการจำกัดปริมาณการใช้งาน (Throttling) คือแนวป้องกันด่านแรกจากกับดักโทเค็น (Token trap) โดยหัวข้อที่ควรตั้งค่าสามารถแบ่งออกได้เป็น 3 ส่วนหลัก ดังนี้

บทสรุป: การลดการใช้โทเค็นอย่างเป็นระบบทำได้โดยใช้ 3 ขั้นตอน ได้แก่ การบีบอัดพรอมต์ (Prompt Compression), การปรับแต่งบริบท (Context Optimization) และการแยกโมเดล (Model Separation)

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

หลายคนมักคิดว่า "ยิ่งอธิบายละเอียด ความแม่นยำยิ่งสูง" จึงมักเขียน Prompt ให้ยาวขึ้น แต่ในความเป็นจริง มีรายงานจำนวนมากระบุว่า Prompt ที่กระชับและตัดข้อมูลที่ไม่จำเป็นออกไป มักให้ผลลัพธ์ที่ดีกว่าทั้งในด้านต้นทุนและคุณภาพ

การลดจำนวน Input Token เป็นมาตรการลดต้นทุนที่เห็นผลเร็วที่สุด โปรดทบทวนโดยพิจารณาจากประเด็นดังต่อไปนี้:

• ตัดคำเกริ่นนำที่เยิ่นเย้อออก: ประโยคมาตรฐานอย่าง "คุณคือผู้ช่วยที่ยอดเยี่ยม" เป็นการสิ้นเปลือง Token โดยไม่ช่วยให้งานสำเร็จ ควรจำกัด System Prompt ให้เหลือเพียงการกำหนดบทบาทและเงื่อนไขเท่านั้น
• ลดจำนวนตัวอย่าง Few-shot ให้เหลือน้อยที่สุด: แม้การยกตัวอย่างจะช่วยเพิ่มคุณภาพได้ แต่การใช้ Token ต่อหนึ่งตัวอย่างมักถูกมองข้าม ควรหลีกเลี่ยงการใส่ตัวอย่างในงานที่สามารถทำแบบ Zero-shot ได้
• ใช้รูปแบบที่มีโครงสร้างแทนการอธิบายแบบยืดยาว: การส่งข้อมูลในรูปแบบ JSON หรือรายการแบบ Bullet point จะมีประสิทธิภาพด้าน Token สูงกว่าการเขียนอธิบายเป็นประโยคยาวๆ
• ออกแบบให้เปลี่ยนเฉพาะส่วนที่เป็นตัวแปรแบบไดนามิก: ทำให้ส่วนที่เป็นเนื้อหาคงที่ใน Prompt Template สั้นลง และเปลี่ยนเฉพาะตัวแปรที่ใส่เข้าไปในขณะประมวลผลเท่านั้น

มุมมองในการเลือกโมเดลก็มีความสำคัญเช่นกัน ขีดจำกัดอัตราการใช้งานของ Cloud LLM มักถูกตั้งค่าไว้สูงมาก และยิ่งโมเดลมีขีดจำกัดสูงเท่าใด หากไม่บีบอัด Prompt อย่างจริงจัง ก็จะยิ่งนำไปสู่การใช้งานจำนวนมหาศาลโดยไม่ตั้งใจได้ง่ายเท่านั้น

ใน RAG pipeline การตั้งค่าขนาดของ Chunk ส่งผลโดยตรงต่อปริมาณการใช้ Token หาก Chunk ใหญ่เกินไป LLM จะได้รับบริบทที่ไม่จำเป็น แต่หากเล็กเกินไป ความหมายจะถูกตัดขาดทำให้ความแม่นยำในการค้นหาลดลง การแก้ไขภาวะกลืนไม่เข้าคายไม่ออกนี้คือหัวใจสำคัญของ Context Engineering

เกณฑ์การตัดสินใจเลือกขนาดของ Chunk จะแตกต่างกันไปตามวัตถุประสงค์การใช้งาน:

• สำหรับ Query ประเภทอ้างอิงข้อเท็จจริง (เช่น การค้นหา FAQ หรือคู่มือข้อมูลจำเพาะ) Chunk ขนาดเล็กจะเหมาะสมกว่า เนื่องจากสามารถดึงเฉพาะส่วนที่จำเป็นและจำกัดปริมาณข้อมูลที่ไหลเข้าสู่ Context Window ได้
• สำหรับงานที่ต้องมีการสรุปเอกสารหรือการใช้เหตุผลกับข้อความยาวๆ Chunk ขนาดใหญ่จะเหมาะสมกว่า แต่ต้องรักษาสมดุลด้วยการจำกัดจำนวนผลลัพธ์ในการ Retrieval

ในมุมมองของ Context Engineering สิ่งสำคัญคือการไม่นำ Chunk ที่ดึงมาได้มาเชื่อมต่อกันแล้วส่งไปทันที แต่ต้องมีการตัดออกด้วยคะแนนความเกี่ยวข้อง (Relevance Score) มีรายงานว่าเพียงแค่การกรอง Chunk ที่มีคะแนนความคล้ายคลึง (Similarity Score) ต่ำกว่าเกณฑ์ที่กำหนดออกไป ก็สามารถลดจำนวน Input Token ต่อหนึ่งคำขอลงได้อย่างมาก

การออกแบบ Chunk ที่ดึงมาได้อย่างหละหลวมจะส่งผลโดยตรงต่อปริมาณ Input Token เนื่องจาก Cloud LLM มักตั้งค่าขีดจำกัดอัตราการใช้งานไว้สูง การควบคุมปริมาณอินพุตที่ฝั่งกลยุทธ์ Chunk โดยไม่พึ่งพาขีดจำกัดดังกล่าวจึงเป็นสิ่งจำเป็น

นอกจากนี้ การที่ System Prompt มีขนาดใหญ่เกินไปก็เป็นปัจจัยด้านต้นทุนที่มักถูกมองข้ามเช่นกัน

「งานนี้จำเป็นต้องส่งให้ LLM ขนาดใหญ่ทำทุกครั้งเลยหรือเปล่า?」——วินาทีที่คุณรู้สึกเช่นนั้นในหน้างาน คือสัญญาณที่บ่งบอกว่าถึงเวลาต้องทบทวนการแยกงาน (Task Separation) แล้ว

แม้ LLM อเนกประสงค์จะสามารถตอบคำถามได้ทุกรูปแบบ แต่ในขณะเดียวกันก็สิ้นเปลือง Context Window จำนวนมากไปกับงานจัดเส้นทาง (Routing) หรือการจัดหมวดหมู่แบบง่ายๆ แนวทางที่มีประสิทธิภาพในจุดนี้คือ การแยกงานเฉพาะทางออกมาให้ SLM (Small Language Model) ที่ผ่านการ Fine-tuning แล้วเป็นผู้จัดการ

เกณฑ์ในการตัดสินใจแยกงานคือ "ระดับความเป็นมาตรฐานของงาน (Task Routine)"

• งานที่มีความเป็นมาตรฐานสูง (การวิเคราะห์อารมณ์, การจัดหมวดหมู่, การดึงข้อความสั้น) → มอบหมายให้ SLM หรือโมเดลที่ผ่านการ Fine-tuning
• งานที่ต้องใช้การอนุมานระดับกลาง (การสรุปความ, การแปลภาษา, การดึงข้อมูลแบบมีโครงสร้าง) → หลายกรณีสามารถใช้โมเดลขนาดเล็กจัดการได้
• งานที่ต้องใช้การอนุมานซับซ้อนหรือการสร้างสรรค์ (การวางแผนหลายขั้นตอน, การเขียนโค้ด) → คงไว้ที่ LLM ขนาดใหญ่

ในการเลือกโมเดล นอกจากราคาต่อหน่วยของโทเค็นแล้ว การตั้งค่าขีดจำกัดของ Output Token ก็เป็นสิ่งที่ต้องให้ความสำคัญด้วย โมเดลส่วนใหญ่มีการตั้งค่าจำนวนโทเค็นขาออกสูงสุด (Default Max Output Tokens) ไว้ ดังนั้นภายใน Agent Loop จึงควรทำความเข้าใจค่าขีดจำกัดของแต่ละโมเดลและกำหนดข้อจำกัดอย่างชัดเจน

บทสรุป: การปรับเปลี่ยนการตั้งค่ารายบุคคลเพียงอย่างเดียวมีข้อจำกัด ดังนั้นการออกแบบเพื่อจำกัดการใช้โทเค็นในระดับสถาปัตยกรรมจึงเป็นสิ่งที่ขาดไม่ได้

การผสมผสานระหว่าง AI Guardrails และการออกแบบ Orchestration จะช่วยให้สามารถควบคุม Token Trap ได้อย่างเป็นระบบ ต่อไปนี้จะอธิบายวิธีการนำไปใช้งานจริงโดยแบ่งเป็น 3 ชั้น ได้แก่ การจัดการงบประมาณ (Budget Management), การป้องกันการทำ Injection และการมีมนุษย์เข้ามามีส่วนร่วม (Human-in-the-Loop: HITL)

ชั้นการประสานงานเอเจนต์ (Agent Orchestration Layer) เป็นจุดควบคุมเดียวที่สามารถบริหารจัดการการใช้โทเค็นของทั้งระบบที่ประกอบด้วยซับเอเจนต์หลายตัวทำงานร่วมกันได้อย่างเบ็ดเสร็จ

ในตอนแรก เรามักจะคิดว่า "ซับเอเจนต์แต่ละตัวสามารถปรับต้นทุนได้ด้วยตนเอง" แต่ในความเป็นจริง การบริหารจัดการงบประมาณแบบรวมศูนย์ที่ฝั่งออร์เคสตราเตอร์ (Orchestrator) จะมีประสิทธิภาพมากกว่า เนื่องจากซับเอเจนต์ไม่สามารถมองเห็นภาพรวมของการใช้ทรัพยากรของตนเองได้ การจัดการแบบกระจายศูนย์จึงมักจะป้องกันการใช้เกินขีดจำกัดได้ยาก

มาตรการหลักที่ควรนำไปใช้ในชั้นการประสานงานมีดังนี้:

• การจัดสรรงบประมาณโทเค็นล่วงหน้า: กำหนดเพดานโทเค็นให้กับแต่ละโหนดในกราฟงาน (Task Graph) ก่อนเริ่มดำเนินการ หากปริมาณคงเหลือต่ำกว่าเกณฑ์ที่กำหนด ให้ยุติงานย่อยหรือเปลี่ยนไปใช้ SLM (Small Language Model) แทน
• การติดตามการใช้สะสมแบบเรียลไทม์: รวบรวมข้อมูลจากฟิลด์การใช้งานที่อยู่ใน API Response เพื่อให้ออร์เคสตราเตอร์เก็บข้อมูลการใช้โทเค็นต่อเซสชันและต่อเอเจนต์ไว้ตลอดเวลา
• การควบคุมปริมาณ (Throttling) และการจัดลำดับความสำคัญ: จัดสรรงบประมาณให้กับงานที่มีความสำคัญสูงก่อน ส่วนงานที่มีความสำคัญต่ำให้ใช้วิธีการเข้าคิวหรือการลดทอนงาน

ขีดจำกัดอัตราการใช้งานของ Cloud LLM มักถูกตั้งค่าไว้สูงมาก ทำให้การควบคุมที่พึ่งพาขีดจำกัดดังกล่าวทำงานได้ยาก ดังนั้นการฝังตรรกะการสำรองข้อมูล (Fallback) ไว้ภายในออร์เคสตราเตอร์ ที่จะสลับไปใช้โมเดลขนาดเล็กโดยอัตโนมัติเมื่อการใช้โทเค็นถึงอัตราที่กำหนด จึงเป็นการออกแบบที่มีประสิทธิภาพ

Prompt Injection (การฉีดคำสั่ง) ไม่เพียงแต่เป็นความเสี่ยงด้านความปลอดภัยเท่านั้น แต่ยังเป็นปัจจัยแฝงที่ทำให้การใช้โทเค็นพุ่งสูงขึ้นอีกด้วย

เมื่อผู้โจมตีฝังคำสั่งที่เป็นอันตรายลงในข้อมูลภายนอก เอเจนต์จะพยายามประมวลผลคำสั่งนั้นเสมือนเป็นงานปกติ ส่งผลให้เกิดการอนุมานเพิ่มเติม การเรียกใช้เครื่องมือ และลูปการตรวจสอบซ้ำที่ไม่จำเป็น ซึ่งทำให้การใช้โทเค็นเพิ่มขึ้นอย่างมหาศาล ยิ่งเป็นสภาพแวดล้อมที่มีขีดจำกัดอัตราการใช้งานสูง การใช้งานจำนวนมากโดยไม่ตั้งใจจากการโจมตีแบบ Injection ก็จะยิ่งสังเกตเห็นได้ยากเท่านั้น จึงเป็นจุดที่ต้องระมัดระวัง

การเลือกมาตรการป้องกันขึ้นอยู่กับสถานการณ์ หากจัดการกับแหล่งข้อมูลภายนอก (เช่น การดึงข้อมูลจากเว็บ, ข้อมูลที่ผู้ใช้ป้อนเข้ามา, หรือฐานข้อมูล) ควรให้ความสำคัญกับการทำ Input Sanitization และ Prompt Firewall ส่วนในสภาพแวดล้อมปิดที่จัดการเฉพาะข้อมูลภายใน การจัดโครงสร้าง System Prompt และการจำกัดขอบเขตสิทธิ์ (Permission Scope) จะให้ผลลัพธ์ที่มีประสิทธิภาพ

มาตรการที่มีประสิทธิภาพโดยเฉพาะมีดังนี้:

สถานการณ์ที่ว่า "ปล่อยให้เอเจนต์จัดการเอง รู้ตัวอีกทีก็เรียกใช้ API ที่ไม่ตั้งใจไปหลายสิบครั้งแล้ว" เป็นตัวอย่างคลาสสิกของสิทธิ์การใช้งานเอเจนต์ที่มากเกินไป (Excessive Agency) หากไม่จำกัดขอบเขตการตัดสินใจโดยอิสระของเอเจนต์ การใช้โทเค็นจะเพิ่มขึ้นอย่างไม่มีที่สิ้นสุด

HITL (Human-in-the-Loop) คือแนวทางการออกแบบที่กำหนดจุดตรวจสอบเพื่อให้มนุษย์ยืนยันและอนุมัติการกระทำของเอเจนต์ ในบริบทของกับดักโทเค็น (Token Trap) วิธีนี้จะทำหน้าที่เป็น "ประตู" ที่ไม่อนุญาตให้ดำเนินการขั้นตอนถัดไปหากไม่ได้รับการอนุมัติ

จุดที่ควรติดตั้งประตู (Gate Points) หลัก

• ก่อนการดำเนินการที่มีต้นทุนสูง: ก่อนการประมวลผลที่ใช้โทเค็นจำนวนมากในครั้งเดียว เช่น การเรียกใช้ API ภายนอก, การดึงข้อมูลจำนวนมาก หรือการสร้างข้อความยาวๆ
• การตัดสินใจดำเนินการต่อในลูป: กำหนดให้ต้องมีการอนุมัติจากมนุษย์ก่อนที่เอเจนต์จะตัดสินใจ "ลองใหม่" (Retry) หรือ "ค้นหาเพิ่มเติม" (Additional Research) ด้วยตนเอง
• เมื่อถึงเกณฑ์งบประมาณ: หยุดชั่วคราวเมื่อการใช้โทเค็นใน 1 เซสชันถึง 80% ของขีดจำกัดที่ตั้งไว้ เพื่อสอบถามว่าต้องการดำเนินการต่อหรือไม่

การออกแบบขั้นตอนการอนุมัติแบบอะซิงโครนัส (Asynchronous) เป็นวิธีที่ใช้งานได้จริง การใช้การแจ้งเตือนผ่าน Slack หรือ Teams ร่วมกับปุ่มอนุมัติ จะช่วยให้สามารถรักษาจุดตรวจสอบไว้ได้โดยลดเวลาที่มนุษย์ต้องรอให้เหลือน้อยที่สุด

กรณีทั่วไปที่นำไปสู่กับดักโทเค็น (Token Trap) สามารถสรุปได้เป็นสองประเด็นหลัก คือ "ไม่สามารถสังเกตการณ์ได้" และ "ไม่สามารถหยุดได้" ขีดจำกัดอัตราการใช้งานของ Cloud LLM มักถูกตั้งค่าไว้สูงมาก และด้วยขนาดของขีดจำกัดที่สูงนี้เองที่ทำให้การใช้งานจำนวนมหาศาลโดยไม่ตั้งใจเกิดขึ้นได้ง่าย จึงเป็นจุดที่ต้องระมัดระวังเช่นกัน ต่อไปเราจะมาดูรูปแบบความผิดพลาดแต่ละอย่างและวิธีรับมือกัน

"ค่าใช้จ่ายพุ่งสูงขึ้นอย่างรวดเร็ว แต่กลับไม่รู้ตัวเลย"

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

รูปแบบความล้มเหลวที่เกิดจากการขาดบันทึกข้อมูล (Log) สามารถสรุปได้เป็น 3 ประการหลัก:

• ไม่มีการสรุปยอดแยกตามโมเดลหรือตาม Endpoint: ทำให้ไม่สามารถระบุได้ว่า Agent ตัวใดเป็นผู้ใช้งาน ส่งผลให้เสียเวลาในการตรวจสอบหาสาเหตุ
• ไม่มีการแยก Token ขาเข้าและขาออก: เนื่องจากหลายโมเดลมีราคาต่อหน่วยของ Output Token สูงกว่า Input การมองข้ามปริมาณ Output ที่เพิ่มขึ้นจะทำให้ความสูญเสียขยายตัวได้ง่าย
• การขาดบันทึกการลองใหม่ (Retry) เมื่อเกิดข้อผิดพลาด: หากมีการตั้งค่าให้ลองใหม่โดยอัตโนมัติเมื่อเกิด Timeout หรือ API Error ก็อาจทำให้การใช้ Token ในงานเดียวกันเพิ่มขึ้นเป็นสองเท่าโดยที่เราไม่รู้ตัว

นอกจากนี้ ในขณะที่โมเดลส่วนใหญ่มีการตั้งค่าจำนวนโทเค็นขาออกสูงสุด (Default Max Output Tokens) ไว้ แต่ทางฝั่ง Input นั้น Rate Limit (เช่น TPM) มักถูกตั้งค่าไว้สูงมาก และยิ่งขีดจำกัดสูงเท่าใด การใช้งานจำนวนมากโดยไม่ตั้งใจก็จะยิ่งเกิดขึ้นได้ง่ายเท่านั้น หากไม่มี Log แบบเรียลไทม์ ก็จะไม่สามารถสังเกตเห็นความผิดปกติเหล่านี้ได้

สิ่งที่ทั้งสามกรณีนี้มีร่วมกันคือ การตัดสินใจเชิงออกแบบที่มองว่าการเก็บ Log เป็น "ฟีเจอร์ที่ค่อยเพิ่มทีหลัง" จึงทำให้ถูกละเลยไป

หากมีการนำการเรียกซ้ำ (Recursive call) ไปใช้งานโดยที่เงื่อนไขการหยุดทำงานยังมีความคลุมเครือ มีรายงานว่าค่าใช้จ่ายอาจพุ่งสูงขึ้นหลายสิบเท่าภายในระยะเวลาอันสั้น

รูปแบบที่พบบ่อยมีดังนี้:

• เอเจนต์เรียกตัวเองซ้ำทุกครั้งที่ตัดสินว่า "งานยังไม่เสร็จสิ้น"
• ในการเรียกแต่ละครั้ง จะมีการนำผลลัพธ์จากเทิร์นก่อนหน้าทั้งหมดติดไปในบริบท (Context) ด้วย
• เมื่อหน้าต่างบริบท (Context window) สะสมมากขึ้น จำนวนโทเค็นต่อการเรียกหนึ่งครั้งจะเพิ่มขึ้นแบบทวีคูณ

ขีดจำกัดอัตราการใช้งานของ Cloud LLM มักถูกตั้งค่าไว้สูงมาก และยิ่งขีดจำกัดสูงเท่าใด การใช้งานจำนวนมากโดยไม่ตั้งใจก็จะยิ่งเกิดขึ้นได้ง่ายเท่านั้น ในกรณีที่การจัดการข้อผิดพลาด (Error handling) ไม่เพียงพอ ตัวอย่างที่พบบ่อยคือเอเจนต์ตีความการหมดเวลา (Timeout) ของ API ภายนอกว่าเป็น "งานล้มเหลว" จึงส่งคำขอเดิมซ้ำๆ อย่างต่อเนื่อง เพียงแค่ลูปทำงานครบ 10 รอบ ปริมาณการใช้โทเค็นอาจพุ่งสูงขึ้นหลายสิบเท่าจากตอนเริ่มต้นเนื่องจากการสะสมของบริบท

เกณฑ์การตัดสินใจเพื่อรับมือจะแตกต่างกันไปตามสถานการณ์ หากสามารถคาดการณ์จำนวนรอบของลูปได้ การจำกัดจำนวนการทำซ้ำสูงสุด (max_iterations) ด้วยการ Hardcode เป็นวิธีที่แน่นอนที่สุด ในทางกลับกัน หากเป็นงานแบบไดนามิกที่ไม่สามารถระบุจำนวนรอบที่แน่นอนได้ การออกแบบให้ระบบหยุดทำงานโดยอัตโนมัติเมื่อจำนวนโทเค็นสะสมเกินเกณฑ์ที่กำหนด แล้วส่งต่อให้ HITL (Human-in-the-Loop) ดำเนินการต่อ ถือเป็นวิธีที่เหมาะสม

สรุปมาตรการที่มีประสิทธิภาพเพื่อป้องกันการเกิดซ้ำ: