Trình bày quyết định kiến trúc và các đánh đổi

Một quyết định kiến trúc đúng vẫn có thể bị bác chỉ vì trình bày sai cách: giám đốc tài chính phải ngồi nghe hết sơ đồ thành phần mới biết dự án tốn bao nhiêu, còn người phụ trách bảo mật không thấy rủi ro nào đã được chặn.

Bài này giúp bạn trả lời: trình bày một quyết định kiến trúc và các đánh đổi (trade-offs) của nó thế nào để mỗi người nghe quyết được phần của mình?

Ví dụ xuyên suốt: công ty xây dựng đọc hồ sơ mời thầu

Một công ty xây dựng nhận khoảng 60 bộ hồ sơ mời thầu mỗi tháng, mỗi bộ 300–800 trang. Kỹ sư dự toán mất trung bình hai ngày để đọc một bộ, và đã có lần bỏ sót một điều khoản phạt chậm tiến độ. Nhóm của bạn xây một trợ lý đọc hồ sơ: trích yêu cầu kỹ thuật, hạn nộp, điều khoản phạt, rồi đối chiếu với hồ sơ năng lực của công ty.

Nhóm đã thử ba phương án:

Nhóm chọn B. Tuần sau phải trình bày quyết định này trước ban điều hành: tổng giám đốc (người tài trợ dự án), giám đốc tài chính, trưởng pháp chế, trưởng phòng an toàn thông tin, và hai trưởng nhóm kỹ thuật sẽ xây hệ thống.

Quyết định trước, phần của từng người sau

Người nghe hỗn hợp không cần cùng một độ sâu. Cách sắp quen thuộc, cũng là cách câu luyện thi chấm đúng:

1. Mở bằng quyết định: chọn gì, phục vụ kết quả kinh doanh nào, chấp nhận đánh đổi gì.
2. Sau đó đi vào mối quan tâm chính của từng người, mỗi người một phần riêng để tìm đúng chỗ của mình mà không phải đọc hết phần còn lại.

Trong ví dụ, đoạn mở đầu có thể là: "Chúng tôi đề xuất workflow cố định ba bước. Thời gian đọc một bộ hồ sơ giảm từ hai ngày xuống dưới một giờ, kỹ sư chỉ còn kiểm và ký. Đánh đổi chúng tôi chấp nhận: chi phí mỗi lần chạy cao hơn phương án rẻ nhất một chút, và đội kỹ thuật phải viết thêm phần tách chương."

Sau đoạn mở đầu là các phần riêng:

Nói về chi phí: tính trên mỗi việc xong

Giám đốc tài chính thường hỏi "model nào rẻ nhất". Docs của Anthropic về tối ưu chi phí trả lời: so model bằng chi phí trên mỗi việc hoàn thành, không bằng giá mỗi token. Bài blog của Anthropic về chọn model nói thêm rằng model hạng cao có thể rẻ hơn tính trên mỗi việc dù giá token cao hơn, vì nó thường cần ít lượt và ít thời gian suy nghĩ hơn.

Trong ví dụ, phương án A rẻ nhất mỗi lần chạy nhưng bỏ sót điều khoản phạt ở 6 trên 40 bộ hồ sơ thử. Với tỉ lệ đó, kỹ sư vẫn phải đọc lại chương điều khoản của mọi bộ hồ sơ cho chắc, nên phần thời gian tiết kiệm được gần như mất hết. Tính cả công đọc lại, A đắt hơn B.

Docs cũng chia các cách giảm chi phí thành hai nhóm. Người nghe nên biết bạn đã làm hết nhóm đầu trước khi đụng tới nhóm sau:

• Tiết kiệm không mất chất lượng: prompt caching cho phần lặp lại ở mọi lần gọi (chỉ dẫn và hồ sơ năng lực công ty), Batch API giảm 50% giá cho việc không cần kết quả ngay (hồ sơ nhận buổi chiều, sáng hôm sau kỹ sư mới đọc).
• Đánh đổi: hạ model, hạ effort, giới hạn độ dài đầu ra. Những thứ này có thể làm giảm chất lượng, nên phải đo lại.

Docs còn khuyên so model trên khoảng 10% việc khó nhất, vì hoá đơn thường do những việc model rẻ làm hỏng quyết định. Trong ví dụ, đó là các bộ hồ sơ dài nhất, nhiều phụ lục nhất.

Mỗi lớp phức tạp phải có giá

Bài "Building effective agents" của Anthropic nói hệ agent thường đổi độ trễ và chi phí lấy chất lượng, nên chỉ thêm độ phức tạp khi nó cải thiện kết quả rõ ràng, và bắt đầu từ cách đơn giản nhất. Bài blog về hệ nhiều agent cho biết hệ nhiều agent thường tốn gấp 3–10 lần token so với một agent làm cùng việc, và lợi ích chính của chạy song song là làm kỹ hơn chứ không phải nhanh hơn.

