Hầu hết các đội ngũ vẫn xây dựng pipeline truy xuất đầu tiên theo cùng một cách. Họ chọn một giới hạn token cố định, có thể là 512, chia tài liệu thành các khối đồng nhất và đưa các khối đó vào cơ sở dữ liệu vector. Với một tập dữ liệu nhỏ và các câu hỏi đơn giản, điều này trông có vẻ thần kỳ. Nhưng khi đưa vào vận hành thực tế (production), nó sẽ đổ vỡ.
Các hợp đồng pháp lý bị xé nhỏ thành những mảnh vụn vô nghĩa khi một điều khoản bị cắt ngang giữa câu. Tài liệu API trở thành một mớ hỗn độn nhiễu loạn nếu một chunk duy nhất nuốt trọn ba hàm không liên quan. Các phiếu hỗ trợ khách hàng (support tickets) mất đi toàn bộ mạch nội dung nếu không có sự chồng lấp (overlap) giữa các phân đoạn. Kết quả là điều có thể dự đoán trước: độ trễ tăng cao, khả năng truy hồi (recall) yếu và các câu trả lời buộc mô hình tạo (generator) phải ảo giác (hallucinate).
Chúng tôi đã tháo dỡ lớp truy xuất của mình và xây dựng lại từ đầu. Kết quả là khả năng truy hồi tăng vọt từ 78% lên 95%, độ trễ giảm 62%, và một pipeline cuối cùng đã hoạt động như một hạ tầng thực thụ thay vì một bản chắp vá làm qua loa vào cuối tuần. Dưới đây là những gì thực sự hiệu quả.
Chunking Thông minh: Ưu tiên Cấu trúc hơn Token
Sai lầm đầu tiên là giả định rằng mọi tài liệu đều có cùng một ngôn ngữ. Một chunk 512 token có thể hợp lý đối với văn xuôi tự sự nhưng hầu như không phù hợp ở bất kỳ đâu khác. Chúng tôi đã chuyển sang một chiến lược tôn trọng cấu trúc (anatomy) của nguồn dữ liệu.
Đối với các tài liệu pháp lý, chúng tôi sử dụng recursive chunking (chia nhỏ đệ quy). Thuật toán trước tiên sẽ cố gắng chia theo các ranh giới cấp cao như các phần (sections) và điều khoản (articles). Nếu một phần vẫn còn quá dài, nó sẽ tìm đến các tiểu mục, sau đó là các đoạn văn, rồi đến các câu. Điều này giúp bảo toàn tính lồng ghép logic của các điều khoản. Một thỏa thuận không cạnh tranh sẽ được giữ nguyên vẹn. Các định nghĩa không bị lẫn sang các điều khoản bồi thường.
Tài liệu API đòi hỏi chunking nhận biết cấu trúc (structure-aware chunking). Một chữ ký hàm (function signature), bảng tham số của nó và một yêu cầu ví dụ (example request) phải đi cùng nhau. Việc chia nhỏ sau một số lượng token cố định thường để lại các tham số ở một chunk và các ví dụ ở một chunk khác. Thay vào đó, chúng tôi chia nhỏ theo đối tượng tài liệu (document object). Một chunk sẽ chứa một endpoint hoàn chỉnh hoặc một hàm duy nhất. Khi đó, bộ truy xuất có thể trả về một tham chiếu độc lập, thực sự trả lời được câu hỏi.
Các phiếu hỗ trợ khách hàng về bản chất rất phù hợp với semantic chunking (chia nhỏ theo ngữ nghĩa). Thay vì cắt tại ranh giới token, chúng tôi phát hiện nơi chủ đề thay đổi. Một phiếu hỗ trợ bắt đầu bằng khiếu nại về đăng nhập và chuyển sang câu hỏi về thanh toán sẽ được chia thành hai phần mạch lạc. Mỗi phần đều mang theo siêu dữ liệu (metadata) cần thiết, và mô hình không còn phải đoán xem người dùng thực sự quan tâm đến vấn đề nào.
Các wiki nội bộ thì lộn xộn hơn. Chúng trộn lẫn văn xuôi, bảng biểu, sơ đồ và các luồng thảo luận được nhúng vào. Đối với những loại này, chúng tôi sử dụng agentic chunking. Một mô hình ngôn ngữ nhỏ sẽ đọc trước và quyết định nơi một đơn vị hoàn chỉnh về mặt chủ đề kết thúc. Việc này tốn kém hơn một chút tại thời điểm nạp dữ liệu (ingestion time), nhưng nó loại bỏ công việc thủ công là phải tinh chỉnh các quy tắc cho từng định dạng trang mới.
Truy xuất Hybrid: Bao quát mọi khía cạnh
Tìm kiếm vector (vector search) rất xuất sắc trong việc nắm bắt ý nghĩa mơ hồ. Nếu bạn hỏi về việc tải lên chậm, nó sẽ vui vẻ trả về các đoạn văn về độ trễ và băng thông. Nhưng nó cũng nổi tiếng với việc làm sai lệch các kết quả khớp chính xác. Nếu một nhà phát triển tìm kiếm mã lỗi ERR_CONNECTION_REFUSED, các dense embeddings thường sẽ coi đó là nhiễu thông thường.
BM25, thuật toán từ khóa kinh điển, lại làm điều ngược lại. Nó nắm bắt chính xác các chuỗi ký tự và các thuật ngữ hiếm, nhưng lại bỏ lỡ các sắc thái ngữ nghĩa. Một truy vấn về việc ký kết thỏa thuận (signing the agreement) có thể không bao giờ hiển thị nội dung được gắn thẻ là thực thi hợp đồng (executing the contract).