Context Optimization: Tối ưu ngữ cảnh #12

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Context Optimization là quá trình chọn, biến đổi và sắp xếp đầu vào để tăng giá trị cho một nhiệm vụ trong giới hạn cho phép. Cần học vì prompt dài không đồng nghĩa AI hiểu tốt hơn: bằng chứng quan trọng có thể bị chìm, mâu thuẫn, sai quyền hoặc chiếm hết chỗ dành cho câu trả lời.

Đọc xong, bạn sẽ hiểu:

• Cách chia context budget và đóng gói một Context Pack có thể truy ngược.
• Cách quyết định giữ, rút gọn, bỏ hoặc chặn từng đoạn bằng chứng.
• Cách kiểm tra chất lượng sau nén thay vì chỉ khoe số lượng đầu vào đã giảm.

1. Context Optimization là gì, và vì sao nhét thêm có thể làm tệ hơn?

Hãy hình dung bạn chuẩn bị vali 20 kg. Nếu nhét đầy quần áo trước chuyến đi, bạn không còn chỗ cho tài liệu làm việc và đồ mang về. Prompt cũng vậy. Context budget là giới hạn được phân bổ cho instruction, câu hỏi, bằng chứng, nguồn trích dẫn và phần trả lời cần sinh. Output reserve là phần chừa trước cho câu trả lời, không phải khoảng trống dùng thừa mới tính.

Nhét thêm có thể gây lặp, trộn tài liệu cũ–mới, đưa nhầm dữ liệu của khách hàng khác hoặc chôn bằng chứng đúng giữa một khối nhiễu dài.

Ví dụ, người dùng hỏi cách xử lý ERR_CONN_RESET khi đăng nhập SSO. Hệ thống tìm tám đoạn: policy hiện hành, bản sao, hướng dẫn lỗi, phỏng đoán diễn đàn, policy cũ, tài liệu tenant B, bước xử lý an toàn và bảng thuật ngữ. Đẩy cả tám vào model là chuyển trách nhiệm lựa chọn sang nơi khó kiểm soát.

Nghiên cứu Lost in the Middle cho thấy ở các model và task được thử, hiệu quả thường giảm khi thông tin liên quan nằm giữa ngữ cảnh dài. Đây là lý do để test vị trí, không phải luật “đặt đầu luôn thắng”.

Đoạn sai tenant chắc chắn phải bị chặn trước model. Đưa evidence quan trọng gần câu hỏi có thể cải thiện kết quả, nhưng phải đo trên câu hỏi thật. Chưa test thì hãy thừa nhận chưa biết vị trí tối ưu.

2. Context budget và cấu trúc một Context Pack

Một Context Pack là đầu vào cuối có cấu trúc: mục tiêu, câu hỏi, evidence kèm nguồn, xung đột, điều chưa biết và khuôn dạng đầu ra.

Hình 1 — Context budget phải chừa chỗ cho output và giữ source ID cho từng claim.

Ta dùng ví dụ giả 100U:

INSTRUCTION 12U + QUERY 5U + EVIDENCE 58U + CITATIONS 10U + OUTPUT 15U = 100U

U là đơn vị giả để luyện phân bổ, không phải token, tiền hay độ trễ. Giảm 20U không chứng minh hệ thống rẻ hoặc nhanh hơn; phải đo trong môi trường thật.

Một pack tối thiểu có thể theo mẫu:

GOAL: giúp người dùng xử lý lỗi an toàn
QUERY: ERR_CONN_RESET khi login SSO
EVIDENCE:
  - [C1, policy-v2026, checked_at]
  - [C3, error-guide-v4, checked_at]
CONFLICTS:
  - C5 là policy 2025, chỉ giữ ghi chú khác biệt
UNKNOWNS:
  - chưa biết lỗi xảy ra ở mọi mạng hay một mạng
OUTPUT SCHEMA:
  - nguyên nhân có bằng chứng
  - bước kiểm tra theo thứ tự
  - điều chưa xác minh
  - source IDs

Source ID là mã nối claim với tài liệu gốc, kèm version và thời điểm kiểm tra khi cần. Không có source ID thì không dùng cho claim chính. Tóm tắt do model tạo vẫn phải trỏ về nguồn gốc.

CONFLICTS giữ điểm không đồng thuận; UNKNOWNS ghi điều chưa đủ bằng chứng.

