Giảm token bằng ngữ cảnh gọn, không cắt chất lượng

Trả lời nhanh: Bài này là phần thực hành: bảy kỹ thuật cụ thể để cắt lượng chữ nạp vào mà không làm agent kém đi. Bốn cái hiệu quả nhất: nêu khoảng dòng cần đọc thay vì cả file, giới hạn đầu ra của lệnh chạy vì log dài là nguồn rác lớn nhất, yêu cầu trả về theo định dạng ngắn có ràng buộc số dòng, và giao việc đọc nhiều cho phiên con. Phần lý do vì sao chúng tiết kiệm nằm ở bài về chi phí, ở đây chỉ nói cách làm.

Biết chi phí đến từ phần nạp vào là một chuyện, biết cắt cái gì mà không mất chất lượng là chuyện khác. Bài này liệt kê bảy kỹ thuật cụ thể, kèm ví dụ đối chiếu giữa cách viết tốn và cách viết gọn.

Ba kỹ thuật khi yêu cầu đọc file

Một, nêu khoảng dòng. Với file lớn mà bạn chỉ cần một hàm:

Ton:  Doc src/services/payment.ts roi sua ham tinhPhiGon:  Doc src/services/payment.ts tu dong 120 den 190,      sua ham tinhPhi trong do

Hai, nêu rõ file nào không cần đọc. Với thư mục có nhiều file phụ trợ, một câu loại trừ tiết kiệm rất nhiều: không cần đọc các file kiểm thử và file dữ liệu mẫu trong thư mục đó.

Ba, hỏi trước khi giao việc. Khi bạn chưa biết code nằm đâu, hãy tách làm hai: một lượt hỏi vị trí và trả về danh sách đường dẫn, rồi mở phiên mới với danh sách đó. Cách này thường rẻ hơn để agent vừa tìm vừa làm trong cùng một phiên, vì phần tìm kiếm sẽ nằm lại tới hết phiên.

Giới hạn đầu ra của lệnh

Đây là nguồn rác lớn nhất mà ít người để ý. Một lệnh cài gói hoặc một lượt chạy kiểm thử có thể trả về hàng trăm dòng, và tất cả nằm lại trong ngữ cảnh.

Ton:  npm testGon:  npm test 2>&1 | tail -30 Ton:  cat /var/log/ung-dung.logGon:  grep -i error /var/log/ung-dung.log | tail -20 Ton:  git logGon:  git log --oneline -10

Cách bền hơn là ghi thẳng quy ước này vào file luật dự án: khi chạy lệnh, luôn giới hạn đầu ra ở mức cần thiết; với kiểm thử chỉ lấy phần tóm tắt và các ca thất bại. Khi đó bạn không phải nhắc lại ở mỗi lần.

Ràng buộc định dạng trả về

Agent mặc định trả lời khá dài. Một câu ràng buộc đổi hẳn lượng chữ:

Ton:  Ra soat file nay va cho toi biet co van de giGon:  Ra soat file nay. Tra ve toi da 5 phat hien,      moi phat hien mot dong: duong dan, so dong, van de.      Khong giai thich them, khong de xuat sua.

Ba phần trong câu ràng buộc: số lượng tối đa, định dạng mỗi mục, và những gì không cần. Phần thứ ba tiết kiệm nhiều nhất, vì phần giải thích và đề xuất thường dài gấp nhiều lần phần phát hiện.

Nếu bạn dùng kiểu yêu cầu này thường xuyên, hãy gói thành lệnh tắt theo bài về lệnh tắt, hoặc đặt sẵn trong cách trình bày mặc định theo bài về cách trình bày.

Giao việc đọc nhiều cho phiên con

Kỹ thuật này tiết kiệm nhiều nhất trong repo lớn. Dấu hiệu nhận biết việc nên tách: đầu vào lớn, đầu ra nhỏ.

Ví dụ giao việc cho phiên con:

Tim moi cho trong repo goi truc tiep den bang don_hangma khong qua lop OrderRepository. Chi doc, khong sua gi.Tra ve toi da 15 dong, moi dong: duong dan:so-dong.Khong giai thich.

Toàn bộ nội dung phiên con đọc sẽ biến mất khi nó xong, phiên chính chỉ nhận về mười lăm dòng. Chi tiết về ranh giới nên tách hay không nằm ở bài về subagent.

Nén hội thoại và biết lúc dừng

Kỹ thuật sáu: nén khi chuyển khâu. Khi xong phần khảo sát và chuẩn bị viết code, hãy yêu cầu một bản tóm tắt rồi mở phiên mới với bản đó:

Tom tat phien nay thanh: muc tieu, cac quyet dinh da chot,danh sach file lien quan. Toi da 20 dong.Toi se mang sang phien moi.

Kỹ thuật bảy: biết lúc dừng tối ưu. Đừng dành mười phút để tiết kiệm vài nghìn token trong khi mười phút đó của bạn đáng giá hơn nhiều. Các kỹ thuật ở trên đáng làm vì chúng thành thói quen và không tốn thêm thời gian sau khi quen.

Nguyên tắc cuối cùng và quan trọng nhất: đừng cắt phần khiến agent hiểu sai yêu cầu. Tiết kiệm ngữ cảnh mà phải làm lại từ đầu là lỗ nặng hơn nhiều. Phần lý giải chi phí đến từ đâu nằm ở bài về chi phí token.

Chỗ tiêu tốn nhiều nhất, xếp theo mức độ

Cắt gọn mà không cắt mất thông tin cần

• Giữ nguyên văn thông báo lỗi. Đây là chỗ không được rút gọn. Một dòng lỗi đầy đủ đáng giá hơn cả trang mô tả bằng lời.
• Bỏ phần đã đúng. Nếu một tệp đã chạy tốt và bạn không định sửa nó, đừng đưa vào.
• Thay việc dán bằng việc chỉ đường. Nêu đường dẫn tệp và tên hàm thường hiệu quả hơn dán cả nghìn dòng.

Giới hạn đầu ra ngay từ lệnh

# Thay vi de lenh in ca nghin dong, cat ngay tai nguon: # Nhat ky: chi lay phan cuoitail -n 100 /var/log/nginx/error.log # Tim kiem: gioi han so ket quagrep -rn "ten_ham" src/ | head -n 30 # Danh sach tep: bo qua thu muc phu thuocfind src -name "*.ts" | head -n 50 # Trang thai kho ma: dang ngan gongit status --shortgit diff --stat # Ket qua kiem thu: chi in phan that bainpm test 2>&1 | grep -A 5 -i "fail" | head -n 40

Biết lúc nào nên bắt đầu lại

Khi bạn thấy câu trả lời bắt đầu nhắc lại những thứ đã giải quyết xong từ đầu phiên, đó là dấu hiệu nội dung cũ đang chiếm chỗ. Tóm tắt lại trong năm dòng những gì đã chốt, mở phiên mới, dán năm dòng đó vào. Cách này gần như luôn rẻ hơn việc cố kéo dài một phiên đã quá dài.