AI Solutions Architect là gì? Vai trò thiết kế giải pháp AI

1. Phạm vi của AI Solutions Architect trong một dự án

1.1. Giải thích tên nghề và những đầu ra chính

AI Solutions Architect là vị trí phụ trách định hướng và thiết kế kiến trúc giải pháp công nghệ có thành phần trí tuệ nhân tạo. Tên nghề này có thể được viết dưới dạng AI Solution Architect hoặc gọi bằng tiếng Việt là kiến trúc sư giải pháp AI. Trọng tâm công việc là chuyển những yêu cầu nghiệp vụ thành phương án kỹ thuật có thể xây dựng, tích hợp, kiểm thử và vận hành.

Trong một dự án, doanh nghiệp có thể đặt ra yêu cầu như tự động phân loại yêu cầu hỗ trợ khách hàng, hỗ trợ tra cứu tài liệu nội bộ hoặc phát hiện bất thường trong dữ liệu. AI Solutions Architect cần xác định hệ thống phải xử lý những thông tin nào, cần kết nối với phần mềm nào, thành phần AI đảm nhận tác vụ gì và kết quả được kiểm soát ra sao.

Đầu ra quan trọng của vị trí này không chỉ là sơ đồ kiến trúc mà còn là những quyết định thiết kế có căn cứ. Tùy phạm vi dự án, các đầu ra có thể bao gồm:

- Tài liệu yêu cầu nghiệp vụ và kỹ thuật, thể hiện phạm vi xử lý cùng những điều kiện cần đáp ứng.

- Sơ đồ kiến trúc tổng thể, mô tả các thành phần phần mềm, dữ liệu, mô hình AI và phương thức kết nối.

- Phương án lựa chọn công nghệ, kèm lý do lựa chọn và những giải pháp thay thế đã cân nhắc.

- Thiết kế luồng dữ liệu, phân quyền truy cập và các điểm kiểm soát chất lượng, bảo mật.

- Tiêu chí kiểm thử, nghiệm thu, triển khai, giám sát và xử lý khi hệ thống hoạt động không đạt yêu cầu.

Chẳng hạn, với yêu cầu xây dựng công cụ hỗ trợ nhân viên tra cứu quy trình nội bộ, người thiết kế phải làm rõ tài liệu nào được phép truy cập, kết quả cần dẫn chiếu nguồn hay không, trường hợp nào phải chuyển cho nhân viên phụ trách và cách phát hiện câu trả lời không đáng tin cậy.

Không phải doanh nghiệp nào cũng giao toàn bộ những công việc trên cho cùng một người. Có tổ chức tách riêng nhiệm vụ thiết kế, phát triển phần mềm, bảo mật và vận hành. Vì vậy, ứng viên cần xem phạm vi chịu trách nhiệm thực tế thay vì suy luận từ tên chức danh.

1.2. Phân biệt với Solution Architect, AI Consultant và AI Engineer

AI Solutions Architect có nhiều điểm giao thoa với Solution Architect, AI Consultant và AI Engineer. Sự khác biệt chủ yếu thể hiện ở loại quyết định cần đưa ra, mức độ đi sâu vào kiến trúc hệ thống và kết quả công việc phải bàn giao.

Solution Architect có thể thiết kế hệ thống không sử dụng AI, trong khi AI Solutions Architect phải giải quyết thêm những vấn đề như lựa chọn mô hình, đánh giá sai lệch đầu ra, quản lý dữ liệu đầu vào và xử lý tính không ổn định của kết quả AI.

AI Consultant có thể tham gia đề xuất kiến trúc, còn AI Engineer có thể đảm nhiệm một phần thiết kế kỹ thuật. Tuy nhiên, vai trò kiến trúc AI thường đòi hỏi khả năng kết nối các quyết định thành một hệ thống thống nhất và bàn giao đủ thông tin để nhóm triển khai thực hiện.

Người đọc có thể tham khảo thêm chủ đề mô tả công việc solution architect - vị trí hấp dẫn thu nhập cao để đối chiếu trách nhiệm thiết kế giải pháp nói chung với những yêu cầu chuyên sâu dành cho hệ thống AI.

Cần phân biệt rõ rằng đây là nghề kiến trúc hệ thống công nghệ, không phải nghề thiết kế nhà ở hoặc công trình xây dựng bằng AI. Những kỹ năng thiết kế kiến trúc xây dựng không phải nội dung chuyên môn được đề cập trong phạm vi bài viết này.

2. Chuyển yêu cầu kinh doanh thành kiến trúc hệ thống AI

2.1. Làm rõ tác vụ, người dùng và tiêu chí thành công

Một trong những nhiệm vụ đầu tiên của AI Solutions Architect là làm rõ vấn đề mà doanh nghiệp thực sự cần giải quyết. Yêu cầu ban đầu thường được diễn đạt theo kết quả mong muốn, chẳng hạn giảm thao tác nhập liệu, rút ngắn quá trình tìm kiếm thông tin hoặc hỗ trợ nhân viên xử lý yêu cầu khách hàng.

Trước khi lựa chọn công nghệ, người thiết kế cần xác định:

- Ai là người trực tiếp sử dụng hệ thống và họ đang thực hiện công việc theo quy trình nào?

- Đầu vào của tác vụ gồm những gì và kết quả đầu ra cần có đặc điểm nào?

- Những thao tác nào có thể xử lý bằng quy tắc thông thường, những thao tác nào thực sự cần khả năng của AI?

- Sai sót nào có thể chấp nhận, sai sót nào buộc phải dừng xử lý hoặc yêu cầu con người kiểm tra?

- Hiệu quả sẽ được đánh giá bằng tiêu chí nào và lấy dữ liệu kiểm chứng từ đâu?

Ví dụ giả định, một doanh nghiệp muốn sử dụng AI để phân loại yêu cầu hỗ trợ khách hàng. Nếu nội dung yêu cầu đã có cấu trúc cố định và có thể nhận biết bằng các điều kiện rõ ràng, hệ thống quy tắc có thể là lựa chọn đơn giản hơn. Nếu nội dung đa dạng, chứa nhiều cách diễn đạt và khó phân loại bằng quy tắc, phương án sử dụng mô hình AI mới cần được xem xét.

Trong tình huống này, tiêu chí thành công có thể liên quan đến khả năng phân loại đúng trên tập dữ liệu kiểm thử, tốc độ trả kết quả, tỷ lệ trường hợp phải chuyển xử lý thủ công và mức độ ảnh hưởng khi phân loại sai. Các ngưỡng chấp nhận phải được thống nhất theo đặc điểm nghiệp vụ, không áp một mức chung cho mọi dự án.

Quyết định không sử dụng AI cũng có thể là một kết quả thiết kế hợp lý nếu công nghệ thông thường đáp ứng tốt yêu cầu với chi phí và rủi ro phù hợp hơn.

2.2. Phân tích dữ liệu, quyền truy cập và tích hợp

Khi đã xác định bài toán, kiến trúc sư cần đánh giá điều kiện dữ liệu và hệ thống hiện có. Đây là bước ảnh hưởng trực tiếp đến tính khả thi của phương án, bởi một mô hình phù hợp về chức năng vẫn có thể không sử dụng được nếu dữ liệu thiếu chất lượng, không được cấp quyền hoặc không đáp ứng yêu cầu bảo mật.

Những nội dung cần làm rõ gồm nguồn dữ liệu, định dạng, độ đầy đủ, mức độ cập nhật, quyền sở hữu và mục đích được phép sử dụng. Đồng thời, người thiết kế phải xác định hệ thống AI sẽ kết nối với cơ sở dữ liệu, phần mềm quản lý hay ứng dụng nội bộ bằng phương thức nào.

Ví dụ giả định, doanh nghiệp muốn xây dựng công cụ hỗ trợ tra cứu thông tin từ tài liệu nội bộ. Khi đó, AI Solutions Architect phải xem xét:

- Tài liệu được lưu trữ ở đâu và có được phép sử dụng cho chức năng tra cứu bằng AI hay không.

- Người dùng thuộc bộ phận nào và được quyền xem những nhóm tài liệu nào.

- Thông tin thay đổi có được cập nhật vào hệ thống tra cứu kịp thời hay không.

- Kết quả cần dẫn chiếu tài liệu nguồn, ghi nhận lịch sử truy cập hoặc chuyển sang quy trình kiểm tra thủ công trong trường hợp nào.

- Những hệ thống hiện hữu cần kết nối và trách nhiệm quản lý từng điểm tích hợp.

Kiến trúc phải thể hiện rõ ranh giới truy cập dữ liệu và trách nhiệm bảo vệ thông tin. Việc dữ liệu có thể truy xuất về mặt kỹ thuật không đồng nghĩa với việc mọi người dùng hoặc mọi thành phần AI đều được phép sử dụng dữ liệu đó.

Khi xây dựng hồ sơ hoặc minh họa kiến trúc, ứng viên nên sử dụng dữ liệu công khai được phép dùng, dữ liệu tự tạo hoặc dữ liệu mô phỏng. Không đưa thông tin khách hàng, tài liệu nội bộ hay cấu hình bảo mật thực tế chưa được phép công bố vào sơ đồ và portfolio.

2.3. Ghi lại quyết định và giả định cần kiểm chứng

Thiết kế kiến trúc không chỉ là việc xác định các thành phần hệ thống. Người phụ trách còn phải giải thích vì sao một phương án được lựa chọn và những điều kiện nào có thể khiến quyết định đó không còn phù hợp.

Một bản ghi quyết định kiến trúc có thể trình bày theo các nội dung:

Bối cảnh: Vấn đề cần giải quyết, yêu cầu nghiệp vụ và ràng buộc kỹ thuật.

Các phương án: Những giải pháp đã được cân nhắc, bao gồm cả phương án không sử dụng AI nếu phù hợp.

Quyết định: Phương án được đề xuất và lý do lựa chọn.

Đánh đổi: Những lợi ích, giới hạn và rủi ro phải chấp nhận.

Giả định: Điều kiện về dữ liệu, lưu lượng, hạ tầng hoặc khả năng tích hợp chưa được xác minh.

Điều kiện xem xét lại: Những kết quả thử nghiệm hoặc thay đổi yêu cầu có thể dẫn đến việc điều chỉnh kiến trúc.

