Thực hànhTrung cấp

Query rewriting: viết lại câu hỏi để tìm đúng hơn

Biến câu hỏi phụ thuộc hội thoại thành truy vấn rõ nghĩa, giữ nguyên ràng buộc và đo xem viết lại có thật sự cải thiện truy xuất không.

Trong bài viết này

Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.

Người dùng hỏi: “Gói học buổi tối có được nghỉ bù không?” Sau câu trả lời, họ hỏi tiếp: “Thế cuối tuần thì sao?” Nếu gửi riêng câu thứ hai vào tìm kiếm, hệ thống không biết đang tìm lịch học, chính sách nghỉ bù hay giờ mở cửa. Viết lại truy vấn giúp mang phần ngữ cảnh cần thiết tới bộ tìm kiếm.

Viết lại để tìm, không phải để trả lời trước

Query rewriting tạo một truy vấn phù hợp hơn với công việc truy xuất. Nó có thể giải quyết đại từ, bổ sung đối tượng đã xuất hiện trong hội thoại hoặc chuyển một câu dài thành các nhu cầu tìm cụ thể. Kết quả vẫn là câu hỏi cần tìm căn cứ, chưa phải đáp án.

Công trình Query Rewriting for Retrieval-Augmented Large Language Models nghiên cứu chuỗi Rewrite–Retrieve–Read để xử lý khoảng cách giữa lời hỏi và thông tin cần truy xuất. Đây là cơ sở cho ý tưởng có một bước sửa truy vấn; hiệu quả trong một kho tài liệu riêng vẫn cần được kiểm tra.

Trong hội thoại trên, truy vấn mong muốn có thể là “Chính sách nghỉ bù cho gói học cuối tuần”. Truy vấn sai là “Gói cuối tuần được nghỉ bù bao nhiêu buổi?”, vì nó đã giả định được nghỉ bù trước khi có tài liệu xác nhận.

Giữ các ràng buộc quan trọng nguyên vẹn

Việc viết lại không được làm mất phủ định, mốc thời gian hoặc tên sản phẩm. Câu “không tính khóa đã khai giảng” không thể thành “các khóa đã khai giảng”. Những chi tiết này thường quyết định tập tài liệu cần xét.

Bạn có thể yêu cầu đầu ra có cấu trúc để dễ kiểm tra. Ví dụ minh họa:

Đối tượng: gói học cuối tuần
Nhu cầu: điều kiện nghỉ bù
Ràng buộc: chỉ dùng quy định đang có hiệu lực
Chưa rõ: cơ sở học, nếu quy định khác theo cơ sở
Truy vấn: chính sách nghỉ bù gói học cuối tuần

Nếu hội thoại chưa xác định cơ sở mà tài liệu phụ thuộc cơ sở, không nên tự chọn một địa điểm. Hệ thống có thể tìm quy định chung trước hoặc cần làm rõ phần thiếu, tùy thiết kế sản phẩm.

Nhìn để hiểuBốn phần của một yêu cầu rõ ràng

Một prompt dễ kiểm tra nêu nhiệm vụ, cung cấp ngữ cảnh, đặt giới hạn và quy định đầu ra. Sau đó thử trên các ví dụ thật để xem mô hình có đáp ứng hay không.

Ghép bốn phần của một prompt rõ ràngMột tờ giao việc có bốn phần: mục tiêu tóm tắt cho người vắng mặt, ngữ cảnh là ghi chú được cung cấp, giới hạn không tự điền dữ kiện thiếu, và đầu ra gồm quyết định, người thực hiện, hạn chót. Đây là ví dụ biên soạn, không bảo đảm mô hình luôn làm đúng.1Mục tiêuTóm tắt cho người vắng mặt2Ngữ cảnhDùng ghi chú đã cung cấp3Giới hạnThiếu dữ kiện → ghi “chưa rõ”4Đầu raQuyết định · người làm · hạn chót

↔ Vuốt ngang để xem toàn bộ sơ đồ.

  1. 01 / Nhiệm vụ

    Nêu công việc cụ thể: chẳng hạn viết lại thông báo kỹ thuật cho người dùng phổ thông.

  2. 02 / Ngữ cảnh

    Cung cấp thông báo gốc và nói rõ ai sẽ đọc, họ cần biết điều gì.

  3. 03 / Giới hạn

    Yêu cầu giữ nguyên mốc giờ, tên tính năng và con số; không tự thêm thông tin thiếu căn cứ.

  4. 04 / Định dạng đầu ra

    Quy định tiếng Việt, tối đa 120 từ, nêu hành động cần làm và đánh dấu phần còn thiếu.

Đây là khung soạn yêu cầu, không phải công thức bảo đảm đầu ra đúng. Các giới hạn về quyền và bảo mật phải được thực thi trong ứng dụng.

Hình minh họa việc làm rõ đầu vào và yêu cầu đầu ra. Nó không đo được chất lượng truy xuất sau viết lại; phần đó cần một bộ câu hỏi có đáp án đối chiếu.

Giữ truy vấn gốc làm đối chứng

Viết lại thêm một bước suy diễn nên cũng tạo thêm cơ hội sai. Một từ viết tắt nội bộ có thể bị mở rộng nhầm; mã lớp học có thể bị sửa thành từ phổ biến. Vì vậy, hãy lưu truy vấn gốc cùng bản viết lại và lý do chọn ngữ cảnh.

Một phương án thử là tìm bằng cả hai rồi hợp nhất kết quả. Đổi lại, số lượt truy xuất và lượng ứng viên tăng lên. Không nên áp cách này mặc định nếu câu hỏi đã rõ và tìm kiếm gốc hoạt động tốt.

Cũng cần giới hạn lịch sử hội thoại được dùng. Một chi tiết ở lượt rất cũ có thể không còn liên quan sau khi người dùng đổi chủ đề. Bước viết lại nên dựa vào ngữ cảnh cần thiết, không biến mọi điều từng xuất hiện thành ràng buộc cho câu hỏi mới.

Bài tập: phát hiện truy vấn làm đổi ý định

Viết năm hội thoại ngắn về lớp học: hai câu hỏi tiếp nối, một câu có phủ định, một câu chứa mã lớp và một câu chuyển chủ đề. Ghi trước truy vấn độc lập mà người đọc có thể hiểu đúng.

So sánh bản viết lại với bản mong muốn trước khi chạy tìm kiếm. Sau đó kiểm tra nguồn cần thiết có xuất hiện trong các kết quả đầu hay không. Tách lỗi “viết lại đổi nghĩa” khỏi lỗi “viết đúng nhưng tìm sai”.

Tiêu chí đạt là giữ nguyên mã và phủ định, không thêm giả định về quyền lợi, nhận ra câu chuyển chủ đề và tìm được căn cứ cho câu hỏi tiếp nối. Một bản viết lại dài hơn hoặc trau chuốt hơn chưa phải thành công nếu nó khiến hệ thống trả lời một câu hỏi khác.

Bạn muốn hiểu điều gì?

Khám phá tất cả bài viết esc để đóng