Những bài học
Bắt đầu
Bắt đầu học
CodeGym /Các khóa học /ChatGPT Apps /Bản địa hóa tools và description: ảnh hưởng đến GPT và th...

Bản địa hóa tools và description: ảnh hưởng đến GPT và thử nghiệm hành vi

ChatGPT Apps
Mức độ , Bài học
Có sẵn

1. Mô hình “nhìn” công cụ của bạn như thế nào

Bắt đầu từ việc đối với mô hình, tool — hoàn toàn không phải “hàm TypeScript đẹp đẽ của bạn”, mà là một mô tả có cấu trúc theo kiểu:

  • name: tên kỹ thuật, ví dụ "search_gifts";
  • description: văn bản ngôn ngữ tự nhiên giải thích khi nào và vì sao nên dùng công cụ này;
  • inputSchema: JSON Schema với các trường, mỗi trường cũng có thể có description, kiểu, và ràng buộc.

Một cách cực kỳ giản lược, mô hình làm cỡ như sau (pseudo-code trong “đầu” GPT):


1. Đọc yêu cầu của người dùng (ở bất kỳ ngôn ngữ nào).
2. Đọc danh sách tools: name + description + mô tả các tham số.
3. Với mỗi tool, ước lượng xem nó có phù hợp với nhiệm vụ hay không.
4. Nếu cần tool — sinh JSON với các tham số theo schema.
5. Nếu không — trả lời bằng văn bản.

Có hai kết luận quan trọng ở đây.

Thứ nhất, trường description của công cụ — không phải chú thích cho lập trình viên, mà là giao diện giữa mô hình và backend của bạn. Nếu mô tả công cụ mơ hồ, không đầy đủ hoặc ở ngôn ngữ không trùng với ngôn ngữ người dùng, mô hình sẽ trượt nhiều hơn: chọn sai tool, tham số sai, trả lời thuần văn bản ở nơi lẽ ra phải gọi tool.

Thứ hai, description của các trường trong JSON Schema cũng quan trọng như mô tả của chính công cụ. Mô hình thực sự đọc description của từng thuộc tính và dựa vào đó quyết định đặt “tuổi” vào trường nào, “ngân sách” vào trường nào, và chỗ nào phải có id.

Mini ví dụ cho GiftGenius

Lấy công cụ search_gifts của chúng ta. Ở bản “chỉ EN” ban đầu, nó có thể trông như sau: 

// server/tools/searchGifts.ts
export const searchGiftsTool = {
  name: "search_gifts",
  description: "Search for gift ideas based on user preferences.",
  inputSchema: {
    type: "object",
    properties: {
      recipient_age: {
        type: "integer",
        description: "Age of the recipient in years.",
      },
      budget: {
        type: "number",
        description: "Maximum budget in user's currency.",
      },
    },
    required: ["budget"],
  },
};

Nếu người dùng viết: “Cần quà cho mẹ, bà 60 tuổi, ngân sách tối đa 3000 rúp”, mô hình phải:

  1. Hiểu rằng search_gifts — là công cụ phù hợp.
  2. Hiểu rằng “60 tuổi” cần đặt vào recipient_age, còn “3000 rúp” — vào budget.

Khi mô tả chỉ có tiếng Anh, GPT vẫn có thể xử lý, nhưng nó buộc phải “dịch nội bộ” thêm một bước. Với nhiều ngôn ngữ và các mô hình yếu hơn, điều này làm giảm độ chính xác.

2. Vấn đề “mô tả tiếng Anh” trong App đa ngôn ngữ

Trong mô-đun 9, chúng ta đã lướt qua “bản đồ bản địa hóa” tổng quan: widget UI, catalog, lỗi, văn bản thương mại. Giờ hãy thu hẹp tiêu điểm và xem điều gì xảy ra khi mô tả công cụ chỉ viết bằng tiếng Anh còn người dùng lại giao tiếp, chẳng hạn, bằng tiếng Nga hoặc tiếng Tây Ban Nha — lúc đó “độ hỗn loạn” bắt đầu tăng.

