Phân rã RAG Pipeline Thành 5 Điểm Quyết Định Sản Phẩm

Phân rã RAG Pipeline Thành 5 Điểm Quyết Định Sản Phẩm

RAG (Retrieval-Augmented Generation) có 5 bước: Ingest → Chunk → Embed → Retrieve → Generate. Với engineer, đây là 5 bước implementation. Với PM/BA, mỗi bước là một điểm ra quyết định sản phẩm — chỗ mà nếu bạn không tham gia, engineer sẽ tự chọn default, và default đó có thể không khớp với trải nghiệm bạn muốn.

1. Năm bước RAG nhìn qua vai trò của PM, không phải của engineer

Hãy nhìn từng bước theo đúng nghĩa đó, không phải nghĩa kỹ thuật:

• Ingest (đưa dữ liệu vào hệ thống) — Quyết định sản phẩm: nguồn nào được coi là "sự thật"? Tài liệu nội bộ, FAQ cũ, ticket support — cái nào ingest, cái nào không? Ingest sai nguồn = AI trả lời dựa trên thông tin bạn không muốn nó dùng.
• Chunk (cắt tài liệu dài thành mảnh nhỏ) — Quyết định sản phẩm: cắt theo đơn vị nào để một câu trả lời không bị "cụt" giữa chừng? (Lesson 17 sẽ đi sâu.)
• Embed (biến chunk thành vector số để máy so sánh độ giống nhau) — Đây là bước thuần kỹ thuật nhất, PM không cần can thiệp, chỉ cần hiểu: hệ thống "hiểu" nghĩa gần đúng, không phải khớp từ khóa chính xác.
• Retrieve (tìm những chunk liên quan nhất tới câu hỏi) — Quyết định sản phẩm: lấy bao nhiêu chunk là đủ? Ngưỡng "đủ liên quan" là bao nhiêu? (Lesson 18.)
• Generate (AI viết câu trả lời dựa trên các chunk đã lấy) — Quyết định sản phẩm: AI được phép trả lời gì khi không có chunk nào đủ liên quan? (Lesson 19 và 21.)

2. Ví dụ: chatbot tư vấn bảo hiểm và điểm ra quyết định ở mỗi bước

Một app hỏi-đáp chính sách bảo hiểm cho nhân viên bán bảo hiểm (không liên quan gì đến sản phẩm của Uy, chỉ để minh họa):

Nhân viên hỏi: "Khách hàng tiểu đường type 2 có được mua gói bảo hiểm sức khỏe cao cấp không?"

• Ingest: có ingest bảng điều khoản loại trừ bệnh nền không, hay chỉ ingest brochure marketing?
• Chunk: điều khoản này nằm trong 1 đoạn 800 từ — nếu cắt chunk 200 từ, câu trả lời có thể chỉ lấy được nửa điều kiện, bỏ sót phần ngoại lệ.
• Retrieve: hệ thống lấy top-3 chunk giống câu hỏi nhất — nhưng "tiểu đường" và "bệnh nền mãn tính" là 2 cách diễn đạt khác nhau, retrieval có bắt được không?
• Generate: nếu không chunk nào nói rõ về tiểu đường type 2, AI có được phép suy luận từ "bệnh nền mãn tính nói chung" không, hay phải nói "tôi không chắc, vui lòng hỏi bộ phận nghiệp vụ"?

3. Từ câu hỏi kỹ thuật thành dòng trong requirement doc

Mỗi câu hỏi trong ngoặc ở mục 2 là một dòng trong requirement doc, không phải câu hỏi kỹ thuật bạn để engineer tự trả lời. Nếu bạn không viết nó ra trước, engineer sẽ tự chọn một default nào đó — và default đó thường tối ưu cho tốc độ build, không phải cho trải nghiệm người dùng cuối.

4. Ẩn dụ: RAG như một trợ lý nghiên cứu junior

Nghĩ RAG như một trợ lý nghiên cứu junior. Bạn đưa họ một tủ hồ sơ (ingest), họ đánh dấu từng trang thành các mục nhỏ để dễ tra (chunk), học cách nhận biết trang nào "có vẻ liên quan" tới câu hỏi (embed), lục ra vài trang liên quan nhất khi bạn hỏi (retrieve), rồi viết câu trả lời dựa trên các trang đó (generate). Nếu tủ hồ sơ thiếu, họ đánh dấu ẩu, hoặc bạn không dặn họ "nếu không tìm thấy thì nói không biết" — họ sẽ bịa.

Bài tập 16.1: Bạn đang là PM cho một chatbot nội bộ trả lời câu hỏi về quy trình hoàn tiền (refund policy) cho đội chăm sóc khách hàng của một sàn thương mại điện tử. Dữ liệu nguồn gồm: (1) tài liệu chính sách hoàn tiền chính thức (15 trang), (2) 200 ticket hỗ trợ cũ có câu trả lời mẫu, (3) slide đào tạo nội bộ đã lỗi thời 1 năm.

Với mỗi bước Ingest / Chunk / Retrieve / Generate, hãy nêu một quyết định sản phẩm cụ thể bạn cần đưa ra trước khi engineer bắt tay code (không cần chi tiết kỹ thuật, chỉ cần "quyết định gì" và "vì sao nó ảnh hưởng đến trải nghiệm agent chăm sóc khách hàng").