Hybrid search cho RAG: tìm đúng mã hàng và quy định

Đăng ngày 27/10/2026

Tóm tắt: tìm rộng hơn nhưng phải xác nhận đúng đối tượng

Hybrid search cho RAG kết hợp nhiều đường tìm tài liệu trước khi mô hình soạn câu trả lời có căn cứ. Với nhà phân phối, một câu hỏi có thể chứa mã hàng chính xác, tên gọi quen dùng và yêu cầu tra quy định. Tìm theo chữ giúp giữ dấu vết mã; tìm theo vector có thể nhận ra cách diễn đạt khác. Cả hai vẫn có thể đưa lên tài liệu của mặt hàng gần giống hoặc bản chính sách cũ. Quyết định nghiệp vụ cần bước xác nhận riêng sau truy xuất.

Bài đề xuất sổ truy xuất sáu trường để doanh nghiệp nhìn thấy câu hỏi đã đi qua nhánh nào, tài liệu nào được phép tìm, vì sao một kết quả được giữ và điều kiện nào còn thiếu. Tình huống nhà phân phối xuyên suốt là giả định biên tập. Trợ lý chỉ giúp tra nguồn và lập dự thảo cho nhân viên kiểm; bài không mô tả hệ thống đã triển khai, không công bố tỷ lệ tìm đúng, tồn kho hay hiệu quả bán hàng thực tế.

Nghiên cứu ViRE công bố tại Findings EACL 2026 khảo sát truy hồi tiếng Việt trên mười bộ dữ liệu thuộc sáu lĩnh vực, gồm nhiều họ phương pháp tìm kiếm. Phạm vi bản tóm tắt cho thấy cần đánh giá tiếng Việt theo nhiều miền công việc. Nó không đủ để kết luận một cấu hình thắng trong kho nhà phân phối. Bài này chỉ dùng thông tin phạm vi từ bản tóm tắt đã đọc, không dẫn thứ hạng hoặc số điểm của toàn bộ nghiên cứu[1].

Bắt đầu bằng ba loại câu hỏi cần kết quả khác nhau

Câu “tài liệu của mã hàng này ở đâu” cần định danh đúng trước khi cần văn phong trả lời. Câu “loại phù hợp với cách gọi này” có thể cần mở rộng từ đồng nghĩa, nhưng phải giữ sự chưa chắc chắn về sản phẩm đích. Câu “điều kiện đổi hàng nào áp dụng” cần đúng bản quy định và đúng phạm vi hàng hóa. Gộp ba loại vào một điểm tìm kiếm khiến đội làm hệ thống khó biết một cải tiến đang giúp việc nào và làm hỏng việc nào.

Nhà phân phối giả định nên ghi đầu ra mong đợi bên cạnh từng câu hỏi thử. Đầu ra có thể là hồ sơ sản phẩm đúng mã, hai phương án cần người dùng phân biệt, hoặc điều khoản còn hiệu lực với đủ ngoại lệ. Không phải câu hỏi nào cũng cần AI viết một đoạn trả lời. Nếu chỉ cần mở đúng tờ thông tin sản phẩm, kết quả tìm có nhãn rõ và đường về nguồn có thể hữu ích hơn đoạn văn dài diễn giải lại.

Phạm vi cũng phải tách danh mục mô tả khỏi dữ liệu giao dịch. Tìm thấy một tài liệu giới thiệu sản phẩm không xác nhận hàng còn trong kho; tìm thấy chính sách công khai không tự xác nhận điều kiện riêng trong thỏa thuận khách hàng. Trong thiết kế đề xuất, trợ lý nêu tài liệu đã dùng và việc còn phải kiểm. Nhân viên có trách nhiệm đối chiếu nguồn giao dịch được phân quyền trước khi báo giá, xác nhận giao hàng hoặc cam kết với khách.

Từ khóa giữ dấu vết chữ, không thay trường mã chuẩn