3. Pipeline chọn, nén và sắp 8 candidate chunks

Candidate chunk là đoạn có thể được chọn vào Context Pack. Ta xử lý theo chuỗi:

CANDIDATES → PERMISSION/FRESHNESS → DEDUP → SELECT → COMPRESS → ORDER → PACK + SOURCE IDS → MODEL → EVAL

Bước 1: lọc quyền và phạm vi

C6 là hướng dẫn tenant B. Dù rất gần câu hỏi, nó phải Block trước khi chấm relevance. Quyền và phạm vi là cổng cứng, không thể được “bù” bằng độ giống cao.

Bước 2: xem nguồn và độ mới

Authority là độ đáng tin của nguồn; freshness là độ hiện hành. C1 là policy 2026 chính thức nên được ưu tiên. C4 là suy đoán diễn đàn, không đủ làm claim chính. C5 là policy 2025, được rút thành conflict note 6U.

Bước 3: bỏ trùng và chọn giá trị

Deduplication là loại bằng chứng trùng. C2 là bản copy của C1 nên Drop, giống bỏ bớt bản photocopy của cùng một quy định để dành chỗ cho thông tin mới.

Hình 2 — Chọn theo quyền, nguồn, độ mới và giá trị; không chọn chỉ vì passage gần query.

Ledger cuối:

Bước 4: nén có kiểm mất nghĩa

Compression là rút gọn có kiểm mất nghĩa. C5 phải giữ năm hiệu lực, điểm khác policy mới và source ID; C8 chỉ giữ term cần dùng. Không xóa số, phủ định, ngoại lệ, cảnh báo hay điều kiện chỉ để pack ngắn.

LLMLingua nghiên cứu điều khiển budget và nén nhiều mức. LongLLMLingua xét câu hỏi và sắp lại nội dung. Đây là hướng nghiên cứu, không phải bảo đảm production hay vật thay thế loss check.

Bước 5: sắp thứ tự và giữ nguồn

Đặt instruction, query và evidence quyết định gần nhau; nhóm theo claim. Gắn provenance — source ID, version và thời điểm — để truy ngược khi có lỗi.

4. Sai lầm, giới hạn và rủi ro mất bằng chứng

Sai lầm đầu tiên là cắt càng nhiều càng tốt. Pack 40U mất exception quan trọng có thể tệ hơn pack 70U đầy đủ. Tiết kiệm không thay cho chất lượng.

Sai lầm tiếp theo là nén trước khi lọc quyền: bản tóm tắt C6 vẫn sai tenant. Gộp C1 và C5 thành “policy chung” sẽ xóa xung đột. Bỏ source ID khiến claim không thể truy ngược.

Hình 3 — Phải test vị trí và bản nén trên task thật; không giả định model dùng mọi chỗ như nhau.

Một loss check đối chiếu bản gốc và bản nén theo sáu mục: số liệu, phủ định, ngoại lệ, điều kiện, cảnh báo và nguồn. Một mục đổi nghĩa thì dừng. Nội dung y tế, pháp lý, bảo mật hay tài chính cần người chịu trách nhiệm duyệt.

Kỹ thuật này có giới hạn. Retrieval lấy sai thì tối ưu chỉ sắp sai lầm gọn hơn. Task cần toàn văn để phân tích hoặc so hợp đồng có thể không hợp compression. Model hay task đổi thì position test cũ có thể hết giá trị.

Hãy test cùng evidence ở đầu, giữa, cuối và so bản đầy đủ với bản nén; chấm đúng claim, đúng nguồn và biết từ chối. Chưa đủ mẫu thì ghi “chưa đủ dữ liệu”.

5. Checklist triển khai có thể kiểm chứng

