OpenAI có lợi thế lớn để tích hợp trực tiếp khả năng phân loại của Jev vào mô hình

Jev của TypeSafe đã mang đến một làn gió mới cho các mô hình ngôn ngữ lớn (LLM), tạo nên một cơn sốt trong giới AI. Theo Vercel, "Jev được áp dụng nhanh hơn bất kỳ mô hình nào khác trong lịch sử của AI Gateway."... Tuy nhiên, những đám mây đen đang dần xuất hiện ở phía chân trời. OpenAI chắc chắn đang chú ý đến điều này – và đang cân nhắc xem nên làm gì tiếp theo.

Tôi chúc TypeSafe mọi điều tốt đẹp nhất, nhưng nếu họ thực sự làm đúng như những gì đã hứa, tôi lo ngại rằng OpenAI đang ở vị thế thuận lợi để nhanh chóng bắt kịp – không chỉ để sao chép sản phẩm chủ lực của Jev, mà còn để tích hợp khả năng đó vào các mô hình và tác nhân (agent) sắp tới, đồng thời cung cấp những hành vi mới thực sự hữu ích mà Jev chưa có khả năng tái tạo.

Tóm tắt luận điểm của tôi: Trong nhiều năm qua, OpenAI đã sử dụng các LLM của họ như những bộ phân loại (classifier) ẩn; chỉ là họ chưa huấn luyện chúng cho các tác vụ phân loại tổng quát và chưa đóng gói phân loại tổng quát thành một sản phẩm độc lập. Nếu OpenAI có thể sao chép quy trình huấn luyện, họ sẽ có thể tái tạo Jev trong thời gian ngắn. Hơn nữa, OpenAI có lợi thế để sử dụng bộ phân loại mới này bên trong các mô hình và tác nhân hiện có, điều này có thể hữu ích cho việc lựa chọn mô hình nhanh chóng, tư duy hiệu quả hơn, các rào cản bảo mật tốt hơn, và nhìn chung là tạo ra các mô hình thông minh hơn, nhanh hơn và rẻ hơn.

Yếu tố then chốt quyết định tất cả những điều này là liệu TypeSafe có một "con hào kinh tế" (moat) để tự bảo vệ mình hay không. Con hào lớn nhất mà tôi thấy nằm ở dữ liệu huấn luyện và quy trình huấn luyện của TypeSafe.

Cái cũ lại trở thành cái mới

Trước khi đưa ra lập luận, hãy để tôi nêu các giả định của mình và củng cố chúng bằng một số lịch sử và ví dụ liên quan từ OpenAI.

Giả định chính của tôi là Jev đang sử dụng thứ gì đó khá gần với một mô hình ngôn ngữ lớn thông thường. Bằng chứng cho điều này là Latent Space báo cáo rằng nhiều bản sao đời đầu thực sự dựa trên LLM.

Ý tưởng là thế này. Với một trạng thái và một tập hợp các câu hỏi, LLM của Jev tạo ra một token duy nhất hoặc, chính xác hơn, tạo ra phân phối xác suất trên tất cả các token tiếp theo có thể. Các logprobs (log xác suất) liên quan đến mọi token có thể tại một bước đó sau đó được tinh chỉnh thành bất kỳ định dạng nào mà Jev cần để trả về. (Từ đây trở đi, tôi sẽ chỉ gọi là "xác suất" thay vì "logprobs" – vì mục đích của chúng ta, chúng có thể thay thế cho nhau.)

Đối với một câu hỏi dạng "noul" (đúng/sai), Jev chỉ nhìn vào hai token, true và false, bỏ qua mọi thứ khác và chuẩn hóa xác suất của chúng thành một xác suất duy nhất cho câu trả lời là true. Đối với một câu hỏi lựa chọn, Jev có thể được gợi ý với một danh sách các khả năng – ví dụ A=vui, B=buồn, C=giận, D=sợ – và nó nhìn vào xác suất tương đối của bốn token đó để xây dựng phân phối đầy đủ, chọn token cao nhất làm người chiến thắng. Mô hình lựa chọn này khá giống với những gì tôi đã viết trên blog từ năm 2025 trong bài "Supercharging LLM Classifications with Logprobs", và ngay cả khi không cần tinh chỉnh (fine-tuning), nó đã cho thấy nhiều hứa hẹn. (Than ôi... người ta thường nói gì về ý tưởng và tầm quan trọng của việc thực thi nhỉ?) Tôi chưa suy nghĩ kỹ về nguyên hàm điểm số (score primitive), nhưng tôi nghi ngờ đó là một biến thể của cùng một mô hình này.

Một phần tiền đề của bài viết này là OpenAI có thể đã sẵn sàng để nhanh chóng tận dụng ý tưởng này, và điều đó trở nên rõ ràng hơn nếu bạn hiểu cách thức thực hiện. OpenAI đã sử dụng các mô hình ngôn ngữ lớn một cách ẩn ý như những bộ phân loại chuyên biệt kể từ ít nhất là khi giới thiệu tính năng gọi công cụ (tool calling).