Tài liệu Elasticsearch mô tả BM25 là một cách tính mức phù hợp theo trường, có xử lý tần suất từ và độ dài tài liệu. Đây là cơ chế xếp hạng văn bản; điểm cao không có nghĩa mã sản phẩm đã được đối chiếu chính xác. Một tài liệu dài nhắc nhiều mã trong bảng so sánh vẫn có thể xuất hiện khi người dùng hỏi về một mã cụ thể. Vì vậy cần phân biệt trường văn bản dùng để tìm với trường định danh dùng để xác nhận[2].

Trong kho giả định, mỗi tài liệu nên gắn mã sản phẩm chuẩn và tên do đơn vị quản lý danh mục xác nhận. Mã người dùng nhập được giữ nguyên để đối chiếu, còn cách xử lý khoảng trắng hoặc ký tự phân cách phải có quy tắc được chủ danh mục duyệt. Không tự bỏ mọi dấu nối vì chúng có thể phân biệt hai biến thể. Khi mã chưa tồn tại trong danh mục, hệ thống có thể đề nghị mã gần để người dùng chọn, nhưng không âm thầm thay mã rồi trả lời như đã xác nhận.

Tìm từ khóa cũng cần nhìn theo trường. Tên sản phẩm, mã, tiêu đề hướng dẫn và nội dung mô tả có ý nghĩa khác nhau. Đội thử nên xem kết quả đến từ phần nào, thay vì chỉ xem tổng điểm. Một câu hỏi nhắc tên hãng có thể kéo lên tài liệu nhiều sản phẩm cùng hãng. Kết quả ấy hữu ích để mở rộng tra cứu, nhưng chưa đủ cho câu hỏi yêu cầu điều kiện riêng của đúng dòng hàng đang xét.

Vector mở rộng cách diễn đạt, nhưng gần nghĩa có thể khác hàng

DPR minh họa truy hồi bằng hai bộ mã hóa riêng cho câu hỏi và đoạn tài liệu, rồi tìm ứng viên thông qua biểu diễn vector. Trong nghiên cứu này, việc đoạn chứa câu trả lời xuất hiện trong tập ứng viên được phân biệt với việc bộ đọc trả lời đúng. Các thử nghiệm thuộc bối cảnh hỏi đáp trên Wikipedia tiếng Anh. Cơ chế giúp hiểu cách tìm theo biểu diễn, nhưng không chứng minh mô hình bất kỳ sẽ nhận đúng tên gọi ngành hàng hoặc tiếng Việt của doanh nghiệp[3].

Ở nhà phân phối giả định, nhân viên có thể nói theo chức năng sử dụng trong khi danh mục dùng thuật ngữ kỹ thuật. Nhánh vector đáng thử ở chỗ nối hai cách diễn đạt. Tuy nhiên, hai mặt hàng gần chức năng có thể khác kích cỡ, phụ kiện hoặc điều kiện bảo hành. Độ gần của vector chỉ giúp chọn tài liệu để xem tiếp. Nó không được dùng để tự thay thế sản phẩm trong đơn hàng hoặc suy ra rằng quy định của mặt hàng gần cũng áp dụng.

Một câu hỏi thử tốt cần có cả ứng viên hấp dẫn nhưng sai. Nếu tập thử chỉ chứa tài liệu đúng và những tài liệu hoàn toàn xa lạ, hệ thống có thể trông rất tốt mà chưa từng đối mặt với hai biến thể dễ nhầm. Người quản lý ngành hàng nên chỉ ra dấu hiệu phân biệt trong nguồn. Đội kỹ thuật ghi xem nhánh vector có đưa đúng tài liệu vào, đồng thời giữ lại những tài liệu gần nghĩa gây nhầm để kiểm sau mỗi thay đổi.

Tiếng Việt thiếu dấu cần một đường phụ có kiểm soát

