AI mua về cả đống nhưng vẫn không thể triển khai: Hệ thống nhân viên số được thiết kế và phát triển như thế nào

许愿牛科技 Lượt xem 63

Doanh nghiệp đã mua khá nhiều AI, nhưng các câu lệnh gợi ý vẫn chỉ nằm trên máy tính cá nhân, quy trình thì rải rác trong các tài liệu, và ngay cả sau khi các tác tử thông minh được đưa vào vận hành …

Trong hai năm qua, doanh nghiệp đã mua sắm khá nhiều công cụ AI: trợ lý trò chuyện, plugin viết lách, chatbot chăm sóc khách hàng, cũng như hệ thống hỏi đáp kiến thức nội bộ. Tuy nhiên, những năng lực thực sự được tích lũy lại không nhiều. Các câu lệnh gợi ý vẫn nằm trong máy tính cá nhân, quy trình nghiệp vụ thì rải rác ở các góc tài liệu, sau khi triển khai các tác nhân thông minh lại thiếu phản hồi và chỉnh sửa, còn đội ngũ nòng cốt trong doanh nghiệp vẫn bị những dạng tư vấn giống nhau chiếm hết thời gian làm việc. Vấn đề thường không phải là mô hình chưa đủ thông minh, mà làHệ thống chưa thiết kế “làm việc” thành năng lực vị trí công việc có thể quản lý được

Thiết kế vị trí công việc của nhân viên số dựa trên quy trình đối chiếu giữa sản phẩm và nghiên cứu phát triển

Trước tiên cần làm rõ: Tại sao cửa sổ trò chuyện không thể trở thành vị trí công việc?

Chatbot chỉ trả lời một lần rồi kết thúc. Các vị trí công việc cần tiếp nhận liên tục: thu thập thông tin, xác định quy tắc, gọi hệ thống, ghi lại trạng thái, và nếu gặp ngoại lệ thì mới chuyển lên cấp cao hơn. Hoàn ứng chi phí đi công tác là ví dụ điển hình — người dùng có thể trước tiên nói “Hãy giúp tôi báo cáo chi phí đi công tác”, giữa chừng lại hỏi “Hạn mức tháng này còn bao nhiêu”, rồi sau đó bổ sung thêm một hóa đơn. Nếu hệ thống coi mỗi lần trò chuyện đều là một hội thoại mới, quy trình sẽ bị gián đoạn, ngữ cảnh sẽ bị mất, và sau này cũng không thể xem xét lại được liệu lỗi nằm ở quy tắc hay ở giao diện.

Trong ngành đã có cách thức xây dựng các tác nhân thông minh theo kiểu “nhân viên số”: gán cho chúng vị trí công việc, mã số nhân viên, ranh giới năng lực và hồ sơ công việc, đồng thời trang bị thêm SOP có thể chỉnh sửa, cơ sở tri thức, các công cụ và lộ trình thực thi. Về phương hướng mã nguồn mở, StaffDeck do OpenBMB và một số tổ chức khác phát hành đã coi Agent như một tổ hợp tài nguyên có thể vận hành, thay vì chỉ là một đoạn lời nhắc. Đối với các doanh nghiệp tự nghiên cứu hoặc tùy chỉnh, điều đáng học hỏi không phải là tên gọi sản phẩm, mà chính là mô hình đối tượng này.

Logic nghiệp vụ: Trong hệ thống phải có ít nhất bảy loại đối tượng

Khi xây dựng hệ thống nhân viên số, trước tiên cần đưa các đối tượng nghiệp vụ vào trong đặc tả, sau đó mới bàn đến việc lựa chọn mô hình.

  1. Hồ sơ vị trí công việc: Họ tên hoặc tên nhân vật, số hiệu công việc, chức trách, trạng thái trực tuyến, đối tượng phục vụ. Nếu không có hồ sơ, quyền hạn và đánh giá sẽ không có chỗ để gắn kết.
  2. Ranh giới năng lực: Có thể đọc những chứng từ nào, có thể viết những trường nào, không thể cam kết điều gì. Các ranh giới phải có thể được quản trị viên chỉnh sửa, chứ không phải được cố định cứng trong câu lệnh gợi ý.
  3. Kỹ năng theo quy trình / SOP: Chia quy trình phức tạp thành các nút, hỗ trợ phân nhánh theo điều kiện, gọi công cụ, tra cứu kiến thức và chuyển sang nhân viên.
  4. Bản thể tri thức: Chủ đề, quy tắc, nguồn gốc và sổ tay hướng dẫn được lưu riêng biệt; câu trả lời phải có thể truy ngược về nguồn gốc, đồng thời việc tra cứu phải có khả năng điều chỉnh.
  5. Kết nối công cụ: Giao diện HTTP hoặc MCP, dùng để tra cứu hạn mức, tạo chứng từ, thay đổi trạng thái, chứ không chỉ là việc tạo ra một đoạn văn bản.
  6. Tác vụ định kỳ: Các công việc định kỳ như tổng hợp báo cáo hàng ngày, đôn đốc xử lý khi quá hạn, kiểm tra tồn kho… không thể chờ đến khi người dùng chủ động yêu cầu.
  7. Theo dõi và phản hồi: Ghi lại lộ trình, các bước, công cụ, kiến thức và phản hồi; đánh giá like hoặc dislike và chuyển giao cho nhân viên xử lý để tiến hành đợt chỉnh sửa tiếp theo.

