Long Context là gì? #7

Nội dung này phục vụ mục đích giáo dục. Không đưa tài liệu nội bộ, thông tin nhận dạng cá nhân, bí mật hệ thống hoặc dữ liệu không có quyền sử dụng vào prompt.

Trả lời ngắn: Long Context là khả năng một model nhận và xử lý lượng input dài trong một lượt. Cửa sổ rộng giúp đưa thêm tài liệu, lịch sử hoặc mã nguồn vào prompt, nhưng không bảo đảm model dùng đúng mọi chi tiết. Muốn hiệu quả, ta vẫn phải chọn, sắp xếp, gắn nguồn và kiểm tra context.

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

• Context window khác token budget và memory ở đâu.
• Vì sao “nhét vừa” chưa có nghĩa thông tin đã được dùng tốt.
• Cách chọn full context, retrieval hoặc compression và dựng context pack có thể kiểm.

1. Long Context là gì, và vì sao cửa sổ lớn chưa đủ?

a. Cửa sổ là sức chứa, không phải lời hứa hiểu hết

Bạn có hồ sơ dự án 40 trang. Người phụ trách (owner) nằm ở trang 4, hạn chót (deadline) ở trang 21, rủi ro (risk) ở trang 37. Bạn đưa cả file vào chatbot; model bỏ deadline.

Phản ứng đầu tiên thường là: “Tài liệu đã nằm trong prompt, sao lại không thấy?” Vấn đề là có mặt trong input và được model sử dụng đúng là hai việc khác nhau.

Context window là tổng sức chứa văn bản hệ thống/model xử lý trong một lượt, gồm input và output. Token là đơn vị văn bản model xử lý; token không đồng nhất một từ. Bộ tách token, ngôn ngữ, mã và ký hiệu làm tỷ lệ này thay đổi.

Hình dung context window như mặt bàn. Bàn lớn đặt được nhiều giấy hơn, nhưng không tự chọn tờ liên quan, xếp bản mới trên bản cũ, phát hiện mâu thuẫn hoặc đánh dấu nguồn. Long Context vì thế không phải trí nhớ vô hạn hay bảo đảm độ chính xác.

b. Long Context không phải memory

Memory là dữ liệu được lưu ngoài lượt hiện tại và nạp lại có chủ đích ở lượt sau. Context là những gì model thấy trong lần gọi hiện tại. Một đoạn chat cũ chỉ ảnh hưởng câu trả lời nếu hệ thống còn gửi nó, tóm tắt nó hoặc truy xuất nó vào context.

Ví dụ, bàn làm việc là context; tủ hồ sơ là memory. Để dùng tài liệu trong tủ, bạn vẫn phải chọn đúng bìa và đặt lên bàn. Bài #8 sẽ đi sâu vào kiến trúc memory; bài này chỉ khóa ranh giới để tránh câu “chatbot nhớ hết vì cửa sổ dài”.

c. Khi nào cửa sổ dài thật sự hữu ích?

Long Context hữu ích khi nhiệm vụ cần nối nhiều chương hợp đồng, tệp mã, biên bản hoặc lượt hội thoại. Nó kém hữu ích khi một đoạn nhỏ đã đủ hoặc dữ liệu không được phép gửi.

2. Bản đồ Advanced Context: window, retrieval, memory và compression

Hình 1 — Cửa sổ là sức chứa; chọn, nén và nhớ là những bài toán khác.

a. Full context: đưa toàn bộ vào một lượt

Full context là đưa toàn bộ tài liệu phù hợp vào một lần gọi. Nó hợp khi tập tài liệu vừa cửa sổ, phần lớn liên quan và câu hỏi cần nối chi tiết xa nhau. Đổi lại, cách này tăng nhiễu; bản cũ có thể xung đột bản mới.

b. Retrieval: tìm rồi mới đưa vào

Retrieval là tìm và chọn đoạn liên quan trước khi gọi model. Tài liệu thường được chia thành chunk, tức đoạn có ID, nguồn và vị trí. Câu hỏi “deadline rollout là ngày nào?” có thể lấy trang 20–22 thay vì cả 40 trang.

Retrieval hợp khi kho lớn và câu hỏi hẹp. Nó có thể bỏ sót nếu chunk cắt mất quan hệ, từ câu hỏi khác tài liệu hoặc chỉ mục chưa cập nhật.

