Synthetic Data Hackathon - AMD

Fri, 31 Oct 2025 17:15:52 +0000

Finalist Submission Methodology & Technical Deep Dive

First and foremost, I’d like to extend my sincere gratitude to the AMD & Meta Hackathon organizers for orchestrating this intensive, high-impact competition especially for investing time in evaluating submissions, facilitating discussions, and reorganizing logistics to ensure fairness and transparency.

I also want to thank all fellow competitors for their thoughtful contributions and active engagement throughout the event particularly those who participated in Discord threads, shared early insights, or offered peer feedback. Your collaboration elevated the entire experience.

Special thanks to EDA Daniel and Sanyam for dedicating significant time to evaluate submissions, provide nuanced feedback, and help realign judging frameworks as needed.

Problem Context: Why Synthetic Data?

The core challenge of this hackathon centered around generating high-quality, domain-relevant synthetic datasets to train or fine-tune LLMs specifically for reasoning tasks involving character relationships and seating arrangement (linear and circular).

Initial approaches involved Synthetic data generation involving a assorted set of aptitude like questions from nvidia/OpenMathReasoning .

Early attempts at brute-force data generation using generic Aptitude datasets (including math, logic puzzles, and general knowledge Q&A) failed to produce usable training material because:

The semantic relationships between entities were either absent or inconsistent.
Outputs suffered from heavy repetition due to over-reliance on a single base model without diversification strategies.
Generated samples lacked contextual grounding making them unsuitable for fine-tuning models intended for relational reasoning.

This led us to abandon “scrape-and-prompt” approaches and instead design a multi-stage, relationship-aware synthetic data pipeline grounded in structured generation, guided prompting, and iterative refinement.

Methodology: Multi-Stage Question-Answer Pair Generation Pipeline

Prior to embarking on synthetic data generation, we dedicated substantial effort to curating a robust initial dataset. We recognized that a high-quality foundation maximizes training efficiency and long-term returns. Unsloth’s integration was pivotal throughout the hackathon, enabling seamless workflows without NaN errors—issues typically plaguing fp16 and quantized setups.

To produce synthetic QA pairs encoding meaningful character and plot relationships—mirroring reasoning in story-based or logic tasks—we built a streamlined pipeline. We began by defining semantic relationships among characters, such as parent-child, grandparent-grandchild, niece-nephew, and in-laws. For instance, queries like “Who is the mother of the White Rabbit?” drew on inferred or fictional roles when not explicit, forming the core of our prompt engineering.

Next, we assigned concrete names to these roles—e.g., Alice, White Rabbit, Cheshire Cat, Mad Hatter, March Hare—and framed questions around them for consistency. Prompts explicitly directed generation, e.g., “Create a multiple-choice question where the correct answer captures the relationship between [Character A] and [Character B], rooted in their story roles involving [Characters C, D, E].” This minimized hallucinations and boosted output alignment.

Finally, we applied constrained LLM inference: first supplying both question and correct answer to elicit relationship-based explanations, then reversing to generate narrative-plausible distractors from the question and context alone. This bidirectional validation enhanced quality, diversity, and noise reduction. Again using structured output generation.

One of the largely found exploit in arrangement was sorting

Thanks to the tokenisation of Language models.

A prominent vulnerability in seating arrangement tasks (linear or circular) involves alphabetical sorting of entity names. LLMs frequently err by defaulting to sorted orders when given random names, leading to incorrect inferences. We excluded such patterns from our training data to avoid propagating these flaws, as generated answers often replicated the errors.

Technical Implementation details

Model Selection & Training Setup

We experimented with several open-source LLMs known for strong reasoning capabilities:


Llama 2 70B	70B parameters
Qwen3-Next 80B MoE	80B MoE
Phi-4	Smaller, efficient
R1-based LLMs	Custom fine-tuned variants

All models were run locally or via cloud APIs with controlled temperature settings (typically 0.3–0.7) to balance creativity vs. accuracy.

Structured Output (grammar) Enforcement

One critical breakthrough was enforcing structured output formats during generation. Instead of free-form text, we required LLMs to return JSON-like structures containing:

{
"question": "What is the relationship between Alice and the Cheshire Cat?",
"answer": "Observer/Advisor",
"distractors": ["Mother", "Enemy", "Student"],
"relationship_type": "narrative_role",
"context_hint": "The Cheshire Cat provides cryptic advice but does not directly influence Alice's actions."
}

This enabled automated parsing, deduplication, and downstream integration into training pipelines.

{
 "topic": "TopicEnum.FAMILY_TREE",
 "question": "Symbolic notation: A + B → A is mother of B; A – B → A is brother of B; A % B → A is father of B; A × B → A is sister of B. Which of the following shows that P is the maternal uncle of Q?, answer=C",
 "reasoning": "P – M → P is brother of M; M + N → M is mother of N; N × Q → N is sister of Q. So, P is brother of Q’s mother → maternal uncle.",
 "options": ["A. Q – N + M × P", "B. P + S × N – Q", "C. P – M + N × Q", "D. Q – S % P"]
}

Question Generation model

// constraints

max_token_limit = 1024 timelimit for generation = 10 seconds ~100 tokens/s

Modeling Strategy

