Tokenomics: Định lượng token được dùng ở đâu trong kỹ thuật phần mềm tác tử

 (arxiv.org)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Một nghiên cứu đo lường cấu trúc tiêu thụ token bằng cách ánh xạ dấu vết thực thi của các hệ thống phát triển phần mềm đa tác tử dựa trên LLM vào các giai đoạn SDLC, cho thấy tiêu thụ token tập trung vào review mã và kiểm chứng hơn là tạo mã ban đầu
  • Trong 30 tác vụ phát triển phần mềm do ChatDev thực hiện, giai đoạn review mã tiêu thụ trung bình 59.4% token và được xác nhận là khu vực tiêu thụ lớn nhất
  • Cấu thành token trung bình trên toàn bộ tác vụ là 53.9% đầu vào, 24.4% đầu ra, 21.6% suy luận, cho thấy việc truyền ngữ cảnh lặp đi lặp lại giữa các tác tử tạo ra một communication tax lớn
  • Giai đoạn lập trình có tỷ trọng token đầu ra cao ở mức 58.0%, trong khi giai đoạn tài liệu hóa có tỷ trọng token đầu vào cao ở mức 80.2%, cho thấy mẫu sử dụng token được phân biệt rõ theo từng giai đoạn phát triển
  • Kết luận rằng cần có các giao thức cộng tác tác tử hiệu quả token hơn và một khung đánh giá chuẩn hóa để dự đoán chi phí và tối ưu hóa workflow

Tóm tắt

  • Các hệ thống đa tác tử dựa trên LLM (LLM-MA) ngày càng được áp dụng để tự động hóa các tác vụ kỹ thuật phần mềm phức tạp như kỹ nghệ yêu cầu, sinh mã và kiểm thử
  • Hiệu quả vận hành và mức tiêu thụ tài nguyên của chúng vẫn chưa được hiểu đầy đủ, khiến chi phí và tác động môi trường khó dự đoán trở thành rào cản cho triển khai thực tế
  • Nghiên cứu phân tích dấu vết thực thi của 30 tác vụ phát triển phần mềm mà framework ChatDev thực hiện bằng GPT-5 reasoning model, rồi ánh xạ các bước nội bộ sang các giai đoạn thiết kế, lập trình, hoàn thiện mã, review mã, kiểm thử và tài liệu hóa
  • Kết quả sơ bộ cho thấy giai đoạn review mã lặp đi lặp lại chiếm trung bình 59.4% token, là khu vực tiêu thụ lớn nhất
  • Token đầu vào liên tục chiếm tỷ trọng lớn nhất với trung bình 53.9%, cung cấp bằng chứng thực nghiệm cho khả năng tồn tại nhiều kém hiệu quả trong cộng tác tác tử
  • Chi phí chính của kỹ thuật phần mềm tác tử không nằm ở việc sinh mã ban đầu mà tập trung vào quá trình cải tiến và kiểm chứng tự động
  • Phương pháp này có thể được dùng cho dự đoán chi phí, tối ưu hóa workflow và nghiên cứu các giao thức cộng tác tác tử hiệu quả token hơn

