Pipeline RAG của bạn vượt qua bài kiểm tra tải tiêu chuẩn một cách xuất sắc. Độ trễ p95 trông rất ổn định. Tỷ lệ lỗi gần như bằng không. Tuy nhiên, người dùng lại báo cáo rằng các câu trả lời né tránh câu hỏi, trích dẫn các tài liệu không tồn tại, hoặc lôi ra những đoạn văn không liên quan từ một báo cáo trắng đã tải lên từ sáu tháng trước. Bảng điều khiển báo rằng mọi thứ đều ổn. Nhưng trải nghiệm thực tế cho thấy nó đang bị lỗi.
Sự mất kết nối đó tồn tại vì các bài kiểm tra hiệu năng truyền thống được xây dựng cho các hệ thống yêu cầu-phản hồi (request-response), chứ không phải cho các hệ thống có khả năng "tư duy". Khi bạn gửi một nghìn yêu cầu song song đến một endpoint REST, bạn sẽ biết liệu máy chủ của mình có trụ vững hay không. Bạn sẽ không học được gì về việc liệu lớp truy xuất (retrieval layer) có lấy đúng các đoạn dữ liệu (chunks) hay không, liệu mẫu prompt (prompt template) có giữ được ngữ cảnh hay không, hoặc liệu mô hình có tự bịa ra các nguồn khi kho vector (vector store) trống rỗng hay không. Kiểm tra tải tiêu chuẩn đo lường tốc độ. Các ứng dụng RAG yêu cầu bạn phải đo lường sự thấu hiểu.
Vượt ra ngoài Mã trạng thái 200
Một bài kiểm tra tải API điển hình kiểm tra ba thứ: tính khả dụng (availability), độ trễ (latency) và thông lượng (throughput). Nó hỏi xem máy chủ có phản hồi không, mất bao lâu và nó chịu đựng được bao nhiêu người dùng đồng thời. Đối với một ứng dụng RAG, những con số đó là điều kiện tiên quyết, không phải là kết luận. Một câu trả lời sai nhưng nhanh vẫn là một câu trả lời sai, và những câu trả lời sai ở quy mô lớn sẽ gây tốn kém hơn là những câu trả lời chậm.
RAG thêm hai giai đoạn riêng biệt vào mỗi yêu cầu. Đầu tiên, hệ thống chuyển câu hỏi của người dùng thành một embedding, truy vấn kho vector và lấy về một tập hợp các đoạn ngữ cảnh (context chunks). Thứ hai, nó đưa các đoạn đó vào một prompt, gửi mọi thứ đến một mô hình ngôn ngữ và truyền về một câu trả lời hoàn chỉnh. Các bài kiểm tra truyền thống thường gộp các giai đoạn này thành một chỉ số "thời gian phản hồi" duy nhất. Chúng coi công cụ truy xuất và bộ tạo (generator) như một "hộp đen" duy nhất.
Bạn cần phải mở chiếc hộp đó ra. Nếu cơ sở dữ liệu vector của bạn chậm lại dưới tải trọng, độ trễ truy xuất sẽ tăng lên. Mô hình LLM có thể vẫn phản hồi nhanh, nhưng nó đang phản hồi dựa trên ngữ cảnh rác được lấy ra một cách vội vã. Ngược lại, việc tìm kiếm vector vẫn nhanh chóng trong khi hàng đợi LLM bị tắc nghẽn, làm tăng thời gian đến token đầu tiên (time-to-first-token) cho đến khi người dùng phải nhìn chằm chằm vào con trỏ đang nhấp nháy. Một bộ đếm thời gian đầu-cuối (end-to-end) duy nhất sẽ che giấu cả hai loại thất bại này.
Kiểm tra việc Truy xuất, không chỉ là Cơ sở dữ liệu
Hầu hết các nhóm chỉ chạy một bài kiểm tra chuẩn (benchmark) tìm kiếm vector nhanh chóng và coi như lớp truy xuất đã được kiểm tra. Bài kiểm tra đó thường chỉ đo lường tốc độ cơ sở dữ liệu trả về các láng giềng gần nhất cho một truy vấn được chọn sẵn. Nó hiếm khi đo lường xem liệu các láng giềng đó có thực sự chứa câu trả lời hay không.
Chất lượng truy xuất thay đổi theo tải trọng theo những cách tinh vi. Dưới áp lực đồng thời, các chỉ mục láng giềng gần nhất xấp xỉ (approximate nearest neighbor indexes) có thể hoạt động khác với khi chạy riêng lẻ. Các chiến lược chia nhỏ (chunking strategies) trông có vẻ hoàn hảo trong notebook sẽ bắt đầu làm rò rỉ ngữ cảnh qua các ranh giới khi mười nghìn tài liệu cùng cạnh tranh trong cùng một không gian embedding. Một truy vấn trả về đoạn văn lý tưởng trong môi trường yên tĩnh có thể hiển thị một slide marketing gây hiểu lầm khi chỉ mục đang được xây dựng lại hoặc khi việc lọc siêu dữ liệu (metadata) bị lược bỏ dưới áp lực yêu cầu.
Để kiểm tra điều này một cách đúng đắn, bạn cần một bộ dữ liệu chuẩn (ground-truth dataset). Hãy biên soạn các câu hỏi mà bạn đã biết rõ tài liệu nguồn nào sẽ xuất hiện. Chạy các câu hỏi đó ở các mức độ đồng thời khác nhau và kiểm tra xem các đoạn dữ liệu mong đợi có nằm trong kết quả top-k hay không. Hãy theo dõi tỷ lệ trúng (hit rate), chứ không chỉ là thời gian truy vấn. Nếu năm đoạn dữ liệu hàng đầu của bạn hoàn toàn bỏ lỡ nguồn quan trọng, thì quy trình truy xuất của bạn đã thất bại trước khi LLM kịp thức tỉnh.
Bạn cũng nên kiểm tra sức chịu tải ở các trường hợp biên (edges). Hãy gửi các truy vấn không có câu trả lời trong kho ngữ liệu (corpus). Hãy gửi các câu hỏi mơ hồ có thể khớp với nhiều lĩnh vực khác nhau. Hãy gửi các câu hỏi dài vượt quá giới hạn token của mô hình embedding và bị cắt bỏ một cách âm thầm. Hãy quan sát những gì lớp truy xuất trả về. Trong mỗi trường hợp, hình thức thất bại quan trọng hơn số mili giây đã trôi qua.
Khi Mô hình "nghẹt thở" một cách âm thầm
Một khi các đoạn dữ liệu đã đến được LLM, việc kiểm tra tải tiêu chuẩn vẫn tiếp tục lừa dối