Bài 6 — Vận hành sản phẩm RAG: quy trình, đánh đổi và ra quyết định thực tế

Bài cuối ghép năm bài trước thành một hệ thống vận hành mà PM có thể dùng ngay: từ đo lường, chẩn đoán, ưu tiên backlog đến cân bằng đánh đổi và giám sát khi lên production.

Vòng lặp cải tiến RAG

• Đo: chạy golden set → recall@k, precision, faithfulness, tỷ lệ "không biết" đúng.
• Chẩn đoán: phân loại lỗi retrieval vs generation (bài 5), thống kê tỷ lệ.
• Ưu tiên: dồn nguồn lực vào loại lỗi chiếm đa số.
• Can thiệp: chỉnh một biến số mỗi lần (chunk / embedding / hybrid / reranker / prompt / freshness).
• Đo lại: so với baseline trên cùng golden set đã đóng băng.
• Giám sát production: log, phản hồi người dùng, câu hỏi mới → cập nhật golden set.

> Nguyên tắc thí nghiệm: đổi một biến mỗi lần. Đổi cùng lúc chunk và reranker rồi thấy recall tăng, bạn không biết nhờ cái nào — và không lặp lại được thành công.

Ma trận ưu tiên theo loại lỗi

Ma trận này chính là bản đồ dịch triệu chứng → nguyên nhân → hành động, giúp bạn không đổ tiền sai chỗ.

Các đánh đổi PM phải cân

• Recall vs Precision: lấy nhiều chunk tăng recall nhưng thêm nhiễu; giải bằng retrieve-rộng-rerank-tinh.
• Chất lượng vs Chi phí/Độ trễ: reranker và context dài tăng chất lượng nhưng tốn tiền và chậm. Đặt SLA rõ ràng.
• Freshness vs Ổn định: cập nhật index liên tục giữ dữ liệu tươi nhưng tăng rủi ro vận hành; cần quy trình và giám sát.
• Trung thực vs Tỷ lệ trả lời: cho phép "không biết" giảm số câu trả lời nhưng tăng niềm tin và an toàn — thường là đánh đổi đáng giá, nhất là trong lĩnh vực nhạy cảm.

Tình huống ra quyết định thực tế

Bối cảnh: Chatbot hỗ trợ nội bộ, người dùng phàn nàn "trả lời sai nhiều". Sếp muốn đổi sang model đắt nhất.

Bạn làm gì:

• Chạy golden set: recall@5 = 68%, và trong nhóm fail, 70% là lỗi retrieval (mở context không thấy đáp án).
• Kết luận: đổi model chỉ tác động lên 30% còn lại (nhóm generation). Đầu tư lớn, lợi ích nhỏ.
• Đề xuất: ưu tiên (a) bật hybrid vì nhiều câu tra mã lỗi trượt, (b) thử parent-child chunking, (c) thêm reranker.
• Chạy lại golden set: recall@5 lên 86%, tỷ lệ trả lời đúng tăng mạnh — không tốn tiền đổi model.

Đây là giá trị cốt lõi của một RAG/Search PM: biến khiếu nại mơ hồ thành chẩn đoán có số liệu, rồi thành hành động rẻ và hiệu quả.

Giám sát production

• Log đầy đủ: câu hỏi, chunk truy hồi, context, câu trả lời, citation.
• Phản hồi người dùng: nút hữu ích/không, thu thập câu fail làm nguyên liệu golden set.
• Cảnh báo freshness: indexing lag vượt ngưỡng, tài liệu hết hiệu lực còn được trích.
• Theo dõi drift: phân phối câu hỏi thay đổi → golden set cần cập nhật.

Checklist "sẵn sàng lên production"

• [ ] Golden set đã đóng băng, có nhóm "không có đáp án".
• [ ] Dashboard: recall@k, precision, faithfulness, tỷ lệ "không biết".
• [ ] Log context để chẩn đoán được từng câu.
• [ ] Quy trình freshness: cập nhật, gỡ bản cũ, versioning.
• [ ] Chính sách citation trung thực và cho phép "không biết".
• [ ] SLA về recall, freshness, độ trễ được thống nhất với các bên.

Sai lầm thường gặp

• Nhảy vào giải pháp đắt (đổi model) trước khi chẩn đoán.
• Đổi nhiều biến một lúc, không học được gì từ kết quả.
• So sánh trên golden set khác nhau giữa các lần, khiến số liệu vô nghĩa.
• Lên production mà không log context, mất khả năng chẩn đoán sau này.
• Bỏ quên freshness và citation, để rồi mất niềm tin bằng những câu trả lời sai đầy thuyết phục.

Kết khóa: Một RAG/Search PM giỏi coi lõi sản phẩm là một cỗ máy tìm kiếm, đo bằng recall@k và precision, tối ưu qua chunking–embedding–hybrid–reranking–freshness, chẩn đoán tách bạch retrieval vs generation, và bảo vệ niềm tin bằng citation trung thực. Đó là tấm bản đồ để bạn ra quyết định đúng, rẻ và có thể bảo vệ bằng số liệu.