Unicode phân biệt tương đương chuẩn tắc với tương đương tương thích; NFC là phân rã chuẩn tắc rồi tổ hợp chuẩn tắc. Chuẩn hóa kiểu này giúp xử lý những chuỗi tương đương về ký tự, không phải thao tác bỏ dấu tiếng Việt. Nhầm hai việc có thể làm đội dự án cho rằng dữ liệu đã “chuẩn” nên không cần kiểm mất phân biệt tên hàng. Bài dùng UAX 15 bản sửa đổi 58, được công bố cùng Unicode 18.0.0, để giữ rõ ranh giới cơ chế này[4].

Bộ lọc ASCII folding của Elasticsearch chuyển những ký tự ngoài Basic Latin khi có tương đương ASCII và có lựa chọn giữ lại dạng gốc. Tài liệu này mô tả hành vi của một công cụ cụ thể, không bảo đảm mọi tên tiếng Việt hoặc ký hiệu ngành hàng được xử lý đúng. Trong thiết kế đề xuất, nhánh tìm không dấu nên giữ được bản gốc để kiểm và được thử trên tên thực tế. Không dùng biến thể đã mất phân biệt làm định danh duy nhất[5].

Bộ thử nên ghép câu có dấu với câu thiếu dấu do người phụ trách tạo, đồng thời thêm trường hợp biến thể làm nhập nhằng hai tên khác nhau. Cần ghi hệ thống có hỏi lại khi thiếu thông tin hay cứ lấy kết quả đầu. Từ điển viết tắt cũng phải có người duyệt và phạm vi áp dụng. Một chữ viết tắt trong nhóm phụ kiện có thể mang nghĩa khác ở nhóm thiết bị; mở rộng toàn kho có thể tăng số kết quả nhưng làm giảm khả năng kiểm.

Hợp thứ hạng không phải cộng xác suất đúng

RRF kết hợp vị trí của tài liệu trong nhiều danh sách kết quả thay vì đòi điểm thô từ các nhánh cùng thang đo. Tài liệu Elasticsearch mô tả các nhánh độc lập, tham số hằng số xếp hạng và cửa sổ ứng viên; kết quả còn chịu việc cắt danh sách. Vì vậy triển khai cụ thể vẫn có lựa chọn cần kiểm. Điểm sau hợp hạng không phải xác suất sản phẩm đúng hay bằng chứng điều khoản đang áp dụng cho khách hàng[6].

Sổ truy xuất nên lưu thứ hạng trước và sau khi hợp, cùng mã tài liệu ổn định. Điều này giúp phân biệt tài liệu đứng cao vì cả hai nhánh cùng tìm ra, hay vì một nhánh duy nhất đưa nó lên. Khi hai nhánh chỉ trả về các đoạn khác nhau của cùng tài liệu, cần khử trùng mà không đánh mất vị trí đoạn. Không để một tài liệu chia thành nhiều đoạn chiếm hết chỗ và làm mất tài liệu bổ sung điều kiện quan trọng.

Cũng cần phân biệt hợp hạng với xác nhận đối tượng. Nếu câu hỏi chứa mã đã được người dùng xác nhận, quy tắc bảo vệ mã phải được xem xét riêng. Không thể giải quyết việc tìm nhầm mã bằng cách tiếp tục chỉnh trọng số cho đến khi một ví dụ nhìn đúng. Đội dự án nên ghi rõ điều kiện được coi là ràng buộc, tín hiệu nào chỉ để xếp ưu tiên và trường hợp nào phải hỏi thêm trước khi tiếp tục tra cứu.

Quyền và bộ lọc có thể làm thay đổi tập ứng viên

README pgvector phân biệt tìm láng giềng chính xác với gần đúng, đồng thời lưu ý bộ lọc sau quét chỉ mục gần đúng có thể khiến số kết quả trả về ít hơn mong muốn. Cơ chế quét lặp có giới hạn dừng riêng. “Chính xác” ở đây nói về láng giềng theo phép đo đã chọn; nó không xác nhận tính đúng nghiệp vụ. Ngược lại, ít kết quả sau lọc chưa đủ chứng minh trong tập được phép không tồn tại tài liệu cần tìm[7].