1. Chốt task và quality floor. Ví dụ: trả đúng bước an toàn, không dùng dữ liệu sai tenant, mọi claim chính có source ID.
2. Đo baseline. Chạy bộ câu hỏi với pipeline hiện tại; lưu accuracy, citation correctness, refusal và latency.
3. Lập budget. Chừa output reserve trước, rồi mới chia cho instruction, query, evidence và citations.
4. Lọc cổng cứng. Quyền, tenant, nguồn bị cấm và tài liệu hết hiệu lực phải xử lý trước scoring.
5. Bỏ trùng và nhóm xung đột. Không hòa tan hai phiên bản thành một câu mơ hồ.
6. Chọn theo giá trị. Xem relevance, authority, freshness, uniqueness và chi phí cùng lúc.
7. Nén có loss check. Giữ số, phủ định, ngoại lệ, cảnh báo và provenance.
8. Sắp pack và test vị trí. So đầu–giữa–cuối trên chính model và task đang dùng.
9. Đánh giá trước/sau. Không phát hành nếu quality floor giảm dù context ngắn hơn.
10. Chuẩn bị rollback. Giữ cấu hình baseline để quay lại khi dữ liệu hoặc model đổi.

Ablation là phép thử bỏ từng lớp để đo đóng góp. Chẳng hạn, chạy lần lượt không dedup, không compression và không reordering. Nếu bỏ reordering mà kết quả không đổi, đừng duy trì một lớp phức tạp không tạo giá trị.

Hãy đứng ngoài khi chưa xác định được quyền dữ liệu, chưa có tập đánh giá hoặc nhiệm vụ cần nguyên văn. Dừng và xem lại khi citation trỏ sai, câu trả lời bỏ sót exception, tỷ lệ từ chối an toàn giảm, hay bản nén tạo claim không có trong nguồn. Với production, rollback không phải thất bại; đó là phanh.

6. Bài tập 15 phút: đóng gói 8 chunks vào budget 100U

Bắt đầu từ đâu: mở một spreadsheet miễn phí. Không cần API, không cần model trả phí và không dùng tiền thật. Tạo các cột ID, scope, authority, freshness, action, U, source ID, loss check.

• 3 phút: gắn relevance, authority, freshness và tenant cho C1–C8.
• 4 phút: chọn Keep, Condense, Drop hoặc Block.
• 3 phút: cộng evidence budget.
• 3 phút: đặt nguồn hiện hành trước, conflict note ngay sau claim liên quan.
• 2 phút: kiểm output reserve và source IDs.

Mẫu đối chiếu đã điền

Evidence là 18 + 20 + 6 + 10 + 4 = 58U. Full pack là 12 + 5 + 58 + 10 + 15 = 100U. Nhắc lại: U chỉ là đơn vị giả cho bài tập, không phải token, giá tiền hay latency.

Kết quả mong đợi: pack đủ source IDs, có C5 trong conflict note, chặn C6 và chừa 15U cho output. Muốn giữ C4, bạn phải chỉ ra claim nào cần nó và vì sao nguồn diễn đàn đủ thẩm quyền.

7. Tổng kết và bài học tiếp theo

a. Năm ý chính

• Context tốt là context có giá trị cho task, không phải context dài nhất.
• Chừa output reserve trước khi phân bổ evidence.
• Quyền và tenant là cổng cứng; relevance cao không được phép vượt qua.
• Compression phải giữ nghĩa và provenance, đồng thời qua loss check.
• Đánh giá quality, citation và refusal trước khi tin vào số U đã giảm.

b. Câu hỏi tự kiểm tra

• Vì sao C6 phải Block trước khi scoring?
• Bản nén cần giữ sáu nhóm thông tin nào?
• Vì sao giảm context chưa chứng minh hệ thống tốt hơn?
• Ablation giúp trả lời câu hỏi gì?

c. Gợi ý đáp án

Xem gợi ý câu 1

C6 thuộc sai tenant, nên quyền và phạm vi phải chặn trước relevance. Xem mục 3.

Xem gợi ý câu 2

Giữ số, phủ định, ngoại lệ, điều kiện, cảnh báo và nguồn. Xem mục 4.

Xem gợi ý câu 3

Context ngắn hơn vẫn có thể mất claim hoặc citation; phải đo quality floor. Xem mục 5.

Xem gợi ý câu 4

Ablation bỏ từng lớp để đo lớp nào thật sự đóng góp. Xem mục 5.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• Lost in the Middle — TACL 2024
• LLMLingua — arXiv
• LongLLMLingua — ACL 2024

Bài trước, Hybrid RAG #11, đã tạo nguồn candidate bằng tìm kiếm từ khóa và vector. Bài này biến candidates thành pack có kiểm soát. Bài sau, Agent Planning #13, sẽ dùng context đã đóng gói để lập và kiểm tra chuỗi hành động.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.