Model, Context Window và Chiến lược Context (Context Strategy)

Các thuật ngữ riêng biệt rất dễ bị đánh đồng

Các thuật ngữ dưới đây thường bị dùng lẫn lộn trong thực tế, nhưng việc đánh đồng chúng sẽ dẫn đến những sai lầm nghiêm trọng trong thiết kế reference architecture:

• Context window (Cửa sổ ngữ cảnh): Không gian chú ý (active attention space) đang hoạt động của model. Bất kỳ thứ gì nằm bên trong context window đều sẵn sàng cho việc suy luận, và bất kỳ thứ gì nằm ngoài nó đều xem như không tồn tại đối với model. Context window sẽ tự động đặt lại (resets) giữa các lượt gọi, trừ khi ứng dụng của bạn chủ động quản lý tính liên tục.

• Retrieval (Truy xuất dữ liệu): Tri thức bên ngoài được lấy về tại thời điểm truy vấn (query time) từ một tập dữ liệu mà model không lưu trong bộ nhớ. Retrieval bổ trợ cho context window chứ không thay thế nó. Model chỉ nhìn thấy những gì mà bộ truy xuất đưa ra.

• Persistent application state (Trạng thái ứng dụng liên tục): Do hệ thống của bạn sở hữu và quản lý, không phải model (ví dụ: trạng thái đơn hàng, hồ sơ người dùng, số dư tài khoản). Model không có quyền truy cập mặc định và bắt buộc phải dùng một tool call để lấy dữ liệu này.

• Summaries and memory layers (Tầng tóm tắt và ghi nhớ): Tính liên tục giữa các lượt thoại (turns) hoặc các phiên làm việc do ứng dụng tự quản lý. Model không có trí nhớ tự nhiên (native memory) giữa các lần gọi; bất kỳ thông tin nào tồn tại xuyên suốt đều là do ứng dụng của bạn lưu trữ và truyền ngược trở lại vào prompt. Đây là một lựa chọn kiến trúc, không phải năng lực tự thân của model.

Lựa chọn Model: Khởi đầu với Sonnet, dịch chuyển có tính toán

Họ mô hình Claude bao gồm Opus, Sonnet, và Haiku, mỗi model được tối ưu hóa cho các điểm đánh đổi khác nhau giữa chi phí, độ trễ (latency) và năng lực xử lý:

• Opus: Model có năng lực mạnh mẽ nhất của Anthropic, phù hợp cho các bài toán suy luận phức tạp, lập trình nâng cao và tổng hợp nghiên cứu chuyên sâu khi Sonnet không đáp ứng được tiêu chuẩn chất lượng.

• Sonnet: Điểm khởi đầu mặc định cho hầu hết mọi tác vụ. Chỉ nâng cấp lên Opus khi bộ đánh giá (eval set) chứng minh rằng Sonnet không đạt chuẩn chất lượng. Chỉ hạ cấp xuống Haiku khi eval set xác nhận rằng sự đánh đổi về chất lượng vẫn nằm trong ngưỡng chấp nhận được đối với tác vụ cụ thể của bạn.

Quyết định đổi model phải luôn dựa trên đo lường thực tế, không dựa vào cảm tính.

Định cỡ Context-Window: Cú rơi bộ nhớ làm việc (The working-memory cliff)

Tất cả những gì model chú ý tới đều nằm trong context window. Bên trong cửa sổ, khả năng chú ý luôn sẵn sàng. Ra ngoài cửa sổ, model hoàn toàn không thể truy cập. Bộ nhớ làm việc (working memory) là đặc tính có ranh giới khắc nghiệt nhất trong 4 đặc tính: mọi thứ vận hành rất trơn tru cho đến khi chạm giới hạn, và sự sụp đổ diễn ra ngay lập tức.

Context window được đo bằng tokens. Dung lượng văn bản mà một token đại diện sẽ thay đổi tùy theo thế hệ model, bộ tách từ (tokenizer) và ngôn ngữ; do đó hãy coi tỷ lệ ký tự/token chỉ là ước lượng thô. Hãy đo lường thay vì phỏng đoán: mỗi API response đều báo cáo số lượng token thực tế trong trường usage, và con số đo được này là căn cứ để tính giới hạn context lẫn chi phí thanh toán. Tất cả những gì đi vào context window — từ system prompt, lịch sử hội thoại, tài liệu truy xuất, đầu ra của tool, cho đến phản hồi của model — đều được tính bằng token.

Hệ quả thực tế rất rõ ràng: Không bao giờ lập kế hoạch ngân sách chạm trần context window. Hãy dự trù cho cuộc trò chuyện thực tế dài nhất, cộng thêm context được truy xuất, system prompt, không gian nháp làm việc (working scratch), và biên độ dự phòng cho sự tăng trưởng dữ liệu. Context window là một mức trần (ceiling), không phải là một cái đích để nhắm tới. Thiết kế sát trần đồng nghĩa với việc bạn chắc chắn sẽ đụng trần trên môi trường production.

Chiến lược Context: Dải phổ giữa Progressive và Monolithic

