Bài 6 — Chi phí, độ trễ & chọn fine-tune vs RAG vs prompt

Một sản phẩm LLM có thể đúng và an toàn nhưng vẫn thất bại vì quá đắt hoặc quá chậm. Ở quy mô, mỗi token đều tính tiền và mỗi giây chờ đều làm rớt người dùng. Bài này giúp bạn tư duy như một PM biết tối ưu tam giác chất lượng — chi phí — độ trễ, và chọn đúng công cụ.

Hiểu chi phí token

Bạn trả tiền theo token cho cả input (prompt + ngữ cảnh) lẫn output. Vì vậy:

• Prompt dài, RAG nhồi top-k lớn, lịch sử hội thoại dài → đội chi phí input.
• Yêu cầu trả lời dài dòng → đội chi phí output (thường đắt hơn input mỗi token).

Đòn bẩy giảm chi phí:

• Chọn mô hình theo tác vụ: dùng mô hình nhỏ/rẻ cho việc dễ (phân loại, trích xuất), mô hình lớn cho việc khó. Định tuyến (routing) thông minh.
• Nén ngữ cảnh: chunk gọn, top-k vừa đủ, tóm tắt lịch sử hội thoại cũ.
• Prompt caching: cache phần prompt cố định (system, tài liệu chung) để không trả tiền lặp lại.
• Giới hạn max tokens đầu ra và yêu cầu súc tích.

Hiểu độ trễ (latency)

Độ trễ đến từ: kích thước mô hình, số token sinh ra, số bước (agent nhiều bước = chậm gấp bội), và retrieval.

Đòn bẩy giảm trễ:

• Streaming: hiện chữ dần để cảm giác nhanh dù tổng thời gian không đổi.
• Mô hình nhỏ hơn cho phản hồi tức thời.
• Giảm số bước/agent không cần thiết; song song hóa retrieval.
• Cache câu trả lời cho câu hỏi lặp lại phổ biến.

Ba công cụ, chọn cái nào?

Nguyên tắc vàng: đi từ rẻ tới đắt — Prompt → RAG → Fine-tune. Chỉ leo lên bậc sau khi bậc trước đã hết dư địa (chứng minh bằng eval).

Điểm mấu chốt hay bị hiểu nhầm

• Fine-tune dạy mô hình cách hành xử/định dạng, KHÔNG phải cách nhồi dữ kiện mới vào — dữ kiện dùng RAG. Fine-tune để "biết fact" vừa đắt vừa dễ lỗi thời.
• Fine-tune và RAG không loại trừ nhau: có thể fine-tune giọng + RAG dữ liệu.

Ví dụ cụ thể

Trợ lý hỗ trợ đang tốn nhiều token vì mỗi request nhồi 20 ví dụ few-shot để giữ giọng thương hiệu. Sau khi eval ổn định, bạn fine-tune giọng đó vào mô hình → bỏ được 20 ví dụ → giảm token input mỗi request, độ trễ giảm, hóa đơn giảm ở triệu request/tháng. Còn dữ liệu chính sách vẫn để RAG vì nó thay đổi hàng tuần.

Checklist tối ưu

• [ ] Đo chi phí/1.000 request và độ trễ p50/p95 hiện tại.
• [ ] Đã thử routing mô hình nhỏ cho tác vụ dễ?
• [ ] Đã bật prompt caching cho phần cố định?
• [ ] Top-k và độ dài ngữ cảnh đã tối giản mà vẫn giữ chất lượng?
• [ ] Có streaming để cải thiện cảm nhận tốc độ?
• [ ] Trước khi fine-tune: đã vắt kiệt prompt + RAG chưa (có eval chứng minh)?
• [ ] Mọi tối ưu đều chạy lại eval để chắc chất lượng không tụt.

Sai lầm thường gặp

• Fine-tune để nhồi kiến thức — sai công cụ, nên dùng RAG.
• Dùng mô hình lớn nhất cho mọi thứ, đốt tiền vô ích ở tác vụ dễ.
• Bỏ qua chi phí output và để mô hình trả lời dài lê thê.
• Tối ưu chi phí mà không chạy lại eval → rẻ hơn nhưng chất lượng tụt âm thầm.
• Tối ưu quá sớm khi chưa có người dùng, thay vì tìm product-market fit trước.
• Quên p95 latency: trung bình đẹp nhưng đuôi chậm làm nhóm người dùng bực bội.

Hoàn thành 6 bài, bạn đã có khung tư duy đầy đủ của một LLM Application PM: từ vai trò, prompt, RAG, eval, guardrails đến kinh tế token. Hãy làm bài thi tổng kết để kiểm chứng.