Chẳng hạn, nhóm thiết kế đề xuất sử dụng dịch vụ AI được quản lý để giảm khối lượng tự xây dựng hạ tầng. Quyết định này cần đi kèm giả định về chính sách xử lý dữ liệu, khả năng kết nối, mức chi phí và độ trễ có thể chấp nhận. Nếu quá trình kiểm chứng cho thấy dịch vụ không đáp ứng ràng buộc dữ liệu, nhóm phải đánh giá lại phương án.

Cách ghi chép như vậy giúp các bên hiểu được logic thiết kế và hạn chế việc lựa chọn công nghệ chỉ theo sở thích cá nhân. Không có một kiến trúc duy nhất phù hợp với mọi hệ thống AI.

3. Lựa chọn dữ liệu, mô hình, tích hợp và phương án triển khai

3.1. So sánh phương án theo yêu cầu thay vì độ mới

Sau khi xác định bài toán và ràng buộc, AI Solutions Architect cần so sánh các phương án triển khai ở cấp độ hệ thống. Việc lựa chọn phải dựa trên khả năng đáp ứng yêu cầu, thay vì mặc định mô hình mới nhất hoặc có nhiều tính năng nhất sẽ mang lại kết quả tốt hơn.

Ở bước thiết kế, có thể cân nhắc những nhóm phương án sau:

- Không sử dụng AI: Áp dụng quy tắc nghiệp vụ, tìm kiếm thông thường hoặc xử lý dữ liệu theo thuật toán xác định khi đáp ứng được yêu cầu.

- Sử dụng mô hình AI phù hợp tác vụ: Đánh giá mô hình phân loại, dự đoán, nhận dạng hoặc mô hình ngôn ngữ theo đặc điểm đầu vào và đầu ra.

- Sử dụng dịch vụ được quản lý: Cân nhắc khả năng tích hợp, chính sách dữ liệu, chi phí sử dụng và mức độ phụ thuộc vào nhà cung cấp.

- Tự triển khai và vận hành mô hình: Xem xét yêu cầu hạ tầng, năng lực kỹ thuật, cập nhật mô hình, giám sát và trách nhiệm bảo trì.

Ví dụ, nếu hệ thống chỉ cần phân loại các trạng thái nghiệp vụ có quy tắc rõ ràng, việc sử dụng mô hình ngôn ngữ lớn có thể tạo thêm độ phức tạp không cần thiết. Ngược lại, nếu phải phân tích nhiều cách diễn đạt tự nhiên, AI có thể là phương án đáng thử nghiệm.

Đối với lựa chọn dịch vụ quản lý hay tự vận hành, cần so sánh tổng thể thay vì chỉ nhìn vào phí sử dụng mô hình. Phương án tự vận hành có thể phát sinh trách nhiệm quản trị hạ tầng, cập nhật và theo dõi hệ thống; phương án dịch vụ có thể phụ thuộc vào điều kiện sử dụng, khả năng tùy chỉnh và nhà cung cấp.

Vì vậy, kỹ sư giải pháp AI cần xác định trước tiêu chí đánh giá rồi mới thử nghiệm các lựa chọn có khả năng đáp ứng. Không thể kết luận một mô hình vượt trội chỉ dựa trên tên gọi, thông số quảng bá hoặc kết quả thử nghiệm thiếu bối cảnh.

3.2. Thiết kế luồng xử lý và điểm kiểm soát

Một kiến trúc AI cần làm rõ dữ liệu đi qua những thành phần nào, ai có quyền thực hiện thao tác và hệ thống phản ứng ra sao khi kết quả không đạt yêu cầu. Những điểm kiểm soát phải được bố trí theo mức độ rủi ro của tác vụ.

Với ví dụ giả định về công cụ tra cứu tài liệu nội bộ, luồng xử lý có thể được mô tả như sau:

Người dùng gửi yêu cầu thông qua ứng dụng nội bộ.

- Hệ thống xác thực người dùng và xác định phạm vi tài liệu được phép truy cập.

- Thành phần truy xuất tìm những nội dung phù hợp trong phạm vi quyền đã xác định.

- Mô hình AI xử lý yêu cầu dựa trên thông tin được cung cấp theo thiết kế.

- Hệ thống kiểm tra định dạng, điều kiện phản hồi và những yêu cầu chất lượng có thể kiểm chứng.

- Kết quả được trả về cho người dùng hoặc chuyển sang quy trình xử lý khác nếu không đáp ứng điều kiện.

- Thông tin vận hành cần thiết được ghi nhận theo chính sách bảo mật và lưu trữ đã thống nhất.

Trong trường hợp này, phương pháp RAG, tức tạo câu trả lời có bổ sung thông tin được truy xuất, có thể là một lựa chọn để hỗ trợ sử dụng tài liệu. Tuy nhiên, RAG không tự bảo đảm câu trả lời chính xác hoặc tuân thủ quyền truy cập. Các điểm kiểm soát dữ liệu, kết quả và quyền sử dụng vẫn cần được thiết kế riêng.