Một yêu cầu thực tế thường bao gồm nhiều nhiệm vụ. Nhân viên số cần phải vào trước SOP hoàn tiền, thu thập đầy đủ các trường và thực hiện kiểm tra quy tắc, sau đó mới chuyển sang SOP tra cứu hạn mức để gọi API. Khi người dùng xen ngang hỏi về chính sách, cần lưu lại nút hiện tại, sau khi trả lời xong mới quay trở lại quy trình ban đầu. Đối với những câu hỏi vượt quá quy tắc, cần chuyển ngữ cảnh cho người tạo hoặc người trực, nghiêm cấm việc trả lời một cách tùy tiện mà không có căn cứ.

Logic thiết kế: vai trò, máy trạng thái, phân tầng kiến thức

Cách chuyển đổi vai trò như thế nào

Ít nhất chia thành bốn loại người:Người tạo(Đóng gói kinh nghiệm thành tài sản của nhân viên),Quản trị viên(quản lý quyền hạn, phát hành, hạn ngạch),Người sử dụng(Phân công công việc cho nhân viên số),Người trực ban(Đã tiếp tục xử lý ngoại lệ). Người tạo không nên mặc định có quyền sửa tồn kho, sửa giá; người sử dụng không nên nhìn thấy toàn bộ câu lệnh và khóa bí mật. Các giao diện mở cũng cần được phân tầng: khóa cấp tài khoản có thể quản lý việc cấu hình tài nguyên, còn khóa cấp nhân viên chỉ có thể tạo phiên và đọc nhật ký hoạt động của chính mình.

SOP sử dụng máy trạng thái, đừng chỉ dùng bộ nhớ đối thoại

Ngôn ngữ tự nhiên có thể tạo ra bản thảo đầu tiên, còn việc thực thi nhất định phải theo máy trạng thái: nút hiện tại, các slot đã thu thập, các công cụ có thể gọi, thử lại khi thất bại và nút thủ công. Khi nhiệm vụ bị gián đoạn, cần phải serial hóa ngữ cảnh và quay trở lại nút ban đầu để tiếp tục. Nhiều SOP cho phép chuyển đổi theo thời gian thực, nhưng khi chuyển đổi phải lưu lại “từ đâu đến, đã xác nhận những thông tin gì”, nhằm tránh người dùng phải điền biểu mẫu lặp lại. Phiên bản và nhánh phải có khả năng rollback; chỉ cần chỉnh sửa một câu từ gợi ý tại hiện trường là có thể đưa lên hệ thống, sau đó chắc chắn sẽ không thể truy cứu trách nhiệm.

Kiến thức không nên được tổng hợp thành một kho dữ liệu hỗn tạp để tra cứu.

Tạo chỉ mục có thể điều hướng theo tài liệu, chương, trang và tóm tắt; trước tiên xác định thông tin có thể thuộc loại nào, sau đó định vị văn bản gốc. Phân chia kiến thức thành các thùng riêng: tách biệt quy chuẩn hệ thống, mô tả sản phẩm, kịch bản hỗ trợ sau bán hàng và các trường hợp ngoại lệ; tra cứu định hướng sẽ ổn định hơn so với tìm kiếm từ khóa toàn diện. Mỗi câu trả lời đều được gắn với nguồn, quy tắc và chủ đề nghiệp vụ; trong môi trường thử nghiệm cần hiển thị được “tại sao lại khớp với đoạn này”. Việc hiệu chỉnh tra cứu thường giải quyết vấn đề tốt hơn so với việc chuyển sang một mô hình lớn hơn.

Biên soạn các quy định và sổ tay vận hành thành tài sản tri thức có thể truy xuất nguồn gốc

Phát triển và triển khai: giao diện, cô lập, giám sát, nghiệm thu