Giới thiệu

  • Kỹ thuật phần mềm quy mô lớn đang khám phá các hệ thống đa tác tử dựa trên LLM để tự động hóa những tác vụ phức tạp trên toàn bộ SDLC
  • Các framework LLM-MA mô phỏng những vai trò trong nhóm con người như product manager, architect, developer và tester bằng các tác tử LLM chuyên biệt, cùng cộng tác để thực hiện thiết kế, lập trình và kiểm chứng
  • Về nguyên tắc, hệ thống LLM-MA có thể phân chia công việc giữa các tác tử để tăng tính tự chủ và độ bền vững
  • Nghiên cứu trước đây cho thấy hệ thống LLM-MA có thể thúc đẩy tư duy phân kỳ, tăng cường suy luận và tính xác thực, đồng thời mở rộng sang những vấn đề vượt quá năng lực của một tác tử đơn lẻ
  • Trong kỹ thuật phần mềm, điều này mở ra khả năng tự động hóa workflow end-to-end từ yêu cầu đến kiểm thử theo cách tích hợp
  • Framework AGENTTAXO cung cấp một hệ phân loại để phân tích phân bố token của các hệ thống LLM-MA nói chung và đưa ra khái niệm “communication tax” để mô tả overhead tương tác giữa các tác tử
  • Phân loại lỗi MAST xác nhận rằng nhiều vấn đề trong hệ thống LLM-MA bắt nguồn từ thiết kế và điều phối hệ thống, như lặp lại giai đoạn hoặc kiểm chứng không đầy đủ, hơn là từ giới hạn của từng LLM riêng lẻ
  • Nghiên cứu hiện có đã phân tích hành vi tác tử trong bối cảnh tổng quát, nhưng vẫn tồn tại khoảng trống tri thức về hiệu quả tài nguyên của các hệ thống được áp dụng vào workflow kỹ thuật phần mềm nhiều giai đoạn
  • Câu hỏi cốt lõi cho triển khai thực tế là “token đi về đâu” vẫn chưa được trả lời đầy đủ trong lĩnh vực kỹ thuật phần mềm
  • Tokenomics là thuật ngữ dùng để nghiên cứu hiệu quả vận hành và mức tiêu thụ tài nguyên của các hệ thống LLM-MA
  • Phân tích thực hiện bằng cách ánh xạ các bước nội bộ của ChatDev sang các giai đoạn phát triển để quan sát phân bố tiêu thụ token
  • ChatDev mô phỏng một công ty phần mềm ảo, nơi nhiều vai trò tác tử như lập trình viên và kiểm thử viên hoàn thành SDLC thông qua hội thoại nhiều lượt
  • Nghiên cứu cung cấp một bộ dữ liệu đã tuyển chọn gồm 30 dấu vết thực thi và gói tái lập đầy đủ

