Sửa Lỗi Agent Bằng Kỹ Thuật Context Engineering Cho LLM
Khi chuyển từ bản demo sân chơi sang môi trường sản xuất thực tế, trí thông minh của mô hình nền tảng không phải lúc nào cũng là nguyên nhân khiến các AI agent suy giảm hiệu suất. Vấn đề thực sự nằm ở dữ liệu mà nó nhận được. Khi các quy trình làm việc phát triển thành các hệ thống đa bước, việc tinh chỉnh prompt đơn thuần không còn đủ nữa.
Kỹ thuật ngữ cảnh (context engineering) cho LLM chuyển trọng tâm từ việc viết các prompt thông minh sang kiểm soát dữ liệu nào được đưa vào mô hình trong mỗi lần gọi. Bởi vì mọi lượt lịch sử, truy xuất cơ sở dữ liệu và lược đồ công cụ đều cạnh tranh không gian, các kỹ sư phải chủ động quản lý toàn bộ vòng đời của ngữ cảnh khi nó đi vào mô hình.
Mặc dù các thuật ngữ này đôi khi bị nhầm lẫn, kỹ thuật prompt (prompt engineering) và kỹ thuật ngữ cảnh (context engineering) hoạt động ở các tầng khác nhau của ngăn xếp AI:
Trong một thiết lập thực tế, ngữ cảnh là một hỗn hợp dữ liệu thay đổi nhanh chóng, nơi mọi thứ từ hướng dẫn cơ bản đến phản hồi cơ sở dữ liệu lớn đều được chuyển đổi thành token.
Bởi vì bạn đang làm việc với các giới hạn token nghiêm ngặt, các phần khác nhau của ngữ cảnh tích cực cạnh tranh để giành sự chú ý của mô hình. Nếu không có quản lý cửa sổ ngữ cảnh, bạn sẽ gặp phải tình trạng "thối ngữ cảnh" (context rot), nơi các hướng dẫn có giá trị cao mà agent của bạn cần để hoạt động bị chôn vùi dưới dữ liệu thực thi có giá trị thấp.
Để ngăn chặn sự pha loãng này, bạn phải phân tích bốn nguồn chính tạo nên cửa sổ ngữ cảnh.
Thiết kế system prompt của LLM xác định tính cách của agent, các ràng buộc cấu trúc, quy tắc xử lý lỗi và ranh giới thực thi. Mặc dù nó thường được coi là tĩnh, các hệ thống agent phức tạp thường yêu cầu system prompt động, nơi các hướng dẫn được thêm vào hoặc hoán đổi dựa trên trạng thái hiện tại của quy trình làm việc. Bởi vì những hướng dẫn này phải tồn tại qua mọi lượt của một cuộc hội thoại, một system prompt phình to hoạt động như một khoản thuế vĩnh viễn đối với ngân sách token của bạn. Một system prompt chi tiết có thể dễ dàng tiêu thụ 1.000–2.000 token lặp đi lặp lại trong mỗi lần gọi.
Khi một agent bắt đầu lặp lại, quản lý bộ nhớ agent (agent memory management) trở thành người tiêu thụ chính không gian cửa sổ ngữ cảnh. Nhóm này chứa nhật ký đang chạy của các tin nhắn người dùng, phản hồi của trợ lý và các suy nghĩ thực thi trung gian. Nếu bạn mù quáng thêm toàn bộ lịch sử trở lại vòng lặp với mỗi lượt mới, hiệu suất sẽ suy giảm nhanh chóng. Theo thời gian, các tương tác ban đầu trở nên không liên quan hoặc thậm chí mâu thuẫn trực tiếp với nhiệm vụ hiện tại, khiến mô hình mất mạch thực thi.
Khi agent của bạn cần dữ liệu bên ngoài để trả lời một câu hỏi cụ thể, bạn có thể sẽ dựa vào RAG (retrieval-augmented generation) để lấy dữ liệu liên quan từ kho vector hoặc cơ sở dữ liệu. Nhưng việc đổ các payload JSON thô hoặc các đoạn tài liệu lớn vào cửa sổ là một cách nhanh chóng để kích hoạt ảo giác AI (AI hallucinations). Phương pháp tốt nhất là coi các lần lấy dữ liệu này là các bổ sung sạch sẽ, đúng lúc, loại bỏ siêu dữ liệu và đánh dấu cấu trúc, chỉ trích xuất các đoạn văn bản chính xác cần thiết cho bước ngay lập tức.
Nếu agent của bạn sử dụng các công cụ, bạn phải phân bổ không gian cho các định nghĩa của chúng. Mọi mô tả endpoint API, ràng buộc tham số và lược đồ đầu ra JSON dự kiến phải nằm trong cửa sổ ngữ cảnh LLM để mô hình biết cách định dạng các lệnh gọi của nó. Nếu
Bạn cấp cho một agent quyền truy cập vào một danh mục công cụ toàn cầu, thì riêng các định nghĩa cấu trúc này đã có thể tiêu tốn toàn bộ ngân sách token của nó trước khi nó xử lý truy vấn thực tế của người dùng.
Nếu không được quản lý, bốn nguồn này có thể mở rộng độc lập: Prompt hệ thống phình to khi yêu cầu phát triển, bộ nhớ tích lũy theo từng cuộc hội thoại, kết quả RAG thay đổi kích thước theo mỗi truy vấn, và định nghĩa công cụ mở rộng theo từng khả năng mới. Quản lý chúng đồng nghĩa với việc đưa ra các quyết định có chủ đích về dung lượng mà mỗi thành phần được cấp và những gì phải cắt bỏ khi chúng không vừa.
Trong môi trường sản xuất, một cửa sổ ngữ cảnh không được quản lý dẫn đến bỏ sót hướng dẫn, truy xuất kém, và chi phí gia tăng. Khi các vòng lặp thực thi lặp đi lặp lại, ngữ cảnh trở nên nặng nề hơn, tốn kém hơn, và lộn xộn hơn cho đến khi mô hình bỏ qua các hướng dẫn quan trọng, bị ảo giác, hoặc chọn sai công cụ.
Để ngăn chặn sự cố này, hãy triển khai các chiến lược cấu trúc kiểm soát những gì mô hình thấy ở mỗi bước. Hãy nghĩ về nó như một đường ống lọc liên tục loại bỏ dữ liệu không liên quan và chỉ giữ lại thông tin cần thiết cho hành động hiện tại.
Dưới đây là bốn mẫu cốt lõi mà các kỹ sư dựa vào để kiểm soát những gì đi vào cửa sổ ngữ cảnh.
**Kết nối các chiến lược ghi, chọn, nén và cô lập như các nút có thể kiểm tra**
Cách đơn giản nhất để kiểm soát kích thước ngữ cảnh là kỷ luật về những gì bạn viết vào prompt hệ thống. Thiết kế prompt hệ thống LLM tốt không có nghĩa là nhồi nhét hướng dẫn bằng văn bản phòng thủ hoặc cầu xin mô hình "hãy chú ý kỹ." Thay vào đó, đó là việc sử dụng các định dạng có cấu trúc, súc tích như tiêu đề markdown và lược đồ JSON rõ ràng. Mỗi câu trong prompt hệ thống của bạn phải chứng minh được sự cần thiết của nó. Loại bỏ bất kỳ ràng buộc nào không cần thiết cho nhiệm vụ cốt lõi. Nếu không, bạn đang thêm chi phí không cần thiết vào mỗi bước suy luận.
Bạn không cần phải cung cấp cho mô hình toàn bộ lịch sử hoặc cơ sở dữ liệu cùng một lúc. Các chiến lược chọn tập trung vào việc lọc dữ liệu trước khi nó chạm vào cửa sổ ngữ cảnh. Đối với nhật ký hội thoại, điều đó có nghĩa là chuyển từ việc đổ toàn bộ lịch sử trò chuyện sang sử dụng bộ đệm cửa sổ trượt chỉ giữ lại các lượt gần đây nhất. Đối với dữ liệu bên ngoài, điều đó có nghĩa là sử dụng RAG hoặc truy xuất có mục tiêu để lấy các khối dữ liệu cụ thể dựa trên ý định tức thời của người dùng. Nguyên tắc tương tự áp dụng cho định nghĩa công cụ khi bạn chỉ hiển thị các công cụ liên quan đến nhiệm vụ hiện tại thay vì cấp quyền truy cập vào mọi thứ theo mặc định.
Khi bạn có thông tin có giá trị cao nhưng quá dài để truyền thô, đã đến lúc nén để tăng mật độ thông tin. Có hai lựa chọn để triển khai nén:
Bằng cách cô đọng dữ liệu trước, bạn đảm bảo agent giữ lại ngữ cảnh cốt lõi cần thiết mà không làm cạn kiệt cửa sổ ngữ cảnh LLM của chính nó.
Nếu agent của bạn cố gắng làm mọi thứ trong một cửa sổ ngữ cảnh khổng lồ, nó sẽ gặp khó khăn khi quy trình làm việc trở nên phức tạp hơn. Cô lập phá vỡ một agent nguyên khối thành một mạng lưới các bước chuyên biệt nhỏ hơn. Mỗi bước hoạt động trong cửa sổ ngữ cảnh bị cô lập riêng của nó, chỉ chứa công cụ cụ thể
ls, hướng dẫn và các đoạn dữ liệu cần thiết cho tác vụ hẹp của nó. Bằng cách chỉ truyền các đầu ra cuối cùng giữa các khối biệt lập này, bạn giữ cho mức sử dụng token thấp và ngăn lỗi ở một bước ảnh hưởng đến phần còn lại của quy trình. Sự đánh đổi là việc điều phối, nơi bạn phải quyết định mỗi bước nhận gì và cái gì được chuyển tiếp.
Trong các framework ưu tiên mã code hoặc script điều phối tùy chỉnh, ngữ cảnh thường được quản lý theo cách lập trình. Khi một agent rơi vào vòng lặp vô hạn hoặc ảo giác trong sản xuất, việc gỡ lỗi có nghĩa là theo dõi qua các log để tái tạo lại những gì mô hình thực sự nhận được.
n8n thay đổi điều này bằng cách hiển thị toàn bộ vòng đời ngữ cảnh dưới dạng các node có thể cấu hình và kiểm tra. Thay vì dựa vào các trừu tượng hóa cứng nhắc, bạn có được quyền kiểm soát trực tiếp, chi tiết đối với các backend bộ nhớ, ngưỡng cửa sổ ngữ cảnh, thời điểm truy xuất và phạm vi gọi công cụ.
Bạn có thể triển khai từng chiến lược ngữ cảnh được đề cập ở trên với các thành phần quy trình cụ thể. Các node IF/Switch xử lý việc lựa chọn ngữ cảnh động, định tuyến các truy vấn đến các đường dẫn truy xuất khác nhau dựa trên ý định hoặc loại người dùng. Node Code hoặc Basic LLM Chain cho phép bạn nén dữ liệu, tóm tắt lịch sử hoặc trích xuất các sự kiện có cấu trúc trước khi chúng đi vào cửa sổ ngữ cảnh.
Các quy trình con (sub-workflows) rất tốt cho việc cách ly, nơi mỗi agent con hoạt động trong ngữ cảnh riêng của nó chỉ với các công cụ và dữ liệu cần thiết. Các node con bộ nhớ (Memory sub-nodes) xử lý việc quản lý lịch sử, kiểm soát số lượt tương tác được duy trì và nơi chúng được lưu trữ. Mọi quyết định về những gì đi vào cửa sổ ngữ cảnh đều là một node trên canvas, không phải là một dòng mã ẩn sâu trong code.
Vì n8n được xây dựng xung quanh việc điều phối quy trình trực quan, bạn có thể kiểm tra, gỡ lỗi và sửa đổi các luồng ngữ cảnh tại mọi bước thực thi. Nếu một agent thất bại, bạn không cần phải đoán xem điều gì đã sai. Bạn có thể mở lịch sử thực thi và xem log của agent, xem chính xác payload JSON được gửi đến LLM tại bước suy luận đó, xem dữ liệu đầu vào, những gì mô hình trả về và điều chỉnh logic quy trình trực tiếp.
Tính không phụ thuộc vào nhà cung cấp này
