Đừng chạy theo model mới: Hãy xây hệ thống AI vẫn sống khỏe sau mỗi lần nâng cấp

TL;DR

Model mới luôn đáng để thử, nhưng không nên là tài sản duy nhất bạn xây dựng. Trong bài đưa ra một luận điểm rất thực tế: model là phần có thể thay, còn phần tạo ra lợi thế tích lũy là hệ thống quanh nó - ngữ cảnh, quy trình, skill, bộ nhớ, kết nối dữ liệu và quyền hạn.

Góc nhìn này đáng chú ý vì nó chuyển câu hỏi từ "model nào mạnh nhất tuần này?" sang "nếu đổi model vào ngày mai, phần nào trong cách làm việc của đội ngũ vẫn giữ nguyên?". Một hệ thống tốt phải cho phép thay engine mà không phải xây lại cả chiếc xe.

Model nên là module thay thế được; skill, memory, policy và dữ liệu kết nối mới là lớp tạo giá trị dài hạn.

Vấn đề không phải là model yếu hay mạnh

Thói quen phổ biến khi có model mới là chuyển toàn bộ sự chú ý sang benchmark, context window hay giá token. Những yếu tố đó có ý nghĩa, nhưng chúng chỉ là một phần của năng lực vận hành. Nếu kiến thức nằm trong các chat riêng lẻ, prompt quan trọng nằm rải rác trong lịch sử, và quyền truy cập tool được nối tạm cho từng thử nghiệm, mỗi lần đổi model có thể kéo theo một đợt làm lại.

Phần bền vững này là system. Dùng Hermes làm ví dụ, ý tưởng không phụ thuộc vào một sản phẩm cụ thể: hãy tách profile model khỏi các tài sản của tổ chức. Model có thể đổi theo loại việc - model mạnh cho lập kế hoạch khó, model gọn hơn cho tác vụ thường ngày - trong khi context, skill, permission và memory vẫn nằm ở lớp bên dưới.

Đây cũng là điểm giao với khuyến nghị của Anthropic. Họ phân biệt workflow, nơi luồng công việc được định nghĩa trước bằng mã, với agent, nơi model tự điều phối tool và bước thực hiện. Cả hai không đối nghịch; lựa chọn đúng phụ thuộc vào độ rõ ràng của nhiệm vụ. Với việc lặp lại và có đầu ra xác định, workflow đơn giản thường dễ đo, dễ debug và ít tốn kém hơn một agent lớn. via Anthropic.

Thang 8 mức: từ chat đến company brain

Framework không nên được hiểu như benchmark hay lộ trình bắt buộc. Nó hữu ích hơn khi được dùng làm câu hỏi chẩn đoán: đội ngũ đang dừng ở đâu, và bước kế tiếp có thực sự tạo thêm đòn bẩy không?

1. Hỏi đáp: dùng AI để tra cứu, giải thích, phác thảo ý tưởng.

2. Tác vụ một lần: giao một việc có đầu vào và đầu ra rõ ràng, nhưng chưa tái sử dụng được.

3. Artifact: biến câu trả lời thành checklist, diagram, HTML, one-pager hoặc tài liệu mà người khác có thể mở và dùng lại.

4. Skill: đóng gói một quy trình lặp lại thành hướng dẫn, input, output, tiêu chí hoàn thành và eval.

5. Cron: để những việc đáng theo dõi chạy theo lịch, có tín hiệu thay đổi và đề xuất hành động.

6. Làm việc nhiều người: đưa agent vào nơi đội ngũ đang làm việc, kết nối dữ liệu theo đúng phạm vi.

7. Governance: xác định agent được đọc gì, được soạn nháp gì và hành động nào phải có người duyệt.

8. Company brain: duy trì decision log, task, lesson và memory để lần chạy sau không bắt đầu lại từ số không.

Điểm quan trọng là không cần nhảy cóc lên mức 8. Một đội content còn chưa có checklist review ổn định thì thêm agent đa tác nhân chỉ làm tăng độ phức tạp. Hãy chọn đúng một bậc cao hơn hiện tại: nếu đang có prompt tốt, đóng gói nó thành skill; nếu đã có skill, thêm eval; nếu đã có eval, mới tính đến cron hay kết nối dữ liệu.

Một câu trả lời trở nên hữu ích hơn khi được chuyển thành artifact có thể chia sẻ, xem lại và tái sử dụng. (Ảnh trong bài viết gốc của Eric Siu)

Artifact và skill mới là nơi giá trị bắt đầu tích lũy

Một câu trả lời riêng tư có thể giải quyết vấn đề trước mắt, nhưng nó không tự động nâng năng lực của cả đội. Artifact thay đổi điều đó. Một checklist launch, sơ đồ pipeline, template brief hay báo cáo phân tích là thứ một người khác có thể kiểm tra, phản biện, sửa và dùng tiếp.