Kịch bản điển hình:

  1. Người dùng: “Hãy chọn quà cho bạn làm IT, ngân sách đến 50 euro”.
  2. Mô hình xem danh sách tools và thấy mô tả chỉ có EN.
  3. Nếu truy vấn cũng bằng EN — mọi thứ ổn.
  4. Nếu truy vấn bằng ngôn ngữ khác, nó phải:
    • trước hết hiểu yêu cầu,
    • ngầm đối chiếu với mô tả tiếng Anh,
    • chọn công cụ,
    • rồi còn phải trích xuất tham số sang JSON.

Với các mô hình mạnh, điều này vẫn “sống” được, nhưng:

  • tỷ lệ trả lời không gọi tool tăng — mô hình “nghĩ” tự nó làm được;
  • xác suất sai tham số cao hơn (đặc biệt khi quan trọng tiền tệ, đơn vị đo, ràng buộc vùng);
  • logic định tuyến giữa nhiều tools kém tin cậy hơn (chọn nhầm công cụ).

Ví dụ lỗi đơn giản: trường budget kỳ vọng “theo tiền tệ người dùng”, nhưng mô tả không nói rõ. Mô hình mặc định là USD và gửi về backend 50 đô ở chỗ người dùng rõ ràng muốn 50 euro.

Và đây là lúc bản địa hóa mô tả phát huy tác dụng.

3. Cách tiếp cận bản địa hóa: tools riêng cho mỗi ngôn ngữ vs mô tả đa ngôn ngữ

Có hai hướng kiến trúc cơ bản, và cả hai đều hợp lý.

Công cụ riêng cho từng ngôn ngữ

Với phương án này, bạn tạo nhiều tools với các tên khác nhau, mỗi tool có mô tả theo “ngôn ngữ của riêng nó”.

Với GiftGenius, có thể như sau:

export const searchGiftsEn = {
  name: "search_gifts_en",
  description: "Search for gift ideas based on user preferences.",
  // ...
};

export const searchGiftsRu = {
  name: "search_gifts_ru",
  description: "Chọn quà dựa trên sở thích của người dùng.",
  // ...
};

Với ChatGPT App, điều quan trọng là danh sách tools khả dụng phải phụ thuộc vào locale. Nếu locale = "ru-RU", thì MCP‑server của bạn nên trả về duy nhất search_gifts_ru. Nếu locale = "en-US", — thì chỉ search_gifts_en.

Ưu điểm của cách này là descriptions tối đa “sạch” và đơn ngữ. Bạn có thể xem App như vài phiên bản đơn ngữ khác nhau, mỗi cái có prompts và mô tả riêng. Thoải mái khi số ngôn ngữ ít và thị trường khác biệt mạnh.

Nhược điểm — lặp logic và khó phân tích. Ở backend có lẽ vẫn dùng cùng một handler, nhưng ở MCP/manifest — đã là hai công cụ khác nhau. Cần nhớ cập nhật đồng bộ mô tả cả hai mỗi lần thay đổi.

Insight (dữ liệu ngày 2025-12-01)

Thử nghiệm cho thấy không phát hiện lợi thế đáng kể của description theo ngôn ngữ người dùng/locale. Việc lựa chọn công cụ diễn ra gần như với tần suất như nhau, bất kể ngôn ngữ mô tả. Nếu có 2 công cụ với mô tả tương tự (ở các ngôn ngữ khác nhau), chúng gây nhiễu cho ChatGPT.

Ngoài ra, ứng dụng của bạn sẽ cần qua review khi đăng ký lên Store. Vì vậy tôi khuyến nghị chỉ cần viết tất cả tool description và argument description bằng tiếng Anh.

Tuy nhiên, nếu về sau có hàng nghìn ứng dụng trong ChatGPT, và cạnh tranh “được chọn làm công cụ” tăng cao, có thể description theo locale người dùng sẽ có lợi thế. Chờ đón thời đại Tool Search Optimization.

Một công cụ với mô tả đa ngôn ngữ

Ở phương án thứ hai, bạn giữ một name (ví dụ search_gifts), nhưng description và mô tả các trường trong JSON Schema là đa ngôn ngữ.