Tương tự, hệ thống chỉ cần phân loại dữ liệu không nhất thiết phải dùng RAG. Việc sử dụng AI agent có khả năng thực hiện nhiều bước hoặc gọi công cụ cũng chỉ phù hợp khi yêu cầu thực sự cần những chức năng đó và các quyền thao tác được kiểm soát.

Kiến trúc tốt phải chỉ ra được cách hệ thống xử lý đầu vào không hợp lệ, dữ liệu không tồn tại, mô hình không phản hồi, kết quả thiếu căn cứ hoặc thao tác vượt quyền. Với tác vụ có ảnh hưởng đáng kể, có thể cần bước xác nhận của con người trước khi thực hiện hành động.

3.3. Chuẩn bị thử nghiệm, triển khai và bàn giao

Một bản thiết kế chỉ có giá trị triển khai khi nhóm thực hiện biết phải xây dựng những gì, kiểm chứng bằng cách nào và điều kiện nào cho phép đưa hệ thống vào sử dụng.

AI Solutions Architect cần phối hợp xác định các nhóm tiêu chí nghiệm thu:

- Chức năng: Hệ thống có xử lý đúng tác vụ, định dạng đầu ra và quy trình nghiệp vụ hay không.

- Chất lượng AI: Kết quả có đáp ứng bộ tiêu chí đánh giá trên các tình huống đại diện, bao gồm trường hợp khó và ngoại lệ hay không.

- Bảo mật: Quyền truy cập, dữ liệu nhạy cảm và những điểm tích hợp có được kiểm soát phù hợp không.

- Hiệu năng: Độ trễ, khả năng xử lý lưu lượng và mức sử dụng tài nguyên có nằm trong giới hạn đã thống nhất không.

- Vận hành: Có cơ chế theo dõi, phát hiện suy giảm chất lượng, xử lý lỗi và khôi phục phương án ổn định khi cần không.

Quá trình triển khai có thể bắt đầu bằng thử nghiệm trên phạm vi giới hạn, đánh giá với dữ liệu được phép sử dụng rồi mở rộng khi các điều kiện nghiệm thu được đáp ứng. Nhóm cũng cần quản lý phiên bản các thành phần liên quan để xác định thay đổi nào dẫn đến sự khác biệt về kết quả.

Theo tài liệu AWS Well-Architected Generative AI Lens, khi thiết kế và vận hành ứng dụng AI tạo sinh, các yếu tố cần xem xét bao gồm chất lượng đầu ra, bảo mật, độ tin cậy, hiệu năng và tối ưu chi phí. Đây là khung tham khảo hữu ích cho các hệ thống thuộc phạm vi AI tạo sinh, không phải một sơ đồ bắt buộc áp dụng cho mọi dự án.

Trong quá trình bàn giao, kiến trúc sư cần làm rõ ai phụ trách triển khai, ai theo dõi các chỉ số, ai có quyền thay đổi cấu hình và quy trình xử lý khi chất lượng suy giảm.

Cần phân biệt trách nhiệm thiết kế kiến trúc với công việc MLOps hằng ngày. AI Solutions Architect có thể đề xuất cơ chế giám sát, quản lý phiên bản và cập nhật mô hình, nhưng việc trực tiếp vận hành pipeline, xử lý sự cố hoặc thực hiện triển khai tự động có thể thuộc nhóm MLOps, kỹ sư phần mềm hoặc nhóm hạ tầng, tùy cách tổ chức dự án.

4. Kỹ năng cân bằng chất lượng, chi phí, độ trễ và bảo mật

4.1. Hiểu kiến trúc phần mềm, dữ liệu và AI

Để đưa ra những quyết định thiết kế có cơ sở, AI Solutions Architect cần kết hợp kiến thức kiến trúc phần mềm với hiểu biết về dữ liệu và đặc điểm hoạt động của các hệ thống AI.

Nhóm kiến thức về kiến trúc phần mềm giúp người làm nghề hiểu cách các thành phần giao tiếp, tổ chức API, quản lý cơ sở dữ liệu, xử lý bất đồng bộ, thiết kế khả năng mở rộng và phân tách trách nhiệm giữa các dịch vụ.

Kiến thức dữ liệu hỗ trợ quyết định về nguồn thông tin, chất lượng đầu vào, phương án lưu trữ, cập nhật và quản lý quyền truy cập. Đối với AI, người thiết kế cần hiểu khả năng và giới hạn của những nhóm mô hình phù hợp với dự án, phương pháp đánh giá và nguyên nhân khiến chất lượng kết quả có thể thay đổi.

Những năng lực này cần gắn với quyết định thực tế. Chẳng hạn:

- Hiểu API để lựa chọn phương án tích hợp và xử lý lỗi giữa các hệ thống.

- Hiểu cơ sở dữ liệu và quyền truy cập để hạn chế tình trạng thành phần AI sử dụng thông tin ngoài phạm vi được phép.

- Hiểu đặc điểm mô hình để xác định cách thử nghiệm, so sánh đầu ra và xử lý trường hợp thiếu độ tin cậy.

- Hiểu hạ tầng và kiến trúc cloud để đánh giá phương án triển khai, độ sẵn sàng và chi phí vận hành.