Skill đi thêm một bước. Thay vì lưu một prompt dài ở đâu đó, hãy mô tả quy trình như một đơn vị có chủ đích: khi nào dùng, cần input nào, các bước ra sao, output trông như thế nào, và tiêu chí nào quyết định "đạt". Đây là khác biệt giữa "tôi biết cách làm" và "đội ngũ có thể làm lặp lại với chất lượng kiểm soát được".

Ví dụ, một skill viết brief SEO không nên chỉ là "hãy viết brief hay". Nó nên nhận mục tiêu kinh doanh, đối tượng đọc, danh sách chủ đề, nguồn dữ liệu và ràng buộc thương hiệu; sau đó trả ra outline, search intent, điểm cần kiểm chứng và checklist duyệt. Nếu có thể, hãy giữ một bộ mẫu tốt và bộ mẫu lỗi để eval mỗi lần đổi model hoặc sửa skill.

Việc này phù hợp với pattern workflow mà Anthropic mô tả: tách nhiệm vụ thành các bước nhỏ, thêm gate ở giữa, và chỉ dùng routing hay orchestration khi chúng giải quyết một khó khăn rõ ràng. Độ phức tạp là chi phí vận hành, không phải huy chương kiến trúc.

Khi agent nằm trong không gian làm việc chung, kết quả có thể trở thành điểm xuất phát cho cuộc thảo luận tiếp theo - miễn là quyền truy cập được giới hạn đúng cách. (Ảnh trong bài viết gốc của Eric Siu)

Tự động hóa phải có hàng rào

Phần dễ bị bỏ qua nhất trong câu chuyện "company brain" là governance. Kết nối agent với CRM, analytics, kho tài liệu hay kênh chat có thể biến nó thành một trợ lý rất hữu ích. Nhưng cùng lúc đó, nó mở rộng bề mặt rủi ro: dữ liệu nhạy cảm có thể bị đọc sai phạm vi, tool có thể bị lạm dụng, và một hành động gửi ra ngoài có thể gây hậu quả thật.

NIST AI RMF đặt Govern là chức năng xuyên suốt cùng với Map, Measure và Manage, thay vì để governance thành một checklist ở cuối dự án. NIST cũng lưu ý hệ thống GenAI có thể cần thêm human review, tracking, documentation và oversight tùy theo rủi ro. via NIST AI RMF Core.

Với agent, cách thực dụng là chia quyền theo mức tác động:

• Đọc: cấp quyền tối thiểu, giới hạn nguồn dữ liệu và log truy cập.

• Soạn nháp: cho phép agent chủ động tạo email, nội dung hay đề xuất, nhưng giữ bản nháp trong hàng chờ duyệt.

• Hành động bên ngoài: gửi email, publish, sửa CRM, thanh toán hoặc thay đổi production phải có policy rõ ràng và human approval khi rủi ro còn cao.

OWASP liệt kê các rủi ro như chiếm quyền hành vi agent, lạm dụng tool và lạm dụng danh tính hoặc privilege. Điều đó nhắc chúng ta rằng prompt "đừng làm điều xấu" không phải là cơ chế phân quyền. Quyền phải được thực thi ở connector, API gateway, scope token và workflow approval. via OWASP.

Một kế hoạch 30 ngày để bắt đầu

Tuần 1: chọn một việc lặp lại, tốn thời gian nhưng ít rủi ro. Viết rõ input, output, người chịu trách nhiệm và thế nào là kết quả tốt. Đừng bắt đầu bằng việc cho agent quyền gửi hoặc xóa dữ liệu.

Tuần 2: biến quy trình đó thành skill. Lưu artifact đầu ra, tạo checklist review và thu thập vài ví dụ tốt hoặc xấu. Đây là dữ liệu cần có để so sánh model và phát hiện regression.

Tuần 3: tách model profile khỏi skill. Chạy cùng một task với một lựa chọn model khác, sau đó so sánh chất lượng, chi phí, độ trễ và mức độ cần sửa tay. Không đổi toàn bộ hệ thống chỉ vì một demo đẹp.

Tuần 4: thêm memory hoặc cron ở phạm vi hẹp. Memory cần có nguồn, thời điểm cập nhật và owner; cron cần cho biết điều gì đã thay đổi, vì sao đáng chú ý, và hành động đề xuất là gì. Xóa cron không còn giá trị như một phần của vận hành bình thường.

Kết luận: xây lớp tích lũy, không chỉ thử engine mới

Eric Siu đưa ra lời nhắc hữu ích trong giai đoạn model đổi quá nhanh: người thắng lâu dài không nhất thiết là người thử model mới sớm nhất. Họ là người đã có hệ thống tốt để cắm model mới vào, đo nó, kiểm soát nó và giữ lại những gì đã học.

Vì vậy, thay vì hỏi "nên chuyển sang model nào?", hãy thử hỏi: skill nào của đội đang đáng đóng gói nhất, artifact nào đang bị chôn trong chat, memory nào cần được chuẩn hóa, và hành động nào vẫn cần con người ký duyệt? Trả lời được những câu đó mới là lúc AI bắt đầu trở thành năng lực của tổ chức, không chỉ là một tab chat mới.