Thiết kế PoC RAG theo thực tiễn FDE: Đừng để PoC chỉ dừng ở bản demo tìm kiếm

RAG (Retrieval-Augmented Generation) thường được trình diễn bằng một giao diện trò chuyện có thể tìm kiếm tài liệu nội bộ và trả lời câu hỏi. Nhưng trong thực tế, câu hỏi cần đặt ra trước tiên không phải là “AI có đưa ra câu trả lời nghe hợp lý không?”, mà là: câu trả lời đó được phép làm căn cứ cho quyết định nghiệp vụ đến mức nào? Nếu ranh giới này còn mơ hồ, ta có thể giữ lại một bản demo tìm kiếm, nhưng sẽ không có thiết kế đủ tin cậy để vận hành.

Trước hết, bài viết nêu rõ quan điểm: PoC RAG nên bắt đầu như một công việc thiết kế kiểm soát chất lượng quyết định nghiệp vụ, chứ không phải thử nghiệm giao diện AI tạo sinh. Vào ngày đầu, FDE (Forward Deployed Engineering) cần xác định phạm vi quyết định, tài liệu làm căn cứ, cách đánh giá, quyền truy cập và những sản phẩm bàn giao cần giữ lại sau PoC, trước khi chọn mô hình hay UI.

Với doanh nghiệp Nhật Bản, nên cân nhắc các công việc có căn cứ được lưu trong tài liệu, chẳng hạn quy định nội bộ, sổ tay chất lượng, thông số sản phẩm và quy trình bảo trì. Tuy vậy, nếu các tài liệu chưa thống nhất về phiên bản mới nhất, ngày hiệu lực, bộ phận áp dụng, ngoại lệ và quyền xem, việc đưa nguyên trạng vào tìm kiếm AI sẽ làm mờ những vấn đề PoC cần kiểm chứng.

Ngày đầu cần quyết định “được phép phán đoán điều gì”, không chỉ “cần trả lời điều gì”

Chỉ đặt tên phạm vi PoC là “tra cứu quy định”, “hỏi đáp về đặc tả” hay “hỗ trợ yêu cầu” là chưa đủ. FDE nên ghi thành văn bản ranh giới giữa các quyết định mà câu trả lời được phép hỗ trợ, không được hỗ trợ và bắt buộc phải có người xác nhận.

Ví dụ với quy định nội bộ, “kiểm tra hạn mức chi phí công tác” khác với “quyết định có chấp thuận ngoại lệ hay không”. Việc đầu chủ yếu cần chỉ ra điều khoản làm căn cứ; việc sau còn liên quan đến thẩm quyền, cách xử lý trước đây và luồng phê duyệt. Trong PoC, nên tránh nhồi cả hai loại quyết định vào cùng một giao diện trò chuyện.

Nếu bắt đầu đánh giá mà chưa thống nhất ranh giới này, cuộc thảo luận sẽ chỉ xoay quanh độ tự nhiên của câu trả lời. Demo có thể trông hoàn thiện với người ngoài, nhưng bộ phận sử dụng, kiểm toán, hệ thống và mua sắm sẽ không thống nhất PoC đã kiểm chứng điều gì.

Chốt ranh giới tài liệu làm căn cứ trước khi nạp dữ liệu

Tổng quan về RAG trong Azure AI Search giải thích rằng thay vì đưa nguyên khối lượng lớn tài liệu cho mô hình ngôn ngữ lớn (LLM), cần thiết kế để truy xuất các đoạn văn bản liên quan. Vì vậy, tài liệu được đưa vào tìm kiếm, kích thước phân đoạn và chiến lược tìm kiếm là tiền đề của chất lượng câu trả lời. 5

Azure AI Search cũng nêu việc chia đoạn khi lập chỉ mục là một phần của thiết kế RAG. 5

