CHUYÊN ĐỀ CONTEXT ENGINEERING: Dynamic Context Pruning – Tối ưu ngữ cảnh cho AI agent

Dynamic Context Pruning giúp AI agent ưu tiên tín hiệu quan trọng trong giới hạn token.

Một cửa sổ ngữ cảnh lớn không đồng nghĩa với một ngữ cảnh tốt. Khi AI agent làm việc qua nhiều lượt, prompt có thể nhanh chóng tích tụ lịch sử hội thoại, tài liệu truy xuất, kết quả công cụ, ghi chú và các quyết định cũ. Nếu đưa tất cả vào mỗi lần gọi mô hình, hệ thống phải trả chi phí token cao hơn, chờ lâu hơn và đối mặt với nhiều tín hiệu cạnh tranh hơn. Dynamic Context Pruning — cắt tỉa ngữ cảnh động — là cách chọn lại phần thông tin thực sự cần cho nhiệm vụ hiện tại, trong khi bảo vệ các ràng buộc và quan hệ phụ thuộc không được phép mất.

Đây không phải lời hứa rằng cứ xóa token là mô hình sẽ tốt hơn. Pruning là một bài toán tối ưu có rủi ro: tiết kiệm ngân sách ngữ cảnh nhưng có thể làm mất bằng chứng, trạng thái công cụ hoặc một yêu cầu quan trọng. Vì vậy, hệ thống production cần kết hợp chấm điểm, quy tắc bảo vệ, quan sát kết quả và cơ chế fallback.

Dynamic Context Pruning là gì?

Trong bài này, Dynamic Context Pruning được hiểu là quá trình đánh giá và loại bỏ có điều kiện những đơn vị ngữ cảnh có giá trị thấp đối với truy vấn hoặc trạng thái hiện tại, dưới một ngân sách token, latency hay chi phí. “Dynamic” nhấn mạnh rằng quyết định có thể thay đổi theo câu hỏi, bước thực thi, kết quả tool và mục tiêu của agent; một đoạn bị bỏ ở lượt này vẫn có thể được truy xuất lại ở lượt sau.

Đơn vị bị cắt có thể là cả tin nhắn, đoạn tài liệu, kết quả tool, câu, cụm từ hoặc token. Một triển khai tốt không chỉ hỏi “đoạn này có liên quan không?” mà còn hỏi “đoạn nào phụ thuộc vào nó?”, “nó có chứa chỉ dẫn an toàn không?”, “nó có phải bằng chứng cho kết luận đang dùng không?” và “có thể phục hồi nó khi cần không?”.

Hai lớp cắt tỉa cần phân biệt

Cắt tỉa bên ngoài mô hình diễn ra trước khi tạo prompt cuối: hệ thống phân đoạn, chấm điểm, loại trùng, giữ các mục quan trọng rồi đóng gói theo ngân sách. Đây là lớp dễ kiểm soát và audit nhất trong ứng dụng AI agent.

Cắt tỉa bên trong inference loại hoặc trì hoãn việc xử lý token ở các lớp mô hình hay bước giải mã. LazyLLM là một hướng nghiên cứu thuộc nhóm này: token được giữ hay bỏ có thể thay đổi theo từng bước sinh. Nó đòi hỏi quyền can thiệp sâu vào runtime/model và không tương đương với việc ứng dụng xóa vài tin nhắn khỏi prompt.

Khác compression, summarization, truncation và retrieval

Trong thực tế, các kỹ thuật bổ trợ nhau. Retrieval lấy ứng viên; reranker sắp xếp; pruning loại phần ít hữu ích; compression rút gọn phần dài; token-budget packing tạo prompt cuối. Gọi tất cả là “pruning” sẽ khiến kiến trúc và benchmark khó so sánh.

Vì sao “nhiều context hơn” chưa chắc tốt hơn?

Chi phí, độ trễ, nhiễu và lost-in-the-middle

Token đầu vào thường được tính vào chi phí API và phải đi qua các bước tiền xử lý, attention hoặc quản lý KV cache. Trong Transformer chuẩn, self-attention có chi phí theo cặp token, dù các runtime hiện đại có nhiều tối ưu và không phải mọi pha đều tuân một công thức chi phí giống nhau. Kết luận an toàn là: context dài hơn thường làm tăng tài nguyên và độ trễ, nhưng mức tăng cụ thể phụ thuộc model, phần cứng, batching, cache và kiến trúc phục vụ.

