Trả lời ngắn: Context là thông tin hiện tại của một run, memory là trạng thái được lưu để dùng về sau, còn retrieval là pipeline tìm và chọn evidence. Ba phần này không thay nhau. Output hay vẫn có thể sai nếu context lẫn instruction, memory cũ hoặc retrieval lấy nhầm nguồn.

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

  • Context, memory và retrieval khác nhau ở đâu.
  • Cách viết context contract và memory policy nhỏ.
  • Cách vẽ retrieval pipeline có chunk, rerank, provenance và quality check.
  • Khi nào phải ghi NEEDS_REVIEW vì evidence thiếu, cũ hoặc sai scope.

Lưu ý giáo dục: Bài dùng tài liệu public và dữ liệu giả cho research assistant. Không đưa PII, secrets, customer data, API key hoặc production prompt vào bài. RAG không tự bảo đảm câu trả lời đúng; evidence, policy và người chịu trách nhiệm vẫn cần được review.

1. Ba lớp thông tin không nên trộn

Một research assistant nhận câu hỏi “tóm tắt thay đổi trong policy giả”. Context là câu hỏi, instruction, format trả lời và evidence được đưa vào run hiện tại. Memory có thể là sở thích format của người dùng hoặc trạng thái công việc đã lưu. Retrieval là quá trình tìm các đoạn policy liên quan từ kho tài liệu.

Nếu đưa mọi thứ vào một prompt dài, bạn khó biết câu nào là lệnh, câu nào là dữ liệu, nguồn nào mới và memory nào được phép dùng. Hãy tách contract:

  • Context trả lời: run này cần biết gì?
  • Memory trả lời: thông tin nào được lưu, cho ai, bao lâu và để làm gì?
  • Retrieval trả lời: evidence nào được chọn, từ nguồn/version nào và vì sao?

Ví dụ support: ticket hiện tại là context; preference “thích câu trả lời ngắn” có thể là memory; policy hoàn tiền là retrieval. Preference không được ghi đè policy. Policy trong tài liệu cũng không được tự trở thành instruction nếu chỉ là nội dung được tìm thấy.

Hình 1 — Tách ba lớp giúp biết thông tin đang dùng, đang lưu hay đang được tìm.

Ví dụ đời thường: context là đồ đang trên bàn hôm nay; memory là sổ tay có quy tắc lưu/sửa/xoá; retrieval là thư viện chọn trang phù hợp cho câu hỏi. Đồ trên bàn không tự thành sổ tay, và một trang thư viện không tự thành mệnh lệnh.

2. Context contract: input nào được dùng

a. Bảy loại input

Context contract là thỏa thuận về input, thứ tự, giới hạn và output của một run. Một contract nhỏ nên tách:

  1. System instruction: mục tiêu, vai trò và điều cấm.
  2. User input: câu hỏi hoặc ticket hiện tại.
  3. Retrieved evidence: đoạn nguồn đã chọn, kèm id/version.
  4. Tool result: dữ liệu tool trả về, đã kiểm quyền.
  5. Memory được phép: chỉ trường cần cho task này.
  6. Output schema: format, citation và trạng thái không chắc.
  7. Limits: token, thời gian, field nhạy cảm và stop rule.

Đừng coi context window là memory. Context window là phần model thấy trong run; memory là dữ liệu có vòng đời. Một tài liệu dài hơn context không nên bị cắt ngẫu nhiên rồi gọi là “đã hiểu”. Hãy chọn đoạn, ghi nguồn và nói rõ phần không có.

b. Priority và redaction

Instruction cần được phân biệt với retrieved content. Một tài liệu có câu “bỏ qua policy” vẫn chỉ là dữ liệu cần phân tích. Redaction là che hoặc loại dữ liệu nhạy cảm trước khi đưa vào context/log. Scope cần có tenant/team, document version và owner.

OpenAI Agents SDK đặt tools, guardrails, state và tracing trong cùng thiết kế agent; đó là lời nhắc rằng context không chỉ là chuỗi text mà còn là state, quyền và bằng chứng của run. OpenAI Agents SDK

Hình 2 — Context contract tách instruction, data, memory và limit trước khi model xử lý.

