Nếu Jev nói tiếng Arrow? Khám phá tương lai của AI có cấu trúc

Jev là mô hình mới của TypeSafe AI, có khả năng chuyển đổi ngôn ngữ tự nhiên và trạng thái ứng dụng thành các quyết định có kiểu dữ liệu rõ ràng. Bài viết từ Columnar.tech đặt câu hỏi thú vị: điều gì sẽ xảy ra nếu Jev không chỉ trả về JSON mà còn "nói" được định dạng Apache Arrow — một công nghệ đang thay đổi cách các pipeline dữ liệu vận hành?

Jev là gì và tại sao nó quan trọng?

Jev là một mô hình mới từ TypeSafe AI, được thiết kế để biến ngôn ngữ tự nhiên và trạng thái ứng dụng thành các quyết định có kiểu dữ liệu. Thay vì để bạn phải tự phân tích kết quả đầu ra của mô hình ngôn ngữ lớn (LLM), Jev cho phép bạn cung cấp ngữ cảnh và định nghĩa các câu trả lời có thể có. Đổi lại, nó trả về các lựa chọn, điểm số và xác suất mà code của bạn có thể sử dụng trực tiếp.

Hiện tại, API của Jev trả kết quả dưới dạng JSON. Đây là cách tiếp cận khác biệt so với các công cụ như Outlines của .txt — vốn sử dụng kỹ thuật "giải mã có ràng buộc" (constrained decoding) để buộc các mô hình hiện có tạo ra đầu ra tuân theo một schema nhất định.

TypeSafe đã chọn một hướng đi riêng: họ công bố một kiến trúc mô hình mới, một bộ lấy mẫu song song (parallel sampler) và phương pháp huấn luyện gọi là Học tăng cường cho các quyết định đã hiệu chỉnh (Reinforcement Learning for Calibrated Decisions). Jev tạo ra xác suất song song, tránh việc sinh từng token một. TypeSafe báo cáo tốc độ và chi phí được cải thiện đáng kể so với các LLM đa dụng trong các quy trình ra quyết định.

Jev là một nguyên thủy mới, và chưa ai biết hết phạm vi những gì nó có thể mở ra.

Các mẫu thiết kế mạnh mẽ với Jev

Tài liệu của TypeSafe mô tả một số mẫu (pattern) đã rõ ràng:

• Speculative fan-out: Đặt nhiều câu hỏi trong một lần gọi, bao gồm cả những câu mang tính dự đoán, và để code của bạn quyết định câu trả lời nào liên quan.
• Confidence-gated routing: Coi độ tin cậy như một trục quyết định thứ hai, cho phép code đi theo hướng khác khi Jev không chắc chắn.
• Composite scoring: Kết hợp nhiều chiều đánh giá thành một điểm số duy nhất.
• Intent routing: Phân loại ý định người dùng và định tuyến yêu cầu đến handler phù hợp.

Những mẫu này mở ra cánh cửa cho các quy trình và pipeline mang tính xác suất — ở những nơi mà gần đây chúng ta vẫn cho rằng chỉ có quy trình tất định (deterministic) mới khả thi.

Tại sao Apache Arrow lại là mảnh ghép phù hợp?

Các pipeline như vậy vận chuyển rất nhiều dữ liệu có cấu trúc. Điều này khiến nhóm Columnar.tech tự hỏi: liệu Jev có thể hoạt động với Apache Arrow — công nghệ kết hợp cấu trúc với hiệu năng và hiệu quả — hay không?

Trong bài viết trước mang tên "Stop paying the JSON tax" (Ngừng trả thuế JSON), họ đã mô tả cách Arrow tăng tốc pipeline dữ liệu bằng cách tránh việc chuyển đổi sang JSON rồi lại chuyển ngược lại. Liệu Arrow có thể làm điều tương tự ở đây?

Mô hình hóa câu trả lời của Jev bằng Arrow

Jev có ba loại câu hỏi, mỗi loại có hình dạng câu trả lời khác nhau:

• Choice: Một lựa chọn được chọn, xác suất cho mọi lựa chọn, và điểm tin cậy.
• Noul: Xác suất câu trả lời "có" cho một câu hỏi có/không. Không có trường tin cậy riêng.
• Score: Một vị trí trên các mức có thứ tự, có thể nằm giữa các mức; xác suất cho mỗi mức, độ tin cậy, và chú giải mô tả các mức.

Nhóm nghiên cứu đã thiết kế một schema Arrow để biểu diễn các câu trả lời này dưới dạng cột. Định nghĩa câu hỏi cho biết kiểu của cột trước khi suy luận bắt đầu. Nhãn Choice và chú giải Score mô tả các câu trả lời có thể có, nên có thể đưa chúng vào metadata của trường trong schema. Các dự đoán và xác suất nằm trong bộ đệm dữ liệu (data buffers).

Arrow extension types cho phép gắn ý nghĩa ngữ nghĩa đó vào các kiểu lưu trữ Arrow thông thường. Nếu API TypeSafe trả về Arrow trực tiếp theo schema này, các công cụ như pandas, Polars, DuckDB và Apache DataFusion có thể tiêu thụ kết quả mà không cần giải mã JSON trước và xây dựng lại các cột có kiểu.

Đây đã là cách trao đổi dữ liệu có cấu trúc phổ biến: Databricks, Snowflake và ClickHouse có thể trả kết quả truy vấn dưới định dạng Arrow qua HTTP. Hugging Face Datasets dùng Arrow nội bộ và cho phép truy xuất bảng Arrow trực tiếp.

Từ một trạng thái đến nhiều trạng thái

Jev hiện chưa hỗ trợ đầu ra Arrow, nên nhóm Columnar.tech đã mô phỏng những gì sẽ xảy ra nếu API TypeSafe có tính năng này. Điều đó có nghĩa là đưa Jev từ tầng vận hành — nơi nó ra quyết định từng tương tác một — sang tầng phân tích, nơi đơn vị công việc là cả một bảng dữ liệu.

Ở đây, họ gặp một vấn đề cơ bản hơn với định dạng yêu cầu. Một yêu cầu API TypeSafe chứa state (ngữ cảnh cần đánh giá) và questions (bản đồ các phán đoán cần thực hiện). API được thiết kế tuyệt vời cho việc hỏi nhiều câu hỏi về một trạng thái. Nhưng nó không có thao tác batch gốc để hỏi cùng một bộ câu hỏi về nhiều trạng thái độc lập.

Ví dụ, với một tương tác khách hàng trực tiếp, bạn có thể muốn xác định ý định, chấm điểm mức độ khẩn cấp, kiểm tra điều kiện hoàn tiền và tìm dấu hiệu gian lận. Bạn gửi ngữ cảnh một lần, hỏi tất cả các câu hỏi cùng lúc, và Jev đánh giá chúng độc lập song song.

Nhưng trước khi tin tưởng những phán đoán đó trong ứng dụng thực tế, bạn cần kiểm chứng chúng — chạy chúng trên một mẫu đại diện các tương tác khách hàng lịch sử và so sánh câu trả lời với kết quả đã biết.

Đó chính là khối lượng công việc mà nhóm quan tâm: nhiều trạng thái, một bộ câu hỏi cố định. Tốc độ và giá của Jev rất phù hợp cho công việc này. Trở ngại nằm ở API: không có endpoint bulk, nên bạn phải thực hiện hàng nghìn đến hàng triệu lời gọi API riêng lẻ, mỗi trạng thái một lần.

Xây dựng Jevaro

Không bỏ cuộc, nhóm đã xây dựng Jevaro: một proxy server Python nhỏ, kèm client Python và JavaScript. Nó nhận nhiều trạng thái và một bản đồ câu hỏi chung trong một yêu cầu, gọi Jev cho từng trạng thái, và trả về luồng Arrow IPC theo schema đã thiết kế. Kết quả đến theo thứ tự đầu vào. Schema được gửi đi ngay lập tức, và các câu trả lời theo sau khi chúng sẵn sàng.

Để cải thiện thông lượng, nhóm đã trải qua nhiều vòng tinh chỉnh:

• Mở kết nối mới liên tục làm tăng thời gian thiết lập mạng và TLS.
• Chờ từng câu trả lời trước khi gửi yêu cầu tiếp theo khiến các lời gọi không thể chồng lấn.
• Giải pháp: tái sử dụng pool kết nối HTTP/2 sống lâu, duy trì một cửa sổ các yêu cầu bất đồng bộ đang chờ, và nạp lại trước khi ghi các batch kết quả.
• SDK retries khôi phục kết nối bị ngắt và backoff khi gặp giới hạn tốc độ hoặc phản hồi quá tải.

Ngay cả sau khi tinh chỉnh, mỗi trạng thái vẫn cần một yêu cầu HTTP thượng nguồn riêng và phản hồi JSON riêng. Nhóm kỳ vọng một lời gọi bulk gốc trả về luồng Arrow trực tiếp từ API sẽ đạt thông lượng tốt hơn nhiều bậc độ lớn bằng cách tránh việc xử lý yêu cầu lặp lại và chuyển đổi JSON.

Sử dụng Jevaro từ Python và JavaScript

Với uv, bạn đặt khóa API TypeSafe và khởi động server:

export TYPESAFE_API_KEY="your-api-key"
uvx jevaro-server

Sau đó chạy script Python để đọc kết quả dưới dạng PyArrow RecordBatchReader. Với JavaScript, bạn chạy npm install jevaro và nhận về Apache Arrow AsyncRecordBatchStreamReader. SDK cũng hoạt động trên trình duyệt.

Thông lượng và chi phí thực tế

Để đo thông lượng của Jevaro, nhóm đã thử nghiệm một batch 10.000 tin nhắn khách hàng tổng hợp, mỗi tin được đánh giá với một Choice cho bộ phận, một Score cho mức độ khẩn cấp, và một Noul cho việc liệu có yêu cầu hoàn tiền hay không.

Kết quả:

• Lần chạy nhanh nhất trả về đủ 10.000 hàng trong 21,5 giây — khoảng 464 trạng thái mỗi giây.
• Client nhận schema sau 34 mili giây và hàng trả lời đầu tiên sau 290 mili giây.
• Chi phí ước tính: 0,20 USD cho 30.000 câu trả lời.

Jev xử lý khối lượng công việc này một cách rẻ và tương đối nhanh, bất chấp chi phí của 10.000 lời gọi API riêng lẻ.

Điều đó chưa cho biết Jev có thể nhanh hơn bao nhiêu với một API bulk trả về Arrow trực tiếp. Jevaro vẫn thực hiện một lời gọi API mỗi trạng thái, và API TypeSafe vẫn tuần tự hóa mỗi phản hồi thành JSON. Jevaro phân tích các phản hồi đó và xây dựng mảng Arrow. Nhóm đã tối ưu việc chuyển đổi và đưa nó ra khỏi code người dùng, nhưng nó vẫn diễn ra.

Để loại bỏ chi phí đó, việc batching và đầu ra Arrow cần diễn ra trong chính API TypeSafe.

Điều gì tiếp theo?

Danh sách mong muốn của nhóm đối với API TypeSafe khá hẹp: một endpoint bulk trả về Arrow. Mọi thứ khác về Jev đều khiến họ hào hứng, đặc biệt là triển vọng về các pipeline kết hợp quyết định xác suất với xử lý dữ liệu tất định.

Họ đang xây dựng một số khả năng mới theo hướng đó vào Columnar Gateway, đồng thời tiếp tục tinh chỉnh Jevaro: thêm đầu vào Arrow, cải thiện khả năng thích ứng với giới hạn tốc độ API đang thay đổi, và thử nghiệm thêm với kích thước batch bản ghi đầu ra.

Đối với độc giả Việt Nam đang theo dõi xu hướng AI có cấu trúc (structured AI) và kỹ thuật dữ liệu, đây là tín hiệu đáng chú ý: sự giao thoa giữa mô hình AI tạo sinh và định dạng dữ liệu hiệu năng cao như Arrow có thể định hình lại cách các hệ thống ra quyết định tự động được xây dựng trong vài năm tới.