Vấn đề không chỉ là hiệu năng. Nghiên cứu Lost in the Middle cho thấy trên các thiết lập được thử nghiệm, hiệu quả có thể cao hơn khi thông tin liên quan nằm ở đầu hoặc cuối context và giảm khi nó nằm giữa. Đây là bằng chứng chống lại giả định “đã nằm trong cửa sổ thì mô hình sẽ dùng tốt như nhau”, chứ không phải quy luật tuyệt đối cho mọi model hay nhiệm vụ.

Context dài còn tạo nhiễu: nhiều đoạn gần đúng cạnh tranh với bằng chứng chính; hướng dẫn cũ xung đột với yêu cầu mới; kết quả tool lỗi vẫn nằm cạnh kết quả đã sửa; những câu lặp lại làm tăng trọng số ngầm cho một ý. Pruning vì thế vừa là tối ưu hạ tầng, vừa là thiết kế chất lượng tín hiệu.

Các failure mode thường gặp

1. Xóa nhầm ràng buộc: mất yêu cầu định dạng, ngôn ngữ, phạm vi hoặc điều kiện an toàn.
2. Đứt cặp tool call–result: mô hình thấy lời gọi nhưng không thấy kết quả, hoặc ngược lại.
3. Mất provenance: giữ kết luận nhưng bỏ nguồn, khiến câu trả lời không thể kiểm chứng.
4. Sai recency: ưu tiên tin nhắn mới dù một quyết định cũ vẫn còn hiệu lực.
5. Tóm tắt trôi nghĩa: bản summary lặp qua nhiều vòng dần biến đổi dữ kiện.
6. Pruning theo truy vấn quá hẹp: loại bối cảnh cần cho bước kế tiếp của agent.
7. Không thể phục hồi: dữ liệu bị xóa khỏi cả prompt lẫn kho lưu trữ.

Cơ chế chấm điểm: không chỉ là relevance

Một hệ thống thực tế có thể tính utility cho từng item từ nhiều tín hiệu:

• Relevance: mức liên quan ngữ nghĩa hoặc lexical với truy vấn/bước hiện tại.
• Recency: độ mới của item, có decay theo thời gian hay số lượt.
• Importance: nhãn tầm quan trọng từ con người, policy hoặc model; ví dụ quyết định đã duyệt có trọng số cao.
• Redundancy: mức trùng với item khác; chỉ nên giữ bản rõ, mới và có nguồn tốt nhất.
• Dependency: item có phải tiền đề của quyết định, trích dẫn hay trạng thái tool đang được dùng không.
• Risk: hậu quả nếu bỏ nhầm, đặc biệt với safety, quyền hạn, tài chính và dữ liệu cá nhân.
• Recoverability: có thể truy xuất nguyên bản nhanh chóng từ durable store hay không.

Điểm tổng hợp chỉ nên dùng để xếp hạng ứng viên. Trước đó phải có lớp hard pinning cho system instructions, chính sách an toàn, yêu cầu người dùng chưa hoàn thành, quyết định đang hiệu lực và các bằng chứng bắt buộc. Sau đó, dependency graph mở rộng tập bảo vệ: nếu giữ một kết luận, phải giữ hoặc liên kết đến nguồn của nó; nếu giữ tool result, cần giữ tên tool, tham số thiết yếu và trạng thái liên quan.

Pipeline trước, trong và sau inference

Pipeline cắt tỉa ngữ cảnh động có lớp bảo vệ phụ thuộc và cơ chế đánh giá sau inference.

Trước inference: tạo context có chủ đích

Pipeline bắt đầu bằng việc gom ứng viên từ hội thoại, memory, retrieval và tool state. Nội dung được chuẩn hóa thành item có ID, timestamp, nguồn, loại, số token và quan hệ phụ thuộc. Hệ thống pin các mục bất khả xâm phạm, lọc dữ liệu hết hạn, khử trùng lặp rồi chấm relevance, recency và importance. Reranker có thể tinh chỉnh thứ tự. Cuối cùng, bộ đóng gói chọn item theo token budget; đoạn quá dài có thể được nén với liên kết về bản gốc.

Trong inference: tối ưu ở runtime/model