- Hiểu các nguyên tắc bảo mật để xác định điểm cần bảo vệ dữ liệu và kiểm soát thao tác.

Chứng chỉ cloud, chứng chỉ AI hoặc các khóa đào tạo chuyên môn có thể hỗ trợ thể hiện nền tảng kiến thức. Tuy nhiên, không có cơ sở để mặc định tất cả doanh nghiệp đều yêu cầu cùng một chứng chỉ. Ứng viên cần đối chiếu JD và chứng minh khả năng áp dụng kiến thức vào thiết kế.

4.2. Đo và giải thích các đánh đổi

Thiết kế kiến trúc AI là quá trình cân bằng những yêu cầu có thể xung đột. Một phương án có chất lượng đầu ra tốt chưa chắc đáp ứng được yêu cầu về thời gian phản hồi, chi phí hoặc quyền sử dụng dữ liệu.

Ví dụ giả định, doanh nghiệp muốn xây dựng trợ lý tra cứu tài liệu nội bộ và đang cân nhắc hai phương án:

- Phương án A sử dụng dịch vụ mô hình được quản lý, giúp giảm phần công việc trực tiếp quản trị hạ tầng mô hình nhưng phải đánh giá kỹ điều kiện xử lý dữ liệu, phụ thuộc nhà cung cấp và chi phí sử dụng.

- Phương án B sử dụng mô hình do doanh nghiệp tự triển khai, có thể tạo thêm khả năng kiểm soát môi trường vận hành nhưng đòi hỏi năng lực quản lý hạ tầng, duy trì hiệu năng, cập nhật và xử lý sự cố.

Không thể khẳng định phương án nào tốt hơn nếu chưa kiểm tra mô hình cụ thể, cấu hình triển khai, dữ liệu, lưu lượng thực tế và ràng buộc của doanh nghiệp.

Để so sánh có cơ sở, người thiết kế có thể đề xuất bộ tình huống kiểm thử đại diện, xác định cách đánh giá tính đúng đắn của kết quả, ghi nhận độ trễ và đo chi phí theo cùng một đơn vị công việc. Những trường hợp hệ thống không trả lời được hoặc trả lời sai cũng phải được đưa vào đánh giá.

Hướng dẫn Google Cloud Well-Architected Framework dành cho AI và ML đề cập đến các yêu cầu về vận hành, bảo mật, độ tin cậy, chi phí và hiệu năng của hệ thống AI. Đây là những nhóm tiêu chí có thể tham khảo khi xây dựng phương pháp đánh giá kiến trúc, đồng thời cần điều chỉnh theo hệ thống và nền tảng thực tế.

Nếu sử dụng kết quả benchmark để chứng minh một phương án, ứng viên cần nêu rõ mô hình, phiên bản, cấu hình, tập dữ liệu, cách đo và điều kiện thử nghiệm. Kết quả thu được trong một môi trường không tự động đại diện cho mọi môi trường khác.

4.3. Truyền đạt kiến trúc với các nhóm liên quan

AI Solutions Architect thường phải làm việc với các nhóm có góc nhìn khác nhau về cùng một hệ thống. Nhóm nghiệp vụ quan tâm hệ thống có giải quyết đúng vấn đề hay không, nhóm phát triển quan tâm khả năng xây dựng, còn nhóm vận hành và bảo mật cần biết những rủi ro phải kiểm soát.

Do đó, khả năng trình bày kiến trúc không chỉ nằm ở kỹ năng thuyết trình mà còn ở việc diễn đạt chính xác những quyết định cần được thống nhất.

Với nhóm nghiệp vụ, người thiết kế nên giải thích tác vụ được tự động hóa đến đâu, tình huống nào cần con người xác nhận và điều kiện nào được xem là đạt yêu cầu. Với nhóm kỹ thuật, cần trình bày rõ thành phần hệ thống, giao diện tích hợp, luồng dữ liệu, giả định hiệu năng và phương án xử lý lỗi.

Ví dụ, thay vì chỉ nói rằng hệ thống sử dụng một mô hình AI có khả năng hiểu tài liệu, người thiết kế cần làm rõ tài liệu được truy xuất từ đâu, ai được phép truy cập, câu trả lời được đánh giá thế nào và điều gì xảy ra khi không tìm thấy căn cứ phù hợp.

Một tài liệu bàn giao có giá trị phải giúp nhóm triển khai nhận biết được điều gì đã được quyết định, điều gì còn là giả định và vấn đề nào cần kiểm chứng trước khi thực hiện. Đây là năng lực trực tiếp phục vụ trách nhiệm kiến trúc, không chỉ là kỹ năng giao tiếp thông thường.

5. Mức lương AI Solutions Architect và yếu tố ảnh hưởng

5.1. Kiểm tra đúng vai trò, thị trường và đơn vị lương

Mức lương AI Solutions Architect phụ thuộc vào thị trường lao động, phạm vi công việc, năng lực chuyên môn và trách nhiệm mà doanh nghiệp giao cho vị trí. Không nên lấy mức lương của Solution Architect nói chung làm mức đại diện cho một chức danh chuyên về AI khi chưa đối chiếu nội dung công việc và nguồn dữ liệu.

