Resources

Piloting a Burmese-Language AI Chatbot on Small Dataset

nyeinchanaung.mr@gmail.com (Nyein Chan Aung) — Wed, 09 Sep 2026 08:29:27 GMT

At a previous company, I managed the development of a pilot AI chatbot meant to help Burmese-speaking farmers get faster answers to seasonal farming questions - pest and disease pressure, fertilizer timing, that kind of thing. It's an old project from a former employer, so I won't name the product here; what I want to write about honestly is the pilot itself, because the result wasn't very good, and I think the reasons why are more useful to talk about than the reasons a project went well.

Why we built it

The team behind the platform was already running a farmer advisory channel by hand - answering around 300 questions a month, publishing roughly 170 seasonal articles, and fielding about 1,500 comments, all in Burmese. The honest bottleneck wasn't a lack of expertise; it was throughput. Replies were taking up to 24 hours, a large share of the questions repeated each other almost verbatim, and reporting on what farmers were actually asking was scattered across different app versions and social channels with no single view. An AI-assisted first response looked like a reasonable way to close that gap - not to replace the advisory team, but to take the repetitive volume off their plate and let them focus on the questions that actually needed a person.

Figure 1. Technical Architecture

What we built, and why the approach itself was sound

We fine-tuned SeaLLMs-v3-7B-Chat - a 7-billion-parameter model with native Burmese support - using QLoRA: 4-bit quantization plus low-rank adapters that only touch about 0.1% of the model's parameters. That choice deserves credit on its own. It meant a full training run fit on a single AWS SageMaker GPU instance, took two to three hours, and cost roughly four to five dollars a run. For a pilot with a real budget ceiling, being able to iterate for a few dollars at a time - instead of needing a multi-GPU cluster - was the right call, and it's a pattern I'd reach for again on any resource-constrained AI pilot.

The serving design was the other thing that held up well: every response came back with a confidence score, and that score routed the response rather than just decorating it. Above 0.6 confidence, the bot answered directly. Between 0.3 and 0.6, it answered but attached a disclaimer and logged the exchange for review. Below 0.3, the question was queued for a human expert instead of being answered at all. That's a genuinely responsible way to ship a model you don't fully trust yet - the system was designed to know what it didn't know, rather than to guess confidently and hope.

Figure 2. Operational and Performance Result

Where it actually fell short

Here's the part that's less flattering, and the reason I wanted to write this at all.

The training set was small - 527 Q&A pairs total, split down to 385 actual training examples once we set aside data for validation and testing. About a third of that came from the platform's own farmer support history; the rest came from supplementing it with a public Burmese-language agriculture dataset, just to get to a workable size. A later review of the project recommended scaling that up to 15,000-plus examples: 3,000 or more per crop category, to get to something resembling robust coverage. We were short of that by roughly a factor of ten.

The evaluation results reflected it, in a specific and instructive way. The confidence metrics looked excellent on paper - 94.5% average confidence, and a 0.708 correlation between the model's confidence and the actual quality of its answers, which is a genuinely strong calibration result. But confidence isn't correctness, and this is where the small-dataset problem actually bit us: the text-quality metrics that would have told us whether the content of the answers was accurate - BLEU, ROUGE, chrF, the standard measures for comparing generated text against a reference answer were never actually computed on the real evaluation run, because the tooling for it hadn't been fully installed on the training infrastructure at the time. So the one number that mattered most for a farming product- is this factually right- is the one number we didn't reliably have. A well-calibrated model that's confidently wrong about fertilizer timing is worse than a model that hedges, and we didn't have the instrumentation in place to rule that out at scale. We were relying on spot-checking rather than a real quality score, which is a smaller and less rigorous safety net than it should have been.

Latency and throughput missed their targets too - average response time of about 11.6 seconds against a 5-second target, generation speed under the target range - which matters more than it might seem for a product where farmers are asking time-sensitive questions in the field, sometimes on a poor connection.

Takeaway 1: An AI that "Knows What It Knows"

The true breakthrough of this project isn't just raw intelligence; it’s an unprecedented level of "honesty." By implementing rigorous calibration metrics, we achieved a 0.708 correlation between the model’s internal confidence and the actual quality of its output.

