Đo lường khả năng truy xuất dữ liệu doanh nghiệp 'lộn xộn' cho các tác nhân AI

Cách các đội ngũ truy xuất dữ liệu đang thay đổi rất nhanh trên mọi lĩnh vực. Cursor mới đây đã ngừng tìm kiếm mã nguồn bằng embedding mà chuyển sang chỉ dùng grep và tìm kiếm có chỉ mục. Nhiều nơi khác cũng đang thay thế các bộ xếp hạng lại (reranker) truyền thống bằng những mô hình mới như Jev.

Một trong những loại tri thức quan trọng nhất mà các tác nhân AI (agent) dựa vào là tri thức doanh nghiệp: tài liệu, ticket, tin nhắn chat, wiki nội bộ và mã nguồn. Thế nhưng hầu hết các đội ngũ không thể biết cách truy xuất nào là tốt nhất, bởi họ không có cách nào đo lường hiệu quả truy xuất trên dữ liệu thật.

Kapa là một nền tảng giúp lập chỉ mục tri thức doanh nghiệp và cho phép các tác nhân tìm kiếm chúng để lấy ngữ cảnh. Bạn kết nối các nguồn dữ liệu, Kapa biến chúng thành một cơ sở tri thức có thể tìm kiếm, và bất kỳ tác nhân nào cũng có thể truy vấn để lấy thông tin cần thiết. Truy xuất chính là lõi sản phẩm của Kapa, và họ thay đổi cách làm liên tục.

Company Knowledge Bench là gì?

Company Knowledge Bench là bộ công cụ mà Kapa tự xây dựng để cải thiện hệ thống của chính mình: 1.000 ca kiểm thử (eval case) được gán nhãn từ dữ liệu sản xuất thật. Bài viết này giải thích cách nó hoạt động và chấm điểm một vài cách triển khai truy xuất phổ biến.

Kết quả đáng chú ý: một mô hình tiên tiến chỉ với grep đạt 0,61 điểm, ngang bằng một pipeline truy xuất hiện đại đã được tinh chỉnh, nhưng mất thời gian gấp năm lần. Một bộ truy xuất tác nhân tối ưu (Kapa Deep) còn làm tốt hơn: 0,65 điểm trong khoảng năm giây.

Cần lưu ý về yếu tố thiên lệch: truy xuất là lõi sản phẩm của Kapa, và cả bảy bộ truy xuất đều do chính họ xây dựng, sử dụng tài liệu được nạp qua pipeline của họ.

Các benchmark công khai không phù hợp với Kapa vì không có bộ nào bao quát hết mọi trường hợp sử dụng và kiểu truy vấn mà họ gặp.

Vì sao cần benchmark riêng cho tri thức doanh nghiệp?

Các đội ngũ lập chỉ mục nguồn dữ liệu trong Kapa rồi kết nối một tác nhân với hệ truy xuất, và tác nhân đó phục vụ những trường hợp sử dụng rất khác nhau, mỗi trường hợp có tài liệu riêng và người hỏi riêng:

• Lập trình viên hỏi về sản phẩm qua tài liệu, đặc tả API, mã nguồn và GitHub issue, thường thông qua Claude Code.
• Nhân viên kinh doanh hỏi về sản phẩm, quy trình và khách hàng qua Slack, Confluence, Notion và Google Drive.
• Đội hỗ trợ soạn phản hồi cho ticket mới dựa trên ticket cũ, bài viết trung tâm trợ giúp và sổ tay nội bộ.

Các kiểu truy vấn cũng rất đa dạng tùy theo người viết:

• Người dùng thường gộp tất cả vào một tin nhắn: nhiều câu hỏi, một đoạn lỗi dán vào, một tham chiếu đến điều đã nói trước đó.
• Các tác nhân như Claude Code lại tự viết truy vấn, chia một câu hỏi phức tạp thành những tìm kiếm ngắn gọn, chính xác, chẳng hạn như webhook retry backoff config.

Các benchmark truy xuất công khai phần lớn quá hẹp, chỉ xoay quanh một lĩnh vực như luật hay y tế, hoặc quá nhân tạo, được dựng từ tài liệu và câu hỏi tổng hợp. Không bộ nào bao quát được phạm vi này, nên Kapa tự xây dựng bộ của riêng mình.

Định nghĩa "truy xuất tốt"

Trước khi đo lường truy xuất tốt, cần định nghĩa nó là gì. Một vài thuật ngữ:

• Truy vấn (query): nội dung được gửi đến bộ truy xuất.
• Kho ngữ liệu (corpus): toàn bộ những gì một đội ngũ đã lập chỉ mục trong Kapa.
• Đoạn (chunk): một mẩu ngắn của kho ngữ liệu, chẳng hạn một phần của trang.
• Bộ truy xuất (retriever): nhận một truy vấn và trả về những đoạn liên quan nhất từ kho ngữ liệu.

Mục tiêu của bộ truy xuất là thu thập một tập đoạn tối thiểu nhưng trả lời trọn vẹn truy vấn, sử dụng những nguồn chất lượng cao nhất hiện có.

Company Knowledge Bench dựa trên ba thuộc tính:

• Tính đầy đủ. Tác nhân nhận các đoạn này không cần gì thêm để trả lời truy vấn. Nếu tập hợp thiếu, tác nhân sẽ đưa ra câu trả lời thiếu hoặc sai.
• Tính tối thiểu. Bỏ bất kỳ đoạn nào cũng khiến tập hợp trở nên thiếu hụt. Những đoạn thừa không cần thiết vừa tốn tiền vừa khiến mô hình khó suy luận hơn.
• Ưu tiên nguồn. Một kho ngữ liệu thường chứa nhiều tập đoạn có thể trả lời cùng một truy vấn, và chúng gần như không bao giờ có chất lượng ngang nhau. Benchmark chỉ chấp nhận những nguồn được ưu tiên.

Việc quyết định nguồn nào được ưu tiên rất khó và có nhiều vùng xám, nhưng nhìn chung quy về hai yếu tố:

• Thẩm quyền nguồn (source authority). Một trang tham chiếu chuyên dụng xếp trên một bài hướng dẫn, một luồng issue, hay một bài blog lặp lại cùng thông tin.
• Tính thời sự (currency). Nguồn hiện hành xếp trên nguồn lỗi thời. Một luồng Slack từ tuần trước thắng một trang Confluence sửa lần cuối ba năm trước.

Ngoài ra còn có các quy tắc cho những tình huống cụ thể:

• Truy vấn mơ hồ. Bộ truy xuất phải trả về các đoạn cho mọi cách hiểu hợp lý. Việc chọn một cách hiểu là nhiệm vụ của tác nhân.
• Vấn đề có nhiều cách giải hợp lệ. Bộ truy xuất phải trả về các đoạn cho từng giải pháp đã được ghi nhận, để tác nhân có thể trình bày các lựa chọn và đánh đổi của chúng.
• Kho ngữ liệu không có gì trả lời truy vấn. Bộ truy xuất phải trả về bằng chứng mạnh nhất hiện có: một tuyên bố rằng tính năng không được hỗ trợ, một danh sách đầy đủ mà tính năng đó không nằm trong, hoặc một cách xử lý vòng đã được ghi nhận. Nếu không có gì trong số đó, kết quả đúng là không trả về gì cả.

Tất cả những điều này được ghi chép chính xác trong sổ tay gán nhãn của benchmark.

Cấu trúc của một ca kiểm thử

Benchmark là một tập hợp các ca kiểm thử. Mỗi ca gồm một truy vấn sản xuất thật, một ảnh chụp kho ngữ liệu tại thời điểm truy vấn được đặt ra, và một tiêu chí truy xuất: một biểu thức logic xác định những đoạn nào trong kho ngữ liệu là hợp lệ để lấy về.

Ví dụ đơn giản: tiêu chí yêu cầu chunk_1 và chunk_2, cả hai đều được trả về → đạt. Độ chính xác (precision) là 2 trên 4, tức 50%, vì chunk_3 và chunk_4 không nằm trong tiêu chí.

Bài đăng trên diễn đàn không nằm trong tiêu chí vì lý do ưu tiên nguồn: nó trả lời cùng phần truy vấn như trang giá (pricing page) — gói nào bao gồm SSO — nhưng trang giá có thẩm quyền nguồn cao hơn. Bản changelog thì đơn giản là không liên quan. Cả hai đều bị trừ vào độ chính xác, nhưng vì lý do khác nhau: một cái không liên quan, cái kia liên quan nhưng không được ưu tiên.

Tổng cộng Kapa tạo ra 1.000 ca kiểm thử cho Company Knowledge Bench, và đây là cơ sở cho các kết quả trong bài.

Gán nhãn quy mô lớn bằng tác nhân AI

Gán nhãn thủ công một nghìn ca kiểm thử là điều bất khả thi. Lấy mẫu cho đúng còn khó hơn: các truy vấn đến từ mọi loại nguồn mà Kapa nạp vào, cả kho ngữ liệu nội bộ lẫn công khai, cùng mọi ngành họ phục vụ. Để đạt quy mô này, việc gán nhãn phải do tác nhân AI thực hiện.

