Trong phim Men in Black II, Đặc vụ J đến thăm K tại một bưu điện trông có vẻ bình thường. Anh mở một chiếc máy phân loại thư và phát hiện ra một người ngoài hành tinh bên trong đang chia thư nhanh thoăn thoắt.
Đó là một cảnh nhỏ khá ngớ ngẩn, nhưng nó lại cho chúng ta một cách hữu ích để nghĩ về AI.
Giữa việc nhận được một thứ gì đó và xử lý nó, thường có một quyết định nhỏ hơn cần đưa ra: thứ này thuộc về đâu?
Giải quyết đúng quyết định đó ngay từ đầu, phần còn lại của hệ thống sẽ đi theo đúng hướng.
Tôi đã nghĩ về chú người ngoài hành tinh nhỏ bé đó khi xây dựng phần mềm AI.
Một ứng dụng nhận được câu hỏi về thanh toán, báo cáo lỗi, ảnh sản phẩm và yêu cầu đặt lịch demo. Mỗi thứ cần được xử lý khác nhau. Thế nhưng chúng ta lại hay bắt cùng một mô hình ngôn ngữ lớn kiểm tra mọi thứ và tự suy ra bước tiếp theo. Cách này vừa không hiệu quả vừa tốn kém.
Đó là lý do tôi tin rằng các mô hình chuyên biệt sẽ đóng vai trò lớn hơn nhiều trong tương lai của AI. Ví dụ: Jev được tạo ra để đưa ra các quyết định có cấu trúc mà phần mềm có thể thực thi. Coinbase đã tùy chỉnh Qwen3.5-9B riêng cho việc phát hiện gian lận trong dịch vụ Onramp của họ. Mỗi mô hình tập trung vào một nhiệm vụ cụ thể, với kết quả có thể đo lường được.
https://x.com/brian_armstrong/status/2109412046244913643
Tôi đang xây dựng lớp phân loại
Những yêu cầu quen thuộc có thể đi thẳng vào một quy trình đã định sẵn. Những yêu cầu cần suy luận nhiều hơn sẽ được chuyển sang mô hình khác. Những yêu cầu mơ hồ sẽ bị đánh dấu để làm rõ hoặc xem xét lại.
Khoản tiết kiệm tiềm năng đến từ việc chỉ cấp cho mỗi yêu cầu đúng lượng tài nguyên xử lý mà nó cần. Sau đó, chúng ta phải đo xem bộ phân loại có đưa ra đủ số quyết định chính xác để chứng minh sự tồn tại của nó hay không.
Điểm khởi đầu của chúng tôi là CludeMem. Chúng tôi cố gắng xác định AI nên ghi nhớ điều gì, nên truy xuất điều gì, và điều gì đang tiêu tốn token một cách vô ích. Một sở thích lâu dài, một chỉ dẫn tạm thời và một câu hỏi chưa được giải đáp cần được xử lý khác nhau. Trước khi đưa ra những quyết định đó, chúng tôi cần phân loại thông tin.
Từ đó nảy sinh ý tưởng về một lớp phân loại rộng hơn. Cùng một bước này có thể giúp sắp xếp yêu cầu hỗ trợ, định tuyến tài liệu hoặc chọn chuyên gia phù hợp để xử lý tác vụ.
GIF
Khi ngày càng có nhiều mô hình chuyên biệt xuất hiện, các ứng dụng sẽ cần quyết định đầu vào nào xứng đáng được chúng xử lý. Đó chính là phần chúng tôi đang xây dựng: phân loại những gì đến, xử lý cục bộ các trường hợp quen thuộc, và chuyển những ca khó hơn cho mô hình hoặc quy trình duyệt phù hợp.
Giới thiệu Clude Cat (Cat nghĩa là categorisation - phân loại 😉)
Trước khi lưu trữ một ký ức, truy xuất tài liệu, gọi công cụ hay tạo phản hồi, thường luôn có một quyết định về việc chúng ta đang xử lý loại thông tin nào.
Những quyết định đó có mặt ở khắp nơi.
Hãy tưởng tượng ai đó viết thư cho một công ty phần mềm:
“Tôi có thể tải hóa đơn của mình ở đâu?”
Một AI agent có thể đọc tin nhắn, kiểm tra các công cụ của nó, cân nhắc ý định của khách hàng và quyết định tìm kiếm hóa đơn.
Một quy trình trực tiếp hơn có thể trông như thế này:
Tin nhắn → yêu cầu tài liệu thanh toán → xác minh tài khoản → truy xuất hóa đơn.
Mô hình ngôn ngữ vẫn có thể soạn câu trả lời. Quyết định định tuyến ban đầu có thể được xử lý cục bộ.
Bây giờ hãy đổi nội dung tin nhắn:
“Tôi bị trừ tiền hai lần, tài khoản bị khóa, và tôi muốn hủy dịch vụ.”
Nếu cứ tự tin đẩy tin nhắn đó vào một quy trình xử lý hóa đơn duy nhất thì sẽ chỉ tạo thêm việc. Có nhiều vấn đề cần giải quyết, và phản hồi đúng có thể đòi hỏi phải làm rõ thêm hoặc cần con người can thiệp.
Bộ phân loại cần được phép nói: “Tôi không thể xếp loại tin này một cách chắc chắn.”
Đó là một phần thiết yếu của sản phẩm. Một hệ thống tự tin gửi yêu cầu đến sai địa chỉ có thể xóa sạch lợi thế về tốc độ bằng khối lượng công việc cần để sửa lỗi.
Với khách hàng, lợi ích mong đợi là ít phải chờ đợi và ít phải lặp lại thông tin hơn.
Với lập trình viên, đó là một quyết định rõ ràng mà họ có thể kiểm tra, thử nghiệm và thay đổi. Họ có thể thấy danh mục được chọn, phiên bản mô hình, thời gian xử lý và liệu hệ thống có từ chối đưa ra quyết định hay không.
Ở tầng dưới, phần triển khai cho văn bản bắt đầu bằng một mô hình pretrain nhỏ gọi là encoder.
Nó chuyển đổi tin nhắn thành một danh sách các con số đại diện cho các khía cạnh ý nghĩa của tin nhắn đó. Giới lập trình viên gọi biểu diễn này là embedding.
“Hóa đơn của tôi đâu rồi?” và “Tôi cần một bản sao của hóa đơn” dùng những từ khác nhau. Nhưng biểu diễn số của chúng vẫn có thể đủ giống nhau để hệ thống nhận ra đó là cùng một loại yêu cầu.
Lớp phân loại sử dụng những biểu diễn đó để chấm điểm các danh mục mà lập trình viên đã định nghĩa.
Chúng tôi đã triển khai hai phương pháp. Một phương pháp so sánh tin nhắn đến với các ví dụ của từng danh mục. Phương pháp còn lại học ranh giới giữa các danh mục từ các ví dụ đã gán nhãn.
Trong phương pháp fitted (tinh chỉnh), chúng tôi giữ nguyên encoder và huấn luyện một lớp quyết định nhỏ hơn nằm phía trên nó. Chúng tôi không cần huấn luyện một mô hình nền tảng mới cho mỗi ứng dụng.
Lập trình viên vẫn phải định nghĩa ý nghĩa của các danh mục và kết nối chúng với những hành động hữu ích. Bộ phân loại không thể tự bịa ra các phòng ban, chính sách hoàn tiền hay quyền hạn tài khoản của công ty.
Nó cũng cần một chính sách chấp nhận.
Danh mục đạt điểm cao nhất vẫn có thể là một lựa chọn tồi. Hai danh mục có thể suýt soát điểm nhau. Một yêu cầu lạ lẫm có thể trông giống một yêu cầu quen thuộc.
Điểm số cục bộ hiện tại của chúng tôi chưa được hiệu chuẩn thành xác suất. Điểm 0.92 không tự động có nghĩa là “92% khả năng chính xác”.
Chúng tôi phải kiểm tra xem điều gì xảy ra khi những điểm số đó chi phối quyết định.
Do đó, đầu ra phải phân biệt được giữa một danh mục được chấp nhận, một yêu cầu cần xem xét lại và một lỗi kỹ thuật. Tình trạng quá thời gian, hủy bỏ và lỗi mô hình cũng cần được xử lý một cách dự đoán được.
Đó chính là phần kỹ thuật xung quanh bộ phân loại. Nó quyết định liệu một ứng dụng khác có thể sử dụng kết quả đó một cách an toàn và nhất quán hay không.
Chúng tôi đã chạy thử nghiệm trên 770 yêu cầu ngân hàng để xem phương pháp này có giảm bớt khối lượng công việc cho mô hình sinh hay không.
Cấu hình đầu tiên gửi mọi yêu cầu đến mô hình Qwen2.5 7B chạy cục bộ để phân loại.
Cấu hình thứ hai dùng bộ phân loại cục bộ của chúng tôi trước, và chỉ gửi những yêu cầu chưa giải quyết được cho Qwen.
Kết quả thu được:
- Số lần gọi Qwen giảm từ 770 xuống 227.
- Số lượt phân loại đúng tăng từ 535 lên 642.
- Độ chính xác trên toàn bộ đầu vào tăng từ 69.5% lên 83.4%.
- Tổng thời gian truy vấn đo được giảm từ 299.7 giây xuống 87.7 giây.
Bước xử lý cục bộ đã tránh được 543 lần gọi Qwen, giảm 70.5%.
Bộ nhớ đệm vẫn được bật, và phương pháp trực tiếp được chạy trước phương pháp kết hợp. Các con số về thời gian không bao gồm phần thiết lập và khởi động. Chúng tôi chỉ đo khâu phân loại, chứ không đo việc tạo câu trả lời cuối cùng cho khách hàng hay trả phí cho nhà cung cấp mô hình.
Những con số đó chỉ mô tả cấu hình này. Chúng không khẳng định ưu thế vượt trội so với mọi LLM hay chứng minh được khoản tiết kiệm cho khách hàng.
Một thử nghiệm riêng biệt sau đó kiểm tra bộ phân loại cục bộ dạng fitted trên 24 ý định liên quan đến du lịch và nơi làm việc.
Trong 720 yêu cầu, nó xử lý cục bộ được 688 yêu cầu. Trong số đó, 681 yêu cầu đúng và 7 yêu cầu sai. Nó để lại 32 yêu cầu chờ xem xét.
Điều đó cho chúng ta hai thước đo khác nhau:
- Độ phủ: nó xử lý cục bộ được 95.6% yêu cầu.
- Độ chính xác khi chấp nhận: nó đúng trong 99.0% các quyết định mà nó chấp nhận.
Cả hai đều phải có trong kết quả. Một bộ phân loại có thể đạt độ chính xác ấn tượng nếu chỉ chịu chấp nhận vài yêu cầu dễ nhằn.
Chúng tôi cũng thử nghiệm 100,000 đầu vào xa lạ vốn nên nằm ngoài các danh mục được hỗ trợ. Nó chính xác hơn 94% số lần.
Nhận biết được những gì hệ thống không biết vẫn là một phần của công việc.
Tốc độ cũng cần sự cẩn trọng tương tự. Trong một bài test CPU ấm riêng biệt, toàn bộ bộ phân loại ngân hàng mất khoảng 1.8 mili giây cho mỗi yêu cầu ở mức trung vị trên M4 Max. Con số này bao gồm token hóa, embedding và chấm điểm.
Nó không bao gồm việc tải mô hình và khởi động. Đây là phép đo cho khâu phân loại, không phải thời gian cần để giải quyết trọn vẹn yêu cầu của người dùng. Nó cũng không đảm bảo hiệu năng tương tự trên điện thoại hay laptop thông thường.
Jev phù hợp với cuộc thảo luận này vì nó vốn đã giải quyết một nhóm quyết định tương tự.
TypeSafe mô tả Jev là một mô hình dành cho các phán đoán có giới hạn, bao gồm việc chọn giữa các phương án được cung cấp và định tuyến yêu cầu tới mã nguồn thông thường, mô hình chuyên biệt hoặc con người. \Tài liệu định tuyến ý định của Jev\
Vai trò mà tôi thấy ở Jev là một đường leo thang tùy chọn cho những yêu cầu mà bộ phân loại cục bộ không thể giải quyết chắc chắn.
Kiến trúc mà chúng tôi đang hướng tới rất đơn giản:
Yêu cầu đến → phân loại cục bộ → yêu cầu quen thuộc đi theo luồng định sẵn; yêu cầu chưa chắc chắn chuyển sang Jev, mô hình khác hoặc con người xem xét.
Nếu không có Jev, bước phân loại cục bộ này vẫn có thể trả những yêu cầu chưa giải quyết được về LLM hiện có của ứng dụng, bước làm rõ hoặc quy trình duyệt.
Lập trình viên kiểm soát các danh mục, ngưỡng chấp nhận và phương án dự phòng. Họ có thể đưa bộ phân loại cục bộ vào một quy trình đang hoạt động và đo xem nó có thể đảm nhận những quyết định nào.
Hiện tại, phần tích hợp Jev đang chạy ở chế độ shadow, so sánh các quyết định trên năm chủ đề lớn mà không làm thay đổi hành vi của ứng dụng. Bước tiếp theo là kiểm tra xem việc leo thang có chọn lọc có cải thiện toàn bộ quy trình hay không. Kết quả của Qwen ở trên không phải là benchmark cho Jev.
Đó là điều chúng ta cần đo lường: ít lần gọi mô hình không cần thiết hơn, xử lý các yêu cầu quen thuộc nhanh hơn, và một lộ trình rõ ràng cho những trường hợp cần chú ý nhiều hơn.
Chúng tôi đã bắt đầu mở rộng phương pháp này sang hình ảnh.
Hãy tưởng tượng một doanh nghiệp nhận được một tờ biên lai, một ảnh chụp màn hình báo lỗi và một bức ảnh sản phẩm. Mỗi thứ cần một luồng xử lý khác nhau.
Biên lai có thể chuyển sang khâu trích xuất biên lai. Ảnh chụp màn hình có thể đi vào quy trình hỗ trợ. Ảnh sản phẩm có thể đi vào quy trình cập nhật danh mục. Hình ảnh chưa rõ ràng có thể chuyển sang khâu duyệt.
Bộ phân loại chọn đích đến. Còn việc đọc tổng tiền mua hàng, chẩn đoán lỗi và nhận diện chi tiết sản phẩm vẫn là những tác vụ riêng biệt.
Phần triển khai thử nghiệm cho hình ảnh của chúng tôi dùng một CLIP encoder pretrain để tạo ra biểu diễn số của hình ảnh.
Một ứng viên nghiên cứu dạng fitted đã phân loại đúng 19 trên 20 bức ảnh sản phẩm thực phẩm trong một bài test chẩn đoán nhỏ. Nó cũng chuyển toàn bộ 30 ảnh lá đậu sang khâu duyệt.
Lỗi duy nhất là bảng thành phần dinh dưỡng và mã vạch trên một cái chai bị phân loại nhầm thành biên lai.
Bạn có thể thấy vấn đề rồi đấy. Cả hai đều có thể chứa nhiều chữ, số và bố cục hình chữ nhật dày đặc. Chúng tôi cần các ví dụ dạy cho mô hình ranh giới mà ứng dụng của mình quan tâm.
Mẫu đó quá hẹp để đưa ra tuyên bố cho môi trường production. Nhãn được lấy từ dataset thay vì được đánh giá độc lập, và không có ví dụ mới nào về biên lai hay ảnh chụp màn hình trong bài test. Bản demo công khai dùng một baseline riêng, nên không thể gán kết quả của ứng viên fitted cho nó.
Xử lý hình ảnh cũng nặng hơn phân loại văn bản. Thời gian xử lý trung vị khi máy đã khởi động mất khoảng 36 mili giây trong Node và 197 mili giây trong Chromium trên M4 Max. Trình duyệt trước tiên cần tải khoảng 85 MiB tài nguyên mô hình, cộng thêm runtime của nó.
Chạy cục bộ vẫn có chi phí. Dung lượng tải về, bộ nhớ, thời gian khởi động và hiệu năng thiết bị đều phải được tính vào quá trình đánh giá.
Sản phẩm mà tôi hình dung sẽ khớp vào một ứng dụng đang có, nơi nó quyết định chuyện gì xảy ra tiếp theo.
Lập trình viên định nghĩa danh mục, cung cấp ví dụ tiêu biểu, kết nối các đích đến và chọn hành động khi việc phân loại chưa chắc chắn.
Lần triển khai đầu tiên nên chỉ quan sát quy trình hiện tại mà không thay đổi kết quả của nó. Sau đó chúng ta có thể so sánh các quyết định được đề xuất với kết quả thực tế đã xác minh trước khi cho phép bộ phân loại kiểm soát việc định tuyến.
Chúng ta cần soi xét những lỗi được chấp nhận kỹ lưỡng như những yêu cầu bị từ chối. Nếu không, một quyết định sai lầm nhưng đầy tự tin có thể biến mất đằng sau một điểm số đẹp mắt.
Việc huấn luyện, hiệu chuẩn và kiểm thử cũng cần dữ liệu riêng biệt. Huấn luyện giúp mô hình học các danh mục. Hiệu chuẩn chọn ra quy tắc chấp nhận. Bài test được bảo vệ sẽ kiểm tra kết quả đã đóng băng.
Một khi lỗi trong bài test lại ảnh hưởng đến mô hình ở vòng sau, ví dụ đó trở thành dữ liệu phát triển. Lần đánh giá tiếp theo sẽ cần một bài test mới.
Chú người ngoài hành tinh nhỏ trong máy phân loại thư giúp mọi người dễ hình dung công việc. Nhưng để xây dựng một phiên bản hữu ích, ta phải tìm ra chính xác những đầu vào nào nó xử lý được, khi nào nó nên kêu cứu, và cái giá của những sai lầm nó gây ra là bao nhiêu.
Bước tiếp theo là một quy trình mang tính đại diện với nhãn độc lập và hồ sơ ghi nhận mọi kết quả. Chúng ta cần đo xem có bao nhiêu yêu cầu đi theo luồng cục bộ, bao nhiêu yêu cầu chuyển sang mô hình khác, bao nhiêu yêu cầu bị xử lý sai, và liệu toàn bộ ứng dụng có nhanh hơn hay rẻ hơn không sau khi đã tính cả những lỗi đó.
Đã đến lúc mở rộng quy mô và bơm thêm "steroid" cho mô hình cục bộ này.
