TL;DR
SoT (Structured-of-Thought) is a prompting method that turns natural-language queries into structured representations in 4 steps. Instead of simply translating into English, SoT makes the model think in English (step 1), then pull out the entities and their relationships (step 2), account for language-specific expressions such as a "four-five discount" = 55% off (step 3), and give the final answer in the original language (step 4).
LLMs struggle with non-English languages because of skewed training data. Complex semantic structures in Spanish, Chinese, or Arabic lead to misreading the relationships between numbers and entities. For example, the model mixes up "0.75 cakes per guest" and "1/4 of the guests won't show up", two different phrasings of the same thing. Or it reads "70% discount" as "minus 70%" rather than "70% of the price". Plain translation doesn't help: translation errors pile up, and the model still loses the semantic links.
SoT fixes this by structuring the knowledge: it extracts entities (numbers, units, objects), their relationships, and the linguistic quirks of the expressions. The model sees not a stream of words but a clear map of "what connects to what". That removes ambiguity and lets the model lean on its strength, logical reasoning, even when the question is phrased in a language it knows less well.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
All 4 steps can run in a single prompt (as in the original) or be split into separate requests.
STEP 1: Language Thinking Transformation → Restate the question in English and think in English
STEP 2: Structured Knowledge Extraction → Extract entities, numbers, units, and their relationships in structured form
STEP 3: Language-Specific Knowledge Injection → Add explanations of language-specific expressions (idioms, cultural conventions)
STEP 4: Answer Generation → Give the final answer in the original language based on steps 1-3
Example in Practice
Task: You're planning a company party for 50 people with a caterer in Shanghai. The caterer offers a "four-five discount" (四五折) on orders of 40+ guests, and the base price is $40 per person. You also know that about a quarter of people usually bail at the last minute. What will the final bill be with the discount?
Prompt:
I'll give you a problem that contains a Chinese pricing expression. Apply the SoT method:
Step 1: Restate the problem in English and think in English
Step 2: Extract all entities (numbers, units, objects) and their relationships in structured form
Step 3: Explain language-specific expressions (e.g., "four-five discount" in a Chinese retail context)
Step 4: Solve the problem and answer in the language of the original problem
Problem: You're planning a company party for 50 people. The caterer offers a "four-five discount" (四五折) on orders of 40+ guests, base price $40 per person. You also know that about a quarter of people usually bail at the last minute. What will the final bill be with the discount?Result:
The model will walk through all 4 steps:
- Step 1: a restatement in English ("planning corporate event for 50 people...")
- Step 2: a structured list: "planned guests: 50, no-shows: 25% (12.5 → 13 people), final guests: 37-38, price: $40/person, discount threshold: 40 people, discount: four-five"
- Step 3: the explanation: "'four-five' = you pay 45% of the price, i.e. 55% off (NOT minus 45%)"
- Step 4: the final calculation and answer, with every nuance read correctly
Why It Works
The LLM's weakness: Models are trained mostly on English (and Mandarin). When a question comes in another language with culture-specific expressions, the model loses the semantic links between entities. It sees "four-five discount" and "a quarter won't show" and doesn't realize the first means "45% of the price" and the second means "25% drop out". It mixes up similar phrasings ("0.75 per guest" vs "1/4 won't come") and treats them as separate conditions.
The LLM's strength: Models are excellent at working with structured data and explicitly defined relationships. Show the model "entity A is linked to entity B through relationship X" and it will reason correctly. This holds even for languages the model knows less well: structure is universal.
How the method leverages that strength: SoT converts fuzzy linguistic expressions into an explicit structure of relationships. The model first thinks in English (where it has the most experience), then extracts the skeleton of the problem: who, what, how much, how it's connected. Language-specific expressions are decoded in a separate step so cultural idioms don't get tangled up with the math. The upshot: the model reasons at the level of relationships, not words, which removes the ambiguity of non-English phrasing.
Control levers:
- Thinking language (step 1): keep the original language for simple tasks; switch to English for complex calculations → token savings vs. accuracy
- Structuring depth (step 2): ask for only the key entities or a full relationship graph → speed vs. detail
- Linguistic explanations (step 3): drop this step if you're sure the wording is unambiguous → fewer steps, but a risk of missing an idiom
- Output format: ask the model to show intermediate steps or just the final answer → transparency vs. brevity
Prompt Template
I'll give you a problem in {source_language}. Apply the SoT (Structured-of-Thought) method:
Step 1: Restate the problem in English and think in English
Step 2: Extract all entities (numbers, units, objects) and their relationships in structured form
Step 3: Explain language-specific expressions (idioms, cultural conventions)
Step 4: Solve the problem and give the final answer in {source_language}
Problem: {your_problem}What to plug in:
{source_language}: Spanish, Chinese, Arabic, etc.{your_problem}: your task with numbers, calculations, or relationships between entities
Simplified version (when there are no language quirks):
Solve in {source_language}:
1. Think in English, restate the problem
2. Lay out the entities and relationships in structured form
3. Answer in {source_language}
{your_problem}Limitations
⚠️ Not for simple tasks: SoT adds 3-4 reasoning steps. For questions like "capital of France" that's overkill; the model will handle it anyway. The method pays off on tasks with complex relationships between entities.
⚠️ Tokens and time: The method raises token usage by ~20-40% (on average +50-100 tokens per request) and adds 0.1-0.3 seconds to response time. For most tasks you won't notice, but at high volume it can matter.
⚠️ Translation quality matters: If the model restates the question incorrectly in step 1, the error carries into the next steps. Check the intermediate output on critical tasks.
⚠️ Cultural context: The method relies on the model knowing what language-specific expressions mean. For very rare idioms or regional dialects, the model may not explain them correctly in step 3.
How They Tested It
The researchers took three kinds of LLMs (GPT-3.5-Turbo, Qwen2.5, DeepSeek-R1) and tested them on three benchmarks: MGSM (math problems in 11 languages), MSVAMP (problems with units and number semantics), and XCOPA (commonsense problems with cultural context). Each benchmark is translated from English into various languages, from high-resource (German, French) to low-resource (Swahili, Tamil).
The experiment's logic: SoT was compared against two kinds of methods. The first are training-free (DoLa, CLP, EMCEI): they also work without fine-tuning but use other techniques such as layer contrasting, adding dictionaries, or extracting cultural explanations. The second are post-training (xCoT, QAlign, MindMerger, MAPO): they require fine-tuning the model on multilingual data. The idea is simple: if SoT beats the training-free methods and comes close to post-training ones, structuring works.
The surprise: SoT reached 76.5% accuracy on MSVAMP (vs. 73.9% for the best training-free method, EMCEI, and 76.2% for the best post-training method, MindMerger). On MGSM: 68.3% (vs. 66.3% for EMCEI and 66.0% for xCoT). In other words, a method with no fine-tuning beats methods WITH fine-tuning. That suggests the problem isn't a lack of data but misunderstanding the structure of the question.
Key insight: The researchers checked what each step contributes on its own (Table 3 in the paper). It turned out that step 2 (structuring) and step 3 (language quirks) together give 61.6% accuracy, nearly as much as the full method (62.8%). Meanwhile step 1 (switching the thinking to English) adds only 1.2%: a bonus, not the foundation. So structure matters more than translation.
Another takeaway: when SoT was combined with CoT (Chain-of-Thought) and few-shot examples, results rose to 78-79%. So the method doesn't conflict with other techniques; it complements them. The authors showed that SoT extracts an average of 2.93 structured facts per problem and adds 1.76 language-specific explanations: not an overload, but enough for the model to get the point.
Original Prompt from the Paper
Context: The researchers applied SoT through a 4-step prompt. Here's their original instruction:
Given the sentence X in source language Ls, apply the following steps:
Step 1: Language Thinking Transformation
Transform your reasoning from Ls to Lt (English). Express your thought
process in Lt.
Step 2: Structured Knowledge Extraction
Extract entities, numerical values, units, and their relationships from
the text. Represent this as structured knowledge K.
Step 3: Language-Specific Knowledge Injection
Identify language-specific expressions in Ls (idioms, cultural phrases,
numerical conventions). Explain them in the context of the problem.
Step 4: Answer Generation
Based on the reasoning in Lt, structured knowledge K, and language-specific
knowledge, generate the final answer. Return the answer in Ls.
Now solve: [your question in Ls]Adaptations and Extrapolations
💡 Adaptation for foreign-language documents:
If you work with legal texts, contracts, or technical specs in another language (say, a German or Spanish supplier contract), SoT helps you extract the key terms and how they connect. After step 2, add an extra block: "Flag contradictions and dependencies between clauses".
Analyze this contract using the SoT method:
1. Restate the key terms in English
2. Extract: parties, amounts, deadlines, obligations, penalties, and structure them
3. Explain specialized legal terms (e.g., "joint and several liability")
4. Find contradictions between clauses or dependencies (if A, then B can't be fulfilled)
5. Give a summary in the contract's original language
Contract: {text}💡 Adaptation for educational content:
If you're explaining a tough topic to students or colleagues in a language other than English, use SoT as a clarity check. After writing the explanation, ask the model to run steps 1-2 on your text: if the structure extracts easily, the explanation is clear. If the model gets confused, rephrase.
Check my text for clarity using the SoT method:
1. Restate the key ideas in English
2. Extract the main concepts and how they connect
3. Find spots where language could cause misunderstandings
If the connections in step 2 are unclear, show exactly where and suggest a rewrite.
Text: {your explanation}🔧 Technique: Drop step 1 to save tokens
If the problem doesn't contain tricky cultural expressions, skip the thinking-in-English step. Keep only steps 2-3: structuring and linguistic explanations.
Solve this problem:
1. Lay out the entities, numbers, units, and their relationships in structured form
2. Explain any special expressions (if present)
3. Solve and give the answer
Problem: {question}This cuts token usage by 20-30% while keeping most of the effect.
🔧 Technique: Visualize the structure
If the problem is very complex (lots of entities and links), ask the model to draw a relationship graph in ASCII after step 2. It helps you see the logic before the calculations start.
...
Step 2: Extract entities and relationships. Draw them as an ASCII graph:
planned_guests (50)
|
v
no_shows (25% = 12.5)
|
v
actual_guests (37-38)
|
v
discount_threshold (40) --X--> discount does not applyResources
Paper: SoT: Structured-of-Thought Prompting Guides Multilingual Reasoning in Large Language Models (2025)
Authors: Rui Qi, Zhibo Man, Yufeng Chen, Fengran Mo, Jinan Xu, Kaiyu Huang (Beijing Jiaotong University, University of Montreal)
Code: https://github.com/Cherry-qwq/SoT
Key links:
- Benchmark MGSM (Multilingual Grade School Math)
- Benchmark MSVAMP (Multilingual Semantic Value Math Problems)
- Benchmark XCOPA (Cross-lingual Choice of Plausible Alternatives)