Thiết kế nghiên cứu

  • Mục tiêu và đối tượng phân tích

    • Mục tiêu là khảo sát thực nghiệm cách tiêu thụ token được phân bố khi hệ thống LLM-MA thực hiện các tác vụ phát triển phần mềm end-to-end
    • Đối tượng phân tích ban đầu là ChatDev
    • Kiến trúc “chat chain” của ChatDev thể hiện mô hình thác nước tuần tự rõ ràng từ thiết kế → lập trình → kiểm thử, với các giai đoạn tách bạch nên phù hợp để ánh xạ sang các giai đoạn phát triển phần mềm
    • ChatDev là một trong những framework mã nguồn mở phổ biến và được trích dẫn nhiều

  • Tuyển chọn bộ dữ liệu

    • Chạy ChatDev trên 30 tác vụ phát triển phần mềm khác nhau
    • Prompt được thu thập từ ProgramDev Dataset đã dùng trong nghiên cứu MAST
    • Các prompt được chọn bao gồm từ thuật toán đơn giản như sinh số Fibonacci đến các ứng dụng phức tạp hơn như trò chơi cờ vua
    • Tính đa dạng được xác nhận dựa trên nghiên cứu gần đây cho thấy số token suy luận có thể là chỉ dấu thay thế cho độ phức tạp tác vụ
    • Mức tiêu thụ token suy luận của 30 tác vụ dao động từ 17,280 đến 40,000, cho thấy bộ nghiên cứu có đủ đa dạng về độ phức tạp tác vụ
    Quảng cáo

  • Lựa chọn mô hình

    • Mô hình nền cho mọi tác tử là GPT-5 reasoning model
    • Tiêu chí lựa chọn gồm mức độ phổ biến và tính mới, độ phù hợp với các use case tác tử, và năng lực suy luận mạnh đáp ứng kỳ vọng về tác tử tự chủ
    • Phiên bản mô hình dùng trong thí nghiệm là gpt-5-2025-08-07
    • Tham số temperature không được hỗ trợ trong mô hình này nên dùng giá trị mặc định 1.0
    • Cửa sổ ngữ cảnh là 400,000 token, số token đầu ra tối đa là 128,000 token
    • Mốc cắt tri thức là ngày 30 tháng 9 năm 2024

  • Pipeline phân tích

    • Ở bước thu thập dấu vết, ChatDev được gắn công cụ theo dõi để ghi log toàn bộ dấu vết thực thi của từng tác vụ trong 30 tác vụ
    • Ghi lại prompt, phản hồi và số token đầu vào, đầu ra, suy luận của từng lời gọi LLM
    • Ánh xạ giai đoạn là phương pháp cốt lõi nhằm chuyển các bước nội bộ của framework ChatDev thành các giai đoạn phát triển phổ quát
    • Sự trừu tượng hóa này cho phép phân tích có thể khái quát hóa và mở rộng sang các framework LLM-MA khác cho kỹ thuật phần mềm
    • Việc tổng hợp token được thực hiện bằng script Python
    • Dấu vết thu thập được được phân tích và tổng số token theo từng giai đoạn phát triển được cộng dồn trên toàn bộ 30 lần chạy
    • Phân tách thành token đầu vào, đầu ra và suy luận

  • Ánh xạ bước nội bộ của ChatDev sang giai đoạn phát triển

    • Giai đoạn thiết kế tương ứng với DemandAnalysis, LanguageChoose, tập trung vào hiểu yêu cầu và ra quyết định kỹ thuật ở mức cao
    • Giai đoạn lập trình tương ứng với Coding, trực tiếp tham gia viết mã nguồn ban đầu
    • Giai đoạn hoàn thiện mã tương ứng với CodeComplete, hoàn tất các placeholder hoặc các tệp mã chưa hoàn chỉnh còn lại từ giai đoạn lập trình
    • Giai đoạn review mã tương ứng với CodeReview, nơi tác tử lập trình viên và tác tử reviewer trao đổi lặp đi lặp lại để kiểm tra, sửa và cải thiện mã
    • Giai đoạn kiểm thử tương ứng với Test, tập trung vào kiểm thử hệ thống động để tìm và sửa các lỗi ảnh hưởng đến khả năng chạy được
    • Giai đoạn tài liệu hóa tương ứng với EnvironmentDoc, Reflection, Manual, tạo tài liệu phụ thuộc môi trường cần thiết và hướng dẫn sử dụng