Nguyên nhân là cùng tên gọi Architect nhưng có vị trí chủ yếu thiết kế ứng dụng doanh nghiệp, có vị trí thiên về giải pháp cloud, trong khi những công việc chuyên sâu về AI còn yêu cầu đánh giá dữ liệu, mô hình và chất lượng kết quả.

Khi tìm hiểu lương, ứng viên cần kiểm tra ít nhất các yếu tố:

- Chức danh được công bố và những nhiệm vụ thực tế trong JD.

- Thị trường, địa điểm làm việc và hình thức làm việc.

- Cấp độ kinh nghiệm, quy mô hệ thống và trách nhiệm kỹ thuật.

- Đồng tiền, kỳ thanh toán và cách xác định thu nhập.

- Thời điểm thông tin lương được công bố.

Chẳng hạn, khi tham khảo nhóm việc làm kỹ sư giải pháp phần mềm, ứng viên cần đọc phần nhiệm vụ để nhận biết vị trí có thực sự phụ trách kiến trúc AI hay chủ yếu thiết kế giải pháp phần mềm truyền thống.

Một mức lương được công bố cho vị trí ở thị trường nước ngoài cũng không thể mặc nhiên coi là mức lương phổ biến tại Việt Nam. Khi chưa có dữ liệu đủ rõ về chức danh, địa bàn, thời điểm và cách tính, không nên đưa ra một dải lương được trình bày như mức chung của nghề.

5.2. Đối chiếu mức sở hữu giải pháp và trách nhiệm

Hai vị trí có tên AI Solutions Architect vẫn có thể khác nhau đáng kể về phạm vi trách nhiệm. Vì thế, khi so sánh thu nhập, ứng viên cần đánh giá mức độ sở hữu giải pháp và những quyết định phải chịu trách nhiệm.

Một vị trí có thể tập trung vào giai đoạn trước bán hàng, bao gồm tìm hiểu yêu cầu khách hàng, xây dựng phương án kỹ thuật, trình diễn giải pháp và phối hợp chuẩn bị đề xuất. Vị trí khác có thể chịu trách nhiệm thiết kế chi tiết, điều phối triển khai, kiểm chứng kiến trúc và hỗ trợ bàn giao vận hành.

Những yếu tố cần đối chiếu bao gồm:

- Phạm vi phụ trách một hệ thống nội bộ hay nhiều dự án, nhiều khách hàng.

- Mức độ tự chủ khi lựa chọn công nghệ, xác định kiến trúc và đề xuất thay đổi.

- Trách nhiệm trực tiếp đối với thiết kế bảo mật, chất lượng AI, khả năng mở rộng và vận hành.

- Yêu cầu làm việc với khách hàng, phối hợp nhiều nhóm hoặc tham gia trình bày giải pháp.

- Kinh nghiệm đã được chứng minh qua những dự án có độ phức tạp phù hợp.

Khi đọc thông tin tuyển dụng, ứng viên nên phân biệt các yêu cầu bắt buộc với những năng lực được ưu tiên. Một vị trí yêu cầu xây dựng kiến trúc tổng thể và chịu trách nhiệm về quyết định thiết kế không nên được so sánh đơn giản với vị trí chỉ tham gia triển khai một thành phần.

Tuy nhiên, trách nhiệm rộng hơn không tự động chứng minh mức lương cao hơn trong mọi trường hợp. Thu nhập cụ thể vẫn phải dựa trên đề nghị của doanh nghiệp và điều kiện làm việc thực tế.

5.3. Làm rõ cấu phần offer trước khi so sánh

Để đánh giá hai đề nghị công việc, ứng viên không nên chỉ so sánh con số thu nhập được giới thiệu. Điều cần làm rõ là phần thu nhập cố định, các khoản biến đổi và những điều kiện đi kèm.

Một số nội dung nên xác nhận trực tiếp với doanh nghiệp gồm:

- Mức lương được thông báo là gross hay net và được tính theo tháng, năm hay kỳ thanh toán khác.

- Phần lương cố định được xác định như thế nào.

- Có thưởng hiệu suất, thưởng dự án hoặc hoa hồng hay không; nếu có thì điều kiện hưởng và cách tính cụ thể là gì.

- Có yêu cầu đi công tác, trực hỗ trợ hệ thống hoặc làm việc theo lịch của khách hàng hay không.

- Những quyền lợi, trách nhiệm và điều kiện đánh giá kết quả công việc được ghi nhận ra sao.

Ví dụ giả định, hai doanh nghiệp đưa ra mức thu nhập kỳ vọng tương đương nhưng một bên có phần thưởng phụ thuộc vào kết quả dự án, còn bên kia sử dụng mức cố định. Ứng viên cần làm rõ phần thu nhập có điều kiện trước khi đưa ra quyết định, thay vì coi cả hai đề nghị có giá trị chắc chắn như nhau.

Người muốn tìm việc nhanh có thể dễ bỏ qua bước kiểm tra này khi thấy chức danh phù hợp hoặc mức thu nhập hấp dẫn. Tuy nhiên, việc đối chiếu đầy đủ offer với JD, phạm vi trách nhiệm và khả năng đáp ứng của bản thân sẽ giúp hạn chế những hiểu nhầm trong quá trình nhận việc.

