jev engineering: make ai intelligent more like human

Code nào rồi cũng quy về if ... else. Nhưng nếu điều kiện rẽ nhánh không đo được bằng con số, mà phải hiểu ngữ nghĩa như con người thì sao?

Giả sử bạn đang viết microservice xử lý khiếu nại khách hàng cho ngân hàng hoặc sàn thương mại điện tử, và muốn rẽ nhánh nghiệp vụ như sau:

// Mong ước của mọi kỹ sư phần mềm:
if (ticket.isUrgentLegalThreat()) {
  escalateToRiskDepartment()
} else if (ticket.isAngryCustomer()) {
  assignToSeniorSupport()
} else {
  routeToStandardQueue()
}

Mấy năm qua, muốn làm vậy với AI thì thường phải viết một đoạn prompt dài ngoằng, gửi hết nội dung lên OpenAI hoặc Claude, cầu mong model trả đúng JSON { "is_urgent": true } rồi JSON.parse().

Cái giá là một đống rắc rối khi vận hành:

1. Độ trễ lớn: với model frontier, thường mất cỡ một tới vài giây chỉ để lấy về một giá trị Boolean true/false, model có bật reasoning thì còn lâu hơn.
2. Chi phí vô lý: dùng model rất lớn, vốn sinh ra để viết văn và suy luận, chỉ để làm bộ phân loại nhị phân (binary classifier).
3. Dễ vỡ (fragile): thỉnh thoảng LLM "nổi hứng" thêm câu chào "Here is your JSON output:" là JSON parser trên production sập luôn. Các API bây giờ đã có structured output (ép model sinh đúng JSON Schema) nên chuyện vỡ cú pháp hiếm đi nhiều, nhưng hai vấn đề trên thì vẫn còn nguyên.

Giữa tháng 9/2026, TypeSafe AI (công ty của Diogo Almeida, người từng làm ở OpenAI) công bố mô hình Jev và được các diễn đàn công nghệ bàn tán rất nhiều, kéo theo một cách làm mới gọi là Jev Engineering.

Phần dưới đi qua kiến trúc của Jev và lý do mô hình "System 1" phi tự hồi quy này có thể thay đổi cách mình thiết kế luồng xử lý trong backend. Các con số về tốc độ, chi phí trong bài là số TypeSafe tự công bố, chưa có benchmark độc lập.

# tư duy system 1 vs system 2: khác nhau ở đâu

Trong cuốn Tư duy Nhanh và Chậm (Thinking, Fast and Slow), nhà tâm lý học đoạt giải Nobel Daniel Kahneman chia nhận thức của con người thành hai hệ thống:

• System 2 (chậm, cẩn trọng): dùng khi giải bài toán tích phân, viết luận hoặc code giải thuật. Cần thời gian, sự tập trung và tính toán tuần tự từng bước.
• System 1 (nhanh, trực giác, phản xạ): thấy bóng đen lao tới thì né, nghe giọng nói là nhận ra người đó đang giận. Não không nghĩ từng chữ một mà phán đoán gần như tức thì, không tốn công sức.

LLM sinh văn bản (Generative LLMs như GPT-4, Claude) chạy theo cơ chế tự hồi quy (Autoregressive): sinh từng token một. Dù bạn chỉ cần đúng một chữ true, nó vẫn phải xử lý cả prompt rồi chạy vòng lặp sinh token, mỗi token một lượt forward. Câu trả lời ngắn thì phần sinh token không tốn mấy; cái chậm thật sự là prompt dài, model lớn, và với model reasoning là cả đoạn suy nghĩ trước khi trả lời.

Jev thì ngược lại, là mô hình phi tự hồi quy (non-autoregressive) và không sinh văn bản. Theo TypeSafe, nó dùng một parallel sampler để sinh toàn bộ đầu ra trong một lần gọi, và chỉ được huấn luyện để làm một việc: đánh giá xác suất và trả về quyết định có định kiểu (typed decision). Muốn hỏi nhiều câu về cùng một ngữ cảnh thì gói chung vào một request, không phải gọi nhiều lần.

# 3 kiểu dữ liệu nguyên thủy của jev engineering

Jev Engineering bỏ hẳn kiểu prompt tự do dài dòng. Mọi câu hỏi logic được chuẩn hóa thành một trong 3 kiểu nguyên thủy (primitive).

