Đi sâu vào nền tảng để xem Jev, liệu có thể đội vương miện "cải cách mô hình" không

Tác giả: Bác Dương

Biên tập: Xu Thanh Dương

Trong giới công nghệ, chu kỳ thổi phồng luôn giống nhau một cách đáng ngạc nhiên.

Vào tháng 9 năm 2026, toàn bộ Thung lũng Silicon và cộng đồng mã nguồn mở đang phát cuồng vì một mô hình có tên là Jev.

Nó tuyên bố đây là một mô hình "Hệ thống Một (System One)", tự xưng có khả năng mang lại những thay đổi mang tính cách mạng.

Trong ba bốn năm qua, chúng ta đã quen với những mô hình ngôn ngữ lớn (LLM) giống như những nhà văn dài dòng, trước khi trả lời một câu hỏi đơn giản "Có" hay "Không", chúng thường phải tạo ra hàng trăm token suy nghĩ vô nghĩa, rồi mới từ từ đưa ra một kết luận ở định dạng JSON.

Nhưng Jev thì khác, nó hứa hẹn sẽ trực tiếp đưa ra phán đoán, cung cấp xác suất và nhanh đến mức đáng kinh ngạc.

Các nhà phát triển đã phát cuồng vì giao diện "nhanh, chính xác, mạnh mẽ" này.

Dù sao, khi bạn xây dựng một AI Agent (tác nhân thông minh) phức tạp, điều bạn thường cần chỉ là hỏi nó: "Ký ức này có liên quan không?", "Yêu cầu này nên giao cho công cụ nào?", "Sự cố này có cần kiểm tra lại bằng tay không?".

Mọi người đã phải trả giá quá nhiều token và độ trễ để một mô hình lớn tổng quát tạo ra văn bản, giải thích và mã hóa có cấu trúc cho từng vấn đề nhỏ trong công việc. Bắt đầu từ nhu cầu thực tế, Jev đã chạm vào một điểm đau cực kỳ nhức nhối.

Nhưng liệu nó có thực sự đủ tính cách mạng không?

Khi chúng ta bỏ qua quá trình "tạo văn bản", khả năng phán đoán còn lại trong cái hộp đen này, thực sự có bao nhiêu là từ món quà của mô hình ngôn ngữ lớn ban đầu, và bao nhiêu là từ việc đào tạo chuyên biệt mà đội ngũ TypeSafe gọi là?

Để trả lời câu hỏi này, chúng ta có thể bóc tách lớp lớp bao bì của Jev, phân tích từ nhiều khía cạnh khác nhau.

01

Mô hình dự đoán phán đoán ra đời trước GPT

Hướng đi mà Jev đại diện có một lịch sử rất dài.

Ngay từ năm 2018, Google đã phát hành BERT. Nó khác với các mô hình GPT mà chúng ta quen thuộc ngày nay, sử dụng kiến trúc Encoder-only (chỉ mã hóa) cho phép thông tin giao tiếp hai chiều, đào tạo mô hình để hoàn thành các câu.

Mặc dù sau này, mô hình Decoder-only (chỉ giải mã) được sử dụng để đào tạo viết tiếp (như ChatGPT) trở thành xu hướng chính, nhưng trong các nhiệm vụ phân loại rõ ràng, BERT vẫn có những lợi thế của nó.

Nhờ vào Encoder có thể nhìn thấy tất cả thông tin, BERT có thể kết hợp các vị trí trong văn bản với bối cảnh trước và sau để tạo ra biểu diễn đặc trưng hoàn chỉnh, sau đó kết nối với một lớp phân loại đơn giản, và sau khi được đào tạo bằng các email đã được gán nhãn, nó có thể nhanh chóng đưa ra phán đoán.

Và các LLM hiện đại thực sự cũng thường được đào tạo thành vai trò của một bộ phân loại.

Năm 2019, OpenAI trong bài báo "Fine-Tuning Language Models from Human Preferences" đã bắt đầu thử nghiệm để mô hình học sở thích của con người đối với văn bản.

Đến năm 2020, trong nghiên cứu về tóm tắt văn bản, quy trình công nghệ này trở nên rõ ràng hơn, các nhân viên gán nhãn con người trước tiên so sánh hai tóm tắt, sau đó sử dụng nó để đào tạo mô hình thưởng học cách dự đoán con người thực sự thích tóm tắt nào hơn.

Trong quá trình này, phán đoán của con người đã được chuyển đổi thành một hàm điểm số thành công. Mô hình thưởng bản thân không cần viết ra những bình luận dài dòng, nó chỉ cần đọc câu hỏi và câu trả lời, rồi thông qua lớp đầu ra của mạng nơ-ron đưa ra điểm số.

Điều này thực sự cũng là một trong những mô hình học cơ bản nhất hiện nay, đó chính là RLHF mà Jev mạnh mẽ chỉ trích.

Do đó, "kế thừa khả năng hiểu biết của mô hình ngôn ngữ, nhưng không tạo ra văn bản" không phải là ý tưởng thiên tài độc quyền của Jev.

Đến năm 2023, trong bài báo nổi tiếng "Let's Verify Step by Step", sự giám sát này đã được tinh chỉnh hơn nữa và áp dụng vào từng bước của mô hình. Mô hình thưởng, bộ xác thực và các chỉ số đánh giá đã phát triển từ các nhiệm vụ khác nhau, dần dần hình thành nên một số công cụ phán đoán không thể thiếu trong ngành công nghiệp AI.

Đến năm 2025-2026, các nghiên cứu liên quan vẫn đang được thúc đẩy. Năm 2025, Galileo phát hành Luna-2 và trong bài báo tiếp theo đã trình bày cách đào tạo các mô hình ngôn ngữ nhỏ thành "bộ phân loại đơn Token", thông qua một lần tính toán tiến về phía trước để trực tiếp đọc xác suất của các loại mục tiêu. Trong khi đó, Skywork-Reward-V2 đã phát hành một loạt mô hình thưởng từ 0.6B đến 8B, tối ưu hóa lộ trình điểm số trực tiếp cho LLM.

Từ góc độ thực hiện thuật toán, điều này không khó. Thực hiện một số thay đổi đơn giản cho LLM, để nó trực tiếp tính toán điểm số ứng viên từ các biểu diễn ẩn bên trong, thay vì phát ra một đống chữ, có rất nhiều cách.

Trong các thí nghiệm sao chép sau đó, chúng ta có thể thấy hơn ba cách.

Vậy Jev thực sự mang đến điều gì khác biệt trong làn sóng này?

Từ những thông tin giải mã cấu trúc hiện tại và các tuyên bố chính thức, sự khác biệt cốt lõi của Jev thể hiện ở hai khía cạnh.

Đầu tiên, là sự thay đổi tổng quát hơn, nhờ vào phương pháp đào tạo hậu kỳ hoàn toàn mới.

