Có một kiểu cuộc họp đặc biệt diễn ra ở mọi đội ngũ đang xây dựng trên các LLM tuyến đầu. Ai đó chia sẻ bảng xếp hạng benchmark mới nhất. Người khác chỉ ra rằng thứ hạng đã xáo trộn so với tháng trước. Người thứ ba nhận xét rằng mô hình đội của họ hiện đang dùng đã tụt hai bậc trên một chỉ số mà ba tuần trước chẳng ai nghe tới. Kết thúc cuộc họp, không ai chắc có nên chuyển mô hình hay không, và cuộc trao đổi lại được đặt lịch cho quý sau.
Vấn đề của cuộc họp đó không nằm ở con người. Mà là ở chỗ benchmark đo các tác vụ tổng hợp, còn sản phẩm của bạn thì không. Bảng xếp hạng cho bạn biết một mô hình thể hiện ra sao trên MMLU, trên SWE-bench Verified, trên GPQA Diamond — những bài kiểm tra do nhà nghiên cứu thiết kế để có thể đo lường giữa các mô hình. Không bài nào trong số đó giống các prompt ứng dụng của bạn thực sự gửi trong môi trường sản xuất. Không bài nào nắm bắt được cách mô hình xử lý kiểu đầu vào bừa bộn, mang hình hài miền nghiệp vụ mà người dùng của bạn tạo ra.
Bài viết này hướng dẫn đúng bài tập mà benchmark không thể làm. Ba prompt cụ thể, được thiết kế để gửi tới GPT-5.5, Claude Sonnet 4.6 và Gemini 3.1 Pro thông qua cùng một endpoint tương thích OpenAI, với cùng thiết lập temperature và không có nhắc lệnh bổ sung. Các prompt trải rộng ba hạng mục chạm tới phần lớn khối lượng công việc trong sản xuất: trích xuất có cấu trúc từ tài liệu lộn xộn, một tác vụ lập kế hoạch đòi hỏi lý luận nặng, và tạo mã dưới các ràng buộc. Các quan sát dưới đây là những mẫu hành vi mà các đội ngũ chạy kiểu so sánh này thường xuyên báo cáo — những mẫu bạn sẽ tự mình thấy nếu chạy các prompt này trên hệ thống của bạn.
Trên bảng xếp hạng, ba mô hình này chênh nhau trong 0.8 điểm phần trăm trên SWE-bench Verified. Trên thực tế, chúng hành xử rất khác nhau. Việc lựa chọn giữa chúng không phải về mô hình nào đạt điểm cao hơn trên benchmark — mà là về mẫu hành vi nào phù hợp với khối lượng công việc của bạn.
Benchmark đo gì, và bỏ sót gì
Benchmark tồn tại vì chúng buộc phải có. Nhà cung cấp mô hình cần bài kiểm tra tiêu chuẩn để đưa ra tuyên bố năng lực, nhà nghiên cứu cần chúng để công bố so sánh, và phần còn lại của chúng ta cần chúng để có bất kỳ điểm khởi đầu khách quan nào để đánh giá mô hình. Chúng hữu ích. Nhưng chúng cũng không đầy đủ theo những cách quan trọng đối với sử dụng trong sản xuất.
Ba hạn chế cụ thể đáng nói rõ, vì mỗi cái đều xuất hiện trong các ví dụ prompt bên dưới.
- Benchmarks đo năng lực cô lập, không đo mẫu hành vi. SWE-bench Verified cho bạn biết liệu một mô hình có giải được một loại issue GitHub cụ thể hay không. Nó không cho bạn biết liệu mô hình có xu hướng “over-engineer” các vấn đề đơn giản, liệu nó có đặt câu hỏi làm rõ khi prompt mơ hồ, hoặc liệu nó có tạo ra đầu ra khớp cấu trúc bạn yêu cầu ngay lần đầu không. Đây là những điều bạn sẽ quan sát hằng ngày trong sản xuất.
- Benchmarks bị tinh chỉnh hướng tới. Khi một bản phát hành mô hình nổi bật với điểm số trên một benchmark cụ thể, đó là tín hiệu rằng mô hình ít nhất phần nào được tối ưu cho benchmark đó. Hiệu năng thực tế và hiệu năng benchmark có thể khác nhau — đôi khi đáng kể — một khi mô hình rời khỏi các điều kiện mà benchmark được thiết kế cho.
- Benchmarks tổng hợp. Chênh lệch 0.8 điểm phần trăm trong điểm SWE-bench Verified có thể che giấu thực tế rằng Mô hình A tốt hơn nhiều ở một danh mục nhiệm vụ cụ thể và tệ hơn ở danh mục khác, trong khi Mô hình B đồng đều trên toàn bộ. Việc tổng hợp làm co lại thông tin bạn cần để quyết định.
Bài tập dưới đây được thiết kế để làm lộ đúng loại thông tin mà benchmark gộp lại làm mất. Mục đích không phải để tuyên bố người thắng — mà là chỉ cho bạn các câu hỏi bạn nên đặt ra khi chạy cùng bài tập đó trên chính các prompt của bạn.
Thiết lập
Ba prompt, được chọn vì chúng ánh xạ tới các hạng mục mà hầu hết khối lượng công việc trong sản xuất gặp phải. Thiết lập: mỗi prompt được gửi tới cả ba mô hình với các tham số giống nhau (temperature 0.3, không ghi đè system prompt, định dạng phản hồi mặc định), truy cập qua một endpoint tương thích OpenAI duy nhất để so sánh “táo–táo” — không quirks SDK theo nhà cung cấp, không khác biệt ánh xạ tham số, không có rủi ro một mô hình được đối xử đặc biệt vì cách dựng yêu cầu.
Các prompt tự thân ở bên dưới, dưới dạng code block bạn có thể copy và chạy. Các mô tả hành vi theo sau mỗi prompt là những mẫu mà các đội ngũ nhất quán báo cáo khi chạy kiểu so sánh này — các mẫu được ghi nhận qua nhiều nghiên cứu bên thứ ba trong năm 2026, và là thứ bạn nên kỳ vọng sẽ tự thấy khi chạy các prompt này trên hệ thống của bạn. Tự chạy mới là mục tiêu; bài viết tồn tại để cung cấp khung tư duy và prompt khởi đầu cho bạn làm điều đó.
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["COMET_API_KEY"], # or replace with your API key
base_url="https://api.cometapi.com/v1", # one endpoint, multiple models
)
MODELS = [
"gpt-5.5",
"claude-sonnet-4-6",
"gemini-3.1-pro",
]
def run_comparison(prompt: str, temperature: float = 0.3) -> dict[str, str]:
"""
Send the same prompt to all three models and return their responses.
"""
responses = {}
for model in MODELS:
result = client.chat.completions.create(
model=model,
messages=[
{
"role": "user",
"content": prompt,
}
],
temperature=temperature,
)
responses[model] = result.choices[0].message.content
return responses
# Example usage
if __name__ == "__main__":
prompt = "Summarise the key risks in this contract."
outputs = run_comparison(prompt)
for model, response in outputs.items():
print(f"\n--- {model} ---")
print(response)
Lời nhắc 1: Trích xuất có cấu trúc từ tài liệu lộn xộn
Đây là tác vụ “cơm áo gạo tiền” của nửa số tính năng LLM ra mắt năm 2026. Lấy đầu vào phi cấu trúc — email, phiếu hỗ trợ, biên bản họp, biểu mẫu quét — và trích xuất các trường cụ thể thành một đối tượng có cấu trúc. Prompt dưới đây yêu cầu mỗi mô hình trích xuất bảy trường từ một email hỗ trợ khách hàng cố tình lộn xộn, chứa thông tin không đầy đủ, tín hiệu mâu thuẫn, và một trường không hề có trong văn bản nguồn.
Đề bài
You are processing customer support emails. Extract the followingseven fields from the email below into a JSON object with exactlythese keys: - customer_name (string)- order_id (string)- issue_type (one of: "shipping", "product_quality", "billing", "returns", "other")- urgency (one of: "low", "medium", "high")- requested_action (string)- affected_product (string)- escalation_history (any prior contact about this issue, if mentioned)
Email:---Hi there, I'm writing about order #FT-2289334 from last Tuesday. The Cascadehiking boots I received are NOT the size 11 I ordered — they'reclearly size 10 (I can see the label inside). I have a guided trekbooked in 5 days and I genuinely don't know what to do. I've beena customer for years and this is the first time something likethis has happened. Can you sort this out urgently? I'd prefer a same-day exchange ifat all possible. I'm in Manchester. Margaret W.--- Return only the JSON object. No commentary, no markdown code fences.
Cần theo dõi
Ba điều. Thứ nhất, liệu mô hình tuân thủ lược đồ JSON yêu cầu mà không tự bịa. Thứ hai, cách mô hình xử lý trường không tồn tại trong nguồn (escalation_history — khách hàng không đề cập liên hệ trước đó về vấn đề này) — có thừa nhận là không có hay bịa một cách “có vẻ hợp lý”? Thứ ba, liệu mô hình có sinh thêm diễn giải ngoài JSON, khiến hậu xử lý phải tước bỏ phần bao ngoài. Trường urgency cũng đáng chú ý: “5 ngày” không là tức thì nhưng khách hàng rõ ràng lo lắng, nên còn dư địa diễn giải.
Những gì các đội ngũ chạy bài này thường báo cáo
- GPT-5.5. Thường tạo JSON sạch ngay lần đầu. Mức tuân thủ lược đồ tốt; đủ mọi trường yêu cầu, và định dạng có thể parse không cần tiền xử lý. Với trường thiếu, GPT-5.5 có xu hướng trả về null rõ ràng. Thường không bọc JSON trong code fence markdown hoặc kèm giải thích văn bản, giúp việc parse phía sau rất đơn giản. Với các phán đoán mơ hồ như đánh giá mức độ khẩn ở đây, GPT-5.5 thường thận trọng hơn hai mô hình kia — nơi Claude và Gemini có thể đánh “high” dựa trên cảm xúc của khách hàng, GPT-5.5 hay bám vào mốc 5 ngày và chọn “medium”.
- Claude Sonnet 4.6. Cũng tạo JSON sạch, và thường chính xác nhất trong việc tuân lược đồ. Nơi GPT-5.5 để trường thiếu là null, Claude thường thêm các trường không được yêu cầu để gắn cờ vấn đề chất lượng dữ liệu — một khóa “notes” hoặc “data_quality_notes” không được hỏi nhưng chứa thông tin hữu ích thật sự. Trường bổ sung đó hữu ích cho người duyệt thủ công nhưng gây lỗi nếu parser phía sau nghiêm ngặt về lược đồ. Đây là mẫu lặp lại của Claude: chất lượng cao, nhưng đôi khi “kỹ lưỡng hơn” yêu cầu, cần chỉ dẫn ràng buộc rõ ràng trong prompt.
- Gemini 3.1 Pro. Thường tạo đầu ra gọn nhất trong ba mô hình. Đủ mọi trường yêu cầu, không thêm trường, không có văn bản bao quanh. Tuân thủ lược đồ đúng như yêu cầu. Một nét riêng cần biết: với trường thiếu, Gemini có xu hướng trả về chuỗi rỗng thay vì null. Các parser JSON chặt chẽ phân biệt điều này sẽ phát hiện; parser “lỏng” thì không. Hành vi này đủ nhất quán qua các lần chạy cho thấy đây là sở thích của mô hình hơn là tạo tác ngẫu nhiên.
Điều này cho bạn biết
Cả ba mô hình đều làm được trích xuất có cấu trúc. Khác biệt nằm ở “viền hành vi” quanh lược đồ yêu cầu. Nếu hệ thống phía sau nghiêm ngặt về lược đồ và xem trường bổ sung là lỗi, Gemini 3.1 Pro và GPT-5.5 an toàn hơn. Nếu bạn muốn mô hình tự nêu vấn đề chất lượng dữ liệu dù không được hỏi, Claude Sonnet 4.6 hữu ích hơn. Không điều nào trong số này xuất hiện trên benchmark.
Lời nhắc 2: Một tác vụ lập kế hoạch đòi hỏi lý luận nặng
Prompt này yêu cầu mô hình lập kế hoạch điều tra nhiều bước: một câu hỏi nghiên cứu với ba ràng buộc ngầm mà một mô hình cẩn trọng nên xác định trước khi xếp trình tự công việc. Loại tác vụ mà một ứng dụng tác tử sẽ ủy quyền cho LLM như bước lập kế hoạch trước khi gọi bất kỳ công cụ nào.
Đề bài
I'm trying to answer this research question for my team: "Is our customer churn rate higher among users who haven't usedfeature X in the last 30 days?" Produce a plan for how to investigate this. The plan should:- Identify the steps required- Sequence them with dependencies- Be actionable for a data analyst on my team Return the plan in clear, structured form.
Các ràng buộc ngầm đáng theo dõi: câu hỏi không định nghĩa “churn” là gì (đóng tài khoản? không đăng nhập? không mua hàng?), không chỉ định cách kiểm soát biến gây nhiễu (người dùng ít tương tác rời bỏ vì nhiều lý do không liên quan tới tính năng X), và không thiết lập nhóm đối chứng cơ bản. Một người lập kế hoạch cẩn trọng nên nêu đủ ba điều trước khi đề ra các bước.
Cần theo dõi
Liệu mô hình thực sự lý luận qua vấn đề hay chỉ tạo một chuỗi bước “trông hợp lý” nhưng không đứng vững khi kiểm tra. Liệu nó có nhận diện các ràng buộc ngầm mà không cần gợi ý. Và liệu phụ thuộc giữa các bước có đúng — một kế hoạch nhìn ổn nhưng bước ba lại phụ thuộc kết quả của bước năm thì vô dụng trong thực tế.
Những gì các đội ngũ chạy bài này thường báo cáo
- GPT-5.5. Thường tạo kế hoạch vận hành được nhất. Lý luận có thể “nhìn thấy” — GPT-5.5 liệt kê giả định của nó về các ràng buộc ngầm (định nghĩa churn, nhóm đối chứng, biến gây nhiễu) trước khi đưa ra các bước, giúp dễ nhận ra chỗ giải thích của mô hình khác với ý định. Phụ thuộc giữa bước được nhận diện và gắn nhãn đáng tin cậy. Đầu ra thường có một mục chỉ ra bước nào có thể chạy song song, dù không được yêu cầu nhưng thêm giá trị thực sự. Đây là kiểu tác vụ nơi đào tạo về sử dụng công cụ và tác tử của GPT-5.5 bộc lộ — hành vi lập kế hoạch được định hình bởi giả định rằng sẽ có thực thi phía sau.
- Claude Sonnet 4.6. Thường tạo kế hoạch “nghĩ sâu” nhất theo nghĩa đen — kế hoạch của Claude thường nêu những cân nhắc mà hai mô hình kia không đề cập. Với câu hỏi này, Claude có thể gắn cờ vấn đề phương pháp giữa tương quan và nhân quả, lưu ý rằng “chưa dùng tính năng X” có thể là triệu chứng của churn chứ không phải nguyên nhân, và rõ ràng xác định các ràng buộc không được nói ra nhưng một nhà phân tích cẩn trọng nên phát hiện. Điểm trừ: kế hoạch có thể dài hơn cần thiết, và một số bước đôi khi “over-engineered” so với câu hỏi thực tế. Mẫu này nhất quán với hành vi của Claude ở nơi khác — mức độ chăm chút chuyên gia, đôi khi hơn mức nhiệm vụ yêu cầu.
- Gemini 3.1 Pro. Thường tạo kế hoạch có cấu trúc sạch nhất, với đồ thị phụ thuộc rõ ràng nhất. Chất lượng lý luận cao — Gemini ổn định nhận diện các ràng buộc ngầm, phân rã vấn đề thành một trình tự có thể bảo vệ, và đưa ra hướng dẫn từng bước có thể thực thi. Hạn chế: kế hoạch có thể đọc hơi “cơ khí”. Nó hoàn thành công việc nhưng ít nêu các tinh tế phương pháp học như Claude, cũng không có insight về song song hóa như GPT-5.5. Điều này khớp với mẫu rộng hơn của Gemini — mạnh về lý luận, thực dụng về các phán đoán xung quanh.
Điều này cho bạn biết
Chất lượng lý luận trên tác vụ này cao ở cả ba mô hình. Khác biệt nằm ở hành vi xung quanh — những gì mô hình thêm ngoài yêu cầu chữ nghĩa. GPT-5.5 thêm tính thực dụng vận hành (song song hóa, gợi ý thực thi). Claude thêm sự chăm chút cấp chuyên gia (phương pháp, cạnh biên, tinh tế thống kê). Gemini thêm sự rõ ràng và tiết kiệm. Không lựa chọn nào là sai. Mô hình nào phù hợp với ứng dụng của bạn phụ thuộc vào việc bạn muốn mô hình làm gì khi nó đã hoàn tất tác vụ bạn yêu cầu.
Lời nhắc 3: Tạo mã với các ràng buộc cụ thể
Prompt này yêu cầu các mô hình hiện thực một hàm nhỏ nhưng không tầm thường: một hàm Python nhận danh sách sự kiện có timestamp và trả về khoảng trống dài nhất giữa các sự kiện liên tiếp, xử lý bốn trường hợp biên. Ràng buộc đã nêu rõ; ý định là kiểm tra tạo mã dưới ràng buộc hơn là trần năng lực — mô hình nào cũng viết được hàm này. Khác biệt là cách họ xử lý ràng buộc.
Đề bài
Write a Python function that takes a list of timestamped events andreturns the longest gap (in seconds) between consecutive events. Requirements:- Function signature: longest_gap(events: list[datetime]) -> float- Handle these edge cases: 1. Empty list (return 0.0 or raise — your choice, but be consistent) 2. Single event 3. Duplicate timestamps 4. Unsorted input- Use only the standard library- Include type hints- Return just the function. No tests or usage examples.
Cần theo dõi
Liệu mô hình xử lý cả bốn trường hợp biên hay lặng lẽ bỏ sót. Liệu type hint chính xác hay chung chung. Liệu hiện thực chọn giải thuật có thể bảo vệ (sort rồi scan) hay cái gì “kỳ lạ”. Và liệu mô hình tôn trọng ràng buộc “không test, không ví dụ sử dụng” ở cuối prompt — đây là kiểu chỉ dẫn cuối prompt mà các mô hình theo chỉ dẫn mạnh sẽ tuân thủ còn mô hình yếu hơn sẽ lặng lẽ vi phạm.
Những gì các đội ngũ chạy bài này thường báo cáo
- GPT-5.5. Thường tạo mã được kỹ sư hóa kỹ lưỡng nhất. Cả bốn trường hợp biên được xử lý với nhánh rõ ràng, type hint chính xác (thường có Optional hoặc Union cho giá trị trả về ở trường hợp biên), và docstring với ví dụ gọi. Hiện thực thường chọn giải thuật hiển nhiên — sort, scan, theo dõi khoảng trống lớn nhất — và là đúng. Lưu ý: GPT-5.5 thường kèm unit test hoặc ví dụ sử dụng ngay cả khi prompt yêu cầu chỉ trả về hàm. Đây là đánh đổi với các mô hình thiên về thực dụng vận hành — chúng thêm thứ chúng nghĩ bạn cần, ngay cả khi bạn yêu cầu đừng làm.
- Claude Sonnet 4.6. Thường tạo mã dễ đọc nhất. Hàm gọn, trường hợp biên xử lý bằng mẫu guard clause ở đầu, type hint chính xác và tối giản. Claude thường thêm bình luận có cân nhắc giải thích một lựa chọn phán đoán mà prompt để mở — ví dụ, với timestamp trùng, xem chúng như khoảng trống độ dài 0 và giải thích lý do, một lựa chọn có thể bảo vệ dù prompt không quy định. Claude có xu hướng tôn trọng ràng buộc “không test” đáng tin cậy hơn GPT-5.5. Bản thân hàm dễ bảo trì nhất trong ba. Nhất quán với danh tiếng về chất lượng mã của Claude: sạch, idiomatic, đậm chất chuyên gia.
- Gemini 3.1 Pro. Thường tạo mã gọn nhất trong ba. Hàm đúng, xử lý trường hợp biên, hiện thực ngắn nhất. Docstring thường một dòng. Type hint đầy đủ và chính xác. Giải pháp của Gemini hiếm khi kèm test hoặc bình luận dài, và không “over-engineer” — đúng như prompt yêu cầu. Với lập trình viên muốn một hàm chạy được và dự định bổ sung test sau, đây là con đường trực diện nhất. Với lập trình viên muốn mô hình làm cả phần việc xung quanh, hai mô hình kia bổ sung nhiều hơn (dù bạn có yêu cầu hay không).
Điều này cho bạn biết
Cả ba mô hình đều viết được hàm. Khác biệt hành vi nằm ở việc mỗi mô hình thêm bao nhiêu “việc xung quanh” ngoài yêu cầu chữ nghĩa — và mỗi mô hình tôn trọng các chỉ dẫn “không làm X” rõ ràng tốt đến đâu. GPT-5.5 nghiêng về kỹ lưỡng, ngay cả khi prompt đã miễn trừ sự kỹ lưỡng. Claude nghiêng về tay nghề (mã dễ đọc, bình luận thấu đáo về quyết định phán đoán). Gemini nghiêng về tối giản (làm đúng những gì được yêu cầu, không hơn). Với quy trình tác tử nơi đầu ra của mô hình đi thẳng vào codebase sản xuất, hành vi bạn muốn phụ thuộc vào việc quy trình review phía sau kỳ vọng gì — và bạn cần mô hình tuân thủ nghiêm thế nào với chỉ dẫn phủ định.
Những mẫu nổi lên
Xuyên suốt ba prompt trên, ba mẫu hành vi nhất quán nổi lên từ các nghiên cứu so sánh và báo cáo của nhà phát triển công bố trong năm 2026. Đây không phải là tuyên bố năng lực — mô hình nào cũng xử lý tốt mọi tác vụ. Chúng là khuynh hướng, kiểu thứ bạn chỉ thấy khi các đội ngũ quan sát cùng một mô hình xử lý hàng chục prompt. Hãy chạy các prompt trên hệ thống của bạn và bạn sẽ thấy cùng các mẫu đó; bài viết tồn tại để đưa cho bạn khung nhận diện điều bạn đang thấy khi làm vậy.
| Model | Khuynh hướng hành vi | Phù hợp nhất khi… |
|---|---|---|
| GPT-5.5 | Thực dụng vận hành. Thêm gợi ý thực thi, coding phòng thủ, và đầu ra thân thiện với bước sau. Mạnh ở tác vụ định hình bởi tác tử và sử dụng công cụ. | Ứng dụng của bạn xâu chuỗi đầu ra của mô hình vào thực thi tiếp theo — tác tử, workflow, hoặc pipeline nơi bước kế tiếp được tự động hóa. |
| Claude Sonnet 4.6 | Chăm chút cấp chuyên gia. Nêu các cân nhắc vượt ngoài yêu cầu chữ nghĩa, đưa ra quan ngại đạo đức và phương pháp, tạo mã rất dễ đọc. | Ứng dụng của bạn có con người duyệt đầu ra của mô hình — tạo nội dung, review mã, phân tích nơi tay nghề quan trọng. |
| Gemini 3.1 Pro | Tối giản và trực diện. Làm đúng những gì được yêu cầu, không hơn. Tuân lược đồ sạch nhất và lượng token thấp nhất cho khối lượng công việc tương đương. | Ứng dụng của bạn yêu cầu đầu ra nghiêm ngặt, chi phí dự đoán được là ưu tiên, hoặc bạn muốn mô hình là công cụ chính xác hơn là cộng sự biết suy xét. |
Một lưu ý quan trọng. Những mẫu này là khuynh hướng, không phải quy tắc. Mỗi mô hình có thể được steer tới bất kỳ hành vi nào trong số này với nhắc lệnh phù hợp — một system prompt đủ chi tiết sẽ khiến Gemini thêm test, hoặc ràng buộc Claude chỉ cho ra tối thiểu, hoặc bảo GPT-5.5 bỏ qua unit test. Điểm mấu chốt là từng mô hình làm gì theo mặc định, trước khi bạn bắt đầu “lái”. Hành vi mặc định là thứ bạn phải sống chung trong sản xuất trừ khi bạn chủ động nhắc chống lại nó.
Cách kiểm thử trên khối lượng công việc của riêng bạn
Bài tập trên có thể tái lập trên bất kỳ khối lượng công việc nào, và nên được làm. Điểm benchmark hữu ích như bộ lọc đầu tiên, nhưng các mẫu hành vi quan trọng cho ứng dụng cụ thể của bạn chỉ thấy được khi bạn quan sát các mô hình xử lý prompt cụ thể của bạn.
Hướng dẫn thực tế để chạy bài tập trên traffic của bạn:
- Chọn ba danh mục prompt đại diện. Không phải ba prompt ngẫu nhiên — ba danh mục trải rộng khối lượng công việc. Hầu hết hệ thống sản xuất có thể phân rã thành một vài loại prompt (trích xuất, phân loại, tạo sinh, lý luận, mã, tóm tắt). Chọn các danh mục chiếm phần lớn traffic của bạn.
- Chắt lọc 20–30 ví dụ mỗi danh mục. Tốt nhất lấy từ traffic thực. Ẩn danh nếu cần. Mục tiêu là prompt phải trông như những gì ứng dụng của bạn thực sự thấy, không như câu hỏi benchmark. Hai mươi ví dụ mỗi danh mục đủ để thấy mẫu; ba mươi là đủ để tự tin.
- Chạy chúng qua một endpoint, cho tất cả mô hình. Một endpoint tổng hợp tương thích OpenAI sẽ giúp việc này nhanh hơn nhiều so với chạy mỗi mô hình qua SDK riêng. Đoạn code ở đầu bài là toàn bộ thiết lập. Cùng temperature, cùng tham số, cùng prompt — khác biệt ở đầu ra là khác biệt mô hình.
- Chấm điểm định tính trước định lượng. Hãy “soi” đầu ra trước. Các mẫu hành vi thường rõ ràng trong chục prompt đầu tiên. Khi bạn có giả thuyết về cách mỗi mô hình hành xử trên khối lượng công việc của bạn, lúc đó hãy xây rubric để chấm — nhưng giả thuyết đến từ quan sát, không từ mẫu chấm dựng sẵn.
- Chú ý điều mô hình thêm vào. Câu hỏi benchmark là liệu mô hình có cho đáp án đúng. Câu hỏi hành vi là mô hình còn làm gì nữa. Nó có thêm test không? Nó có giải thích lý do không? Nó có nêu quan ngại không? Nó có sinh thêm trường bạn không yêu cầu không? Khác biệt giữa mô hình nằm ở đây.
- Chọn mô hình khớp với mẫu phía sau của bạn. Nếu quy trình phía sau được tự động hóa, bạn muốn một mô hình có hành vi mặc định tạo đầu ra sạch, có thể parse. Nếu quy trình phía sau là con người duyệt, bạn muốn mô hình có hành vi mặc định thêm kiểu phán đoán xung quanh mà người duyệt muốn thấy. Đáp án đúng phụ thuộc vào việc điều gì đến sau mô hình.
Kết luận
Lựa chọn giữa GPT-5.5, Claude Sonnet 4.6 và Gemini 3.1 Pro không phải về mô hình nào tốt nhất. Mà là về mô hình nào khớp với hình dáng khối lượng công việc của bạn — và hình dáng đó là thứ benchmark không thể thấy. Bài tập trên có thể làm xong trong một buổi chiều nếu bạn đã chắt lọc prompt; giá trị của việc làm nó là bạn dừng phỏng đoán và bắt đầu quan sát.
Dành cho các đội tự chạy bài tập: thiết lập dễ nhất là một endpoint tương thích OpenAI duy nhất phơi bày cả ba mô hình sau một thông tin xác thực. CometAPI là một con đường; bạn trỏ SDK OpenAI hiện có của bạn tới một base URL khác và tham số model trở thành biến số.
Benchmark cho bạn biết một mô hình có thể làm gì. Mẫu hành vi cho bạn biết một mô hình sẽ làm gì, theo mặc định, trên các prompt của bạn. Câu trả lời đầu tiên đã được công bố. Câu thứ hai bạn phải tự quan sát. Hai mươi prompt mỗi danh mục, một buổi chiều, và bạn có câu trả lời mà không bảng xếp hạng nào từng đưa ra.
Sẵn sàng tích hợp đáng tin cậy? Truy cập CometAPI và API doc để có quyền truy cập liền mạch Claude Fable 5 cùng các mô hình tuyến đầu khác, thanh toán hợp nhất và độ tin cậy cấp doanh nghiệp. Đăng ký ngay hôm nay và bắt đầu với ưu đãi credit hào phóng cho người dùng mới — dự án đột phá tiếp theo của bạn đang chờ đón.