Nền tảng AI
Cách xây dựng chatbot: Kiến trúc, dữ liệu, an toàn và đánh giá
Thêm Unite.AI vào các nguồn ưu tiên của bạn trên Google
Chatbot là một ứng dụng nhận tin nhắn, xác định nhu cầu của người dùng và trả về phản hồi dưới dạng văn bản hoặc giọng nói. Các hệ thống hiện đại có thể kết hợp quy tắc, truy xuất, bộ phân loại, transformers, công cụ và các mô hình ngôn ngữ lớn thay vì chỉ dựa vào một mô hình.
Việc xây dựng một chatbot hữu ích do đó là một vấn đề về sản phẩm và hệ thống. Lớp hội thoại phải kết nối với kiến thức đáng tin cậy và các hành động kinh doanh, trong khi danh tính, quyền hạn, ghi nhật ký, đánh giá, dự phòng và tăng cấp con người giới hạn những gì bot được phép thực hiện.
Những điểm chính
- Bắt đầu với một nhiệm vụ người dùng hẹp và tiêu chí thành công có thể đo lường.
- Tách việc sinh ngôn ngữ ra khỏi truy xuất, công cụ, quyền hạn và quy tắc kinh doanh.
- Kiểm thử các cuộc hội thoại đầy đủ, bao gồm sự mơ hồ, gián đoạn, từ chối và phục hồi.
- Xem các prompt và đầu ra của mô hình như dữ liệu không tin cậy; giám sát môi trường sản xuất và duy trì các đường tăng cấp.
Xác định công việc trước khi chọn mô hình
Ghi lại người dùng là ai, họ đang cố gắng đạt được gì, dữ liệu nào hệ thống có thể truy cập và hành động nào cần xác nhận. Bot trả lời các câu hỏi thường gặp, trợ lý kiểm tra trạng thái đơn hàng và đại lý quản lý tài khoản có các hồ sơ rủi ro rất khác nhau.
Tạo một chuẩn không AI và một tập hợp các cuộc hội thoại đại diện để chấp nhận. Đo lường mức độ hoàn thành nhiệm vụ, hỗ trợ trả lời, độ trễ, bỏ cuộc, tăng cấp và chi phí của các lỗi gây hại. Một bản demo trôi chảy không phải là bằng chứng rằng quy trình làm việc hoạt động đáng tin cậy.
Sử dụng kiến trúc lớp
Một pipeline tiêu chuẩn bao gồm bộ điều hợp kênh, trạng thái phiên, xác thực đầu vào, logic định hướng hoặc ý định, truy xuất, mô hình phản hồi hoặc chính sách, bộ điều hợp công cụ và khả năng quan sát. Truy xuất có thể dựa câu trả lời trên các tài liệu đã được phê duyệt; công cụ thực hiện các hành động kiểm soát thông qua các schema rõ ràng.
Giữ các kiểm tra quyết định bên ngoài mô hình ngôn ngữ. Xác thực, ủy quyền, giới hạn tồn kho, hoàn tiền và các hành động không thể đảo ngược nên được thực thi bằng mã ứng dụng. Prompt engineering có thể định hình hành vi, nhưng nó không phải là một hệ thống kiểm soát truy cập.
Thiết kế hội thoại, kiến thức và phục hồi cùng nhau
Những cuộc hội thoại tốt xử lý các yêu cầu không đầy đủ, sửa lỗi, nhiều ý định và tham chiếu đến các lượt trước. Chỉ lưu trữ ngữ cảnh cần thiết cho nhiệm vụ, làm cho việc lưu trữ trở nên rõ ràng, và phân biệt câu phát biểu của người dùng với một thực tế đáng tin cậy được trả về bởi hệ thống đã được phê duyệt.
Khi mức độ tin cậy hoặc bằng chứng không đủ, bot nên đặt câu hỏi tập trung, đề xuất một lựa chọn an toàn, hoặc chuyển sang người có bản tóm tắt ngắn gọn. Phục hồi là một phần của trải nghiệm cốt lõi — không phải một trường hợp biên được thêm vào sau khi ra mắt.
Đánh giá và vận hành toàn bộ hệ thống
Kiểm thử chất lượng truy xuất, lựa chọn công cụ, độ chính xác lập luận, tuân thủ chính sách, khả năng chống tấn công chèn prompt, rò rỉ quyền riêng tư và kết quả đầu cuối. Thực hiện các đầu vào đối kháng red‑team và xác minh rằng một tài liệu độc hại không thể âm thầm ghi đè hướng dẫn của hệ thống.
Phiên bản các prompt, chỉ mục, mô hình, chính sách và công cụ. Xem xét các cuộc hội thoại mẫu với kiểm soát quyền riêng tư, theo dõi sự trôi dạt và các cụm lỗi, và duy trì khả năng quay lại. Kỷ luật vận hành này liên kết phát triển chatbot với AIOps và phản hồi sự cố.
Các thành phần cốt lõi của chatbot chi tiết hơn
Lớp kênh chuẩn hóa đầu vào từ trò chuyện web, ứng dụng di động, nền tảng nhắn tin hoặc giọng nói. Lớp phiên gắn các tin nhắn với một cuộc hội thoại đã xác thực hoặc ẩn danh, thực thi thời gian hết hạn và chỉ lưu trạng thái cần thiết cho nhiệm vụ. Kiểm soát đầu vào giới hạn kích thước và loại tệp, phát hiện tải trọng không an toàn và loại bỏ markup mà các hệ thống hạ nguồn không nên thực thi.
Một bộ định tuyến sau đó quyết định yêu cầu thuộc luồng quyết định, tìm kiếm, sinh hay hàng đợi con người. Các bộ phân loại ý định cổ điển vẫn hữu ích khi tập nhãn ổn định; các mô hình ngôn ngữ linh hoạt hơn nhưng khó hiệu chỉnh hơn. Bộ định tuyến hỗn hợp có thể dành các nhiệm vụ được điều chỉnh hoặc khối lượng lớn cho các quy trình đã kiểm thử và dùng mô hình chung cho các giải thích mở rộng.
Lớp phản hồi nên mang bằng chứng và trạng thái riêng biệt. Một câu được sinh ra có thể trích dẫn một đoạn được truy xuất, nhưng ứng dụng phải bảo quản nguồn và phiên bản đã hỗ trợ. Bộ nhớ hội thoại nên phân biệt sở thích người dùng với dữ liệu tài khoản đã xác thực, và không bao giờ cho phép một tin nhắn người dùng cũ cấp quyền mới.
Truy xuất, công cụ và giao dịch
Chất lượng truy xuất bắt đầu trước tìm kiếm vector. Tài liệu cần có quyền sở hữu, nhãn truy cập, phiên bản chuẩn, các đoạn hữu ích và ngày loại bỏ. Việc viết lại truy vấn, tìm kiếm từ khóa, embedding, bộ lọc và sắp xếp lại có thể được kết hợp. Đánh giá nên đo lường liệu bằng chứng cần thiết đã được truy xuất, các đoạn không liên quan đã bị loại bỏ, và câu trả lời có thực sự dựa trên bằng chứng hay không.
Công cụ chuyển đề xuất của mô hình thành một yêu cầu có kiểu cho mã ứng dụng. Mỗi công cụ cần một mục đích hẹp, schema rõ ràng, xác thực phía máy chủ, thông tin xác thực tối thiểu, thời gian chờ, tính không thay đổi khi có thể và kết quả rõ ràng. Mô hình không nên tạo truy vấn cơ sở dữ liệu thô hoặc URL tùy ý khi một hoạt động kinh doanh có giới hạn có thể được phơi bày thay thế.
Giao dịch yêu cầu xác nhận tại thời điểm cam kết. Hiển thị cho người dùng các trường vật liệu — người nhận, số tiền, địa chỉ, ngày hoặc thay đổi quyền truy cập — và không coi một “có” cũ là sự chấp thuận cho hành động mới. Đối với công việc đa bước, giữ một máy trạng thái bên ngoài mô hình để một lần thử lại hoặc tin nhắn được sắp xếp lại không thể bỏ qua cổng bắt buộc.
Kế hoạch xây dựng và đánh giá thực tiễn
Bắt đầu với hai mươi đến năm mươi nhiệm vụ đại diện và bao gồm các yêu cầu không thành công, mơ hồ và ngoài phạm vi. Đánh dấu hành động dự kiến, bằng chứng, tăng cấp và hành vi bị cấm. Triển khai luồng khả thi đơn giản nhất, sau đó chỉ thêm truy xuất hoặc sinh khi nó cải thiện kết quả đo lường. Điều này tạo ra một bộ kiểm thử hồi quy có thể tái sử dụng trước khi giao diện trở nên phức tạp.
Đánh giá các thành phần và cuộc hội thoại riêng biệt. Các chỉ số truy xuất, độ chính xác gọi công cụ, kiểm tra chính sách và hỗ trợ phản hồi chẩn đoán các lỗi cụ thể; mức độ hoàn thành nhiệm vụ và nỗ lực người dùng tiết lộ chất lượng ở cấp hệ thống. Sử dụng các bài kiểm tra đa lượt sửa các chi tiết trước, gián đoạn luồng, chuyển chủ đề, giữ lại thông tin cần thiết và gây ra lỗi phụ thuộc.
Việc triển khai sản xuất nên được phân giai đoạn theo nhóm người dùng, nhiệm vụ và quyền hạn. Giám sát các tuyên bố không được hỗ trợ, các lần làm rõ lặp lại, từ chối công cụ, tăng cấp, độ trễ và bỏ cuộc. Xem xét các mẫu an toàn quyền riêng tư, duy trì đường tắt khẩn cấp cho mỗi công cụ, và sử dụng kết quả sự cố để cập nhật prompt, dữ liệu, mã và bộ kiểm thử đồng thời.
Ví dụ thực tế: chatbot hỗ trợ từ nguyên mẫu đến sản xuất
Giả sử một nhà bán lẻ muốn một chatbot trả lời các câu hỏi về đơn hàng và trả hàng. Đầu tiên xác định các ý định được hỗ trợ, điều kiện tăng cấp, kiến thức đã phê duyệt, quy tắc xác thực và các hành động bị cấm. Xây dựng bộ kiểm thử từ các câu hỏi lịch sử đã được ẩn danh, bao gồm yêu cầu mơ hồ, lỗi chính tả, đầu vào đa ngôn ngữ, người dùng giận dữ, chèn prompt và các câu hỏi không có câu trả lời. Một chuẩn truy xuất nên trả về bằng chứng trước khi bất kỳ phản hồi sinh nào được phép tuyên bố chính sách hoặc trạng thái đơn hàng.
Thời gian chạy có thể phân loại ý định, truy xuất các đoạn chính sách, yêu cầu xác thực danh tính chỉ khi cần dữ liệu tài khoản, gọi API đơn hàng có phạm vi hẹp, soạn câu trả lời và đính kèm trích dẫn. Mỗi lần gọi công cụ cần một schema rõ ràng, kiểm tra ủy quyền, thời gian chờ, chính sách thử lại và khóa không thay đổi. Mô hình không bao giờ nên tạo truy vấn cơ sở dữ liệu thô hoặc tự quyết định quyền hạn. Các hành động có tác động lớn như hủy đơn hoặc hoàn tiền yêu cầu xác nhận và, nếu vượt qua giới hạn đã định, cần phê duyệt của con người.
Đánh giá độ chính xác ý định, độ đúng của câu trả lời, hỗ trợ bằng chứng, chất lượng từ chối, khả năng kiềm chế thành công, độ chính xác tăng cấp, độ trễ và chi phí mỗi cuộc hội thoại được giải quyết. Xem xét kết quả theo ý định và nhóm người dùng thay vì trung bình chung. Trong môi trường sản xuất, ghi nhật ký các vết theo đồng thuận, kết quả công cụ, phiên bản tài liệu truy xuất và các sửa chữa của người dùng. Triển khai dần dần, so sánh với kênh hiện có và vô hiệu hoá các khả năng khi vượt ngưỡng lỗi, lạm dụng hoặc phụ thuộc.
Danh sách kiểm tra triển khai thực tiễn
Biến khái niệm thành một quy trình có giới hạn, có thể kiểm thử: xác định nhiệm vụ → định tuyến → truy xuất → sinh → sử dụng công cụ → đánh giá. Đặt tên cho người chịu trách nhiệm, tài liệu dữ liệu và các phụ thuộc, thiết lập một chuẩn đơn giản, đặt tiêu chí chấp nhận và dừng, kiểm thử các thất bại đại diện, và xác định giám sát, quay lại và đánh giá trước khi mở rộng phạm vi. Ghi lại các phiên bản và giả định để đội khác có thể tái tạo kết quả và hiểu những gì đã thay đổi.
Trước khi ra mắt, thực hiện một cuộc đánh giá sẵn sàng có tài liệu với những người xây dựng, vận hành, bảo mật và bị ảnh hưởng bởi hệ thống. Kiểm thử các trường hợp bình thường, điều kiện biên, lỗi phụ thuộc và lạm dụng; bảo quản bằng chứng và các rủi ro chưa giải quyết. Xác định ai có thể phê duyệt phát hành, thay đổi ngưỡng, ghi đè đầu ra hoặc dừng hoạt động. Xem lại quyết định sau khi dữ liệu thực tế xuất hiện, vì một dự án thí nghiệm thành công về mặt kỹ thuật không đảm bảo hiệu suất đáng tin cậy ở quy mô rộng hơn.
- KIẾN THỨC: nguồn đã được phê duyệt và trích dẫn.
- HÀNH ĐỘNG: công cụ có kiểu dữ liệu với quyền tối thiểu.
- PHỤC HỒI: làm rõ, từ chối hoặc tăng cấp.
Câu hỏi thường gặp
Chatbot có cần mô hình ngôn ngữ lớn không?
Không. Các quy tắc, tìm kiếm, biểu mẫu và bộ phân loại nhỏ có thể an toàn và rẻ hơn cho các nhiệm vụ hẹp. Một LLM hữu ích khi khả năng hiểu hoặc sinh ngôn ngữ linh hoạt mang lại giá trị đo lường được.
Cần kiểm thử gì trước khi ra mắt?
Các nhiệm vụ đại diện, yêu cầu không được hỗ trợ, ngôn ngữ mơ hồ, lỗi công cụ, ranh giới quyền riêng tư, prompt đối kháng, chuyển giao cho con người, độ trễ và độ chính xác của mọi hành động có hậu quả.
Tài liệu tham khảo chính