Mọi hệ thống trên production đều phải đưa ra lựa chọn — dù vô tình hay hữu ý — về cách context tiếp cận model trong mỗi lần gọi. Lựa chọn này nằm trên một dải phổ giữa hai thái cực:

• Monolithic (Nguyên khối): Đưa mọi thứ vào prompt cùng một lúc (toàn bộ tài liệu, lịch sử hội thoại, tập dữ liệu truy xuất). Phù hợp cho các tác vụ có ranh giới rõ ràng với kích thước đầu vào dự đoán được. Tuy nhiên, đây là chiến lược dễ va vào "vực thẳm bộ nhớ làm việc" trên production nhất, vì ngữ cảnh tích lũy qua từng lượt và cửa sổ sẽ đầy lên trong im lặng trước khi ai đó nhận ra dữ liệu đã bị cắt gọt (truncated).

• Progressive (Tiệm tiến): Phân giai đoạn cho context: truy xuất đúng lúc cần (just-in-time), tóm tắt qua các lượt thoại, và chỉ nạp những gì bước tiếp theo thực sự cần. Đây là lựa chọn mặc định chuẩn xác cho hầu hết các bài toán thực tế.

Bên cạnh hai thái cực trên, có 4 chiến lược cụ thể thường xuyên được áp dụng:

Kết hợp các chiến lược trong thực tế

4 chiến lược trên được tách rời để phục vụ việc học, nhưng các hệ thống production hầu như luôn kết hợp chúng lại với nhau. Một hệ thống tốt sẽ xếp lớp các chiến lược một cách có chủ đích:

Ví dụ thực tế: Coding Agent chạy tác vụ dài hạn

• Bắt đầu phiên (Session start): Tải mô tả tác vụ và một vài file mà người dùng chỉ định đích danh.

  → Áp dụng Monolithic prefix: Ngữ cảnh nhỏ, ổn định, tải một lần, tối ưu hoàn hảo cho prompt caching.

• Trong quá trình làm việc (Active work): Mỗi lệnh gọi tool (đọc file, chạy test, sửa code) được nối tiếp vào context làm việc.

  • → Áp dụng Progressive recent state: Những cập nhật mới nhất chính là thứ bước tiếp theo cần.

• Khám phá thêm (Discovery): Agent nhận ra nó cần một file chưa được tải ban đầu; nó tìm kiếm trong codebase và lấy về các file khớp.

  • → Áp dụng Just-in-time retrieval: Toàn bộ codebase quá lớn để nạp sẵn, chỉ trích xuất phần liên quan theo yêu cầu.

• Context bị đầy (Context filling): Sau nhiều lượt thoại, các bước tìm kiếm ban đầu chiếm quá nhiều diện tích; kết luận rút ra thì quan trọng nhưng các log đầu ra chi tiết của tool thì không cần thiết nữa.

  • → Áp dụng Compaction: Tóm tắt lại "chúng ta đã thử những gì và học được gì", chỉ giữ lại thông tin và quyết định quan trọng để tiếp tục công việc.

Quy tắc kiến trúc cốt lõi: Khi thiết kế hệ thống context, hãy tự trả lời 4 câu hỏi độc lập:

1. Model cần gì ngay từ khi bắt đầu? → Quyết định phần Monolithic baseline.

2. Model cần gì từ các bước gần đây nhất? → Quyết định cửa sổ Progressive.

3. Model có thể cần tìm nạp dữ liệu gì theo yêu cầu? → Quyết định tầng Retrieval.

4. Tài liệu nào ở các bước trước có thể nén lại mà không làm mất chi tiết ảnh hưởng đến quyết định? → Quyết định chính sách Compaction.

Cơ chế điều khiển Extended Thinking

Extended thinking là năng lực suy luận sâu trên từng request: model xử lý bài toán trong một khối các thinking tokens riêng biệt trước khi tạo ra câu trả lời cuối cùng. Cách điều khiển cơ chế này đã thay đổi qua các thế hệ model:

• Trên các dòng thế hệ mới như Claude Opus 4.6+, Claude Sonnet 4.6+, và Claude Sonnet 5, chế độ adaptive thinking sử dụng tham số effort là cách điều khiển được khuyến nghị: bạn thiết lập mức độ nỗ lực suy luận cần áp dụng thay vì cấu hình một ngân sách token cứng.

• Chế độ cấp ngân sách thủ công cũ (budget_tokens) đã bị ngừng hỗ trợ (deprecated) trên thế hệ 4.6 và bị loại bỏ hoàn toàn trên Sonnet 5 (sẽ trả về mã lỗi 400).

• Thinking tokens được tính tiền như output tokens thông thường và việc sinh ra chúng sẽ làm tăng độ trễ của cuộc gọi API.

• Trên các model hỗ trợ, API có thể trả về một bản tóm tắt quá trình suy luận thay vì toàn bộ nội dung suy luận chi tiết, nhưng bạn vẫn được tính tiền dựa trên lượng thinking tokens thực tế đã tiêu thụ trong quá trình xử lý.