Với runtime tự quản lý, các nghiên cứu như LazyLLM mở ra việc bỏ qua token khác nhau theo layer hoặc bước giải mã. Hướng này có thể giảm tính toán mà không buộc ứng dụng xóa token khỏi prompt, nhưng cần benchmark riêng cho prefill, decoding, chất lượng và tương thích model. Đội ứng dụng dùng API đóng thường không có quyền triển khai lớp này và không nên quảng bá nó như tính năng sẵn có.

Sau inference: đánh giá và học từ pruning regret

Sau mỗi lần gọi, hệ thống ghi lại item đã giữ/bỏ, lý do, phiên bản scorer, token trước–sau, latency, chi phí và kết quả nhiệm vụ. Nếu câu trả lời thiếu bằng chứng, mâu thuẫn hoặc tool thất bại, có thể chạy lại với context rộng hơn. “Pruning regret” đo trường hợp item bị loại nhưng sau đó chứng minh là cần thiết. Đây là tín hiệu quan trọng để chỉnh ngưỡng, policy và tập dữ liệu huấn luyện reranker.

Bốn nhóm chiến lược triển khai

So sánh bốn chiến lược pruning và nhóm chỉ số cần đo trong production.

1. Rule-based

Quy tắc như “pin 4 lượt gần nhất”, “xóa tool output đã hết hạn”, “giữ mọi quyết định có trạng thái open” dễ giải thích và rẻ. Nhược điểm là brittle khi workflow đổi, đồng thời recency không đảm bảo relevance. Rule-based phù hợp làm baseline và safety guard, hiếm khi đủ nếu đứng một mình.

2. Embedding và reranker

Embedding tìm nhanh các đoạn gần truy vấn; reranker đánh giá sâu hơn top ứng viên. Cách này phù hợp tài liệu lớn và nhiều chủ đề, nhưng semantic similarity vẫn có thể bỏ sót ID, con số, phủ định hoặc phụ thuộc procedural. Cần kết hợp lexical match, metadata và dependency guard.

3. Learned policy

Một classifier hoặc policy có thể học quyết định keep/drop từ dữ liệu nhiệm vụ, phản hồi người dùng hay kết quả agent. Nó thích nghi tốt hơn với pattern phức tạp, nhưng đòi hỏi nhãn đáng tin cậy, kiểm soát drift và khả năng giải thích. Learned policy không nên được quyền xóa system/safety constraints.

4. Hybrid

Hybrid thường là lựa chọn production hợp lý: quy tắc pin và dependency guard tạo biên an toàn; embedding/reranker tối ưu relevance; bộ phát hiện trùng giảm redundancy; compression xử lý item lớn; learned policy chỉ điều chỉnh phần rủi ro thấp. Khi confidence thấp hoặc nhiệm vụ rủi ro cao, hệ thống tăng budget hay tắt pruning.

Đo hiệu quả: đừng chỉ báo “giảm bao nhiêu token”

Một dashboard tối thiểu nên gồm:

• token reduction và compression ratio;
• task success/quality retention so với baseline không pruning;
• recall của critical facts và safety-constraint retention;
• citation fidelity, contradiction và hallucination rate;
• latency p50/p95, time-to-first-token và end-to-end latency;
• chi phí theo nhiệm vụ hoàn tất, không chỉ chi phí mỗi call;
• tool success rate, số lần retry/fallback;
• pruning regret và tỷ lệ khôi phục item.

Nên chạy A/B trên tập nhiệm vụ đại diện, tách theo độ dài context và mức rủi ro. Baseline cần dùng cùng model, temperature, toolset và hạ tầng. Con số từ paper không thể chuyển thẳng thành SLA production.

Bốn thí nghiệm/case nghiên cứu có nguồn

Lost in the Middle (Liu và cộng sự): các thí nghiệm multi-document question answering và key-value retrieval chỉ ra độ nhạy với vị trí thông tin trong context. Ý nghĩa cho pruning là ưu tiên tín hiệu quan trọng và kiểm thử vị trí sau khi đóng gói. Kết quả phụ thuộc model, nhiệm vụ và độ dài được nghiên cứu.

Context compression của Li và cộng sự: công trình *Compressing Context to Enhance Inference Efficiency of Large Language Models* dùng độ đo thông tin để lọc phần context ít hữu ích trước inference. Đây là ví dụ gần với informed context pruning. Các mức tiết kiệm/chất lượng phải được đọc cùng dataset, model và tỷ lệ nén trong paper; không nên biến thành tuyên bố phổ quát.

