Chọn mô hình phù hợp với công việc (và ngân sách)

Cách tư duy hữu ích: Đặc điểm tác vụ trước, mô hình sau

Trong thực tế, tôi phân loại khối lượng công việc LLM theo năm khía cạnh trước cả khi xem tên mô hình:

Việc chọn mô hình trở nên dễ dàng hơn nhiều khi bạn ngừng hỏi “mô hình nào thông minh nhất?” và bắt đầu hỏi “tôi đang chi tiền để giảm kiểu lỗi nào?”

Ví dụ:

• Công cụ tóm tắt yêu cầu đặt lại mật khẩu cần tính nhất quán và chi phí thấp.
• Trợ lý chuyển đổi mã cần khả năng suy luận và sử dụng công cụ.
• Công cụ so sánh thay đổi trong hợp đồng cần ngữ cảnh dài, đồng thời phải xác định nguồn thông tin cẩn thận.
• Tác nhân tương tác trực tiếp với khách hàng cần độ trễ có thể dự đoán hơn là chất lượng cao nhất trên bài đánh giá chuẩn.
• Quy trình làm giàu dữ liệu theo lô có thể quan tâm đến thông lượng trên mỗi đô la hơn là sự trau chuốt của phản hồi.

Mô hình không phù hợp thường không sai về mặt kỹ thuật. Nó sai về mặt kinh tế.

Thang lựa chọn mô hình thực tế

Đây là thang lựa chọn tôi sử dụng cho hầu hết các hệ thống sản xuất.

Các mô hình cùng phân khúc Haiku: Lựa chọn mặc định cho tác vụ ngôn ngữ nhanh, chi phí thấp

Các mô hình cùng phân khúc Haiku rất phù hợp cho lượt xử lý đầu tiên. Tôi dùng chúng cho những công việc có câu trả lời ngắn, đầu vào rõ ràng và định dạng đầu ra được ràng buộc.

Các tác vụ phù hợp:

• Gắn nhãn phiếu hỗ trợ
• Tóm tắt ngắn
• Phân loại cảm xúc
• Chuẩn hóa tiêu đề email
• Đối chiếu câu hỏi thường gặp
• Trích xuất JSON đơn giản
• Bộ lọc sơ bộ cho kiểm duyệt nội dung ít rủi ro

Ví dụ về prompt cho bộ phân loại sơ bộ chi phí thấp:

{
  "model": "claude-haiku-4.5",
  "temperature": 0,
  "max_tokens": 120,
  "response_format": { "type": "json" },
  "messages": [
    {
      "role": "system",
      "content": "Classify the support ticket. Return only valid JSON."
    },
    {
      "role": "user",
      "content": "Subject: Refund not received\nBody: I canceled two weeks ago and still see a charge."
    }
  ]
}

Đầu ra dự kiến:

{
  "category": "billing",
  "urgency": "medium",
  "needs_human": true,
  "reason": "Refund dispute involving payment status"
}

Một vấn đề thường gặp: các nhóm yêu cầu mô hình giá rẻ vừa suy luận vừa định dạng hoàn hảo trong một lần. Nếu đôi khi mô hình tạo ra JSON không hợp lệ, đừng lập tức chuyển sang Opus. Trước tiên, hãy làm rõ và thu hẹp tác vụ:

• Đặt temperature: 0
• Sử dụng lược đồ JSON hoặc lệnh gọi công cụ
• Thu gọn phạm vi chỉ dẫn
• Tách bước phân loại khỏi bước giải thích
• Kiểm tra tính hợp lệ của đầu ra và thử lại một lần

Với nhiều tác vụ trong môi trường thực tế, thử lại một lần bằng mô hình cấp Haiku vẫn rẻ hơn và nhanh hơn so với mặc định dùng mô hình suy luận tiên tiến nhất.

Mô hình cấp Sonnet: Lựa chọn chủ lực cho logic sản phẩm thực tế