Các bộ điểm trước đây chủ yếu được đào tạo cho một nhiệm vụ đơn lẻ. Jev không còn bị giới hạn bởi một loại điểm số cụ thể nào, mà cố gắng cung cấp một giao diện xác suất cực kỳ tổng quát.

Hơn nữa, sự tổng quát này là về xác suất thực tế, chứ không phải về sở thích của con người.

Lần này, đội ngũ TypeSafe đã đặt "chuẩn hóa xác suất" vào vị trí trung tâm tuyệt đối của mục tiêu đào tạo, họ gọi phương pháp này là RLCD (học tăng cường hướng tới quyết định chuẩn hóa). Trong khi đó, mô hình thưởng theo sở thích truyền thống (RLHF) tìm kiếm xác suất của sở thích con người, chứ không phải xác suất của các sự kiện trong thế giới thực.

Thứ hai, là sự khai thác tối đa khả năng tính toán song song trong kiến trúc.

Jev đã thay đổi cách thông tin chảy qua mô hình. Các mô hình điểm trước đây không có nhiều thay đổi trong việc trả lời song song, vì mục tiêu chính là đào tạo mô hình thưởng dày đặc, để chấm điểm cho từng token xuất hiện.

Nhưng lần này, Jev có thể trả lời tối đa 250 câu hỏi cho cùng một tài liệu. Chỉ cần những câu hỏi này không có mối quan hệ phụ thuộc về thứ tự, chúng có thể được thực hiện hàng loạt một cách song song.

Tất cả những điều này được thực hiện như thế nào?

Mặc dù Jev không tiết lộ cụ thể kiến trúc của nó, nhưng dựa trên hiệu suất thực tế và nhiều nỗ lực để phục hồi Jev, chúng ta đã có thể mô tả đại khái hình dáng của nó.

02

Từ thử nghiệm và phục hồi, ghép lại hình ảnh nguyên bản của Jev

Trước tiên, chúng ta hãy xem TypeSafe hiện tại đã công bố những gì.

Bên ngoài cái hộp đen, điều đầu tiên mà TypeSafe công bố rõ ràng là giao diện. Bạn có thể cung cấp hai thứ cho giao diện này,

State (trạng thái): Tương đương với một văn bản dài của bài đọc hiểu (chẳng hạn như một đoạn dài về khiếu nại của khách hàng, hoặc nhật ký hệ thống).

Questions (câu hỏi): Đối với văn bản này, bạn có thể đặt nhiều câu hỏi cùng lúc. Các câu hỏi không ảnh hưởng đến nhau. Hệ thống nhận được những câu trả lời độc lập này, sau đó người viết mã (bạn) sẽ quyết định logic công việc tiếp theo sẽ đi như thế nào.

Để chuẩn hóa câu hỏi, TypeSafe đã thu hẹp cách đặt câu hỏi thành ba nguyên lý (Primitives). Bao gồm:

Noul (câu hỏi đúng sai): Hỏi "Có không", trả về một xác suất giữa 0~1 (chẳng hạn: việc này có khẩn cấp không? Trả về 0.95).

Choice (câu hỏi lựa chọn): Hỏi "Chọn cái nào", đưa ra một số lựa chọn, trả về phân phối xác suất của chúng (chẳng hạn: chuyển cho bộ phận kỹ thuật 0.8, chuyển cho bộ phận tài chính 0.2).

Score (câu hỏi chấm điểm): Hỏi "Mức độ", trả về xác suất của các cấp độ khác nhau và điểm số tổng hợp cuối cùng (chẳng hạn: chỉ số tức giận của khách hàng 4.5 điểm).

Nếu mục tiêu là để chương trình thực hiện các phán đoán phổ biến, ba nguyên lý này đã bao phủ một phần lớn các hình thức đầu ra, gần như tất cả các phán đoán đều có thể chuyển đổi thành ba loại câu hỏi này.

Cuối cùng, chương trình nhận được số liệu, rồi theo quy tắc của mình thực hiện hành động.

Chính thức cam kết, Jev chỉ đọc State một lần. Sau đó, tất cả các câu hỏi sẽ được thực hiện trong cùng một yêu cầu, nhằm thực hiện phán đoán song song và độc lập cho trạng thái này.

Sự độc lập có nghĩa là các câu hỏi không thể tham khảo lẫn nhau. Nếu câu hỏi thứ hai của bạn phải phụ thuộc vào kết quả của câu hỏi thứ nhất, bạn chỉ có thể gửi yêu cầu hai lần.

Do đó, TypeSafe khuyến khích một cách sử dụng gọi là "Speculative fan-out (song song suy đoán)": chẳng hạn như xử lý một khiếu nại của khách hàng, ngay cả khi cuối cùng phát hiện ra đây không phải là lỗi của hệ thống, chương trình cũng có thể ngay từ đầu hỏi "Có phải lỗi không?", "Lỗi nghiêm trọng đến mức nào?", "Nên chuyển cho ai?". Hệ thống sẽ tính toán song song tất cả các câu trả lời một lần, sau đó mã logic hạ nguồn sẽ loại bỏ những kết quả không cần thiết.

Hiện tại, đây là tất cả thông tin chính mà chúng ta biết được từ các công bố chính thức.

Sau khi Jev thu hút sự chú ý, Archer Hume đã tiến hành một loạt thử nghiệm hộp đen, từ đó chúng ta có thể thu được nhiều cái nhìn về cách Jev xử lý văn bản trạng thái. Đồng thời, các dự án phục hồi mã nguồn mở như Kev, NanoJev, minojev cũng xuất hiện như nấm sau mưa.

Bằng cách so sánh phản hồi thử nghiệm của các dự án phục hồi nào gần giống với Jev thật nhất, chúng ta có thể giả định ngược lại về kiến trúc nội bộ thực sự của chúng.

Mặc dù không thể nói rằng những phục hồi này 100% tái hiện được bản chất của Jev, nhưng giữa những khoảng trống lớn còn lại trong tài liệu giao diện chính thức, chẳng hạn như văn bản gốc chia sẻ trạng thái như thế nào? Các lựa chọn ứng viên thông thường hình thành biểu diễn đặc trưng ra sao? Chúng ảnh hưởng đến nhau ở bước nào?

Chúng ta cũng có thể nhìn thấy hình dáng đại khái thông qua ống kính này.

Tiếp theo, chúng ta sẽ sử dụng một yêu cầu cụ thể, đi qua quy trình "tiêu hóa nội bộ" của mô hình lớn này.

Đầu tiên, chúng ta cần làm rõ cấu trúc thông tin mà Jev thực sự xử lý. Một quy trình hoàn chỉnh bao gồm ba phần: State (trạng thái) như một bối cảnh chung (ví dụ như văn bản khiếu nại dài), một số Questions (câu hỏi) được đưa ra độc lập, và các Options (lựa chọn) tương ứng với từng câu hỏi.