Có vài phong cách:

  1. Dạng ngắn hai ngôn ngữ: 
    description: "Search gifts for a recipient. / Tìm kiếm quà tặng theo sở thích của người nhận.",
  2. Khối liệt kê theo ngôn ngữ: 
    description: "[EN] Search for gifts based on user preferences. [RU] Chọn quà dựa trên sở thích của người nhận.",
  3. Trường riêng rồi nối thành chuỗi (kém tiện hơn): 
    description: `EN: ${enDescription} RU: ${ruDescription}`,

Ưu điểm — một tool duy nhất, nguồn sự thật duy nhất (single source of truth), dễ triển khai kiến trúc với MCP Gateway: bạn luôn lộ một giao diện giống nhau cho ChatGPT, bất kể người dùng đang nói ngôn ngữ nào.

Nhược điểm: mô tả dài hơn. Nếu “trộn” ngôn ngữ không khéo, mô hình có thể hơi bối rối — đặc biệt khi tiếng Anh và ngôn ngữ địa phương lẫn lộn mà không có nhãn rõ [EN], [RU].

Với dự án học tập như GiftGenius, chúng tôi khuyến nghị phương án lai: giữ mô tả chủ yếu bằng tiếng Anh, nhưng thêm phần giải thích ngắn bằng ngôn ngữ địa phương, còn mọi “ngữ nghĩa” thực sự (dùng ngôn ngữ nào, xưng hô ra sao) thì truyền qua tham số (locale) và system‑prompt.

4. Bản địa hóa JSON Schema: mô tả các trường

Giờ đi sâu hơn: đến chính các tham số của công cụ.

Trong JSON Schema, mỗi trường có thể (và nên) có description. Mô hình đọc chuỗi này khi sinh JSON để gọi công cụ.

Với GiftGenius có thể làm như sau:

export const searchGiftsTool = {
  name: "search_gifts",
  description:
    "Search gifts based on user preferences (RU: chọn quà dựa trên sở thích của người nhận).",
  inputSchema: {
    type: "object",
    properties: {
      recipient_age: {
        type: "integer",
        description:
          "Recipient age in years. RU: tuổi của người nhận (số nguyên).",
      },
      budget: {
        type: "number",
        description:
          "Maximum budget in user's currency. RU: ngân sách tối đa theo tiền tệ của người dùng.",
      },
      locale: {
        type: "string",
        description:
          "User locale (e.g. 'en-US', 'ru-RU'). RU: ngôn ngữ giao diện và câu trả lời.",
      },
    },
    required: ["budget", "locale"],
  },
};

Một vài quan sát thực tế.

Thứ nhất, tên trường (recipient_age, budget, locale) thường để tiếng Anh. Cái được dịch là description. Điều này quan trọng để định dạng JSON không thay đổi giữa các ngôn ngữ và bạn không phải duy trì hai hợp đồng khác nhau.

Thứ hai, trong description nên chỉ rõ tiền tệ, đơn vị đo và các ràng buộc quan trọng. Điều này giảm mạnh số lượng tham số “lệch”.

Thứ ba, nếu bạn đã dùng MCP Gateway, có thể thống nhất để nó tự động truyền locale vào tham số công cụ, giúp mô hình không nhất thiết phải tự chèn. Nhưng ngay cả vậy, đừng quên mô tả locale: mô hình vẫn hiểu tốt hơn đó là tham số gì và để làm gì.

5. Chọn ngôn ngữ mô tả: chiến lược cho App thực tế

Câu hỏi thực dụng nhất: chọn ngôn ngữ nào làm chính cho mô tả, và khi nào nên bản địa hóa hoàn toàn?

Khuyến nghị và kinh nghiệm thực tế cho thấy các mô hình GPT vẫn hoạt động tốt nhất trong ngữ cảnh tiếng Anh, và nhiều lập trình viên giữ mô tả chỉ bằng EN. Nhưng với App đa ngôn ngữ, đó có thể là một thỏa hiệp.

Hãy xét vài chiến lược.

Chỉ mô tả EN

Phương án đơn giản nhất — tất cả bằng tiếng Anh.

