Jev và Lớp Quyết Định Mới cho Các Đại Lý AI

Tại sao các mô hình System One có thể tách biệt phán đoán nhanh khỏi suy luận chậm

Nhiều đại lý AI sử dụng mô hình ngôn ngữ cho hầu hết các quyết định của chúng. Mô hình ngôn ngữ chọn một công cụ, đánh giá kết quả, xác định xem có cần tiếp tục hay không, và cuối cùng tạo ra câu trả lời. Linh hoạt; tuy nhiên, quy trình này có thể tốn kém khi các quyết định có/không được lặp lại ở quy mô lớn. Unite.AI đã từng thảo luận về cách các quy trình làm việc dạng đại lý làm tăng số lần gọi mô hình, ngữ cảnh và lần thử lại. Mỗi quyết định bổ sung có thể làm tăng thời gian và chi phí trước khi cung cấp thông tin hữu ích cho người dùng.

Jev đề xuất chia nhiệm vụ theo cách khác. Sử dụng một mô hình được xây dựng cho các phán đoán có giới hạn, trong đó tập hợp câu trả lời được xác định. Sử dụng một mô hình sinh để thực hiện suy luận mở và ngôn ngữ. Jev cho rằng ý chính ở đây không phải là mọi đại lý đều cần mua một sản phẩm mới. Khái niệm then chốt là một đại lý không cần cùng một loại trí tuệ ở mọi thời điểm.

Những gì Jev Thực Sự Làm

TypeSafe đã ra mắt Jev vào tháng 9 năm 2026, là mô hình System One mới đầu tiên của họ. Jev không viết ra văn bản. Thay vào đó, bạn gửi cho nó một trạng thái (như tin nhắn hỗ trợ và dữ liệu người dùng). Bạn cũng gửi một hoặc nhiều câu hỏi có các loại câu trả lời được định trước. Sau đó Jev phản hồi bằng các câu trả lời có kiểu và xác suất.

Theo tài liệu chính thức của công ty, có ba khái niệm cơ bản để đưa ra các phán đoán:

• Choice cho phép bạn chọn từ các tùy chọn đã định sẵn.
• Score cho phép bạn đánh giá một thứ gì đó dựa trên một thang điểm có thứ tự.
• Noul ước tính xác suất một phát biểu là đúng.

Bạn có thể đặt nhiều câu hỏi độc lập về cùng một trạng thái trong một yêu cầu.

Ví dụ, giả sử bạn đang xử lý một vấn đề dịch vụ khách hàng. Hệ thống có thể muốn xác định đội nào nên xử lý trường hợp này. Nó cũng có thể xác định thời gian phản hồi cần thiết và xem liệu khách hàng có yêu cầu hoàn tiền hay không.

Một mô hình trò chuyện có thể thực hiện cả ba nhiệm vụ. Tuy nhiên, nó sẽ cần trả lại kết quả cho ứng dụng của bạn dưới dạng phản hồi có cấu trúc. Ngược lại, Jev chỉ cung cấp những quyết định có giới hạn đó. Ứng dụng của bạn sau đó sẽ quyết định hành động tiếp theo dựa trên các quyết định đó.

Sự Thay Đổi Kiến Trúc Quan Trọng Hơn Mô Hình

Phần lớn các tranh luận này so sánh mô hình lớn với mô hình nhỏ. Jev đề xuất một ranh giới thay thế. Một số bước liên quan đến việc sinh ngôn ngữ. Các bước khác là các phán đoán hẹp mà phần mềm có thể tiêu thụ.

Điều này tạo ra một lớp quyết định trong đại lý. Mô hình sẽ ước tính. Phần mềm sẽ áp dụng chính sách. Nếu xác suất ước tính vượt qua ngưỡng đã kiểm nghiệm và hành động có rủi ro thấp và có thể đảo ngược, quy trình làm việc có thể tiếp tục. Nếu có sự không chắc chắn trong kết quả hoặc nếu hành động có thể gây hậu quả nghiêm trọng, hệ thống có thể yêu cầu giám sát của con người. Một mô hình suy luận có thể giúp điều tra sự không chắc chắn, nhưng nó không thay thế việc phê duyệt của con người cần thiết.

Hình 1. Một đường quyết định có giới hạn giữ các ngưỡng, quyền và việc leo thang trong mã.