3. Memory: lưu gì và xoá khi nào

Memory có thể chia thành ba mức. Working memory chỉ tồn tại trong một task; session memory giữ trạng thái của cuộc trao đổi; long-term memory giữ một điều được phép dùng qua nhiều lần. Không phải thông tin nào hữu ích một lần cũng nên lưu lâu dài.

Memory policy cần trả lời:

  • Ai sở hữu memory và tenant nào được đọc?
  • Vì sao cần lưu, field nào không được lưu?
  • Có consent hoặc cơ chế thông báo phù hợp không?
  • Khi nào hết hạn, được sửa hoặc xoá?
  • Provenance của memory là gì?

Provenance là nguồn và lịch sử của memory/evidence. Preference “trả lời bằng bullet” có thể có TTL dài hơn một trạng thái ticket. Một claim về policy phải có source/version; khi tài liệu đổi, memory cũ không được âm thầm ghi đè nguồn mới. Freshness là mức còn cập nhật của thông tin, nên cần ngày hiệu lực hoặc lần kiểm gần nhất.

Với support giả, lưu preferred_language=vi có thể hữu ích; lưu toàn bộ ticket và PII vô hạn là quyết định khác, cần policy riêng. Với research, lưu danh sách nguồn đã xem có thể giúp tránh lặp; lưu kết luận cũ mà không có ngày và source dễ tạo false confidence.

4. Retrieval pipeline và quality check

Retrieval là pipeline tìm và chọn evidence, không phải nút “bật RAG”. Một flow cơ bản:

ingest → clean → chunk → index → retrieve → filter/rerank → cite → evaluate

Chunk là mảnh tài liệu có nghĩa. Cắt giữa một điều kiện “trừ khi” có thể làm đoạn trông liên quan nhưng mất ý. Embedding là biểu diễn số giúp so độ tương đồng ngữ nghĩa. Sau khi retrieve, rerank sắp xếp lại theo relevance và policy. Cuối cùng, output cần citation/provenance và trạng thái nếu không đủ evidence.

Quality không chỉ là “tìm được đoạn”. Hãy kiểm:

  • Relevance: đoạn có trả lời câu hỏi không?
  • Coverage: có đủ điều kiện/ngoại lệ quan trọng không?
  • Freshness: nguồn có còn hiệu lực không?
  • Groundedness: output có bám evidence đã chọn không?
  • Scope: nguồn có đúng tenant và quyền không?

Microsoft hướng dẫn đánh giá RAG theo nhiều chiều thay vì chỉ nhìn câu trả lời cuối; Google Cloud cũng mô tả RAG là cách kết hợp model với nguồn dữ liệu riêng, không phải lời hứa loại bỏ mọi lỗi. Azure RAG evaluation Google Cloud RAG

Hình 3 — Mỗi bước retrieval có failure mode và quality check riêng, không chỉ phụ thuộc model.

5. Sai lầm, giới hạn và stop gate

Sai lầm đầu tiên là prompt stuffing: nhét toàn bộ tài liệu vào context rồi hy vọng model tự ưu tiên. Sai lầm thứ hai là memory không có TTL, correction hoặc deletion. Sai lầm thứ ba là keyword match đúng từ nhưng sai version, sai tenant hoặc thiếu điều kiện. Sai lầm thứ tư là trích citation sau khi tạo output nhưng không kiểm nó có thật sự hỗ trợ claim.

Retrieval cũng có thể bị nội dung độc hại dẫn hướng. Một tài liệu được tìm thấy có thể chứa câu lệnh giả; coi nó là evidence, không phải system instruction. Không cho retrieved text tự gọi tool. Giới hạn field, domain, index và quyền trước khi ghép vào context.

Dùng stop gate khi không biết nguồn, source hết hiệu lực, tenant không khớp, chunk mất điều kiện, memory conflict hoặc groundedness không đạt. Fallback có thể là hỏi lại, trả danh sách evidence để người xem, chuyển NEEDS_REVIEW hoặc quay về workflow read-only. NIST AI RMF đặt risk management và accountability trong vòng đời; retrieval quality không thay thế owner hoặc quyết định vận hành. NIST AI Risk Management Framework