Điểm đầu tiên: xử lý thông tin chung

Nếu mỗi câu hỏi đều phải đọc lại hàng chục nghìn từ của khiếu nại từ đầu đến cuối, càng nhiều câu hỏi, sức mạnh tính toán lặp lại vô ích càng nhiều.

Vì vậy, cách tốt nhất là tất cả các câu hỏi chỉ cần đọc một lần và có thể sử dụng cho tất cả.

Để xác minh xem Jev có thực sự làm được "chỉ đọc một lần" hay không, nhà nghiên cứu Archer Hume đã tham khảo hóa đơn tính phí API và dữ liệu độ trễ: khi gửi một câu hỏi đúng sai đơn giản nhất, hóa đơn hiển thị là 268 token đầu vào; khi tăng lên hai câu hỏi, nó trở thành 276 token. Sự gia tăng chỉ là chi phí từ số từ của câu hỏi mới, hệ thống không tính phí cho tài liệu State chung.

Trong khi số lượng câu hỏi tăng lên gần trăm, thời gian phản hồi của máy chủ gần như là một đường thẳng ngang.

Mặc dù quy tắc tính phí thương mại và việc chạy hàng loạt đã che giấu hồ sơ tính toán thực sự của card đồ họa, nhưng điều này rất phù hợp với tuyên bố chính thức rằng "tài liệu chung chỉ đọc một lần, các câu hỏi tính toán hàng loạt".

Đối với kiến trúc thông tin này, dự án mã nguồn mở Kev hiện đang là sự phục hồi rõ ràng nhất.

Kev trước tiên xử lý trạng thái một lần, đóng băng kết quả trung gian tính toán trong Kv Cache. Tiếp theo, 50 câu hỏi này chia sẻ bộ Kv Cache này để tính toán, như vậy không cần phải đọc từng câu hỏi một lần nữa.

Điểm dừng thứ hai: Phân tách câu hỏi

Nhưng một vấn đề quan trọng khác là, những câu hỏi tính toán hàng loạt này, có thực sự không liên quan đến nhau như những gì chính thức nói không?

Archer Hume đã thiết kế một "thí nghiệm mật mã" khéo léo cho điều này. Anh đã nhét vào câu hỏi A một câu "mật mã là ZEBRA-7741", sau đó trong các tùy chọn của câu hỏi B, yêu cầu mô hình chọn "mật mã được đề cập trong câu hỏi khác". Kết quả cho thấy, xác suất Jev đưa ra mật mã đúng là 0.00. Nhưng nếu đưa mật mã này ra khỏi câu hỏi A và đặt vào văn bản State chung, xác suất câu hỏi B đưa ra câu trả lời đúng ngay lập tức tăng vọt lên trên 0.90.

Điều này tạo thành bằng chứng mạnh mẽ về việc giữa các câu hỏi có sự tách biệt vật lý nghiêm ngặt: tài liệu chung có thể nhìn thấy bởi tất cả các câu hỏi, nhưng các câu hỏi liền kề hoàn toàn không thể "nhìn trộm" lẫn nhau.

Để đảm bảo các câu hỏi có thể tách biệt, Kev đã sử dụng hai bộ phương pháp.

Bộ giải pháp đầu tiên là mặt nạ chú ý, với nó, khi hệ thống đưa [nội dung khiếu nại đã đóng băng] + [câu hỏi 1] + [câu hỏi 2] vào cùng một phép tính, chỉ cần mô hình đang xử lý câu hỏi 1, cơ chế mặt nạ sẽ buộc khu vực của câu hỏi 2 trở thành trạng thái có giá trị 0, buộc nó chỉ "chú ý" đến nội dung khiếu nại chung và chính nó khi trả lời.

Bộ giải pháp thứ hai là tái sử dụng nhánh độc lập, khi có nền tảng có đặc điểm vòng lặp hoặc kiến trúc cụ thể (như Qwen3.5 được đề cập trong bài viết), mặt nạ chú ý không thể tách rời. Vì vậy, khi sử dụng những mô hình này, khi mô hình đọc xong nội dung khiếu nại, nó sẽ lấy ký ức đã đóng băng này làm điểm khởi đầu, trực tiếp phân tách ra 50 con đường cao tốc song song (nhánh độc lập).

Bởi vì mỗi con đường phân nhánh đều hoàn hảo kế thừa ký ức khiếu nại đã được xử lý trên đường chính, chúng cũng tận hưởng lợi ích không cần đọc lại nội dung gốc.

Điểm dừng thứ ba: Tính toán tùy chọn

Bây giờ, trạng thái đã được công khai, các câu hỏi cũng đã được tách ra, vậy trong một câu hỏi lựa chọn đã được tách ra, mô hình thực sự tính toán và xử lý những tùy chọn đó như thế nào?

Lúc này, mô hình trước mặt có một vài tùy chọn, chẳng hạn như "tài chính", "kỹ thuật". Cách làm truyền thống nhất là đầu tuyến tính (Linear Head) cộng với Softmax. Đây chính là mô hình mà phiên bản Zefan Open-Jev đã cố gắng tái hiện khi thử nghiệm Jev.

Bạn có thể hoàn toàn coi nó như một "thẩm định mù trong phòng tối" tuyệt đối. Thí sinh "tài chính" vào phòng tối biểu diễn, bạn dựa vào một hướng dẫn chấm điểm cứng nhắc (đây chính là chức năng của đầu tuyến tính), đã cho anh ta 80 điểm tuyệt đối, sau đó "kỹ thuật" vào phòng tối, bạn cho 90 điểm. Hai người này hoàn toàn không gặp nhau, bạn cũng không bao giờ so sánh họ. Cuối cùng, bạn sử dụng công thức toán học Softmax chuyên tính tỷ lệ phần trăm, chuyển đổi 80 và 90 này thành tỷ lệ thắng.

Trong quy trình giả định này, nếu chúng ta nhét vào một tùy chọn gây rối hoàn toàn không có logic, chẳng hạn như "thời tiết xấu", nó tối đa chỉ đóng vai trò như một vật hy sinh trong mẫu số, khiến tỷ lệ phần trăm mà mọi người nhận được giảm đi một chút. Nhưng vì bạn đã ghi chết 80 điểm cho tài chính và 90 điểm cho kỹ thuật trên giấy, "tỷ lệ tương đối" giữa họ tuyệt đối không thể bị ảnh hưởng bởi sự tham gia của một vật hy sinh.