Quay lại đầu năm 2024, tôi đã viết bài "Tool Invocation – Demonstrating the Marvel of GPT's Flexibility", nơi tôi đã thuyết phục một mô hình GPT tiết lộ chính xác cách nó quyết định gọi một công cụ. Dưới đây là giao diện nội bộ của một phiên trò chuyện. Ở đây có một tin nhắn của người dùng, sau đó là phản hồi của trợ lý không có lệnh gọi công cụ, tiếp theo là tin nhắn của người dùng có lệnh gọi công cụ:

Tôi đã mã hóa màu văn bản để chỉ ra ranh giới của các token. Nếu bạn chưa từng thấy ChatML trước đây, đó là ngôn ngữ đánh dấu nội bộ mà OpenAI giới thiệu để tổ chức các lời nhắc hội thoại giữa người dùng và tác nhân. <|im_start|> và <|im_end|> là các token dành riêng để phân định các tin nhắn, và token đầu tiên sau <|im_start|> xác định người nói, là user hoặc assistant.

Ngay sau <|im_start|>assistant, token đầu tiên mà mô hình dự đoán là \n hoặc to=function.. Nếu nó dự đoán \n, nó sẽ tiếp tục với một phản hồi ngôn ngữ tự nhiên bình thường. Nếu nó dự đoán to=function., thì chuỗi token đó thực sự hoạt động như một bộ phân loại quyết định xem một công cụ có nên được gọi hay không. Một vài token tiếp theo xác định công cụ nào cần gọi – get_temperature – một bộ phân loại khác, lần này là chọn từ danh sách các công cụ có sẵn. Sau đó, mô hình tạo ra tên đối số, rồi đến giá trị đối số, những thứ này cũng có thể được coi một cách mơ hồ là các bộ phân loại hoặc bộ ước tính. Cuối cùng, khi mô hình tạo ra token <|im_end|>, đó cũng là một bộ phân loại đọc là "true" khi mô hình tin rằng tin nhắn đã hoàn tất.

Một số LLM chỉ đơn giản là không biết khi nào nên dừng lại - một chi tiết bên lề khá hài hước.

Khi còn ở GitHub làm việc với Copilot, tôi đã có cơ hội làm việc với một API nội bộ rất mới và thô sơ cho GPT-4. Ngay từ đầu, chúng tôi biết có điều gì đó không ổn vì sau một phản hồi ban đầu rất mạch lạc, mô hình gặp khó khăn trong việc kết thúc. Nó sẽ kết thúc mọi phản hồi bằng những câu như "Hãy cho tôi biết nếu bạn có bất kỳ câu hỏi nào khác. Chúc bạn một ngày tốt lành. Chúc bạn một tuần tuyệt vời. Chúc bạn có khoảng thời gian vui vẻ. Chúc bạn một cuộc sống tuyệt vời. Chúc bạn một ngày đặc biệt...." và nó cứ tiếp tục như vậy cho đến khi chạm giới hạn token phản hồi.

Hóa ra, API yêu cầu chúng tôi thiết lập một số giá trị tiêu đề (header) cho phép mô hình sử dụng các dấu phân cách tin nhắn đặc biệt <|im_start|> và <|im_end|>. Thực tế là chúng tôi đã ngăn cản mô hình dự đoán điểm kết thúc phản hồi của chính nó – nó hoàn toàn không có khả năng nội tại để tự dừng lại!

Điểm tôi muốn nhấn mạnh trong bài viết cũ đó là OpenAI đã sử dụng các token đơn lẻ như những bộ phân loại siêu nhỏ trong nhiều năm. Mỗi token mang một xác suất: chúng ta có nên sử dụng công cụ hay không, nên sử dụng công cụ nào, trợ lý đã hoàn thành chưa. Đó thực sự là toàn bộ thủ thuật của Jev, ngoại trừ một điều quan trọng: các bộ phân loại siêu nhỏ này là những chuyên gia, chỉ phù hợp cho những tác vụ nhỏ này, trong khi các bộ phân loại của Jev mang tính tổng quát. Nhưng hãy lùi lại một hoặc hai bước và bạn sẽ thấy đây có thể là một điều nhỏ nhặt, bởi vì một LLM thực sự là một bộ phân loại cực kỳ tổng quát, liên tục gán một phân phối xác suất cho mọi token tiếp theo.

Liệu TypeSafe có "con hào" bảo vệ không?

Tôi thực sự đang ủng hộ Jev. Tôi nghĩ họ đã tìm thấy một điều gì đó rất thú vị vốn luôn ẩn giấu ngay trước mắt chúng ta.