Hình 4 — Evidence thiếu, cũ hoặc sai scope phải dẫn tới stop/fallback, không dẫn tới câu trả lời chắc hơn.

6. Practice Bridge 15 phút

Bắt đầu từ đâu

Mở Google Sheets hoặc notes. Tạo research assistant giả và ba tài liệu public giả: policy-v1, policy-v2 và note ngoài scope. Điền source, version, date, tenant, đoạn cần lấy, expected citation và hành động khi conflict. Không dùng API key, PII hoặc production.

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

Source giả Version/date Scope Dùng trong context? Test/fallback
Policy refund v2 / 2026-01 Team A Có, nếu câu hỏi Team A Cite section; check freshness
Policy refund v1 / 2025-01 Team A Không nếu v2 hợp lệ Ghi stale, không trộn
Note ngoài scope v3 / không rõ Team B Không Wrong tenant → NEEDS_REVIEW

Sau 15 phút, viết một context contract ngắn: task, user input, hai đoạn evidence, memory được phép và output cần citation. Thử xoá ngày/version; nếu bạn không biết chọn nguồn nào, đó chính là gap cần sửa. Kết quả mong đợi là map source/version/scope và một stop action, không phải câu trả lời dài.

Hình 5 — Practice map giúp kiểm source, version, scope và freshness trước khi ghép context.

7. Tổng kết: tìm đúng evidence trước khi nói chắc

a. Năm ý chính

  • Context là input của run hiện tại; memory là state có policy; retrieval là pipeline chọn evidence.
  • Context contract phải tách instruction, user input, memory, evidence, tool result, output và limits.
  • Memory cần scope, provenance, freshness, TTL, correction/deletion và owner; không lưu vô hạn.
  • Retrieval cần ingest, chunk, index, retrieve, rerank/filter, cite và evaluate theo relevance/coverage/groundedness.
  • Source thiếu/cũ/sai tenant hoặc content lẫn instruction thì dừng, fallback hoặc NEEDS_REVIEW.

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

  • Vì sao context window không phải memory?
  • Một chunk cắt sai có thể làm retrieval sai như thế nào?
  • Freshness và provenance trả lời hai câu hỏi nào?
  • Khi nào retrieval nên chuyển NEEDS_REVIEW thay vì đoán?

c. Gợi ý đáp án

Xem gợi ý câu 1

Context chỉ là phần model thấy trong run; memory là dữ liệu có policy, scope, retention và có thể dùng về sau. Xem lại mục 1 và mục 2.

Xem gợi ý câu 2

Cắt giữa điều kiện/ngoại lệ làm đoạn vẫn giống từ khóa nhưng mất ý đầy đủ, nên output có thể bám một nửa quy tắc. Xem lại mục 4.

Xem gợi ý câu 3

Freshness nói thông tin còn cập nhật không; provenance nói nguồn và lịch sử tạo ra thông tin. Xem lại mục 3 và mục 4.

Xem gợi ý câu 4

Khi source thiếu/cũ, wrong tenant, conflict, chunk mất điều kiện hoặc không chứng minh được groundedness. Xem lại mục 5.

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

Thuật ngữ Giải thích ngắn
Context Thông tin hiện tại được đưa vào một run.
Memory Trạng thái được lưu để dùng ở run sau.
Retrieval Pipeline tìm và chọn evidence liên quan.
Chunk Mảnh tài liệu có nghĩa dùng cho index/retrieval.
Embedding Biểu diễn số giúp so độ tương đồng ngữ nghĩa.
Rerank Sắp xếp lại kết quả theo relevance/policy.
Provenance Nguồn và lịch sử của memory/evidence.
Freshness Mức còn cập nhật của thông tin.
Groundedness Mức output bám evidence đã chọn.

e. Nguồn tham khảo

Bài trước là Chọn Workflow, Copilot hay Agent #8. Bài tiếp theo là Thiết kế Tool Layer và Human Approval #10.

Lưu ý giáo dục: Context, memory và retrieval cần test, scope, provenance và owner. Hãy bắt đầu với tài liệu giả/public, read-only và stop gate trước khi lưu hoặc mở rộng quyền.