4 đặc tính cốt lõi mà các Architect dùng làm căn cứ thiết kế

4 đặc tính và hệ quả thiết kế tương ứng

Với mỗi đặc tính dưới đây, chính những đặc điểm giúp Claude hoạt động tốt trong tình huống này lại có thể là nguyên nhân khiến nó thất bại trong tình huống khác. Hãy tiếp cận từng hàng như một năng lực (capability) đi kèm với giới hạn (limitation) tương ứng, cùng phương án giảm thiểu rủi ro (mitigation) mà một Architect sẽ áp dụng.

4 đặc tính cốt lõi bao gồm:

Next-token prediction Dự đoán token tiếp theo

• Năng lực (Capability): Thực hiện các tác vụ dựa trên những patterns phổ biến: tóm tắt, định dạng lại (reformatting), và giải thích các khái niệm đã định hình rõ ràng.

• Giới hạn (Limitation): Bất kỳ tác vụ nào yêu cầu độ chính xác tuyệt đối về mặt chi tiết. Claude có thể tạo ra văn bản trông có vẻ chính xác nhưng thực chất lại không phải. Rủi ro này tập trung ở tên riêng, ngày tháng, trích dẫn (citations) và số liệu thống kê.

• Phương án giảm thiểu (Mitigation): Sử dụng citations, cơ chế báo hiệu độ không chắc chắn (uncertainty signaling), và các vòng lặp generator-verifier. Định tuyến các truy vấn thực tế cụ thể qua tool calls hoặc nguồn dữ liệu chuẩn xác thay vì chỉ dựa vào đầu ra của model.

Knowledge Tri thức (Dữ liệu đã học/huấn luyện)

• Năng lực (Capability): Xử lý tốt các chủ đề trong training data của model mang tính phổ biến, gần đây và xuất hiện nhất quán – nơi model có thể trả lời một cách đáng tin cậy hoàn toàn dựa trên những gì nó đã được học.

• Giới hạn (Limitation): Các chủ đề hiếm, thuộc thị trường ngách (niche), còn gây tranh cãi hoặc thường xuyên thay đổi. Model có thể đưa ra thông tin đã cũ (stale) hoặc thiếu sót với cùng một tông giọng tự tin như khi trình bày các sự thật cơ bản.

• Phương án giảm thiểu (Mitigation): Sử dụng web search, retrieval (RAG), tool use, hoặc các MCP server để biến một hệ thống bên ngoài thành source of truth (nguồn thông tin chuẩn xác) thay vì bản thân model. Thay vì phụ thuộc vào parametric knowledge (tri thức tham số) của model, câu trả lời mang tính thẩm quyền sẽ đến từ nguồn dữ liệu được truy xuất. Khi độ tươi mới của thông tin (freshness) hoặc tính chính xác chính thống được ưu tiên, hãy chủ động nạp lại dữ liệu đó vào hệ thống thay vì dựa vào những gì sẵn có trong training data của model.

Working memory Bộ nhớ làm việc (Phạm vi xử lý ngữ cảnh)

• Năng lực (Capability): Bất kỳ nội dung nào nằm vừa trong active context window (cửa sổ ngữ cảnh đang hoạt động).

• Giới hạn (Limitation): Context window là một ranh giới cứng (hard edge): một khi nội dung rơi ra ngoài cửa sổ này, model hoàn toàn không thể truy cập vào nó nữa. Có 2 lỗi khác nhau xảy ra tại ranh giới này nhưng rất dễ bị nhầm lẫn:

  1. Oversized request: Là một prompt hoặc cuộc trò chuyện vốn đã quá lớn để có thể gửi đi. Khi một oversized request được gửi, nó sẽ bị từ chối ngay trước khi tiến hành generation (sinh văn bản). Nếu request vượt quá giới hạn token của model, API sẽ trả về lỗi 400 invalid_request_error kèm thông báo prompt quá dài. Nếu phần raw request body vượt quá giới hạn byte của API, API sẽ trả về lỗi 413 request_too_large báo hiệu yêu cầu vượt quá dung lượng byte tối đa cho phép.

  2. Lỗi còn lại xảy ra khi prompt đầu vào thì vừa vặn, nhưng quá trình generation sau đó lại đụng trần context window và phải dừng sớm; trên các model hiện tại, response trả về sẽ có lý do dừng (stop reason) là model_context_window_exceeded kèm đầu ra bị cắt dở (truncated output). Để tránh chạm giới hạn này, bạn có thể kiểm tra trường usage trên mỗi response và dùng token-counting API trước khi gửi request.

• Phương án giảm thiểu (Mitigation): Sử dụng các kỹ thuật progressive context loading (nạp ngữ cảnh tiệm tiến), chunking (chia nhỏ dữ liệu) và front-loading (đưa các thông tin quan trọng lên đầu). Với các công việc kéo dài, tính năng Projects có thể giúp quản lý những gì cần giữ lại trong phạm vi (scope). Hãy tập thói quen tóm tắt qua từng lượt thoại (summarizing across turns) khi context bắt đầu dài ra.

Steerability Khả năng điều hướng (Tính tuân thủ chỉ dẫn)

• Năng lực (Capability): Tiếp nhận và thực thi tốt các chỉ dẫn (instructions) ngắn gọn, cụ thể và có thể kiểm chứng – đi kèm định dạng rõ ràng, giới hạn độ dài minh bạch và phân vai (roles) cụ thể.