Kết quả nghiên cứu và thảo luận

  • Câu hỏi nghiên cứu

    • Câu hỏi cốt lõi là mẫu tiêu thụ token của hệ thống LLM-MA trong các tác vụ phát triển phần mềm
    • Hiểu tokenomics của các hệ thống kỹ thuật phần mềm tác tử là điều quan trọng để triển khai thực tế và bền vững
    • Mức sử dụng token cao liên hệ trực tiếp với chi phí tài chính, tiêu thụ năng lượng và tác động môi trường gia tăng
    • Việc xác định token được tiêu thụ ở đâu trong SDLC cho phép tạo ra một “bản đồ chi phí” hữu ích cho dự đoán chi phí và tối ưu hóa workflow
    • Phân tích được tiến hành theo hai trục
    • Phân bố tổng token theo từng giai đoạn phát triển đã được ánh xạ, như thiết kế, lập trình, v.v.
    • Tỷ lệ token đầu vào, đầu ra và suy luận trong từng giai đoạn
    Quảng cáo

  • Phát hiện 1: Giai đoạn review mã chi phối tiêu thụ token

    • Việc sử dụng token trên toàn bộ quá trình phát triển có phân bố rất không đồng đều
    • Giai đoạn review mã tiêu thụ trung bình 59.4% token trên toàn bộ 30 tác vụ, là khu vực tiêu thụ lớn nhất
    • Giai đoạn hoàn thiện mã xuất hiện ở 6 trong số 30 tác vụ và tiêu thụ trung bình 26.8% token trong các lần chạy đó
    • Giai đoạn tài liệu hóa tiêu thụ trung bình 20.1%, còn kiểm thử tiêu thụ trung bình 10.3% token
    • Giai đoạn kiểm thử xuất hiện ở 12 trong số 30 tác vụ
    • Lập trình ban đầu chỉ chiếm trung bình 8.6%, còn thiết kế là 2.4%, tức chi phí tương đối thấp
    • Chi phí chính của kỹ thuật phần mềm tác tử tập trung vào quá trình cải tiến và kiểm chứng mang tính lặp lại, đối thoại, hơn là sinh mã ban đầu
    • Giá trị n trong hình cho biết số tác vụ trong 30 tác vụ có thực thi giai đoạn tương ứng
    • Không phải mọi giai đoạn đều luôn được thực thi, và các tác tử trong hệ thống đa tác tử tự quyết định có thực hiện một giai đoạn nào đó hay không
    • Thanh sai số là ±1 độ lệch chuẩn, biểu thị mức biến động tiêu thụ token của từng giai đoạn

  • Phát hiện 2: Tiêu thụ token lấy token đầu vào làm trung tâm

    • Ngoại trừ giai đoạn lập trình, ở mọi giai đoạn token đầu vào đều vượt đáng kể token đầu ra và token suy luận
    • Cấu thành sử dụng token trung bình trên toàn bộ tác vụ là 53.9% đầu vào, 24.4% đầu ra, 21.6% suy luận
    • Tỷ lệ xấp xỉ 2:1 giữa token đầu vào và token đầu ra là bằng chứng thực nghiệm mạnh cho “communication tax” đã được nêu trong các nghiên cứu trước
    • Các tác tử tiêu tốn token để lặp đi lặp lại việc truyền những ngữ cảnh lớn trong hội thoại cộng tác
    • Trong các giao thức cộng tác tác tử hiện tại tồn tại sự kém hiệu quả khi phần lớn token được dùng để truyền ngữ cảnh thay vì tạo ra đầu ra mới
    • Communication tax có thể là đặc tính nội tại của kiến trúc đa tác tử dạng hội thoại và là chủ đề cần nghiên cứu thêm trong tương lai

  • Phát hiện 3: Khác biệt về tokenomic profile theo từng giai đoạn phát triển

    • Tỷ lệ token theo từng giai đoạn tạo thành những mẫu riêng cho từng hoạt động kỹ thuật phần mềm
    • Giai đoạn lập trình là ngoại lệ theo hướng đầu ra, với 58.0% đầu ra và 6.9% đầu vào
    • Cấu trúc thiên về đầu ra của giai đoạn lập trình phù hợp với đặc tính tạo mã nguồn dài từ các đặc tả thiết kế ngắn gọn
    • Các giai đoạn kiểm chứng và tài liệu hóa như review mã hay tài liệu hóa lại thiên về đầu vào
    • Tỷ trọng đầu vào của review mã là 51.4%
    • Tỷ trọng đầu vào của tài liệu hóa là 80.2%
    • Các giai đoạn này tiêu thụ mã hiện có như một ngữ cảnh lớn và tạo ra đầu ra phân tích nhỏ hơn
    • Token profile theo giai đoạn có thể được dùng làm bản đồ chi phí cho từng loại hoạt động kỹ thuật
    • Người làm thực tế có thể xác định tốt hơn chi phí dự báo và cơ hội tối ưu hóa quy trình

  • Tỷ lệ token theo từng giai đoạn

    • Tỷ lệ trung bình của giai đoạn thiết kế là 60.4% đầu vào, 3.6% đầu ra, 36.0% suy luận
    • Tỷ lệ trung bình của giai đoạn lập trình là 6.9% đầu vào, 58.0% đầu ra, 35.1% suy luận
    • Tỷ lệ trung bình của giai đoạn hoàn thiện mã là 47.7% đầu vào, 41.7% đầu ra, 10.5% suy luận
    • Tỷ lệ trung bình của giai đoạn review mã là 51.4% đầu vào, 24.7% đầu ra, 23.9% suy luận
    • Tỷ lệ trung bình của giai đoạn kiểm thử là 60.8% đầu vào, 20.7% đầu ra, 18.4% suy luận
    • Tỷ lệ trung bình của giai đoạn tài liệu hóa là 80.2% đầu vào, 8.3% đầu ra, 11.5% suy luận
    • Tỷ lệ trung bình toàn tác vụ là 53.9% đầu vào, 24.4% đầu ra, 21.6% suy luận
    Quảng cáo

  • Thảo luận

    • Kết quả sơ bộ cung cấp bản đồ chi phí ban đầu cho phát triển phần mềm tác tử
    • Chi phí token lớn ở giai đoạn review mã có thể được diễn giải là “chi phí hội thoại”
    • Chi phí này phát sinh trực tiếp từ kiến trúc hội thoại của hệ thống LLM-MA, nơi các tác tử liên tục trao đổi toàn bộ ngữ cảnh mã để cải thiện mã
    • Các giao thức cộng tác tác tử cho kiểm chứng hiện tại có thể cực kỳ kém hiệu quả, vì ngay cả các tác vụ chỉ cần sửa nhỏ cũng có thể tiêu tốn nguồn lực rất lớn
    • Điều này cũng phù hợp với các kết quả của phân loại MAST về lỗi kiểm chứng và lặp lại giai đoạn
    • Mức sử dụng token cao có thể là triệu chứng cho thấy hệ thống tác tử đang cố vượt qua các vấn đề điều phối nội tại bằng đối thoại cưỡng ép
    • Người làm thực tế có thể ước tính chi phí cho các dự án dựa trên tác tử theo loại công việc cần thực hiện
    • Các dự án greenfield có tỷ trọng lập trình ban đầu cao và các dự án tập trung vào refactor hoặc debug mã hiện có sẽ có cấu trúc chi phí khác nhau
    • Với các dự án tập trung vào refactor hoặc debug mã hiện có, các vòng review mã tốn kém và thiên về đầu vào sẽ chi phối chi phí
    • Việc tích hợp checkpoint “human-in-the-loop” trước giai đoạn review mã có thể ngăn các vòng lặp tốn kém và hỗ trợ các quyết định thiết kế nhằm tăng hiệu quả kinh tế lẫn tính toán
    • Một hướng nghiên cứu là thiết kế các giao thức cộng tác hiệu quả token hơn cho kiểm chứng và cải tiến
    • Cần những phương thức vượt ra ngoài việc đơn giản chuyển toàn bộ ngữ cảnh
    • Cần một khung đánh giá chuẩn hóa và toàn diện
    • Khung này có thể đóng vai trò là nền tảng chung để benchmark và so sánh hiệu quả của các kiến trúc LLM-MA khác nhau, như workflow hội thoại phân cấp của ChatDev và dây chuyền dựa trên SOP của MetaGPT
    • Nó cũng có thể đóng vai trò “Rosetta Stone” để dịch hành vi đặc thù của từng framework sang các hoạt động kỹ thuật phần mềm phổ quát