6. Chuẩn bị portfolio kiến trúc, CV và phỏng vấn

6.1. Chọn case study có yêu cầu và ràng buộc rõ

Đối với AI Solutions Architect, portfolio cần thể hiện khả năng phân tích vấn đề và đưa ra những quyết định thiết kế có thể giải thích, thay vì chỉ tập hợp hình ảnh sơ đồ hoặc tên công nghệ.

Ứng viên có thể lựa chọn một dự án đã thực hiện và được phép công bố, hoặc xây dựng tình huống giả định để thể hiện tư duy thiết kế. Điều quan trọng là phải ghi rõ bản chất của dự án, phạm vi công việc và mức độ hoàn thiện.

Ví dụ giả định, ứng viên xây dựng case study về hệ thống hỗ trợ nhân viên tra cứu tài liệu hướng dẫn nghiệp vụ. Portfolio có thể được triển khai theo trình tự:

- Bối cảnh: Xác định nhóm người dùng, nhu cầu tra cứu và những vấn đề trong quy trình hiện tại.

- Yêu cầu và ràng buộc: Nêu loại dữ liệu được phép sử dụng, phạm vi truy cập, điều kiện bảo mật và yêu cầu về kết quả.

- Phương án: So sánh phương pháp tìm kiếm thông thường với phương án sử dụng AI có bổ sung thông tin truy xuất.

- Sơ đồ kiến trúc: Thể hiện ứng dụng người dùng, cơ chế xác thực, thành phần truy xuất, mô hình, kiểm soát đầu ra và tích hợp.

- Đánh đổi: Giải thích các yếu tố về chất lượng, độ trễ, chi phí, độ phức tạp và khả năng vận hành.

- Kiểm chứng: Đề xuất hoặc thực hiện thử nghiệm trên bộ dữ liệu hợp lệ, ghi nhận cách đo và giới hạn của kết quả.

- Kết luận thiết kế: Nêu những điều kiện để lựa chọn phương án, rủi ro còn lại và những việc cần xác minh trước khi triển khai thật.

Nếu đây chỉ là bài tập cá nhân, cần ghi rõ chưa triển khai cho doanh nghiệp và chưa được kiểm chứng trong môi trường thực tế. Không sử dụng dữ liệu bí mật, tài liệu khách hàng hay những kết quả không thuộc quyền công bố của mình.

Một case study có yêu cầu, quyết định, đánh đổi và phương pháp kiểm chứng rõ ràng thường giúp người đánh giá hiểu năng lực kiến trúc tốt hơn một sơ đồ chứa nhiều công nghệ nhưng thiếu lý do sử dụng.

6.2. Chứng minh quyết định của mình và kết quả kiểm tra

Khi chuẩn bị cv xin việc, ứng viên nên trình bày kinh nghiệm theo những quyết định kỹ thuật và bằng chứng thực tế có thể kiểm tra. Việc liệt kê hàng loạt công cụ sẽ thiếu sức thuyết phục nếu không cho thấy ứng viên đã sử dụng kiến thức đó để giải quyết vấn đề gì.

Với mỗi dự án, có thể mô tả theo trình tự: yêu cầu cần giải quyết, trách nhiệm cá nhân, phương án đã đánh giá, quyết định được đưa ra và kết quả có bằng chứng.

Chẳng hạn, nếu từng tham gia xây dựng hệ thống xử lý tài liệu, ứng viên cần nêu rõ mình phụ trách thiết kế luồng dữ liệu, lựa chọn phương án tích hợp hay xây dựng bộ tiêu chí đánh giá. Nếu chỉ tham gia một phần, không nên ghi toàn bộ kiến trúc là thành quả cá nhân.

Cần phân biệt những mức độ công việc sau:

- Đề xuất kiến trúc: Có bản thiết kế và lập luận kỹ thuật nhưng chưa chắc đã thử nghiệm.

- Thực hiện thử nghiệm: Có kết quả kiểm tra trong phạm vi dữ liệu và môi trường đã xác định.

- Tham gia triển khai: Có đóng góp thực tế vào quá trình đưa hệ thống vào sử dụng.

- Chịu trách nhiệm vận hành: Có phạm vi công việc cụ thể liên quan đến theo dõi, xử lý và cải thiện hệ thống sau triển khai.

Những mức độ này không được sử dụng thay thế cho nhau. Một bản vẽ kiến trúc không chứng minh hệ thống đã hoạt động ổn định, cũng như một thử nghiệm thành công không đồng nghĩa với việc giải pháp đã sẵn sàng phục vụ mọi quy mô sử dụng.

Nếu ứng viên có số liệu kiểm thử, cần ghi đúng phương pháp, điều kiện và phạm vi đo. Không thêm tỷ lệ chính xác, lượng người dùng, mức tiết kiệm chi phí hoặc thành tích khi không có bằng chứng.

Đối với người chuyển hướng từ Solution Architect, kỹ sư phần mềm, kỹ sư dữ liệu hoặc AI Engineer, hồ sơ có thể tập trung vào những năng lực đã có, đồng thời bổ sung case study thể hiện cách xử lý các vấn đề đặc thù của AI. Không cần tự nhận đã đảm nhiệm đầy đủ vai trò kiến trúc AI nếu kinh nghiệm thực tế chưa bao phủ trách nhiệm đó.

