Đổi model không chỉ là đổi API key: vì sao prompt viết cho GPT có thể hỏng trên Claude, Gemini và Llama

Ngày 31/10/2026, nền tảng Evals của OpenAI chuyển sang chế độ chỉ đọc với người dùng hiện có. Đến 30/11/2026, nó tắt hẳn. Đội nào đang dùng Evals để kiểm tra trước khi đổi model thì còn chưa đầy tám tuần để tìm thứ thay thế.

Khách hàng hỏi thử Claude có tốt hơn không, thử Gemini có rẻ hơn không, hoặc có chạy Llama trên hạ tầng của họ được không. Thử hình dung bạn là FDE ở một dự án triển khai và nhận đúng câu hỏi đó.

Cách làm dễ nhất là đổi endpoint, giữ nguyên prompt rồi xem kết quả. Nhưng tài liệu chính thức của OpenAI, Anthropic, Google và Meta đều cho thấy cách này không ổn. Prompt chạy tốt là prompt đã được tinh chỉnh cho đúng một model. Khi đổi model, thứ cần bảo vệ là bộ test, chứ không phải câu chữ trong prompt.

Prompt được viết cho một model cụ thể

Bắt đầu từ chính OpenAI. Hãng khuyên pin ứng dụng production vào một snapshot model cụ thể, vì ngay các snapshot trong cùng một họ cũng có thể chạy khác nhau. Như vậy, rủi ro đã có ngay khi bạn chưa rời khỏi OpenAI.

OpenAI còn phân biệt hai cách viết prompt. Model reasoning cho kết quả tốt hơn khi chỉ nhận mục tiêu ở mức cao. Model GPT thường cần chỉ dẫn chính xác, từng bước. Một prompt viết chi tiết để GPT làm đúng có thể là prompt chưa phù hợp với model reasoning, và ngược lại.

Nếu khác biệt đã lớn như vậy trong cùng một hãng, thì khi sang hãng khác prompt càng khó giữ nguyên. Lý do là người viết prompt thường thêm vào những câu để bù cho điểm yếu của model cũ. Các câu đó vẫn nằm trong prompt, kể cả khi model mới không còn điểm yếu ấy.

Một prompt tốt cho GPT có thể gây hại trên Claude