Nhưng thử nghiệm của Archer Hume đã chứng minh rằng, tùy chọn mới thực sự sẽ ảnh hưởng đến sự chênh lệch điểm số của mô hình. Anh đã nhét một tùy chọn gây rối "thời tiết xấu" vào một nhóm tùy chọn bình thường, và trong mười nhóm thử nghiệm sắp xếp ngẫu nhiên, phát hiện rằng điều này thực sự đã thay đổi tỷ lệ tương đối giữa tài chính và kỹ thuật. Điều này trực tiếp tuyên án tử hình cho mô hình "thẩm định mù trong phòng tối".

Vì không phải là thẩm định mù, điều này có nghĩa là các thí sinh chắc chắn đã "nhìn thấy nhau" và tạo ra phản ứng hóa học trước khi giám khảo đưa ra điểm số cuối cùng. Cộng đồng mã nguồn mở đã đưa ra hai loại sơ đồ để thực hiện phản ứng hóa học này.

Sơ đồ đầu tiên là mô hình "đầu con trỏ (Pointer Head)" do dự án Kev thiết kế. Bạn có thể tưởng tượng nó như một "cuộc phỏng vấn nhóm". Mô hình không còn nhốt thí sinh trong phòng tối nữa, mà xếp "tài chính, kỹ thuật, thời tiết xấu" thành một hàng, để giám khảo có thể nhìn thấy tất cả cùng một lúc.

Khi giám khảo nhìn thấy thí sinh đứng ở cuối hàng, trong đầu họ đã hình thành một "bối cảnh tổng thể" về cuộc phỏng vấn này. Sau đó, giám khảo đứng ở vị trí cuối cùng, giống như dùng tay chỉ, lần lượt chỉ về các thí sinh trước đó, dựa trên ấn tượng tổng thể hiện tại để chấm điểm, hành động này được gọi là đầu con trỏ. Khi giám khảo nhìn xong tất cả mọi người rồi quay lại chỉ trỏ, tâm lý và hệ quy chiếu đã thay đổi, điểm số mà họ đưa ra cho tài chính và kỹ thuật tự nhiên cũng sẽ thay đổi theo.

Sơ đồ thứ hai là "thảo luận nội bộ của giám khảo", là mô hình "mô-đun chú ý giữa các ứng viên (Inter-candidate Attention Module)" do các dự án như NanoJev thiết kế. Lần này, mô hình không phải là thẩm định mù hoàn toàn, cũng không phải là phỏng vấn nhóm hoàn toàn. Nó trước tiên để "tài chính" và "kỹ thuật" lần lượt biểu diễn, làm cho màn trình diễn của họ được cô đọng thành một chuỗi số đánh giá cao chiều dài, thuật ngữ này gọi là vector đặc trưng.

Lúc này, hai thẻ đánh giá vẫn còn tách biệt. Nhưng sau đó, một mô hình nhỏ riêng biệt sẽ ném hai thẻ đánh giá này, cùng với thẻ đánh giá "thời tiết xấu" được nhét vào sau, vào một phòng họp gọi là "mô-đun chú ý".

Trong phòng họp này, các nhóm số đại diện cho thí sinh (vector đặc trưng) sẽ được so sánh và cân nhắc lẫn nhau. Ban đầu tài chính và kỹ thuật rất khó phân biệt, đột nhiên có thêm một thẻ "thời tiết xấu" tham gia thảo luận, toàn bộ trọng tâm thảo luận và trọng số so sánh của ban giám khảo ngay lập tức bị xáo trộn và tái tổ chức.

Sau cuộc họp nội bộ này, điểm số cuối cùng được đưa ra, tự nhiên sẽ không còn giống như lúc chỉ có hai người.

Tại sao Jev lại phải tốn công sức để khiến những tùy chọn này "kéo nhau xuống" trong mã nguồn? Điều này không chỉ đơn thuần là để thể hiện kỹ năng, mà còn vì trong các doanh nghiệp phức tạp thực sự, câu trả lời đúng thường không phải là tuyệt đối, mà là "so sánh" ra. Các tùy chọn bản thân thực sự là manh mối ẩn giấu để giải quyết vấn đề.

Chẳng hạn hỏi tháp Eiffel ở đâu? Các tùy chọn có A. Châu Âu B. Pháp C. Paris. Khi mô hình nhìn thấy cả ba tùy chọn này cùng một lúc, những tùy chọn này bản thân đã trở thành manh mối ẩn giấu để giải mã ý định của câu hỏi này. Câu hỏi này không chỉ kiểm tra vị trí tổng quát, mà còn kiểm tra độ chính xác cao nhất của vị trí địa lý.

Điểm dừng thứ tư: Đưa ra kết quả

Bước cuối cùng của quy trình là giải ra một điểm số cụ thể.

Theo lời của TypeSafe, Jev sẽ trực tiếp trả về số xác suất, tuyệt đối không tạo ra văn bản từng chữ một.

Khám phá bên ngoài của Archer Hume cũng xác nhận điều này, khi anh đưa số tùy chọn từ hai tăng lên hai trăm, văn bản phản hồi mà API trả về mặc dù trở nên rất dài, nhưng thời gian xử lý của máy chủ không kéo dài theo tỷ lệ.

Điều này cho thấy mô hình lớn thực sự đã bỏ qua bước tạo ra tự hồi quy tốn thời gian nhất (cũng giống như ChatGPT dự đoán từ tiếp theo).

Vậy, số xác suất cuối cùng này thực sự "được lấy" từ đâu? Thực tế, việc thực hiện kỹ thuật này có nhiều cách khác nhau, chủ yếu phụ thuộc vào phương pháp mà chúng sử dụng trong bước tính toán tùy chọn trước đó.

Cách làm của openjev/openjev không xử lý tương tác giữa các tùy chọn đặc biệt là trong vị trí "đáp án" mà mô hình đáng lẽ phải tạo ra chữ đầu tiên, trực tiếp đọc điểm số gốc (Logits) của token chữ cái tùy chọn đã chỉ định trong từ điển nội bộ của mô hình lớn.

Kev có đầu con trỏ dựa vào đầu con trỏ có thể xem xét toàn cục để trực tiếp xuất ra điểm so sánh. Còn minojev có mô-đun chấm điểm chia sẻ nhân tạo để đưa ra kết quả.

Dù là cách nào để trích xuất, chỉ cần quy trình được thiết kế hợp lý, mô hình lớn hoàn toàn có thể từ bỏ việc tạo ra văn bản dài dòng, trực tiếp rút ra xác suất toán học chính xác ở cuối phép toán, hoàn thành một quyết định tự động cấp hệ thống.

Đến đây, chúng ta đã có thể rõ ràng dựa trên đánh giá và phục hồi, đưa ra mô hình kiến trúc của Jev.

Kiến trúc này bản thân không phức tạp, cũng khó có phần nào được coi là đổi mới mô hình. Mặc dù thực sự là một tối ưu hóa kỹ thuật xuất sắc cho một tình huống cụ thể, nhưng cũng chỉ có vậy mà thôi.