In emerging markets, AI is not just a tool—it is a risk management strategy for the underserved. A model that "hallucinates" an answer to a crop disease query can lead to total harvest failure. Therefore, model calibration is the ultimate form of risk mitigation. This correlation is a surprising achievement, proving the model acts as its own internal auditor.

"A well-calibrated model gives high confidence to correct answers and low confidence to uncertain ones, enabling reliable Human-in-the-Loop (HITL) routing."

This calibration ensures that when the AI is unsure, it remains silent and seeks help. In agricultural advisory, a model that knows when it is wrong is objectively more valuable than a model that is right 100% of the time but cannot flag its own errors.

Takeaway 2: High Performance on a Shoestring Budget

We are often told that elite AI requires Silicon Valley-sized budgets. This project shatters that myth through what I call computational frugality. By utilizing QLoRA (Quantized Low-Rank Adaptation) on AWS SageMaker , we deployed a sophisticated model with elite-level performance for the price of a cup of coffee.

The secret sauce behind this memory efficiency on the ml.g5.2xlarge instance included:

4-bit Quantization (NF4): Slashed memory requirements from 28GB to approximately 8GB.
Secret Technical Sauce: The use of Flash Attention 2 support and gradient checkpointing allowed us to maximize the 24GB VRAM of the single NVIDIA A10G GPU.
Radical Efficiency: Each training run cost a mere $4 to $5.
Precision Training: LoRA adapters required training only 0.1% of the total parameters, focusing specifically on attention layers (q, k, v, o_proj).

This proves that specialized, high-impact AI can be democratized, allowing localized tools to thrive without massive infrastructure overhead.

Takeaway 3: The Power of Native Language Models

Generic, Western-centric LLMs often treat Southeast Asian languages as an afterthought. We bypassed this by selecting SeaLLMs-v3-7B-Chat as our foundation. This "Language-First" design is the only way to prevent the generation issues that plague general models when dealing with Burmese script.

Data quality was our North Star. We implemented a rigorous process of Unicode normalization and standardized the use of the "။" (the Burmese period) to ensure structural integrity.

"The data quality process highlighted the importance of domain-specific agricultural terminology and real-world queries from farmers to prevent generation issues and ensure the AI speaks the language of the field."

By starting with a model natively optimized for the syntax and nuances of Myanmar, our fine-tuning could focus on agricultural expertise rather than teaching the AI basic linguistics.

Takeaway 4: The "Confidence Gatekeeper" Workflow

Trust is built through safety. To ensure the platform remains the gold standard for advice, we implemented a Human-in-the-Loop (HITL) routing system that functions as a "Confidence Gatekeeper." Responses are directed based on precise probability thresholds:

High (≥0.6): Direct response to the farmer.
Medium (0.3 - 0.6): The AI responds but includes a localized disclaimer: "ဤအဖြေသည် AI မှထုတ်ပေးသည့် အကြံပြုချက်ဖြစ်ပါသည်။" (This response is an AI-generated suggestion).
Low (<0.3): The query is immediately routed to a human expert.

We proved the efficacy of this system during a "Shadow Mode" pilot, where AI suggestions were shown only to experts. In this phase, the AI suggestions were validated by experts at a 90%+ rate , providing the credibility needed for full deployment. In the review interface, experts can Approve, Edit, Reject, or Escalate, creating a continuous loop of improvement.

Takeaway 5: From 1,500 to 15,000—The Data Scarcity Reality Check

There is a sobering reality in emerging market AI: the data scarcity is real. Our initial success was built on a combined corpus of roughly 1,500 Q&A pairs —500 meticulously sourced from Village Link field data and 1,000 from the Burmese Agriculture public dataset. While this was a strong foundation, mastery requires scale.

Architectural Mandate: The Road to 15,000. For production-grade reliability across Myanmar’s diverse landscape, we require 3,000+ Q&A pairs per crop type . Data scarcity isn't a failure; it is the fuel for our continuous improvement phase, where every expert correction is fed back into the model to reach our goal of 15,000+ entries.