LLMLingua và LongLLMLingua (Jiang và cộng sự): hai công trình nghiên cứu prompt compression, gồm budget controller, token-level compression và trong LongLLMLingua là question-aware compression/reordering cho long context. Chúng là bằng chứng rằng lựa chọn và nén có điều kiện có thể cải thiện hiệu quả trong các benchmark đã thử, nhưng compression không đồng nhất với deletion-only pruning.

LazyLLM (Fu và cộng sự): nghiên cứu dynamic token pruning trong inference, nơi tầm quan trọng token thay đổi theo layer và bước sinh. Case này cho thấy “dynamic” có thể nằm bên trong model runtime. Tuy nhiên, lợi ích latency/compute chỉ có ý nghĩa dưới model, phần cứng và cấu hình đánh giá của công trình.

Pseudocode triển khai tham khảo

def build_context(query, items, budget):

pinned = [x for x in items if x.is_system or x.is_safety

or x.is_open_constraint]

candidates = [x for x in items if x not in pinned]

for item in candidates:

item.score = (

W_REL * relevance(query, item)

+ W_REC * recency(item)

+ W_IMP * importance(item)

– W_RED * redundancy(item, candidates)

)

protected = dependency_closure(pinned, candidates)

selected = protected + budgeted_pack(

sorted(candidates, key=lambda x: x.score, reverse=True),

remaining_tokens=budget – tokens(protected),

)

selected = compress_large_items(selected, keep_source_links=True)

assert preserves_tool_pairs(selected)

assert preserves_citations(selected)

log_pruning_decisions(items, selected)

return selected

Ở production, cần xử lý trường hợp tokens(protected) > budget: không được âm thầm xóa safety constraint. Hệ thống nên chuyển sang model/context window phù hợp hơn, chia nhiệm vụ, yêu cầu người dùng làm rõ hoặc dừng với lỗi có thể hành động.

Guardrails và best practices

1. Pin theo policy trước khi chấm điểm: system, safety, quyền hạn và open constraints không đi qua ngưỡng relevance thông thường.
2. Giữ dependency closure: bảo vệ tool call/result, quyết định/tiền đề và claim/citation như một cụm.
3. Lưu bản gốc ngoài prompt: pruning phải là thao tác có thể đảo ngược; summary luôn có source pointer.
4. Ghi reason code: mỗi item bị loại cần lý do như expired, duplicate, low-relevance hay superseded.
5. Dùng budget theo rủi ro: tác vụ tài chính, y tế, pháp lý hoặc destructive cần ngưỡng bảo thủ hơn.
6. Fallback theo confidence: nếu khoảng cách điểm thấp hoặc thiếu nguồn, mở rộng context và chạy lại.
7. Chống prompt injection: dữ liệu retrieved/tool output không được nâng cấp thành system instruction chỉ vì có điểm relevance cao.
8. Đánh giá end-to-end: tiết kiệm một call nhưng gây retry có thể làm tổng chi phí tăng.
9. Canary và rollback: rollout scorer/policy theo phiên bản, giám sát regression theo nhóm nhiệm vụ.

Checklist production

• ☐ Có schema item gồm ID, nguồn, thời gian, loại, token count và dependencies.
• ☐ System/safety/open constraints được pin bằng policy độc lập.
• ☐ Tool call–result và claim–citation được kiểm tra toàn vẹn.
• ☐ Baseline không pruning và bộ dữ liệu đánh giá đã cố định.
• ☐ Đo token, quality, critical-fact recall, latency, cost và pruning regret.
• ☐ Có log keep/drop, version scorer và khả năng replay.
• ☐ Có durable store để phục hồi nguyên bản.
• ☐ Có fallback khi confidence thấp hoặc protected set vượt budget.
• ☐ Đã test multilingual, số liệu, phủ định, hội thoại dài và tool failure.
• ☐ Có canary, cảnh báo và rollback.

Kết luận

Dynamic Context Pruning không phải thao tác “dọn prompt” đơn giản. Nó là một lớp điều phối thông tin: giữ tín hiệu có giá trị, bảo vệ quan hệ phụ thuộc và dùng ngân sách ngữ cảnh có chủ đích. Thiết kế tốt thường là hybrid, bắt đầu từ hard pinning và dependency guard, sau đó mới chấm relevance, recency, importance và redundancy; compression chỉ là bước bổ sung.