03

Đảm bảo độ chính xác là huấn luyện sau

Kiến trúc chỉ đảm bảo tốc độ, vậy Jev đạt được độ chính xác cao như thế nào?

Đó chính là nhờ vào phương pháp huấn luyện sau mà TypeSafe gọi là RLCD (tăng cường học tập quyết định hiệu chỉnh). Vì RLCD là một hộp đen không công khai, chúng ta chỉ có thể xem xét những nỗ lực từ cộng đồng mã nguồn mở để tìm hiểu về các câu hỏi và phương pháp thuật toán tiềm năng của nó.

Sự ra đời của một câu hỏi dùng để huấn luyện RLCD

Cách đơn giản nhất là tổng hợp trực tiếp, chẳng hạn như cách mà phiên bản Hmm đã tái hiện.

Các nhà nghiên cứu đã yêu cầu DeepSeek V4.1 liệt kê hơn một trăm tình huống làm việc trong mã, bao gồm xử lý hoàn tiền, kiểm tra sự cố, tìm kiếm liên quan, phân luồng email, v.v.

Mỗi lần chọn một tình huống, sau đó kết hợp với hình thức tài liệu và yêu cầu đặt câu hỏi. Chẳng hạn như

Sử dụng một đoạn tin nhắn dài có chi tiết không liên quan, viết một vài trường hợp hoàn tiền

Thêm một trường hợp dễ bị nhầm lẫn bởi từ khóa

Mỗi trường hợp kèm theo bốn đến năm câu hỏi lựa chọn, đúng sai hoặc cấp độ

DeepSeek V4.1 Flash sau đó tạo ra toàn bộ tài liệu, câu hỏi, tùy chọn, tiêu chí đánh giá và câu trả lời.

Sau đó, việc kiểm tra xem câu hỏi này có thể sử dụng được hay không phụ thuộc vào việc ẩn câu trả lời gốc, yêu cầu DeepSeek V4.1 Flash trả lời lại, mặc định gọi ba lần, yêu cầu mỗi lần đưa ra xác suất tùy chọn. Mã cho phép các câu hỏi có ít nhất hai phản hồi hợp lệ mới có thể sử dụng.

Phương pháp của Kev là thống nhất các bộ dữ liệu hiện có như phân loại tin tức, cảm xúc bình luận, nội dung văn bản theo quy tắc thành định dạng phán đoán "Tài liệu + Vấn đề + Câu trả lời ứng cử viên".

Mô hình sau đó sẽ tạo ra quy tắc và sự thật, tính toán câu trả lời, và viết chúng thành văn bản.

Vào ngày 24 tháng 9, Kev-4B còn thử nghiệm xây dựng câu hỏi bằng cách sử dụng môi trường làm việc thực tế. Họ đã thu thập 5,219 đơn khiếu nại tài chính của người tiêu dùng thực tế, và tạo ra câu hỏi xoay quanh "sản phẩm liên quan là gì, vấn đề chính là gì". Sau khi câu hỏi được đưa ra, chỉ khi hai mô hình giáo viên khác nhau đều có phán đoán nhất quán với nhãn báo cáo ban đầu của người tiêu dùng thì nhãn mới được giữ lại.

Để làm cho việc đào tạo này hiệu quả hơn, các bài kiểm tra phục hồi còn đặc biệt đưa ra một số câu hỏi bẫy theo cặp.

Ví dụ, hai câu hỏi có quy tắc hoàn toàn giống nhau, chỉ thay đổi một cái tên quan trọng (chẳng hạn như người ký từ Mira có quyền thành Noah không có quyền), câu trả lời sẽ đảo ngược ngay lập tức. Những câu hỏi như vậy có thể hiệu quả ngăn chặn mô hình học thuộc lòng câu trả lời thông qua Reward Hacking, buộc nó phải trung thực làm việc để ghi nhớ sự biểu hiện và mối liên hệ sâu sắc giữa câu hỏi và các tùy chọn câu trả lời.

Phương pháp đào tạo, chỉ cần LoRA cộng với chưng cất là đủ sao?

Hiện tại, hầu hết tất cả các phương pháp đào tạo đã qua sử dụng đều sử dụng phương pháp "LoRA + chưng cất giáo viên" để tăng xác suất lựa chọn đúng.

Lấy Winnow làm ví dụ, nó chọn thực hiện tinh chỉnh LoRA trên mô hình chỉ thị Gemma 4 12B. Chức năng của LoRA là giữ lại trọng số gốc, đào tạo một phần nhỏ tham gia vào việc tính toán các tham số điều chỉnh, giảm chi phí sửa đổi mô hình.

Winnow đồng thời sử dụng hai loại giám sát. Một loại đưa ra câu trả lời tiêu chuẩn, yêu cầu mô hình tăng xác suất của lựa chọn đúng. Loại còn lại cung cấp phân phối xác suất cho tất cả các tùy chọn từ giáo viên, để học sinh gần gũi với phân phối này. Chỉ khi vị trí đầu tiên do giáo viên chọn nhất quán với câu trả lời tiêu chuẩn, Winnow mới áp dụng giám sát thứ hai.

Cả hai đều tính toán sai số đào tạo thông qua entropy chéo. Entropy chéo ở đây đảm nhận công việc kiểm tra học sinh đã phân phối xác suất sai bao nhiêu. Chỉ khi có câu trả lời tiêu chuẩn, xác suất của lựa chọn đúng càng thấp thì hình phạt càng lớn.

Khi sử dụng phân phối giáo viên, việc đào tạo sẽ thúc đẩy học sinh bắt chước phân phối của giáo viên đối với các tùy chọn. Ví dụ, giáo viên phân phối 80%, 15%, 5% cho A, B, C, học sinh sẽ được yêu cầu học sự khác biệt giữa ba tùy chọn này.

Nói chung, LoRA, chưng cất và entropy chéo đã đủ cho các nhiệm vụ đã chuẩn bị sẵn câu hỏi, câu trả lời và phân phối tham khảo (chẳng hạn như nhiệm vụ dự đoán xác suất này), vì chúng chỉ học một xác suất.

Nhưng chưng cất thực sự học xác suất của giáo viên, chứ không phải xác suất thực tế như RCLD đã nói. Cách mà khoảng cách chưng cất vượt qua thực tế / tỷ lệ của giáo viên, hiện tại không có ý tưởng rõ ràng nào về việc tái hiện.

Về lý thuyết, để thực hiện tuyên bố của Jev, chỉ có thể dựa vào khối lượng dữ liệu lớn hơn và phương pháp học tập hiệu quả hơn về mẫu.

Tất nhiên, nếu một mô hình phán đoán nhỏ như vậy có thể đạt được độ chính xác phán đoán của mô hình lớn, thì nó cũng rất hữu ích ngay cả khi chưa giải quyết được vấn đề này.

