Ảo giác của nén token: Vì sao tôi hoài nghi về RTK

• RTK hứa hẹn giảm chi phí bằng cách nén đầu ra terminal của các coding agent, nhưng việc giảm đầu ra thô không đồng nghĩa với kỹ thuật phần mềm rẻ hơn, an toàn hơn hay chính xác hơn
• Mức “giảm 60~90%” không có nghĩa là hóa đơn LLM giảm tương ứng từng đó, mà gần hơn với tỷ lệ đầu ra dòng lệnh bị RTK loại bỏ
• Nếu xảy ra silent failure khiến đầu ra terminal bị hỏng hoặc bị thiếu một cách âm thầm, agent có thể đưa ra phán đoán sai khi không có stack trace hay ngữ cảnh compiler quan trọng
• Chỉ biểu đồ tiết kiệm token là chưa đủ; cần có tỷ lệ hoàn thành tác vụ và các đánh giá độ chính xác kiểu SWE-bench để cho thấy agent tự động có thực sự hoàn thành công việc hay không
• RTK có vẻ giống một tính năng của công cụ phát triển hơn là một sản phẩm độc lập, và vì dễ bị ảnh hưởng bởi thay đổi đầu ra CLI như git, cargo, npm, grep, nên rủi ro vận hành là lớn nếu đưa vào đường dẫn quan trọng của agent production

---

Cấu trúc chi phí thực sự bị các con số tiết kiệm che khuất

• RTK quảng bá việc giảm lượng token sử dụng và giảm chi phí bằng cách nén đầu ra terminal cho coding agent
  • Dự án đã đạt hơn 60k GitHub star và ngành đang phản ứng rất mạnh với thông điệp quảng bá này
  • Tuy vậy, những tuyên bố về công cụ phát triển “quá tốt để là thật” cần được xem xét kỹ cấu trúc thực tế
• Con số lan truyền “giảm 60~90%” không đồng nghĩa với mức giảm hóa đơn API thực tế
  • Thứ RTK cắt giảm chỉ là một phần của đầu ra Bash
  • Những yếu tố chi phí lớn hơn như đọc file chuyên sâu, ngữ cảnh kho mã, system prompt và token suy luận nội bộ của mô hình vẫn còn đó
  • Các lệnh như rtk gain trông giống được tối ưu cho ảnh chụp màn hình trên mạng xã hội hoặc các chỉ số dễ trình bày với quản lý không chuyên kỹ thuật hơn là tối ưu hóa kiến trúc căn bản
  • Ngay cả trong các issue GitHub gần đây cũng đã bắt đầu xuất hiện nghi vấn về các chỉ số bị thổi phồng

Độ chính xác và độ ổn định vận hành mới là biến số lớn hơn

• Tối ưu hóa là vô nghĩa nếu độ chính xác không đi cùng, và trong các issue công khai của kho mã đã xuất hiện những trường hợp đầu ra terminal bị hỏng hoặc bị thiếu một cách âm thầm
  • Rủi ro cốt lõi là AI agent không biết rằng văn bản đã bị nén
  • Nếu RTK loại bỏ các dòng quan trọng trong stack trace hoặc ngữ cảnh compiler để tiết kiệm vài token, cả người dùng lẫn LLM đều phải làm việc với thông tin không đầy đủ
  • Việc áp dụng RTK là một lựa chọn phụ thuộc vào một lớp bên ngoài phải phân tích, diễn giải và rút gọn đầu ra của vô số công cụ CLI mà không làm mất ý nghĩa
• RTK cho thấy biểu đồ tiết kiệm token, nhưng lại thiếu chỉ số tỷ lệ hoàn thành tác vụ mới là điều thực sự quan trọng
  • Điểm mấu chốt là liệu agent tự động có giải quyết được bài toán kỹ thuật phần mềm ở cuối vòng lặp thực thi hay không
  • Ngay cả khi giảm 80% chi phí prompt, nếu agent bị hallucination, build thất bại hoặc lặp vòng vì ngữ cảnh suy giảm, cuối cùng có thể còn tiêu tốn nhiều token hơn
  • Cho tới khi có đánh giá độ chính xác nghiêm ngặt kiểu SWE-bench đi kèm biểu đồ chi phí, câu chuyện về RTK vẫn chưa hoàn chỉnh
• Từ góc độ kiến trúc, RTK bổ sung một phụ thuộc bên ngoài dễ tổn thương vào đường dẫn quan trọng đồng bộ giữa agent và shell
  • Tối ưu hóa đầu ra có vẻ gần với một tính năng hơn là một sản phẩm hay nền tảng độc lập
  • Nếu các CLI và công cụ phát triển chủ chốt cung cấp sẵn các cờ --compact hoặc --json-stream gốc để phục vụ việc tiêu thụ của LLM, lợi thế chính của RTK có thể biến mất
• RTK phụ thuộc rất nhiều vào việc phân tích cụ thể các định dạng stdout/stderr vốn dành cho con người đọc, nên khó bảo trì
  • Chỉ cần git, cargo, npm, grep thay đổi vài khoảng trắng trong định dạng terminal hoặc bố cục lỗi, regex và các bộ lọc phân tích của RTK có thể hỏng
  • Khi đó hệ thống có thể thất bại âm thầm thay vì báo lỗi rõ ràng, rồi cung cấp cho agent văn bản bị hỏng hoặc chỉ còn một phần
• RTK đánh đổi độ tin cậy mang tính quyết định, tính toàn vẹn ngữ nghĩa và sự đơn giản của kiến trúc để lấy một chỉ số hào nhoáng là giảm số token terminal thô
  • Chừng nào chưa giải quyết được silent degradation và chưa cung cấp benchmark minh bạch về độ chính xác tác vụ, thì việc đặt nó vào đường dẫn quan trọng của workflow agent production vẫn mang rủi ro vận hành lớn hơn mức giảm giá mà nó hứa hẹn

[GN⁺]

Ý kiến trên Hacker News

• Mừng vì những bài như thế này cuối cùng cũng bắt đầu có sức nặng hơn khi nói về toàn bộ ngành công nghiệp hộp ma thuật LLM
  Từ caveman mode đến RTK rồi semantic search, cảm giác như các lập trình viên đang trở thành phù thủy đọc thần chú hơn là kỹ sư, và ở chỗ làm thì điều đó đặc biệt mệt vì ai cũng tin thần chú của mình là cách tiết kiệm token tối thượng
  Tiêu chí của tôi là thế này: ý tưởng nào không có trong evaluation harness thì phần lớn là không ổn, còn ý tưởng tốt thì cuối cùng cũng sẽ được đưa lên Codex/Claude. Cũng khó mà tin những quảng cáo kiểu tiết kiệm được bao nhiêu phần trăm token trên GitHub
  Trong lĩnh vực như thế này rất khó tránh các công cụ mang tính lừa bịp, và tôi mong mọi người bắt đầu nhìn chúng một cách phê phán hơn

  • Hoàn toàn sai, và bạn đang đánh giá thấp việc các công ty tuyến đầu kém cỏi đến mức nào ở những mảng ngoài việc tạo mô hình LLM
    Suốt 1 năm qua đã có cả những trường hợp kiểu TUI nhấp nháy “được viết như game engine”, và khi tự chạy nhiều benchmark thì có những cách đã được kiểm chứng là giảm token mà vẫn cho ra cùng kết quả. Ví dụ như tìm cùng một CVE, hoặc phát hiện cùng một lỗi trong code review
    Muốn xem một minh chứng nhỏ của tôi thì vào https://maki.sh
  • Vì thế tôi A/B test mù mọi thứ
    Tốn rất nhiều token, nhưng phải chứng minh được là nó thực sự có giá trị, và đa số hoàn toàn không đạt chuẩn đó
    Trong AI agent của tôi cũng có nhiều tính năng, nhưng tôi không cho rằng kết quả A/B test mù từ 4 tháng trước vẫn còn ý nghĩa đến hôm nay. Chỉ riêng cách tôi chọn từ ngữ cũng có thể làm kết quả thay đổi rất lớn
    Dù vậy tôi vẫn test để tự xác nhận giá trị và tận mắt thấy nó. Tôi không chủ động công khai kết quả A/B test mù cụ thể
    Tôi cũng đã thấy người khác làm A/B test mù rất sai, và nếu đo lường kém thì bản thân bài test cũng vô nghĩa
    Chúng ta đều đang cùng giải bài toán này, có rất nhiều hắc thuật nên tôi phụ thuộc khá nhiều vào hooks. AI agent nhỏ của tôi chắc cũng đầy hắc thuật
    Điều duy nhất tôi biết chắc là nó hoạt động với tôi. Nếu không dùng cái này thì thật lòng tôi không biết giờ mọi người làm việc với AI kiểu gì
    Tôi vẫn để link ở đây, nhưng không có nghĩa là tôi khuyến nghị bạn làm gì cả. Phần lớn chỉ có các kỹ sư phần mềm khác dùng, và nó rất chuyên biệt với công việc tôi phải làm. Cùng lắm nó chỉ có thể cho bạn vài ý tưởng để tự triển khai
    https://github.com/notque/vexjoy-agent
  • Câu “ý tưởng tốt thì sẽ được đưa lên Codex/Claude” chỉ đúng khi có ai đó tạo ra công cụ như RTK để người khác dùng thử
    Đứng ngoài quan sát vòng này cũng không sao, nhưng các công cụ như RTK, Headroom, caveman mode có thể giảm lượng token đầu vào/đầu ra cần xử lý, và trên LLM chạy cục bộ thì có thể tạo ra cải thiện tốc độ đo được
    Chưa có đủ dữ liệu để nói liệu nó có làm giảm chất lượng đầu ra cuối cùng hay không, nhưng nghịch thử để tìm hiểu thì vẫn rất vui
  • Bản thân ý tưởng là hợp lý. Nếu có thể hạ tỷ lệ tín hiệu trên nhiễu của cửa sổ ngữ cảnh thì đó là điều tốt
    Chỉ là RTK có thực sự làm được vậy hay chưa thì vẫn chưa được chứng minh. Thay vì các câu vô nghĩa kiểu “lên tới 90%”, tôi muốn xem benchmark đàng hoàng về khác biệt mà công cụ này thực sự tạo ra
  • Xa hơn nữa, một số tối ưu tôi thấy trong rtk cho các lệnh như git status có vẻ đã được đưa lên tầng mô hình rồi
    Giờ Codex thường gọi các công cụ như git status --short thay vì git status

• Tôi là tác giả bài viết. Nói thật thì tôi viết vì với tư cách kỹ sư phần mềm, rtk ai trông quá kỳ quặc
  Việc không có số liệu, không nhắc gì đến độ chính xác, và cách ban lãnh đạo thúc đẩy kiểu này để tối ưu chi phí khiến tôi khó chịu. Giờ mọi người đang cố bọc mọi lệnh có thể bằng rtk, xử lý toàn bộ các lệnh chính, thậm chí còn muốn quyết định cả loại đầu ra cần nhận

  • Tôi thật lòng muốn nghe ý kiến về https://www.github.com/jahala/tilth
    Đây là một cách tiếp cận khác với RTK, và đã benchmark là giảm khoảng 40% chi phí trên mỗi đáp án đúng
  • Tôi không hiểu vì sao lại không đưa ra lấy một số liệu sử dụng thực tế nào để hậu thuẫn cho lập luận. Không giúp ích mấy

• Kết quả đầu ra của công cụ chiếm tỷ trọng lớn trong đầu ra của tôi. Nếu có thể tiết kiệm 3,7 triệu trong số 3,9 triệu token đầu vào thì tôi sẽ nhận. Token tiết kiệm được vẫn là token tiết kiệm được
  Với tư cách là người dùng RTK, tôi muốn có benchmark về độ chính xác, nhưng đến giờ tôi vẫn chưa thấy bằng chứng nào cho thấy mô hình đã bỏ lỡ điều quan trọng vì nén
  Về mặt triết lý thiết kế, việc bảo toàn độ chính xác được xử lý rất nghiêm ngặt, đến mức nếu bộ lọc thất bại thì nó sẽ quay lại đầu ra gốc. Tôi cũng đã trực tiếp xem mã nguồn của các lệnh hay dùng, thấy ổn, và đến nay tôi cho rằng nó đã tạo được sự tin cậy
  Cũng có lo ngại rằng nếu git, cargo, npm, grep thay đổi vài cột định dạng terminal hoặc đổi bố cục lỗi thì regex và parser của RTK sẽ hỏng. Nhưng nếu bộ lọc thất bại thì nó sẽ quay lại đầu ra gốc. RTK là công cụ được thiết kế để không đưa văn bản hỏng hoặc không đầy đủ vào agent
  Lo ngại là hợp lý, nhưng tôi muốn chỉ trích phải được hậu thuẫn bằng bằng chứng. Tôi tò mò không biết họ đã dùng RTK chưa, và có tìm thấy bằng chứng nào cho thấy nó không bảo toàn được độ chính xác hay không

  • Tôi có xem khi điều tra issue này, và một vài issue nổi bật trông khá tệ
    https://github.com/rtk-ai/rtk/issues/2494
    https://github.com/rtk-ai/rtk/issues/2462
    https://github.com/rtk-ai/rtk/issues/2395
  • Có những lúc token tiết kiệm được không hẳn là token tiết kiệm được
    RTK loại bỏ cờ và các thông tin khác. Đôi khi vì vậy mà về sau phải tốn thêm token để khôi phục lại chúng. Dù có thể tiết kiệm 70% token ở lần gọi công cụ đó, nhưng số liệu không cho thấy liệu bạn đã phải gọi công cụ 3 lần thay vì 1 lần hay chưa
    Cũng cần xem liệu đầu ra bị lược bỏ có khiến phải dùng thêm token suy luận hay không
  • Tôi không nghĩ chỉ riêng việc nói rằng độ chính xác được bảo toàn cực kỳ nghiêm ngặt là đủ
    Nếu xét chênh lệch chi phí giữa các mô hình mới nhất và các mô hình open-weight đã tụt hậu, hoặc giữa mô hình lớn nhất và mô hình cấp dưới nó, thì hiệu năng phải được đo cực kỳ cẩn thận
    Thay vì bên chỉ trích phải đưa bằng chứng, RTK phải chứng minh rằng nó không làm giảm hiệu năng

• Cốt lõi là có vô số công cụ tuyên bố giúp AI tốt hơn, nhưng lại không có cách đo xem AI có thực sự hoạt động tốt hơn hay không
  Các công ty lớn có sản phẩm phổ biến thì có cách. Ở đâu đó giữa phân tích sản phẩm thông thường và đánh giá chatbot, họ xác định được liệu người dùng có thành công trong một session hay không. Đó là công việc của họ
  Nhưng một lập trình viên cá nhân chạy 3 đến 50 session mỗi ngày thì gần như không có cách nào biết điều gì thực sự làm LLM tốt hơn. Mọi thứ đều là cảm giác
  Công ty chúng tôi có cả một stack hoàn chỉnh với harness ưa thích, mô hình, skills, thậm chí cả cấu trúc mã. Ngay cả ở quy mô chỉ bằng một phần triệu của Claude Code, vẫn cần có cách đo liệu thiết lập này có hiệu quả với chúng tôi hay không

  • Trong sản phẩm của tôi, chúng tôi bảo agent hỏi một cách tường minh. Có ví dụ thực tế và repository thật để bạn tự thử
    https://gitsense.com
    https://github.com/gitsense/smart-ripgrep
    https://github.com/gitsense/smart-codex
    Tôi không quá quan tâm đến mức tiết kiệm token trung bình. Điều tôi quan tâm hơn là AI có đưa các file không cần thiết vào ngữ cảnh hay không, vì điều đó có thể ảnh hưởng đến suy luận
    Sau khi hoàn thành tác vụ, chỉ cần hỏi agent: “Nếu biết trước mục đích của file thì bạn nghĩ mình đã không đọc bao nhiêu file?”
  • Nỗ lực tạo ra một benchmark hợp lệ là cực lớn. Có lẽ điều đó đúng, và vì thế lại càng bực hơn
    Ngay cả khi đã có framework, người ta cũng tranh cãi không ngớt, mà chuyện này còn tệ hơn nhiều. Nó trở thành cuộc đấu cảm giác của anh với cảm giác của tôi. Ai mà ngờ đầu ra phi định tính lại đưa chúng ta đến mức này chứ
  • Có một câu trả lời. Những công cụ như vậy nên được benchmark theo chi phí trên mỗi đáp án đúng, chứ không chỉ là tiết kiệm token đơn thuần

• Tôi đã tự dùng thử, và những message chiếm 90% ngữ cảnh của tôi thì không được nén, nên phần bị nén chỉ là một phần nhỏ trong tổng lượng token sử dụng
  Nếu đọc kỹ bài viết thì nó nói đúng như vậy. Xem /context là có thể thấy chỗ tốn token có lẽ không phải các lần gọi công cụ. Vì vậy proxy chỉ nén các lần gọi công cụ sẽ không tạo tác động lớn, ngay cả khi đúng là nó nén được các lần gọi công cụ tới 8 lần
  Trong các session code dài, với tôi điều đó không quá quan trọng
  “native/built-in Read or cat tools, the data is not intercepted by RTK's shell hook”

• Bài này hầu như không có dữ liệu để chống lưng cho phản biện, và phần lớn đọc giống như bài do LLM tạo ra

• Ở Semble chúng tôi cũng từng nhận những phàn nàn như vậy. Tôi nghĩ đó là phàn nàn hợp lý, nhưng việc tạo loại benchmark này rất khó và tốn kém vì tổ hợp harness × model × MCP/CLI
  Trong machine learning truyền thống hay công cụ thông thường, việc không đưa benchmark ra thường là tín hiệu xấu. Nhưng với công cụ LLM thì tôi không chắc

• Nếu để agent nhận biết việc nén của RTK và có tùy chọn bỏ qua, thì vẫn có cách khiến nó phát hiện bị cắt cụt. Tôi dùng RTK_DISABLE=1 theo cách khôi phục toàn bộ văn bản gốc
  Nó hoạt động tốt, và đúng vậy. Vì chỉ nén đầu ra lệnh nên về mặt “nén”, nó chỉ ảnh hưởng đến token đầu vào

• Đúng là CLI và công cụ dành cho lập trình viên phổ biến hoàn toàn có thể cung cấp cờ --compact hoặc --json-stream gốc để phục vụ việc tiêu thụ bởi LLM, nhưng họ sẽ không sớm làm vậy đâu
  Vì thế các công cụ như rtk, caveman, ponytail mới đang cố giảm khoản chi phí ngày càng tăng. Với một tổ chức khoảng 2.000 người thì hiện tại con số này vào cỡ 2,5 triệu USD, và mọi người đều đang hiểu và điều chỉnh những đánh đổi này
  Trái với lập luận của tác giả, chúng tôi hiểu rất rõ các đánh đổi này, và đang dùng công cụ sau khi fork, benchmark và xác minh xem chất lượng đầu ra có phù hợp nhu cầu hay không. Không phải dùng một cách mù quáng
  Với lập trình viên cá nhân thì có thể không thực sự cần, và tự host mô hình khác để tiết kiệm chi phí có khi còn tốt hơn. Nhưng trong tổ chức thì đây là vấn đề khá đau đầu
  Những bài như thế này soi rọi vấn đề là tốt, nhưng cũng nên đọc chúng với một mức độ chắt lọc nhất định, giống như khi đối xử với công cụ

• Đã thử chạy rtk gain trên Mac. Máy phát triển chính đã phải cài lại image vì vấn đề bộ nhớ và có vài thứ bị rối nên chưa kiểm tra được, nhưng trên Mac thì đã giảm khoảng 51 nghìn token đầu vào và 23 nghìn token đầu ra, đồng thời tiết kiệm trung bình 3 giây cho mỗi lệnh
  Không rõ tại sao lại tức giận đến vậy, cũng không hiểu vì sao còn phải viết hẳn một bài về chuyện này
  Không biết ai lại pipe stack trace vào RTK. Tôi chỉ dùng nó cho một vài chương trình rất cụ thể, và việc nhét đầu ra của compiler vào đó trông khá ngớ ngẩn. Chỉ cần chỉ thị cho agent dùng RTK với một tập lệnh cụ thể là được