Chọn Foundation Model và vòng đời ứng dụng FM

Domain 3 là phần lớn nhất của kỳ thi (28%). Trọng tâm: biết chọn một mô hình nền tảng (FM) foundation model phù hợp cho bài toán, và hiểu vòng đời của một ứng dụng dùng FM — từ ý tưởng đến vận hành. Bài này đặt nền cho bốn bài còn lại (prompting, RAG, customization, đánh giá & agent).

Foundation model là gì trong bối cảnh ứng dụng#

FM là mô hình lớn được tiền huấn luyện trên dữ liệu khổng lồ, có thể dùng cho nhiều tác vụ mà không cần huấn luyện lại từ đầu. Trên AWS, bạn truy cập FM chủ yếu qua Amazon Bedrock (API tới nhiều nhà cung cấp như Anthropic, Meta, Amazon Titan, Cohere, AI21, Stability AI…) hoặc qua Amazon SageMaker JumpStart. Bạn không tự xây FM — bạn chọn và tùy biến nó.

Tiêu chí chọn một foundation model#

Đây là phần được hỏi rất nhiều. Hãy cân bằng các tiêu chí sau theo yêu cầu bài toán:

Tiêu chí	Câu hỏi cần trả lời
Chi phí Cost	Giá theo token đầu vào/đầu ra? Khối lượng dự kiến?
Độ trễ Latency	Ứng dụng thời gian thực (chatbot) hay theo lô (batch)?
Phương thức dữ liệu Modality	Chỉ văn bản, hay cần ảnh, âm thanh, đa phương thức (multimodal)?
Cửa sổ ngữ cảnh Context window	Cần đưa tài liệu dài vào prompt không?
Khả năng tùy biến Customization options	Mô hình có hỗ trợ fine-tuning, RAG, agent không?
Hiệu năng / chất lượng Performance / quality	Độ chính xác, khả năng suy luận, ngôn ngữ hỗ trợ?

Chi phí và độ trễ#

Mô hình lớn hơn thường chính xác hơn nhưng đắt và chậm hơn. Một mẹo thiết kế thường gặp: dùng mô hình nhỏ/rẻ cho tác vụ đơn giản (phân loại, tóm tắt ngắn) và chỉ gọi mô hình lớn khi thật sự cần suy luận phức tạp. Với khối lượng lớn không cần thời gian thực, batch inference giúp giảm chi phí.

Modality#

• Văn bản → văn bản: chatbot, tóm tắt, dịch, trích xuất.
• Văn bản → ảnh: sinh ảnh (vd Stability AI, Amazon Titan Image Generator).
• Đa phương thức (multimodal): nhận đầu vào gồm cả ảnh lẫn văn bản (vd phân tích hóa đơn từ ảnh). Chọn modality khớp với dữ liệu thực tế của bài toán.

Context window#

Cửa sổ ngữ cảnh Context window là số token tối đa (đầu vào + đầu ra) mô hình xử lý cùng lúc. Cửa sổ lớn cho phép đưa nhiều ngữ cảnh hơn (tài liệu dài, lịch sử hội thoại). Nhưng đưa nhiều token hơn cũng làm tăng chi phí và độ trễ, nên không phải lúc nào "càng lớn càng tốt".

Vòng đời của một ứng dụng dùng FM#

Một cách ghi nhớ thực dụng các giai đoạn xây dựng ứng dụng FM:

1. Xác định bài toán & tiêu chí thành công — định nghĩa use case, KPI (độ chính xác, chi phí/yêu cầu, độ trễ chấp nhận được).
2. Chọn FM — dựa trên các tiêu chí ở trên; thử nghiệm vài mô hình.
3. Tùy biến (customize) — theo thứ tự rẻ→đắt: prompt engineering → RAG → fine-tuning → continued pretraining (xem bài d3-04).
4. Tích hợp — kết nối FM với dữ liệu (Knowledge Bases), công cụ/API (Agents), và ứng dụng.
5. Đánh giá (evaluate) — bằng chỉ số tự động (ROUGE, BLEU, BERTScore) và đánh giá con người (xem bài d3-05).
6. Triển khai & giám sát — đưa vào sản xuất, theo dõi chi phí, độ trễ, chất lượng, an toàn (Guardrails); lặp lại khi cần.

Hai nền tảng truy cập FM trên AWS#

Dịch vụ	Đặc điểm chính
Amazon Bedrock	API serverless, không quản lý hạ tầng; truy cập nhiều FM; tích hợp Knowledge Bases, Agents, Guardrails, model evaluation.
Amazon SageMaker JumpStart	Kho mô hình dựng sẵn; phù hợp khi cần kiểm soát hạ tầng, triển khai endpoint riêng, hoặc tùy biến sâu hơn.

Với phần lớn câu hỏi AIF-C01 về "xây nhanh ứng dụng GenAI không quản lý hạ tầng" → đáp án thường là Amazon Bedrock.

Tóm tắt#

• Domain 3 là phần lớn nhất (28%); trọng tâm là chọn FM và vòng đời ứng dụng FM.
• Tiêu chí chọn FM: chi phí, độ trễ, modality, context window, khả năng tùy biến, chất lượng.
• Context window lớn = đưa được nhiều ngữ cảnh, nhưng tốn token hơn; không tự loại bỏ hallucination.
• Vòng đời: xác định bài toán → chọn FM → tùy biến → tích hợp → đánh giá → triển khai & giám sát.
• Truy cập FM trên AWS chủ yếu qua Amazon Bedrock (serverless) hoặc SageMaker JumpStart.