Từ đó, FDE nên lập danh mục trước khi nạp dữ liệu, ghi rõ tên tài liệu, phiên bản, ngày hiệu lực, bộ phận áp dụng và chủ sở hữu. Đồng thời ghi riêng các thuộc tính vận hành như quyền tham chiếu, lý do loại trừ, quy tắc chia đoạn và người chịu trách nhiệm khi cập nhật. Việc này có thể trông như một dự án quản lý tài liệu đầy đủ, nhưng với RAG, đây chính là các điều kiện đầu vào của chất lượng tìm kiếm.

Cần tránh nạp trước mọi PDF hoặc trang web sẵn có rồi mới phát hiện tài liệu cũ bị trộn lẫn hoặc hệ thống dựa vào tài liệu người dùng không được phép xem. Chẳng hạn, nếu phiên bản cũ và mới của sổ tay chất lượng cùng nằm trong một chỉ mục tìm kiếm, câu trả lời trích quy trình từ bản cũ nên được xem là lỗi về ranh giới dữ liệu, không phải vấn đề cần cải thiện UI.

Tách đánh giá chất lượng tìm kiếm và chất lượng câu trả lời

Tài liệu của Microsoft về bộ đánh giá RAG chia việc đánh giá thành đánh giá quy trình tìm kiếm và đánh giá hệ thống ở câu trả lời cuối cùng. Ở phía tìm kiếm, các khía cạnh gồm Retrieval (tính phù hợp của truy xuất); ở phía câu trả lời, gồm Groundedness (mức độ dựa trên căn cứ) và Relevance (mức độ trả lời đúng trọng tâm). Groundedness xem xét câu trả lời có dựa trên ngữ cảnh được cung cấp hay không. 7

Cách chia này giúp xác định nguyên nhân thất bại của PoC. Nếu không tách được việc tìm kiếm không trả về đoạn căn cứ phù hợp với trường hợp đã lấy được căn cứ nhưng phần tạo câu trả lời lại bỏ sót hoặc suy diễn quá mức, ta sẽ không biết nên cải thiện cấu hình tìm kiếm, prompt hay việc chuẩn bị tài liệu.

Tài liệu Azure AI Search đề cập chia đoạn khi lập chỉ mục, embedding cho tìm kiếm vector và tìm kiếm lai kết hợp tìm kiếm từ khóa với tìm kiếm vector. Tài liệu cũng đề cập xếp hạng ngữ nghĩa, hồ sơ chấm điểm, điều chỉnh trọng số vector và ngưỡng. 5

Mức độ chi tiết của bảng đánh giá FDE chuẩn bị

Bộ đánh giá nên có câu hỏi và câu trả lời kỳ vọng, đồng thời xác định tài liệu và vị trí căn cứ mong đợi, cách diễn đạt lại được chấp nhận, và các điều kiện không được trả lời. Ngay cả khi dùng Groundedness, đừng dừng ở mô tả khái quát “dựa trên căn cứ”; hãy ghi vào bảng đánh giá tài liệu nào và phạm vi nào được công nhận là căn cứ. 7

Ví dụ với sổ tay bảo trì, câu hỏi “Quy trình khởi động lại thiết bị A là gì?” còn quá rộng. Cần phân biệt căn cứ mong đợi là “khởi động lại sau khi dừng bình thường” hay “khôi phục sau khi dừng bất thường”; đồng thời ghi trước điều kiện chấm điểm, chẳng hạn thiếu lưu ý an toàn trong trường hợp thứ hai thì không đạt.

Về đánh giá hiệu năng khối lượng công việc AI tạo sinh, Generative AI Lens của AWS khuyến nghị thường xuyên đánh giá bằng dữ liệu đáp án chuẩn (ground truth), so sánh đầu ra với đáp án đã biết để theo dõi hiệu năng. 8