Đội ngũ nên đánh giá pruning bằng kết quả nhiệm vụ, khả năng giữ dữ kiện quan trọng và chi phí end-to-end. Khi mọi quyết định keep/drop đều có dấu vết và có thể phục hồi, pruning trở thành một năng lực context engineering đáng tin cậy thay vì một thủ thuật tiết kiệm token đầy may rủi.

FAQ

1. Dynamic Context Pruning có làm mô hình mất trí nhớ không?

Không nhất thiết. Pruning nên chỉ loại nội dung khỏi prompt hiện tại, còn bản gốc nằm trong durable store để truy xuất lại. Nếu xóa cả dữ liệu nguồn, đó là chính sách retention/forgetting, không chỉ là context pruning.

2. Pruning khác RAG như thế nào?

RAG truy xuất tài liệu bên ngoài để đưa vào context; pruning chọn phần nào trong tập context đã gom nên được giữ. Một pipeline có thể dùng RAG trước, reranking và pruning sau.

3. Có nên luôn giữ các tin nhắn gần nhất không?

Nên coi recency là một tín hiệu, không phải luật tuyệt đối. Tin mới có thể ít quan trọng, trong khi một ràng buộc cũ vẫn có hiệu lực. Open constraints và quyết định cần được pin theo trạng thái.

4. Tỷ lệ giảm token bao nhiêu là tốt?

Không có tỷ lệ chung. Mục tiêu đúng là giảm token trong khi task success, critical-fact recall, safety và citation fidelity nằm trong ngưỡng chấp nhận. Tỷ lệ tối ưu phụ thuộc model, tác vụ và dữ liệu.

5. Có thể dùng một LLM khác để quyết định keep/drop không?

Có, nhưng phải tính thêm chi phí, latency và lỗi của judge model. Với tác vụ rủi ro cao, quyết định của LLM vẫn cần policy guard, log và fallback.

6. Khi nào không nên pruning?

Không nên pruning mạnh khi context còn ngắn, nhiệm vụ yêu cầu đọc toàn văn, phụ thuộc khó xác định, hoặc hậu quả bỏ nhầm rất cao. Nếu protected set đã gần bằng budget, chia nhiệm vụ hay dùng context window lớn hơn thường an toàn hơn.

Nguồn tham khảo

Ngày truy cập cho toàn bộ nguồn: 10/08/2026.

1. Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, Percy Liang. Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172, bản đầu 06/07/2023; TACL 2024. https://arxiv.org/abs/2307.03172
2. Yucheng Li, Bo Dong, Chenghua Lin, Frank Guerin. Compressing Context to Enhance Inference Efficiency of Large Language Models. arXiv:2310.06201, 09/10/2023. https://arxiv.org/abs/2310.06201
3. Huiqiang Jiang, Qianhui Wu, Chin-Yew Lin, Yuqing Yang, Lili Qiu. LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models. Microsoft Research; EMNLP 2023; arXiv:2310.05736, 09/10/2023. https://arxiv.org/abs/2310.05736
4. Huiqiang Jiang, Qianhui Wu, Xufang Luo, Dongsheng Li, Chin-Yew Lin, Yuqing Yang, Lili Qiu. LongLLMLingua: Accelerating and Enhancing LLMs in Long Context Scenarios via Prompt Compression. arXiv:2310.06839, 10/10/2023. https://arxiv.org/abs/2310.06839
5. Qichen Fu, Minsik Cho, Thomas Merth, Sachin Mehta, Mohammad Rastegari, Mahyar Najibi. LazyLLM: Dynamic Token Pruning for Efficient Long Context LLM Inference. arXiv:2407.14057, 19/07/2024; ICML 2024. https://arxiv.org/abs/2407.14057
6. Ashish Vaswani và cộng sự. Attention Is All You Need. NeurIPS 2017; arXiv:1706.03762, 12/06/2017. https://arxiv.org/abs/1706.03762
7. Patrick Lewis và cộng sự. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020; arXiv:2005.11401, 22/05/2020. https://arxiv.org/abs/2005.11401
8. Anthropic Applied AI Team. Effective context engineering for AI agents. Anthropic Engineering, 29/09/2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

**Lưu ý biên tập:** Các kiến trúc production trong bài là khung triển khai tổng hợp, không phải kiến trúc chính thức của một vendor. Mọi con số benchmark khi bổ sung vào bản Word cần giữ nguyên model, dataset, tỷ lệ nén/pruning, phần cứng và baseline của nguồn.

Vui lòng đăng nhập để bình luận.