CJK Language Disambiguation Prompt

This prompt is for platform engineers and AI infrastructure teams who need to route Chinese, Japanese, and Korean (CJK) text to the correct downstream model, translation layer, or locale-specific workflow. The core job is reliable language identification when input text shares the CJK Unified Ideographs block—where the same Unicode character can represent a different word in each language. Use this prompt when your system ingests user-generated content, documents, or queries that may arrive without explicit language metadata, and where misrouting to the wrong language model produces garbled translations, broken search results, or degraded user trust.

The ideal scenario is a text sample of at least 15–20 characters. At this length, character frequency distributions, kana presence (Japanese), Hangul syllable blocks (Korean), and vocabulary markers provide enough signal for reliable disambiguation. The prompt is designed to work as a classification step in a routing middleware pipeline: it takes raw text and returns a language label, a confidence score, and an ambiguity flag. Do not use this prompt for single-character inputs, proper nouns in isolation, or text that consists entirely of shared CJK characters with no language-specific scripts present—these cases require a fallback to user prompting, metadata inspection, or a default routing policy. Also avoid using this prompt as a standalone translation or transliteration tool; its job is classification only.

Before wiring this into production, test it against your hardest cases: short strings under 10 characters, mixed CJK documents where Japanese text contains kanji without kana, and Korean text that uses Hanja (Chinese characters) without Hangul. These edge cases are where disambiguation confidence drops fastest. The playbook includes eval checks and failure mode guidance so you can measure misrouting rates before deployment. If your pipeline handles regulated content or high-stakes routing decisions, pair this prompt with a confidence threshold that triggers human review or a clarification request when the model cannot disambiguate reliably.

This template is designed to be dropped directly into your CJK routing middleware. It accepts raw text and returns a structured language classification with a confidence score. The prompt uses multiple disambiguation signals—Unicode block analysis for Hangul and Kana, character frequency heuristics for Hanzi/Kanji dominance, and vocabulary marker detection—rather than relying on a single fragile signal. This multi-signal approach is essential because short strings, mixed-script documents, and proper nouns frequently defeat single-signal classifiers.

Below is the copy-ready template. Replace each square-bracket placeholder with your application's values before use. The [INPUT] placeholder receives the raw text to classify. [OUTPUT_SCHEMA] should be replaced with your expected JSON structure, typically including language, confidence, signals_used, and ambiguity_flag fields. [CONSTRAINTS] allows you to inject domain-specific rules, such as defaulting to a specific language when confidence is below threshold or handling mixed CJK documents with a primary-language extraction policy. [EXAMPLES] should contain 3–5 few-shot examples covering the hardest cases for your domain: short queries, mixed-script inputs, and proper nouns that could belong to multiple languages.

textCopy
You are a CJK language classifier. Your task is to determine whether the input text is Chinese (zh), Japanese (ja), or Korean (ko).

Use the following signals in order of reliability:
1. **Hangul presence (U+AC00–U+D7AF)**: Any Hangul syllable blocks strongly indicate Korean.
2. **Kana presence (U+3040–U+309F Hiragana, U+30A0–U+30FF Katakana)**: Any Kana characters strongly indicate Japanese.
3. **Hanzi/Kanji character frequency**: When only CJK Unified Ideographs (U+4E00–U+9FFF) are present, compare character frequency patterns. Chinese uses a wider distribution of characters; Japanese uses a smaller set of Joyo Kanji with higher repetition.
4. **Vocabulary markers**: Detect language-specific particles, verb endings, and common words:
   - Japanese markers: は (wa), が (ga), を (wo), です (desu), ます (masu), いる/ある
   - Korean markers: 은/는 (eun/neun), 이/가 (i/ga), 을/를 (eul/reul), 합니다 (hamnida), 습니다 (seumnida)
   - Chinese markers: 的 (de), 了 (le), 是 (shi), 在 (zai), 和 (he)
5. **Script mixture patterns**: Japanese commonly mixes Kanji + Kana. Korean commonly mixes Hangul + Hanja (rare in modern text). Chinese is predominantly Hanzi with Latin script or punctuation.

[CONSTRAINTS]

