Ví dụ nhé. Thứ Hai, một bạn mới vào làm hỏi trong kênh chung: “Nghỉ không lương thì xin trước mấy ngày vậy mọi người?” Câu hỏi dễ. Vậy mà đến thứ Tư mới có câu trả lời.
Câu trả lời nằm rải ở ba nơi. Điều khoản chính nằm trong một file PDF mà chẳng ai nhớ đường dẫn. Phần ngoại lệ nằm trong một thread Slack từ mười tháng trước. Còn cách làm thật hằng ngày thì nằm trong đầu chị phụ trách nhân sự — chị ấy đi công tác hai hôm.
Nghe quen không? Đó là một trong những lý do chúng tôi bắt tay vào xây dựng hệ thống RAG doanh nghiệp nội bộ. Không phải để có thêm một con bot trả lời cho vui, mà để những câu hỏi kiểu trên có đáp án trong ba mươi giây — kèm nguồn, kèm phân quyền, và tự cập nhật khi tài liệu thay đổi.
RAG là gì?
RAG là viết tắt của Retrieval-Augmented Generation — tạm dịch: sinh văn bản có tra cứu hỗ trợ. Nghe kỹ thuật, nhưng ý tưởng thì rất đời thường.
Hãy tưởng tượng một nhân viên mới cực kỳ thông minh, nhưng mới vào tuần này. Bạn không thể bắt họ học thuộc toàn bộ quy định, hợp đồng và biên bản họp ba năm qua. Bạn chỉ có thể đưa cho họ một cuốn sổ tra cứu thật tốt, rồi dạy cách tra.
RAG chọn cách sau. Hệ thống chia tài liệu thành từng đoạn nhỏ (chunk), chuyển mỗi đoạn thành một vector số (embedding), rồi lưu vào cơ sở dữ liệu vector. Khi có câu hỏi, nó tìm những đoạn gần nghĩa nhất, đưa vào prompt, và mô hình ngôn ngữ trả lời — chỉ dựa trên những gì vừa được đưa vào.
Vậy vì sao không nhét hết tài liệu vào một chatbot rồi bảo nó ghi nhớ?
- Cửa sổ ngữ cảnh có hạn. Nhét vài nghìn trang vào một lần hỏi là chuyện không làm được.
- Tài liệu thay đổi mỗi tuần. Học lại từ đầu sau mỗi lần sửa là cách chắc chắn nhất để trả lời bằng thông tin cũ.
- Không truy được nguồn. Khi con bot nói “nhân viên được nghỉ 12 ngày”, bạn cần biết con số đó lấy từ đâu.
- Không phân quyền được. Người mới vào và người ở phòng kế toán không nên đọc cùng một tập tài liệu.
RAG tách hai việc ra: tìm và viết. Việc nào sai thì sửa việc đó.
Xây dựng hệ thống RAG doanh nghiệp nội bộ: 5 bước chúng tôi thường đi
1. Chọn phạm vi tài liệu — và nói không với phần lớn trong đó.
Đây là bước bị xem nhẹ nhất, mà lại quyết định nhất. Chúng tôi từng thấy những đội muốn nạp hết: wiki nội bộ, Drive cá nhân, email tám năm, thư mục scan hợp đồng. Kết quả là trả lời được rất nhiều thứ, nhưng không thứ nào đáng tin.
Cách làm của chúng tôi là bắt đầu bằng câu hỏi, không phải bằng tài liệu. Hỏi nhân viên: tuần trước bạn phải đi tìm cái gì? Rồi chọn ba đến năm chủ đề có lượng câu hỏi lặp lại cao nhất — nhân sự, quy trình nội bộ, thông số sản phẩm.
2. Làm sạch và chia nhỏ tài liệu.
Tài liệu nội bộ thật thường xấu: tiêu đề lộn xộn, bảng biểu vỡ khi chuyển từ Word, ảnh chụp màn hình không có chữ. Bước này tốn thời gian nhất và không có cách nào né.
Chia nhỏ cũng cần chút khéo. Đoạn quá dài thì thông tin bị loãng, mô hình lấy nhầm ý. Đoạn quá ngắn thì mất ngữ cảnh — một câu trích ra khỏi điều khoản có thể mang nghĩa ngược lại. Chúng tôi chia theo cấu trúc gốc (mục, điều, phần) rồi cho các đoạn chồng lên nhau một chút.
3. Chọn embedding và nơi lưu vector.
Với tiếng Việt, đây là chỗ dễ sai nhất nếu chọn mô hình embedding theo thói quen tiếng Anh. Cách kiểm tra nhanh: lấy vài chục câu hỏi thật kèm câu trả lời đúng, rồi xem mô hình có đưa đúng đoạn lên đầu không. Nơi lưu vector thì tùy quy mô — vài nghìn đoạn chưa cần hạ tầng cầu kỳ.
4. Thiết kế prompt trả lời.
Prompt là nơi chúng tôi đặt luật chơi. Ba luật quan trọng nhất:
- Chỉ trả lời bằng thông tin trong đoạn vừa được cung cấp.
- Nếu không đủ thông tin, nói thẳng là không biết — và chỉ chỗ để hỏi tiếp.
- Luôn kèm tên tài liệu và mục mà câu trả lời lấy ra.
Luật thứ hai khó chấp nhận nhất. Nhưng trợ lý dám nói “tôi không biết” thì còn dùng được lâu dài. Trợ lý đoán bừa thì chỉ cần sai một lần là cả công ty thôi tin.
5. Đo chất lượng bằng câu hỏi thật của nhân viên.
Đừng đo bằng bộ câu hỏi tự nghĩ ra. Lấy log câu hỏi thật từ kênh chat nội bộ, từ ticket, từ hộp thư chung. Theo dõi hai thứ riêng biệt: hệ thống có tìm đúng đoạn không, và câu trả lời có đúng không.
Đây là hai lỗi khác nhau. Tìm sai đoạn thì vấn đề nằm ở chia nhỏ hoặc embedding. Tìm đúng mà trả lời sai thì vấn đề nằm ở prompt.
RAG cho doanh nghiệp truy vấn tài liệu nội bộ phải kèm trích dẫn
Trả lời đúng mà không nói nguồn thì vẫn chưa dùng được. Người hỏi cần biết câu trả lời lấy từ đâu — vì tài liệu nội bộ thường có nhiều phiên bản, và bản mới nhất mới là bản đúng.
Nên trong mọi hệ thống RAG cho doanh nghiệp truy vấn tài liệu nội bộ, chúng tôi gắn trích dẫn vào từng câu trả lời: tên tài liệu, số mục, ngày cập nhật, và đường dẫn mở bản gốc.
Song song với trích dẫn là phân quyền — chỗ những bản demo đẹp thường sụp đổ khi vào công ty thật. Một hệ thống chỉ tìm kiếm rồi trả lời sẽ trả lời cả câu hỏi về bảng lương cho bất kỳ ai gõ đúng từ khóa.
Cách chúng tôi làm: lọc theo vai trò ở tầng truy vấn, trước khi mô hình nhìn thấy dữ liệu. Prompt là chỉ dẫn, không phải hàng rào. Hàng rào nằm ở danh sách đoạn ứng viên được lọc theo đúng quyền của người hỏi.
Còn một thứ ít ai nghĩ tới: tài liệu hết hạn. Quy định cũ, biểu mẫu cũ, chính sách đã thay. Chúng tôi thêm ngày hiệu lực vào từng đoạn, và khi tài liệu xung đột, ưu tiên bản mới hơn kèm ghi chú rằng có bản cũ đang tồn tại.
Những cạm bẫy chúng tôi từng gặp
Tài liệu trùng lặp. Cùng một quy trình lưu ở bốn nơi, mỗi nơi sửa một chút. Hệ thống tìm ra cả bốn và trả lời lẫn lộn. Cách xử lý không nằm ở code — mà ở việc chọn một nguồn chính thức cho mỗi chủ đề.
Chunk quá to hoặc quá nhỏ. Quá to thì trả lời lan man, lấy chi tiết phụ làm chi tiết chính. Quá nhỏ thì mất ngữ cảnh, đôi khi trả lời ngược nghĩa. Không có con số đúng cho mọi bộ tài liệu — phải thử.
Tài liệu cũ không ai dọn. Một quy định từ hai năm trước, vẫn nằm trong thư mục, vẫn được trích dẫn như thật. Đây là lỗi tốn kém nhất.
Kỳ vọng sai. RAG không chữa được dữ liệu bẩn. Nếu quy trình chưa từng được viết ra, hoặc mỗi người làm một kiểu, thì không mô hình nào đoán đúng ý bạn. Làm rõ quy trình thường tốn thời gian hơn cả xây hệ thống — và cũng tạo ra giá trị nhiều nhất.
Khi nào RAG chưa đủ
RAG rất giỏi một việc: tìm thông tin có trong tài liệu của bạn. Nó không giỏi việc khác, và biết ranh giới này giúp tiết kiệm rất nhiều tiền.
RAG không đủ khi:
- Câu trả lời phải tính toán trên dữ liệu thay đổi liên tục — tồn kho, doanh thu hôm nay, lịch giao hàng.
- Công việc cần làm thật, không chỉ trả lời: tạo đơn, gửi thư, cập nhật CRM.
- Một việc cần phối hợp nhiều bước, có bước sau phụ thuộc kết quả bước trước.
- Dữ liệu quá nhạy cảm để gửi ra ngoài, buộc phải chạy mô hình tại chỗ.
Với những trường hợp đó, RAG thường là một phần của hệ thống lớn hơn — ghép với công cụ, với agent nhiều bước, hoặc với mô hình nhỏ chạy ngay trên hạ tầng của bạn. Chúng tôi viết kỹ hơn ở bài viết về SLM Local và multi-agent.
Bắt đầu từ đâu
Đừng bắt đầu bằng việc chọn mô hình. Bắt đầu bằng một thư mục gồm những tài liệu đồng nghiệp đang phải hỏi nhau nhiều nhất, và một danh sách hai mươi câu hỏi thật.
Muốn đi nhanh hơn thì chúng tôi có thể xem cùng bạn. Ở Mon AI, chúng tôi thiết kế và xây những hệ thống tra cứu tri thức nội bộ như vậy — bắt đầu từ chính quy trình của bạn, chứ không phải từ một mô hình có sẵn. Xem qua cách chúng tôi xây agent, hoặc nhắn cho chúng tôi một câu hỏi — kể cả khi bạn mới chỉ tò mò liệu tài liệu công ty mình có đủ sạch để bắt đầu.