• Giới hạn (Limitation): Các chỉ dẫn trừu tượng hoặc mơ hồ, các chuỗi suy luận dài (long reasoning chains), và các tác vụ yêu cầu tính toán logic hoặc con số chính xác tuyệt đối. Dối với các bài toán tính toán có rủi ro cao (high-stakes), tính toán định tính (deterministic computation) hoặc việc thực thi tool nên chịu trách nhiệm đưa ra đáp án. Model có thể tuân thủ chính xác từng mặt chữ của chỉ dẫn nhưng lại đi lệch khỏi mục đích thực sự (intent).

• Phương án giảm thiểu (Mitigation): Sử dụng system prompts, structured outputs, và code execution cho bất kỳ tác vụ nào đòi hỏi độ chính xác về logic. Khi mục đích (intent) và chỉ dẫn trên mặt chữ có nguy cơ lệch nhau, hãy phát biểu lại mục tiêu một cách rõ ràng ngay bên cạnh chỉ dẫn đó.

Từ đặc tính đến hệ quả thiết kế

Chúng ta sẽ quay lại từng đặc tính này ở các phần sau của khóa học. Hãy liên kết từng đặc tính với hệ quả thiết kế (design consequence) của nó ngay từ bây giờ:

1. Non-determinism: Cùng một đầu vào có thể tạo ra các đầu ra khác nhau giữa các lần chạy. Đây là lý do các evaluation frameworks tồn tại: bạn không thể chứng nhận một hành vi mà bạn mới chỉ quan sát thấy đúng một lần. (Nền tảng cho phần evaluation trong Module 2.)

2. Context là tài nguyên hữu hạn: Context window là một giới hạn cứng với ngân sách token cố định. Những gì bạn đưa vào, thứ tự ra sao, và những gì bạn bỏ ra đều là các quyết định thiết kế ảnh hưởng đến cả khả năng xử lý của model lẫn chi phí vận hành. (Nền tảng cho chiến lược model và context ở phần sau của module này.)

3. Sự tự tin không đồng nghĩa với tính đúng đắn (Confidence is not validity): Claude có thể đưa ra câu trả lời sai với cùng một tông giọng trôi chảy, tự tin như khi đưa ra câu trả lời đúng. Đó là lý do việc bố trí human-in-the-loop và cơ chế xác minh (verification) là những lựa chọn mang tính kiến trúc chứ không phải ý tưởng thêm vào sau. (Nền tảng cho phần triển khai có trách nhiệm trong Module 3.)

4. Ranh giới tri thức và năng lực (Knowledge and capability boundaries): Model hoạt động đáng tin cậy với các chủ đề phổ biến, gần đây và nhất quán trong dữ liệu huấn luyện, nhưng không đáng tin cậy với các chủ đề hiếm, nội bộ hoặc thay đổi nhanh. Đối với các chủ đề không đáng tin cậy, web search, retrieval (RAG), tools, và MCP có thể được dùng để biến một hệ thống bên ngoài thành source of truth (nguồn thông tin chuẩn xác) thay vì bản thân model. (Nền tảng cho reference architectures và RAG ở phần sau của module này.)

Kịch bản thực tế: Thất bại bắt đầu từ việc hiểu sai đặc tính

Một Architect thấy bản demo chạy mượt mà 5 lần liên tiếp và kết luận rằng hành vi của hệ thống là định tính (deterministic). Dựa trên đó, team đã triển khai một pipeline đối soát tài chính mà xử lý mỗi đầu ra của model như một kết quả cố định, có thể lặp lại và không xây dựng bất kỳ cơ chế kiểm tra nào xung quanh.

Đến tuần thứ hai trên môi trường production, các đầu ra bắt đầu bị lệch (drifted): cùng một sao kê, khi xử lý lại, lại cho ra kết quả phân loại khác. Sự sai lệch này chỉ vô tình được phát hiện khi một chuyên viên phân tích chạy lại một batch dữ liệu. Không có gì thay đổi ở đầu vào, nhưng các đầu ra khác nhau lại được tạo ra vì model là một hệ thống non-deterministic, trong khi kiến trúc lại được xây dựng như thể nó là deterministic.

Bài học ở đây không phải là model không đáng tin cậy, mà là: demo không phải là bằng chứng của tính deterministic, và 4 đặc tính này luôn tồn tại dù kiến trúc của bạn có thừa nhận chúng hay không.

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

• Chi phí (Cost): Thiết kế mà bỏ qua các đặc tính này là sai lầm đắt giá nhất của một Architect, vì chi phí sẽ trả giá sau khi launch – thời điểm mà việc sửa chữa (rework) tốn kém nhất và việc khôi phục niềm tin là khó nhất.

• Độ phức tạp (Complexity): Gọi tên chính xác 4 đặc tính ngay từ đầu giúp các cuộc thảo luận thiết kế sau này trở nên chuẩn xác. Bạn có thể khẳng định "đây là bài toán thuộc về knowledge-boundary" thay vì tranh cãi xem model đã "đủ tốt" hay chưa.

• Rủi ro (Risk): Các đặc tính này không tự cảnh báo lỗi. Một hệ thống không được thiết kế xoay quanh các đặc tính này sẽ không báo lỗi trực tiếp; nó sẽ lặng lẽ chệch hướng (drift) và khoảng trống đó dẫn đến các kết quả bất định – vốn chỉ bị phát hiện trong một kỳ audit hoặc từ sự tức giận của người dùng, chứ không phải do bản thân hệ thống tự nhận biết.