Mistral Agentic Search: khi RAG một lượt không đủ bằng chứng

Mistral Agentic Search nên được thêm vào khi kết quả truy xuất đầu tiên mới chỉ xác định nguồn có liên quan, nhưng chưa đủ bằng chứng để trả lời. Nếu một chunk trong nhóm top-k đã chứa câu trả lời hoàn chỉnh, RAG một lượt vẫn là lựa chọn gọn hơn: ít lần gọi công cụ, độ trễ dễ dự đoán và luồng vận hành đơn giản hơn.

Cách dùng thực tế là dựng chỉ mục có thể điều hướng, cho tác nhân lặp có giới hạn qua các thao tác tìm, mở nguồn, dò từ khóa và đọc vùng liên quan. Không nên áp dụng vòng lặp này cho mọi truy vấn; hãy định tuyến theo cấu trúc câu hỏi, chống đọc lại chunk cũ và so sánh hai phương án trên cùng corpus nội bộ.

Cây quyết định: one-shot RAG hay Agentic Search

Điểm phân nhánh nằm ở vị trí của bằng chứng, không nằm ở độ dài câu hỏi. Giữ one-shot RAG khi câu trả lời thường xuất hiện trọn vẹn trong một đoạn, nguồn và vị trí gần như đã biết, hoặc hệ thống chỉ cần trả về đoạn liên quan với lưu lượng lớn.

Chuyển sang Agentic Search khi cần mở rộng vùng lân cận của một kết quả, theo tham chiếu trong tài liệu dài, đọc bảng cùng tiêu đề và chú thích, hoặc nối dữ kiện từ nhiều nguồn. Đây chính là các trường hợp mà phần giới thiệu của Mistral đối chiếu với one-shot RAG: lượt đầu có thể tìm đúng tài liệu nhưng chưa tìm đủ phần cần thiết để trả lời.

Có thể định tuyến bằng ba câu hỏi: top-k đã chứa câu trả lời hoàn chỉnh chưa; từng vế của câu hỏi có nằm ở nhiều vị trí không; và câu trả lời có cần dẫn về vị trí nguồn cụ thể không. Nếu câu đầu là “có” còn hai câu sau là “không”, một lượt thường đủ. Nếu tác nhân phải dùng thông tin vừa đọc để quyết định tìm gì tiếp theo, hãy chuyển sang vòng agentic có ngân sách.

Vòng tìm–mở–grep–đọc thu thập bằng chứng ra sao

search tìm chunk liên quan trên toàn corpus; kết quả này là điểm xuất phát chứ chưa nhất thiết là bằng chứng cuối. open mở rộng ngữ cảnh quanh chunk theo thứ tự đọc, còn navigate đưa tác nhân tiến hoặc lùi trong cùng nguồn.

Khi đã biết mã điều khoản, thuật ngữ hoặc cụm từ chính xác, grep tìm trong một tài liệu cụ thể thay vì tiếp tục tìm rộng. read lấy nội dung từ khoảng nguồn đã xác định. Chỉ nên quay lại search toàn corpus khi phần vừa đọc tạo ra một truy vấn tốt hơn hoặc cho thấy bằng chứng còn nằm ở nguồn khác.

Tài liệu Agentic Search mô tả search, open, navigate, read và grep, đồng thời yêu cầu truyền exclude_ids ở lượt tìm tiếp để các chunk đã xem không xuất hiện lại. Khả năng điều hướng cần NavigableIndex và chế độ DOCUMENT_PER_CHUNK, nhờ đó mỗi chunk giữ vị trí nguồn và có thể được đọc theo thứ tự.

Dựng phép thử bằng starter app

Starter app yêu cầu Mistral API key, Docker để chạy Vespa, uv, Copier và một tác nhân tương thích MCP. Tạo dự án bằng uvx copier copy gh:mistralai/search-starter-app my-search-project, chuyển vào thư mục vừa tạo, rồi chạy make setup-vespa. Template dựng pipeline nạp dữ liệu, chỉ mục Vespa và máy chủ MCP cung cấp các công cụ truy xuất.