Vì vậy, khi trình bày, mỗi lớp thêm vào (thêm agent, thêm bước kiểm, thêm model) phải trả lời được ba câu: thêm được gì, tốn thêm bao nhiêu, đo bằng gì. Trong ví dụ, phương án C bỏ sót ít ngang B nhưng tốn gấp bốn lần và chậm hơn, nên lớp điều phối không mua thêm được gì.

1. Lớp này không cải thiện chỉ số đã thống nhất?Bỏ
2. Phần cải thiện không đáng chi phí và độ trễ tăng thêm?Bỏ
3. Chưa đo trên bộ test của mình?Đo trước khi đưa vào bản trình bày
4. Còn lạiGiữ, và ghi rõ giá của lớp đó

Chứng minh bằng đánh giá trên dữ liệu của mình

Docs chọn model nói có một bộ đánh giá tốt là bước quan trọng nhất. Bài blog về chọn model nói thêm rằng các bộ benchmark công khai đã gần chạm trần với các model mạnh, chỉ nên xem như chỉ dẫn hướng; hãy thử trên khối việc thật với tiêu chí thành công của chính bạn.

Với người nghe, điều đó nghĩa là đừng nói "model này đứng đầu bảng xếp hạng". Hãy đưa các phương án đã cân nhắc (alternatives considered) và tiêu chí dùng để đánh giá chúng. Trong ví dụ, nhóm chạy cả ba phương án trên 40 bộ hồ sơ cũ mà kỹ sư đã đánh dấu đủ điều khoản phạt:

Số trong bảng là số đo của nhóm trong ví dụ, không phải số liệu chung về các model.

Bảng này phục vụ cả hai phía. Ban điều hành thấy vì sao chọn B. Đội kỹ thuật thấy A và C bị loại vì đâu, và hiểu cơ chế được chọn: B là workflow, tức đường đi viết sẵn trong code, vì các bước đọc hồ sơ đã biết trước, không cần để Claude tự quyết bước tiếp theo. Việc của họ khi triển khai cũng hiện ra từ đó: viết phần tách chương, chạy song song từng chương, đặt phần cố định ở đầu prompt để cache trúng.

Rủi ro còn lại: nói rõ và có giới hạn

Bài blog của Phó CISO Anthropic về agent (07/2026) viết rằng việc của người phụ trách bảo mật không phải đưa rủi ro về 0, mà là làm cho rủi ro của agent nhìn thấy được và có giới hạn. Bài gợi ý bốn câu hỏi cho mỗi trường hợp dùng:

Bài blog cũng nhấn mạnh hai điều: chỉ cấp năng lực hẹp nhất mà vẫn làm xong việc, và chấp nhận một rủi ro là việc của người có thẩm quyền chấp nhận nó, không phải của nhóm kỹ thuật.

Phần dành cho người duyệt bảo mật và tuân thủ vì vậy gồm: mô hình mối đe doạ (threat model), mỗi rủi ro được kiểm soát nào xử lý (control mappings), tiêu chí chấp nhận rủi ro còn lại (residual-risk acceptance criteria), và khả năng truy vết khi kiểm toán (audit traceability). Trong ví dụ, rủi ro còn lại là B vẫn bỏ sót 1/40 bộ khi thử. Tiêu chí chấp nhận: kỹ sư kiểm danh mục điều khoản phạt theo mẫu trước khi ký; giám đốc dự toán là người ký chấp nhận rủi ro; nếu trong vận hành có hơn một bộ bỏ sót mỗi tháng thì dừng lại xem xét.

Ghi người phụ trách và lúc xem lại

Quyết định đúng hôm nay có thể sai sau ba tháng: có model mới, model đang dùng sắp bị ngừng, khối lượng tăng gấp ba. Một bản ghi quyết định tốt có hai thứ hay bị bỏ quên:

• Các phương án đã cân nhắc kèm tiêu chí đánh giá, như bảng ở mục trên. Người đọc sau này cần biết vì sao A và C bị loại, không chỉ biết B được chọn.
• Người phụ trách và nhịp xem lại (ownership and review cadence): ai chịu trách nhiệm, bao lâu xem lại một lần, và chuyện gì buộc phải xem lại sớm.

Trong ví dụ: trưởng nhóm kỹ thuật phụ trách; xem lại mỗi quý; xem lại ngay khi Anthropic báo ngừng model đang dùng (docs nói Anthropic báo trước ít nhất 60 ngày), khi chi phí mỗi bộ vượt $4, hoặc khi có bộ hồ sơ bỏ sót điều khoản phạt trong vận hành. Cách ghi quyết định thành tài liệu chuẩn có ở bài 6.4.