Claude Code ใช้โทเคนไปถึง 3 ใน 4 ของงบประมาณเพียงเพื่อการอ่าน codebase เท่านั้น จากการวิเคราะห์ของ Red Hat ต่อเซสชันการใช้งานจริง 219 ครั้ง ผลลัพธ์นี้พลิกความเชื่อเดิมที่ว่าเอเจนต์เขียนโค้ดที่ขับเคลื่อนด้วย AI มักเสียเวลาไปกับการสร้างโค้ด และชี้ให้เห็นว่านักพัฒนาควรหันมาแก้ปัญหาเรื่องการจัดการบริบท (context management) แทนที่จะมุ่งเน้นแค่ความเร็วของโมเดลเพียงอย่างเดียว

ข้อมูลเบื้องหลังข้อกล่าวอ้างนี้

Red Hat ได้ตรวจสอบการโต้ตอบกับ Claude Code ของ Anthropic จำนวน 219 ครั้ง และคำนวณการใช้โทเคนต่อการโต้ตอบ (turn) จากกลุ่มตัวอย่างพบว่า ค่ามัธยฐานของการโต้ตอบแต่ละครั้งมีการจัดสรรโทเคนถึง 75% ไปกับการอ่านโค้ดและเอกสารประกอบที่เกี่ยวข้อง ในขณะที่มีเพียง 25% เท่านั้นที่ใช้ในการสร้างบรรทัดโค้ดใหม่ เนื่องจากผู้ให้บริการ AI ส่วนใหญ่คิดค่าบริการโทเคนขาเข้า (input) และขาออก (output) ในอัตราที่เท่ากัน ส่วนของการ "อ่าน" จึงเป็นตัวขับเคลื่อนต้นทุนส่วนใหญ่

ทำไมต้นทุนการอ่านจึงสำคัญ

กลยุทธ์การเพิ่มประสิทธิภาพ

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

การควบคุมต้นทุน

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

จุดเน้นทางวิศวกรรม

ผู้สร้างเครื่องมือมักจะวิ่งไล่ตามคุณภาพโมเดลที่สูงขึ้น โดยมองข้ามวิธีการสร้าง prompt การวิเคราะห์นี้ชี้ให้เห็นว่า "context engineering" – การตัดทอน (trimming), การทำแคช (caching) และการสรุปเนื้อหา (summarizing) โค้ดที่ส่งให้โมเดล – ให้ผลตอบแทน (ROI) ที่คุ้มค่ากว่าการอัปเกรดโมเดลเพียงเล็กน้อย

ขั้นตอนปฏิบัติเพื่อลดภาระการอ่าน

  • ตัดไฟล์ที่ไม่เกี่ยวข้องออก (Prune irrelevant files) – นำไฟล์ที่งานปัจจุบันไม่จำเป็นต้องใช้ ออกจาก prompt ยิ่ง prompt เล็ก โทเคนขาเข้าก็น้อยลง
  • ทำแคชสำหรับการอ่านซ้ำ (Cache repeated reads) – จัดเก็บการตีความของโมเดลในส่วนที่ไม่มีการเปลี่ยนแปลงของ codebase และนำกลับมาใช้ใหม่ในการโต้ตอบครั้งต่อๆ ไป แทนที่จะส่งข้อความเดิมซ้ำๆ
  • บีบอัดผลลัพธ์จากเครื่องมือ (Compress tool outputs) – เมื่อเครื่องมือภายนอกส่งข้อมูลขนาดใหญ่กลับมา (เช่น รายงาน lint) ให้สรุปข้อมูลเหล่านั้นก่อนส่งกลับไปยัง Claude
  • ใช้ incremental diffs – ส่งเฉพาะส่วนที่มีการเปลี่ยนแปลงนับจากการโต้ตอบครั้งล่าสุด แทนที่จะส่งเนื้อหาไฟล์ทั้งหมด

กลยุทธ์เหล่านี้มีเป้าหมายเพื่อหยุดไม่ให้ AI อ่านภาพจำลอง (snapshot) ของ repository เดิมซ้ำๆ ในทุกการโต้ตอบ ซึ่งจะช่วยลดทั้งความหน่วง (latency) และต้นทุน

ข้อโต้แย้ง: ความเร็วยังคงมีความสำคัญ

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

สิ่งที่ต้องจับตามองต่อไป

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

สรุป: สำหรับการเขียนโค้ดโดยมี AI ช่วยเหลือ การเพิ่มประสิทธิภาพที่ประหยัดที่สุดคือการส่งข้อมูลให้โมเดลน้อยลง ไม่ใช่การทำให้โมเดลเขียนได้เร็วขึ้น ตัวเลขของ Red Hat แสดงให้เห็นอย่างชัดเจนว่า: จงตัดทอน, ทำแคช และสรุป prompt ของคุณ แล้วคุณจะเห็นการประหยัดทั้งเวลาและเงินอย่างเป็นรูปธรรม