Thử hình dung một prompt trích xuất dữ liệu hóa đơn cho một công ty logistics, đã được tinh chỉnh vài tháng trên GPT. Prompt dùng markdown để chia phần. Nó có câu ép model làm kỹ, như “PHẢI đọc hết mọi dòng, KHÔNG được bỏ sót”. Cuối prompt có thêm một bước tự kiểm tra lại kết quả. Lượt assistant được prefill bằng dấu { để buộc model trả JSON.

Khi chuyển sang Claude 4.6, prompt này có bốn chỗ cần xem lại. Chỗ đầu tiên làm hỏng integration ngay lập tức. Anthropic ghi rõ rằng từ các model Claude 4.6, prefill ở lượt assistant cuối không còn được hỗ trợ. Mẹo ép JSON bằng dấu { vì thế phải được thay bằng cách khác.

Chỗ thứ hai khó thấy hơn. Theo ghi chú migration của Anthropic, Claude 4.6 chủ động hơn và có thể phản ứng quá mức với những chỉ dẫn từng cần thiết cho model cũ. Hãng khuyên giảm bớt các câu ép model làm kỹ hơn. Những câu viết hoa từng giúp model cũ không bỏ sót giờ có thể khiến model mới làm quá tay.

Chỗ thứ ba là bước tự kiểm tra. Anthropic cảnh báo rằng chỉ dẫn kiểm tra lại, khi được giữ từ prompt viết cho model đời trước, có thể khiến model kiểm tra quá nhiều, làm tăng token và độ trễ.

Chỗ thứ tư liên quan đến định dạng và chi phí. Một bài phân tích độc lập trên VentureBeat ghi nhận model của OpenAI hợp với markdown hơn, còn model của Anthropic hợp với XML tag khi chia các phần của prompt. Bài này cũng chỉ ra tokenizer của Anthropic thường tách cùng một đoạn văn bản thành nhiều token hơn.

Vì vậy, chi phí tính trên bảng tính cũ không còn đúng, dù prompt vẫn y nguyên.

Gemini và Llama có những bẫy khác

Nếu đích đến là Gemini 3, vấn đề lại nằm ở chỗ khác. Google khuyên dùng prompt trực tiếp, có cấu trúc rõ ràng, và giữ tham số sampling ở mặc định. Hãng cảnh báo rằng đặt temperature thấp hơn 1.0 có thể khiến model chạy bất thường.

Nếu bạn quen đặt temperature bằng 0 cho các tác vụ trích xuất, đây là một thói quen nên kiểm tra sớm khi chuyển sang Gemini 3.

Google còn khuyên luôn đưa few-shot example vào prompt cho Gemini. Theo hãng, prompt không có ví dụ nhiều khả năng sẽ kém hiệu quả hơn. Một prompt chỉ gồm hướng dẫn, vốn chạy ổn trên model khác, sẽ cần thêm vài cặp input-output mẫu.

Llama khác ở tầng thấp hơn. Model của Meta dùng định dạng prompt riêng với các special token, và tài liệu của Meta yêu cầu function call phải theo đúng định dạng đã quy định. Khả năng hỗ trợ tool cũng hạn chế hơn. Vì thế, prompt và tool schema viết theo kiểu GPT không thể chép thẳng sang. Phần tool calling gần như phải được viết lại.

Bảng dưới đây gom những điểm trên thành danh sách cần kiểm tra theo từng đích đến. Các gợi ý về XML tag và tokenizer đến từ phân tích độc lập của VentureBeat, không phải hướng dẫn chính thức của Anthropic:

Đích đến	Thói quen cũ có thể gây lỗi	Nên làm gì
GPT (snapshot khác, hoặc model reasoning)	Không pin snapshot; dùng chỉ dẫn từng bước cho model reasoning	Pin snapshot; với model reasoning, chuyển sang nêu mục tiêu ở mức cao
Claude 4.6	Prefill lượt assistant; câu ép làm kỹ; bước tự kiểm tra cũ; chia phần bằng markdown	Bỏ prefill; giảm các câu ép; bỏ hoặc rút gọn bước kiểm tra (theo Anthropic). Thử XML tag và tính lại chi phí theo tokenizer (theo phân tích của VentureBeat)
Gemini 3	Temperature 0; prompt không có ví dụ	Giữ sampling ở mặc định; thêm few-shot example; viết prompt trực tiếp, có cấu trúc
Llama	Tool schema và cách gọi hàm kiểu GPT	Viết lại theo định dạng special token; tool call theo đúng định dạng của Meta

Viết eval trước khi sửa prompt

Bảng trên chỉ cho biết nên nhìn vào đâu. Còn prompt đã sửa có thật sự tốt hơn hay không thì phải đo mới biết. OpenAI khuyên chuẩn bị fixture đại diện, test và các bước kiểm tra eval trước khi thay đổi prompt production.

Anthropic còn coi đây là điều kiện tiên quyết: muốn làm prompt engineering thì trước hết phải có tiêu chí thành công rõ ràng và cách kiểm chứng tiêu chí đó.

Các công cụ tự động cũng không thay được bước này. Prompt optimizer của OpenAI cảnh báo rằng prompt do nó viết lại có thể chạy kém hơn, và luôn cần được đánh giá cùng review thủ công trước khi đưa lên production.

Quay lại ví dụ hóa đơn. Giả sử bạn có 50 hóa đơn thật đã được gán nhãn, gồm cả hóa đơn mờ, hóa đơn nhiều trang và hóa đơn thiếu trường. Chạy bộ này trên model hiện tại để có baseline, ví dụ đạt 46/50.

Sau đó port prompt sang model mới, chạy lại và ghi ba con số: tỷ lệ đạt, số token trung bình, độ trễ trung bình.

Khi có bảng này, cuộc trao đổi với khách hàng thay đổi hẳn. Thay vì nói “Claude có vẻ ổn”, bạn có thể nói rằng model mới đạt bao nhiêu trên 50 ca, hỏng ở ca nào, tốn thêm hay bớt bao nhiêu token. Anthropic cũng viết rằng đôi khi đổi sang model khác lại dễ hơn ngồi tinh chỉnh prompt.

Nhưng chỉ khi có eval, bạn mới biết mình đang ở trường hợp nào.

Nếu đội của bạn đang dùng nền tảng Evals của OpenAI, mốc 30/11/2026 là lý do để chuyển bộ fixture về repo của mình ngay. Nên giữ chúng dưới dạng file, có version control, chạy được trên bất kỳ model nào.

Với các đích đến không có trong bảng trên, như Grok, nên áp dụng cùng nguyên tắc: đọc tài liệu prompting của hãng, liệt kê các thói quen cũ, rồi để bộ fixture quyết định.

Bộ fixture đáng giá hơn một dòng “thành thạo prompt”

Với một developer muốn làm FDE, model migration là bài tập luyện tập rất tốt vì nó gần với công việc thật. Hãy lấy một prompt bạn từng viết, port nó sang hai model khác, dựng một harness nhỏ chạy chung bộ fixture, rồi viết một trang ghi lại những gì đã hỏng và cách sửa. Kết quả đó có thể đưa thẳng vào portfolio.

Khi đọc job description, hãy để ý các cụm như “eval”, “LLM evaluation”, “model migration” hoặc “multi-model”. Nếu gặp chúng, nên đưa kinh nghiệm này lên đầu CV. Hãy mô tả bằng kết quả đo được, chẳng hạn “chuyển pipeline trích xuất từ GPT sang Claude, giữ tỷ lệ đạt trên bộ 50 fixture và giảm độ trễ nhờ bỏ bước tự kiểm tra thừa”.

Một dòng như vậy thuyết phục hơn câu “thành thạo prompt engineering”.

Model sẽ còn được thay mới nhiều lần, còn bộ fixture được gán nhãn từ dữ liệu thật của khách hàng thì có thể dùng lại qua các lần đổi model. Nếu phải chọn việc làm trước, hãy xây bộ fixture trước khi tối ưu prompt.