Tất nhiên, để tác nhân tạo benchmark chỉ hiệu quả nếu chúng làm đúng. Một tiêu chí sai đồng nghĩa với điểm sai cho mọi bộ truy xuất được kiểm tra. Vì vậy, trước khi tác nhân có thể xây dựng benchmark, cần một benchmark thứ hai đo lường mức độ chúng xây dựng benchmark tốt đến đâu: một benchmark để tạo benchmark.

Benchmark thứ hai đó là tập 170 ca kiểm thử được con người gán nhãn hoàn toàn thủ công, theo cùng sổ tay gán nhãn. Quy trình là: xây dựng tác nhân làm được cùng nhiệm vụ mà con người đã làm, chạy chúng trên các truy vấn đó, rồi so sánh tiêu chí chúng viết với tiêu chí của con người. Kapa liên tục cải thiện cho đến khi tác nhân đạt mức đồng thuận đủ cao với người gán nhãn. Chỉ khi đó họ mới để chúng tạo 1.000 ca kiểm thử từ truy vấn sản xuất.

Việc gán nhãn chia cho hai loại tác nhân:

• Tác nhân ứng viên quét toàn bộ kho ngữ liệu để tìm những đoạn có thể thuộc tiêu chí. Chúng được xây dựng để tối đa hóa khả năng hồi tưởng (recall) và trả về một tập lớn các đoạn có khả năng liên quan.
• Tác nhân tiêu chí nhận các ứng viên đó và biến chúng thành tiêu chí truy xuất thực sự, theo các quy tắc trong sổ tay.

Các tác nhân không cần tái tạo chính xác tiêu chí của con người, nhưng phải đến gần. Để đạt được điều đó cần nhiều vòng lặp, cả trên tác nhân lẫn trên chính sổ tay.

Bảy bộ truy xuất được thử nghiệm

Kapa chạy bảy bộ truy xuất trên Company Knowledge Bench. Tất cả đều tìm kiếm cùng kho ngữ liệu, được nạp và chia đoạn theo cùng cách, nên điểm khác biệt duy nhất là chiến lược truy xuất.

Nhóm RAG truyền thống — chạy cùng các bước cho mọi truy vấn, không có mô hình nào quyết định bước tiếp theo:

• Tìm kiếm lai (hybrid search). Điểm khởi đầu của hầu hết pipeline RAG. Truy vấn được đối chiếu đồng thời với chỉ mục từ khóa và chỉ mục embedding, dùng gemini-embedding-001, trả về 15 đoạn hàng đầu.
• Tìm kiếm lai kèm reranker. Vẫn tìm kiếm như trên nhưng lấy 100 đoạn hàng đầu và đưa qua reranker (rerank-2 của Voyage AI), giữ lại 15 đoạn tốt nhất.
• Phân rã truy vấn, tìm kiếm lai và reranker. Trước khi tìm, một mô hình (gpt-6.1-luna) chia truy vấn thành tối đa ba truy vấn con, mỗi truy vấn con lấy 50 đoạn qua tìm kiếm lai, gộp lại rồi xếp hạng lại còn 15 đoạn.

Nhóm tác nhân (agentic) — mô hình dẫn dắt việc tìm kiếm, quyết định tìm gì tiếp theo và khi nào đã đủ:

• Agentic grep với mô hình lớn. gpt-6.1-sol với một công cụ duy nhất: tìm kiếm toàn văn và regex trên các đoạn. Không dùng embedding, giống cách một tác nhân lập trình khám phá kho mã nguồn.
• Agentic grep với mô hình nhỏ. Cùng thiết lập nhưng dùng gpt-6.1-luna, mô hình nhỏ và nhanh hơn, để xem sức mạnh mô hình quan trọng đến đâu.
• Default mode. Chế độ nhanh của Kapa: pipeline cố định với một bước lập kế hoạch nhỏ và ngân sách nghiêm ngặt, trả về số đoạn tốt nhất cố định.
• Deep mode. Tác nhân truy xuất của Kapa: tìm kiếm, đọc sâu trong tài liệu đã tìm thấy, loại bỏ những gì hóa ra không liên quan, trả về đúng số đoạn mà truy vấn cần.

Việc so sánh dựa trên bốn chiều: điểm truy xuất, độ trễ, độ chính xác và số token trả về. Một bộ truy xuất điểm cao vẫn có thể quá chậm để đưa cho người dùng, hoặc trả về quá nhiều khiến tác nhân đọc phải trả giá ở mỗi lần gọi.