Initial Training Phase: SFT with System Prompts

We began by fine-tuning base LLMs (Llama 3 70B, Qwen3-Next 80B MoE) using system prompts similar to starter code but for faster iterations models like Qwen 4b was very benificial especially for RL finetuning.

We also added format enforcement instructions such as:

“Always include exactly four options labeled A, B, C, D. Never omit any keys. Do not use markdown or plain text only valid JSON.”

This reduced early-stage hallucinations and format violations.

GRPO Reward Functions

To overcome issues with output format and missing parts of the questions, we applied Guided Reinforcement Policy Optimization (GRPO) with custom rewards:

1.JSON Format Compliance 2.Presence of All Required Keys - Enforces inclusion oftopic,question,reasoning,options 3.Single-Character Answer Enum (A/B/C/D) -Prevents invalid answer labels like “Option C” or “C.”

These rewards were weighted during reinforcement learning phases to nudge the model toward clean, machine-readable outputs.

What Didn’t Work

Despite initial success, we encountered critical issues while infering:

Repetitive Outputs Due to Static System Prompts

Even after SFT, the model would generate near-identical questions repeatedly because the system prompt remained constant across generations.

Flawed Questions With Invalid Logic

Some generated questions had internal contradictions or unsolvable logic (e.g., “If A is brother of B and B is sister of C, then A is sister of C” false!).

(Unfinished Experimentation): Cross-Validation via Answer Model

Started with the idea of exploring using the trained Answer Generation Model as a validator:

For every generated question, we can pass it to the Answer Model and check validity:

Does it return a valid JSON?

Is the answer among A/B/C/D?

Does the reasoning match the expected logic?

This could creaties a self-correcting pipeline if the Answer Model couldn’t solve the question, the Question Model was penalized during GRPO updates.

This could have significantly improved logical consistency and reduced flawed samples.

ANSWER GENERATION MODEL

// constraints
{
"max_token_limit": 512,
"time_limit": "5 seconds (~100 tokens/sec)"
}

Modeling Strategy

Intuition Behind Design

Rather than treating this as a simple “answer extraction” task, we modeled it as a reasoning-first, answer-second process mimicking human problem-solving:

“First understand the logic. Then deduce the answer. Only then present it clearly.”

Supervised Fine-Tuning (SFT)

Trained on curated question-answer-reasoning triplets from our own dataset.

Each sample followed this schema:

{
"question": "...",
"reasoning": "... step-by-step derivation ...",
"answer": "C"
}

We had two training phases here

longer reasoning context
Shorter reasoning context

The shorter reasoning helps us in reducing the token output.

GRPO Reward Functions

Applied during iterative tuning to refine behavior beyond basic accuracy:


1.Exact JSON Pattern Match	1.0	Must match predefined schema exactly
2.Correct Answer Letter	2.0	Highest weight — getting the right choice matters most
3.Approximate JSON Pattern	0.5	Tolerates minor formatting deviations if meaning preserved
4.Presence of All Expected Keys	0.1 per key	Encourages completeness without over-penalizing

This weighting strategy prioritized correctness > structure > completeness, which aligned with our goal: build a reliable validator for the Question Generator (TODO).

Why Reasoning Matters More Than Just Answer

We found that the reasoning field is crucial for labeling correctness.

Example:

Question: “Who is P’s maternal uncle?”
Option C: “P – M + N × Q”
Reasoning: “P – M → P is brother of M; M + N → M is mother of N; N × Q → N is sister of Q. So P is brother of Q’s mother → maternal uncle.”

Without the reasoning, you can’t verify whether option C is truly correct — especially when symbolic notation varies.

Thus, we treated reasoning as a core component of ground truth, not just an explanation.

What Didn’t Work

Rewarding Low Token Usage in Reasoning

We initially tried rewarding shorter reasoning traces to encourage efficiency.

Failed because:

Often led to skipped steps or unjustified conclusions
Reduced model confidence and increased error rates - removed this reward entirely. Instead, focused on logical completeness and clarity of inference chain.

Summary

For final submissions, the question model used a base, unfine-tuned Phi-4 14B, while the answering model employed Qwen3 14B with LoRA training via SFT and GRPO. To ensure compatibility and fairness, we adhered closely to the provided submission code templates, minimizing deviations.

AI on Narain

Synthetic Data Hackathon - AMD

Finalist Submission Methodology & Technical Deep Dive

Problem Context: Why Synthetic Data?

Methodology: Multi-Stage Question-Answer Pair Generation Pipeline

One of the largely found exploit in arrangement was sorting

Technical Implementation details

Model Selection & Training Setup

Structured Output (grammar) Enforcement

Question Generation model

Modeling Strategy

Initial Training Phase: SFT with System Prompts

GRPO Reward Functions

What Didn’t Work

Repetitive Outputs Due to Static System Prompts

Flawed Questions With Invalid Logic

(Unfinished Experimentation): Cross-Validation via Answer Model

ANSWER GENERATION MODEL

Modeling Strategy

Intuition Behind Design

Supervised Fine-Tuning (SFT)

GRPO Reward Functions

Why Reasoning Matters More Than Just Answer

What Didn’t Work

Rewarding Low Token Usage in Reasoning

Summary