Có một số điểm tương đồng với việc định tuyến mô hình, nhưng có một sự khác biệt quan trọng. RouteLLM đưa ra quyết định về việc chọn mô hình ngôn ngữ nào trong hai mô hình. Nó chọn giữa một mô hình mạnh hơn và một mô hình yếu hơn để cân bằng chất lượng và giá cả. Một mô hình System One tạo ra các phán đoán có giới hạn mà mã có thể sử dụng trực tiếp. Những phán đoán này có thể hỗ trợ việc định tuyến mô hình cũng như các quyết định khác trong một đại lý.

Tại sao Vòng Lặp Đại Lý Là Sự Phù Hợp Tự Nhiên

Bản chất của các vòng lặp đại lý khiến chúng đặc biệt phù hợp để thực hiện nhiều phán đoán ở mức độ rất nhỏ. Những phán đoán này giúp đạt được kết quả cuối cùng. Nói cách khác, các đại lý phải thực hiện rất nhiều phán đoán \”nhỏ\” sau khi người dùng gửi câu hỏi hoặc yêu cầu. Những phán đoán đó xảy ra trước khi câu trả lời hoặc kết quả được trả về.

Một ví dụ có thể là quyết định công cụ nào sẽ sử dụng, xếp hạng các bản ghi đã truy xuất và đánh giá rủi ro. Hệ thống cũng xác định liệu có đủ bằng chứng và liệu quy trình có nên tiếp tục hay không. Rất có thể tất cả những điều này sẽ lặp lại nhiều lần. Thêm nữa, độ trễ giữa mỗi vòng lặp có thể tích lũy theo thời gian.

Vai trò này của các vòng lặp đại lý được minh họa bởi tích hợp Jev của LangChain, trong đó Jev có thể thực hiện cả định tuyến mô hình và kiểm tra lời gọi công cụ. Trong khi Jev tích hợp vào các phần xung quanh mô hình sinh, mô hình sinh tự nó vẫn tiếp tục lập kế hoạch và tạo nội dung. Điều này đại diện cho một trường hợp sử dụng thực tế hơn rất nhiều cho Jev. Nó bổ sung cho một mô hình ngôn ngữ đa năng thay vì thay thế nó.

Thêm vào đó, việc song song hoá các câu hỏi cũng thay đổi cách các nhóm suy nghĩ về việc phân tách nhiệm vụ. Cụ thể, các nhóm có thể chia một chỉ dẫn mơ hồ thành nhiều câu hỏi đánh giá riêng biệt. Điều này có thể dẫn đến một chuỗi lời gọi mô hình ngắn hơn đáng kể. Nó có thể tạo ra một quy trình làm việc dễ đánh giá hơn nhiều. Nó cũng cho phép các nhà phát triển sử dụng logic kinh doanh rõ ràng để kết hợp các phán đoán thu được.

Các mô hình ngôn ngữ đa mục đích có thể tạo ra đầu ra có cấu trúc và có thể là lựa chọn tốt hơn trong một số trường hợp. Ví dụ, một quyết định và một lời giải thích có thể cần được cung cấp cùng nhau. Do đó, Jev phải chứng minh hơn chỉ việc tuân thủ schema để được coi là hiệu quả.

Hiệu quả của Jev phụ thuộc vào việc đạt được giảm độ trễ tổng thể của hệ thống. Nó cũng phụ thuộc vào việc tạo ra các ước lượng xác suất hữu ích và thể hiện sự ổn định trong hiệu năng qua các đầu vào đa dạng. Nếu Jev không cung cấp được những lợi ích này, việc chọn một mô hình khác sẽ chỉ làm tăng thêm gánh nặng phát triển và vận hành.

Typed có nghĩa là Chính xác không?

Ngôn ngữ được sử dụng khi đưa ra các khẳng định về Jev cũng cần được diễn đạt cẩn thận. Vì không gian đầu ra được định nghĩa trước, mô hình không nên trả về một trường được tự tạo hoặc một đoạn văn không thể phân tích. Điều này loại bỏ một dạng lỗi; nhưng không loại bỏ lỗi ngữ nghĩa. Không có gì ngăn cản một hệ thống trả về phòng ban sai, gán mức rủi ro không chính xác, hoặc khẳng định quá mức chắc chắn. Nó có thể thực hiện tất cả những điều này trong khi vẫn hoàn toàn an toàn về kiểu dữ liệu.

của TypeSafe System One tài liệu đưa ra một sự phân biệt quan trọng. Hiệu chuẩn được đo trên các nhóm dự đoán; nó không đảm bảo độ chính xác của một dự đoán cá nhân. Trong môi trường sản xuất, điều này có những hệ quả. Các nhóm cần kiểm tra xem các xác suất dự đoán có khớp với kết quả quan sát trên dữ liệu của họ hay không.