This scale is necessary to move from general advice to local specialization, accounting for specific soil types and regional climate zones.

The honest verdict

Put together, the pilot didn't reach a bar where it could stand in for the advisory team's judgment, and it would have been the wrong call to represent it as more capable than it was. What it did prove was that the architecture - a cheaply fine-tuned small model, gated by its own confidence score, backstopped by a human queue for anything uncertain - is a sound way to introduce AI into a workflow like this without overpromising. The gap wasn't the design. We asked a model to learn Burmese agricultural nuance from about 1,500 examples when the realistic number was closer to fifteen thousand, and we didn't have quality metrics in place to catch that gap early instead of discovering it in the results.

If I were scoping this pilot again, I'd treat the dataset size and the evaluation tooling as first-class requirements before writing a line of training code, not as line items to reconsider once the model was already running. A confidence-based safety net is a good idea. It's not a substitute for enough data to actually be confident about.

What Ten Years of Two-Week Sprints Taught Me About Realistic Estimation

nyeinchanaung.mr@gmail.com (Nyein Chan Aung) — Tue, 08 Sep 2026 10:03:44 GMT

I've run roughly two hundred and fifty two-week sprints. That number surprised me when I actually sat down and counted it — from a scrum-master seat at 360ed in 2018, through years of product management at Village Link, to the loan and traceability platforms I still advise on today. Same rhythm, same ceremonies, wildly different domains: education apps, microfinance wallets, an agri-social platform that now serves 300,000+ farmers.

What didn't stay wildly different was how often my estimates were wrong. Not because the team was bad at guessing — because for a long time, we were guessing, and calling it estimation.

This is the honest version of what actually got our estimates closer to reality. No framework claims a permanent fix here; these are five habits that moved the needle for me, in the order I learned them the hard way.

1. Separate the known work from the unknown work — don't average them together

In 2021, we migrated roughly a hundred thousand user records from Htwet Toe's legacy system to a new platform. I scoped it the way I scoped everything else at the time: break it into tickets, estimate each ticket, sum the tickets. The total came out confident and wrong.

The problem wasn't the estimating technique. It was that "migrate the data" and "build the new onboarding form" don't carry the same kind of uncertainty, and averaging them into one backlog hid that. The onboarding form was well-understood work — we'd built a dozen forms before. The migration touched a system nobody on the current team had designed, with edge cases nobody had catalogued yet.

Now I split those two categories explicitly. Well-understood work gets a normal estimate. Anything touching unfamiliar systems, a first-time vendor integration, or code nobody currently on the team wrote gets a short, timeboxed investigation first — a spike, sized in hours, whose only deliverable is a real estimate for the work behind it. It feels slower up front. It's faster than re-estimating mid-sprint.

2. Let the person doing the work size the work

For longer than I'd like to admit, I sized tickets myself and handed them to developers as fully-formed assignments. It was efficient in the way that skipping a step is always efficient — right up until the actual hours came back nothing like the plan.

The fix was almost embarrassingly simple: ask. The developer who's going to write the code has context I don't — which library is fighting them lately, which part of the codebase is fragile, what "similar" ticket from last sprint actually took twice as long. Estimation improved measurably once sizing moved from something I did to the team to something I did with them.

3. A buffer is not padding — it's an honest number with a name

Early on, "padding an estimate" felt like something to be a little ashamed of, so I didn't do it consistently, and the estimates that needed it most usually didn't get it. What changed my mind was realizing there's a real difference between padding and buffering.

Padding is adding time you can't justify because you don't trust the number. A buffer is a named, sized allowance for a specific category of risk you can point to — waiting on a partner vendor's API, working with agricultural data collection that depends on field connectivity, or building against a spec that's still being negotiated with a client. On projects like the MMTW loan and POS system, where cash and in-kind loan logic had to be worked out with the partner as we went, an explicit 15–20% schedule buffer wasn't pessimism. It was the most accurate number on the page.

4. Track estimate versus actual, every single sprint, even when it's uncomfortable