Hiệu chỉnh, có thể vẫn là tuyệt chiêu

Ngoài ra, Jev còn có một tuyệt chiêu, đó là khả năng hiệu chỉnh mà nó tuyên bố.

Số lượng câu hỏi mà mô hình trả lời đúng, và việc nó có chính xác thể hiện sự tự tin hay không, là hai vấn đề khác nhau. Một mô hình có thể chỉ trả lời đúng bảy phần trăm, nhưng lại luôn báo cáo tự tin 90%.

Để xác minh xem Jev có đang tự tin mù quáng hay không, Archer Hume đã thực hiện một "thí nghiệm đo lường nói dối".

Ông đã cho Jev 1200 câu hỏi kiểm tra MMLU (Hiểu ngôn ngữ đa nhiệm quy mô lớn), sau đó phân loại tất cả các câu trả lời được chọn theo xác suất mà hệ thống báo cáo thành mười cấp độ. Qua các phép tính phức tạp, sai số hiệu chỉnh của Jev chỉ là 0.031.

Trong 30 câu nhân ba chữ số đơn giản, Jev trả lời đúng 86.7%, trong khi tự báo cáo mức độ tự tin trung bình là 83%, rất khớp nhau. Khi câu hỏi chuyển thành "câu hỏi ứng dụng hai bước" khó hơn, tỷ lệ chính xác của nó giảm mạnh xuống 32%, điều quan trọng là, mức độ tự tin trung bình mà nó báo cáo cũng giảm xuống 30%.

Về vấn đề này, đào tạo sau thực sự có thể cải thiện hiệu suất xác suất, nhưng nhiều lúc sẽ khiến mô hình trở nên tự tin mù quáng hơn.

Để phục hồi khả năng hiệu chỉnh chính xác của Jev, phiên bản tái hiện đã sử dụng một số phương pháp. Ví dụ, Kev sẽ yêu cầu rõ ràng mô hình giảm độ chắc chắn khi thiếu chứng cứ. Nó đã thêm các mẫu mà chứng cứ quan trọng bị loại bỏ vào tập huấn luyện, sau đó giảm xác suất của chúng trong câu trả lời, do đó mô hình sẽ bị phạt vì tập trung xác suất vào một tùy chọn nào đó mà không có cơ sở.

Tuy nhiên, nhiều tái hiện chỉ thực hiện một loại hiệu chỉnh nhiệt độ không giải quyết tận gốc.

Kỹ sư sẽ đưa ra một nhóm nhỏ các câu hỏi kiểm tra mà mô hình chưa thấy để cho mô hình đã được đào tạo thực hiện. Nếu phát hiện mô hình quá tự tin, hệ thống sẽ thông qua nhóm câu hỏi này, tính toán mức độ tự tin tổng thể cần điều chỉnh lại bao nhiêu.

Khi núm điều chỉnh đã được thiết lập, mô hình sẽ bị buộc phải đeo một bộ lọc khiêm tốn khi xuất ra xác suất, biến thành một xác suất nhẹ nhàng hơn.

Điều này sẽ không thay đổi thứ hạng của các tùy chọn cho cùng một câu hỏi, vì vậy câu trả lời có xác suất cao nhất không thay đổi. Nhưng ngưỡng xác suất và điểm số tính toán theo xác suất có thể thay đổi.

Chiêu này vẫn khá hiệu quả. Ví dụ, sau khi Kev-9B thực hiện hiệu chỉnh nhiệt độ, sai số hiệu chỉnh đã giảm từ khoảng 10.6 điểm phần trăm xuống 4.2 điểm phần trăm, trong khi số lượng câu hỏi trả lời đúng không thay đổi.

Nói rằng nó chỉ giải quyết tạm thời là vì điều này thực sự đến từ việc giảm độ tự tin tổng thể, chứ không phải từ việc phân biệt chính xác hơn liệu mình có nên tự tin hay không.

Giả sử Jev thực sự đã cải thiện hiệu suất hiệu chỉnh, thì có thể họ thực sự có một số kỹ năng đặc biệt ở đây.

04

Ranh giới áp dụng của Jev, thực sự lớn đến mức nào?

Jev chắc chắn có ý nghĩa ứng dụng thực tế. Nó đã phục hồi những nhiệm vụ mà trước đây chỉ cần quyết định nhanh chóng, trở lại với quyết định nhanh chóng bản thân.

Trong toàn bộ quy trình của Agent, việc phân loại yêu cầu và định tuyến, sắp xếp kết quả tìm kiếm, có rất nhiều yêu cầu kiểm tra từng mục rõ ràng. Đây đều là những nơi mà Jev có thể phát huy tác dụng.

Ví dụ, phân luồng dịch vụ khách hàng, phân loại sản phẩm, phân tích phản hồi, gán nhãn dữ liệu, đều là những tình huống phổ biến mà chúng ta gặp trong các nhiệm vụ hàng ngày.

Nhưng ranh giới áp dụng của nó lớn đến mức nào, quyết định xem nó có phải là thứ mà nó tuyên bố có giá trị mẫu mực hay không.

Từ các Benchmark hiện tại, nó thực sự có một mức độ tổng quát nhất định. Nhóm Nimble đã sử dụng 13 nhóm, tổng cộng 3,880 dữ liệu công khai để đo lường kiểm tra sự thật, định tuyến ý định, nội dung hàm ý, kiểm duyệt nội dung, câu hỏi y tế, v.v., Jev có độ chính xác trung bình theo tập dữ liệu là 76.0%.

Điều này cho thấy Jev thực sự có thể đảm nhận nhiều công việc phán đoán khác nhau.

Nhưng thực sự tổng quát còn hai rào cản.

Rào cản đầu tiên là nhiệm vụ khó khăn, nếu chỉ có thể thực hiện phán đoán đơn giản, thì phạm vi áp dụng của nó sẽ rất hạn chế.

Trước tiên, chúng ta cần định nghĩa điều gì là khó khăn trong phán đoán. Thông thường, chúng ta cho rằng, vấn đề càng nhiều bước, điều kiện càng nhiều, yêu cầu hiểu chi tiết càng tỉ mỉ thì càng khó khăn.

Nhận diện "người dùng muốn hoàn tiền" chỉ cần hiểu nghĩa đen, nhưng phán đoán "liệu khoản hoàn tiền này có nên được phê duyệt hay không" lại cần kiểm tra ngày tháng, tính toán thời hạn, so sánh quyền ưu tiên của các điều khoản, rõ ràng khó hơn. Và nếu một phán đoán cần suy luận ba bước để đến kết quả, thì bước thứ ba cần kết quả của bước thứ hai, đây là sự phụ thuộc nhiều bước. Nếu tìm sai chính sách ở bước đầu tiên, các phép tính sau đó dù hoàn toàn chính xác, cuối cùng cũng sẽ phán đoán sai.

Trong bài kiểm tra câu hỏi khó của JevBench, JevBench đã quy định một số yếu tố liên quan đến độ khó của câu hỏi phán đoán, bao gồm phán đoán nhiều điều kiện, tìm kiếm chứng cứ liên tục, so sánh ngày tháng và số ba tùy chọn. Trong nhóm câu hỏi này, tỷ lệ chính xác của Jev trong việc tìm kiếm nhiều bước là 85.7%, phán đoán chính sách dài là 60.5%, phán đoán thời gian và số chỉ đạt 26.7%, đều kém xa so với mô hình cấp Flash. Tổng cộng các câu hỏi khó, Jev trả lời đúng 74.1%, DeepSeek V4.1 Flash là 95.0%, gần tương đương với trình độ của các chuyên gia con người.

Mặc dù thời gian trung bình yêu cầu cho các bài kiểm tra tương ứng khoảng 0.67 giây và 3.15 giây, tốc độ của Jev nhanh gần bốn lần. Nhưng sự chênh lệch độ chính xác lớn như vậy, đối với một số phán đoán phải đối mặt với nhiệm vụ phức tạp (chẳng hạn như việc đầu tư chứng khoán mà mọi người đều mong muốn) thì việc lựa chọn gì gần như không cần phải bàn cãi.

Hơn nữa, độ chính xác tìm kiếm nhiều bước ở đây thực sự không phải là suy luận nhiều bước, mà chủ yếu liên quan đến việc tìm kiếm. Trong bài kiểm tra của Archer Hume, Jev có tỷ lệ chính xác lên tới 86.7% trong phép nhân đơn giản, nhưng khi chuyển sang câu hỏi ứng dụng hai bước, tỷ lệ chính xác của nó ngay lập tức giảm xuống 32%.

Briantrust đã thực hiện một đánh giá chi tiết hơn, cũng có thể thấy Jev gặp khó khăn trong các vấn đề khó khăn. Nó đã so sánh Jev và mô hình GPT 5.6 Luna, yêu cầu mô hình chọn ra một trong hai câu trả lời ứng cử viên đúng, cuối cùng so sánh 616 câu hỏi hợp lệ. Hai mô hình chỉ có sự chênh lệch 1.6 điểm phần trăm trong các câu hỏi kiến thức, nhưng trong toán học và suy luận đã mở rộng lên 19.3 điểm phần trăm, và trong mã đạt 20 điểm phần trăm.

Do đó, rào cản phán đoán khó khăn này, Jev rất khó để nói rằng mình đã vượt qua.

Rào cản thứ hai là khả năng tổng quát.

Nếu Jev thực sự có thể tổng quát, nó nên có khả năng tổng quát tốt hơn, nâng cao độ chính xác của phán đoán các vấn đề khác từ những gì nó đã học.

Nếu không, nó chỉ là một "mô hình phán đoán chuyên dụng" có phạm vi áp dụng rộng hơn một chút, không tạo ra sự khác biệt gì so với các mô hình phán đoán trước đó.

Các bằng chứng trực tiếp từ nhiều bài kiểm tra hiện có có thể chứng minh rằng Jev thực sự có một khả năng tổng quát nhất định, nhưng khả năng này trong lĩnh vực rất không ổn định. Và một khi bước ra khỏi bối cảnh quen thuộc, hiệu suất của nó vẫn phải đối mặt với rủi ro lớn.

Đầu tiên, dưới cùng một nhiệm vụ và sự thật hoàn toàn giống nhau, phán đoán của Jev rất dễ bị ảnh hưởng bởi cách trình bày thông tin. Trong thí nghiệm OpenProse, mà không thay đổi bất kỳ sự thật, câu hỏi và khối lượng tính toán nào, khi mối quan hệ quan trọng được tập trung ở vị trí đầu của văn bản, tỷ lệ chính xác của Jev là 80.5%, nhưng khi những mối quan hệ này được chuyển đến giữa, tỷ lệ chính xác giảm ngay lập tức xuống 40.9%.

Điều này cho thấy, ngay cả khi không thay đổi lĩnh vực kinh doanh, tính ổn định của Jev cũng rất thiếu. Khả năng phán đoán của nó phụ thuộc cao vào cách mà các chương trình bên ngoài cung cấp dữ liệu cho nó.

Thứ hai, khi đối mặt với các câu hỏi mới trong cùng một hệ thống đánh giá, hiệu suất của Jev cũng có sự biến động rõ rệt. Trong phiên bản mới v1.4 của JevBench, 308 câu hỏi khó đã được thêm vào, tỷ lệ chính xác của Jev giảm từ 86.6% trong các câu hỏi công khai xuống còn 36.7%, trong khi đó, DeepSeek V4.1 Flash sử dụng phương pháp suy nghĩ vẫn duy trì ở mức 94.8%.

Những điểm số cao mà Jev đạt được trong các câu hỏi công khai trước đây không thể tự động duy trì trong các bài kiểm tra phức tạp chưa biết.

Khi thử nghiệm được đẩy mạnh vào việc chuyển giao kinh doanh thực tế, hiệu suất của Jev cũng có những điểm tích cực và tiêu cực. Ví dụ tích cực đến từ việc phát hiện tiêm ngừa của Agent Journal, Jev có độ chính xác 83.65% trên tập dữ liệu thử nghiệm ban đầu, khi chuyển trực tiếp sang một tập thử nghiệm khác chứa hơn hai ngàn dữ liệu bên ngoài, độ chính xác thậm chí đã tăng lên 95.58%, vượt xa mô hình cơ sở truyền thống.

Điều này cho thấy trong một số nhiệm vụ cụ thể, nó thực sự có thể thích ứng với sự thay đổi nguồn dữ liệu.

Nhưng trong các doanh nghiệp có logic phức tạp hơn, sự tổng quát này thường sẽ thất bại. Scarif Labs đã sử dụng nó để xác định xem cập nhật phần mềm có an toàn hay không. Khi chuyển mô hình từ một hệ sinh thái phần mềm sang một hệ sinh thái khác, khả năng phân biệt giữa cập nhật an toàn và nguy hiểm của Jev (AUROC) đã giảm từ 0.851 xuống 0.605 (gần với việc đoán ngẫu nhiên là 0.5).

Vì vậy, chúng ta ít nhất có thể nói rằng, hiện tại sự tổng quát của Jev có vẻ khá hạn chế và đáng nghi ngờ. Nó còn xa mới đạt tiêu chuẩn tổng quát chung.

Vì Jev chưa vượt qua được hai rào cản chung này, chúng ta nên sử dụng nó ở đâu?

Vị trí phù hợp hơn là đặt Jev vào các khâu có tiêu chuẩn rõ ràng, bằng chứng tập trung, và kết quả phán đoán có thể được kiểm tra hoặc sửa chữa.

Vẫn lấy ví dụ về hoàn tiền. Việc xác định xem người dùng có bày tỏ ý định hoàn tiền hay không, khiếu nại liên quan đến logistics hay chất lượng hàng hóa, có cần bổ sung chứng từ hay không, đều là những phán đoán ngữ nghĩa có thể xác minh riêng. Những câu hỏi này xuất hiện thường xuyên, thường không cần tạo ra một đoạn giải thích, và không cần mỗi lần đều để mô hình chính thực hiện suy luận. Jev có thể đảm nhận việc phân luồng ban đầu ở đây.

Nhưng để phê duyệt hoàn tiền, mọi thứ đã thay đổi. Có vượt quá thời hạn hay không, cần kiểm tra mã ngày tháng, số tiền hoàn, cần tính toán theo quy tắc, gặp phải xung đột điều khoản hoặc tình huống ngoại lệ, còn cần xem xét thêm. TypeSafe cũng đã đề xuất rằng, nên giao các phép toán và so sánh ngày tháng cho mã, và cố gắng giảm thiểu sự phụ thuộc nhiều lớp trong phán đoán.

Cách phân công như vậy mới có thể tận dụng tốc độ của nó ở vị trí phù hợp.

Còn đối với những ứng dụng phụ thuộc nhiều vào độ chính xác, chẳng hạn như mô hình thưởng, điều cần xác định thường chính là những câu trả lời có vẻ hợp lý nhưng thực tế lại sai. Mô hình còn cần phân biệt những khác biệt tinh tế, chống lại sự can thiệp của phong cách diễn đạt.

Còn đối với những nhiệm vụ mà quy định khó khăn, chẳng hạn như các quy tắc chứa đánh giá chủ quan, ít nhất cần thử nghiệm độ chính xác của Jev trước khi triển khai.

Lúc này, Jev có thể là một phương án ứng cử, nhưng người sử dụng vẫn cần đánh giá chuyên biệt cho nhiệm vụ.

Ngoài ra, còn một điều không thể bỏ qua. Jev phản hồi nhanh không có nghĩa là khi thêm nó vào, toàn bộ Agent sẽ nhanh hơn.

Nếu nó có thể xử lý trước một loạt yêu cầu đơn giản, khiến những yêu cầu này không còn gọi đến mô hình chính, thì lợi thế về tốc độ và chi phí có cơ hội được hiện thực hóa.

Nhưng nếu mỗi lần đều gọi Jev trước, sau đó vẫn phải gọi cùng một mô hình chính, thì những phán đoán mới phải tiết kiệm đủ nhiều công việc tiếp theo để bù đắp cho thời gian và chi phí của nó.

Trong một loạt thí nghiệm truy xuất trí nhớ Agent trên GitHub, hệ thống đã đưa Jev vào để xác định xem thông tin được truy xuất có hữu ích hay không. Để tránh Jev vô tình loại bỏ thông tin hữu ích, các nhà phát triển đã phải điều chỉnh tiêu chuẩn phán đoán nhiều lần.

Mặc dù cuối cùng đã cho phép 20 trường hợp thông thường thông qua, nhưng cái giá phải trả rõ ràng, độ trễ tổng thể của hệ thống đã từ 649 mili giây tăng lên 1087 mili giây, chi phí cho mỗi nghìn lần gọi cũng đã tăng gấp đôi.

Nếu mô hình chính đã có khả năng lọc câu trả lời từ tài liệu phức tạp, thì việc thêm một Jev như một bộ phận phán đoán không chỉ làm tăng thêm thời gian chờ đợi, mà còn mang theo rủi ro vì phán đoán sai mà bỏ lỡ bằng chứng quan trọng.

05

Sự đột phá của Jev thực sự là bao nhiêu?

Cuối cùng, câu hỏi cốt lõi mà Jev để lại cho chúng ta là, nó thực sự đang học gì?

Lẽ ra, một mô hình dùng để phán đoán, biểu diễn mà nó học được chính là thông qua các sự kiện mới để đưa ra phán đoán hiệu quả.

Đây gần như là một trong những biểu diễn khó khăn nhất.

Phán đoán tổng quát cần phải gọi đồng thời nhiều khả năng, không thể chỉ vì cuối cùng chỉ xuất ra một xác suất mà cho rằng nó dễ hơn việc tạo ra câu trả lời.

Lấy ví dụ về hoàn tiền. Khi thấy "Tôi muốn hoàn tiền", việc nhận diện ý định hoàn tiền chủ yếu phụ thuộc vào hiểu ngôn ngữ. Nhưng khi hỏi "Theo chính sách này, có nên phê duyệt hoàn tiền không", mô hình phải hiểu chính sách, đối chiếu ngày mua, trạng thái hàng hóa với các điều khoản cụ thể, rồi xử lý các ngoại lệ.

Điều này cơ bản là nền tảng khả năng của mô hình ngôn ngữ đứng sau Jev.

Câu hỏi cuối cùng "Việc hoàn tiền có giúp giữ chân khách hàng này không", cần phải dự đoán hậu quả hành động. Đây mới là phần mà mô hình cần được đào tạo.

Nó cần học những sự kiện nào ảnh hưởng đến kết quả, trong điều kiện nào ảnh hưởng, và liệu những mối quan hệ này có còn tồn tại khi chuyển sang một bối cảnh khác hay không.

Cả ba câu hỏi đều có thể xuất ra "xác suất có", nhưng kiến thức và tính toán cần thiết thì khác nhau.

Để vượt qua khoảng cách từ "dự đoán người khác sẽ phán đoán" đến "dự đoán đáng tin cậy hậu quả hành động", chúng ta thực sự cần bao nhiêu dữ liệu và đào tạo?

Ít nhất đối với con người, phán đoán tổng hợp là điều khó học nhất. Nó phức tạp như những gì chúng ta đã đề cập trong bài viết trước về gu thẩm mỹ và tính toán lợi ích tổng hợp.

Vì vậy, tôi rất nghi ngờ liệu phương pháp học mà bài viết này hiện đang tiết lộ có thể chịu đựng được những biểu diễn phức tạp như vậy hay không.

Tất nhiên, chúng ta có thể xem Jev như một công cụ kỹ thuật rất tinh tế.

Trong các quy trình kinh doanh có quy tắc rõ ràng và tài liệu đầy đủ, nó có thể giảm đáng kể thời gian chờ đợi và chi phí tính toán, giá trị là không thể phủ nhận.

Nhưng trước khi chứng minh rằng nó thực sự đã học được một số quy tắc phán đoán tổng quát, việc để nó đội vương miện "cải cách mô hình" vẫn còn quá sớm.