Classify the following text:

[INPUT]

Return your classification in this exact JSON format:
[OUTPUT_SCHEMA]

Examples:
[EXAMPLES]

When adapting this template, pay close attention to the [CONSTRAINTS] section. For production routing, you should specify a confidence threshold below which the input is flagged for human review or routed to a fallback multilingual model. For short-text applications like search queries or chatbot messages, add an explicit instruction that inputs under 10 characters should return ambiguity_flag: true and a lower confidence score. If your system handles mixed CJK documents (e.g., a Japanese academic paper quoting Chinese text), add a constraint for primary-language extraction rather than single-language classification. The [EXAMPLES] few-shot block is not optional for this prompt—CJK disambiguation on short or ambiguous strings improves significantly with 3–5 well-chosen examples that demonstrate edge cases your application actually encounters.

After copying this template, validate it against your eval suite before deployment. Test specifically on: single-character inputs, proper nouns (person names, place names that could be Chinese or Japanese), mixed-script documents, and inputs where the only CJK characters are shared Hanzi/Kanji. These four categories produce the majority of production misclassifications. If your eval results show confidence scores clustering near your threshold, consider adding a clarification step rather than routing on low-confidence output.

The CJK Language Disambiguation Prompt is designed to sit at the ingress layer of a multilingual AI platform, immediately after text ingestion and before any downstream model selection, translation, or locale-specific processing. Its job is narrow: given a raw string that may contain Chinese, Japanese, Korean, or mixed CJK text, return a single primary language label and a confidence score. This prompt is not a general language detector—it assumes the input is already known to be CJK-dominant and focuses on resolving the ambiguity that generic language classifiers struggle with. Wire it as a synchronous pre-processing step with a strict timeout (200-500ms) and a hard fallback to a script-based heuristic if the model call fails or times out.

The implementation should wrap the prompt in a lightweight router function that handles validation, retries, and logging. On invocation, construct the prompt by injecting the raw text into the [INPUT] placeholder. Set [CONSTRAINTS] to enforce a JSON-only output with fields language (one of zh, ja, ko, mixed) and confidence (0.0-1.0). After receiving the model response, validate the JSON structure and field values before acting on the result. If confidence is below a configurable threshold (start with 0.7 and tune from production logs), route to a human review queue or apply a conservative fallback policy. Log every disambiguation decision with the input hash, detected language, confidence, model used, and latency for later eval analysis. For high-throughput pipelines, batch up to 25 short strings per call to amortize latency, but keep individual string length under 500 characters to avoid token waste on long documents where CJK disambiguation is rarely the bottleneck.

Model choice matters here. Use a fast, instruction-tuned model with strong multilingual performance—Claude 3.5 Haiku or GPT-4o-mini work well for this task because the prompt relies on character-level pattern recognition (kana presence, hangul blocks, simplified vs. traditional character frequency) rather than deep semantic reasoning. Avoid larger models unless you observe persistent failures on short strings or mixed-script documents. Implement a two-tier fallback: if the primary model call fails, retry once with a different model; if both fail, fall back to a deterministic script-detection function that checks for Unicode ranges (Hangul → ko, Hiragana/Katakana → ja, CJK Unified Ideographs only → zh with low confidence). This ensures the routing pipeline never blocks on language detection failure. Wire structured logging to capture which fallback path was used so you can measure the reliability of the prompt-based path over time.

Testing this prompt in production requires a focused eval harness. Build a golden dataset of at least 200 examples covering: short strings under 10 characters (where disambiguation is hardest), mixed CJK documents (e.g., Japanese text with Chinese proper nouns), Korean text with Hanja, and edge cases like CJK punctuation-only strings or emoji-heavy inputs. Run this dataset through the prompt on every change and assert that accuracy stays above 95% for unambiguous inputs and that mixed is correctly flagged when multiple CJK languages appear. Monitor production for confidence-score calibration drift—if the model starts returning 0.99 confidence on wrong answers, you have a silent failure mode that script-based fallbacks won't catch. Set up an eval pipeline that samples production inputs weekly, runs them through the prompt, and compares against human-verified labels to detect drift before users notice.