6.3. Luyện trình bày và bảo vệ một phương án kiến trúc

Trong phỏng vấn AI Solutions Architect, ứng viên có thể được yêu cầu trình bày cách tiếp cận một bài toán chưa có sẵn lời giải. Người phỏng vấn không chỉ quan tâm công nghệ được lựa chọn mà còn muốn hiểu cách ứng viên xác định yêu cầu, phân tích rủi ro và bảo vệ quyết định.

Một số nhóm câu hỏi có thể chuẩn bị gồm:

- Nếu dữ liệu chưa đủ chất lượng, bạn sẽ đánh giá tính khả thi của giải pháp AI như thế nào?

- Khi hai mô hình có chất lượng đầu ra khác nhau nhưng chi phí và độ trễ cũng khác nhau, bạn sẽ quyết định dựa trên tiêu chí nào?

- Nếu người dùng yêu cầu truy xuất tài liệu không thuộc quyền của họ, kiến trúc sẽ kiểm soát ở những điểm nào?

- Nếu mô hình trả lời sai nhưng câu văn có vẻ hợp lý, bạn sẽ xây dựng phương pháp kiểm thử và xử lý ra sao?

- Khi hệ thống hoạt động kém hơn sau một thay đổi, cần những thông tin gì để xác định nguyên nhân và lựa chọn phương án khắc phục?

Đối với các câu hỏi tình huống, ứng viên nên bắt đầu bằng việc làm rõ mục tiêu, loại dữ liệu, người sử dụng, ràng buộc bảo mật, khối lượng xử lý và giới hạn chi phí. Sau đó mới trình bày các phương án khả thi, lý do lựa chọn và cách kiểm chứng.

Chẳng hạn, trước câu hỏi thiết kế trợ lý AI cho nhân viên nội bộ, không nên lập tức khẳng định phải sử dụng một mô hình cụ thể kết hợp RAG và agent. Cần hỏi hệ thống xử lý loại tài liệu nào, có cần thực hiện hành động trên phần mềm khác hay chỉ tra cứu thông tin, yêu cầu phân quyền ra sao và cách xác nhận kết quả đúng.

Một cách trả lời có sức thuyết phục là chỉ rõ phương án được đề xuất phù hợp với điều kiện nào, điều kiện nào chưa xác minh và trường hợp nào sẽ khiến người thiết kế thay đổi quyết định.

Khi chưa có dữ liệu để đưa ra lựa chọn cuối cùng, ứng viên có thể đề xuất thử nghiệm so sánh thay vì khẳng định chắc chắn một phương án. Đây là cách thể hiện tư duy kiến trúc dựa trên bằng chứng, đồng thời cho thấy khả năng nhận diện giới hạn của giải pháp.

7. Câu hỏi thường gặp

7.1. AI Solutions Architect có phải người thiết kế nhà bằng AI không?

Không. Trong phạm vi công nghệ thông tin, AI Solutions Architect là vị trí thiết kế kiến trúc giải pháp phần mềm có sử dụng trí tuệ nhân tạo. Công việc liên quan đến dữ liệu, mô hình, tích hợp hệ thống, bảo mật và vận hành. Đây không phải chức danh dành cho người sử dụng AI để thiết kế nhà ở hoặc công trình xây dựng.

7.2. Vị trí này có cần biết lập trình không?

Người đảm nhiệm vị trí này cần hiểu cách phần mềm và các thành phần AI được xây dựng, kết nối và kiểm chứng để đưa ra những quyết định kiến trúc khả thi. Khả năng đọc mã nguồn, thử nghiệm API hoặc xây dựng nguyên mẫu có thể hữu ích. Tuy nhiên, mức độ trực tiếp viết code và ngôn ngữ lập trình bắt buộc phụ thuộc vào JD cụ thể, không thể áp một yêu cầu chung cho mọi doanh nghiệp.

7.3. Có chứng chỉ cloud là đủ để làm AI Solutions Architect không?

Không. Chứng chỉ cloud có thể giúp thể hiện kiến thức về hạ tầng và dịch vụ công nghệ, nhưng chưa thay thế được khả năng phân tích yêu cầu, lựa chọn mô hình, thiết kế tích hợp, đánh giá chất lượng và giải thích đánh đổi. Ứng viên cần kết hợp kiến thức chuyên môn với những dự án, case study hoặc kết quả công việc phù hợp và có thể kiểm chứng.

7.4. Portfolio chỉ có sơ đồ kiến trúc đã đủ chưa?

Chưa đủ để thể hiện toàn bộ năng lực. Sơ đồ giúp người xem nhận diện các thành phần và mối quan hệ trong hệ thống, nhưng cần được bổ sung bằng bối cảnh, yêu cầu, giả định, lý do lựa chọn công nghệ, phương án thay thế và cách kiểm chứng. Nếu dự án mới dừng ở mức thiết kế, ứng viên phải ghi rõ giới hạn đó, không trình bày như một hệ thống đã triển khai và vận hành thành công.