1. Chọn một corpus nhỏ nhưng đại diện: tài liệu ngắn, tài liệu dài, bảng và ít nhất một câu hỏi phải nối bằng chứng từ hai vị trí.
2. Viết trước đáp án chuẩn và vị trí nguồn cho từng mệnh đề; không dùng chính mô hình đang được thử để tự tạo toàn bộ đáp án chấm.
3. Chạy cùng bộ câu hỏi qua one-shot RAG và vòng agentic, giữ nguyên corpus, mô hình, cấu hình chỉ mục và tiêu chí chấm.
4. Lưu chuỗi gọi công cụ, chunk đã đọc, nguồn được trích dẫn, câu trả lời cuối, độ trễ và lượng token.

Đây là phép thử chấp nhận trên dữ liệu của tổ chức, không phải benchmark độc lập cho Mistral Agentic Search. Kết quả cần cho biết lớp câu hỏi nào được cải thiện và phần chi phí bổ sung có phù hợp với yêu cầu vận hành hay không.

Chống lặp và đặt điều kiện dừng

Giới hạn vòng lặp ở cả số hop, số chunk mỗi hop, tổng ngữ cảnh, thời gian và số lần gọi công cụ. Có thể dừng khi mọi vế của câu hỏi đã có bằng chứng, khi các hop liên tiếp không bổ sung nguồn mới hoặc khi hệ thống chạm ngân sách đã đặt.

Không nên chỉ dựa vào lời nhắc yêu cầu tác nhân “đừng lặp lại”. Ứng dụng cần lưu source_id và chunk ID đã xem, chuẩn hóa các truy vấn gần trùng, dùng exclude_ids và ghi nhận phần bằng chứng mới do mỗi hop mang lại.

Một phân tích 14,44 triệu lượt tìm kiếm agentic trên DeepResearchGym nhận thấy mức lặp cao trong các phiên tìm dữ kiện và đề xuất dừng sớm có nhận biết lặp, ngân sách theo ý định cùng việc theo dõi ngữ cảnh xuyên suốt các bước. Đây là quan sát về hành vi tìm kiếm nhiều lượt nói chung, không phải đánh giá riêng sản phẩm của Mistral.

Độ sâu cũng không nên cố định cho mọi câu hỏi. Nếu tác nhân thường xuyên hết ngân sách mà vẫn thiếu bằng chứng, hãy kiểm tra lại trích xuất, cách chia chunk, metadata và chất lượng truy xuất nền trước khi tăng số vòng.

Đánh giá trên corpus riêng, không vay kết luận từ benchmark hãng

Mistral công bố kết quả FinanceBench và OfficeQA Pro cho cấu hình Search Toolkit của hãng, với các mô hình, corpus và cách chấm được mô tả trong bài giới thiệu. Những số liệu đó là tuyên bố benchmark của Mistral, không chứng minh rằng một hệ thống nội bộ sẽ đạt mức cải thiện tương tự.

Phép đánh giá nội bộ nên tách bốn lớp: khả năng tìm đúng nguồn, mức hỗ trợ bằng chứng cho từng mệnh đề, độ chính xác của câu trả lời cuối và chi phí vận hành. Một câu trả lời đúng nhưng thiếu nguồn cho một vế vẫn là lỗi bằng chứng, còn một lượt tìm được tài liệu đúng nhưng không mở được vùng chứa điều khoản chưa phải là truy xuất thành công.

Quyết định triển khai nên dựa trên chênh lệch giữa hai nhánh trong cùng điều kiện. Nếu vòng agentic chỉ cải thiện câu hỏi nhiều hop hoặc cần xác minh nguồn, hãy đặt bộ định tuyến trước khâu truy xuất và giữ các tra cứu trực tiếp ở one-shot RAG. Khi đó, chi phí nhiều lượt chỉ phát sinh ở nơi nó thực sự mua thêm bằng chứng.