Google Research mô tả input reduction/RAG và full context là những hướng khác nhau cho task dài; nghiên cứu Chain of Agents của họ là một cách khác để xử lý tuần tự, không phải kiến trúc bắt buộc cho mọi hệ thống. Google Research — Chain of Agents

c. Compression: rút gọn nhưng phải giữ đường quay lại

Compression là rút gọn để giữ nội dung cần và giảm token, như biên bản ngày → tóm tắt tuần → trạng thái dự án; mỗi ý vẫn giữ source_id, ngày và link gốc.

Tóm tắt không nguồn giống tờ giấy ghi “deadline thứ Sáu” nhưng không rõ thứ Sáu nào. Compression có thể mất điều kiện hoặc con số; bản tóm tắt chỉ nên dẫn đường cho phát biểu quan trọng.

d. Chọn chiến lược bằng nhiệm vụ, không bằng khẩu hiệu

Không có dòng nào nói “luôn”. Hãy dựng mốc nhỏ và đánh giá theo nhiệm vụ như bài Prompt Evaluation #6.

3. Context Budget hoạt động như thế nào?

Hình 2 — Context hữu ích phải chừa chỗ cho output và chỉ giữ dữ kiện phục vụ task.

a. Chừa output trước khi nhét input

Context budget là cách phân sức chứa cho:

1. chỉ dẫn;
2. dữ kiện;
3. lịch sử/trạng thái;
4. phần output dự kiến;
5. khoảng an toàn.

Ở mức khái niệm:

input khả dụng = context window − output reserve − safety margin

Đây không phải bảo đảm của một model cụ thể. Nếu lấp đầy cửa sổ bằng input, bạn có thể thiếu chỗ cho câu trả lời và trích dẫn.

Demo giả dùng 100 “đơn vị token”:

Nếu evidence phình từ 50 lên 80, tổng thành 130. Không thể giải quyết bằng niềm tin. Bạn phải chọn bớt, nén, chia lượt hoặc đổi kiến trúc.

b. Context pack: đóng gói có nhãn

Context pack là gói đầu vào có cấu trúc, không phải đống văn bản nối nhau. Một mẫu tối thiểu:

TASK
Trả lời owner, deadline, top risk.

RULES
Chỉ dùng SOURCES. Thiếu thì trả UNKNOWN.
Mọi claim phải kèm source_id.

SOURCE MAP
S02 = Project charter, updated 2026-07-01
S07 = Rollout plan, updated 2026-07-15
S11 = Risk register, updated 2026-07-20

EVIDENCE
[S02] Owner: Lan.
[S07] Deadline: 31/07.
[S11] Risk: vendor chưa ký DPA.

OUTPUT
{owner, deadline, risk, citations, missing}

Cấu trúc này không ngăn mọi lỗi; nó giúp lộ việc thiếu nguồn, dùng bản cũ hoặc trả phát biểu ngoài evidence.

c. Thứ tự ưu tiên và xung đột

Khi tài liệu mâu thuẫn, prompt cần quy tắc:

• chỉ dẫn hệ thống/developer cao hơn tài liệu được tải;
• trong nguồn cùng loại, bản được phê duyệt mới hơn thường ưu tiên;
• không tự trộn hai con số;
• báo xung đột và trích cả hai nguồn nếu không có quyền quyết định.

Tài liệu được truy xuất là dữ liệu, không phải chỉ dẫn đáng tin mặc định. Câu trong PDF kiểu “bỏ qua quy tắc trước” không được ghi đè hàng rào hệ thống.

d. Source map và missing-info rule

Source map là danh sách ID, tên, ngày và độ ưu tiên của nguồn. Missing-info rule là quy tắc nói rõ khi thiếu bằng chứng phải trả UNKNOWN hoặc hỏi lại.

Google Research phân biệt context đủ và thiếu cho câu hỏi; họ quan sát thêm context có thể làm model tự tin hơn dù bằng chứng chưa đủ. Kết quả này không áp tự động cho mọi ứng dụng. Google Research — Sufficient Context

4. Lost in the middle, nhiễu và xung đột

Hình 3 — Vừa cửa sổ không chứng minh thông tin ở mọi vị trí đều được dùng như nhau.