Ưu điểm: một codebase, một ngôn ngữ để duy trì, dễ viết câu từ chính xác. Mô hình “hạnh phúc” khi mọi thứ xung quanh là tiếng Anh.

Nhược điểm: với người dùng viết bằng ngôn ngữ khác, chất lượng chọn công cụ và tham số có thể thấp hơn. Đặc biệt với mô hình “lười” hoặc công cụ phức tạp nhiều tham số.

EN + đoạn đuôi bản địa ngắn

Cách thỏa hiệp: mô tả chính bằng EN, cuối cùng — một khối ngắn bằng ngôn ngữ địa phương để giúp mô hình đối chiếu từ của người dùng với tham số.

Ví dụ:

description:
  "Search for gifts based on user preferences. RU: công cụ chọn quà theo mô tả về người nhận, tuổi và ngân sách của họ.",

Với JSON Schema:

description:
  "Age of the recipient in years. RU: tuổi của người nhận (tính theo năm).",

Ưu điểm: mô hình vẫn ở “thế giới tiếng Anh”, nhưng có gợi ý theo ngôn ngữ người dùng.

Nhược điểm: mô tả dài hơn, thường không quá nghiêm trọng.

Bản địa hóa đầy đủ theo locale

Cách “nặng” nhất: mô tả công cụ và trường thay đổi theo locale mà bạn nhận từ ChatGPT. Với en-US bạn trả về mô tả thuần tiếng Anh, với ru-RU — thuần tiếng Nga, với de-DE — tiếng Đức.

Lúc này không còn “một JSON Schema cố định”, mà là một tập schema được MCP/Gateway chọn động.

Ở mức MCP có thể như sau:

function getSearchGiftsToolDescription(locale: string) {
  if (locale.startsWith("ru")) {
    return {
      name: "search_gifts",
      description: "Chọn quà dựa trên sở thích của người nhận.",
      // ru‑schema...
    };
  }
  return {
    name: "search_gifts",
    description: "Search for gifts based on user preferences.",
    // en‑schema...
  };
}

Ưu điểm: mô hình thấy giao diện cùng ngôn ngữ với người dùng. Tối đa tiện lợi.

Nhược điểm: tăng độ phức tạp bảo trì và kiểm thử. Cần quy trình đảm bảo mọi biến thể bản địa hóa giữ đồng bộ ý nghĩa, và bạn không quên cập nhật, chẳng hạn, schema tiếng Đức khi thêm trường mới vào schema tiếng Anh.

6. Triển khai trong ứng dụng GiftGenius của chúng ta

Đi vào cụ thể. Ta làm phương án lai trong GiftGenius: một công cụ search_gifts, mô tả chủ yếu bằng EN nhưng có chú giải tiếng Nga ngắn, cộng tham số locale.

Giả sử bạn có MCP‑server bằng TypeScript, mô tả tools theo phong cách MCP SDK. 

// mcp/tools/searchGifts.ts
import { z } from "zod";

export const searchGiftsInputSchema = z.object({
  recipient_age: z
    .number()
    .int()
    .describe(
      "Age of the recipient in years. RU: tuổi của người nhận (số nguyên)."
    ),
  budget: z
    .number()
    .describe(
      "Maximum budget in user's currency. RU: ngân sách tối đa theo tiền tệ của người dùng."
    ),
  locale: z
    .string()
    .describe(
      "User locale (e.g. 'en-US', 'ru-RU'). RU: ngôn ngữ giao diện và câu trả lời."
    ),
});

export const searchGiftsTool = {
  name: "search_gifts",
  description:
    "Search for gifts based on user preferences (RU: chọn quà dựa trên sở thích của người nhận).",
  inputSchema: searchGiftsInputSchema,
  // execute(...) ...
};

Quan trọng là:

  • locale là bắt buộc. Nếu widget biết nó (và ta biết từ _meta["openai/locale"]), widget sẽ tự chèn vào lệnh callTool, hoặc MCP Gateway sẽ tự làm ở phía mình;
  • mô tả đã có các từ khóa tiếng Nga “tuổi”, “ngân sách”, “ngôn ngữ giao diện”, vì vậy mô hình dễ hiểu hơn nên đặt phần nào của yêu cầu người dùng vào đâu.