Ở giai đoạn PoC, theo chúng tôi, đặt một số trường hợp đại diện rộng nhưng gọn cho từng ranh giới quyết định sẽ giúp kiểm tra ý đồ thiết kế dễ hơn việc chỉ cố tăng kích thước bộ đánh giá. Thay vì tạo cảm giác bao quát, hãy ưu tiên giữ một bảng đánh giá có thể giải thích rõ “đây là trường hợp có thể cân nhắc sử dụng” và “đây là quyết định ngoại lệ không dùng”.

Không để quyền truy cập thành việc bổ sung sau

Trong thực tế, kể cả PoC cũng không nên chỉ dựa vào đăng nhập trên UI. Hãy xác định trước ai được phép tìm kiếm nhóm tài liệu nào và điều kiện đó sẽ được thể hiện ở kho dữ liệu, chỉ mục tìm kiếm hay siêu dữ liệu của các đoạn văn bản.

Cần tránh thỏa hiệp kiểu “PoC nên mọi người thử trên cùng một chỉ mục”. Dù phân tách đăng nhập trên màn hình, nếu các đoạn được tìm kiếm vẫn dùng chung, căn cứ từ tài liệu vốn không nên hiển thị cho người dùng đó vẫn có thể lọt vào câu trả lời. Ngay cả trong PoC, quyền truy cập cần được xử lý như một phần thiết kế kho dữ liệu và phạm vi tìm kiếm, không chỉ là UI.

Hãy xem xét việc đưa quy định nhân sự và ghi chú vận hành theo từng bộ phận lên cùng nền tảng RAG. Nếu tài liệu tham chiếu phải khác nhau theo vai trò người dùng, điều kiện đó nên được đặt trong bộ lọc trước khi tìm kiếm hoặc trong thiết kế tách chỉ mục, thay vì chỉ ghi trong chỉ dẫn tạo câu trả lời. Dù kiểm soát đầu ra AI cẩn thận đến đâu, nếu căn cứ không phù hợp được truy xuất ngay từ bước tìm kiếm thì khó có thể dùng khâu tạo câu trả lời phía sau để bù đắp khiếm khuyết thiết kế.

Chuyển sản phẩm cần giữ lại sau PoC thành ngôn ngữ hợp đồng và mua sắm

Không nên xem giao diện hoạt động được là sản phẩm bàn giao duy nhất của PoC. Trong RAG, việc nạp tài liệu, chia đoạn, lập chỉ mục, tìm kiếm, tạo câu trả lời và đánh giá có quan hệ nối tiếp. Ngay từ đầu, cần xác nhận phần nào là tài sản thiết kế sẽ được giữ trong công ty và phần nào được dùng như chức năng dịch vụ.

Trong công việc FDE, nên đặt vấn đề này từ lúc bắt đầu thay vì đợi đến khi kết thúc PoC. Chỉ mục, quy tắc chia đoạn, bộ đánh giá, bảng phân quyền và ghi chép về các trường hợp thất bại có thể được tái sử dụng cho MVP hoặc mua sắm sản phẩm chính thức. Nếu không ghi rõ đâu là sản phẩm bàn giao và đâu là chức năng dịch vụ, sẽ khó biến kết quả kiểm chứng kỹ thuật thành tài sản của tổ chức.

• Danh mục tài liệu: liệt kê tài liệu mục tiêu, phiên bản, chủ sở hữu, phạm vi áp dụng và lý do loại trừ.
• Tài liệu thiết kế chia đoạn và lập chỉ mục: ghi lại quy tắc chia đoạn, phương thức tìm kiếm, ngưỡng và cách xác định số kết quả lấy lên.
• Bộ đánh giá: ghi lại câu hỏi, căn cứ mong đợi, câu trả lời kỳ vọng, điều kiện không đạt và vai trò người dùng.
• Bảng phân quyền: sắp xếp mối tương ứng giữa người dùng hoặc vai trò với kho dữ liệu hay nhóm tài liệu được phép tham chiếu.
• Danh sách vấn đề chưa giải quyết: ghi nhận tài liệu thiếu, quản lý phiên bản chưa đầy đủ, vận hành ngoại lệ và quyết định chưa thể đánh giá.