Mô hình cấp Sonnet thường là lựa chọn của tôi cho các tính năng sản phẩm có tính tương tác. Chúng đủ mạnh để suy luận, đủ ổn định để sử dụng công cụ và thường đủ nhanh cho các luồng tương tác với người dùng.

Các tác vụ phù hợp:

• Soạn phản hồi hỗ trợ khách hàng
• Quy trình tác nhân sử dụng công cụ
• Giải thích mã và tái cấu trúc nhẹ
• Hỏi đáp tài liệu qua nhiều bước
• Quy trình trợ lý cho bán hàng hoặc hỗ trợ khách hàng thành công
• Trích xuất dữ liệu có cấu trúc từ đầu vào lộn xộn

Trong thực tế, Sonnet thường là lựa chọn tốt nhất khi bạn muốn “khỏi phải suy nghĩ quá nhiều về việc định tuyến”. Nếu chỉ có thể tích hợp một cấp mô hình vào tính năng mới, hãy bắt đầu từ đây.

Ví dụ: một tác nhân hỗ trợ có thể kiểm tra đơn hàng, chính sách và các phiếu hỗ trợ trước đó.

SYSTEM = """
You are a support resolution assistant.
Use tools before making claims about orders, refunds, or account state.
If policy is ambiguous, say what is ambiguous and escalate.
Return:
- summary
- recommended_action
- customer_reply
- escalate: true/false
"""

request = {
    "model": "claude-sonnet-4.6",
    "temperature": 0.2,
    "max_tokens": 900,
    "tools": [
        {"name": "get_order", "description": "Fetch order state"},
        {"name": "get_refund_policy", "description": "Fetch current refund rules"},
        {"name": "search_prior_tickets", "description": "Search customer history"}
    ],
    "messages": [
        {"role": "system", "content": SYSTEM},
        {"role": "user", "content": "Customer says they returned item A but were charged again."}
    ]
}

Điều thực sự xảy ra khi bạn chạy loại quy trình này trong môi trường thực tế: phần lớn lỗi không phải do “mô hình kém thông minh”. Đó là lỗi tích hợp.

• Công cụ trả về trạng thái đã lỗi thời.
• Mô hình nhận quá nhiều ngữ cảnh không liên quan.
• Tài liệu chính sách có nội dung mâu thuẫn.
• Tác nhân được phép tiếp tục sau khi lệnh gọi công cụ thất bại.
• Prompt yêu cầu cả phân tích nội bộ lẫn nội dung có thể gửi ngay cho khách hàng mà không tách riêng hai phần.

Mô hình cấp Sonnet có đủ năng lực để xử lý một phần sự lộn xộn, nhưng bạn vẫn cần các quy ước giao tiếp với công cụ rõ ràng.

Mô hình cấp Opus: Đắt, nhưng đôi khi rẻ hơn những sai lầm

Mô hình cấp Opus dành cho các tác vụ mà chi phí của một câu trả lời sai lớn hơn nhiều so với chi phí suy luận.

Tôi chọn Opus khi:

• Đầu vào mơ hồ và có hệ quả lớn
• Có nhiều ràng buộc tác động lẫn nhau
• Người dùng kỳ vọng khả năng suy luận sâu
• Tác vụ liên quan đến các đánh đổi về mã, chính sách hoặc kiến trúc
• Một lần thử thất bại bằng mô hình giá rẻ sẽ làm lãng phí thời gian của con người

Ví dụ:

• Rà soát kế hoạch di chuyển cơ sở dữ liệu
• Phân tích diễn biến theo thời gian của một sự cố trong môi trường thực tế
• Tạo bản so sánh phức tạp về pháp lý và chính sách để con người rà soát
• Gỡ lỗi tác nhân gặp sự cố trên nhiều dịch vụ
• Đánh giá liệu một hành động tự động có an toàn hay không

