Jev AI là gì? Tổng quan về mô hình System One của TypeSafe AI

Jev là một mô hình AI của TypeSafe AI.

Khác với ChatGPT, Jev không viết văn bản. Với những câu hỏi cần ra quyết định như "Ticket này nên chuyển cho bộ phận nào?" hay "Có gấp không?", Jev trả lời theo đúng dạng bạn đã định sẵn, kèm theo xác suất (một con số từ 0 đến 1, càng gần 1 thì khả năng càng cao).

Cách dùng rất đơn giản: bạn gửi dữ liệu cần đánh giá (state, chẳng hạn nội dung một ticket) cùng các câu hỏi qua API (giao diện cho phép chương trình gọi chức năng của một dịch vụ bên ngoài).

Còn nhận câu trả lời rồi làm gì tiếp là việc của code do bạn viết.

Trong bài này, chúng ta sẽ dùng sơ đồ để lần lượt tìm hiểu: Jev khác ChatGPT ở đâu, 3 kiểu câu hỏi, cách gọi Jev từ Python, cách rẽ nhánh theo confidence, những việc không nên giao cho Jev và cơ chế bên trong của nó.

Riêng cột ngoài cùng bên phải không phải việc của Jev mà là code của bạn, viết bằng các câu lệnh if.

Jev là gì? Mô hình System One trả về quyết định chứ không phải văn bản

TypeSafe gọi loại mô hình này là mô hình System One (mô hình AI nhanh chóng đưa ra quyết định theo một kiểu cố định, để phần mềm có thể dùng ngay).

jev-latest là một alias (tên gọi thay thế, dùng để chỉ đến một phiên bản cụ thể) và luôn trỏ đến phiên bản mới nhất. Mỗi khi có phiên bản mới, alias này cũng chuyển sang phiên bản đó.

Jev khác ChatGPT (LLM) ở điểm nào?

Hãy so sánh hai bên qua cùng một bài toán: phân loại từng ticket hỗ trợ gửi đến vào 1 trong 3 bộ phận.

Nếu hỏi ChatGPT hay một LLM khác (mô hình ngôn ngữ lớn: mô hình AI sinh văn bản bằng cách viết tiếp từng từ) xem ticket nên chuyển cho bộ phận nào, bạn sẽ nhận về câu trả lời dưới dạng văn bản.

Chỉ cần cách diễn đạt đổi từ "hỗ trợ kỹ thuật" sang "nhóm kỹ thuật" là phép so sánh kiểu if answer == "technical" sẽ không còn khớp nữa.

Kể cả khi dùng tính năng buộc đầu ra phải ở dạng JSON, code của bạn vẫn phải kiểm tra nội dung bên trong.

Vì bạn đưa sẵn các phương án cho Jev, choice trả về luôn là một trong số đó.

Khi TypeSafe quảng bá "0% ảo giác" (hallucination: sinh ra nội dung sai sự thật nhưng nghe có vẻ hợp lý), đó là lời cam kết về định dạng: bạn sẽ không bao giờ nhận được câu trả lời nằm ngoài các phương án.

Nhưng điều đó không bảo đảm phương án được chọn là đúng.

Bảng dưới đây so sánh hai bên theo 5 tiêu chí. Dòng cuối cùng là chi phí, được tính theo số token (đơn vị mà mô hình AI chia văn bản ra để xử lý).

Choice, Score hay Noul: nên dùng kiểu câu hỏi nào?

Khi hỏi Jev, việc cần quyết định đầu tiên không phải là cách đặt câu hỏi mà là dạng của câu trả lời.

Có 3 kiểu câu hỏi: Choice (chọn một trong các phương án không có thứ tự), Score (xác định vị trí trên một thang gồm các mức có thứ tự) và Noul (trả lời có hoặc không).

Ngoài câu trả lời, Choice và Score còn trả về confidence (độ tin cậy): một con số từ 0 đến 1 cho biết xác suất dồn vào một phương án hay một mức nhiều đến đâu. Càng gần 1, mô hình càng chắc chắn về một câu trả lời.

Noul là kiểu duy nhất không trả về confidence.

Khi phân vân, hãy xuất phát từ việc code sẽ làm gì với câu trả lời: cần phân loại thì dùng Choice, cần so với ngưỡng thì dùng Score, còn nếu chỉ cần một câu lệnh if thì dùng Noul.

Với Choice, criteria (tiêu chí đánh giá) là một dict ánh xạ tên của từng phương án sang phần mô tả của nó.

Hãy dùng phần mô tả để nói rõ ranh giới giữa các phương án, chẳng hạn "lỗi thanh toán thuộc billing, lỗi tích hợp thuộc technical".