Hai nhánh phải cùng tuân theo phạm vi người dùng được tìm, nhưng cách thi hành cần được kiểm ở hệ thống thực tế. Không được chạy nhánh từ khóa trên kho đã phân quyền trong khi nhánh vector tìm toàn kho rồi đưa đoạn chưa được phép vào lời giải thích. Nhật ký, phần gợi ý và tài liệu mở rộng cũng nằm trong phạm vi cần xem xét. Hợp kết quả không thể hợp thức hóa tài liệu vốn không được phép xuất hiện cho người hỏi.

Trong phép thử, nhóm nghiệp vụ tạo hai tài khoản thử với các tập tài liệu được duyệt khác nhau và dùng nội dung giả lập phù hợp. Kiểm cả câu hỏi trực tiếp về mã lẫn cách nói vòng qua từ đồng nghĩa. Nếu một nhánh không có ứng viên, giao diện cần báo trạng thái có giới hạn, không hé lộ tài liệu bị chặn để giải thích. Kết luận “chưa tìm thấy trong phạm vi được phép” trung thực hơn “doanh nghiệp không có tài liệu này”.

Sổ truy xuất sáu trường làm rõ lỗi nằm ở đâu

Trường đầu ghi câu hỏi nguyên bản và loại công việc, giữ được dấu, mã và các chỗ người dùng chưa xác nhận. Trường thứ hai ghi định danh chuẩn nếu đã có, tách dữ liệu được xác minh khỏi mã được hệ thống gợi ý. Trường thứ ba ghi phạm vi nguồn được tìm: quyền, nhóm hàng, mốc phiên bản và điều kiện lọc đã áp dụng. Ba trường này mô tả đề bài trước khi xem điểm, giúp ngăn việc sửa cách hiểu câu hỏi chỉ để hợp với kết quả đã tìm ra.

Trường thứ tư giữ các nhánh, cấu hình và thứ hạng tài liệu trước sau khi hợp. Trường thứ năm ghi căn cứ đúng cần có, phần đã xuất hiện và chỗ còn thiếu. Trường cuối ghi quyết định bàn giao: mở nguồn cho người kiểm, hỏi người dùng phân biệt đối tượng, hoặc dừng soạn trả lời. Sổ không cần sao chép toàn bộ nội dung nhạy cảm; nó cần đủ dấu vết để người có quyền tái kiểm đúng lần truy xuất trong môi trường được kiểm soát.

Cách ghi này phân biệt ba lỗi thường bị gộp chung. Tài liệu đúng không có trong ứng viên là lỗi phát hiện. Có ứng viên đúng nhưng bị đẩy khỏi phần được xem là lỗi xếp chọn. Có đoạn đúng nhưng thiếu ngoại lệ để trả lời là lỗi đủ căn cứ. Mỗi lỗi dẫn tới hành động khác nhau: sửa dữ liệu và cách tìm, sửa cách chọn, hoặc bổ sung ngữ cảnh. Đổi mô hình trả lời ngay lập tức có thể không chạm đúng nguyên nhân.

Ca giả định: cùng một cách gọi, hai hồ sơ cần phân biệt

Giả sử nhân viên hỏi về “bộ nối dùng ngoài trời” và nhớ một phần mã. Kho có hướng dẫn của hai dòng sản phẩm cùng cách mô tả chung, kèm quy định đổi hàng theo từng nhóm. Nhánh từ khóa có thể ưu tiên tài liệu nhắc phần mã; nhánh vector có thể tìm tài liệu mô tả chức năng. Không nhánh nào đủ quyền chọn thay khách. Trợ lý nên nêu cần xác nhận mã đầy đủ hoặc dòng hàng trước khi gắn điều kiện đổi trả.