Về mặt kiến trúc, tôi không nghĩ có nhiều "con hào" vì chính những lý do đã nêu ở trên. Tôi nghĩ TypeSafe đang sử dụng một mô hình ngôn ngữ lớn thông thường cho Jev, hoặc thứ gì đó gần giống như vậy. Và ngay cả khi không phải, các LLM thông thường dường như rất phù hợp cho công việc phân loại tổng quát.

Có lẽ "con hào" thực sự nằm ở chính dữ liệu huấn luyện. Không phải dữ liệu thô, mà là kỹ thuật biến nó thành thứ huấn luyện Jev trở nên "được hiệu chuẩn" (calibrated). Đồng sáng lập của TypeSafe, Diogo Almeida, đã nói như vậy khi có người cho rằng dữ liệu quan trọng hơn kiến trúc:

bạn có thể là người đầu tiên nói về dữ liệu hơn là kiến trúc! 🥲 chúng tôi coi mình là một phòng thí nghiệm nghiên cứu dữ liệu! phần lớn các nghiên cứu tập trung vào việc tạo ra dữ liệu thực sự tổng quát (giống như một lõi nhận thức) và 100% dữ liệu của chúng tôi là dữ liệu tổng hợp (nhưng tất nhiên không phải loại rác rưởi được tạo ra từ LLM).

Nếu tôi xây dựng tập dữ liệu đó, tôi sẽ muốn một đống lớn các ví dụ mà kết quả đã được biết trước – các phiếu hỗ trợ và cách chúng thực sự được định tuyến, sơ yếu lý lịch và liệu ứng viên đó có thực sự được tuyển dụng hay không, đánh giá sản phẩm và xếp hạng sao thực tế của chúng, hàng đợi kiểm duyệt và phán quyết thực tế của chúng, thị trường dự đoán và cách chúng thực sự giải quyết – mỗi ví dụ được ghép nối với một câu hỏi mà tôi đã biết câu trả lời đúng. Mục đích không phải là dạy Jev về phiếu hỗ trợ hay sơ yếu lý lịch cụ thể. Mà là để cho nó thấy hàng ngàn tình huống trên các lĩnh vực hoàn toàn khác nhau và xây dựng khả năng khái quát hóa các phân loại trên các lĩnh vực rộng lớn.

Sau đó là học tăng cường (reinforcement learning). Tôi tự hỏi điều này bao gồm những gì. Các tác nhân tự hành điều hướng các quyết định với một tập hợp các tùy chọn hạn chế như bản demo Wikipedia hoặc bản demo Doom mà họ xây dựng trên trang web của mình? Có lẽ là dự đoán kết quả của các sự kiện xảy ra sau thời điểm cắt dữ liệu huấn luyện (pre-training cutoff)? Tôi không biết, nhưng nếu có "bí quyết" nào đó, thì có lẽ nó nằm ở đây.

Lưu ý rằng không có điều nào trong số này là "con hào" trừ khi Jev thực sự chính xác. Tốc độ, chi phí và sự dễ sử dụng là những thứ rõ ràng, nhưng độ chính xác là thứ khó kiểm tra nhất. Tôi đã tìm thấy các lĩnh vực mà xác suất của Jev không chính xác. Thời gian sẽ trả lời liệu Jev có đủ tổng quát và chính xác cho các trường hợp sử dụng mà mọi người đang cố gắng áp dụng hay không.

Sắp tới sẽ là nước đi của OpenAI

Vậy nước đi tiếp theo của OpenAI ở đây là gì? Điều hiển nhiên là chỉ cần sao chép Jev và phát hành nó như một loại mô hình mới. Jev rõ ràng đang phổ biến, và nếu "con hào" nông, thì OpenAI có kỹ năng, phần cứng và nguồn vốn để thực hiện điều đó.

Nhưng OpenAI có thể làm điều gì đó thú vị hơn cả việc sao chép Jev, họ có thể tích hợp khả năng phân loại vào một LLM thông thường và gặt hái một số phần thưởng thú vị.

Một LLM tự trả lời các câu hỏi của chính mình

Hãy nhớ cú pháp đặc biệt báo hiệu một lệnh gọi công cụ, to=function.? OpenAI có thể làm điều tương tự ở đây: giới thiệu cú pháp mới, ví dụ, một thẻ mới, <prediction>, mà mô hình có thể đưa vào ngữ cảnh của chính nó bất cứ khi nào nó cần một phán đoán phân loại nhanh. Đây là một ví dụ về cách nó có thể trông như thế nào.