Những kết quả đáng chú ý

Reranker là cú hích lớn với chi phí rẻ nhất. Tìm kiếm lai thuần đạt 0,41. Lấy 100 ứng viên rồi xếp hạng lại còn 15 nâng lên 0,50, chỉ tốn thêm một phần ba giây, không tăng token, và một lần gọi reranker rẻ hơn nhiều so với gọi mô hình ngôn ngữ. Nếu chỉ thay đổi một thứ trong pipeline RAG cơ bản, hãy thêm reranker.

Tìm kiếm bằng nhiều truy vấn giúp ích, nhưng có giá. Chia truy vấn thành các truy vấn con nâng điểm lên 0,56, nhưng độ trễ tăng hơn gấp đôi lên 1,8 giây, cộng thêm chi phí gọi mô hình cho mỗi truy vấn.

Pipeline cố định được tối ưu đi được khá xa. Kapa Default đạt 0,61 trong 3,3 giây — ngang điểm tác nhân grep mạnh nhất nhưng chỉ bằng một phần năm thời gian, với độ chính xác tốt nhất trong các pipeline cố định.

Mô hình mạnh với công cụ đơn giản đi được rất xa. Đưa một mô hình suy luận vào truy xuất hoạt động tốt, kể cả khi công cụ duy nhất là grep. gpt-6.1-sol đạt 0,61, ngang Kapa Default; gpt-6.1-luna nhỏ hơn đạt 0,54, gần bằng mức phân rã truy vấn.

Với bộ truy xuất tác nhân, trí tuệ mô hình rất quan trọng. Đổi gpt-6.1-sol sang gpt-6.1-luna mất 0,07 điểm. Phân rã truy vấn — một pipeline cố định — thắng tác nhân dùng mô hình nhỏ về điểm số với thời gian chỉ bằng một phần bảy. Vòng lặp tác nhân không tự động tốt hơn.

Điểm trừ lớn nhất của bộ truy xuất tác nhân là chi phí. Nó thể hiện ở độ trễ — các tác nhân grep mất 13 đến 17 giây mỗi truy vấn — và ở tiền bạc theo hai hướng:

• Chi phí của chính bộ truy xuất. Tác nhân grep dùng gpt-6.1-sol tiêu tốn khoảng 0,17 USD tiền gọi mô hình mỗi truy vấn, ở quy mô sản xuất có thể quá đắt.
• Chi phí của những gì nó trả về. Mỗi đoạn lấy ra trở thành token đầu vào cho tác nhân nhận kết quả. Các tác nhân grep trả về khoảng 40.000 token mỗi truy vấn, gấp khoảng bốn lần mọi pipeline cố định, trong khi chỉ một phần hai mươi lăm đoạn là thực sự cần thiết.

Bộ truy xuất tác nhân tối ưu gom được ưu điểm của cả hai. Có thể xem Kapa Deep là một bộ truy xuất tác nhân tối ưu, được thiết kế để chỉ trả về những gì truy vấn cần. Nó có điểm cao nhất — 0,65 trong khoảng năm giây — và độ chính xác cao nhất, 0,26 so với 0,12 hoặc thấp hơn ở mọi bộ khác. Nó trả về khoảng 5.000 token mỗi truy vấn, bằng một nửa mọi pipeline cố định và một phần tám so với các tác nhân grep, qua đó cũng là lựa chọn rẻ nhất cho tác nhân đọc, khoảng 10 USD cho mỗi 1.000 truy vấn.

Ý nghĩa với doanh nghiệp Việt Nam

Với các doanh nghiệp Việt Nam đang bắt đầu triển khai trợ lý AI nội bộ trên kho tri thức phân tán — từ Slack, Google Drive cho đến Confluence và các hệ thống ticket — bài học từ benchmark này khá thực tế:

• Chỉ số quan trọng không chỉ là độ chính xác. Độ trễ và chi phí token trên mỗi truy vấn cũng quyết định liệu giải pháp có khả thi khi mở rộng cho toàn bộ nhân viên hay không.
• Thêm reranker là bước tối ưu rẻ nhất nếu đang vận hành pipeline RAG cơ bản.
• Không nên mặc định chọn tác nhân AI phức tạp. Một pipeline cố định được tinh chỉnh tốt có thể đạt điểm tương đương với chi phí và độ trễ thấp hơn nhiều.

Benchmark này được giữ kín vì xây dựng từ dữ liệu sản xuất thật. Kapa cho biết sẽ tiếp tục mở rộng benchmark và cải thiện đồng thời cả ba tiêu chí: độ chính xác, độ trễ và chi phí.