Tôi không dùng Opus cho mọi tác vụ “quan trọng”. Mức độ quan trọng và độ khó là hai điều khác nhau. Một triệu phiếu yêu cầu đặt lại mật khẩu đều quan trọng với người dùng, nhưng từng phiếu riêng lẻ không khó xử lý. Một lần di chuyển dữ liệu có thao tác xóa tinh vi có thể vừa quan trọng vừa khó.

Một cách làm hữu ích là “chuyển lên mô hình mạnh hơn khi không chắc chắn”:

def choose_model(task):
    if task["context_tokens"] > 700_000:
        return "fable-5"

    if task["risk"] == "high" and task["requires_reasoning"]:
        return "claude-opus-4.8"

    if task["requires_tools"] or task["multi_step"]:
        return "claude-sonnet-4.6"

    return "claude-haiku-4.5"

Cách này được giữ đơn giản có chủ đích. Bộ định tuyến nên đơn giản đến mức nhóm của bạn có thể gỡ lỗi lúc 2 giờ sáng.

Fable 5 và ngữ cảnh 1M: Sử dụng khi vấn đề nằm ở việc truy xuất

Mô hình có ngữ cảnh dài rất hấp dẫn vì giúp loại bỏ nhiều công việc kỹ thuật liên quan đến truy xuất. Cửa sổ ngữ cảnh 1M của Fable 5 thay đổi những gì bạn có thể xử lý trực tiếp: rà soát toàn bộ tài liệu, tổng hợp bản chép lời khổng lồ, kiểm tra kho mã lớn và phân tích chính sách trên nhiều tệp.

Nhưng ngữ cảnh dài không phải phép màu.

Cửa sổ 1M token hữu ích khi phần khó nằm ở chỗ “thông tin liên quan có thể ở bất kỳ đâu”. Nó không bảo đảm mô hình sẽ suy luận hoàn hảo trên toàn bộ một triệu token, và cũng không khiến ngữ cảnh không liên quan trở nên miễn phí. Prompt dài vẫn tốn tiền, làm tăng độ trễ và có thể phân tán sự chú ý.

Tôi dùng ngữ cảnh dài kiểu Fable khi:

• Tập tài liệu có quá nhiều liên kết chéo để chia đoạn theo cách đơn giản
• Bỏ sót một chi tiết gây hậu quả lớn hơn việc trả thêm tiền cho ngữ cảnh
• Người dùng có thể chấp nhận phản hồi chậm hơn
• Tác vụ được hưởng lợi từ việc xem nội dung gốc xung quanh

Ví dụ về kiến trúc rà soát tài liệu lớn:

User request
  -> lightweight classifier
  -> retrieve obvious relevant sections
  -> if confidence high: Sonnet answer with citations/quotes from chunks
  -> if confidence low or query is global: Fable 5 over full document set
  -> optional Opus review for high-risk final answer

Cách kết hợp này hiệu quả hơn việc “luôn nhét mọi thứ vào ngữ cảnh”. Trong thực tế, mô hình có ngữ cảnh dài có giá trị nhất khi được dùng làm phương án dự phòng lúc độ tin cậy của truy xuất thấp.

Mô hình có trọng số mở: Quyền kiểm soát, chi phí và thông lượng

Các mô hình có trọng số mở như Llama, Qwen, DeepSeek, MiniMax và Kimi không chỉ là “những lựa chọn thay thế rẻ hơn”. Chúng là những lựa chọn về vận hành.

Chúng phù hợp khi bạn cần:

• Triển khai cục bộ hoặc trong VPC
• Chi phí xử lý theo lô khối lượng lớn có thể dự đoán
• Tinh chỉnh hoặc chưng cất mô hình
• Tối ưu hóa suy luận theo nhu cầu riêng
• Kiểm soát nơi lưu trữ dữ liệu
• Chi phí biên cực thấp sau khi thiết lập

Chúng đặc biệt phù hợp với các tác vụ hẹp, lặp lại. Ví dụ, một biến thể Qwen hoặc Llama được phục vụ qua vLLM có thể xử lý phân loại, trích xuất và bổ sung thông tin nội bộ với thông lượng cao nếu bạn kiểm soát độ dài prompt và định dạng đầu ra.