Khi nhân viên chọn đúng mã trong danh mục đã xác minh, hệ thống mới chạy bước tra điều kiện tương ứng. Nếu tài liệu mới chỉ sửa một ngoại lệ trong phụ lục, việc tìm đoạn chính sách chung chưa đủ. Người kiểm cần mở được bản nguồn và thấy phần áp dụng cho dòng hàng đó. Trong dự thảo, trợ lý chỉ nêu điều kiện có căn cứ, chỉ ra phụ lục đang thiếu nếu chưa tìm thấy, và để trạng thái chờ kiểm thay vì tự điền điều kiện từ mặt hàng gần.

Đội thử chạy lại tình huống bằng câu thiếu dấu, tên viết tắt và mã gần giống được tạo riêng cho phép thử. Kết quả cần được xem từng câu: hệ thống có giữ đúng lựa chọn đã xác nhận, có nhầm sang hồ sơ tương tự, có dùng lại bản cũ từ lần trước không. Không ghi tỷ lệ giả định thành kết quả đo. Khi thử thật, mỗi nhận định đúng hoặc sai phải gắn tài liệu và vị trí cụ thể để chủ ngành hàng xem lại.

Đo riêng việc tìm thấy, xếp đúng và trả lời đủ

BEIR xây dựng đánh giá truy hồi không huấn luyện theo miền trên nhiều bộ dữ liệu tiếng Anh, đồng thời thảo luận khác biệt nhiệm vụ và thiên lệch gán nhãn. Nghiên cứu phân biệt thước đo xét thứ hạng với các cách đo độ chính xác và độ bao phủ. Điều rút ra cho phép thử nội bộ là phải chọn thước đo theo việc cần làm. Kết quả benchmark lịch sử không cho phép xếp hạng mặc định các sản phẩm hiện tại hay suy ra hiệu quả ở Việt Nam[8].

Với câu hỏi mã hàng, cần xem tài liệu đúng mã có xuất hiện trong phần nhân viên thực sự nhìn hay không. Với câu hỏi nhiều điều kiện, cần xem đủ các phần căn cứ có được đưa tới người trả lời hay chưa. Với câu hỏi nhập nhằng, kết quả mong đợi có thể là yêu cầu làm rõ thay vì tài liệu đứng đầu. Mỗi nhóm nên có kết quả riêng; một số tổng đẹp có thể che việc hệ thống tìm khá tốt tên gọi nhưng vẫn làm sai mã.

So sánh nên giữ cùng bản kho, quyền, câu hỏi và tiêu chí chấm cho từ khóa, vector và kết hợp. Ghi thêm thời gian chờ, số tài liệu cần người kiểm mở và số bước hỏi lại. Đây là kế hoạch đo, chưa phải số liệu. Khi tăng cửa sổ ứng viên giúp tìm thấy thêm tài liệu nhưng khiến người kiểm đọc quá nhiều, đội phải cân nhắc lợi ích theo cả công việc. Không chọn phương án chỉ vì số tài liệu truy hồi được lớn nhất.

Đưa vào dùng từng phần và giữ đường quay lại

Doanh nghiệp nhỏ có danh mục được quản lý tốt có thể bắt đầu bằng tìm mã và từ khóa, chỉ thêm vector vào nhóm câu thực sự thất bại vì khác cách nói. Kho lớn cần thêm người chịu trách nhiệm phiên bản, quyền và phép thử hồi quy; thêm nhánh tìm sẽ thêm phần phải duy trì. Không có ngưỡng số tài liệu chung buộc mọi doanh nghiệp dùng tìm lai. Quyết định nên dựa trên lỗi đã ghi, năng lực giữ dữ liệu và chi phí kiểm kết quả.

Khi đổi mô hình biểu diễn, từ điển viết tắt hoặc cách hợp hạng, cần lưu cấu hình trước và chạy lại câu từng đúng. Giữ một tập câu không dùng để chỉnh cấu hình nhằm xem thay đổi có khái quát hơn các ví dụ đã sửa hay không. Cần dừng mở rộng nếu tìm nhầm mã đã xác nhận, lộ tài liệu ngoài quyền hoặc dùng bản cũ mà không báo. Khôi phục đường tìm đã kiểm phải đi cùng việc ghi nhận câu thất bại để tiếp tục điều tra.

