ทำไมเราถึงปฏิเสธการประหยัด Token ถึง 96%
เราพบ MCP server ที่ช่วยประหยัด token ได้ถึง 96% โดยใช้เครื่องมือเพียงอย่างเดียวคือ execute_code แทนที่จะเรียกใช้ฟังก์ชันเฉพาะเจาะจง ตัว agent จะเขียน JavaScript เพื่อดึงข้อมูลแทน
ในทางทฤษฎี มันดูเหนือกว่า สำหรับงานที่ซับซ้อน การรันโค้ด (code execution) ให้ประสิทธิภาพดีกว่าการเรียกใช้เครื่องมือ (tool-calling)
แต่เราไม่ได้นำมันมาใช้ เรายังคงใช้เครื่องมือแบบแยกส่วนที่มีชื่อเรียกชัดเจน (discrete, named tools) ต่อไป
และนี่คือเหตุผลว่าทำไมทางเลือกที่ดูเหมือนจะดีที่สุด ถึงเป็นทางเลือกที่ผิดสำหรับ agent ของเรา
เป้าหมายเป็นตัวกำหนดการออกแบบ
คนส่วนใหญ่สร้างระบบสำหรับ frontier models ในหน้าต่างแชท โมเดลเหล่านั้นมีงบประมาณ token มหาศาล สำหรับโมเดลเหล่านั้น การรันโค้ดคือหัวใจสำคัญ
แต่เราสร้าง agent ที่เน้นการสั่งงานด้วยเสียง (voice-first) โดยใช้โมเดลขนาดเล็กที่รันแบบ local (Hermes 3 8B) บนเรือ
สำหรับโมเดลขนาดเล็ก ข้อจำกัดไม่ใช่เรื่อง token แต่คือความน่าเชื่อถือ (reliability)
หากโมเดลขนาดเล็กยังลำบากในการเรียกใช้เครื่องมือธรรมดาๆ การสั่งให้มันเขียน JavaScript ให้ถูกต้องก็เป็นงานที่ยากกว่ามาก execute_code คือการแลกความน่าเชื่อถือกับจำนวน token ซึ่งเราไม่สามารถยอมรับการแลกเปลี่ยนนั้นได้
ปัญหาช่วงสุดท้าย (The Last-Mile Problem)
การรันโค้ดเป็นการผลักภาระงาน "ช่วงสุดท้าย" (last mile) ไปให้ agent ซึ่ง agent จะต้อง:
- กรองข้อมูล
- เรียงลำดับผลลัพธ์
- จัดรูปแบบเอาต์พุต
เครื่องมือของเราจัดการงานเหล่านี้ภายในเซิร์ฟเวอร์ ตัวอย่างเช่น เมื่อถามเกี่ยวกับสถานะแบตเตอรี่ เครื่องมือของเราจะส่งค่ากลับมาเป็นข้อความ (string) ที่พร้อมสำหรับระบบ text-to-speech โดยจะพูดว่า "68 เปอร์เซ็นต์, 12.8 โวลต์" แทนที่จะเป็นตัวเลขดิบๆ
หากเราใช้ execute_code ตัว agent จะต้องเขียน logic เพื่อจัดรูปแบบคำพูดนั้นเอง ซึ่งโมเดลขนาดเล็กมักจะล้มเหลวในเรื่องนี้อยู่บ่อยครั้ง
กฎแห่งการขาดหาย (The Absence Rule)
เมื่ออยู่บนเรือ เซนเซอร์อาจจะออฟไลน์ได้ ในระบบของเรา หากเซนเซอร์หายไป ระบบจะส่งค่า null กลับมาอย่างชัดเจน ซึ่งถือว่าเป็นการเรียกใช้งานที่สำเร็จ
ในโมเดลแบบรันโค้ด หากเซนเซอร์หายไป มักจะเกิด error ขึ้น หากโมเดลขนาดเล็กคาดเดาเส้นทางผิดไปเพียงไม่กี่ครั้ง มันจะไปกระตุ้นขีดจำกัดของ error และทำให้ agent พังได้ การใช้เครื่องมือที่มีชื่อเรียกชัดเจนช่วยให้เรากำหนดให้การขาดหายของข้อมูลเป็น "ความสำเร็จ" ไม่ใช่ "ข้อผิดพลาด"
รายการตรวจสอบ: จะนำมาใช้หรือจะสร้างเอง (Adopt-vs-Build Checklist)
ก่อนที่คุณจะนำ MCP server มาใช้หรือสร้างขึ้นเอง ให้ลองถามคำถามเหล่านี้:
• Who is the target agent? (Frontier model vs. Small local model) • What is the binding constraint? (Tokens vs. Reliability) • Who does the last mile? (เครื่องมือเป็นคนจัดรูปแบบข้อมูล หรือ agent เป็นคนทำ?) • How does it handle absence? (ค่าที่หายไปคือ error หรือเป็น null?) • What is the maintenance cost? (คุณกำลังรับช่วงต่อ codebase ที่ไม่มีคนดูแลอยู่หรือเปล่า?)
เราไม่ได้เพิกเฉยต่อโปรเจกต์นั้น แต่เราได้เก็บเกี่ยวไอเดียจากมัน เรานำตรรกะการจัดการสัญญาณเตือน (alarm handling) และการค้นหาเส้นทาง (path discovery) ของพวกเขามาใส่ไว้ใน roadmap ของเรา
ประสิทธิภาพนั้นเป็นเรื่องดี แต่ความน่าเชื่อถือคือสิ่งที่จำเป็นเมื่อคุณอยู่กลางทะเล
Source: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae
Optional learning community: https://t.me/GyaanSetuAi