Jev: khi agent không cần gọi LLM cho mọi quyết định

Mình đang ngồi quán quen, terminal mở, theo dõi một con agent nhỏ đọc vài email rồi đoán cái nào gấp. Việc chỉ có hai đáp án. Vậy mà log hiện 11 lần gọi model.

Lần thứ mười một, mình dừng lại. Không phải vì model trả lời sai — vì câu hỏi đó không cần một mô hình ngôn ngữ. Nó chỉ cần một câu trả lời có cấu trúc, nhanh, và đủ tin để code quyết định tiếp.

Phần lớn quyết định trong agent loop không cần sinh chữ. Chúng cần một xác suất, một lựa chọn, hoặc một điểm số.

Đó là khoảng trống Jev của TypeSafe AI đang nhắm tới. Theo công bố của họ, trên bài toán phân loại Jev nhanh hơn tới 200 lần và rẻ hơn tới 400 lần so với LLM thường. Mình đọc bài LangChain về cách ghép Jev vào harness, rồi viết lại theo góc mình sẽ thử: không phải "model mới hot", mà "chỗ nào mình đang trả tiền oan".

Vòng lặp agent mạnh — và mỗi mũi tên đều tính tiền

Agent quen thuộc chạy như thế này: LLM quyết định → tool chạy → model đánh giá → lặp. Tool calling và structured output đã giúp model nói chuyện với code rõ hơn. Nhưng chúng chỉ sửa giao diện. Chúng không sửa việc mỗi quyết định nhỏ — kể cả "gấp hay không?" — vẫn tốn một round-trip model đầy đủ.

Với agent chạy vài bước mỗi ngày, ổn. Với hệ chạy hàng nghìn lần, tiền và độ trễ rỉ ra rất êm. Con agent mail của mình là phiên bản thu nhỏ của cái đó: cùng một state, hỏi lại nhiều lần bằng cách đắt nhất.

Jev không phải LLM thay thế

Điểm quan trọng nhất: Jev không sinh text. TypeSafe gọi nó là System One model — lớp model làm quyết định nhanh, có kiểu, để phần mềm tiêu thụ trực tiếp.

Bạn gửi state (ngữ cảnh) và một tập questions. Không có "trả lời thân thiện". Chỉ có câu hỏi và xác suất:

{
  "model": "jev-latest",
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

Kết quả kiểu 0.999 — 99.9% khả năng gấp. App so ngưỡng rồi đẩy ticket vào hàng ưu tiên.

Ba kiểu câu hỏi mình thấy đủ dùng ngay:

• Choice — chọn trong tập cố định, kèm xác suất từng lựa chọn.
• Score — chấm theo mức có thứ tự (thấp / vừa / cao).
• Noul — có/không, trả xác suất câu đó đúng.

Chi tiết mình thích: hỏi nhiều câu trên cùng một state trong một request, chạy song song. Thêm câu gần như không kéo latency — chỉ tốn token phần câu hỏi. Mười một lần gọi của mình, trên lý thuyết, gom lại được thành một.

Ba chỗ mình gắn trước

1. Định tuyến model

Tra cứu đơn giản không nên chung model với bug khó. Jev đọc request, chọn model rẻ nhất đủ làm xong, rồi cả run dùng model đó. Việc khó vẫn leo lên model mạnh. Việc dễ không còn ăn chung hoá đơn.

2. Guardrail trước khi tool chạy

Agent vẫn khó tin theo bản năng. Một chỉ dẫn xấu — vô tình hoặc bị nhồi — là có thể đụng shell. Coding harness lớn đã có bước phân loại hành động nguy hiểm, nhưng thường nằm trong phần đóng.

Classifier rẻ và nhanh thì pattern đó mang ra được cho agent của mình: soi tool call, chặn trước khi chạy. Đây là chỗ mình quan tâm nhất, vì nó đổi cảm giác khi để agent gần terminal.

3. Triage ticket và email

Gấp / không gấp, chủ đề, mức khó chịu, team nào nhận — đều là phân loại. Một state, năm câu, năm xác suất. Với support inbox, đây gần như job description của Jev.

LangChain expose qua TypeSafeClassifier:

from langchain_typesafe import Noul, TypeSafeClassifier

classifier = TypeSafeClassifier()
response = classifier.invoke({
    "state": "The deploy failed twice and customers are seeing 500s. Can someone look now?",
    "questions": {
        "urgent": Noul(instructions="Does this need attention right now?"),
    },
})
urgency = response.nouls["urgent"].noul

Cài langchain-typesafe, set TYPESAFE_API_KEY, gọi từ node hoặc middleware với đúng context agent đang có. Guardrail còn ngắn hơn với AutoModeMiddleware — Jev soi tool call rủi ro rồi chặn trước khi tool chạy.

Khi nào không dùng Jev

Mình sẽ không đẩy Jev vào chỗ cần viết, giải thích, hoặc suy luận mở. Nó không thay LLM soạn email, không viết kế hoạch sửa bug, không "hiểu" theo nghĩa kể chuyện.

Cũng không tin mù con số 200x / 400x. Đó là số nhà cung cấp, trên bài toán của họ. State dài, mạng chậm, hoặc câu hỏi viết ẩu — con số thật của mình sẽ khác. Cách đúng: đếm số lần gọi model cho câu hỏi có/không trong một tuần, rồi thay đúng những lần đó bằng một request classifier.

Checklist ngắn mình dùng:

1. Đáp án có nằm trong tập cố định không? (có/không, chọn một, chấm mức)
2. Nếu sai một lần, thiệt hại có chấp nhận được không? (sai route model ≠ sai xoá production)
3. Có gom được nhiều câu trên cùng state không?
4. Có ngưỡng rõ để code quyết định tiếp không?

Ba câu "có" → thử Jev. Cần chữ, cần lý do dài, cần sáng tạo → giữ LLM.

Kết lại ở chỗ đau thật

Jev không phải đồ chơi thay ChatGPT. Nó là lời nhắc: mình đang dùng LLM như dao đa năng cho cả việc chỉ cần một công tắc.

Nếu bạn cũng có một agent đang gọi model quá nhiều cho câu hỏi chẳng cần sinh chữ — bắt đầu đúng chỗ đó. Đếm lần gọi. Gom câu có/không. Đo hoá đơn và latency trước / sau. Con số marketing sẽ tự nói chuyện với số liệu của bạn.

Bài gốc mình đọc: Building a harness with Jev trên LangChain.