Sau bốn tháng đưa một pipeline Retrieval-Augmented Generation (RAG) từ Jupyter notebook vào dịch vụ thực tế, tác giả đã chỉ ra năm lựa chọn cụ thể giúp biến một bản demo trình diễn thành một hệ thống mà người dùng thực sự có thể tin cậy. Sự khác biệt thể hiện qua các con số: một thay đổi đơn giản trong cách chia nhỏ văn bản đã nâng tỷ lệ truy xuất chính xác (hit rate) từ 61% lên 83%, và một tập đánh giá khiêm tốn gồm 200 truy vấn thực tế hiện có thể phát hiện hầu hết các lỗi hồi quy trước khi chúng đến tay khách hàng.
Tại sao điều này lại quan trọng
Các bản demo RAG trông rất ấn tượng – chúng có thể tìm thấy một đoạn văn và đưa ra câu trả lời hợp lý chỉ trong vài giây. Trong môi trường thực tế (production), cùng một cách tiếp cận đó thường trả về các sự thật lỗi thời, bỏ lỡ mã lỗi hoặc các câu bị đứt đoạn, làm xói mòn lòng tin của người dùng. Nút thắt cổ chai hiếm khi nằm ở mô hình ngôn ngữ; nó nằm ở cách nội dung được nạp vào (ingested), lập chỉ mục (indexed) và phục vụ (served). Việc xây dựng pipeline đúng cách có thể là ranh giới giữa một sản phẩm mang lại giá trị và một sản phẩm trở thành gánh nặng.
1. Ngừng sử dụng các đoạn văn bản có kích thước cố định
Nhiều bản mẫu (prototypes) chia mọi tài liệu thành các khối 512 token. Cách này hiệu quả với các văn bản ngắn nhưng lại làm xé nát các hướng dẫn kỹ thuật, các luồng hỗ trợ và các đoạn mã. Các câu bị chia cắt, các tiêu đề biến mất, và công cụ truy xuất không thể khớp được ngữ cảnh mà người dùng mong đợi.
Hãy chuyển sang chia nhỏ văn bản dựa trên cấu trúc (structure-aware chunking)—chia tại các tiêu đề, ranh giới hội thoại hoặc các khối mã (code fences)—để bảo toàn các đơn vị ngữ nghĩa. Trong hệ thống của tác giả, chỉ riêng việc này đã nâng tỷ lệ các truy vấn tìm thấy đoạn văn liên quan từ 61% lên 83%. Sự cải thiện đến từ việc thay đổi định dạng dữ liệu; mô hình nền tảng vẫn giữ nguyên.
2. Sử dụng tìm kiếm hỗn hợp
Tìm kiếm vector thuần túy (dựa trên độ tương đồng embedding) rất giỏi trong việc tìm các đoạn văn có cùng ý nghĩa, nhưng lại gặp khó khăn với các định danh chính xác như mã lỗi, số phiên bản hoặc các thuật ngữ chuyên biệt. Một người dùng đang tìm mã lỗi như “ERR-XXXX” có thể nhận được một đoạn văn tương đồng về mặt ngữ nghĩa nhưng hoàn toàn không chứa mã đó.
Tìm kiếm hỗn hợp (hybrid search) kết hợp chỉ mục vector dày đặc (dense vector index) với chỉ mục BM25 truyền thống (dựa trên tần suất thuật ngữ). Bằng cách trọng số hóa hai điểm số này, hệ thống sẽ truy xuất được các mục vừa gần gũi về ngữ nghĩa vừa chứa chính xác các thuật ngữ mà người dùng đã nhập. Đối với môi trường production, tìm kiếm hỗn hợp là một yêu cầu cơ bản, không phải là một tính năng bổ sung tùy chọn.
3. Xử lý dữ liệu lỗi thời
Các bảng giá, tài liệu chính sách hoặc ghi chú phát hành firmware lỗi thời sẽ nhanh chóng phá hủy uy tín. Ba bước thực tế để giữ cho chỉ mục luôn mới:
- Gắn thẻ (tag) mọi tài liệu với một dấu phiên bản hoặc dấu thời gian.
- Áp dụng cơ chế ưu tiên độ mới (recency boost) trong quá trình chấm điểm để các mục mới hơn xếp trên các bản sao cũ hơn.
- Chạy tái lập chỉ mục gia tăng (incremental re-indexing) hàng đêm để cập nhật các thay đổi từ các hệ thống nguồn.
Những biện pháp bảo vệ này ngăn hệ thống cung cấp một mức giá có hiệu lực từ quý trước hoặc một chính sách đã bị thay thế.
4. Tái xếp hạng thay vì nâng cấp mô hình
Việc nâng cấp mô hình embedding chỉ mang lại sự cải thiện nhỏ về chất lượng, trong khi việc thêm một bộ tái xếp hạng cross-encoder sẽ mang lại bước nhảy vọt lớn hơn nhiều với chi phí thấp hơn.
Quy trình production sẽ truy xuất 20 ứng viên rẻ tiền bằng tìm kiếm hỗn hợp, sau đó đưa chúng qua bộ tái xếp hạng để chọn ra 5 ứng viên hàng đầu. Cách tiếp cận hai giai đoạn này mang lại bước nhảy vọt về chất lượng lớn hơn với chỉ một phần chi phí so với việc nâng cấp toàn bộ mô hình.
5. Xây dựng một tập đánh giá thực tế
Bạn không thể cải thiện những gì bạn không đo lường được. Tác giả đã tập hợp một bộ thử nghiệm gồm 200 truy vấn thực tế của người dùng, mỗi truy vấn đi kèm với một câu trả lời được chuyên gia soạn thảo. Mọi thay đổi mã nguồn đều được chạy thử với bộ này; bất kỳ sự suy giảm chất lượng nào cũng được phát hiện trước khi triển khai.
Khi người dùng báo cáo một câu trả lời không tốt, hãy thêm ngay truy vấn đó vào tập đánh giá, biến những thất bại trong thế giới thực thành những biện pháp bảo vệ trong tương lai. Việc ghi nhật ký (logging) liên tục mọi câu trả lời được tạo ra sẽ cung cấp dữ liệu cho vòng lặp đánh giá, giúp hệ thống luôn bám sát nhu cầu sử dụng thực tế.
Quy trình pipeline trong thực tế
- Ingest (Nạp): Chia nhỏ văn bản dựa trên cấu trúc giúp bảo toàn các tiêu đề, khối mã và các lượt hội thoại.
- Index (Lập chỉ mục): Lưu trữ cả embedding dày đặc và thống kê thuật ngữ BM25.
- Retrieve (Truy xuất): Tìm kiếm hỗn hợp trả về 20 ứng viên, cân bằng giữa độ tương đồng ngữ nghĩa và các khớp thuật ngữ chính xác.
- Rerank (Tái xếp hạng): Một cross-encoder thu hẹp danh sách xuống còn 5 đoạn văn triển vọng nhất.
- Generate (Tạo lập): LLM nhận các đoạn văn hàng đầu này cùng với siêu dữ liệu (metadata) của chúng để soạn thảo câu trả lời cuối cùng.
- Evaluate (Đánh giá): Mọi phản hồi đều được ghi nhật ký; các lỗi được đưa ngược lại vào tập kiểm thử 200 truy vấn.
Các rủi ro và sự đánh đổi
Một pipeline được tinh chỉnh tốt giúp giảm thiểu hiện tượng ảo giác, cải thiện độ liên quan của câu trả lời và cắt giảm chi phí cho các mô hình được cấp phát quá mức. Lợi ích mang lại là sự hài lòng của người dùng cao hơn và chi phí vận hành hỗ trợ thấp hơn. Việc bỏ qua các bước này sẽ tạo ra một dịch vụ kém ổn định, làm xói mòn niềm tin vào thương hiệu và buộc bạn phải tốn kém chi phí để xử lý các sự cố phát sinh.
Những gì cần theo dõi tiếp theo
Khi các embedding mã nguồn mở và cơ sở dữ liệu vector trở nên hoàn thiện hơn, ranh giới giữa truy xuất "dày" (dense) và "thưa" (sparse) sẽ dần mờ nhạt, nhưng nguyên tắc kết hợp giữa khớp ngữ nghĩa và khớp chính xác vẫn không thay đổi.
Bài học rút ra: Trong một hệ thống RAG, mô hình ngôn ngữ hiếm khi là điểm nghẽn. Công việc thực sự nằm ở cách bạn phân tách, lập chỉ mục và hiển thị nội dung nền tảng. Đưa ra những quyết định đúng đắn về các yếu tố này sẽ biến một bản demo hào nhoáng thành một sản phẩm đáng tin cậy.