Đe dọa đối với tính hợp lệ và công việc tương lai

  • Đe dọa đối với tính hợp lệ

    • Phân tích dựa trên một hệ thống LLM-MA duy nhất là ChatDev và một LLM duy nhất là GPT-5 Reasoning Model
    • Mẫu tiêu thụ token quan sát được có thể khác ở các kiến trúc LLM-MA khác hoặc ở những LLM có hiệu quả token khác nhau
    • Dù đa dạng, 30 tác vụ phát triển phần mềm có thể vẫn không đại diện cho mọi kịch bản và mức độ phức tạp phát triển phần mềm có thể có
    • Quy mô bộ dữ liệu tuyển chọn này xuất phát trực tiếp từ việc thiếu các benchmark công khai quy mô lớn về dấu vết tác tử chuyên cho kỹ thuật phần mềm
    • Tuyển chọn dữ liệu là một quá trình tốn thời gian và chi phí
    • Một số giai đoạn phát triển chỉ được thực thi trong một tập con nhỏ của 30 tác vụ
    • Hoàn thiện mã có n=6, kiểm thử có n=12, tức chỉ được kích hoạt hiếm khi
    • Vì kết luận về tokenomic profile của các giai đoạn cụ thể này dựa trên mẫu nhỏ nên có thể kém tính đại diện và hạn chế khả năng khái quát hóa
    • Cách ánh xạ các bước nội bộ của ChatDev sang các giai đoạn phát triển phần mềm là một sự trừu tượng hóa
    • Dù là một ánh xạ hợp lý và hữu ích để xây dựng khung đánh giá chuẩn hóa, đây chỉ là một trong nhiều cách có thể để ánh xạ hoạt động tác tử

  • Kết luận và công việc tương lai

    • Trong kỹ thuật phần mềm tác tử, chi phí token không phân bố đồng đều mà tập trung áp đảo vào giai đoạn review mã lặp đi lặp lại và mang tính đối thoại
    • Token đầu vào cấu thành “communication tax” chiếm phần lớn tổng sử dụng token và là khu vực cốt lõi cho tối ưu hóa trong tương lai
    • Nhiệm vụ đầu tiên cho công việc tương lai là mở rộng bộ dữ liệu với nhiều tác vụ hơn để cải thiện khả năng khái quát hóa
    • Nhiệm vụ thứ hai là mở rộng phân tích sang các LLM khác để xác định tác động theo từng mô hình
    • Nhiệm vụ thứ ba là mở rộng phân tích sang các hệ thống LLM-MA khác để so sánh ảnh hưởng của khác biệt kiến trúc lên tokenomics
    • Nhiệm vụ thứ tư là điều tra mối quan hệ giữa mẫu tiêu thụ token và các chế độ lỗi
    • Nhiệm vụ thứ năm là tiếp tục phát triển và kiểm chứng một khung ánh xạ giai đoạn phát triển mạnh mẽ và phổ quát để benchmark hiệu quả của các tác tử kỹ thuật phần mềm

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Tôi đang tự làm và dùng một hệ thống đa tác nhân cho mục đích cá nhân
    Khi đưa vào một vấn đề, trước tiên một mô hình nhanh và rẻ sẽ đặt câu hỏi, rồi dựa trên câu trả lời để tinh chỉnh prompt đầu vào
    Sau đó nó chia vấn đề thành từng phần và chọn chiến lược như để một giám khảo cuối cùng đưa ra kết luận, hoặc để nhiều tác nhân tranh luận rồi giám khảo tóm tắt lại
    Cách tốt nhất là thứ tôi gọi là all angles, chạy song song nhiều chiến lược rồi một meta-giám khảo cuối cùng tổng hợp câu trả lời
    Phần hữu ích nhất tôi mới thêm gần đây là màn hình cho thấy độ lệch giữa các chiến lược
    Tôi dùng nó cho các vấn đề đời sống như tìm nơi ở, trường học, chuyện gia đình

    • Có video demo cái tôi làm ở đây: https://streamable.com/e49cgt
    • Bạn có nhắc đến chi phí, nên tôi muốn hỏi liệu bạn có thể giải thích thêm về cấu trúc chi phí ước tính theo từng loại vấn đề không
      Tôi cũng muốn biết bạn dùng chiến lược nào và chi phí khác nhau ra sao giữa các chiến lược
    • Tôi cũng tò mò bạn dùng execution harness nào, và dùng những LLM nào
    • Tôi cũng đã làm một hệ thống tương tự, nhưng tập trung vào vòng phản hồi nhiều hơn là cải tiến prompt theo hướng thăm dò
      Theo kiểu điều khiển học, tôi liên tục mở rộng thư viện kiểm tra tất định và tự động sửa lỗi để giữ đầu ra của prompt ổn định
      Những “vấn đề” mà thư viện đó không xử lý được sẽ hiện ra cho người đang vận hành quy trình

  • Tôi đã dùng GitHub Copilot rất nhiều trong một tháng không bị gián đoạn, nhưng sau khi họ đổi giá thì sang tháng sau tôi dùng hết token chỉ trong hai ngày
    Một thay đổi đột ngột như vậy khiến tôi thấy giá token có vẻ tùy tiện, và là dấu hiệu cho thấy các công ty AI đang cạn tiền rất nhanh

    • Tôi nghĩ chuyện này giống hệ quả của việc cố đẩy mức định giá tối đa hoặc IPO hơn
      Cũng có tin đồn rằng biên lợi nhuận suy luận vượt 70%
      Lấy SpaceX làm ví dụ, trong 6 tháng qua họ đã tăng giá hàng loạt sản phẩm tiêu dùng, nhưng khi Alphabet và Anthropic cộng lại đang trả hơn 2 tỷ USD mỗi tháng thì không phải là họ đang thiếu tiền
      Microsoft/GitHub vốn ở vị thế đóng gói lại sản phẩm của người khác, nên trong trường hợp này họ là bên bị lỗ
    • Trường hợp GitHub gần với một ngoại lệ trông đặc biệt đột ngột vì gần đây họ có thay đổi chính sách giá
      Nhìn chung, giá được quyết định bởi nhiều yếu tố nền tảng, chứ không có nghĩa bản thân nó là tùy tiện
      Ví dụ, nếu các lãnh đạo GitHub dùng máy tạo số ngẫu nhiên để định giá token thì khi đó mới là định giá tùy tiện

  • Có đoạn nói rằng “token đầu vào chiếm phần lớn nhất trong tiêu thụ với trung bình 53,9%”, nhưng trong mức sử dụng của tôi thì tỷ lệ gần 10:1
    Phần áp đảo trong số token tiêu thụ là ở phía đầu vào, và chuyện tác nhân đọc một triệu token chỉ để sửa một dòng code xảy ra khá thường xuyên
    Nếu gần 1:1 hoặc đầu ra còn lớn hơn thì theo tôi либо tác nhân có vấn đề, либо codebase còn mới hoặc trống

    • Tôi muốn hỏi liệu bạn đã thử cung cấp cho tác nhân những công cụ tốt hơn như AST, language server để khám phá và lập tài liệu cho codebase dễ hơn chưa
      Một triệu token không được cache có vẻ là khá nhiều
    • Nếu token đầu vào thật sự chi phối chi phí ở mức đó, thì chỉ cần tận dụng cache tốt hơn cũng có thể cải thiện lớn
      Có thể cho mô hình làm một bước “nén” một lần bằng cách dump các phần code liên quan, rồi dùng kết quả đó làm tiền tố được cache cho nhiều lần gọi tác nhân con

  • Khi dùng tác nhân để lập trình, chúng có vẻ rất muốn viết unit test tới hàng nghìn cái, nhưng lại ít có xu hướng test động

    • Chúng cũng rất thích đốt rất nhiều token để viết rồi debug những bài test bị hỏng về mặt ngữ nghĩa
    • Unit test cũng là một dạng test động
      Test tĩnh là những thứ như lint hoặc kiểm tra kiểu
      Nếu bạn muốn các loại test động khác ngoài unit test, tôi tò mò không biết bạn đã thử nêu rõ điều đó thành yêu cầu ngay từ giai đoạn lập kế hoạch hoặc PRD chưa
    • AWS cũng rất hay thúc đẩy mạnh những lời giải Lambda phức tạp, gắn càng nhiều dịch vụ AWS tính phí càng tốt vào các yêu cầu đơn giản
      Lợi ích của họ không phải lúc nào cũng trùng với lợi ích của bạn
      Trong trường hợp này, họ muốn bạn tiêu tiền không cần thiết vào công việc vô ích
      Có lẽ cũng nên thôi dùng cách nói giảm là “token”
    • Chỉ cần bảo nó làm nhiều test động hơn
      Tôi nghĩ một phần lý do test động bị né tránh là vì nó làm chậm lại, và có thể khiến phần mềm dừng ở những chỗ không lường trước

  • Tôi nhớ đến một bài báo năm ngoái có cung cấp thông tin hướng dẫn ngân sách để tối ưu hiệu quả sử dụng token
    [1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=Stee...

  • Cái này giống điểm thưởng dặm bay của hãng hàng không, và từ góc nhìn doanh nghiệp thì không có lợi thế gì so với việc thuê thời gian GPU bare-metal

    • Tôi hy vọng giai đoạn tồi tệ này sẽ sớm kết thúc khi có thêm nhiều công ty phần cứng tung ra NPU giá rẻ hơn và kích thước mô hình được tối ưu tốt hơn
      Khi phần lớn nhu cầu AI có thể được đáp ứng bằng phần cứng và mô hình on-premise hoặc on-device, tôi tự hỏi những nông trại tính toán siêu lớn và các mô hình đắt đỏ với chi phí vận hành như vậy còn hữu ích cho việc gì
      Có lẽ khách hàng còn lại chỉ là các chính phủ lớn, và cuối cùng người nộp thuế sẽ phải trả cho hàng chục tỷ USD mà cartel AI đã đầu tư

  • Tôi đã viết một bài Substack về chủ đề này vào tháng 12: https://open.substack.com/pub/zacharywhitley/p/the-coming-ag...

  • Trước đây, các công ty như Google từng tuyển kỹ sư bằng cách xem họ tối ưu hạ tầng giỏi đến đâu
    Chẳng bao lâu nữa có khi các công ty sẽ nhìn vào khả năng tối ưu hiệu quả token AI của kỹ sư

    • Điều đó đòi hỏi giả định rằng token sẽ tiếp tục là một chi phí đáng kể
      Khó chắc được rằng các nhà phát triển sẽ tìm ra thêm cách tiêu nhiều token nhanh đến mức giá giảm hay không
    • Tôi biết một cách đưa chi phí token của công ty về 0
      Chỉ cần coi token như chi phí tiện ích kiểu Internet và để kỹ sư tự trả

  • Một chuyện bên lề khá buồn cười là tôi có mặt trong một cuộc họp xem xét một ứng viên sản phẩm mới, mọi thứ đang diễn ra ổn thì hiện lên một màn hình cho thấy họ đã thêm AI vào sản phẩm đó
    Dĩ nhiên là có AI, và cảm giác rất rõ là bị nhét vào cho có
    Một trong những dấu hiệu rõ nhất là có hẳn một cột hiển thị mỗi truy vấn tốn bao nhiêu token
    Tôi hỏi ai là người trả chi phí token thì họ nói đã gồm trong giấy phép, rồi tôi hỏi có giới hạn ngân sách hay là không giới hạn thì họ bảo đó là câu hỏi hay và sẽ kiểm tra lại
    Lý do tôi hỏi là vì chỉ một truy vấn đơn giản liên quan đến thiết bị vừa được cho xem đã đốt 250 nghìn token
    Lúc đó tôi nghe một vị lãnh đạo phía bên kia nói lớn “Tại sao chúng ta lại đang cho khách hàng xem cái này?” và cả bọn đã cười khá nhiều
    Điều tôi rút ra là chi phí để thêm AI vào mọi thứ đang không được tính toán đúng mức, và chi phí thực sự của vận hành AI ngoài đời lại càng không được phản ánh
    Mọi thứ có AI gắn vào rồi sẽ đắt hơn, dù bạn có muốn hay không

    • AIshittification

  • Tokenomics vốn đã là một từ để mô tả kinh tế học tiền mã hóa, nên dù token trong AI là loại khác thì tôi cũng không hiểu vì sao lại phải cố định nghĩa lại từ đó

    • Tokenomics cũng đã được dùng từ lâu trong cộng đồng người thích cần sa
    • Đây là một mốt mới
      Quên mốt cũ đi, cái này rồi cũng sẽ lỗi thời, nên phải nhảy lên trước khi quá muộn
    • cryptocurrency economics = cryptonomics
    • “Crypto” cũng đã tồn tại từ trước khi tiền mã hóa chiếm nó làm của riêng
      “Web 3.0” cũng đã có từ trước khi phe tiền mã hóa biến Web3 thành thứ xoay quanh crypto
      Vậy nên tôi không thấy có vấn đề gì
      Thuật ngữ vẫn luôn được tái sử dụng trong các bối cảnh khác nhau
      Với lại đa số mọi người cũng đã rời khỏi crypto rồi, nên khả năng gây nhầm lẫn cũng không lớn