Danh sách này không phải bảng chọn nhà cung cấp. Đây là tập hợp tối thiểu các tài sản thiết kế để bất kỳ ai tiếp nhận sau PoC cũng có thể tiếp tục kiểm chứng dựa trên những gì đã biết. Từ góc nhìn AIX (AI transformation), PoC RAG vừa là hoạt động đưa AI vào, vừa là quá trình kết nối tài liệu, kiểm toán, hợp đồng và đánh giá chất lượng.

Khi nào cách tiếp cận này không phù hợp

Thiết kế trong bài này không phù hợp nếu mục tiêu là thử ngay một chatbot tán gẫu công khai rộng rãi, hoặc nếu mục đích coi trọng khả năng sáng tạo hơn tài liệu làm căn cứ. Nếu thứ cần đánh giá là trải nghiệm sử dụng chứ không phải quyết định nghiệp vụ, việc đầu tư sâu cho danh mục tài liệu và bảng phân quyền sẽ ít ưu tiên hơn.

Ngược lại, với các trường hợp như quy định, đặc tả, quy trình, hợp đồng và tiêu chuẩn chất lượng, càng vội làm demo tìm kiếm thì càng có thể phát sinh nhiều việc làm lại. FDE cần không chỉ khả năng dựng giao diện chạy được trong tuần đầu tiên, mà còn khả năng thống nhất các ranh giới cần được quyết định trước khi hệ thống hoạt động.

Gợi ý cho thực tiễn

Thứ nhất, khuyến nghị không bắt đầu chương trình họp khởi động PoC bằng việc “thu thập tài liệu mục tiêu”. Trước tiên, hãy tổng hợp trên một trang các quyết định mà hệ thống được hỗ trợ, không được hỗ trợ và bắt buộc phải có người xác nhận. Sau đó mới suy ngược ra các tài liệu căn cứ cần thiết.

Thứ hai, tách đánh giá tìm kiếm khỏi đánh giá câu trả lời. Đánh giá tìm kiếm xem có lấy được đoạn căn cứ mong đợi không. Đánh giá câu trả lời xem nội dung có dựa trên căn cứ không, có bỏ sót nội dung cần thiết không và có kiềm chế khi gặp điều kiện không được trả lời không.

Thứ ba, ngay ngày đầu hãy chuyển quyền truy cập và sản phẩm bàn giao sang ngôn ngữ của hợp đồng và mua sắm. Xác nhận chỉ mục, quy tắc chia đoạn, bộ đánh giá, bảng phân quyền và ghi chép về trường hợp thất bại tạo ra trong PoC sẽ là sản phẩm bàn giao hay là điều kiện để sử dụng dịch vụ.

Vai trò của FDE không chỉ là đưa AI vào hiện trường. Đó còn là diễn đạt rõ ranh giới quyết định nghiệp vụ, cách xử lý tài liệu căn cứ, tiêu chí đánh giá, quyền truy cập và sản phẩm có thể bàn giao, để thiết kế các điều kiện trong đó hiện trường được phép sử dụng AI.

---

Tài liệu tham khảo

[1] Hướng dẫn tiêu chuẩn thúc đẩy xã hội số (2026-09-01) https://www.digital.go.jp/resources/standard_guidelines

[5] Retrieval-augmented generation (RAG) in Azure AI Search https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview?tabs=docs

[7] Retrieval-Augmented Generation (RAG) Evaluators for Generative AI https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators

[8] GENOPS01-BP01 Periodically evaluate functional performance - Generative AI Lens https://docs.aws.amazon.com/wellarchitected/latest/generative-ai-lens/genops01-bp01.html

Bài viết này được thực hiện với sự hỗ trợ của AI và đã được rà soát tự động trước khi xuất bản. Ngày kiểm tra thông tin: 2026-09-21.