Có một kiểu họp rất điển hình diễn ra trong 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. 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 lưu ý rằng mô hình đội họ đang dùng hiện tại đã tụt hai bậc trên một chỉ số mà ba tuần trước không ai trong họ từng nghe tới. Kết thúc buổi họp, chẳng ai chắc có nên chuyển đổi hay không, và cuộc trao đổi lại được lên lịch cho quý sau.
Vấn đề của cuộc họp đó không nằm ở con người. Mà là benchmark đo lường các tác vụ tổng hợp, còn sản phẩm của bạn thì không phải tác vụ tổng hợp. Bảng xếp hạng cho bạn biết một mô hình thể hiện thế nào trên MMLU, trên SWE-bench Verified, trên GPQA Diamond — các bài kiểm tra do nhà nghiên cứu thiết kế để có thể đo được giữa các mô hình. Không bài nào trong số đó giống những prompt mà ứ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ột mô hình xử lý kiểu đầu vào lộn xộn, mang dấu ấn miền nghiệp vụ mà người dùng của bạn tạo ra.
Bài viết này đi qua đúng bài tập mà benchmark không làm được. Ba prompt cụ thể, được thiết kế để gửi tới GPT-5.5, Claude Sonnet 4.6 và Gemini 3.1 Pro qua cùng một endpoint tương thích OpenAI, với cùng thiết lập nhiệt độ và không có prompt bổ sung. Các prompt trải rộng ba danh mục chạm tới phần lớn khối lượng công việc 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 nặng suy luận, và tạo mã dưới các ràng buộc. Những quan sát dưới đây là các kiểu hành vi mà các đội chạy kiểu so sánh này báo cáo nhất quán — các kiểu bạn sẽ tự thấy nếu chạy những prompt này trên thiết lập của chính bạn.
Trên bảng xếp hạng, ba mô hình này chênh nhau trong vòng 0.8 điểm phần trăm trên SWE-bench Verified. Trong thực tế, chúng hành xử rất khác nhau. Lựa chọn giữa chúng không phải là chọn mô hình nào điểm benchmark cao nhất — mà là mô hình nào có kiểu hành vi 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 bắt buộc phải có. Nhà cung cấp mô hình cần các bài kiểm tra tiêu chuẩn để đưa ra tuyên bố về 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ó điểm xuất phát khách quan khi đánh giá mô hình. Chúng hữu ích. Chúng cũng không đầy đủ theo những cách quan trọng đối với dùng trong sản xuất.
Ba hạn chế cụ thể đáng nêu rõ, vì mỗi cái đều xuất hiện trong các ví dụ prompt dưới đây.
- Benchmark đo lường năng lực cô lập, không phải kiểu hành vi. SWE-bench Verified cho bạn biết liệu một mô hình có thể giải được một kiểu issue trên GitHub. Nó không cho bạn biết mô hình có xu hướng “làm quá” các vấn đề đơn giản hay không, liệu nó có hỏi câu làm rõ khi prompt mơ hồ, hoặc liệu nó có tạo đầu ra đúng cấu trúc bạn yêu cầu ngay lần đầu. Đây là những điều bạn sẽ quan sát hàng ngày trong sản xuất.
- Benchmark bị “tối ưu vào”. 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 đã được tối ưu ít nhất một phần cho benchmark đó. Hiệu suất thế giới thực và hiệu suất trên benchmark có thể lệch nhau — đôi khi đáng kể — khi mô hình rời khỏi điều kiện mà benchmark được thiết kế cho.
- Benchmark tính gộp. Chênh lệch 0.8 điểm phần trăm trong điểm SWE-bench Verified có thể che giấu việc Mô hình A tốt hơn nhiều ở một hạng mục cụ thể và kém hơn ở hạng mục khác, trong khi Mô hình B lại ổn định trên toàn bộ. Việc gộp làm sụt thông tin bạn cần để ra quyết định.
Bài tập dưới đây được thiết kế để bộc lộ chính kiểu thông tin mà benchmark gộp vào và làm mất dấu. Mục đích không phải để tuyên bố người thắng — mà là chỉ cho bạn những 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 danh mục mà hầu hết khối lượng công việc sản xuất chạm tới. Thiết lập: mỗi prompt được gửi tới cả ba mô hình với tham số giống hệt nhau (temperature 0.3, không override 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 giữ được tính “táo so với táo” — không rắc rối SDK riêng của nhà cung cấp, không khác biệt ánh xạ tham số, không rủi ro một mô hình được đối xử đặc biệt do cách xây dựng request.
Các prompt nằm bên dưới, ở dạng code block bạn có thể sao chép và chạy. Các mô tả hành vi theo sau mỗi prompt là những kiểu mẫu mà các đội nhất quán báo cáo khi chạy kiểu so sánh này — các kiểu mẫu được ghi nhận trong nhiều nghiên cứu bên thứ ba năm 2026, và là những gì bạn có thể kỳ vọng sẽ tự thấy khi chạy các prompt này trên thiết lập của mình. Việc tự chạy là trọng tâm; bài viết tồn tại để cho bạn khung tư duy và các prompt khởi đầu để 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)
Prompt 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 một nửa tính năng LLM ra mắt năm 2026. Lấy một đầu vào không có 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 bên dưới 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 một phần, tín hiệu mâu thuẫn và một trường không hề có trong văn bản nguồn.
Prompt
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 chú ý điều gì
Ba điều. Thứ nhất, liệu mô hình tuân thủ lược đồ JSON được yêu cầu mà không bịa đặt. 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 đó cho vấn đề này) — nó thừa nhận sự vắng mặt, hay chế tác “hợp lý”? Thứ ba, liệu mô hình có tạo thêm chú thích bên ngoài JSON, khiến quá trình phân tích downstream phải loại bỏ phần bọc. Trường urgency cũng đáng lưu ý: “5 ngày” không phải tức thời nhưng khách hàng rõ ràng lo lắng, để lại khoảng không cho cách diễn giải.
Những gì các đội chạy thử nghiệm này báo cáo nhất quán
GPT-5.5. Thường tạo JSON sạch ngay lần đầu. Tuân thủ lược đồ mạnh; mọi trường được yêu cầu đều có mặt, và định dạng có thể phân tích mà không cần tiền xử lý. Với các trường thiếu, GPT-5.5 có xu hướng trả về null rõ ràng. Nó thường không bọc JSON trong code fence markdown hay chèn giải thích bằng văn xuôi, giúp parsing downstream đơn giản. Với các đánh giá mơ hồ như mức độ khẩn ở đây, GPT-5.5 có xu hướng thận trọng hơn hai mô hình còn lại — nơi Claude và Gemini có thể đánh giá ticket “high” dựa trên cảm xúc của khách hàng, GPT-5.5 thường neo vào mốc cụ thể 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 ba mô hình khi tuân theo lược đồ được yêu cầu. 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 key “notes” hoặc “data_quality_notes” không được hỏi đến nhưng chứa thông tin thực sự hữu ích. Trường bổ sung đó hữu ích cho người rà soát nhưng gây lỗi nếu trình phân tích downstream của bạn nghiêm ngặt về lược đồ. Đây là mô thức lặp lại với Claude: chất lượng cao, nhưng đôi khi kỹ lưỡng hơn yêu cầu, cần chỉ dẫn prompt rõ ràng để ràng buộc.
Gemini 3.1 Pro. Thường tạo đầu ra tiết kiệm nhất trong ba. Mọi trường được yêu cầu, không có trường thừa, không có văn xuôi xung quanh. Tuân thủ lược đồ đúng như yêu cầu. Một điểm lạ đáng biết: với các trường thiếu, Gemini có xu hướng trả về chuỗi rỗng thay vì null. Trình phân tích JSON nghiêm ngặt phân biệt hai điều này sẽ phát hiện khác biệt; trình lỏng lẻo thì không. Hành vi đủ nhất quán giữa các lần chạy để có vẻ là sở thích của mô hình hơn là hiện tượng ngẫu nhiên.
Điều này cho bạn biết gì
Cả ba mô hình đều có thể trích xuất có cấu trúc. Khác biệt nằm ở rìa hành vi quanh lược đồ yêu cầu. Nếu hệ thống downstream của bạn nghiêm ngặt về lược đồ và coi trường thừa là lỗi, Gemini 3.1 Pro và GPT-5.5 là lựa chọn an toàn hơn. Nếu bạn muốn mô hình nêu bật vấn đề chất lượng dữ liệu mà không cần yêu cầu, Claude Sonnet 4.6 hữu ích hơn. Không điều nào trong số này hiện lên trên benchmark.
Prompt 2: Một tác vụ lập kế hoạch nặng suy luận
Prompt này yêu cầu các mô hình lập kế hoạch cho một cuộc đ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 sắp xếp công việc. Kiểu tác vụ mà một ứng dụng agentic 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.
Prompt
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 chú ý: 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ỉ rõ cách kiểm soát biến gây nhiễu (người dùng tương tác thấp rời bỏ vì nhiều lý do không liên quan tới feature X), và không thiết lập nhóm so sánh chuẩn. Một người lập kế hoạch cẩn trọng nên nêu cả ba trước khi đưa ra các bước.
Cần chú ý điều gì
Liệu mô hình thực sự suy luận qua vấn đề hay 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ó xác định các ràng buộc ngầm mà không được chỉ ra. Và liệu sự phụ thuộc giữa các bước có chính xác — một kế hoạch nhìn ổn nhưng bước ba lại phụ thuộc vào kết quả mà bước năm mới tạo ra thì vô dụng trong thực tế.
Những gì các đội chạy thử nghiệm này báo cáo nhất quán
GPT-5.5. Thường tạo kế hoạch vận hành được nhất. Lý luận có xu hướng hiện rõ — 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 trình bày các bước, giúp dễ phát hiện nơi cách hiểu của nó khác với ý định. Phụ thuộc giữa các bước được xác định và gắn nhãn đáng tin cậy. Đầu ra thường có phần đánh dấu bước nào có thể chạy song song, điều không được yêu cầu nhưng thêm giá trị thực. Đây là kiểu tác vụ nơi việc huấn luyện về tool-use và agentic của GPT-5.5 biểu hiện — hành vi lập kế hoạch được định hình bởi giả định rằng sẽ có thực thi downstream theo sau.
Claude Sonnet 4.6. Thường tạo kế hoạch “sâu sắc” nhất theo nghĩa đen — kế hoạch của Claude thường bao gồm các cân nhắc mà hai mô hình kia không nêu. Với câu hỏi như thế này, Claude có khả năng nêu vấn đề phương pháp luận giữa tương quan và nhân quả, lưu ý rằng “chưa dùng feature 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 nhận ra. Điểm trừ: kế hoạch có thể dài hơn cần thiết, và từng bước đôi khi “quá kỹ” so với câu hỏi thực tế. Mô thức phù hợp với hành vi khác của Claude — sự cẩn trọng cấp chuyên gia, đôi khi vượt quá 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 suy luận cao — Gemini ổn định xác định các ràng buộc ngầm, phân rã vấn đề thành một chuỗi có thể bảo vệ được, và đưa ra các chỉ dẫn từng bước có thể triển khai. Điểm trừ: kế hoạch có thể mang cảm giác cơ học. Nó hoàn thành công việc nhưng thường không nêu bật tinh tế phương pháp luận như Claude, cũng không đưa insight về song song hóa như GPT-5.5. Điều này khớp với mô thức rộng hơn của Gemini — mạnh về chất lượng suy luận, “thợ thuyền” hơn ở các phán đoán xung quanh.
Điều này cho bạn biết gì
Chất lượng suy luận trên tác vụ này cao ở cả ba mô hình. Khác biệt nằm ở hành vi đi kèm — 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ự cẩn trọng cấp chuyên gia (phương pháp luận, trường hợp 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 sai. Mô hình nào phù hợp ứ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 thành nhiệm vụ bạn yêu cầu.
Prompt 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 triển khai 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 nghỉ 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. Các ràng buộc được nêu rõ; mục đích là kiểm tra tạo mã dưới ràng buộc chứ không phải trần năng lực — mọi mô hình đều có thể viết hàm này. Khác biệt là cách họ xử lý các ràng buộc.
Prompt
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 chú ý điều gì
Liệu mô hình xử lý cả bốn trường hợp biên hay âm thầm bỏ sót một số. Liệu type hint có chính xác hay chỉ là “cho có”. Liệu triển khai chọn thuật toán có thể bảo vệ (sắp xếp rồi quét) hay thứ gì đó lạ. Và liệu mô hình có 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 muộn trong 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 chạy thử nghiệm này báo cáo nhất quán
GPT-5.5. Thường tạo mã được “kỹ sư hóa” đầy đủ 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 bao gồm Optional hoặc Union cho giá trị trả về ở trường hợp biên), và một docstring với ví dụ gọi. Triển khai thường chọn thuật toán hiển nhiên — sắp xếp, quét, theo dõi khoảng nghỉ lớn nhất — và là đúng. Điều đáng biết: GPT-5.5 thường thê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 những thứ nghĩ rằng bạn sẽ cần, ngay cả khi bạn không yêu cầu.
Claude Sonnet 4.6. Thường tạo mã dễ đọc nhất. Hàm gọn gàng, trường hợp biên xử lý bằng mẫu guard-clause sạch ở đầu, type hint chính xác và tối giản. Claude thường thêm một bình luận có suy nghĩ giải thích một quyết định mà prompt để mở — ví dụ, với timestamp trùng lặp, coi đó là khoảng nghỉ độ dài 0 và giải thích lý do, một lựa chọn có thể bảo vệ mà prompt không chỉ đị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 là dễ bảo trì nhất trong ba. Phù hợp với danh tiếng về chất lượng mã của Claude: sạch, idiomatic, mang chất “chuyên gia”.
Gemini 3.1 Pro. Thường tạo mã tiết kiệm nhất trong ba. Hàm đúng, các trường hợp biên được xử lý, triển khai ngắn nhất. Docstring thường một dòng. Type hint có và chính xác. Lời giải của Gemini hiếm khi kèm test hoặc bình luận dài dòng, và không “kỹ sư hóa quá mức” — đú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à định tự thêm test, đây là đường thẳng nhất. Với lập trình viên muốn mô hình làm cả việc xung quanh, hai mô hình kia thêm nhiều hơn (dù bạn không yêu cầu).
Điều này cho bạn biết gì
Cả ba mô hình đều có thể viết hàm. Khác biệt hành vi nằm ở việc mỗi mô hình làm thêm bao nhiêu ngoài yêu cầu chữ nghĩa — và mức độ tuân thủ chỉ dẫn “đừng thêm X”. GPT-5.5 nghiêng về kỹ lưỡng, ngay cả khi prompt bỏ qua sự kỹ lưỡng. Claude nghiêng về “tay nghề” (mã dễ đọc, bình luận cân nhắc quyết định). Gemini nghiêng về tiết kiệm (làm đúng yêu cầu, không hơn). Với quy trình agentic 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 kỳ vọng của quy trình rà soát downstream — và mức độ bạn cần tuân thủ nghiêm các chỉ dẫn phủ định.
Các mô thức nổi lên
Xuyên suốt ba prompt trên, ba mô thức hành vi nhất quán xuất hiện từ các nghiên cứu so sánh và báo cáo của nhà phát triển được công bố suốt năm 2026. Đây không phải là tuyên bố năng lực — mỗi mô hình xử lý mọi tác vụ ở mức cao. Chúng là khuynh hướng, kiểu thứ bạn chỉ thấy khi các đội quan sát cùng mô hình xử lý hàng chục prompt. Hãy chạy các prompt trên trong thiết lập của bạn và bạn sẽ thấy cùng các mô thức; bài viết tồn tại để cho bạn khung nhận diện điều bạn đang nhìn khi làm điều đó.
| 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, code phòng thủ, và đầu ra thân thiện downstream. Mạnh ở tác vụ định hình bởi agentic và tool-use. | Ứ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 — agent, workflow, hoặc pipeline nơi bước tiếp theo được tự động hóa. |
| Claude Sonnet 4.6 | Chăm chút cấp chuyên gia. Nêu ra cân nhắc vượt quá yêu cầu chữ nghĩa, nhắc về đạ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 rà soá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 | Tiết kiệm và trực diện. Làm đúng những gì được yêu cầu, không hơn. Tuân thủ lược đồ sạch nhất và số token thấp nhất cho khối lượng công việc. | Ứng dụng của bạn có yêu cầu đầu ra nghiêm ngặt, ưu tiên chi phí dự đoán được, hoặc bạn muốn mô hình là công cụ chính xác thay vì cộng tác viên “biết suy nghĩ”. |
Một lưu ý quan trọng. Các mô thức này là khuynh hướng, không phải quy tắc. Mỗi mô hình đều có thể được điều khiển về bất kỳ hành vi nào trong số này với prompt phù hợp — một system prompt đủ chi tiết sẽ khiến Gemini thêm test, hoặc ràng buộc Claude về đầu ra tối thiểu, hoặc khiến GPT-5.5 bỏ qua unit test. Điểm nhấn là mô hình làm gì theo mặc định, trước khi bạn bắt đầu điều khiển nó. 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 prompt 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ể lặp lại 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ô thức hành vi quan trọng với ứ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 tiễn để chạy bài tập trên chính lưu lượng 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 bao quát khối lượng công việc của bạn. Hầu hết hệ thống sản xuất có thể phân rã thành vài loại prompt (trích xuất, phân loại, tạo, suy luận, mã, tóm tắt). Chọn các danh mục chiếm phần lớn lưu lượng của bạn.
- Tuyển chọn 20–30 ví dụ mỗi danh mục. Tốt nhất từ lưu lượng thực. Ẩn danh khi cần. Mục đích là prompt phải giống những gì ứng dụng của bạn thực sự thấy, không phải câu hỏi benchmark. Hai mươi ví dụ mỗi danh mục đủ để thấy mô thức; ba mươi là đủ để tự tin.
- Chạy qua một endpoint, tất cả mô hình. Một endpoint tổng hợp tương thích OpenAI giúp việc này nhanh hơn rất nhiều so với chạy từng 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 trong đầu ra chính là khác biệt mô hình.
- Chấm định tính trước định lượng. Đọc lướt đầu ra trước. Mô thức hành vi thường rõ ràng trong chục prompt đầu. 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ủ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ú ý những gì mô hình “thêm vào”. Câu hỏi benchmark là mô hình có ra đáp án đúng khô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ó tạo thêm trường bạn không yêu cầu không? Khác biệt mô hình nằm ở đây.
- Chọn mô hình phù hợp với mô thức downstream của bạn. Nếu quy trình downstream của bạn tự động, bạn muốn mô hình có hành vi mặc định tạo ra đầu ra sạch, có thể parse. Nếu quy trình downstream của bạn do con người rà soát, bạn muốn mô hình có hành vi mặc định thêm kiểu phán đoán mà người rà soát muốn thấy. Câu trả lời đúng phụ thuộc vào điều gì diễn ra 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 là chọn mô hình nào “tốt nhất”. Đó là chọn mô hình nào phù hợ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ặp lại trong một buổi chiều nếu bạn đã tuyển chọn prompt; giá trị của việc làm nó là bạn ngừ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 lộ trình; bạn trỏ SDK OpenAI hiện có tới một base URL khác và tham số model trở thành biến số. Bài viết đi kèm, The 2026 LLM API Pricing Comparison, đề cập đến mặt chi phí của cùng quyết định — cùng nhau, chúng cho bạn cả bức tranh hành vi và tài chính để chọn lựa đúng.
Benchmark cho bạn biết mô hình có thể làm gì. Kiểu hành vi cho bạn biế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ạo ra được.
Sẵn sàng tích hợp một cách ổn định? Truy cập CometAPI và API doc để có quyền truy cập liền mạch vào 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ý hôm nay và bắt đầu với khoản tín dụng 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.