RAG Pipeline: 5 Quyết Định Định Hình Chất Lượng Câu Trả Lời
RAG không phải một khối duy nhất - đó là một pipeline gồm 5 điểm quyết định, mỗi điểm đều có thể tự làm hỏng câu trả lời, bất kể model nào đứng ở cuối chuỗi.
Phần lớn team mô tả RAG theo cùng một cách: "mình gắn thêm vector database để model tra cứu được." Mô tả đó đúng về mặt kỹ thuật nhưng gần như vô dụng - nó bỏ qua mọi quyết định thật sự quyết định câu trả lời đúng hay model đang tự tin bịa ra một thứ gì đó.
RAG không phải một khối duy nhất có hoặc không có. Đó là một pipeline gồm năm điểm quyết định tách biệt, mỗi điểm đều có thể tự làm hỏng câu trả lời, không liên quan gì tới việc model nào đứng ở cuối chuỗi.
Sơ đồ Luồng Pipeline RAG Tổng quan
Retrieval Mới Là Nút Thắt Cổ Chai, Không Phải Generation
Khi RAG trả lời sai, phản xạ đầu tiên thường là đổ lỗi cho model - đổi sang bản mới hơn, chỉnh prompt, thêm một dòng dặn dò "hãy cẩn thận hơn". Phần lớn thời gian, đó là sửa sai tầng. Model chỉ làm việc được với thứ nó được cấp; nếu tài liệu đúng chưa từng được truy hồi, hoặc được truy hồi nhưng mất phần ngữ cảnh khiến nó có ý nghĩa, không prompt nào cứu vãn được.
Các nghiên cứu về điểm thất bại của RAG đều xác nhận điều này: lỗi ở tầng retrieval và representation - tài liệu không bao giờ xuất hiện, hoặc xuất hiện nhưng thiếu ngữ cảnh để dùng được - là nhóm lỗi phổ biến và được ghi nhận nhiều nhất, đứng trước mọi thứ xảy ra sau khi generation bắt đầu. Sửa các tầng trong pipeline trước, đừng sửa model trước.
Cùng Một Pipeline, Bốn Cách Vỡ Trận Khác Nhau
Mỗi case dưới đây là một câu hỏi thật đi qua cùng một pipeline RAG - chỉ khác nhau ở đúng một quyết định bị sai mỗi lần.
Doanh thu Q3 của Acme là bao nhiêu?
"...tiếp tục tăng trưởng ổn định so với quý trước, biên lợi nhuận cải thiện nhẹ." (câu nêu tên "Acme" và "Q3" nằm ở chunk trước đó 3 vị trí, đã bị tách rời khi xử lý)
Tôi không tìm thấy thông tin doanh thu Q3 của Acme trong tài liệu hiện có.
Ranh giới chunk rơi đúng vào giữa phần định danh (tên công ty, kỳ báo cáo) và con số thật. Retriever không có cách nào khớp câu hỏi với một chunk đã không còn nhắc tới chủ thể của nó.
Chunking Là Một Quyết Định Thiết Kế, Không Phải Bước Tiền Xử Lý
Pipeline RAG nào cũng chia tài liệu thành chunk trước khi embed, và rất dễ coi đó là một bước kỹ thuật thuần tuý - cấu hình một lần rồi quên đi. Không phải vậy. Nghiên cứu của Chroma về các chiến lược chunking cho thấy cách chọn chunking thay đổi recall của retrieval tới vài điểm phần trăm dù cùng một kích thước chunk, và chiến lược đúng phụ thuộc vào loại tài liệu: một hợp đồng có cấu trúc rõ ràng chunk tốt bằng recursive splitting đơn giản, một bài nghiên cứu nhiều chủ đề cần ranh giới đặt đúng chỗ chủ đề thật sự đổi, còn một bản transcript thô thì không cần cả hai.
Một lỗi khác dễ bị bỏ sót nằm ngay bên trong việc chunk, không phải xung quanh nó: một chunk có thể đúng độ dài nhưng vẫn mất phần ngữ cảnh khiến nó có thể tìm thấy được. Một đoạn nói về doanh thu công ty sẽ vô nghĩa với retriever một khi câu nêu tên công ty và kỳ báo cáo đã bị tách sang chunk khác. Đội kỹ thuật của Anthropic đã đo trực tiếp điều này - thêm một đoạn ngữ cảnh ngắn vào trước mỗi chunk trước khi embed giảm 49% lỗi retrieval trong thử nghiệm của họ, mà không cần đổi model trả lời câu hỏi.
Recall Phải Đi Trước Precision
Sau khi chunk đã được index, chất lượng retrieval quy về hai con số cạnh tranh nhau: recall (tài liệu liên quan có được lấy về hay không) và precision (trong số được lấy về, bao nhiêu phần thật sự liên quan). Tăng số lượng kết quả lấy về sẽ nâng recall và hạ precision - nhiều phần đúng của câu trả lời xuất hiện hơn, nhưng nhiễu xung quanh nó cũng nhiều hơn.
Thứ tự ở đây quan trọng hơn cả điểm cân bằng chính xác. Nếu tài liệu đúng chưa từng nằm trong tập được truy hồi, không reranker nào, không prompt nào, không context window lớn hơn nào sửa được điều đó - câu trả lời đúng đã không còn khả thi ngay từ đầu. Vấn đề precision còn sửa được sau bằng cách lọc bớt; vấn đề recall thì không sửa được sau, vì thông tin thật sự đã không còn ở đó vào lúc model nhìn thấy nó.
Ba Con Số Đo Được, Từ Ba Thí Nghiệm Độc Lập
Không cộng dồn được với nhau (khác thí nghiệm, khác baseline) - nhưng cùng chỉ về một hướng.
Mặc định hợp lý cho phần lớn use case (Chroma Technical Report)
Cải thiện biên, đổi lại chi phí embed từng câu (Chroma Technical Report)
Thêm ngữ cảnh trước khi embed, độc lập với việc chọn chiến lược chunk (Anthropic Engineering)
Cả ba con số đến từ ba benchmark riêng biệt, không thể gộp thành một tổng duy nhất - nhưng cả ba đều đo tác động của một quyết định ở bước chuẩn bị dữ liệu, không phải một lần đổi model. Đây là lý do 5 quyết định trong bài này đáng được thiết kế cẩn thận như chọn model.
Grounding Không Đồng Nghĩa Với Đúng Sự Thật
Retrieval và grounding thất bại theo hai cách khác nhau, và gộp chung chúng lại sẽ che mất cái thứ hai. Một câu trả lời có grounding là câu trả lời được hậu thuẫn thật sự bởi context nó nhận được - không phải câu trả lời tình cờ đúng với thực tế. Model hoàn toàn có thể truy hồi đúng chính xác đoạn cần thiết nhưng vẫn khẳng định vượt quá những gì đoạn đó thật sự nói, biến "chưa test chính thức, nhưng một số người dùng báo cáo vẫn hoạt động" thành một câu "có, tương thích" chắc nịch.
Đó là lý do "chỉ trả lời dựa trên context được cấp" phải là một chỉ dẫn tường minh và một bước kiểm tra tường minh, không phải một giả định mặc nhiên. Nó kiểm tra được ở cấp độ từng luận điểm: bóc câu trả lời thành các phát biểu thành phần và xác minh từng phát biểu có thật sự được chunk trích dẫn cho nó hậu thuẫn hay không, thay vì chỉ đánh giá cả câu trả lời như một khối - một đoạn văn nghe rất hợp lý vẫn có thể chứa một luận điểm không có căn cứ nằm cạnh ba luận điểm hoàn toàn có căn cứ.
Freshness Là Một SLA Sản Phẩm, Không Phải Chuyện Kỹ Thuật Phụ
Một index từng trả lời đúng tháng trước có thể âm thầm trở nên sai hôm nay nếu tài liệu gốc đã đổi mà không có gì báo cho index biết để cập nhật. Sai lầm phổ biến là coi "bao lâu re-index một lần" là một cấu hình chung cho tất cả. Không phải vậy - một trang giá và một tài liệu tham khảo nền tảng mang cái giá hoàn toàn khác nhau khi bị cũ, và một lịch refresh chung cho tất cả sẽ hoặc lãng phí tài nguyên re-index nội dung gần như không đổi, hoặc để nội dung thay đổi nhanh sai suốt nhiều ngày.
Cách sửa là định cỡ yêu cầu freshness theo đúng cái giá phải trả nếu sai: gần như tức thời cho bất cứ thứ gì gắn với giá hoặc chính sách, vài giờ cho nội dung đổi thường xuyên nhưng không quá rủi ro, và một cửa sổ dài hơn nhiều cho tài liệu tham khảo vốn ổn định theo bản chất. Đây là một quyết định sản phẩm về mức rủi ro chấp nhận được, không phải một tham số cấu hình database.
Năm Quyết Định, Một Pipeline
Cả bốn kiểu thất bại ở trên đều quy về một trong năm quyết định định hình toàn bộ pipeline RAG - và mỗi quyết định xứng đáng có một bài đào sâu riêng:
Chunking strategy. Cách khớp chiến lược chunking với cấu trúc thật của tài liệu, và vì sao kích thước chunk không phải biến số quan trọng nhất.
Recall vs. precision. Cách định nghĩa thế nào là "retrieval tốt" cho một tính năng cụ thể, và vì sao recall phải được sửa trước khi precision đáng để tinh chỉnh.
Grounding contract. Cách viết và thực thi một quy tắc giữ câu trả lời sinh ra nằm trong đúng giới hạn của thứ đã thật sự được truy hồi.
Indexing cadence. Cách định nghĩa SLA freshness theo từng loại dữ liệu thay vì một lịch re-index chung.
Failure mode taxonomy. Cách phân loại RAG đang hỏng ở đâu - retrieval, representation, hay generation - trước khi tìm cách sửa.
Hình Dạng Của Một Pipeline RAG Hoạt Động Tốt
Bỏ qua từng kỹ thuật cụ thể, một pipeline RAG hoạt động tốt làm đúng ba việc: truy hồi đúng tài liệu trước khi lo câu trả lời được diễn đạt hoa mỹ tới đâu, giữ mọi luận điểm sinh ra có thể lần ngược về đúng thứ nó thật sự được cấp, và coi độ cũ của dữ liệu là một rủi ro cần định cỡ theo từng loại dữ liệu chứ không phải một nút vặn cấu hình một lần. Làm đúng ba việc này, model đứng ở cuối pipeline trở thành một trong những quyết định ít quan trọng nhất trong cả hệ thống - và đó chính xác là điều nên xảy ra.