Clairic của Cloudflare: trích xuất dữ liệu có kiểu cho workflow AI

Clairic là model preview trên Workers AI của Cloudflare, trích xuất dữ liệu có cấu trúc từ văn bản và ảnh phi cấu trúc. Model có thể tính toán, ước lượng và dự báo, nhưng cần được kiểm thử kỹ trước khi dùng trong quy trình quan trọng.

Clairic của Cloudflare: trích xuất dữ liệu có kiểu cho workflow AI

Một email hỗ trợ có thể chứa mã đơn, ngày giao, số tiền, thuế và yêu cầu hoàn tiền — tất cả lẫn trong vài dòng văn bản tự do. Nhiều workflow hiện giao việc này cho LLM, rồi phải tiếp tục kiểm tra JSON, ép kiểu dữ liệu và xử lý trường bị thiếu.

Cloudflare vừa giới thiệu Clairic, một model trích xuất đang ở giai đoạn preview trên Workers AI. Thay vì tạo câu trả lời tự do, Clairic hướng tới việc lấy các giá trị có kiểu từ văn bản và ảnh phi cấu trúc, như số, ngày, mã đơn, danh sách hoặc thời lượng.

Vì vẫn là preview và Cloudflare thừa nhận model có thể mắc lỗi, Clairic không nên được mặc định đưa vào các quy trình quan trọng mà không có kiểm thử, quy tắc kiểm tra và bước xử lý ngoại lệ.

Clairic là gì?

Cloudflare xếp Clairic vào nhóm System One extraction models. Theo mô tả của hãng, model xử lý trong một lượt truyền tiếp, không sinh token đầu ra hay chuỗi suy luận như LLM.

Model hiện được cung cấp trên Workers AI với tên:

@cf/cloudflare/clairic

Một yêu cầu gồm:

State: văn bản cần đọc, cùng tối đa bốn ảnh tùy chọn. Fields: các trường do nhà phát triển khai báo, gồm tên trường, kiểu dữ liệu và hướng dẫn bằng ngôn ngữ tự nhiên nếu cần.

Clairic hỗ trợ các dạng đầu ra:

text: đoạn văn bản lấy trực tiếp từ đầu vào, chẳng hạn tên hoặc mã đơn; đi kèm vị trí ký tự và điểm tin cậy. number: số được đọc hoặc tính từ nội dung, có thể quy định số nguyên hay số chữ số thập phân. date, time, datetime: ngày và thời gian theo định dạng ISO. duration: khoảng thời gian theo đơn vị lựa chọn. list: danh sách văn bản, số hoặc ngày theo thứ tự xuất hiện. estimate: giá trị ước lượng trong phạm vi và độ chia đã khai báo, kèm trung vị và khoảng bất định 80%. forecast: các giá trị dự báo cho các bước tiếp theo của một chuỗi.

Với giá trị vô hướng, model có thể trả thêm confidence và pnull — xác suất giá trị không xuất hiện trong đầu vào. Khi không tìm được đáp án, đầu ra có thể là null.

Khác gì với LLM trả JSON?

Một LLM có thể đọc hóa đơn và trả về JSON gồm mã đơn, ngày giao và tổng tiền. Đây là cách linh hoạt, nhưng workflow vẫn cần đề phòng JSON không hợp lệ, sai định dạng ngày hoặc số bị trích sai.

Clairic dùng cách tiếp cận khác: khai báo trước những trường cần lấy, sau đó nhận về giá trị theo kiểu đã chọn. Với trường text, kết quả còn có thể gắn với vị trí của đoạn trích trong đầu vào để tiện đối chiếu.

Cloudflare cho biết Clairic không sinh token đầu ra, chỉ xử lý token đầu vào trong một lượt. Công ty tuyên bố model nhanh hơn, rẻ hơn và chính xác hơn LLM truyền thống cho các tác vụ trích xuất mục tiêu. Đây là tuyên bố từ nhà cung cấp; đội triển khai vẫn cần đánh giá trên dữ liệu thực tế của mình.

Khi nào phù hợp với workflow?

Clairic phù hợp khi đầu vào tương đối rõ loại tài liệu và đầu ra là nhóm trường xác định trước, ví dụ:

Lấy mã đơn hàng từ email hỗ trợ. Đọc ngày giao hàng hoặc ngày đến hạn. Trích số tiền, thuế và danh sách mặt hàng. Tính chênh lệch thời gian từ các mốc ngày có trong nội dung. Ước lượng chi phí sửa chữa trong một phạm vi đã đặt. Dự báo giá trị tiếp theo của chuỗi dữ liệu.

Một luồng xử lý có thể là:

Nhận email, văn bản hoặc ảnh. Khai báo các trường cần trích xuất. Gửi nội dung và schema trường tới Clairic. Kiểm tra null, confidence và các quy tắc nghiệp vụ. Chuyển bản ghi đạt điều kiện sang CRM, bảng tính hoặc hệ thống nội bộ. Đưa bản ghi thiếu dữ liệu hay có tín hiệu rủi ro vào hàng chờ kiểm tra.

confidence không phải giấy bảo đảm kết quả đúng. Ngưỡng tự động hóa nên khác nhau theo mức rủi ro của từng trường: sai mã đơn có thể gây bất tiện, trong khi sai số tiền hoặc ngày tháng có thể cần kiểm tra thủ công chặt chẽ hơn.

Schema minh họa cho email đơn hàng

Cloudflare minh họa Clairic bằng email hỗ trợ có mã đơn, ngày giao, giá hàng, thuế, tình trạng sản phẩm và yêu cầu sửa hoặc hoàn tiền.

Trong n8n, Make, Workers AI hoặc một công cụ điều phối tương tự, có thể hình dung schema trường như sau:

text orderid: text deliverydate: date subtotal: number (2 chữ số thập phân) tax: number (2 chữ số thập phân) issuelist: list requestedresolution: text

Đây là schema minh họa để ánh xạ kết quả vào các cột CRM, bảng tính hoặc biến trong workflow. Với trường text, vị trí ký tự của đoạn trích có thể giúp nhân viên đối chiếu nhanh với nội dung gốc. Với số, ngày và thời lượng, kiểu dữ liệu giúp giảm bớt bước ép kiểu ở phía sau.

Đánh giá trước khi thay một bước LLM

Không nên thay ngay một bước LLM đang vận hành chỉ dựa trên mô tả sản phẩm. Hãy chạy thử song song trên tập dữ liệu đã được đối chiếu và quản lý phù hợp.

Các điểm nên theo dõi gồm:

Giá trị trích xuất so với dữ liệu đã xác nhận. Tỷ lệ null theo từng trường. Mối liên hệ giữa confidence và lỗi thực tế. Số bản ghi phải sửa thủ công. Thời gian xử lý workflow. Chi phí theo từng loại tài liệu. Các tình huống dễ lỗi như viết tắt, nhiều thông tin trong một đoạn hoặc dữ liệu thiếu.

Cloudflare cho biết Clairic chỉ tính phí token đầu vào, không có phí token đầu ra. Nếu số lượng trường lớn hơn khả năng xử lý trong một lượt, máy chủ sẽ tách thành các lượt song song, mỗi lượt vẫn thấy toàn bộ đầu vào, rồi gộp kết quả. Chi phí thực tế vẫn nên được đo trong môi trường triển khai cụ thể.

Clairic không thay thế mọi vai trò của LLM

Clairic nhắm đến những câu hỏi như:

“Mã đơn là gì?” “Ngày giao là ngày nào?” “Tổng tiền là bao nhiêu?” “Khoảng thời gian chậm là bao lâu?”

LLM vẫn phù hợp hơn khi workflow cần viết phản hồi, giải thích nguyên nhân, xử lý yêu cầu mở hoặc tạo nội dung không giới hạn trong một schema.

Một cách kết hợp hợp lý là dùng Clairic để trích xuất và chuẩn hóa giá trị, dùng model quyết định cho bước phân loại khi cần, còn LLM xử lý phần ngôn ngữ tự do và suy luận mở.

Checklist trước khi vận hành

[ ] Xác định rõ từng trường cần lấy và kiểu dữ liệu tương ứng. [ ] Thiết kế nhánh xử lý cho null, độ tin cậy thấp và dữ liệu mâu thuẫn. [ ] Kiểm tra kết quả trên tập tài liệu có đối chiếu thực tế. [ ] Đặt quy tắc riêng cho các trường rủi ro cao như số tiền và ngày tháng. [ ] Theo dõi lỗi, thời gian xử lý và chi phí theo từng loại đầu vào. [ ] Hạn chế lưu dữ liệu nhạy cảm trong nhật ký workflow. [ ] Chỉ mở rộng sang quy trình quan trọng sau khi đã đánh giá độ chính xác và cơ chế kiểm soát.

Clairic không phải lý do để loại bỏ LLM khỏi workflow. Nhưng với các bước chỉ cần đọc một nhóm trường xác định trước từ dữ liệu phi cấu trúc, đây là một hướng đáng thử: dùng model chuyên biệt cho trích xuất, và dành LLM cho những việc thực sự cần ngôn ngữ tự do.