Bài 1 — Nền tảng: LLM Application PM thực sự làm gì

Một LLM Application Product Manager không phải người huấn luyện mô hình. Bạn dùng mô hình có sẵn (GPT, Claude, Gemini, Llama...) như một nguyên liệu, và trách nhiệm của bạn là biến nó thành một sản phẩm đáng tin cậy, đúng chi phí, giải quyết nỗi đau thật của người dùng.

Khác biệt cốt lõi với PM truyền thống

Phần mềm truyền thống có tính tất định (deterministic): cùng input luôn ra cùng output. LLM thì xác suất (probabilistic): cùng câu hỏi có thể ra hai câu trả lời khác nhau, đôi khi sai một cách rất tự tin. Điều này thay đổi mọi thứ:

• Bạn không thể chỉ viết "acceptance criteria" kiểu pass/fail. Bạn cần eval đo chất lượng theo phân phối.
• "Bug" không phải lúc nào cũng là lỗi code — có thể là prompt kém, ngữ cảnh thiếu, hoặc mô hình sai.
• Chất lượng, chi phí và độ trễ là một tam giác đánh đổi bạn phải cân bằng liên tục.

Bốn lớp của một sản phẩm LLM

• Model layer — chọn mô hình (đóng/mở, kích thước, context window).
• Context layer — đưa đúng thông tin vào (RAG, tool-calling, memory).
• Orchestration layer — prompt, chuỗi bước, agent, retry, fallback.
• Product layer — UX, xử lý lỗi, feedback loop, trust cues.

PM giỏi tư duy đủ cả bốn lớp, thay vì chỉ chăm chăm "đổi prompt cho hay".

Ví dụ cụ thể

Bạn xây trợ lý trả lời chính sách nhân sự nội bộ. Người dùng hỏi "Tôi còn bao nhiêu ngày phép?". Mô hình thuần túy sẽ bịa ra một con số vì nó không có dữ liệu công ty bạn. Lời giải KHÔNG phải fine-tune, mà là:

• RAG kéo tài liệu chính sách phép + tool-calling truy vấn hệ thống HR lấy số ngày còn lại.
• Prompt ràng buộc: "Chỉ trả lời dựa trên ngữ cảnh; nếu thiếu dữ liệu, nói không biết."
• Eval kiểm tra 50 câu hỏi mẫu để đo tỷ lệ trả lời đúng/bịa.

Khung tư duy: bắt đầu từ "job to be done"

Trước khi chọn công nghệ, trả lời:

• Ai dùng, trong bối cảnh nào?
• Cái giá của một câu trả lời sai là gì? (Sai tên món ăn ≠ sai liều thuốc.)
• Người dùng có thể tự kiểm chứng câu trả lời không?

Câu trả lời quyết định bạn cần guardrails chặt tới đâu và eval khắt khe tới đâu.

Checklist khởi động một sản phẩm LLM

• [ ] Xác định rõ use case và "cái giá của sai".
• [ ] Có tập câu hỏi thật (golden set) từ người dùng, không phải tự nghĩ.
• [ ] Chọn baseline: prompt đơn giản trước, đo đã, rồi mới thêm RAG/agent.
• [ ] Định nghĩa metric chất lượng + ngưỡng chấp nhận.
• [ ] Ước lượng chi phí token cho 1.000 lượt dùng.
• [ ] Kế hoạch thu feedback (thumbs up/down, log câu trả lời).

Sai lầm thường gặp

• Nhảy ngay vào fine-tune khi vấn đề thực ra là thiếu ngữ cảnh (nên dùng RAG).
• Không có golden set nên không biết mỗi lần đổi prompt là tốt lên hay tệ đi.
• Coi demo đẹp là sản phẩm xong: demo chọn lọc 5 câu dễ, sản phẩm gặp 5.000 câu khó.
• Bỏ qua chi phí đến khi hóa đơn token tăng vọt ở quy mô.
• Không thiết kế UX cho lúc mô hình sai — người dùng mất niềm tin ngay lần đầu bị bịa.

Hiểu vai trò đúng ngay từ đầu giúp bạn không tốn tuần lễ giải sai bài toán. Các bài sau sẽ đi sâu từng công cụ: prompt, RAG, eval, guardrails và tối ưu chi phí.