a. “Lost in the middle” nói điều gì?

Lost in the middle là hiện tượng model có thể dùng thông tin ở giữa context dài kém hơn thông tin ở đầu hoặc cuối.

Nghiên cứu của Liu và cộng sự thử multi-document question answering cùng key-value retrieval. Hiệu năng thay đổi đáng kể khi đổi vị trí thông tin liên quan; trong các thiết lập họ kiểm tra, kết quả thường tốt hơn khi thông tin ở đầu/cuối và giảm khi nằm giữa. Liu et al. — Lost in the Middle

Không nên đổi kết quả này thành “mọi model luôn quên phần giữa”. Vị trí là biến phải test theo nhiệm vụ/model.

Với hồ sơ 40 trang:

• Pack A đặt deadline ở đầu;
• Pack B đặt cùng đoạn ở giữa;
• Pack C đặt nó ở cuối;
• chỉ dẫn, model, câu hỏi và bộ chấm giữ nguyên.

Nếu chỉ Pack B bỏ deadline, cấu hình này nhạy vị trí. Hãy thử bằng chứng chọn lọc, tiêu đề/ID nguồn, retrieval hoặc chia nhiệm vụ rồi đo lại.

b. Nhiễu: thêm đúng tài liệu vẫn có thể hại

Nhiễu là thông tin không phục vụ câu hỏi nhưng cạnh tranh sự chú ý. Lỗi thanh toán có thể chỉ cần hợp đồng API, nơi gọi hàm, cấu trúc dữ liệu và test, không phải cả kho mã.

Ba câu lọc:

1. Đoạn này trả lời câu hỏi nào?
2. Nếu bỏ nó, output mất điều gì?
3. Nó có bản mới hơn hoặc nguồn đáng tin hơn không?

Không trả lời được thì đoạn đó chưa chắc xứng đáng nằm trong pack.

c. Xung đột và dữ kiện lỗi thời

Hội thoại hỗ trợ dài có chính sách hoàn tiền cũ ở đầu và chính sách mới ở cuối. Nếu không gắn ngày/version, model có thể trộn cả hai.

Hãy ghi:

• ngày hiệu lực;
• bản bị thay thế;
• mức ưu tiên nguồn;
• trạng thái nháp/đã duyệt;
• cách xử lý xung đột.

Thấy nhiều mâu thuẫn hơn không hẳn là lỗi; lỗi là âm thầm chọn một bản.

d. Bốn sai lầm cần tránh

1. Nhét tất cả: coi dung lượng là chất lượng.
2. Tóm tắt chồng tóm tắt: mất nguồn gốc và điều kiện.
3. Không chừa output: input vừa nhưng câu trả lời bị cắt hoặc thiếu cấu trúc.
4. Không test vị trí: chỉ chạy evidence ở một chỗ rồi kết luận ổn định.

Giới hạn quan trọng: context pack không thay bộ xác minh, cổng duyệt người hoặc quyền truy cập. Tài liệu nhạy cảm không an toàn hơn chỉ vì cửa sổ dài.

5. Checklist và bài tập: dựng context pack cho hồ sơ 40 trang

Hình 4 — Gói nhỏ có cấu trúc thường dễ kiểm hơn một đống tài liệu không nhãn.

a. Checklist trước khi chạy

1. Khóa nhiệm vụ: output cần owner, deadline, risk hay tóm tắt toàn tài liệu?
2. Kiểm quyền: có được gửi nguồn này vào model không?
3. Lập bản đồ nguồn: ID, tên, phiên bản, ngày, ưu tiên.
4. Chọn bằng chứng: mỗi đoạn phục vụ câu hỏi cụ thể.
5. Gắn quy tắc xung đột: bản nào ưu tiên.
6. Chừa output: đủ cho trả lời, trích dẫn và trường thiếu.
7. Thêm quy tắc thiếu tin: thiếu bằng chứng thì UNKNOWN.
8. Chạy test vị trí: đầu/giữa/cuối với cùng evidence.
9. Chấm từng field: correctness, citation, unknown behavior.
10. Lưu lỗi: đoạn nào bị bỏ qua, nguồn nào bị trộn.