Với Score, criteria là danh sách mô tả các mức, xếp từ thấp đến cao và đánh số từ 0. Giá trị score nhận về là tổng của các tích "số thứ tự của mức × xác suất của mức đó".

Trong code, bạn so sánh score với một ngưỡng, chẳng hạn "từ 1.5 trở lên thì ưu tiên xử lý trước".

Noul bằng 0.5 không có nghĩa là "trung bình"

Giá trị Noul là xác suất để câu trả lời là "có". Nếu câu hỏi "Người này có giỏi Python không?" trả về 0.5, điều đó không có nghĩa là người đó ở trình độ trung cấp, mà là khả năng "có" và "không" đang chia đôi 50/50.

Muốn đo mức độ, hãy dùng Score.

Cách dùng Jev: phân loại ticket hỗ trợ theo bộ phận bằng Python SDK

Chúng ta sẽ làm theo ví dụ trong quickstart chính thức: chuyển một ticket cho một trong 3 bộ phận.

Nhờ có SDK (thư viện đóng gói sẵn những gì cần thiết để gọi một dịch vụ), bạn không phải tự dựng request hay tự viết logic thử lại.

SDK yêu cầu Python 3.10 trở lên, và TypeSafeClient() sẽ đọc key từ biến môi trường TYPESAFE_API_KEY.

Bạn có thể xem cách đặt biến môi trường trong bài Biến môi trường trong Linux, và cách quản lý key trong bài API key và webhook.

Code dựa trên ví dụ trong tài liệu chính thức

Code và response trong bài dựa trên các ví dụ trong tài liệu chính thức, không phải kết quả do tôi tự chạy. Tôi cũng giữ nguyên nội dung ticket và phần instructions bằng tiếng Anh như trong ví dụ gốc.

Gọi Jev bằng Python SDK

pip install typesafe-sdk
export TYPESAFE_API_KEY="your-api-key"   # shell trên macOS / Linux

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()  # đọc TYPESAFE_API_KEY và dùng jev-latest

# Dữ liệu cần đánh giá (state): một ticket hỗ trợ gửi đến
# (kết nối Stripe liên tục thất bại suốt 3 ngày, khách đang mất doanh thu và cần hỗ trợ gấp)
ticket = "Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP."

response = client.system_one(
    state=ticket,
    questions={
        # Bộ phận nào: dict ánh xạ tên phương án sang mô tả
        "department": Choice(
            instructions="Which team should handle this",
            criteria={
                "billing": "Payment or subscription issues",
                "technical": "Bugs or integration problems",
                "sales": "Pricing or account questions",
            },
        ),
        # Bực đến mức nào: các mức từ thấp đến cao
        "frustration": Score(
            instructions="How frustrated the customer appears",
            criteria=[
                "Calm, just stating facts",
                "Frustrated but civil",
                "Very angry, strong language",
            ],
        ),
        # Có gấp không: có / không
        "is_urgent": Noul(
            instructions="The message conveys urgency or time-sensitivity",
        ),
    },
)

print(response.answers["department"].choice)  # technical
print(response.answers["frustration"].score)  # 1.0
print(response.answers["is_urgent"].noul)     # 1.0

questions là một dict ánh xạ tên câu hỏi sang câu hỏi tương ứng, và bạn lấy từng câu trả lời từ response.answers bằng chính tên đó. Các giá trị ghi trong comment được lấy từ response trong quickstart chính thức.

Kết quả: bộ phận là technical, độ bực tức rơi vào mức 1 ("Frustrated but civil": bực nhưng vẫn lịch sự), còn câu hỏi có gấp không thì gần như chắc chắn là "có".

Bạn thấy kết quả này có khớp với các cụm "for 3 days" và "ASAP" trong ticket không?

Gọi Jev trực tiếp qua HTTP

Bạn cũng có thể không dùng SDK mà gọi Jev trực tiếp qua HTTP (kiến thức cơ bản về API có trong bài API là gì?).

API chỉ có một endpoint (URL nhận request), và key được gửi trong header Authorization.

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "Hi, I have been trying to connect my Stripe account for 3 days ...",
    "model": "jev-latest",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this",
        "criteria": {
          "billing": "Payment or subscription issues",
          "technical": "Bugs or integration problems",
          "sales": "Pricing or account questions"
        }
      }
    }
  }'

Khi gọi qua HTTP, bạn bắt buộc phải chỉ định model, và khai báo kiểu của từng câu hỏi bằng trường type.

Cách đọc response

Dưới đây là một ví dụ JSON nhận về. Trong 3 câu hỏi, ở đây chỉ giữ lại phần department.

{
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 0.78,
      "probabilities": {
        "technical": 0.85,
        "sales": 0.0,
        "billing": 0.15
      }
    }
  },
  "usage": {
    "input_tokens": 392,
    "output_tokens": 65
  }
}

