Dựng chatbot nội bộ với Dify: RAG, phê duyệt và log an toàn
Playbook dựng trợ lý nội bộ bằng Dify theo luồng tri thức → AI xử lý → người duyệt → hành động. Phù hợp cho đội vận hành muốn thử nghiệm AI nhanh nhưng vẫn kiểm soát dữ liệu, chi phí và rủi ro.
Một nhân viên hỏi trên chat: “Khách này có được đổi trả không?”
Nếu chatbot trả lời theo kiến thức chung của mô hình, câu trả lời có thể rất tự tin nhưng lại không khớp với chính sách mới nhất. Nếu chatbot tự gửi email hoàn tiền hoặc sửa CRM, một lỗi nhỏ có thể trở thành sự cố vận hành.
Cách thực tế hơn là để AI làm phần AI phù hợp: đọc tài liệu, phân loại yêu cầu, soạn nháp và trả về dữ liệu có cấu trúc. Những hành động có hậu quả như gửi email, cập nhật khách hàng hoặc xóa dữ liệu nên đi qua một cổng phê duyệt của con người.
Dify là nền tảng mã nguồn mở để phát triển ứng dụng LLM. Nền tảng này kết hợp workflow AI, pipeline RAG, khả năng agent, quản lý model và các tính năng quan sát vận hành. Nếu đang dùng n8n, Make, Zapier, Power Automate hoặc Apps Script, bạn có thể xem Dify là nơi xây phần xử lý AI; công cụ automation hiện có tiếp tục đảm nhiệm trigger và action.
Chọn đúng bài toán: agent không thay thế mọi workflow
Trước khi mở Dify, hãy tách rõ hai loại quy trình.
Workflow cố định phù hợp khi các bước không cần suy luận. Ví dụ: có form mới thì thêm một dòng vào sheet; đến hạn thì gửi nhắc việc; file xuất hiện thì đổi tên và lưu kho. Những luồng này nên chạy bằng điều kiện rõ ràng để dễ kiểm tra và ít biến động.
Workflow AI hoặc agent phù hợp khi đầu vào là ngôn ngữ tự nhiên, tài liệu dài hoặc câu hỏi mơ hồ. Chẳng hạn:
Nhân viên tra cứu chính sách bán hàng, đổi trả hoặc vận hành.
CSKH cần tóm tắt phản ánh và soạn trả lời dựa trên tài liệu nội bộ.
Đội vận hành nhận yêu cầu tự do, cần phân loại thành “tra cứu”, “tạo ticket” hoặc “cần người xử lý”.
IT generalist cần biến yêu cầu của người dùng thành dữ liệu có cấu trúc để đưa sang CRM hoặc hệ thống ticket.
Đừng bắt đầu bằng một agent “làm mọi thứ”. Hãy chọn một việc hẹp, có nguồn tri thức xác định và có cách kiểm tra đầu ra.
Kiến trúc nên dùng: trigger → tri thức → AI → duyệt → action → log
Một luồng nội bộ có kiểm soát có thể thiết kế theo sáu bước:
Trigger: người dùng gửi câu hỏi từ chat nội bộ, form hoặc webhook của công cụ automation.
Knowledge base / RAG: hệ thống truy xuất nội dung liên quan từ tài liệu nội bộ.
Bước AI: model trả lời, phân loại mức rủi ro và đề xuất hành động dưới dạng dữ liệu có cấu trúc.
Cổng phê duyệt: người có trách nhiệm đọc bản nháp, sửa nếu cần, rồi chấp nhận hoặc từ chối.
Action: chỉ sau khi được duyệt, workflow mới gửi email, ghi CRM, tạo ticket hoặc cập nhật sheet.
Log và quan sát: lưu đầu vào, nguồn tham chiếu, đầu ra AI, quyết định duyệt và kết quả action.
RAG là viết tắt của Retrieval-Augmented Generation. Trước khi sinh câu trả lời, hệ thống truy xuất các đoạn tài liệu liên quan để đưa vào ngữ cảnh. Đây là khác biệt quan trọng giữa chatbot trả lời theo kiến thức chung và chatbot bám vào chính sách nội bộ.
README của Dify nêu các nhóm tính năng gồm workflow AI, pipeline RAG, khả năng agent, quản lý model và observability. Dify cũng đề cập các tích hợp quan sát như Opik, Langfuse và Arize Phoenix. Những công cụ này có thể hữu ích khi đội vận hành cần lần lại AI đã nhận gì, trả lời gì và lỗi phát sinh ở đâu.
Bắt đầu với Dify Cloud hoặc tự host bằng Docker
Nếu ưu tiên thử nghiệm nhanh, Dify có Dify Cloud. Nếu đội cần tự kiểm soát hạ tầng triển khai, có thể chọn self-host.
Theo README, yêu cầu tối thiểu cho máy chạy Dify là:
CPU từ 2 core
RAM từ 4 GiB
Cách khởi động được README đề xuất là Docker Compose. Bạn cần Docker daemon đang chạy, Docker Compose từ v2.35.0 trở lên và OpenSSL.
Từ thư mục gốc của mã nguồn, chạy:
bash
cd docker
cp .env.example .env
openssl rand -hex 32
Lệnh cuối tạo một giá trị bí mật. Mở file .env và đặt giá trị vừa sinh cho DIFYAGENTLOCALSANDBOXAUTHTOKEN. README khuyến nghị giữ giá trị COMPOSEPROFILES mặc định để các dịch vụ đi kèm được nạp theo cấu hình sẵn có.
Từ thư mục docker, chạy:
bash
docker compose up -d
docker compose ps --all
Khi các dịch vụ đã chạy, mở:
text
http://localhost/install
Self-host không đồng nghĩa với tự động an toàn
Tự host giúp đội bạn kiểm soát môi trường triển khai, nhưng vẫn cần quản lý quyền truy cập máy chủ, sao lưu, cập nhật, mạng nội bộ và secret.
Một số nguyên tắc cơ bản:
Không đưa file .env vào kho mã nguồn.
Giới hạn người có quyền đọc token và biến môi trường.
Không gửi token vào chat, ticket công khai hoặc prompt.
Với bản triển khai đang tồn tại, giữ file .env hiện có và xem hướng dẫn nâng cấp thay vì ghi đè cấu hình đang dùng.
Dựng knowledge base trước, rồi mới viết prompt
Knowledge base tốt không phải là nơi ném mọi PDF vào. Hãy bắt đầu với một phạm vi rõ ràng, ví dụ:
Chính sách đổi trả.
Quy trình xử lý khiếu nại.
Hướng dẫn tạo ticket.
Quy định bàn giao giữa các bộ phận.
Trước khi nạp tài liệu, đội nghiệp vụ nên rà lại:
Tài liệu nào là bản chính thức và còn hiệu lực?
Ai chịu trách nhiệm cập nhật?
Có tài liệu nào chứa dữ liệu khách hàng, thông tin tài chính hoặc bí mật kinh doanh không?
Nếu không tìm thấy nguồn phù hợp, chatbot phải phản hồi thế nào?
Quy tắc nên đặt ra: không có đủ tài liệu liên quan thì AI phải nói chưa đủ căn cứ, không tự suy đoán chính sách. Với câu hỏi nhạy cảm, luồng nên chuyển sang người phụ trách thay vì đưa ra kết luận cuối.
Ví dụ prompt cho bước AI sau khi truy xuất tri thức:
text
Bạn là trợ lý vận hành nội bộ cho <phòngban>.
Chỉ sử dụng thông tin trong ngữ cảnh knowledge base được cung cấp.
Nếu không có đủ căn cứ, không suy đoán.
Yêu cầu người dùng:
<userrequest>
Hãy trả về JSON hợp lệ theo cấu trúc:
{
"answer": "<câu trả lời ngắn gọn bằng tiếng Việt>",
"confidence": "<high|medium|low>",
"risklevel": "<low|medium|high>",
"recommendedaction": "<replyonly|createticket|draftemail|updatecrm|humanreview>",
"reasonforreview": "<lý do hoặc chuỗi rỗng>",
"sourcesused": ["<tên hoặc định danh nguồn>"]
}
Đầu ra JSON giúp các bước phía sau dễ kiểm tra và rẽ nhánh hơn văn bản tự do. Ví dụ, công cụ automation có thể đọc recommendedaction và risklevel trước khi quyết định có được chạy action tiếp theo hay không.
Ví dụ: bot CSKH chỉ tạo nháp, không tự gửi
Giả sử người dùng gửi từ form hoặc chat nội bộ:
text
Khách yêu cầu đổi sản phẩm đã mua. Hãy cho biết điều kiện và soạn email phản hồi.
Luồng AI truy xuất knowledge base về đổi trả, sau đó trả về dữ liệu như sau:
json
{
"answer": "Đã tìm thấy hướng dẫn liên quan. Cần kiểm tra thêm tình trạng đơn hàng trước khi xác nhận.",
"confidence": "medium",
"risklevel": "medium",
"recommendedaction": "draftemail",
"reasonforreview": "Email liên quan đến cam kết với khách hàng.",
"sourcesused": ["<chínhsáchđổitrả>"]
}
Từ đây, workflow bên ngoài hoặc phần điều phối do đội bạn thiết kế có thể xử lý:
Nếu confidence là low: tạo ticket cho người phụ trách, không tạo câu trả lời cuối.
Nếu risklevel là high: bắt buộc người phụ trách xem lại.
Nếu recommendedaction là draftemail: chỉ tạo bản nháp để người duyệt chỉnh sửa.
Chỉ khi trạng thái phê duyệt là approved: mới gửi email hoặc cập nhật CRM.
README giới thiệu workflow và khả năng agent, nhưng phần tài liệu được cung cấp không mô tả một cấu hình approval gate cụ thể. Vì vậy, không nên mặc định mọi action đã có sẵn cổng duyệt. Hãy chủ động thiết kế các trạng thái như pendingreview, approved và rejected trong công cụ workflow hoặc hệ thống nghiệp vụ của bạn.
Kiểm tra đầu ra, retry có kiểm soát và theo dõi chi phí
Trước khi chạy action, thêm các kiểm tra đơn giản:
JSON có hợp lệ không?
Có đủ trường bắt buộc không?
sourcesused có rỗng không?
risklevel có thuộc nhóm giá trị cho phép không?
Action có đúng quyền của người duyệt không?
Retry hữu ích khi lỗi đến từ kết nối model, API hoặc bước downstream. Tuy nhiên, chỉ nên retry với thao tác không tạo hậu quả lặp.
Ví dụ, truy xuất tài liệu hoặc tạo bản nháp có thể thử lại. Nhưng gửi email, ghi giao dịch hoặc cập nhật CRM cần cơ chế tránh thực thi trùng lặp. Nếu chưa có cơ chế này, hãy dừng luồng và báo người vận hành.
README xác nhận Dify có quản lý model, nhưng không nêu mức giá, hạn mức sử dụng hoặc chi phí theo model trong phần tài liệu này. Vì vậy, đội vận hành nên tự đặt giới hạn thực tế:
Giới hạn độ dài đầu vào.
Chỉ nạp tài liệu thực sự cần thiết.
Theo dõi yêu cầu thất bại hoặc bị gọi lặp.
Không đưa khóa API vào prompt, form hoặc log ứng dụng.
Log tối thiểu nên có:
ID yêu cầu và thời điểm chạy.
Người hoặc hệ thống khởi tạo.
Phiên bản knowledge base và nguồn đã dùng.
Đầu ra JSON của AI.
Người duyệt, quyết định duyệt và lý do.
Kết quả action hoặc thông báo lỗi.
Dữ liệu khách hàng trong log cần được giảm thiểu và phân quyền truy cập. Với self-host, token sandbox và biến môi trường là bí mật vận hành.
Checklist trước khi mở cho cả công ty
[ ] Chọn một use case hẹp, có chủ sở hữu nghiệp vụ.
[ ] Knowledge base chỉ chứa tài liệu đã kiểm tra hiệu lực.
[ ] Prompt yêu cầu đầu ra có cấu trúc cho các bước cần tự động hóa.
[ ] Không đủ căn cứ thì chuyển người phụ trách, không suy đoán.
[ ] Email, tiền, xóa dữ liệu và CRM có bước phê duyệt.
[ ] Retry không tạo hành động lặp.
[ ] Có log cho truy xuất, đầu ra AI, phê duyệt và action.
[ ] API key, token và dữ liệu khách hàng không nằm trong prompt hoặc log mở.
[ ] Theo dõi lỗi, mức dùng model và các câu trả lời bị người duyệt sửa nhiều.
Dify giúp rút ngắn quãng đường từ prototype đến ứng dụng AI. Nhưng giá trị thực với đội automation không nằm ở việc dựng chatbot thật nhanh. Giá trị nằm ở một luồng có tri thức để hỗ trợ, có người giữ quyền quyết định và có khả năng truy vết khi xảy ra sự cố.