Quy tắc quyết định: Extended thinking thuần túy là sự đánh đổi giữa chi phí và độ trễ. Hãy chạy các bộ đánh giá (evals) khi chưa bật tính năng này trước: nếu độ chính xác vẫn không đạt yêu cầu sau khi đã tối ưu prompt, lúc đó mới cân nhắc bật nó lên. Quyết định bật phải đến từ một khoảng trống độ chính xác đo lường được, không phải vì giả định "bật lên thì cũng chẳng hại gì".

Sử dụng Eval làm Stage-Gate trước mọi quyết định đổi Model

Bất kỳ thay đổi nào đối với model đều làm thay đổi hành vi của toàn hệ thống. Việc hoán đổi giữa hai model (model swap) là một đợt phát hành mã nguồn (code deployment) thực sự và phải được đối xử nghiêm ngặt như vậy. Tối thiểu bạn cần 3 yếu tố:

1. Bộ test set chọn lọc: Tập hợp các prompts đi kèm đầu ra chuẩn đã được xác thực, bao quát được phân phối công việc thực tế của hệ thống.

2. Hàm chấm điểm (Grading function): Có thể dùng model để chấm điểm theo một tiêu chí định sẵn (rubric), hoặc chấm bằng code nếu quy tắc kiểm tra có thể lập trình được.

3. Ngưỡng chênh lệch định trước (Pre-set delta threshold): Đặt ra một tỷ lệ suy giảm chất lượng tối đa mà dưới mức đó bạn dứt khoát không đưa lên production. Ngưỡng này bắt buộc phải chốt trước khi chạy eval. Nếu đặt ngưỡng sau khi có kết quả, bạn không phải đang thiết lập tiêu chuẩn, mà chỉ đang hợp thức hóa kết quả sau khi làm xong.

Tình huống thực tế: Hạ cấp từ Sonnet xuống Haiku một cách bài bản

Một quy trình phân tích tài liệu đã chạy trên Sonnet suốt 6 tháng và làm cạn kiệt ngân sách. Team muốn chuyển sang dùng Haiku để tiết kiệm chi phí:

1. Chuẩn bị dữ liệu: Team tạo bộ eval set gồm 250 tài liệu đại diện với các trường trích xuất được chuyên viên kiểm tra bằng tay, phân tầng theo đúng tỷ lệ các loại tài liệu xuất hiện trên môi trường thực tế. Mẫu đủ lớn để điểm số trên từng loại tài liệu đều có ý nghĩa thống kê.

2. Thực thi đánh giá: Chạy cả hai model trên cùng một tập dữ liệu và chấm điểm bằng cùng một rubric.

3. Phân tích kết quả: Sonnet đạt điểm trung bình 0.94, Haiku đạt 0.86. Tuy nhiên, sự sụt giảm chất lượng tập trung chủ yếu ở 2 loại tài liệu khó (Haiku chỉ đạt 0.71 và 0.74), trong khi các loại tài liệu còn lại đều đạt mức chấp nhận được.

4. Áp dụng tiêu chí Rollback: Quy tắc rút lui đã được thống nhất từ trước: Nếu bất kỳ loại tài liệu nào rơi xuống dưới 0.85, việc chuyển đổi bị từ chối. 2 loại tài liệu đã vi phạm ranh giới này, do đó đề xuất chuyển đổi toàn bộ bị bác bỏ.

5. Nước đi cứu vãn (The salvage move): Dùng một bộ phân loại (classifier) sẵn có để route 2 loại tài liệu khó cho Sonnet xử lý, và chuyển toàn bộ các loại tài liệu còn lại cho Haiku. Chi phí giảm rõ rệt mà không làm phát sinh lỗi hồi quy (regression) trên các tài liệu phức tạp.

Bài học lớn nhất ở đây là tiêu chí rollback được thống nhất trước khi có số liệu, giúp team không phải tự thỏa hiệp với chính mình, đồng thời dữ liệu đánh giá chi tiết đã mở ra một phương án di chuyển từng phần (partial migration) mà một con số trung bình chung chung sẽ che giấu mất.

Chi phí · Độ phức tạp · Rủi ro

• Chi phí (Cost): Chiến lược ngữ cảnh nguyên khối (monolithic context) là "kẻ sát thủ" âm thầm bào mòn ngân sách. Một cuộc hội thoại bắt đầu với prompt 4.000 tokens có thể phình lên 80.000 tokens ở lượt thoại thứ 30. Chi phí trên mỗi lượt gọi tăng dần theo độ dài phiên làm việc mà không có tín hiệu cảnh báo nào cho đến khi nhìn thấy hóa đơn.

• Độ phức tạp (Complexity): Hoán đổi model nhìn bên ngoài chỉ như thay đổi một dòng cấu hình, nhưng nó viết lại toàn bộ hành vi của sản phẩm. Hãy đối xử với các đợt model swap như một đợt release phần mềm lớn.

• Rủi ro (Risk): Không có eval set đồng nghĩa với việc không có tín hiệu rút lui (rollback signal). Một lỗi thụt lùi chất lượng chỉ được phát hiện trên production thực chất là một lỗi đã hoàn toàn bị bỏ lọt trong khâu kiểm soát — bởi khi bạn nhìn thấy nó, người dùng đã phải gánh chịu hậu quả rồi.