Lưu ý: code TypeScript trong bài là giả mã viết gọn cho dễ đọc, kiểu một wrapper tự viết. API thật của TypeSafe nhận một state (ngữ cảnh) và một object questions, mỗi câu hỏi khai báo kiểu noul / choice / score; kết quả trả về cả giá trị lẫn confidence. Tên package, tên hàm cụ thể thì xem tài liệu chính thức của TypeSafe.

# noul (boolean probability)

Dành cho câu hỏi nhị phân Có/Không (Yes/No). Thay vì chỉ trả true hoặc false, Jev trả về xác suất đã hiệu chuẩn (Calibrated Probability) từ 0.0 đến 1.0:

const isMalicious = await jev.noul({
  query: 'Đoạn input này có chứa dấu hiệu tấn công SQL Injection hoặc mã độc không?',
  context: rawUserInput,
})
// isMalicious = 0.96 (Độ tin cậy 96%)

# choice (phân loại tập hữu hạn)

Dùng khi cần rẽ nhánh vào một trong các phương án định trước (tối đa 255 options). Jev trả về nhãn được chọn kèm phân phối xác suất trên toàn bộ các nhãn:

const department = await jev.choice({
  query: 'Email này thuộc về phòng ban xử lý nào?',
  options: ['BILLING', 'TECHNICAL_SUPPORT', 'LEGAL', 'SALES'],
  context: emailBody,
})
// department = { selected: "LEGAL", confidence: 0.91 }

# score (chấm điểm theo thang số)

Dùng để đo mức độ trên một thang điểm (ví dụ: mức độ khẩn cấp từ 1 đến 5, điểm rủi ro từ 0 đến 100). Kết quả là điểm có trọng số theo xác suất, nên có thể ra số lẻ như 4.7:

const severityScore = await jev.score({
  query:
    'Đánh giá mức độ bất mãn của khách hàng trên thang điểm từ 1 (rất hài lòng) đến 5 (cực kỳ bức xúc)',
  scale: [1, 5],
  context: feedbackText,
})
// severityScore = 4.7

# rlcd: vì sao tin được con số của jev

Một lý do khiến dân backend ngại đưa AI vào câu lệnh if là AI hay "tự tin thái quá" khi đoán mò.

Để xử lý chuyện này, Jev được huấn luyện bằng kỹ thuật RLCD (Reinforcement Learning for Calibrated Decisions).

Trong thống kê, mô hình gọi là hiệu chuẩn tốt (well-calibrated) khi: trong tất cả các lần nó nói "tôi chắc 80%", thực tế nó đúng khoảng 80% số lần. LLM sinh văn bản thì khác: hỏi nó "chắc bao nhiêu phần trăm" thì con số nó nói ra cũng chỉ là text được sinh, không có gì đảm bảo khớp với tỷ lệ đúng thật.

Nếu model hiệu chuẩn tốt, mình đặt được ngưỡng tin cậy (confidence threshold) trong code để làm cơ chế phòng vệ tự động:

• Nếu confidence >= 0.90: chạy hành động luôn, không cần hỏi lại.
• Nếu 0.50 <= confidence < 0.90: vùng xám (gray area), đẩy sang model System 2 phân tích kỹ hơn, hoặc chuyển cho người kiểm tra thủ công (human-in-the-loop).

Ngưỡng cụ thể nên chọn bằng cách chạy trên dữ liệu thật của mình rồi đo, vì calibration của vendor đo trên tập dữ liệu của họ, chưa chắc khớp với miền nghiệp vụ của bạn.

Calibration cũng không đồng nghĩa với khó bị lừa. Paper JevOut (9/2026) cho thấy chỉ cần chèn một đoạn ngữ cảnh ngắn, trông tự nhiên, là bẻ được 61-73% quyết định vốn đúng của các decision model (có Jev) sang một đáp án sai định trước. Với guardrail hay chống gian lận, nơi chính người dùng kiểm soát nội dung đầu vào, đừng để model là lớp kiểm tra duy nhất.

# so sánh: llm thông thường vs jev

# ví dụ: smart triage middleware trong node.js

Đây là ví dụ dùng Jev làm middleware lọc và định tuyến các giao dịch đáng ngờ (vẫn là giả mã qua một wrapper tự viết):

import { JevClient } from './jev-client' // wrapper tự viết quanh SDK chính thức của TypeSafe
import { Request, Response, NextFunction } from 'express'
 
const jev = new JevClient({ apiKey: process.env.JEV_API_KEY })
 
