Hộp thư hỗ trợ của bạn nhận được ba tin nhắn: « Tôi không tìm thấy hóa đơn của mình », « Tải xuống thất bại » và « Bạn có thể trình bày đề nghị của mình không? ». Trước khi soạn phản hồi, cần quyết định gửi chúng cho đội nào. Bước đầu tiên này là phân loại: chọn một danh mục trong danh sách đã định. Clef, được thông báo bởi Cloudflare vào ngày 1 tháng 10, gợi ý coi lựa chọn này là một nhiệm vụ riêng. Đây là cách chuẩn bị đánh giá của mình trong một bộ phận hỗ trợ giả định, với các lỗi rõ ràng và sự chỉnh sửa của con người.
Bắt đầu bằng quyết định được chờ đợi
Trong ví dụ minh họa của chúng tôi, các danh mục là thanh toán, kỹ thuật và thương mại. Một danh mục thứ tư, ngoài phạm vi, tiếp nhận các yêu cầu mà tổ chức này không biết cách trả lời. Bên cạnh những danh mục này, ứng dụng còn có trạng thái xử lý: chấp nhận hoặc cần xem lại. Danh mục mô tả yêu cầu; trạng thái mô tả những gì bạn cho phép làm với nó.
Sự tách biệt này giúp hiểu một yêu cầu mơ hồ: « Gói đăng ký của tôi đã được thanh toán, nhưng tôi không còn truy cập vào các tệp của mình nữa. » Mô hình có thể đề xuất kỹ thuật, trong khi chính sách của bạn yêu cầu kiểm tra vì thông điệp cũng liên quan đến thanh toán. Bạn không cần phải ép buộc một nhãn duy nhất chịu toàn bộ sự phức tạp của can thiệp.
Xác định những gì còn nằm ngoài bản thử nghiệm đầu tiên: hoàn tiền, đóng tài khoản, thay đổi quyền hoặc trả lời gửi cho khách hàng. Bộ phân loại được đề xuất ở đây chỉ gợi ý một hướng đi. Nó không kích hoạt bất kỳ hành động nào trong số này. Trong lần thử đầu tiên, mọi người vẫn tiếp tục làm việc bình thường trong khi bạn so sánh các gợi ý với các quyết định đã được đưa ra.
Những gì Cloudflare cung cấp
Trong thông báo ngày 1 tháng 10 năm 2026, Cloudflare giới thiệu Clef và Clef-flash như các mô hình quyết định với đầu ra có cấu trúc, có sẵn trong Workers AI. Việc thích nghi với các nhiệm vụ của khách hàng bắt đầu bằng sự hỗ trợ của con người; một nền tảng tinh chỉnh theo nhu cầu tự phục vụ sẽ được công bố sau. Việc tinh chỉnh bao gồm việc điều chỉnh một mô hình dựa trên các ví dụ của một nhiệm vụ cụ thể.
phiếu chính thức Clef trên Hugging Face, được tham khảo vào ngày 6 tháng 10, hiển thị giấy phép Apache-2.0 và mô tả các tệp mô hình của mô hình. Điều này không chứng minh được hoạt động của nó trên phần cứng của bạn. Hồ sơ cũng chứa một loại không phổ biến trong một ví dụ: chúng tôi không coi ví dụ này là một hợp đồng tích hợp được xác nhận.
Những thông tin này mở ra hai hướng thử nghiệm cần đánh giá: một dịch vụ được lưu trữ hoặc việc thực thi các trọng số có sẵn. Lựa chọn phụ thuộc vào các ràng buộc về dữ liệu, phần cứng và thời gian vận hành của bạn. Trước khi hứa hẹn một thử nghiệm cục bộ có thể tái hiện, cần xác định phiên bản các tệp mô hình, các phụ thuộc và cấu hình phần cứng, sau đó thực hiện một bài kiểm tra. Bài viết này không trình bày việc cài đặt đã thực hiện hay cuộc gọi được tính phí.
Các so sánh được công bố trong thông báo là từ nhà cung cấp. Quyết định thử nghiệm của chúng tôi không dựa trên thứ hạng của họ: kết quả quan trọng sẽ là việc chuyển đúng nhóm tốt hơn cho các yêu cầu của bạn, với chi phí lỗi có thể chấp nhận được. Nhiều trang từ cùng một nhà xuất bản không cấu thành một sự xác nhận độc lập về chất lượng trên bộ phận hỗ trợ bằng tiếng Pháp.
Viết một hợp đồng đơn giản cho ứng dụng
Hợp đồng dưới đây là một đề xuất nội bộ Partitech, độc lập với sơ đồ chính thức của Clef. Nó mô tả những gì ứng dụng của bạn phải nhận và kiểm tra. Không có tên trường nào được trình bày như một tham số của API của nhà cung cấp.
| Yếu tố khái niệm | Vai trò trong chương trình thí điểm | Kiểm tra dự kiến |
|---|---|---|
| ID trình diễn | Kết nối đầu vào và quyết định | Sự hiện diện, tính duy nhất trong lô |
| Văn bản được cho phép | Nội dung cần phân loại | Không rỗng, kích thước có giới hạn, không có bí mật |
| Phiên bản của các danh mục | Xác định các lựa chọn có thể | Phiên bản được ứng dụng công nhận |
| Danh mục đề xuất | Hướng dẫn được đề xuất | Giá trị có trong danh sách cho phép |
| Điểm có thể có | Giúp đánh giá mức độ chấp nhận | Định dạng mong đợi và diễn giải có tài liệu |
| Tình trạng xử lý | Chấp nhận hoặc yêu cầu một lần rà soát | Quy tắc nghiệp vụ riêng biệt với mô hình |
Bạn có thể kiểm tra hợp đồng với một vài tin nhắn tổng hợp. Đối với “Hóa đơn demo không tìm thấy”, nhãn tham chiếu được chọn cho bài tập sẽ là hóa đơn. Đối với “Tải xuống tài liệu demo của tôi bị gián đoạn”, nó sẽ là kỹ thuật. Một tin nhắn quảng cáo mà không có yêu cầu sẽ nằm ngoài phạm vi. Những ví dụ này dùng để kiểm tra kết nối và các danh mục; chúng không đo lường chất lượng trên khách hàng thực sự.
Dự đoán các trường hợp từ chối: văn bản vắng mặt, danh mục không xác định, điểm số không đọc được, phản hồi không đầy đủ và quá hạn. Hành vi mong đợi là con người can thiệp lại hoặc thất bại rõ ràng, không bao giờ hướng một cách im lặng tới một danh mục mặc định. Một phản hồi được tạo tốt vẫn có thể chứa một quyết định sai; các kiểm tra định dạng và chất lượng vẫn được giữ tách biệt.
Tạo một bộ kiểm tra tiết lộ các lỗi
Giao thức sau đây được đề xuất bởi Partitech và chưa được thực hiện. Bắt đầu bằng một hướng dẫn chú thích: mỗi lớp có nghĩa gì, cách xử lý các tin nhắn có nhiều chủ đề và khi nào cần loại ra ngoài phạm vi? Hãy để một người khác đọc lại các trường hợp mơ hồ. Nếu những người chú thích không đồng ý, mô hình sẽ không thể tự giải quyết sự mơ hồ trong tổ chức của bạn.
Sau đó, tách ba cách sử dụng dữ liệu. Một phần có thể được dùng để điều chỉnh mô hình. Một phần khác dùng để chọn các cài đặt và ngưỡng. Bộ dữ liệu kiểm tra cuối cùng vẫn được giữ nguyên cho đến khi so sánh. Nếu bạn điều chỉnh một hướng dẫn sau khi đã thấy lỗi của nó trên bộ dữ liệu này, nó trở thành bộ dữ liệu phát triển; lúc này hãy chuẩn bị một đánh giá độc lập mới.
Cũng tránh sao chép giữa các lô: hai tin nhắn trong cùng một chuỗi, một mẫu email được sao chép hoặc các biến thể gần giống nhau có thể tạo cảm giác mô hình có khả năng xử lý các trường hợp mới. Đối với bộ phận hỗ trợ giả định của chúng tôi, việc phân tách theo cuộc trò chuyện và xem xét các bản sao sẽ là các biện pháp kiểm soát thích hợp. Giữ lại các tin nhắn được phép, giảm thiểu thông tin định danh và không gửi bất kỳ dữ liệu khách hàng nào nếu chưa có khuôn khổ đã được thiết lập.
Bao gồm những khó khăn thực sự: câu rất ngắn, tiếng Pháp sơ sài, các yêu cầu kết hợp hai chủ đề và từ vựng mới. Giữ nguyên tần suất và bản chất của chúng. Như vậy, bạn có thể giải thích nếu một phương pháp chủ yếu thành công với các yêu cầu hiển nhiên và chuyển tất cả các yêu cầu khác cho một người khác.
Đếm các lỗi theo hậu quả của chúng
Ma trận nhầm lẫn là một bảng đối chiếu giữa danh mục mong đợi và danh mục được đề xuất. Nó cho phép nhìn thấy nơi hệ thống mắc lỗi. Trong ví dụ của chúng ta, phân loại một yêu cầu kinh doanh vào kỹ thuật sẽ làm mất thời gian; phân loại một vấn đề truy cập vào kinh doanh có thể làm chậm thêm việc giải quyết của nó. Cùng một số lỗi nhưng không tạo ra cùng một chi phí cho doanh nghiệp.
Xác định chi phí này với những người xử lý các yêu cầu. Đối với chương trình thí điểm, bạn có thể tính số lần phân công lại, thời gian xem xét và các trường hợp khẩn cấp bị định hướng sai. Nếu bạn sử dụng một thang điểm định lượng, hãy ghi rõ đây là lựa chọn của nhóm bạn và giữ lại lý do của họ. Một trọng số được quyết định sau khi thấy kết quả thuận lợi sẽ làm cho việc so sánh trở nên khó bảo vệ.
Một điểm số cao không tự động có nghĩa là "quyết định đáng tin cậy". Hiệu chuẩn mô tả sự tương thích giữa mức độ tin cậy được công bố và tần suất các quyết định đúng trong các trường hợp tương tự. Để kiểm tra nó, hãy nhóm các quyết định theo các khoảng điểm số, đếm số trường hợp và so sánh sự tin cậy với mức độ chính xác quan sát được. Một khoảng với rất ít ví dụ cung cấp ít thông tin: hãy hiển thị số lượng của nó thay vì đưa ra một phán quyết một cách rõ ràng.
Việc không đưa ra quyết định cũng xứng đáng được đo lường. Nếu bạn yêu cầu xem xét tất cả các thông điệp khó khăn, các quyết định chuyển nhóm được chấp nhận có thể trông xuất sắc trong khi đội ngũ con người vẫn giữ phần lớn công việc. Hãy tính tỷ lệ yêu cầu được chấp nhận, tỷ lệ cần xem lại và thời gian phục hồi. Xem xét kết quả theo danh mục và theo loại độ khó.
So sánh trước khi điều chỉnh
Điểm xuất phát của bạn, gọi là baseline, có thể là một quy tắc đơn giản: một vài thuật ngữ thanh toán, một danh sách các lỗi kỹ thuật và một giải pháp khi xảy ra xung đột. Thêm vào nếu cần một mô hình tổng quát với đầu ra giới hạn. So sánh những giải pháp này với Clef trên cùng các mục nhập, với cùng các danh mục và cùng các quy tắc xác thực. Một sự điều chỉnh chuyên biệt chỉ được biện minh sau khi so sánh này.
| Biện pháp được đề xuất | Quy tắc đơn giản | Mô hình tổng quát | Clef | Clef-flash |
|---|---|---|---|---|
| Lỗi theo danh mục | Để đo | Để đo | Để đo | Để đo |
| Chi phí nghiệp vụ của các sai sót | Để đo | Để đo | Để đo | Để đo |
| Phần cần xem lại | Để đo | Để đo | Để đo | Để đo |
| Thời gian phản hồi | Để đo | Để đo | Để đo | Để đo |
| Chi phí và thời gian phục hồi | Để đo | Để đo | Để đo | Để đo |
Đo thời gian của toàn bộ quá trình, bao gồm cả việc kiểm tra và phục hồi nếu cần. Ghi chú cấu hình, phiên bản mô hình và ngày tháng. Không thay thế ô trống bằng kết quả thông báo: bảng này phải mô tả thử nghiệm của bạn. Một giải pháp dự đoán nhanh hơn có thể vẫn kém hữu ích hơn nếu nó đòi hỏi nhiều chỉnh sửa hơn.
Cho phép thử nghiệm thí điểm có thể dừng lại
Bắt đầu bằng quan sát, mà không tự động chỉnh sửa các tệp hỗ trợ. So sánh đề xuất với quyết định chuyển nhóm của con người, sau đó xem xét các điểm bất đồng. Chúng có thể tiết lộ một lỗi của mô hình, một tham chiếu sai hoặc một danh mục cần làm rõ. Giải quyết những nguyên nhân này trước khi bắt đầu lại một thử nghiệm với một giao thức rõ ràng.
Quyết định trước các tiêu chí chấp nhận: các lỗi nghiêm trọng được chịu đựng, tải trọng xem xét tối đa và các danh mục được bao phủ. Dự kiến phản hồi ngay lập tức cho xử lý bằng con người nếu kết quả trở nên không hợp lệ, nếu các lỗi nghiêm trọng tăng hoặc nếu từ vựng thay đổi mạnh. Đối với ví dụ này, bước tiếp theo hữu ích là ổn định các danh mục và bộ dữ liệu kiểm tra. Việc lựa chọn mô hình sẽ diễn ra sau hợp đồng công việc này.
Nguồn và ngày kiểm tra
Các trang chính đã được mở lại và đọc vào ngày 6 tháng 10 năm 2026 : Cloudflare, ra mắt Clef, ngày 1 tháng 10 ; Cloudflare, phiếu chính thức Clef trên Hugging Face. Bộ dữ liệu tổng hợp, các hợp đồng và các bảng biểu là những đề xuất Partitech. Không có chuẩn đánh giá riêng, huấn luyện hay lời gọi dịch vụ được lưu trữ nào đã được thực hiện cho bài báo này.