margent-planner-qwen2.5-3b-lora

Uploaded model

• Developed by: hatheemr
• License: apache-2.0
• Finetuned from model : unsloth/Qwen2.5-3B-Instruct-bnb-4bit

---

MARGENT Planner — Qwen2.5-3B LoRA

A LoRA adapter that replaces the planner node of MARGENT (Lanka Market Scout), a LangGraph multi-agent system that researches business ideas for the Sri Lankan market.

Given a business idea and the user's prior-analysis history, it emits a strict ResearchPlan JSON object: a restated idea, 3–4 market questions, 2–3 pricing questions, and 3–5 competitor seeds — all specific enough to be fed directly to a web search tool.

The fine-tuning was prominently initiated to improve model to derive plans specifically for Sri Lanka.

The adapter was trained to replace gpt-4o-mini at this one node, so the pipeline can run a locally-hosted model where the task is narrow and schema-constrained, while keeping a frontier model for open-ended writing.

• **project MARGENT GitHub Repo : https://github.com/hatheem-r/project-MARGENT

Results

Evaluated on 40 held-out examples, greedy decoding, compared against the untuned base model on the identical prompt.

What actually improved

The base model was already reliable at format: it produced valid JSON with the right keys and list lengths on every single example. Fine-tuning changed something else — grounding.

Untuned, the model wrote generic market-research questions ("what are current consumer trends in this sector") that return nothing useful when passed to a search tool. After fine-tuning, questions consistently name the market, a city, a currency or a year ("coffee consumption trends Sri Lanka 2024", "average monthly rent for retail space in Nugegoda LKR"). Since every downstream node in MARGENT depends on these questions being searchable, this is the difference between a working pipeline and a pipeline that retrieves noise.

Latency increased because the tuned model produces fuller, more specific plans rather than terse generic ones — an accepted trade for usable output.

Usage

from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(
    model_name     = "USERNAME/margent-planner-qwen2.5-3b-lora",
    max_seq_length = 2048,
    load_in_4bit   = True,
)
FastLanguageModel.for_inference(model)

SYSTEM_PROMPT = (
    "You are planning market research for the SRI LANKAN market specifically.\n"
    "Create a research plan for the given business idea.\n"
    "Questions must be concrete and searchable "
    "(good: 'coffee consumption trends Sri Lanka 2024', "
    "bad: 'what is the market like'). "
    "Competitor seeds should be real Sri Lankan or regional companies where "
    "you know of any, otherwise specific categories to search for.\n"
    "Respond with ONLY a JSON object with these keys: "
    "product_idea (string, one-sentence restatement), "
    "market_questions (3-4 strings), "
    "pricing_questions (2-3 strings), "
    "competitor_seeds (3-5 strings)."
)

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},
    {"role": "user", "content": (
        "Business idea: a mobile bicycle repair service for office workers in Colombo\n\n"
        "Context from this user's history (use it to avoid repeating work and to "
        "personalize):\nNo previous analyses for this user."
    )},
]

text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
enc  = tokenizer(text, return_tensors="pt").to("cuda")
out  = model.generate(**enc, max_new_tokens=512, do_sample=False)
print(tokenizer.decode(out[0][enc["input_ids"].shape[1]:], skip_special_tokens=True))

The prompt format is not optional. The adapter was trained on this exact system message with the idea and history in the user turn. Changing the wording degrades output quality, often silently.

Example output

IDEA: a mobile bicycle repair service for office workers in Colombo
{
  "product_idea": "A mobile bicycle repair service for office workers in Colombo.",
  "market_questions": [
    "bicycle ownership statistics in Colombo 2024",
    "office worker commuting habits in Colombo",
    "demand for mobile services among office workers in Sri Lanka"
  ],
  "pricing_questions": [
    "average cost of bicycle repairs in Colombo",
    "willingness to pay for mobile bike repair services in Sri Lanka"
  ],
  "competitor_seeds": [
    "Bike Fix Sri Lanka",
    "Colombo Bike Rentals",
    "Sri Lanka Bicycle Tours",
    "Ceylon Cycle Rental"
  ]
}

Training

Loss was masked to the assistant turn only (train_on_responses_only), so the model is graded solely on producing the JSON, not on reconstructing the prompt.

Loss curve: train 0.571 → 0.310, validation 0.529 → 0.369. Validation decreased monotonically at every checkpoint and flattened over the final 10 steps (0.3699 → 0.3694), with a final train/validation gap of 0.06 — converged, with no sign of overfitting.

Data

Approximately 840 training and 56 validation examples, generated synthetically and distilled from a stronger teacher model using MARGENT's production planner prompt.

Input diversity was forced by rotating a grid of 28 sectors × 19 regions × 8 business scales × 9 phrasing styles, rather than sampling ideas from a single prompt (which collapses toward one archetype). Phrasing styles deliberately included terse fragments, phone-typed lowercase with misspellings, and English mixed with Sinhala/Tamil terms, so the model handles the messy input real users produce. Roughly 45% of examples carry a synthetic user-history block matching the format MARGENT's intake node emits.

Every generated sample was filtered programmatically before training:

• schema validity and exact key set
• list-length compliance (3–4 / 2–3 / 3–5)
• question length bounds and rejection of vague templates
• ≥60% of questions anchored to a locality or a year
• rejection of generic competitor seeds ("local competitors", "various companies")
• near-duplicate removal via Jaccard overlap on idea tokens

The dataset is not released.

Limitations

• Single-purpose. This adapter does one job: Sri Lankan market-entry research plans. It is not a general assistant, and general-capability regression after fine-tuning was not measured.
• The 100% scores are in-distribution. The evaluation set was drawn from the same synthetic generator as the training data. Real user inputs will be more varied, and performance on them will be lower. Treat these numbers as evidence the model learned the target behaviour, not as a general capability claim.
• Evaluation is rule-based. The metrics check structure, seed quality and locality anchoring. They do not verify that questions are strategically good or that named competitors actually exist.
• Competitor seeds are search starting points, not verified company data. Some may be hallucinated. Downstream verification is required — in MARGENT this is handled by a separate search-and-analysis subgraph.
• Latency is higher than the base model, and on a T4 it is slower than a hosted API call. The motivation here is cost control and local deployment, not raw speed.
• Small evaluation set (40 examples). Confidence intervals are wide.

License

The base model, Qwen2.5-3B-Instruct, is released under the Qwen Research License — unlike most other Qwen2.5 sizes, which are Apache-2.0. This adapter inherits those terms. Review the license before any commercial use.

Citation

@misc{margent_planner_lora,
  title  = {MARGENT Planner: a LoRA adapter for structured market-research planning},
  author = {YOUR NAME},
  year   = {2026},
  url    = {https://huggingface.co/USERNAME/margent-planner-qwen2.5-3b-lora}
}

Trained with Unsloth and Hugging Face TRL.