Bàn giao vận hành nên có chủ danh mục, người giữ quy định và người phụ trách kỹ thuật. Chủ danh mục xác nhận mã và tên đồng nghĩa; người giữ quy định xác nhận bản áp dụng; kỹ thuật bảo đảm cấu hình, phạm vi và dấu vết có thể kiểm. Không để người sửa thuật toán tự quyết một điều kiện thương mại đang tranh chấp. Nếu nguồn chưa thống nhất, hệ thống giữ trạng thái cần xác minh và giao đúng người nhận, thay vì tạo câu trả lời nghe có vẻ dứt khoát.

Hỏi đáp về lựa chọn đường truy xuất

Có phải cứ có vector thì nên bật tìm lai? Không, hãy thêm nhánh khi nó giải quyết một nhóm lỗi đã xác định và không làm hỏng câu từng đúng. Danh mục chủ yếu tra mã chuẩn có thể được phục vụ tốt bằng đường tìm đơn giản. Khi người dùng thường nói khác thuật ngữ trong nguồn, vector đáng được so trên cùng tập câu. Quyết định cần cả chất lượng, thời gian kiểm và người duy trì; số thành phần nhiều hơn không tự tạo căn cứ tốt hơn.

Điểm hợp hạng cao có cho phép trả lời chắc chắn không? Không, điểm chỉ phản ánh cách ứng viên được sắp trong cấu hình đó. Cần kiểm đúng mã, phiên bản, quyền và phần điều kiện đi kèm. Một tài liệu phổ biến có thể được cả hai nhánh tìm ra nhưng không áp dụng cho dòng hàng người dùng hỏi. Nếu còn thiếu phụ lục hoặc chưa rõ đối tượng, trợ lý nên hỏi thêm hoặc giao người kiểm, kể cả khi tài liệu đứng đầu có điểm cách xa các tài liệu còn lại.

Tìm không dấu có nên thay hết dữ liệu gốc? Không, nên giữ dạng gốc để hiển thị, đối chiếu và phân biệt tên hoặc mã. Chuẩn hóa ký tự tương đương và tạo biến thể không dấu là hai thao tác khác nhau. Đường phụ không dấu cần được kiểm trên tên thực tế, đặc biệt khi nhiều tên rơi vào cùng một dạng tìm. Khi biến thể tạo nhập nhằng, hệ thống nên đưa lựa chọn rõ ràng cho người dùng xác nhận, không tự xem hai tên là cùng đối tượng.

Không có kết quả sau lọc có nghĩa tài liệu không tồn tại không? Không, đó chỉ là trạng thái của lần tìm với quyền, phạm vi và giới hạn đã dùng. Có thể câu hỏi chưa rõ, chỉ mục chưa cập nhật hoặc cách tìm gần đúng chưa đưa tài liệu phù hợp vào ứng viên. Cần kiểm nguyên nhân bằng dấu vết được phân quyền. Thông báo cho người dùng nên giữ giới hạn này, đồng thời tránh hé lộ tên hoặc nội dung tài liệu họ không được phép biết.

Nguồn, phương pháp và giới hạn suy luận

Bài được biên soạn có hỗ trợ AI, dựa trên tám nguồn gốc mở đọc ngày 27/10/2026 trong phạm vi ghi tại hồ sơ nguồn. ViRE chỉ đọc bản tóm tắt công bố, không dùng kết quả toàn văn; các nghiên cứu lịch sử không đại diện cho mọi mô hình hiện tại. Tài liệu Elastic và pgvector phản ánh cơ chế do bên phát triển mô tả. Sổ truy xuất, phép thử và tình huống nhà phân phối là đề xuất biên tập giả định, chưa chạy API, đo tại doanh nghiệp hay được chuyên gia thẩm định; không đưa kết luận pháp lý hoặc cam kết thương mại.