Có một điểm khác biệt thú vị so với việc gọi công cụ thông thường. Với một lệnh gọi công cụ bình thường, mô hình tạo ra tên hàm và các đối số, sau đó quá trình tạo dừng lại – bộ khung tác nhân (agent harness) phải tiếp quản, thực sự gọi hàm và đưa kết quả trở lại trong một lượt mới. Ở đây, không có sự chuyển giao nào cả. Bộ phân loại không phải là một công cụ nằm ngoài mô hình, mà là một khả năng được tích hợp sẵn trong chính mô hình. Mô hình đặt câu hỏi và tự trả lời ngay lập tức, mà không bao giờ rời khỏi GPU.

Giải mã bình thường hoạt động như thế này: tại mỗi vị trí, mô hình tạo ra một tập hợp các logit, một cho mỗi token từ vựng; chúng được chuyển thành phân phối xác suất thông qua softmax; và sau đó một chiến lược giải mã nào đó (greedy, top-p, bất cứ thứ gì) chọn một token duy nhất, token này được thêm vào chuỗi và đưa trở lại cho bước tiếp theo. Nhưng tại thời điểm mô hình đã viết probability:, chúng ta không muốn giải mã thông thường. Khẳng định được diễn đạt như một tuyên bố, vì vậy về cơ bản mô hình vẫn đang cân nhắc hai kết quả ẩn – true hoặc false. Chúng ta muốn đọc các logit cho các token true và false tại vị trí đó, chuẩn hóa chỉ hai giá trị đó với nhau và viết xác suất thu được trở lại chuỗi dưới dạng văn bản, 0.04, thay vì bất kỳ token nào thường thắng. Sau đó, mô hình tiếp tục giải mã như thể nó đã tự tạo ra con số đó, bởi vì đối với phần còn lại của quá trình chuyển tiếp (forward pass), nó đã làm như vậy. Đó là một thủ thuật kỳ lạ, nhưng nó giống với loại giải mã có hướng mà các thư viện đầu ra bị ràng buộc (constrained-output) đã thực hiện tại thời điểm suy luận – chỉ là áp dụng cho xác suất thay vì ngữ pháp.

Thủ thuật khác là vị trí đặc biệt này cần hoạt động khác với dự đoán token thông thường. Thông thường, mô hình đang ước tính "token nào tiếp theo trong văn bản này". Ở đây, chúng ta cần nó ước tính thứ gì đó gần hơn với "câu trả lời đúng cho câu hỏi này là gì", đây là một kỹ năng liên quan nhưng khác biệt. Mọi mô hình tiên phong ngày nay đều là hỗn hợp các chuyên gia (mixture of experts - MoE), vì vậy không khó để tưởng tượng rằng một vài vòng tinh chỉnh có thể tạo ra một chuyên gia chuyên về chính loại phán đoán nhanh được hiệu chuẩn này, trong khi phần còn lại của mô hình vẫn tiếp tục làm tốt những gì nó đã làm. (Tôi đang đơn giản hóa quá mức việc định tuyến MoE, nhưng tôi nghi ngờ bạn hiểu cách điều này có thể ánh xạ tới một hệ thống thực tế.)

Lợi ích của một LLM với tính năng phân loại tích hợp

Hãy nhìn cách mô hình vừa sử dụng chính nó trong ví dụ Donny và Jess đó. Nếu TypeSafe đúng, những phán đoán nhỏ giống Jev này sẽ khá chính xác – và ít bị ảo giác hơn so với việc chỉ yêu cầu mô hình nêu giá trị tin cậy bằng văn bản thuần túy. (Các lưu ý vẫn áp dụng – hãy xem bản tóm tắt của chính TypeSafe về các điểm yếu của Jev. Jev hoạt động tốt nhất cho các phán đoán nhanh, Hệ thống 1, không phải toán học hoặc suy luận đa bước.)

Phần tốt nhất là thực tế đã đề cập ở trên rằng chúng ta không bao giờ phải rời khỏi GPU để tận dụng hệ thống phân loại tổng quát nhanh như chớp này. LLM thực sự có thể tự hỏi chính nó, ngay tại đó trong khối tư duy, như đã hiển thị ở trên. Lợi ích là ngay lập tức: khả năng suy luận của chính mô hình trở nên chính xác hơn và có cơ sở hơn, bởi vì nó đang kiểm tra các giả định của mình dựa trên các ước tính được hiệu chuẩn đã được huấn luyện thay vì các cảm tính về token tiếp theo có khả năng xảy ra nhất.

Và một khi mô hình đã được tinh chỉnh để đưa một <prediction> vào tư duy của chính nó, không có lý do gì để dừng lại ở lời khuyên lãng mạn. Một vài mô hình khác nảy ra trong đầu:

Trong một quá trình suy luận dài, mô hình có thể định kỳ kiểm tra xem nó đã thực sự hoàn thành chưa, và nếu chưa, thì tác vụ nào cần giải quyết tiếp theo:

Đó là một cách rẻ tiền để ngắt quãng một quá trình suy luận đang đi chệch hướng, thay vì đợi mô hình tự thuyết phục bản thân dừng lại.