Khi vận hành, nên thống nhất đầu vào chung để tránh tình trạng mỗi kỹ năng đi theo một chuỗi xử lý riêng, dẫn đến hiện tượng lệch trạng thái. Việc phát hiện năng lực, thực thi cô lập, bảo đảm tính toàn vẹn của công cụ và tính toán hạn ngạch cần được hoàn tất tại thời điểm vận hành, thay vì dựa vào các quy ước. Trước khi đăng tải kỹ năng lên thị trường nội bộ, cần tiến hành rà soát quyền hạn: không được phép xuất hiện tiêu đề xác thực, biến môi trường và thông tin xác thực kết nối trong các giao diện đọc thông thường.

  • Kênh thực thi: Dòng chảy đồng bộ phù hợp cho các cuộc trò chuyện; Run bất đồng bộ + dòng sự kiện phù hợp cho việc tiếp tục truyền tải sau khi bị gián đoạn và hàng đợi tác vụ, cả hai cùng sử dụng chung một nhân hệ thống.
  • Danh tính kênh: WeChat, WeCom, Feishu và DingTalk có thể được sử dụng làm cổng truy cập, nhưng danh tính nhân viên, cuộc trò chuyện và Trace phải được thống nhất; nghiêm cấm việc mỗi kênh tự xây dựng một bộ nhớ riêng.
  • An toàn: Cấu hình mô hình chỉ tham chiếu số hiệu cấu hình đã có, không gửi lại khóa nhà cung cấp; khi đưa kết quả công cụ vào Trace thì thực hiện việc ẩn dữ liệu.
  • Hỗ trợ thủ công: Khi xảy ra tình trạng hết thời gian, độ tin cậy thấp, vượt quyền hoặc người dùng chủ động chuyển sang nhân viên trực tiếp, cả bốn trường hợp này đều phải đảm bảo việc chuyển giao ngữ cảnh một cách hoàn chỉnh.

Việc nghiệm thu không nên chỉ kiểm tra việc “có thể trò chuyện” mà thôi. Hãy cung cấp một bộ kịch bản có thể lặp lại: vòng khép kín bình thường, khi đang xử lý thì bị chèn câu hỏi, hạn mức không đủ, giao diện bị timeout, quyền hạn vượt quá thực hiện ghi dữ liệu, không có nguồn gốc thì từ chối trả lời. Đối với mỗi kịch bản, cần kiểm tra: các nút có được phục hồi hay không, chứng từ có được ghi đúng hay không, Trace có đầy đủ hay không, các trường hợp ngoại lệ có được chuyển đến người xử lý hay không. Tỷ lệ thông qua trong đợt kiểm tra ngẫu nhiên, tỷ lệ xử lý timeout, số lần trả lời không có căn cứ – những chỉ số này còn phù hợp hơn cả mức độ hài lòng theo sao để làm tiêu chí kiểm soát đầu ra.

Thứ tự triển khai: trước hết là một đoạn công việc lặp lại

Đừng vội vàng trở thành một trợ lý toàn năng ngay từ đầu. Hãy chọn ra một quy trình lặp lại hơn nửa giờ mỗi ngày trong các lĩnh vực như ghi chép theo dõi bán hàng, đôn đốc phê duyệt, hỏi đáp về quy định hoặc thẩm định trước chi phí; sau đó viết thành bốn câu về đầu vào, đầu ra, quyền hạn và các trường hợp ngoại lệ, rồi bổ sung SOP cùng hai đến ba giao diện chỉ đọc hoặc ghi hạn chế. Khi dữ liệu chủ còn “bẩn” và các nút phê duyệt chưa rõ ràng, trước hết hãy hoàn thiện đối tượng và trạng thái, rồi mới triển khai thực thi thông minh — khi dữ liệu “bẩn” đã được tự động hóa, nó sẽ lan truyền nhanh hơn khắp toàn công ty.

Làm thế nào để biết thiết kế đã được thực hiện đúng: đoạn trước đây phụ thuộc vào việc nhắn tin nhóm và điền biểu mẫu nay không còn là con đường chính nữa; biên bản, công việc đôn đốc và tổng hợp có thể đối chiếu với chứng từ để kiểm tra ngẫu nhiên; những tình huống khó giải thích đều có người xử lý theo quy trình nâng cấp; các thao tác nhạy cảm đều được kiểm tra bởi người có thẩm quyền, nhật ký hoạt động có thể tra cứu. Để đánh giá xem quá trình phát triển có đạt chuẩn hay không, hãy xemLiệu có thể khôi phục sau khi cùng một SOP bị gián đoạn không?Trả lời có thể trỏ về nguồn gốc không?Trường hợp biên giới có thể được đưa vào đợt sửa đổi tiếp theo không?. Sau khi ba hạng mục này được thông qua, mới mở rộng thêm các vị trí công việc; điều này ổn định hơn so với việc trước hết triển khai rất nhiều cổng trò chuyện.

Độ khó kỹ thuật của hệ thống nhân viên số không nằm ở việc tạo ra các cuộc trò chuyện, mà ở việc biến các vị trí công việc, quy trình, kiến thức, công cụ và hành trình thành những đối tượng phần mềm có thể được phiên bản hóa. Các câu lệnh gợi ý có thể được chỉnh sửa mười lần trong một tuần; nhưng một khi mô hình đối tượng bị phân tán, mỗi kỹ năng sau này sẽ phải viết riêng một bộ. Trước hết cần đảm bảo vận hành trơn tru bảy loại đối tượng này cùng với máy trạng thái; chỉ khi đó mới có thể dễ dàng nâng cấp mô hình; nếu không, mỗi lần thay đổi mô hình sẽ trở thành một dự án mới, chứ không phải là một lần thay đổi cấu hình.

Tư vấn trực tuyến