ภาพลวงตาของการบีบอัดโทเค็น: เหตุผลที่ผมยังไม่เชื่อ RTK
(mroczek.dev)- RTK สัญญาว่าจะลดต้นทุนด้วยการบีบอัดผลลัพธ์จากเทอร์มินัลของโค้ดดิ้งเอเจนต์ แต่การ ลดเอาต์พุตดิบ ไม่ได้แปลว่าจะทำให้วิศวกรรมซอฟต์แวร์ถูกลง ปลอดภัยขึ้น และแม่นยำขึ้นโดยอัตโนมัติ
- ตัวเลข “ลดได้ 60~90%” ไม่ได้หมายความว่า ค่าใช้จ่ายที่เรียกเก็บจาก LLM ลดลงเท่านั้น แต่ใกล้เคียงกับสัดส่วนของเอาต์พุตบรรทัดคำสั่งที่ RTK ตัดออกมากกว่า
- หากเกิด silent failure ที่ทำให้เอาต์พุตจากเทอร์มินัลเสียหายหรือหายไปแบบเงียบ ๆ เอเจนต์อาจตัดสินใจผิดโดยไม่มีสแตกเทรซสำคัญหรือบริบทจากคอมไพเลอร์
- กราฟการประหยัดโทเค็นเพียงอย่างเดียวยังไม่พอ และจำเป็นต้องมี อัตราความสำเร็จของงาน ที่แสดงว่าเอเจนต์อัตโนมัติทำงานเสร็จจริงหรือไม่ รวมถึงการประเมินความแม่นยำแบบ SWE-bench
- RTK ดูคล้ายฟีเจอร์ของเครื่องมือพัฒนามากกว่าจะเป็นผลิตภัณฑ์อิสระ และเปราะบางต่อการเปลี่ยนแปลงของเอาต์พุต CLI อย่าง
git,cargo,npm,grepทำให้มีความเสี่ยงด้านปฏิบัติการสูงเกินกว่าจะวางไว้ใน critical path ของเอเจนต์ระดับโปรดักชัน
โครงสร้างต้นทุนจริงที่ถูกตัวเลขการประหยัดบดบัง
- RTK ชูจุดขายเรื่องการบีบอัดเอาต์พุตจากเทอร์มินัลสำหรับโค้ดดิ้งเอเจนต์ เพื่อ ลดการใช้โทเค็น และลดต้นทุน
- ได้ GitHub star มากกว่า 60k และอุตสาหกรรมก็กำลังตอบสนองต่อการประชาสัมพันธ์นี้อย่างมาก
- แต่คำกล่าวอ้างของเครื่องมือพัฒนาที่ “ดูดีเกินจริง” ควรถูกตรวจสอบจากโครงสร้างที่แท้จริง
- ตัวเลขไวรัลอย่าง “ลดได้ 60~90%” ไม่เท่ากับ การลดค่าใช้จ่าย API จริง
- สิ่งที่ RTK ลดคือเพียงบางส่วนของเอาต์พุต Bash
- ปัจจัยต้นทุนที่ใหญ่กว่ายังคงอยู่ เช่น การอ่านไฟล์เชิงลึก บริบทของรีโพซิทอรี system prompt และโทเค็นการให้เหตุผลภายในของโมเดล
- คำสั่งอย่าง
rtk gainดูเหมือนจะมุ่งไปที่ตัวชี้วัดที่เหมาะกับภาพหน้าจอในโซเชียลมีเดียหรือการนำเสนอแก่ผู้จัดการที่ไม่ใช่สายเทคนิค มากกว่าการเพิ่มประสิทธิภาพเชิงสถาปัตยกรรมอย่างแท้จริง - ใน GitHub issue ช่วงหลัง ก็เริ่มมีการตั้งคำถามกับตัวชี้วัดที่เกินจริงแล้ว
ความแม่นยำและเสถียรภาพในการปฏิบัติการเป็นตัวแปรที่ใหญ่กว่า
- การเพิ่มประสิทธิภาพไม่มีความหมายหากความแม่นยำไม่ตามมา และใน issue สาธารณะของรีโพซิทอรีก็มีกรณีที่เอาต์พุตจากเทอร์มินัล พังหรือหายไปแบบเงียบ ๆ ปรากฏแล้ว
- ความเสี่ยงหลักคือ AI เอเจนต์ไม่รู้ว่าข้อความถูกบีบอัดไปแล้ว
- หาก RTK ลบบรรทัดสำคัญของสแตกเทรซหรือบริบทจากคอมไพเลอร์เพื่อประหยัดไม่กี่โทเค็น ทั้งผู้ใช้และ LLM ก็จะต้องทำงานบนข้อมูลที่ไม่ครบถ้วน
- การนำ RTK มาใช้ คือการเลือกพึ่งพาเลเยอร์ภายนอกที่ต้อง parse ตีความ และย่อเอาต์พุตของเครื่องมือ CLI จำนวนมากโดยไม่ให้ความหมายสูญหาย
- RTK แสดงกราฟการประหยัดโทเค็น แต่ขาดตัวชี้วัดที่สำคัญจริงอย่าง อัตราความสำเร็จของงาน
- ประเด็นสำคัญคือเอเจนต์อัตโนมัติสามารถแก้ปัญหาวิศวกรรมซอฟต์แวร์ได้จริงเมื่อจบรอบการทำงานหรือไม่
- แม้จะลดต้นทุนของพรอมป์ต์ได้ 80% แต่ถ้าบริบทด้อยลงจนเอเจนต์เกิด hallucination, build ล้มเหลว หรือวนลูป สุดท้ายก็อาจใช้โทเค็นมากกว่าเดิม
- จนกว่าจะมีการประเมินความแม่นยำแบบ SWE-bench ที่เข้มงวดควบคู่ไปกับกราฟต้นทุน เรื่องเล่าของ RTK ก็ยังไม่สมบูรณ์
- ในมุมมองเชิงสถาปัตยกรรม RTK เพิ่มการพึ่งพาภายนอกที่เปราะบางไว้ใน เส้นทางสำคัญแบบ synchronous ระหว่างเอเจนต์กับเชลล์
- การเพิ่มประสิทธิภาพเอาต์พุตดูเป็นฟีเจอร์มากกว่าเป็นผลิตภัณฑ์อิสระหรือแพลตฟอร์ม
- หาก CLI และเครื่องมือพัฒนาหลัก ๆ มีแฟลกเนทีฟอย่าง
--compactหรือ--json-streamสำหรับการใช้งานของ LLM ข้อได้เปรียบหลักของ RTK ก็อาจหายไป
- RTK พึ่งพาการ parse รูปแบบ stdout/stderr ที่ออกแบบมาสำหรับมนุษย์อย่างเฉพาะเจาะจงอย่างมาก ทำให้ดูแลรักษาได้ยาก
- ถ้า
git,cargo,npm,grepเปลี่ยนช่องว่างของรูปแบบเทอร์มินัลเพียงไม่กี่จุดหรือเปลี่ยนเลย์เอาต์ของข้อผิดพลาด regex และตัวกรองการ parse ของ RTK ก็อาจพังได้ - ในกรณีนี้ มันอาจล้มเหลวแบบเงียบ ๆ แทนที่จะรายงานข้อผิดพลาดอย่างชัดเจน และส่งข้อความที่เสียหายหรือไม่ครบถ้วนให้เอเจนต์
- ถ้า
- RTK แลก ความน่าเชื่อถือที่กำหนดผลได้แน่นอน ความครบถ้วนเชิงความหมาย และความเรียบง่ายของสถาปัตยกรรม กับตัวชี้วัดที่ดูหวือหวาอย่างการลดโทเค็นเทอร์มินัลดิบ
- จนกว่าจะแก้ปัญหา silent degradation และให้ benchmark ความแม่นยำของงานที่โปร่งใส การวางมันไว้ใน critical path ของ workflow เอเจนต์ระดับโปรดักชันยังมีความเสี่ยงด้านปฏิบัติการสูงเมื่อเทียบกับส่วนลดที่ได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ดีใจที่ในที่สุดบทความแบบนี้เริ่มมีแรงส่งมากขึ้นต่อวงการ กล่องเวทมนตร์ LLM โดยรวม
ตั้งแต่ caveman mode ไปจนถึง RTK และ semantic search นักพัฒนาชวนให้รู้สึกเหมือนกลายเป็นพ่อมดร่ายคาถามากกว่าจะเป็นวิศวกร และในที่ทำงานยิ่งเหนื่อยเป็นพิเศษเพราะแต่ละคนก็มั่นใจว่าคาถาของตัวเองคือวิธีประหยัดโทเคนขั้นสุดยอด
เกณฑ์ของผมคือแบบนี้: ไอเดียที่ไม่อยู่ใน evaluation harness โดยมากมักไม่ค่อยดี และไอเดียที่ดีจริงสุดท้ายก็มักจะไปโผล่ใน Codex/Claude ผมยังเชื่อได้ยากกับการโฆษณาว่าประหยัดโทเคนได้กี่เปอร์เซ็นต์บน GitHub
ในวงการแบบนี้หลีกเลี่ยงเครื่องมือหลอกลวงได้ยาก และหวังว่าผู้คนจะเริ่มมองกันอย่างวิพากษ์วิจารณ์มากขึ้น
ตลอดปีที่ผ่านมาก็มีตัวอย่างอย่าง TUI กระพริบ ๆ ที่ “เขียนเหมือนเกมเอนจิน” และพอผมลองรัน benchmark หลายตัวเอง ก็พบว่ามีวิธีที่พิสูจน์แล้วว่าสามารถลดโทเคนได้โดยยังให้ผลลัพธ์เดิม เช่น หา CVE เดิมตัวเดียวกัน หรือหา bug เดิมตัวเดียวกันใน code review
ถ้าอยากดูหลักฐานเล็ก ๆ ของผมก็ไปที่ https://maki.sh
มันเผาโทเคนเยอะก็จริง แต่ต้องพิสูจน์ให้ได้ว่ามีคุณค่าจริง และส่วนใหญ่ก็ไม่ผ่านเกณฑ์นั้นเลย
ใน AI agent ของผมเองก็มีฟีเจอร์หลายอย่าง แต่ผมก็ไม่คิดว่าผล blind A/B test จากเมื่อ 4 เดือนก่อนยังมีความหมายมาถึงวันนี้ แค่การเลือกคำที่ผมใช้ก็ทำให้ผลลัพธ์ต่างกันมากแล้ว
ถึงอย่างนั้นก็ยังทดสอบเพื่อยืนยันคุณค่าด้วยตัวเองและดูด้วยตาตัวเอง ผมไม่ได้อยากเผยผล blind A/B test แบบละเอียดเป็นพิเศษ
ผมก็เคยเห็นคนอื่นทำ blind A/B test กันผิดแบบมาก ๆ และถ้าวัดผลห่วย การทดสอบก็ไร้ความหมายไปเลย
พวกเราทุกคนกำลังช่วยกันแก้ปัญหานี้ และมันมีเวทมนตร์ดำอยู่เยอะมากจนต้องพึ่ง hooks หนักมาก AI agent เล็ก ๆ ของผมก็น่าจะเต็มไปด้วยเวทมนตร์ดำเหมือนกัน
สิ่งเดียวที่ผมรู้แน่คือ มันใช้ได้ผลสำหรับผม แค่นั้นเอง ถ้าไม่ใช้สิ่งนี้ ผมก็ไม่รู้จริง ๆ ว่าทุกวันนี้คนทำงานกับ AI กันยังไง
ผมแปะลิงก์ไว้ได้ แต่ไม่ได้หมายความว่าแนะนำไม่ว่าคุณจะทำอะไร ส่วนใหญ่ก็มีแต่วิศวกรซอฟต์แวร์คนอื่นใช้ และมันเฉพาะทางมากสำหรับงานที่ผมต้องทำ อย่างดีที่สุดก็คงให้ไอเดียสำหรับเอาไปทำเองได้
https://github.com/notque/vexjoy-agent
จะยืนดูเกมนี้เฉย ๆ ก็ได้ แต่เครื่องมืออย่าง RTK, Headroom, caveman mode สามารถลดจำนวนโทเคน input/output ที่ต้องประมวลผลได้ และบน local LLM ก็ทำให้ความเร็วดีขึ้นแบบวัดได้
ยังมีข้อมูลไม่พอจะบอกว่ามันทำร้ายคุณภาพผลลัพธ์สุดท้ายหรือไม่ แต่การลองจับมาทดลองเพื่อหาคำตอบก็น่าสนุกดี
แต่ RTK ทำแบบนั้นได้จริงหรือเปล่ายังไม่ถูกพิสูจน์ ผมอยากเห็น benchmark ที่วัดความแตกต่างที่เครื่องมือนี้สร้างขึ้นจริง ๆ มากกว่าคำพูดไร้ความหมายอย่าง “สูงสุด 90%”
git statusดูเหมือนว่าจะถูกยกขึ้นไปอยู่ที่ ชั้นโมเดล แล้วตอนนี้ Codex มักเรียกใช้เครื่องมืออย่าง
git status --shortแทนgit statusผมคือคนเขียนบทความนี้เอง พูดตรง ๆ ว่าผมเขียนเพราะในฐานะวิศวกรซอฟต์แวร์ rtk ai ดูแปลกมาก
ทั้งการอ้างเรื่องจำนวนโดยไม่พูดถึงความแม่นยำ และวิธีที่ผู้บริหารผลักของแบบนี้เพื่อ optimize ต้นทุน มันทำให้ผมติดใจ ตอนนี้ผู้คนกำลังเอา rtk ไปครอบทุกคำสั่งที่เป็นไปได้ พยายามจัดการคำสั่งหลักทั้งหมด และถึงขั้นพยายามกำหนดด้วยว่าควรรับ output แบบไหน
มันเป็นแนวทางที่ต่างจาก RTK และ benchmark ออกมาว่าลด ต้นทุนต่อคำตอบที่ถูกต้อง ได้ประมาณ 40%
เอาต์พุตจากเครื่องมือกินสัดส่วนใหญ่ในเอาต์พุตของฉัน ถ้าประหยัดได้ 3.7 ล้านโทเค็นจากอินพุต 3.9 ล้านโทเค็น ฉันก็เอา โทเค็นที่ประหยัดได้ก็คือโทเค็นที่ประหยัดได้
ในฐานะผู้ใช้ RTK ก็คงดีถ้ามี accuracy benchmark แต่จนถึงตอนนี้ฉันยังไม่เห็นหลักฐานว่าการบีบอัดทำให้โมเดลพลาดสิ่งสำคัญ
ในเชิงปรัชญาการออกแบบ มันเข้มงวดมากเรื่องการคงความถูกต้องไว้ ถึงขั้นถ้าฟิลเตอร์ล้มเหลวก็จะย้อนกลับไปใช้อินพุตต้นฉบับ ฉันดูซอร์สของคำสั่งที่ใช้บ่อยด้วยตัวเองแล้ว ชอบมัน และมองว่าจนถึงตอนนี้มันสร้างความน่าเชื่อถือได้
มีความกังวลว่าถ้า git, cargo, npm, grep เปลี่ยนฟอร์แมตเทอร์มินัลไปไม่กี่ช่องหรือเปลี่ยนเลย์เอาต์ของ error แล้ว regex กับ parser ของ RTK จะพัง แต่ถ้าฟิลเตอร์ล้มเหลวก็จะย้อนกลับไปใช้อินพุตต้นฉบับ RTK เป็นเครื่องมือที่ออกแบบมาไม่ให้ป้อนข้อความที่เสียหายหรือไม่ครบถ้วนเข้าไปให้เอเจนต์
ความกังวลนั้นสมเหตุสมผล แต่ฉันอยากให้คำวิจารณ์มีหลักฐานรองรับ อยากรู้ว่าได้ลองใช้ RTK แล้วหรือยัง และเจอหลักฐานหรือไม่ว่ามันรักษาความถูกต้องไว้ไม่ได้
https://github.com/rtk-ai/rtk/issues/2494
https://github.com/rtk-ai/rtk/issues/2462
https://github.com/rtk-ai/rtk/issues/2395
RTK ลบ flags และข้อมูลอื่น ๆ ออกไป ซึ่งบางครั้งทำให้ต้องใช้โทเค็นมากขึ้นเพื่อกู้สิ่งนั้นกลับมาในภายหลัง ถึงจะประหยัดโทเค็นได้ 70% ใน tool call นั้น แต่เมตริกก็ไม่ได้บอกว่าคุณต้องเรียกเครื่องมือ 3 ครั้งแทน 1 ครั้งหรือเปล่า
ต้องดูด้วยว่าเอาต์พุตที่ถูกลบออกไปทำให้ต้องใช้ reasoning tokens เพิ่มหรือไม่
ถ้าคิดถึงส่วนต่างด้านต้นทุนระหว่างโมเดลใหม่กับโมเดล open-weight ที่ล้าหลัง หรือระหว่างโมเดลที่ใหญ่ที่สุดกับรุ่นรองลงมา เราต้องวัดประสิทธิภาพอย่างระมัดระวังมาก
แทนที่จะให้ฝั่งวิจารณ์เป็นคนต้องหาหลักฐาน RTK ต่างหากที่ควรพิสูจน์ว่ามันไม่ทำให้ประสิทธิภาพแย่ลง
ประเด็นสำคัญคือมีเครื่องมือมากมายมหาศาลที่อ้างว่าทำให้ AI ดีขึ้น แต่เราไม่มี วิธีวัดว่า AI ทำงานได้ดีขึ้นจริงไหม
บริษัทใหญ่ที่มีผลิตภัณฑ์ยอดนิยมมีวิธีวัดอยู่ โดยดูว่าผู้ใช้ประสบความสำเร็จในเซสชันหรือไม่ ซึ่งอยู่กึ่งกลางระหว่าง product analytics ทั่วไปกับการประเมินแชตบอต นั่นคืองานของพวกเขา
แต่สำหรับนักพัฒนารายบุคคลที่รันวันละ 3 ถึง 50 เซสชัน แทบไม่มีทางรู้ได้เลยว่าอะไรทำให้ LLM ดีขึ้น ทุกอย่างอาศัยความรู้สึกล้วน ๆ
ที่บริษัทเรา เรามีทั้งสแตกครบชุด ตั้งแต่ harness, model, skills ไปจนถึงโครงสร้างโค้ด และควรมีวิธีวัดได้ว่าการตั้งค่านี้ใช้ได้ผลกับเราหรือไม่ แม้จะมีสเกลแค่หนึ่งในล้านของ Claude Code ก็ตาม
https://gitsense.com
https://github.com/gitsense/smart-ripgrep
https://github.com/gitsense/smart-codex
ฉันไม่ได้สนใจค่าเฉลี่ยการประหยัดโทเค็นมากนัก สิ่งที่สนใจกว่าคือ AI เอาไฟล์ที่ไม่จำเป็นขึ้นมาใส่ในคอนเท็กซ์หรือไม่ เพราะสิ่งนี้อาจส่งผลต่อการให้เหตุผล
หลังจบงานก็แค่ถามเอเจนต์ว่า “ถ้ารู้จุดประสงค์ของไฟล์ตั้งแต่แรก คุณคิดว่ามีไฟล์กี่ไฟล์ที่คุณคงไม่อ่าน”
แค่มี framework อยู่แล้วก็เถียงกันเยอะมากพอแล้ว แต่นี่หนักกว่านั้นอีก มันกลายเป็นการปะทะกันของสัญชาตญาณเธอกับสัญชาตญาณฉัน ใครจะไปคิดว่า เอาต์พุตที่ไม่เป็นเชิงกำหนด จะพาเรามาถึงจุดนี้
ฉันลองใช้เองแล้ว แต่มันไม่บีบอัดข้อความที่กิน 90% ของคอนเท็กซ์ฉัน จึงบีบอัดได้แค่ส่วนเล็ก ๆ ของการใช้โทเค็นทั้งหมด
ถ้าอ่านโพสต์นี้อย่างระมัดระวัง เขาก็เขียนไว้อย่างนั้นชัดเจน ดูจาก
/contextก็น่าจะเห็นว่าแหล่งใช้โทเค็นไม่ใช่ tool call เพราะงั้นพร็อกซีที่บีบอัดเฉพาะ tool call ก็ย่อมไม่ส่งผลมากนัก ต่อให้คำกล่าวว่า compress tool call ได้ 8 เท่าจะเป็นจริงก็ตามสำหรับเซสชันเขียนโค้ดยาว ๆ มันไม่ค่อยสำคัญกับฉันเท่าไร
“native/built-in Read or cat tools, the data is not intercepted by RTK's shell hook”
โพสต์นี้แทบไม่มีข้อมูลมารองรับข้อโต้แย้ง และอ่านเหมือนเป็น ข้อความที่ LLM สร้างขึ้น เป็นส่วนใหญ่
ที่ Semble ก็เคยได้รับคำบ่นแบบนี้เหมือนกัน ฉันคิดว่าเป็นข้อกังวลที่มีเหตุผล แต่การสร้าง benchmark ประเภทนี้ยากและแพงมากเพราะมี harness × model × ชุดผสม MCP/CLI
ในโลก machine learning แบบดั้งเดิมหรือเครื่องมือทั่วไป การไม่แสดง benchmark มักเป็นสัญญาณอันตราย แต่สำหรับเครื่องมือ LLM ฉันก็ไม่แน่ใจ
ถ้าให้เอเจนต์รับรู้การบีบอัดของ RTK และมีตัวเลือกให้ข้ามมัน ก็มีวิธีทำให้มัน ตรวจจับการถูกตัดทอน ได้ ฉันใช้
RTK_DISABLE=1เพื่อกู้ข้อความต้นฉบับทั้งหมดกลับมามันใช้ได้ดี และใช่แล้ว เพราะมันบีบอัดเฉพาะเอาต์พุตของคำสั่ง ดังนั้นในมุมของ “การบีบอัด” มันจึงกระทบเฉพาะ input tokens
ถูกแล้วที่ CLI และเครื่องมือสำหรับนักพัฒนากระแสหลักสามารถมี flags แบบเนทีฟอย่าง
--compactหรือ--json-streamที่ออกแบบมาสำหรับการบริโภคของ LLM ได้ แต่พวกเขาคงไม่ทำในเร็ว ๆ นี้นั่นจึงเป็นเหตุผลว่าทำไมเครื่องมืออย่าง rtk, caveman, ponytail ถึงพยายามลดต้นทุนที่เพิ่มขึ้นเรื่อย ๆ สำหรับองค์กรขนาด 2,000 คน ตอนนี้ค่าใช้จ่ายอยู่ราว 2.5 ล้านดอลลาร์ และทุกคนก็กำลังรับรู้และปรับจูน trade-off พวกนี้กันอยู่
ต่างจากที่ผู้เขียนอ้าง เรารู้เรื่อง trade-off เหล่านี้ดี และใช้เครื่องมือโดยมีการ fork, benchmark และตรวจสอบว่า quality ของเอาต์พุตตรงกับความต้องการหรือไม่ ไม่ได้ใช้แบบหลับหูหลับตา
ถ้าเป็นนักพัฒนารายบุคคลอาจไม่จำเป็นนัก และการโฮสต์โมเดลอื่นเองเพื่อลดต้นทุนอาจดีกว่า แต่ในองค์กรนี่เป็นประเด็นใหญ่พอสมควร
โพสต์แบบนี้ที่ช่วยส่องไฟให้ประเด็นก็เป็นเรื่องดี แต่เหมือนกับเครื่องมือ เราก็ควรอ่านโพสต์แบบนี้อย่างมีการกรองอยู่บ้าง
ลองพิมพ์
rtk gainบน Mac แล้ว เครื่องหลักที่ใช้พัฒนามีปัญหาเรื่องหน่วยความจำเลยต้องลงอิมเมจใหม่ และมีบางอย่างรวน ๆ เลยยังตรวจสอบได้ไม่ครบ แต่บน Mac มันลดได้คร่าว ๆ ราว โทเค็นอินพุต 5.1 หมื่นโทเค็น และโทเค็นเอาต์พุต 2.3 หมื่นโทเค็น และประหยัดเวลาได้เฉลี่ย 3 วินาทีต่อคำสั่งไม่ค่อยเข้าใจว่าทำไมถึงโกรธกันขนาดนี้ หรือทำไมถึงต้องถึงขั้นเขียนโพสต์ด้วย
ไม่รู้เหมือนกันว่าใครจะ pipe stack trace เข้า RTK ผมใช้มันกับแค่โปรแกรมที่เฉพาะมาก ๆ เท่านั้น และการยัดเอาต์พุตของคอมไพเลอร์เข้าไปก็ดูงี่เง่า ถ้าจะใช้ก็แค่สั่ง agent ให้ใช้ RTK เฉพาะกับชุดคำสั่งบางชุดก็พอ