Xin chào các bạn, mình là Jin Chenma.
Hãy bắt đầu bằng một câu hỏi: Xét về loại nội dung mà chúng xử lý, những dạng mô hình AI lớn phổ biến mà chúng ta thường gặp là gì?
Hầu hết mọi người đều quen thuộc với văn bản, hình ảnh, âm thanh và video. Trong vài năm qua, nhiều nhà cung cấp đã liên tục cạnh tranh và cải tiến trong các lĩnh vực này, khiến năng lực ngày càng mạnh mẽ hơn và cuộc đua ngày càng khốc liệt hơn.
Sau khi chứng kiến vô số bản cập nhật, mình không ngừng tự hỏi: Ngoài việc làm cho các mô hình hiện có trở nên mạnh mẽ hơn, liệu có những dạng mô hình mới nào sẽ xuất hiện không?
Gần đây, một mô hình tên là Jev đã trở nên viral. Ban đầu, mình nghĩ: Đây chẳng phải lại là một công ty tung ra một mô hình ngôn ngữ lớn mới sao?
Nhưng sau khi tìm hiểu sâu hơn, mình nhận thấy mô hình này thực sự ấn tượng.
Đứng sau nó, TypeSafe AI đã đề xuất một lớp mô hình gọi là System One Models (Mô hình Hệ thống Một), được thiết kế đặc biệt cho các tác vụ phán đoán trong phần mềm. Jev là mô hình công khai đầu tiên của họ.
Các phân loại trước đó (văn bản, hình ảnh, âm thanh, video) được chia theo loại nội dung; lần này, họ thay đổi góc nhìn: coi "việc đưa ra phán đoán" như một tác vụ độc lập và thiết kế một mô hình xoay quanh nó.
Mình tin rằng hướng đi này có thể tạo ra tác động sâu sắc đến sự phát triển và phân công lao động tương lai của các mô hình AI.
Trong bài viết này, mình sẽ giải thích rõ ràng Jev là gì, nó khác biệt thế nào so với LLM tiêu chuẩn, ứng dụng của nó ở đâu và cách bắt đầu sử dụng.
Bắt đầu từ phép ẩn dụ mã QR
Làm thế nào để hiểu Jev? Hãy tưởng tượng bạn muốn tạo một mã QR.
Thông thường, bạn sẽ dùng một công cụ tạo mã QR. Nhưng giả sử bạn thuê một nghệ sĩ có thể vẽ bất cứ thứ gì, yêu cầu họ vẽ từng pixel của mã QR.
Tất nhiên, nghệ sĩ này rất tài năng và có thể làm được. Nhưng việc tạo mã QR đã có công cụ chuyên dụng. Bạn chỉ cần một mã QR hoạt động tốt, chứ không cần kèm theo một bức tranh phong cảnh.
Tương tự, khi so sánh Jev với Các Mô Hình Ngôn Ngữ Lớn (LLMs):
LLMs có thể viết bài, code và thảo luận các vấn đề phức tạp. Nếu bạn yêu cầu một LLM đọc một bình luận và phán đoán cảm xúc của người dùng, nó chắc chắn làm được.
Nhưng nếu nhiệm vụ chỉ đòi hỏi một lựa chọn hoặc một điểm số, hãy cân nhắc: Liệu chúng ta có thể tạo ra một mô hình nhanh hơn, rẻ hơn và dễ dàng truy cập bằng chương trình, dành riêng cho những tác vụ như vậy không?
Đây chính xác là điều Jev làm.
Nó từ bỏ khả năng tạo văn bản tự do để chuyên tâm vào các phán đoán có phạm vi câu trả lời rõ ràng. Ví dụ, nếu bạn cung cấp bốn tùy chọn—"Hài lòng," "Không hài lòng," "Trộn lẫn," "Không xác định"—nó sẽ chọn một và cung cấp xác suất cho từng tùy chọn.
Giống như mã QR có công cụ chuyên dụng, các tác vụ chỉ đòi hỏi lựa chọn và điểm số có thể được xử lý bởi các mô hình chuyên biệt. Theo giới thiệu chính thức, việc tối ưu hóa của Jev cho các tác vụ phán đoán này giúp giảm thời gian phản hồi và chi phí gọi API.
Ví dụ, việc lọc hàng triệu bình luận thương mại điện tử mỗi ngày đòi hỏi phải phán đoán cảm xúc, mức độ khẩn cấp và phương pháp xử lý. Những phán đoán nhanh hơn, rẻ hơn giúp giảm tổng thời gian chờ đợi và chi phí. Chương trình nhận kết quả và tiếp tục quy trình phân loại hoặc chuyển giao cho con người.
Nguồn gốc của Jev
Ai đã tạo ra Jev? Tại sao xây dựng một mô hình chỉ dành cho việc phán đoán?
Jev đến từ TypeSafe AI, do Diogo Almeida sáng lập, người trước đây từng nghiên cứu về chat model tại OpenAI.
Ông tập trung vào một vấn đề: AI rất giỏi trò chuyện, nhưng tại sao việc tích hợp những khả năng này vào phần mềm để tự động hóa các tác vụ lại không dễ dàng?
Phần mềm xuất sắc trong việc thực thi các quy tắc tường minh. Nếu điều kiện A thỏa mãn, hãy thực hiện hành động B. Nhưng nhiều phán đoán trong thế giới thực khó có thể định nghĩa trước bằng các quy tắc.
Giống như việc đọc bình luận. Biểu đạt nào là phàn nàn? Biểu đạt nào là đùa cợt? Biểu đạt nào nghe có vẻ tích cực nhưng chứa đựng sự phê bình ngầm? Thật khó để bao quát tất cả các kiểu nói của người dùng chỉ với vài quy tắc.
TypeSafe muốn biến phán đoán ngữ nghĩa thành một thành phần có thể gọi được. Khi một chương trình cần hiểu văn bản hoặc chọn bước tiếp theo, nó ủy quyền nhiệm vụ nhỏ này cho mô hình, lấy kết quả và tiếp tục thực thi.
Họ gọi những mô hình này là System One, mượn khái niệm từ cuốn sách Thinking, Fast and Slow (Tư duy nhanh và chậm). Hãy coi nó như phần phán đoán nhanh chóng và trực giác.
Cái tên Jev bắt nguồn từ nhà kinh tế học Jevons. Kỳ vọng của đội ngũ khá đơn giản: Chi phí cho các cuộc gọi thông minh càng thấp, thì càng nhiều nơi sẽ sử dụng chúng.
Một số bước trước đây bị coi là quá đắt đỏ cho một lần gọi AI duy nhất. Nếu phán đoán đủ nhanh và rẻ, nó trở nên đáng để xem xét lại.
Jev khác biệt thế nào so với LLMs?
Việc làm cho các cuộc gọi phán đoán AI trong phần mềm trở nên rẻ hơn và dễ dàng hơn là một khởi đầu tốt. Nhưng các LLM hiện có cũng có thể phán đoán và trả về kết quả có cấu trúc. Tại sao phải xây dựng Jev?
Trước tiên, hãy xem cách LLMs cung cấp kết quả phán đoán cho các chương trình.
LLMs hỗ trợ đầu ra có cấu trúc, nghĩa là các câu trả lời khớp vào các ô được định nghĩa trước. Ví dụ, một ô cho cảm xúc, một ô cho mức độ khẩn cấp, một ô cho phương pháp xử lý. Chương trình biết ý nghĩa của từng vị trí.
Có thể bạn đã biết JSON, một định dạng phổ biến cho dữ liệu có cấu trúc. Các nhà phát triển có thể ràng buộc đầu ra của LLM tuân theo các định dạng cụ thể.
Vì vậy, nếu chỉ nhìn vào việc đầu ra cuối cùng là văn bản hay JSON, chúng ta chưa thấy được sự khác biệt chính giữa Jev và LLMs.
Sự khác biệt nằm ở cách mô hình tạo ra kết quả.
Các LLM sinh tạo tiêu chuẩn thường tạo ra câu trả lời theo từng token. Token là những mảnh nhỏ của văn bản được xử lý bởi mô hình. Ngay cả khi bạn yêu cầu dữ liệu định dạng cố định, nó thường vẫn tạo ra kết quả từng bước một.
Jev sử dụng một phương pháp đầu ra chuyên biệt cho các tác vụ phán đoán, cung cấp nhiều phán đoán và xác suất song song. Bạn có thể đặt vài câu hỏi về cùng một bình luận và nhận tất cả kết quả trong một lần yêu cầu.
Sự khác biệt về đầu ra này liên quan đến tốc độ và chi phí đã đề cập trước đó. Phần mềm xử lý lượng dữ liệu khổng lồ mỗi ngày chịu chi phí đáng kể ngay cả với những bước nhỏ. Agents, vốn gọi các công cụ và thực hiện các chuỗi tác vụ liên tục, cần quyết định lặp đi lặp lại bước tiếp theo. Tốc độ phản hồi và chi phí gọi API ảnh hưởng trực tiếp đến thiết kế phần mềm, chi phí vận hành và trải nghiệm người dùng. Một số bước trước đây bị bỏ qua vì chậm hoặc tốn kém giờ đây có thể bao gồm phán đoán AI.
Ngoài ra còn có tính ổn định của đầu ra. Chúng ta định nghĩa một tập hợp các tùy chọn, và nó trả về kết quả trong phạm vi đó, giúp ích cho việc xử lý downstream của chương trình.
Ba tính năng mới của Jev
Lõi của Jev nằm ở ba tính năng mới. Logic thiết kế của chúng rất thú vị và đáng để xem xét.
Tóm tắt, Choice (Lựa chọn) thực hiện việc chọn từ các tùy chọn đã cho; Score (Điểm số) gán đánh giá dựa trên tiêu chí; Noul phán đoán xác suất một phát biểu là đúng.
Ở đây, mình sẽ sử dụng Playground chính thức để minh họa các tính năng này với một ví dụ thực tế.
Hãy dùng trường hợp xử lý bình luận thương mại điện tử. Giả sử bạn điều hành một cửa hàng trực tuyến nhận được đánh giá từ khách hàng mỗi ngày. Bạn cần đo lường mức độ hài lòng, xác định các vấn đề cần theo dõi, quyết định phương pháp xử lý và ưu tiên các trường hợp khẩn cấp.
Chúng ta sẽ gửi bình luận này cho Jev:
"Sản phẩm tốt, nhưng vận chuyển mất mười ngày, và dịch vụ khách hàng không trả lời."
Chúng ta sẽ sử dụng ba tính năng để phán đoán bình luận này và xem kết quả.
Choice: Thực hiện Lựa chọn
Đầu tiên, hãy hỏi: Cảm xúc chung là gì?
Các tùy chọn được cung cấp: Hài lòng, Không hài lòng, Trộn lẫn, Không xác định.
Kết quả: "Trộn lẫn."
Điều này dễ hiểu. Người dùng khen sản phẩm nhưng phàn nàn về logistics và dịch vụ. Chỉ chọn "Hài lòng" hoặc "Không hài lòng" sẽ làm mất một phần ý nghĩa.
Tương tự, chúng ta có thể hỏi: Nên xử lý bình luận này như thế nào tiếp theo?
Các tùy chọn: "Chuyển cho con người," "Trả lời tự động," "Không cần trả lời." Thêm quy tắc: Các khiếu nại dịch vụ chưa giải quyết yêu cầu sự can thiệp của con người.
Kết quả: "Chuyển cho con người."
Lưu ý rằng, nội dung của câu hỏi trắc nghiệm có thể thay đổi. Cảm xúc, bộ phận, hành động tiếp theo—tất cả đều có thể được khung hóa theo cách này. Các tùy chọn do chúng ta cung cấp; Jev phán đoán dựa trên tài liệu và yêu cầu.
Score: Gán Điểm số
Tiếp theo, hãy hỏi: Bình luận này khẩn cấp đến mức nào? Chúng ta phải theo dõi nhanh như thế nào?
Trước khi chấm điểm, hãy định nghĩa các tiêu chuẩn. Ba cấp độ được thiết lập ở đây:
- 0: Đánh giá chung hoặc thắc mắc đơn giản, không có khiếu nại chưa giải quyết.
- 1: Khiếu nại chưa giải quyết về logistics hoặc dịch vụ, nhưng không có vấn đề an toàn, tổn thất lớn hoặc hạn chót gấp.
- 2: Vấn đề an toàn rõ ràng, tổn thất lớn hoặc hạn chót gấp.
Jev trả về 1, chỉ ra mức độ khẩn cấp trung bình theo tiêu chuẩn này.
Điểm số phụ thuộc rất nhiều vào các tiêu chuẩn bạn cung cấp. Bạn có thể chuyển sang đánh giá chất lượng trả lời hoặc mức độ liên quan, nhưng bạn phải định nghĩa thế nào là tốt hay xấu.
Nó cũng có thể trả về điểm số thập phân giữa các cấp độ, không chỉ là số nguyên.
Noul: Phán đoán Tính đúng đắn của Phát biểu
Cuối cùng, đưa cho nó một phát biểu:
"Người dùng đã yêu cầu hoàn tiền rõ ràng trong bình luận."
Loại này trả về một xác suất giữa 0 và 1, đại diện cho khả năng phát biểu đó là đúng.
Kết quả: 0.03 (3%).
Người dùng không hài lòng, nhưng không yêu cầu hoàn tiền một cách rõ ràng. Vì vậy, mô hình đưa ra xác suất thấp cho "yêu cầu hoàn tiền rõ ràng".
Xem xét tất cả các kết quả trả về cùng nhau giúp làm rõ bức tranh tổng thể:
Bốn câu hỏi này được gửi cùng lúc, mang lại tất cả kết quả trong một lần. API báo cáo thời gian đánh giá của mô hình khoảng 85 mili giây.
Bây giờ, chương trình đã có thông tin hữu ích: danh mục cảm xúc, đích chuyển tuyến, mức độ ưu tiên, ý định hoàn tiền. Việc xử lý có thể tiếp tục dựa trên các kết quả này.
Jev có thể được sử dụng cho những gì?
Chúng ta đã xử lý một bình luận. Trên một nền tảng thương mại điện tử với khối lượng khổng lồ mỗi ngày, cách sử dụng này mở rộng xa hơn nữa.
Thứ nhất, thống kê.
Những người dùng nào hài lòng? Ai phàn nàn về logistics? Vấn đề nào cần dịch vụ khách hàng? Mô hình phán đoán ý nghĩa; chương trình tổng hợp số đếm và hiển thị các danh mục.
Thứ hai, lọc sơ bộ để quyết định những gì cần xử lý sâu hơn.
Các đánh giá chung đi vào thống kê. Các mục không cần trả lời bỏ qua việc trả lời cá nhân. Các vấn đề chưa giải quyết chuyển cho con người. Các phản hồi tự động phù hợp cho việc tạo bởi LLM được chuyển cho các mô hình lớn hơn với bối cảnh đầy đủ.
Trước đây, việc để một LLM chung đắt đỏ sàng lọc mọi thứ trước tiên gây ra chi phí ban đầu cao. Bây giờ, Jev đảm nhận việc sàng lọc phía trước, để lại việc xử lý sâu cho các LLM.
Liệu lọc từ khóa có hoạt động không?
Một phần, nhưng từ khóa bỏ sót ngữ cảnh.
Ví dụ:
"Chất lượng thật tuyệt vời, rã rời sau một ngày."
Việc khớp "chất lượng tuyệt vời" sẽ phân loại sai cái này là tích cực. Đọc cả câu tiết lộ sự mỉa mai.
Jev vẫn chấp nhận đầu vào ngôn ngữ tự nhiên và hiểu toàn bộ ý nghĩa. Sự chuyên môn hóa của nó nằm ở loại tác vụ và định dạng đầu ra, không chỉ là khớp từ khóa.
Biến kết quả thành hành động đòi hỏi các chương trình bên ngoài.
Trả về "chuyển cho con người", chương trình xếp hàng để xem xét thủ công. Trả về "trả lời tự động", chương trình gọi LLM để tạo phản hồi. Các hành động được thực thi bởi các quy tắc workflow và công cụ.
Trong Agents, hệ thống bên ngoài tổ chức các cuộc gọi mô hình, công cụ và workflow này thường được gọi là Harness. Jev phù hợp vào các vị trí phán đoán trong Harness, giúp chọn bước tiếp theo.
Do đó, mình tin rằng Jev và LLMs bổ sung cho nhau, chứ không loại trừ lẫn nhau.
Cụ thể, thay thế LLMs bằng Jev cho việc phân loại và chấm điểm. Sau đó, đối với việc viết copy, code hoặc suy luận đa bước phức tạp, hãy dựa vào LLMs.
Như vậy, một hệ thống có thể sử dụng các mô hình khác nhau cho các giai đoạn khác nhau, kết hợp các khả năng một cách hữu cơ.
Làm thế nào để trải nghiệm Jev?
Cách trực tiếp nhất là mở TypeSafe Playground.
Đăng nhập, đặt văn bản cần phân tích vào State (tài liệu để phán đoán). Thiết lập các câu hỏi trong Questions, chọn loại phán đoán, điền vào các tùy chọn hoặc tiêu chí chấm điểm, nhấp Run để xem kết quả.
Thử bình luận trước đó hoặc hoán đổi sang một đánh giá tích cực để quan sát sự thay đổi.
Để tích hợp vào phần mềm của bạn, hãy sử dụng API.
API cho phép một phần mềm cung cấp khả năng cho phần mềm khác. Lấy một API Key từ console. Chương trình của bạn gửi tài liệu và câu hỏi cùng với thông tin đăng nhập này, nhận kết quả và thực thi logic tiếp theo.
Các SDK chính thức cũng được cung cấp, đóng gói các hàm giao diện phổ biến để thuận tiện cho nhà phát triển.
Giá cả: $0.042 mỗi triệu token đầu vào, đầu ra miễn phí. Đầu vào bao gồm tài liệu, câu hỏi và tiêu chí. Việc lọc bình luận khối lượng lớn có thể sử dụng mô hình trả phí theo lượt gọi này trong các luồng hiện có.
Tương lai của các Mô hình Phán đoán Chuyên biệt
Sau khi nghiên cứu Jev, mình rất ấn tượng: Đáng lẽ ai đó nên làm điều này từ lâu, nhưng không ai làm.
Mình nghĩ cách tiếp cận này là đúng. Trong khi mọi người đang chạy đua để tăng hiệu suất của các mô hình lớn, TypeSafe AI đã mở ra một đường đua mới, tạo ra các mô hình tùy chỉnh cho các kịch bản dữ liệu có cấu trúc, phán đoán xác suất, lựa chọn và ra quyết định.
Lợi ích về chi phí và tốc độ thân thiện với Agents. Chờ đợi các mô hình lớn trả về dữ liệu chậm chạp là không hiệu quả trong một số ngữ cảnh.
Mình tin rằng các nhà cung cấp khác có khả năng sẽ theo xu hướng này, xây dựng các mô hình chuyên biệt cho các giai đoạn phán đoán của Agent.
Một Agent có thể có các mô hình cho phán đoán nhanh, các mô hình khác cho suy nghĩ/phức tạp/viết/code, cộng với các mô hình hình ảnh/âm thanh/video, hoạt động cùng nhau.
Khi phán đoán đủ nhanh và rẻ, chúng ta có thể đặt AI vào nhiều nơi trước đây bị coi là không đáng để gọi. Đối với mình, đây là phần thú vị nhất của hướng đi Jev.