For the first few years, we ran retros that talked about what got built and rarely about how far off we'd been in predicting it. Once I started keeping that number — estimated hours versus actual hours, every sprint, visible to the team — two things happened. First, the gap got smaller within about three sprints, mostly because visibility alone changes behavior. Second, patterns showed up that no single sprint would have revealed: certain types of tickets (anything touching offline sync, in our case) were consistently underestimated by a wide, predictable margin, which meant we could finally correct for it directly instead of hoping the next one would be different.

5. A quarter-long initiative needs a different kind of estimate than a sprint story

Somewhere around the point where I was managing multi-month engagements — the AWBA Force IQ field-monitoring platform, the multi-year MMTW loan system — I learned that trying to estimate an eight-month initiative in the same units as a two-week story just produces false precision. Nobody can size "build a field-force monitoring platform" in story points with a straight face.

What worked instead was estimating in two layers: a rough, range-based T-shirt estimate at the initiative level (small / medium / large, revisited every few sprints as scope firms up), and normal sprint-level estimation only for the slice of work that's actually been scoped in detail. Trying to make the whole eight months precise on day one wastes effort estimating things you don't understand yet — and quietly signals a confidence you don't have.

The thing I'd tell myself ten years ago

None of this made estimation exact — it isn't supposed to be. What it did was turn estimation from a number I defended into a number the team trusted, which is a different and more useful thing. The habits above are less a system and more a record of where the guessing kept breaking and what we did instead.

If it's useful, I put together the actual template I use for this — a sprint backlog with built-in variance tracking, a capacity planner with a named buffer field, and an estimation-accuracy tracker that rolls up automatically from the other two. It's a working spreadsheet, not a mockup — download it below and adapt the categories to your own team.

PRDs Developers Actually Want to Read

nyeinchanaung.mr@gmail.com (Nyein Chan Aung) — Tue, 08 Sep 2026 08:51:42 GMT

A few years ago I wrote a PRD for a rice traceability tool — ShweBo Trace, built at Village Link to help track Shwe Bo Pawsan rice from seed to package, in support of the region's bid for Geographical Indication status. Twenty pages, slide-deck format: assumptions, scope, diagrams, a transaction flow, a glossary, UI sketches. I still think it's one of the more complete PRDs I've written, and going back through it recently to write this post, I noticed exactly where it was strong and exactly where a developer would still have had to walk over and ask me a question.

That gap is what this post is actually about. Not a general theory of documentation — a specific, honest look at one real PRD, what worked, and what I'd add if I wrote it again today.

What the ShweBo Trace PRD got right

An explicit assumptions section, treated as load-bearing. Most of what made this document useful wasn't the feature list — it was a section near the top that stated, plainly, things like: transactions are made offline by scanning a QR code, a synced transaction can't be edited except by manual admin request, a pending transaction needs both parties to cancel it, and — critically — a transaction can be totally or partially lost if a device breaks before syncing, or a user logs out before syncing. That last one isn't a nice-to-know. It's the kind of fact that changes how a developer builds the sync logic, and it was written down before a single screen was designed.

Scope broken out by actor, not by screen. The mobile app scope wasn't "here are the app's features" — it was "here's what an Input Supplier does, here's what a Farmer does, here's what a Miller does." Four different actor types, each with their own login-to-transaction path. That structure is what let five different field roles share one offline-first app without the requirements turning into a single undifferentiated wall of bullet points.

A glossary — "Terms of Reference" — for words that don't mean what they sound like. "Realtime transaction" doesn't mean real-time in this system; it means "reported once synced, which might not be immediately." "Batch code" refers to merged paddy from multiple transactions, not a build identifier. Naming and defining these terms in one place heads off the kind of misunderstanding that otherwise surfaces three sprints later as a bug report against the wrong expectation.

Diagrams that show what the prose can't. A process-flow diagram across CMS admin and each mobile actor, and a system-design diagram showing the physical-to-digital handoff from buying seed through export. Neither replaces the written scope — they compress a page of "and then this actor does X, which triggers Y" into something a developer can trace with a finger.

Where I'd add to it today