Ví dụ về cấu hình phục vụ mô hình cục bộ:

vllm serve Qwen/Qwen3-14B \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

Sau đó gọi mô hình qua một ứng dụng khách tương thích với OpenAI:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local"
)

result = client.chat.completions.create(
    model="Qwen/Qwen3-14B",
    temperature=0,
    messages=[
        {"role": "system", "content": "Return valid JSON only."},
        {"role": "user", "content": "Classify: user cannot access invoice PDF"}
    ]
)

Điều đánh đổi là bạn phải chịu trách nhiệm về kỹ thuật. Với các mô hình tiên tiến nhất được lưu trữ sẵn, bên khác xử lý năng lực phục vụ, vá lỗi, lựa chọn lượng tử hóa và tối ưu hiệu năng ở cấp kernel. Với mô hình mở, đó trở thành công việc của bạn.

Mô hình có trọng số mở rất phù hợp khi khối lượng công việc ổn định. Chúng ít phù hợp hơn khi sản phẩm thay đổi hằng tuần và chất lượng prompt quan trọng hơn chi phí phục vụ thuần túy.

Định tuyến ưu tiên mô hình giá rẻ và chuyển lên khi cần

Một bộ định tuyến tốt không phải bảng xếp hạng. Nó là hệ thống kiểm soát rủi ro.

Dưới đây là một cách làm phù hợp với môi trường thực tế:

1. Thử mô hình rẻ nhất được kỳ vọng là có đủ khả năng.
2. Kiểm tra tính hợp lệ của đầu ra bằng các quy tắc tự động.
3. Yêu cầu mô hình tự kiểm tra có hiệu chỉnh chỉ dựa trên các tiêu chí có thể quan sát.
4. Chuyển lên mô hình mạnh hơn nếu kiểm tra thất bại, độ tin cậy thấp hoặc rủi ro cao.
5. Ghi nhật ký tuyến xử lý và kết quả để tinh chỉnh về sau.

Ví dụ về bộ định tuyến:

def run_with_escalation(task, input_text):
    first_model = pick_first_model(task)

    response = call_model(
        model=first_model,
        input=input_text,
        schema=task["schema"],
        temperature=0
    )

    validation = validate(response, task["schema"])

    if not validation.ok:
        return call_model(
            model="claude-sonnet-4.6",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    if task["risk"] == "high" and response.get("needs_review"):
        return call_model(
            model="claude-opus-4.8",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    return response

Điều quan trọng là việc chuyển lên mô hình mạnh hơn phải dựa trên các tín hiệu đo lường được, không phải cảm tính.

Các tín hiệu hữu ích để chuyển lên mô hình mạnh hơn:

• JSON không hợp lệ
• Thiếu các trường bắt buộc
• Câu trả lời mâu thuẫn
• Lệnh gọi công cụ thất bại
• Bằng chứng truy xuất được thiếu thuyết phục
• Người dùng đang yêu cầu một hành động không thể đảo ngược
• Đầu vào vượt quá độ dài thông thường
• Mô hình đánh dấu rõ sự không chắc chắn
• Bộ phân loại phát hiện nội dung pháp lý, y tế, bảo mật hoặc tài chính

Tránh chỉ dùng “độ tự tin của mô hình” dưới dạng điểm số. Độ tự tin của LLM không phải xác suất đã được hiệu chỉnh. Nó vẫn hữu ích khi được giới hạn vào các kiểm tra cụ thể: “Đầu vào có chứa đủ thông tin để trả lời không?” tốt hơn “Bạn tự tin đến mức nào?”

Độ trễ, giá và trải nghiệm người dùng

Mô hình nhanh nhất không phải lúc nào cũng mang lại trải nghiệm người dùng tốt nhất. Trải nghiệm tốt nhất là trải nghiệm giúp người dùng đạt được kết quả đúng với thời gian chờ có thể chấp nhận.

Với các hệ thống tương tác, tôi suy nghĩ theo ngân sách độ trễ:

Đừng che giấu quá trình suy luận chậm sau biểu tượng chờ mà không cung cấp phản hồi. Nếu một tác vụ Opus hoặc Fable cần 90 giây, hãy thể hiện rõ đó là một tác vụ phân tích:

Analyzing 184 files...
✓ Indexed repository structure
✓ Found 12 migration scripts
✓ Checking rollback safety

Điều đó thay đổi cảm nhận của người dùng vì hệ thống đang thực hiện công việc mà họ có thể thấy được.

Ngoài ra, hãy truyền phát bất cứ khi nào có thể. Truyền phát không làm giảm tổng thời gian hoàn thành, nhưng cải thiện đáng kể cảm nhận về độ trễ trong các quy trình trò chuyện và soạn thảo.

Lựa chọn thực tế cho từng tác vụ

Dưới đây là những lựa chọn cụ thể tôi sẽ đưa ra ở thời điểm hiện tại.

Phân loại yêu cầu hỗ trợ

Dùng Haiku trước.

• Đầu vào: nội dung yêu cầu hỗ trợ ngắn
• Đầu ra: danh mục, mức độ khẩn cấp, hàng đợi tiếp nhận
• Chuyển lên Sonnet đối với tranh chấp thanh toán, khách hàng đang tức giận hoặc chính sách chưa rõ ràng
• Để con người xem xét các khoản hoàn tiền vượt ngưỡng

Đây là một quy trình điển hình ưu tiên mô hình chi phí thấp trước.

Tác tử hỗ trợ tương tác trực tiếp với khách hàng

Dùng Sonnet.

• Cần sử dụng công cụ
• Cần kiểm soát giọng điệu
• Cần xử lý chính sách
• Cần chuyển cấp xử lý một cách phù hợp

Chỉ dùng Haiku để tiền xử lý. Dùng Opus để rà soát ở cấp giám sát đối với các trường hợp rủi ro cao.

Trợ lý rà soát mã

Dùng Sonnet để rà soát PR thông thường. Dùng Opus cho những thay đổi nhạy cảm về kiến trúc, xử lý đồng thời, bảo mật, di chuyển dữ liệu và các công việc kiểm tra tính đúng đắn đòi hỏi sự tinh tế.

Một sai lầm phổ biến là mặc định đưa toàn bộ kho mã vào mô hình. Hãy bắt đầu với phần diff, đồ thị phụ thuộc và các tệp liên quan gần đó. Chỉ chuyển lên Fable hoặc một mô hình có ngữ cảnh dài khác khi thay đổi trải rộng trên nhiều phần.

So sánh hợp đồng hoặc chính sách dài

Dùng truy xuất kết hợp với Sonnet cho các câu hỏi có phạm vi hẹp. Dùng Fable 5 khi câu hỏi bao quát toàn bộ tài liệu, chẳng hạn như “tìm tất cả các điểm mâu thuẫn giữa những tài liệu này.”

Nếu đầu ra ảnh hưởng đến một quyết định pháp lý hoặc tuân thủ thực tế, hãy dùng mô hình để chuẩn bị phân tích, không phải để đưa ra quyết định.

Làm giàu dữ liệu với khối lượng lớn

Dùng mô hình có trọng số mở nếu khối lượng lớn và tác vụ ổn định.

Ví dụ:

• Chuẩn hóa tên công ty
• Trích xuất nhãn ngành
• Phân loại khách hàng tiềm năng gửi yêu cầu đến
• Tạo bản tóm tắt nội bộ ngắn

Chạy các lô xử lý hằng đêm, kiểm tra mẫu và chuyển các trường hợp ngoại lệ sang mô hình được cung cấp dưới dạng dịch vụ.

Trợ lý nghiên cứu trên kho tài liệu lớn

Dùng Gemini 3, GPT-5.5, Opus hoặc Fable tùy theo độ dài ngữ cảnh và nhu cầu suy luận. Tôi sẽ không ưu tiên mô hình chi phí thấp trước cho việc này, trừ khi truy vấn rõ ràng là đơn giản. Sai sót trong nghiên cứu thường khó nhận thấy: mô hình đưa ra câu trả lời có vẻ hợp lý nhưng lại bỏ sót tài liệu then chốt.

Lập ngân sách mà không tự đánh lừa mình

Cách dễ nhất để chi tiêu vượt mức là tối ưu chi phí mỗi lần gọi trong khi bỏ qua các lần thử lại, việc sửa lỗi của con người và các quy trình thất bại.

Theo dõi các chỉ số sau theo loại tác vụ và mô hình:

• Token đầu vào
• Token đầu ra
• Độ trễ p50/p95
• Tỷ lệ không đạt kiểm tra hợp lệ
• Tỷ lệ chuyển cấp xử lý
• Tỷ lệ con người ghi đè kết quả
• Tỷ lệ người dùng thử lại
• Chi phí cho mỗi tác vụ thành công, không phải chi phí mỗi lần gọi

Chỉ số cuối cùng đó rất quan trọng. Một mô hình rẻ cần thử lại ba lần mà vẫn phải rà soát thủ công có thể tốn kém hơn Sonnet. Một lần gọi Opus giúp ngăn chặn một lần di chuyển dữ liệu sai có thể là quyết định tiết kiệm nhất trong tuần.

Nếu bạn dùng một cổng truy cập đa mô hình, bao gồm những giải pháp như quyền truy cập API của AI Prime Tech cho các dòng Claude, GPT và Gemini, lợi ích chính không chỉ là khả năng lựa chọn nhà cung cấp. Nó còn giúp định tuyến và đo lường dễ dàng hơn giữa các nhóm mô hình. Nhưng phần khó vẫn là thiết kế tác vụ của bạn.

Những điểm thực tiễn cần ghi nhớ

• Bắt đầu từ dạng tác vụ: chuyển đổi, trích xuất, suy luận, tổng hợp ngữ cảnh dài hoặc làm giàu dữ liệu theo lô.
• Dùng các mô hình nhóm Haiku cho công việc chi phí thấp, nhanh, có ràng buộc và có thể kiểm tra bằng các quy tắc xác định.
• Dùng các mô hình nhóm Sonnet làm lựa chọn mặc định cho các tính năng sản phẩm cần suy luận, công cụ hoặc chất lượng phù hợp để cung cấp trực tiếp cho người dùng.
• Dùng các mô hình nhóm Opus khi sai sót gây tổn thất lớn, mức độ mơ hồ cao hoặc suy luận sâu là yếu tố quan trọng.
• Dùng ngữ cảnh dài kiểu Fable 5 khi sự không chắc chắn trong truy xuất là vấn đề chính, thay vì mặc định dồn mọi nội dung vào prompt.
• Dùng các mô hình có trọng số mở khi tính ổn định của khối lượng công việc, quyền riêng tư, thông lượng hoặc khả năng kiểm soát triển khai đủ để biện minh cho việc tự vận hành suy luận.
• Xây dựng cơ chế định tuyến ưu tiên mô hình chi phí thấp trước, với các tín hiệu chuyển cấp rõ ràng: đầu ra không hợp lệ, bằng chứng yếu, công cụ thất bại, hành động rủi ro cao và sự không chắc chắn.
• Đo chi phí cho mỗi tác vụ thành công, không phải chi phí mỗi token hay mỗi lần gọi.
• Giữ bộ định tuyến đủ đơn giản để gỡ lỗi khi chịu áp lực.
• Xem việc lựa chọn mô hình là một yếu tố có thể điều chỉnh trong kỹ thuật, không phải quyết định chọn nhà cung cấp chỉ đưa ra một lần.