Bằng chứng về hiệu suất vẫn còn sớm

TypeSafe báo cáo thời gian phản hồi từ 70 đến 500 mili giây. Nó cũng đề cập đến việc tiết kiệm chi phí đáng kể và cải thiện tốc độ trong các đánh giá quy trình làm việc nội bộ của mình. Ngoài ra, TypeSafe cho biết những lợi nhuận tiêu đề đó có khả năng gần mức cao nhất của lợi nhuận thực tế. TypeSafe’s kiểm tra quy trình làm việc có sẵn công khai sử dụng các xác suất tham chiếu do các mô hình tiên tiến khác cung cấp thay vì nhãn thực. Kết quả tốt cho việc hình thành giả thuyết. Kết quả không thể thay thế một bài kiểm tra độc lập đối với một khối lượng công việc thực tế.

Kiểm Tra Thực Tiễn Trước Khi Áp Dụng

Khi bạn xây dựng quy trình quyết định đầu tiên được hỗ trợ bởi AI, đừng chọn những quyết định quan trọng nhất (ví dụ, phê duyệt y tế hoặc đình chỉ tài khoản). Thay vào đó, hãy chọn một việc rất phổ biến, có thể đảo ngược và dễ dàng được các thành viên khác trong nhóm xem xét. Điều này bao gồm nhưng chắc chắn không chỉ giới hạn ở việc định tuyến ticket, phân loại tài liệu, lựa chọn mô hình và kiểm tra chất lượng rủi ro thấp.

Bốn câu hỏi sẽ giúp bạn đánh giá liệu điều này có hoạt động hay không:

• Kết quả có số lượng câu trả lời có hạn không?
• Bạn có thể diễn đạt rõ ràng tiêu chí cho phán đoán không?
• Có kết quả có thể đo lường không? Theo dõi dự đoán, xác suất của nó, hành động và kết quả tiếp theo. Kiểm tra hiệu chuẩn thường xuyên bằng cách so sánh xác suất dự đoán với kết quả quan sát được.
• Bạn có kế hoạch dự phòng trong trường hợp quy trình quyết định tự động thất bại không? Xác định một điểm cụ thể để sử dụng mô hình suy luận, yêu cầu thêm thông tin, hoặc đưa con người vào.

Phân tích của bạn nên bao gồm toàn bộ quy trình, bao gồm cả quá trình ra quyết định. Sử dụng các chỉ số như độ chính xác quyết định, tỷ lệ từ chối hoặc leo thang, tổng thời gian xử lý đầu cuối, chi phí cho mỗi nhiệm vụ hoàn thành thành công, và tác động của các lỗi. Thực hiện các bài kiểm tra trong điều kiện bất lợi: thay đổi cách dùng từ, bỏ qua dữ liệu liên quan, các danh mục hiếm gặp, và đầu vào đối kháng. Một bộ phân loại được tối ưu nhưng tạo ra chi phí bổ sung ở downstream không phải là một tối ưu.

Bài Học Dài Hạn Ở Đây

Nếu Jev thành công, thay đổi đáng kể, hoặc bị thay thế nhanh chóng, một điều vẫn không thay đổi. Câu hỏi kiến trúc vẫn tồn tại. Liệu có cần phải đưa mọi quyết định dựa trên máy móc thành ngôn ngữ được sinh ra không?

Trong nhiều trường hợp, câu trả lời là “không”. Trong môi trường sản xuất, một hệ thống sử dụng mô hình sinh có thể tạo ra các diễn giải, kế hoạch và lời giải thích. Khi sử dụng các mô hình quyết định có giới hạn, cùng một hệ thống có thể định tuyến, chấm điểm và kiểm soát. Mã nguồn vẫn có thể quy định các giá trị ngưỡng và quyền hạn chấp nhận được. Con người nên vẫn chịu trách nhiệm đối với các quyết định ảnh hưởng đến cuộc sống của người khác.

Mặc dù đây là một quan điểm ít kịch tính hơn so với việc một mô hình tự động thực hiện mọi nhiệm vụ một cách đáng tin cậy, nó phản ánh cách các hệ thống đáng tin cậy được tạo ra. Bước tiến tiếp theo về hiệu năng cho các tác nhân có thể phụ thuộc vào việc chọn những khu vực trong hệ thống mà quá trình suy nghĩ mất nhiều thời gian hơn. Các khu vực khác cần quyết định nhanh, và một số không cần hành động nào cả.