RAG (retrieval-augmented generation, tạm dịch là sinh câu trả lời có tra cứu) là cách trợ lý AI trả lời dựa trên tài liệu riêng của bạn: khi nhận câu hỏi, hệ thống tìm vài đoạn tài liệu có vẻ liên quan nhất, đặt các đoạn đó cùng câu hỏi trước mô hình ngôn ngữ, rồi mô hình viết câu trả lời dựa trên những đoạn được đưa cho nó. Mô hình không học thuộc kho tài liệu; nó chỉ đọc những đoạn được tìm ra cho từng câu hỏi.
Thuật ngữ này phổ biến từ một bài nghiên cứu năm 2020 của nhóm Patrick Lewis và cộng sự, và nay là nền của nhiều tính năng "trò chuyện với tài liệu" hay "trợ lý có kiến thức riêng". Bạn không cần lập trình để dùng, nhưng hiểu cơ chế giúp bạn trả lời câu hỏi quan trọng nhất khi trợ lý sai: lỗi nằm ở khâu tìm, khâu đọc hay ở chính tài liệu.
Vì sao cần tra cứu thay vì đưa hết tài liệu cho mô hình
Mỗi mô hình ngôn ngữ có một giới hạn về lượng chữ nó đọc được trong một lần, thường gọi là cửa sổ ngữ cảnh. Giới hạn này đã lớn lên nhiều qua các thế hệ mô hình, nhưng kho tài liệu của một tổ chức vẫn thường vượt xa, và kể cả khi vừa, đưa toàn bộ kho vào mỗi câu hỏi tốn thời gian và chi phí xử lý.
Quan trọng hơn, đọc nhiều chưa chắc đọc kỹ. Khi đưa vào một lượng văn bản rất lớn, mô hình có thể bỏ sót chi tiết nằm giữa, hoặc bị nhiễu bởi những đoạn gần giống nhưng không liên quan. Các nhóm nghiên cứu đã ghi nhận hiện tượng mô hình dùng thông tin ở giữa ngữ cảnh dài kém hơn thông tin ở đầu hoặc cuối, dù mức độ khác nhau giữa các mô hình.
RAG giải quyết bằng cách lọc trước: chỉ đưa những đoạn có khả năng chứa câu trả lời. Cái giá là thêm một khâu có thể sai. Nếu khâu tìm không lấy được đúng đoạn, mô hình giỏi đến đâu cũng không trả lời đúng được, vì nó chưa từng thấy thông tin cần thiết.
Bốn khâu bên trong một trợ lý tra cứu tài liệu
Các công cụ khác nhau làm mỗi khâu theo cách riêng, nhưng khung chung thường gồm bốn khâu dưới đây.
- Chia đoạn. Khi bạn nạp tài liệu, hệ thống cắt nó thành nhiều đoạn nhỏ, có thể theo số chữ, theo đoạn văn hoặc theo tiêu đề. Đoạn là đơn vị được tìm và đưa cho mô hình, nên cách cắt ảnh hưởng trực tiếp tới việc một ý có bị chia đôi hay không.
- Biểu diễn đoạn. Mỗi đoạn được chuyển thành một dạng biểu diễn số, thường gọi là embedding, sao cho những đoạn có nghĩa gần nhau có biểu diễn gần nhau. Nhiều hệ thống kết hợp thêm tìm theo từ khoá truyền thống.
- Tìm đoạn. Câu hỏi của người dùng cũng được biểu diễn theo cách đó, rồi hệ thống lấy ra một số đoạn gần nhất. Số đoạn lấy ra có hạn, thường chỉ vài đoạn tới vài chục đoạn.
- Viết câu trả lời. Mô hình nhận hướng dẫn hệ thống, các đoạn tìm được và câu hỏi, rồi viết câu trả lời. Nếu được dặn, nó ghi lại đoạn nào đã dùng.
Khi dùng tính năng có sẵn trong công cụ chat, bạn thường không thấy và không chỉnh được ba khâu đầu. Nhưng bạn vẫn tác động được tới chúng qua cách viết và tổ chức tài liệu, như phần sau giải thích.
Trợ lý trả lời sai: lỗi ở khâu nào
Bảng dưới giúp bạn đoán lỗi nằm ở đâu từ triệu chứng, và việc bạn làm được mà không cần can thiệp kỹ thuật.
| Triệu chứng | Lỗi có thể ở | Bạn làm được gì |
|---|---|---|
| Nói tài liệu không có, trong khi có | Khâu tìm: câu hỏi dùng từ khác hẳn tài liệu, hoặc đoạn bị cắt mất ý | Thêm tiêu đề mục dùng từ người dùng hay hỏi; viết lại đoạn để mỗi mục tự đủ nghĩa |
| Trích đúng tài liệu nhưng bản cũ | Kho có cả bản cũ và mới | Gỡ bản cũ, ghi ngày hiệu lực ở đầu tệp |
| Đúng một nửa, thiếu điều kiện quan trọng | Điều kiện nằm ở đoạn khác không được lấy ra | Đưa điều kiện vào cùng mục với quy định chính; nhắc lại chủ ngữ |
| Trộn thông tin của hai mục | Hai đoạn gần nghĩa cùng được lấy ra | Đặt tiêu đề phân biệt rõ; tách tài liệu nếu hai mục áp dụng cho đối tượng khác nhau |
| Trả lời trơn tru mà tài liệu không hề nói | Khâu viết: mô hình lấp chỗ trống bằng kiến thức chung | Thêm quy tắc khoảng trống vào hướng dẫn hệ thống, yêu cầu ghi nguồn |
| Câu hỏi tổng hợp cả kho trả lời kém | RAG chỉ lấy vài đoạn, không đọc cả kho | Chia câu hỏi nhỏ, hoặc làm sẵn tài liệu tổng hợp |
Dòng cuối là giới hạn bản chất của cách làm này. Câu hỏi kiểu "trong toàn bộ quy trình, có bao nhiêu bước cần chữ ký giám đốc" đòi hỏi đọc mọi đoạn, trong khi khâu tìm chỉ trả về vài đoạn. Với những câu như vậy, một tài liệu tổng hợp viết sẵn đáng tin hơn.
Ví dụ giả định: một câu hỏi đi qua bốn khâu
Một trợ lý hỗ trợ nhân viên phòng khám nha khoa tư nhân ở Lâm Đồng tra quy trình tiếp đón, ví dụ giả định. Nhân viên lễ tân hỏi: khách đặt lịch qua tin nhắn rồi không đến thì xử lý thế nào. Khâu tìm so câu hỏi với các đoạn tài liệu và lấy ra bốn đoạn: một đoạn về xác nhận lịch hẹn, một đoạn về khách đến muộn, một đoạn về huỷ lịch, và một đoạn về chăm sóc khách sau điều trị vì có chữ "không đến tái khám".
Mô hình đọc bốn đoạn và viết câu trả lời. Nó dùng đúng đoạn về huỷ lịch, nhưng vì đoạn về khách đến muộn nằm ngay bên cạnh, nó ghép thêm một câu rằng lịch được giữ mười lăm phút, một chi tiết thuộc tình huống khác. Câu trả lời trông đầy đủ và có trích dẫn, nhưng lẫn hai quy định.
Người quản lý trợ lý sửa không phải bằng cách thêm quy tắc, mà bằng cách tách tài liệu: mỗi tình huống một mục có tiêu đề rõ như "khách không đến, không báo trước" và "khách đến muộn", mỗi mục nhắc lại đầy đủ đối tượng áp dụng. Lần hỏi sau, khâu tìm lấy đúng mục, và mô hình không còn gì để ghép nhầm.
Viết tài liệu thân thiện với khâu tìm
Mỗi mục tự đủ nghĩa. Vì đoạn có thể bị lấy ra một mình, những cụm như "như trên", "trường hợp này", "nhóm đã nêu" mất nghĩa. Nhắc lại đối tượng đầy đủ trong mỗi mục.
Tiêu đề mang từ khoá của người hỏi. Khâu tìm so câu hỏi với nội dung. Nếu người dùng hay hỏi "khách quên mật khẩu" mà tài liệu ghi "khôi phục thông tin xác thực", hai bên có thể vẫn khớp nhờ tìm theo nghĩa, nhưng đặt cả hai cách gọi vào tiêu đề làm việc tìm chắc chắn hơn.
Điều kiện đi cùng quy định. Quy định ở chương hai còn ngoại lệ ở phụ lục cuối là cấu trúc dễ khiến trợ lý trả lời thiếu. Ghi ngoại lệ ngay dưới quy định, hoặc ít nhất ghi "xem ngoại lệ ở mục nào" ngay tại chỗ.
Bảng có tiêu đề cột rõ. Bảng bị cắt giữa chừng sẽ mất dòng tiêu đề. Bảng ngắn, mỗi bảng một chủ đề, có câu dẫn mô tả bảng nói về gì, sẽ ít bị hiểu sai hơn.
Thuật ngữ thống nhất. Một khái niệm gọi ba tên ở ba tài liệu khiến khâu tìm và cả mô hình lúng túng. Chọn một tên chính, ghi các tên khác trong mục thuật ngữ.
RAG, tinh chỉnh mô hình và dán thẳng tài liệu: khác nhau ở đâu
Ngoài RAG, có hai cách hay được nhắc khi muốn AI biết kiến thức riêng. Cách thứ nhất là dán thẳng tài liệu vào cuộc trò chuyện. Với tài liệu ngắn, cách này đơn giản và đáng tin, vì mô hình đọc toàn bộ thay vì chỉ vài đoạn. Nó phù hợp cho việc làm một lần với một hai tài liệu, không phù hợp cho kho lớn dùng lâu dài.
Cách thứ hai là tinh chỉnh mô hình, tức huấn luyện thêm mô hình trên dữ liệu của bạn. Tinh chỉnh thường giúp mô hình quen với văn phong, định dạng, cách xử lý một loại việc, nhưng không phải cách tốt để nạp kiến thức hay thay đổi như quy định, giá, quy trình, vì mỗi lần đổi lại phải huấn luyện lại, và mô hình vẫn có thể nhớ sai. Tinh chỉnh cũng đòi hỏi chuyên môn và chi phí cao hơn nhiều.
Với phần lớn trợ lý chuyên môn của cá nhân và tổ chức nhỏ, sự kết hợp hợp lý là: hướng dẫn hệ thống và ví dụ mẫu lo phần cách trả lời, RAG hoặc tài liệu đính kèm lo phần nội dung, và dán thẳng tài liệu cho những việc đặc thù một lần. Tinh chỉnh chỉ nên tính tới khi đã có đội ngũ kỹ thuật và một nhu cầu mà ba cách kia không đáp ứng được.
Hiểu cơ chế để hỏi trợ lý tốt hơn
Biết trợ lý chỉ đọc vài đoạn cho mỗi câu hỏi, bạn sẽ hỏi khác đi. Một câu hỏi rõ, nhắc đúng tên quy trình hay tên sản phẩm, giúp khâu tìm lấy đúng đoạn. Một câu gộp ba việc làm khâu tìm phải chia số đoạn có hạn cho ba chủ đề, và câu trả lời thường mỏng ở cả ba.
Khi câu trả lời có vẻ thiếu, thay vì hỏi lại y nguyên, hãy hỏi cụ thể hơn về phần thiếu, hoặc yêu cầu trợ lý nêu đoạn tài liệu nó đã dùng. Nếu đoạn được nêu không liên quan, bạn biết lỗi ở khâu tìm và nên báo người quản lý trợ lý để chỉnh tài liệu.
Cuối cùng, nhớ rằng trích dẫn đúng nguồn không có nghĩa là hiểu đúng nguồn. Mô hình có thể lấy đúng đoạn nhưng đọc sai một điều kiện phủ định hay một ngoại lệ. Với những câu trả lời dẫn tới quyết định có hậu quả, mở đoạn gốc ra đọc vẫn là bước không nên bỏ.
Câu hỏi thường gặp
RAG có làm trợ lý hết bịa không?
Không. RAG giảm bịa khi tìm được đúng đoạn, vì mô hình có thông tin thật để dựa vào. Nhưng khi không tìm được đoạn phù hợp, mô hình vẫn có thể trả lời bằng kiến thức chung nghe hợp lý. Cần thêm quy tắc khoảng trống và yêu cầu ghi nguồn để giảm tiếp.
Tính năng đính kèm tài liệu trong công cụ chat có phải là RAG không?
Tuỳ công cụ và tuỳ dung lượng. Với tài liệu ngắn, nhiều công cụ đưa toàn bộ nội dung vào ngữ cảnh; với kho lớn, chúng thường dùng cơ chế tìm đoạn kiểu RAG. Chi tiết thay đổi theo phiên bản, nên kiểm tài liệu hướng dẫn hiện hành của công cụ bạn dùng.
Cửa sổ ngữ cảnh ngày càng lớn thì còn cần RAG không?
Cửa sổ lớn giúp đưa được nhiều tài liệu hơn trong một lần, nhưng chi phí, tốc độ và việc mô hình có thể bỏ sót chi tiết trong văn bản rất dài vẫn là lý do để lọc trước. Với kho tài liệu lớn và cập nhật thường xuyên, cách tra cứu vẫn hợp lý.
Embedding là gì, có cần hiểu sâu không?
Embedding là cách biểu diễn một đoạn văn thành một dãy số sao cho các đoạn có nghĩa gần nhau thì dãy số cũng gần nhau. Người dựng trợ lý bằng công cụ có sẵn không cần hiểu sâu; chỉ cần biết khâu tìm dựa vào độ gần nghĩa, nên tiêu đề và câu chữ rõ ràng giúp tìm đúng hơn.
Tài liệu tiếng Việt có bị tìm kém hơn tiếng Anh không?
Chất lượng tìm với tiếng Việt phụ thuộc vào mô hình biểu diễn mà công cụ dùng, và đã cải thiện nhiều. Cách chắc nhất là thử bằng bộ câu hỏi thật của bạn, bao gồm câu viết không dấu và viết tắt, để xem trợ lý có tìm đúng đoạn không.
Muốn tự dựng hệ thống RAG thì bắt đầu từ đâu?
Nếu không có nền tảng lập trình, nên bắt đầu bằng tính năng có sẵn trong công cụ chat để hiểu nhu cầu thật. Khi cần nối với hệ thống nội bộ hay kiểm soát dữ liệu chặt hơn, hãy làm việc với người có chuyên môn kỹ thuật, mang theo bộ câu hỏi thử và bảng kê tài liệu bạn đã có.