Ở phía Apps SDK, bạn có thể, ví dụ, có một hàm gọi trực tiếp tool này (nếu bật widgetAccessible), truyền locale từ widget. 

// widget/hooks/useSearchGifts.ts
export async function searchGiftsFromWidget(params: {
  recipientAge: number;
  budget: number;
  locale: string;
}) {
  const openai = (window as any).openai;
  const result = await openai.callTool("search_gifts", {
    recipient_age: params.recipientAge,
    budget: params.budget,
    locale: params.locale,
  });
  return result;
}

Chuỗi này củng cố kiến trúc: locale đến từ ChatGPT → đi vào tool → tool chọn đúng catalog và định dạng giá, sau đó bạn render đẹp ở frontend.

7. Thử nghiệm hành vi: đo ảnh hưởng của bản địa hóa

Phần thú vị nhất: làm sao biết bản địa hóa tools và mô tả thực sự cải thiện hành vi mô hình, chứ không phải bạn đã phí công dịch thuật?

Bạn có thể làm một “thử nghiệm nhỏ” ngay trong Dev Mode trên GiftGenius.

Hai biến thể App: base vs localized

Chuẩn bị hai cấu hình App của bạn:

  • base — mô tả công cụ và JSON Schema chỉ EN;
  • localized — mô tả EN+RU (hoặc bản ru đầy đủ nếu bạn sẵn sàng).

Giữ nguyên phần còn lại (catalog, UI, prompts) để không lẫn hiệu ứng.

Đơn giản hóa có thể:

  • trong Dev Mode (và nhất là Store) chỉ giữ phiên bản localized;
  • còn base chạy local ở nhánh riêng và so sánh kết quả trên bộ truy vấn chuẩn bị sẵn.

Đo cái gì

Có ba chỉ số chính.

Đầu tiên — tần suất chọn đúng công cụ. Với bộ truy vấn thử nghiệm bằng tiếng Nga (và/hoặc ngôn ngữ khác), bạn đo tần suất mô hình:

  • quyết định gọi công cụ khi cần;
  • chọn đúng search_gifts, không phải tool khác.

Thứ hai — độ đúng của tham số. Kiểm tra mức độ JSON gọi khớp kỳ vọng: không nhầm trường, ngân sách đúng tiền tệ, tuổi là số nguyên rõ ràng, locale không bị mất.

Thứ ba — số lượt gọi lạ hoặc vô nghĩa. Ví dụ, mô hình gọi search_gifts cho câu “bây giờ mấy giờ?” hoặc điền recipient_age: 3000 thay vì ngân sách.

Có thể kiểm thử thủ công hoặc qua log MCP/Agents — dù sao log cũng hữu ích về sau, nên hãy quen với dạng phân tích này từ sớm.

Tổ chức bộ test thủ công

Có thể tạo một “golden prompt set” nhỏ cho bản địa hóa:

1. "Tôi cần một món quà rẻ dưới 30 euro cho bé gái 10 tuổi, bé thích vẽ."
2. "Hãy chọn quà cho đồng nghiệp lập trình, 35 tuổi, ngân sách 100$."
3. "Cần quà cho bà nhân dịp sinh nhật tròn, 70 tuổi, ngân sách đến 5000 rúp."

Và chạy qua cả hai bản App (base và localized), quan sát:

  • mô hình chọn công cụ nào;
  • nó chèn tham số ra sao;
  • văn bản trả lời thay đổi thế nào nếu công cụ không được gọi.

Mẹo bán chuyên: có thể viết một wrapper script đơn giản gửi các truy vấn này qua ChatGPT API, nhưng trong khuôn khổ khóa học, chế độ thủ công trong Dev Mode là đủ. Một nhóm truy vấn đặc biệt hữu ích đưa vào bộ này — tin nhắn trộn ngôn ngữ và các tổ hợp locale “kỳ quặc”. Ta sẽ dành riêng một phần cho chúng.