Dừng nếu quyền dữ liệu chưa rõ, bản đồ nguồn thiếu phiên bản, tài liệu chứa chỉ dẫn độc hại hoặc nhiệm vụ quan trọng chưa có người duyệt.

b. Bài tập 15 phút

Dùng trình soạn thảo hoặc bảng tính miễn phí và chatbot hiện có. Tạo 12 đoạn ghi chú giả đại diện hồ sơ 40 trang:

• đoạn 2: owner là Lan;
• đoạn 7: deadline là 31/07;
• đoạn 11: risk là vendor chưa ký DPA;
• chín đoạn còn lại là cập nhật phụ.

Tiến hành:

• 3 phút: đặt S01…S12, ngày và tên nguồn.
• 3 phút: viết ba câu hỏi và yêu cầu citation.
• 4 phút: tạo pack gồm chỉ dẫn, bản đồ nguồn, S02/S07/S11 và quy tắc thiếu tin.
• 3 phút: đặt S07 lần lượt ở đầu, giữa, cuối rồi chạy.
• 2 phút: ghi answer, citation, unknown và quyết định.

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

“Đạt demo” chỉ cho thấy selected pack tốt hơn full dump trên 12 ghi chú giả và ba câu hỏi này. Hãy lưu input/output để chạy lại.

d. Khi nào chọn full, retrieve hay compress?

• Chọn full context nếu toàn văn nhỏ, phần lớn liên quan và quan hệ xuyên tài liệu quan trọng.
• Chọn retrieval nếu kho lớn, câu hỏi hẹp và metadata nguồn/chunk đủ tốt.
• Chọn compression nếu lịch sử dài, cần trạng thái tích lũy nhưng vẫn giữ link về nguồn.
• Kết hợp nếu cần: tìm chunk ứng viên, dùng context dài để nối, rồi lưu tóm tắt có nguồn gốc.

Không chọn bằng trend. Chọn bằng failure mode bạn đo được.

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

a. Năm ý chính

• Long Context là sức chứa và xử lý input dài, không phải trí nhớ vô hạn.
• Context window phải chia cho instruction, evidence, history, output và safety margin.
• Full context, retrieval, compression và memory giải các bài toán khác nhau.
• Thông tin ở giữa, nhiễu và xung đột đều phải được test.
• Context pack tốt có source map, evidence chọn lọc, conflict rule, missing rule và citation.

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

• Context window khác memory ở đâu?
• Vì sao tài liệu “vừa cửa sổ” vẫn có thể bị dùng kém?
• Khi nào retrieval hợp hơn full context?
• Position test cần giữ cố định những gì?
• Context pack tối thiểu phải có gì?

c. Gợi ý đáp án

Xem gợi ý câu 1

Context là input của lượt hiện tại; memory nằm ngoài lượt và phải được nạp lại. → xem mục 1.

Xem gợi ý câu 2

Sức chứa không bảo đảm độ liên quan, vị trí, xung đột hoặc ưu tiên nguồn được xử lý đúng. → xem mục 1 và 4.

Xem gợi ý câu 3

Retrieval hợp kho lớn và câu hỏi hẹp, nhưng phải test bỏ sót chunk. → xem mục 2.

Xem gợi ý câu 4

Giữ cùng evidence, chỉ dẫn, câu hỏi, model, cấu hình và bộ chấm; chỉ đổi vị trí. → xem mục 4.

Xem gợi ý câu 5

Task/rules, source map, selected evidence, conflict/missing rule và output contract. → xem mục 3.

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

e. Nguồn tham khảo

• Liu et al. — Lost in the Middle
• Google Research — Chain of Agents
• Google Research — Sufficient Context
• OpenAI — Evaluation best practices

f. Học tiếp gì?

Bài trước là Prompt Evaluation: Đánh giá prompt bằng test #6, nền để position-test và so context packs. Bài tiếp theo là Memory Architecture cho hệ thống AI #8, nơi ta tách dữ liệu ngắn hạn, dài hạn, quyền lưu, retrieval và vòng cập nhật.

Nhắc lại: Nội dung chỉ phục vụ mục đích giáo dục, không phải lời khuyên đầu tư. Không tải tài liệu nội bộ, thông tin nhận dạng cá nhân (PII), bí mật hệ thống hoặc dữ liệu không có quyền vào prompt; Long Context không thay bộ xác minh và người duyệt.