No goals or success metrics. The document says what to build in real detail. It never says what "working" looks like in a number. That's fine when the same person who wrote the PRD is also the one deciding when it's done — it stops being fine the moment a second stakeholder has a different idea of "done" than the delivery team does.

No explicit non-goals. To be fair, this PRD does state two real limitations directly in the assumptions — no mobile payment integration ("farmers and traders prefer cash for the time being"), and certificate validation can't trace offline transactions. Both are genuinely well-handled. What's missing is a dedicated section that collects boundaries like these in one place, so a reader doesn't have to find them scattered inside the assumptions to know what's deliberately out of scope.

Flat feature bullets instead of testable stories. "Farmers: Sowing, Harvesting, Selling to Aggregators" tells a developer what to build. It doesn't tell them what "done" means for Harvesting specifically — that the volume has to be checked against an estimated maximum yield, or what happens when it's exceeded. That detail exists elsewhere in the document (in the digital rules, in a UI sketch showing "Estimated Maximum Yield: 125,000 Kg"), but it isn't attached to the requirement it belongs to. A developer ends up assembling the actual acceptance criteria from three different pages.

No priority. Every requirement reads with equal weight. When a deadline gets tight — and on a twenty-month project like this one's related loan-management system, it will — someone has to decide what ships and what waits, and without a priority already assigned, that decision happens live, under pressure, instead of calmly in the document.

Third-party dependencies with no owner. The PRD correctly lists what the system depends on — domain and hosting, SSL, SMS for OTP, Firebase for notifications. It doesn't say who owns getting each one in place, or by when. That's usually the thing that quietly slips a launch date while every actual feature is finished on time.

The template

I turned the gaps above into a standard structure I now use for every PRD: the same sections that worked in the original (assumptions, actor-based scope, a glossary, room for diagrams), plus what was missing (goals and metrics, non-goals, user stories with acceptance criteria and priority, a dependencies table with an owner column, and a risks/open-questions section that gives an unresolved question a place to live instead of a Slack thread).

[Download: PRD Template — Developer-Friendly Edition (.docx)]

And because a blank template only shows half the point, I also rewrote the actual ShweBo Trace PRD into this structure — same real project, same real assumptions and rules, restructured so you can see exactly what changed and why. Nothing about the product's scope is different from the original; what's different is that a developer could now build several of its core flows straight from the acceptance criteria without asking me anything first.

Htwet Toe Case Study - Agri-Social Platform

nyeinchanaung.mr@gmail.com (Nyein Chan Aung) — Tue, 08 Sep 2026 06:31:19 GMT

A mobile-first advisory platform helping agricultural communities in Myanmar increase yield and productivity — professional advice, solutions, and services in one app.

The problem

Farmers needed direct access to expert advice

Agricultural communities across Myanmar lacked an easy way to get professional, timely advice on inputs, techniques, and services that could improve yield and productivity — most support was informal, inconsistent, or came too late in the season to act on.

Village Link set out to close that gap with Htwet Toe: a mobile-first platform bringing advisory content, solutions, and services directly to farmers' phones.

My role

From vendor manager to in-house product lead

I joined to manage the relationship with the partner vendor's team that originally built the platform — scoping work, reviewing delivery, and keeping quality and timelines on track.

As the product matured, I led the transition to a fully in-house development team, and now lead that team directly through the active development of Version 2.0 — spanning the web app, mobile app, and content management dashboard.

Screenshots of Htwet Toe Mobile Application
(Scr. Htwet Toe Play Store)

What we built

Three connected surfaces, one platform

Mobile-first farmer app — advisory content, solutions, and services designed for low-connectivity use, the primary surface for the 300,000+ registered farmers.
Web app — companion access for partners and field teams working alongside farmers.
Content management dashboard — internal tooling that enables the team to publish and update advisory content without engineering involvement.
Legacy data migration (2021) — moved hundreds of thousands of user-generated records from the original system onto the new in-house platform with no loss of continuity for existing farmers.

Product roadmapping, Vendor management, Agile delivery, Data migration, Team building

Playstore: Htwet Toe - Apps on Google Play AppStore: ‎Htwet Toe App - App Store