Quá trình cô đọng luôn có tổn hao: Phương pháp đo lường lượng thông tin bị loại bỏ trong bản tóm tắt

Hệ thống kiểm thử độ chuẩn xác của quá trình tóm tắt, xuất phát từ thực tế mọi tác tử (agent) hoạt động dài hạn đều có thể rơi vào tình trạng mất trí nhớ chỉ sau một lần nén dữ liệu sai lệch. Hình 01: Khi quá trình nén bộ nhớ của AI trở thành chứng mất trí nhớ AI (hình ảnh của tác giả). Sau ba giờ gỡ lỗi, theo dữ liệu tổng hợp từ nhật ký hoạt động của nhiều nhóm kỹ thuật, một tác tử đã tích lũy đầy đủ ngữ cảnh tạo nên giá trị của các tác tử hoạt động dài hạn: thông báo lỗi ban đầu (chuỗi kết nối Redis dài 400 ký tự chứa một lỗi chính tả mang tính then chốt), danh sách bốn phương án sửa chữa đã thử nghiệm nhưng thất bại, một giả thuyết ngày càng rõ ràng về tình trạng cạn kiệt nhóm kết nối (connection-pool), cùng 17 tệp tin đã can thiệp trong quá trình xử lý. Khi dung lượng ngữ cảnh đạt mức 85%, tiến trình nén (compaction) được kích hoạt theo đúng thiết kế, đúng lịch trình và chuẩn xác theo quy trình kỹ thuật ngữ cảnh (context engineering). Bản tóm tắt do hệ thống tạo ra đạt chất lượng xuất sắc theo mọi tiêu chuẩn biên tập: mạch tự sự rõ ràng, văn phong mạch lạc với nội dung: “Phiên làm việc đã tiến hành gỡ lỗi diện rộng đối với các sự cố kết nối Redis; một số phương pháp đã được thử nghiệm; công tác điều tra về quản lý kết nối đang tiếp tục diễn ra.” Đối với người đọc thông thường, đây là một hình mẫu về tính cô đọng. Tuy nhiên, ở lượt xử lý tiếp theo, tác tử yêu cầu xem lại thông báo lỗi ban đầu, truy xuất lại dữ liệu và chạy lại quy trình chẩn đoán từng thực hiện ở phút thứ 20. Đáng chú ý, qua kiểm tra nhật ký, đội ngũ kỹ thuật phát hiện tác tử đã thử lại phương án sửa lỗi thứ hai vốn đã thất bại trước đó, bởi nội dung “một số phương pháp đã được thử nghiệm” không hề nêu chi tiết phương pháp cụ thể nào. Việc nén dữ liệu đã tiết kiệm khoảng 120.000 token ngữ cảnh. Dù vậy, quá trình tái suy luận kéo theo — bao gồm truy xuất lại, chạy lại chẩn đoán, lặp lại phương án sửa lỗi bế tắc và hàng giờ làm việc của kỹ sư để tìm hiểu nguyên nhân tác tử đi vào vòng lặp — đã gây tiêu tốn tài nguyên gấp nhiều lần lượng token tiết kiệm được, chưa kể đến sự lãng phí công sức. Đây là sự cố mà các đánh giá về giải pháp nén trong ngành hiện đã định lượng được. Kết luận nổi bật đảo ngược hoàn toàn chỉ số mà giới chuyên môn thường tối ưu hóa: “tỷ lệ nén hóa ra là thước đo hoàn toàn sai lầm” — bởi những chi tiết bị mất đi buộc hệ thống phải truy xuất lại dữ liệu, tiêu tốn tài nguyên lớn hơn mức tiết kiệm từ việc nén. Nhiều đội ngũ kỹ thuật từng đánh giá cao mức nén 99% cho đến khi phải đối mặt với cái giá đắt của tình trạng mất dữ liệu này. Do đó, điều cần ghi nhận là: một bản tóm tắt thực chất là một canh bạc về nhu cầu dữ liệu trong tương lai, được đặt cược trong giới hạn ngân sách token bởi một mô hình không có khả năng nhìn thấy tương lai — và hầu như không ai kiểm chứng kết quả của canh bạc đó. Mỗi lần nén dữ liệu đều mang tính chất đặt cược. Rủi ro ở đây là tính liên tục của tác tử — bao gồm mục tiêu, nhiệm vụ, các điểm nghi vấn và những kiến thức phủ định (negative knowledge) phải trả giá mới có được. Tỷ lệ bất lợi là rất lớn, do cơ chế tóm tắt chỉ tối ưu hóa tính mạch lạc cho việc đọc hiểu, trong khi đối tượng tiếp nhận duy nhất lại là một cỗ máy cần hành động. Bài viết này đề cập đến việc đo lường, cấu trúc và kiểm soát canh bạc nói trên — xây dựng hệ thống kiểm thử cho thao tác mà tác tử tự thực hiện trên bộ nhớ của chính mình mà không có sự giám sát, với tần suất hàng chục lần mỗi tuần. Nội dung này khép lại chuỗi phân tích về các dạng thức thất bại, vốn mở đầu bằng bài viết The Harness Is the Product (Khung kiểm thử chính là sản phẩm). Điều này hoàn toàn phù hợp, bởi sự hao hụt do nén dữ liệu là nguyên nhân cốt lõi trong phần lớn các trường hợp: trò chơi truyền khẩu làm xói mòn mục tiêu, các đầu việc cần làm (TODO) bị lược bỏ dẫn đến thiếu sót, và những nhận định thận trọng bị xóa bỏ làm sai lệch mức độ tin cậy. Đã đến lúc xem xét trực tiếp chính cơ chế vận hành này. Hình 02: Canh bạc. Phần 1: Danh mục mất trí nhớ — Những dữ liệu mà các bản tóm tắt thường xuyên làm mất Nén dữ liệu là yêu cầu tất yếu — cửa sổ ngữ cảnh luôn có giới hạn, chi phí tỷ lệ thuận với ngữ cảnh và hiện tượng suy giảm hiệu năng xuất hiện trước khi cửa sổ ngữ cảnh bị lấp đầy. Do đó, vấn đề không phải là có nén hay không, mà là hệ thống nén sẽ loại bỏ những gì. Kiểm tra các sự cố sau khi nén ở nhiều nhóm kỹ thuật cho thấy sự mất mát dữ liệu không diễn ra ngẫu nhiên; Các lỗi này được phân thành bảy nhóm, mỗi nhóm có một biểu hiện đặc trưng ở khâu xử lý tiếp theo: Định danh chính xác. Chuỗi thông báo lỗi, đường dẫn tệp, mã định danh thẻ yêu cầu (ticket ID), mã băm xác thực phiên bản (commit hash), tham số API. Tóm tắt theo lối tự sự thường diễn giải lại nội dung—đó là bản chất của việc tóm tắt trôi chảy—nhưng việc diễn giải một định danh đồng nghĩa với việc phá hủy định danh đó. Tác vụ tiếp theo đòi hỏi chính xác từng byte của chuỗi kết nối dài 400 ký tự, chứ không phải một cụm từ chung chung như "lỗi kết nối Redis". Biểu hiện: hệ thống phải truy xuất lại những dữ liệu vốn đã từng nằm trong ngữ cảnh. Tri thức phủ định. Danh sách các phương án đã thử nghiệm nhưng thất bại là tổn thất tốn kém nhất trong các dữ liệu bị mất, bởi sự thiếu vắng thông tin này không chỉ làm phát sinh chi phí tra cứu mà còn dẫn đến việc lặp lại sai lầm: phương án sửa lỗi thứ hai được thử lại như một giải pháp mới. Quy tắc "giữ lại thông tin lỗi" trong kỹ nghệ ngữ cảnh tồn tại chính vì lịch sử thất bại có vai trò định hướng quá trình tìm kiếm. Tuy nhiên, thao tác nén ngữ cảnh đã vô hiệu hóa quy tắc này, chuyển hóa thông tin "đã thử X, thất bại do Y" thành "đã thử một số phương pháp". Biểu hiện: tác nhân AI lặp lại các bước xử lý mà nhật ký vận hành cho thấy đã từng thực hiện trước đó. Các nghĩa vụ chưa hoàn thành. Những mạch công việc bị bỏ sót do thiếu thông tin: một kế hoạch gồm 10 bước sau hai lần tóm tắt nén chỉ còn 8 bước và các nội dung bị xóa bỏ không để lại dấu vết. Biểu hiện: công việc được coi là hoàn tất dù vẫn còn thiếu sót. Thẻ ghi nhận độ hoài nghi và nguồn gốc dữ liệu. Cơ chế "hợp thức hóa mức độ tin cậy": nhận định "nhiều khả năng là X, từ một nguồn duy nhất" bị tóm tắt thành "X". Các từ ngữ thể hiện sự dè dặt, thận trọng chính là chi tiết bị loại bỏ khi tối ưu hóa độ trôi chảy của văn bản; sự biến mất của chúng biến những phỏng đoán ở bước 12 thành tiền đề ở bước 37. Biểu hiện: khâu xử lý phía sau có sự chắc chắn mà khâu phía trước chưa từng xác lập. Bản thân mục tiêu. Hiện tượng "tam sao thất bản" trong nội bộ hệ thống: từ mục tiêu "chuyển đổi 214 dịch vụ mà không làm thay đổi hành vi" bị rút gọn thành "cải thiện việc ghi nhật ký (logging)". Biểu hiện: nỗ lực thực hiện một mục tiêu đã bị chệch hướng so với ban đầu. Số lượng và chi tiết định lượng. Số liệu bị làm tròn, các ngưỡng kỹ thuật bị lược bỏ, mệnh đề "3 bài kiểm thử thất bại trong tệp auth_test.py" bị biến thành "một số bài kiểm thử thất bại". Biểu hiện: các quyết định ở khâu sau được đưa ra dựa trên những căn cứ mơ hồ hơn nhiều so với dữ liệu thực tế thu được trong quá trình vận hành. Dấu mốc trạng thái thực tế. Các thẻ mốc thời điểm, dấu thời gian cập nhật, định danh phiên bản. Biểu hiện: các nhận định đã lỗi thời nhưng thiếu siêu dữ liệu về thời hạn hiệu lực, dẫn đến tình trạng không thể phân biệt chúng với các thông tin mới. Điểm chung của danh sách nêu trên là: mọi nhóm thông tin đều mang tính sống còn về mặt vận hành nhưng lại không bắt buộc về mặt diễn đạt tự sự. Một biên tập viên con người có thể lược bỏ cả bảy yếu tố nhằm giúp văn bản tóm tắt dễ đọc hơn; và mô hình tóm tắt, về bản chất, chính là sự kế thừa tập phân phối dữ liệu huấn luyện của một biên tập viên con người dưới dạng giao diện lập trình ứng dụng (API). Sự lệch pha mang tính cấu trúc: đối tượng duy nhất tiếp nhận văn bản tóm tắt là máy móc—vốn cần dữ liệu để hành động—nhưng văn bản lại được soạn thảo cho đối tượng muốn đọc hiểu. Không ai tìm kiếm sự trải nghiệm văn chương trong một bản nén ngữ cảnh kỹ thuật; do đó, cần dừng việc soạn thảo theo hướng này. Phần 2: Đo lường bài toán đặt cược — Bộ công cụ thăm dò (Probe Harness) Không thể cải tiến những gì không thể đánh giá điểm số