Nếu bạn phát triển ứng dụng thương mại nghiêm túc với rủi ro lên đến hàng triệu đô, hãy chắc chắn kiểm thử các điểm này chính trên ứng dụng của bạn. Mô-đun 20 dành cho việc xây dựng “golden prompt set” ở mức chuyên nghiệp — nhất định hãy nắm vững chủ đề này.

8. Trộn ngôn ngữ và tổ hợp locale kỳ lạ

Không gì “vui” với người làm LLM bằng người dùng viết hai ngôn ngữ cùng lúc. Ví dụ: 

"Cần một món quà for my friend, anh ấy thích Star Wars, budget 100€"

Ta đã biết mô hình là đa ngôn ngữ và thường vẫn xử lý được. Nhưng khi trộn ngôn ngữ và mô tả công cụ “tiếng Anh”, xác suất lỗi tăng.

Có vài tình huống điển hình.

Tình huống thứ nhất — người dùng viết bằng RU, mô tả công cụ lại EN. Mô hình có thể hiểu, nhưng đôi khi nhầm, nhất là thuật ngữ đặc thù (tên danh mục, nhãn trường hiếm).

Tình huống thứ hai — locale = "ru-RU", nhưng người dùng lại viết tiếng Anh. ChatGPT gửi tín hiệu rằng giao diện nên hiển thị tiếng Nga, nhưng ngôn ngữ thực tế của văn bản — EN. Có thể:

  • vẫn trả về mô tả tiếng Nga, coi locale là nguồn chân lý chính;
  • hoặc triển khai phát hiện ngôn ngữ tin nhắn như tín hiệu phụ và điều chỉnh mô tả theo ngôn ngữ thực tế.

Tình huống thứ ba — locale = "en", còn người dùng đôi khi chèn vài từ tiếng Nga. Trường hợp này, mô tả tiếng Anh thường vẫn phát huy tốt.

Trong thực tế, chỉ cần chọn một chính sách rõ ràng. Ví dụ:

  • nếu locale bắt đầu bằng "ru" — bạn thêm phần tiếng Nga vào mô tả;
  • nếu không — mô tả là tiếng Anh thuần.

Quy tắc rõ ràng hữu ích vì bạn có thể kiểm thử chủ động từng nhánh, thay vì đoán vì sao hôm nay mô tả lại ở ngôn ngữ này hay kia.

9. Tài liệu, quy trình và “ngôn ngữ chuẩn”

Bản địa hóa mô tả — không phải hành động một lần, mà là một quy trình. Người dùng thích có thêm tính năng, còn bạn — thích không “làm hỏng” cái cũ. Vậy nên hãy thống nhất trước:

  • ngôn ngữ nào là “chuẩn” để căn cứ dịch thuật;
  • lưu mô tả bản địa hóa ở đâu;
  • kiểm tra tính nhất quán thế nào.

Thường tiếng Anh đóng vai trò ngôn ngữ chuẩn. Tất cả công cụ và trường mới được mô tả trước bằng EN, qua review, rồi mới bản địa hóa sang các ngôn ngữ khác. Trong codebase, có thể thể hiện như sau:

  • tệp tools.en.json với mô tả đầy đủ name/description/các trường;
  • các tệp tools.ru.json, tools.de.json làm “bản phái sinh” cho ngôn ngữ cụ thể;
  • một trình tạo nhỏ để lắp ghép JSON Schema cuối cùng cho MCP dựa trên các từ điển này.

Bản đơn giản có thể tạm dùng chuỗi trong code, nhưng cấu trúc sao cho sau này dễ tách ra thành từ điển riêng.

Hãy nhớ rằng mô tả cũng là văn bản sản phẩm. Nên review nghiêm như UI copy: kiểm tra mức độ dễ hiểu, tránh mơ hồ và “rườm rà” không cần. Đặc biệt với mô tả đa ngôn ngữ, ta không muốn phần tiếng Nga mâu thuẫn với phần tiếng Anh.

10. Sơ đồ trực quan: ngôn ngữ đi xuyên stack như thế nào

Để tổng hợp, hãy xem sơ đồ luồng yêu cầu có xét bản địa hóa tools. 