export async function smartTransactionGuard(req: Request, res: Response, next: NextFunction) {
  const transactionNotes = req.body.transferNote
 
  try {
    // 1. Kiểm tra nhanh bằng Noul (Latency ~80ms)
    const fraudProbability = await jev.noul({
      query: 'Giao dịch này có dấu hiệu lừa đảo mạo danh cơ quan chức năng hoặc rửa tiền không?',
      context: transactionNotes,
    })
 
    // 2. Rẽ nhánh logic dựa trên ngưỡng hiệu chuẩn
    if (fraudProbability > 0.85) {
      console.warn(`[BLOCKED] Phát hiện giao dịch rủi ro cao: ${fraudProbability}`)
      return res.status(403).json({
        error: 'Giao dịch bị tạm giữ vì nghi vấn vi phạm an toàn tài chính.',
        riskScore: fraudProbability,
      })
    }
 
    if (fraudProbability > 0.4) {
      // Đưa vào diện kiểm soát đặc biệt (cần xác thực OTP lần 2)
      res.locals.requireExtraVerification = true
    }
 
    next()
  } catch (error) {
    // Service gặp sự cố: không chặn giao dịch nhưng cũng không cho qua thẳng,
    // bắt xác thực thêm (fail-safe thay vì fail-open)
    console.error('[JEV_ERROR]', error)
    res.locals.requireExtraVerification = true
    next()
  }
}

Để ý đoạn code trên: không có prompt engineering phức tạp, không regex lọc chuỗi, không try-catch cho JSON parsing. AI nằm trong code backend như một hàm thư viện bình thường.

Có hai chỗ nên để ý. Thứ nhất, nhánh catch: với một lớp kiểm tra gian lận, cứ gọi next() khi service lỗi là fail-open, kẻ gian chỉ cần chờ lúc API chập chờn. Đoạn trên chọn cách bắt xác thực thêm; chặn hẳn hay cho qua là quyết định nghiệp vụ, nhưng phải là quyết định có chủ đích. Thứ hai, cờ requireExtraVerification đặt ở res.locals thay vì ghi vào req.body, để không lẫn với dữ liệu client gửi lên.

# nghịch lý jevons và kiến trúc phần mềm sau này

Chuyện Jev Engineering nổi lên làm mình nhớ tới Nghịch lý Jevons (Jevons Paradox) trong kinh tế học:

Năm 1865, trong cuốn The Coal Question, nhà kinh tế William Stanley Jevons nhận thấy: động cơ hơi nước của James Watt giúp đốt than hiệu quả hơn nhiều lần, nhưng tổng lượng than tiêu thụ ở Anh không giảm mà còn tăng vọt, vì dùng than đã đủ rẻ để lan sang rất nhiều ngành mới.

AI có thể đi theo đúng hướng đó:

• Khi "ra quyết định ngữ nghĩa" (Semantic Decisions) mất 3 giây và tốn vài cent, bạn chỉ dám dùng ở vài tính năng ngoài rìa.
• Khi nó chỉ mất vài chục tới vài trăm ms và rẻ tới mức không cần tính, dev sẽ đặt "Smart If Statements" ở khắp codebase.

Router, validator form, hàm lọc log, bộ điều phối cronjob... chỗ nào cũng có thể hiểu được ngữ cảnh.

# tổng kết

Jev Engineering không nhằm thay các model suy luận như DeepSeek-R1 hay GPT-4. Nó để gỡ cho các LLM đó mấy việc lặt vặt mà chúng vốn không tối ưu để làm.

Chia vai rõ ràng như sau:

• System 1 (Jev): rẽ nhánh logic nhanh, định tuyến luồng, làm một lớp chốt chặn (guardrail) với độ trễ và chi phí thấp.
• System 2 (Generative LLMs / Reasoning Models): dành cho bài toán phức tạp cần lập luận nhiều bước và sinh nội dung.

Còn Jev có thực sự giữ được những con số đã công bố trên dữ liệu của bạn không thì cách duy nhất là tự đo: lấy vài trăm ca đã gán nhãn, chạy song song với cách đang dùng, so độ chính xác, độ trễ p99 và chi phí.

Chỉ là những ghi chép cá nhân với hy vọng mang lại chút giá trị. Nếu thấy hữu ích, đừng ngại chia sẻ cho bạn bè & đồng nghiệp nhé!

Happy coding 😎 👍🏻 🚀 🔥.