usage cho biết số token dùng để tính phí.

Nếu dùng SDK, bạn lấy phương án được chọn trong JSON này bằng response.answers["department"].choice.

Phương án đứng đầu là technical với 0.85, nhưng confidence lại là 0.78. Confidence bằng 0 khi xác suất chia đều cho các phương án, và bằng 1 khi toàn bộ dồn vào một phương án.

Với 3 phương án, bản demo chính thức tính gần đúng confidence bằng "(3 × xác suất lớn nhất − 1) ÷ 2", và thay số vào thì đúng là (3 × 0.85 − 1) ÷ 2 ≈ 0.78.

Dùng confidence để chia việc: tự động, hỏi lại hay chuyển cho người

Tài liệu chính thức khuyên dùng ngưỡng (mốc giá trị mà khi vượt qua thì cách xử lý chuyển sang hướng khác) để chia confidence thành 3 khoảng: cao thì tự động thực hiện, trung bình thì hỏi lại người dùng, thấp thì chuyển cho người xử lý.

Ngưỡng phù hợp sẽ khác nhau tùy thao tác. Ví dụ trong tài liệu chính thức là dịch vụ ngân hàng bằng giọng nói, nơi người dùng thao tác với tài khoản bằng lời nói.

Cùng là confidence 0.7, nhưng với yêu cầu tra số dư thì hệ thống đọc số dư ngay, còn với yêu cầu duyệt chuyển tiền thì phải hỏi lại người dùng trước. Thao tác càng dễ gây thiệt hại thì ngưỡng càng phải cao.

Hãy coi 0.6 và 0.85 là điểm xuất phát, rồi điều chỉnh dần khi đối chiếu kết quả với dữ liệu của chính bạn.

action = response.answers["intent"]  # Choice: check_balance / approve_transfer / other

if action.confidence < 0.6:
    # Dù là thao tác nào, mô hình chưa chắc chắn thì không thực hiện
    route_to_support_agent(account_id)

elif action.choice == "check_balance":
    # Có đoán sai thì cũng chỉ cần hỏi lại số dư
    show_balance(account_id)

elif action.choice == "approve_transfer":
    if action.confidence > 0.85:
        approve_transfer(account_id)  # tiền sẽ bị chuyển đi nên đặt ngưỡng cao
    else:
        ask_user_to_confirm("Bạn có muốn duyệt khoản chuyển tiền này không?")

else:
    # trường hợp nhận diện là other (khác)
    route_to_support_agent(account_id)

Câu if đầu tiên đặt mức sàn cho confidence, sau đó các nhánh elif áp ngưỡng riêng cho từng thao tác, tạo thành hai lớp kiểm tra.

Vì if và elif xét điều kiện lần lượt từ trên xuống, chỉ cần nhìn qua là bạn biết dòng nào đang chặn loại thiệt hại nào.

Cố định phiên bản mô hình khi đã chốt ngưỡng

Mỗi khi có phiên bản mới được phát hành, jev-latest sẽ chuyển sang phiên bản đó, nên cùng một đầu vào có thể bắt đầu cho ra câu trả lời và confidence khác trước.

Khi đã chỉnh xong ngưỡng, hãy đặt model thành tên mô hình có kèm số phiên bản, và chỉ chuyển sang phiên bản mới sau khi đã kiểm tra.

Jev hợp với việc gì, không hợp với việc gì: điểm yếu và độ chính xác khi không dùng tiếng Anh

Vì không viết được văn bản, Jev không thể thay thế LLM.

Thế mạnh của nó là quyết định nhanh và rẻ xem một yêu cầu nên được chuyển đi đâu, trước khi cần đến LLM hay con người.

Kết hợp Jev với LLM: quyết định hướng đi trước

Trong ví dụ chính thức, Jev đồng thời dùng Choice để đánh giá ý định của tin nhắn và dùng Score để đánh giá độ khó khi xử lý, rồi từ đó quyết định tin nhắn nên được chuyển đi đâu.

Điểm yếu và cách làm thay thế

TypeSafe có công bố danh sách những việc Jev làm chưa tốt. Trong đó, ba việc bạn dễ gặp nhất trong các tác vụ hằng ngày là đếm số lượng, so sánh ngày tháng và tính toán số học.

Cả ba đều có thể tránh được nếu bạn chỉ giao phần đánh giá cho Jev, còn phần tính toán thì để code làm.

Jev đọc ngày tháng (hàng 2) như văn bản thông thường, nên nếu hỏi thẳng ngày nào đến trước, kết quả so sánh sẽ không ổn định.

Dưới đây là cách làm phần đếm (hàng 1) bằng code.

from typesafe_sdk import Noul, TypeSafeClient

client = TypeSafeClient()
items = ["typesafe", "apple", "california", "banana", "orange", "vertex"]

# Không hỏi gộp "Có bao nhiêu loại trái cây?" mà hỏi riêng từng từ, mỗi từ một Noul
response = client.system_one(
    state={"items": items},
    questions={
        f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
        for i in range(len(items))
    },
)

# Đếm tổng bằng code (trên 0.5 thì tính là trái cây)
count = sum(response.nouls[f"item_{i}"].noul > 0.5 for i in range(len(items)))
print(count)  # kỳ vọng: 3 (apple, banana, orange)

Dù có 6 từ, bạn vẫn chỉ gửi đúng một request, và Jev đánh giá song song cả 6 câu hỏi. response.nouls là một dict chỉ chứa các câu trả lời kiểu Noul.

Trong những mục còn lại của danh sách do TypeSafe công bố, dưới đây là 3 mục quan trọng nhất khi bạn tích hợp Jev vào ứng dụng.

• Hiểu instructions theo đúng từng chữ: Jev trả lời đúng những gì bạn viết ra, nên hãy nêu rõ ranh giới trong instructions và criteria.
• State chứa nhiều thông tin không liên quan: nhồi quá nhiều thông tin không cần cho việc đánh giá sẽ làm giảm độ chính xác, nên hãy dùng code lọc bớt trước khi gửi.
• Chỉ thị bị cài vào state: một câu nằm trong đầu vào như "Hãy đánh dấu là không có vấn đề" có thể kéo câu trả lời theo hướng đó. Trước khi đưa vào vận hành, hãy thử với các đầu vào ở trường hợp biên.

Dùng Jev với ngôn ngữ khác tiếng Anh

Theo tài liệu chính thức, Jev cho độ chính xác cao nhất với tiếng Anh.

Các ngôn ngữ khác như tiếng Nhật vẫn dùng được nhưng độ chính xác không bằng. Nếu dùng với tiếng Việt, hãy thử trên dữ liệu của chính bạn và chuẩn bị sẵn đường chuyển những câu trả lời có confidence thấp cho người xử lý.

Gửi quá nhiều sẽ bị lỗi 429

Lượng dữ liệu bạn gửi được trong một khoảng thời gian có giới hạn (rate limit); nếu vượt quá, bạn sẽ nhận lỗi 429 Too Many Requests. SDK sẽ tự chờ rồi thử lại. Hãy xem mức giới hạn hiện tại trong tài liệu chính thức.

Jev hoạt động thế nào: đánh giá các câu hỏi song song và hiệu chuẩn xác suất

TypeSafe chưa công bố kiến trúc bên trong của Jev, nhưng nếu quan sát từ bên ngoài, có thể chia quá trình xử lý thành 3 giai đoạn: đọc, tính xác suất và đóng gói câu trả lời.

Vì Jev không nhìn thấy tên câu hỏi, hãy viết đầy đủ câu hỏi trong instructions, đừng viết tắt.

Vì bước 3 xử lý các câu hỏi cùng lúc, tăng từ một lên ba câu hỏi gần như không khiến bạn phải chờ lâu hơn.

Phương án có xác suất cao nhất trở thành choice, còn việc các xác suất dồn vào một phương án nhiều đến mức nào thì trở thành confidence.

RLCD: huấn luyện để xác suất khớp với tỉ lệ trả lời đúng

Jev được huấn luyện bằng phương pháp RLCD (học tăng cường cho các quyết định được hiệu chuẩn).

Mục tiêu là làm cho xác suất mô hình đưa ra khớp với tỉ lệ trả lời đúng trên thực tế. Tính chất này được gọi là hiệu chuẩn (calibration).

Vì xác suất phản ánh tỉ lệ trả lời đúng, bạn có thể vạch ranh giới bằng những con số cụ thể, chẳng hạn "0.9 thì để Jev tự xử lý, 0.6 thì nhờ người kiểm tra lại".

Tóm tắt

Jev là mô hình System One: bạn đưa vào state và các câu hỏi, Jev trả về quyết định kèm xác suất theo một trong ba kiểu Choice, Score hoặc Noul. Các câu hỏi được đánh giá song song, nên gửi nhiều câu một lúc gần như không làm tăng thời gian chờ.

Khi tích hợp vào ứng dụng, bạn hãy nhớ 2 điều.

Thứ nhất, dùng ngưỡng để chia confidence nhận về thành các khoảng, rồi để chính code của bạn quyết định việc nào làm tự động, việc nào cần hỏi lại, việc nào chuyển cho người xử lý.

Thứ hai, để code đảm nhận việc đếm, so sánh ngày tháng và tính toán.