flowchart TD
    U[Người dùng viết bằng RU] --> C[ChatGPT UI]
    C -->|"_meta.openai/locale = 'ru-RU'"| W[Widget GiftGenius]
    W -->|"locale = 'ru-RU'"| T["Mô tả tool (EN+RU)"]
    T --> M[Mô hình GPT]
    M -->|callTool search_gifts| MCP[MCP / Gateway]
    MCP -->|"locale = 'ru-RU'"| B[Backend / danh mục RU]
    B --> MCP --> M2["Mô hình GPT (trả lời)"]
    M2 --> C2[ChatGPT UI + widget RU]

Ở đây, ngôn ngữ người dùng và locale quyết định:

  • UI widget hiển thị bằng ngôn ngữ nào;
  • mô hình thấy mô tả công cụ và trường bằng ngôn ngữ nào;
  • backend chọn catalog và tiền tệ nào;
  • định dạng câu trả lời ra sao (cả mô hình lẫn widget).

11. Lỗi điển hình khi bản địa hóa tools và mô tả

Lỗi số 1: coi trường description là “kỹ thuật” và không bản địa hóa.
Cách này ổn khi bạn chỉ có người dùng tiếng Anh. Ngay khi có ngôn ngữ khác, mô hình thường trả lời không gọi tools hoặc truyền tham số “lệch” theo schema. Bạn đã dịch UI, nhưng App vẫn “hành xử bằng tiếng Anh”.

Lỗi số 2: đổi tên trường JSON theo ngôn ngữ.
Đôi khi nảy sinh cám dỗ đổi age → vozrast, budjet v.v. Điều này dẫn đến ác mộng backend: schema khác nhau, định dạng khác nhau, phân tích log phức tạp. Tốt hơn giữ name trường ổn định và chỉ bản địa hóa mô tả.

Lỗi số 3: trộn ngôn ngữ lộn xộn trong mô tả.
Những câu kiểu “Tìm kiếm gifts theo sở thích user” không giúp mô hình hay con người. Nếu bạn làm mô tả đa ngôn ngữ, hãy tách khối rõ: [EN] ... [RU] .... Khi đó mô hình thấy cấu trúc, không phải “một nồi lẩu”.

Lỗi số 4: không truyền locale vào công cụ.
Dù bạn đã bản địa hóa mô tả, nhưng không truyền locale vào tool (hoặc MCP Gateway không tự chèn), backend sẽ không biết chọn catalog và định dạng nào. Hệ quả là mô hình cố gắng “đa ngôn ngữ”, còn server chỉ trả dữ liệu cho một thị trường.

Lỗi số 5: dịch tự động mô tả bằng máy mà không review.
Nghe có vẻ có thể dùng máy dịch và vui vẻ. Thực tế các bản dịch này thường không chính xác, nhất là thuật ngữ và tham số. Hệ quả là mô hình có thể hiểu sai ý nghĩa công cụ hay trường. Tốt hơn có một bản EN được trau chuốt và các bản địa hóa cẩn thận, hơn là hai chục ngôn ngữ “tự động”.

Lỗi số 6: thiếu kiểm thử/thử nghiệm cho các locale khác nhau.
Nếu bạn không kiểm tra hành vi App ít nhất trên một bộ truy vấn cơ bản cho mỗi locale, mọi thứ có thể “lệch” hàng tháng cho đến khi người dùng thực đến. Một bộ golden nhỏ và kiểm thử thủ công trong Dev Mode giảm đáng kể rủi ro này.

Lỗi số 7: mất đồng bộ giữa mô tả chuẩn và bản địa hóa.
Bạn thêm trường mới occasion (“dịp” tặng quà) vào schema tiếng Anh, nhưng quên cập nhật bản tiếng Nga. Kết quả là ở locale RU, mô hình không hề biết trường này và không điền, dù backend đã kỳ vọng. Ví dụ, server cố lọc quà theo dịp, nhận null và trả danh sách quá chung chung — ở EN hoạt động bình thường, còn RU thì “lệch” âm thầm. Vì vậy mọi thay đổi mô tả công cụ nên theo một quy trình đơn giản nhưng đều đặn: cập nhật EN → cập nhật các locale → chạy nhanh bộ test.

Bình luận
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION