Kaskor ASR

Khmer speech interfaces are held back by low-resource data, evaluation that standard word-based metrics get wrong, and research pipelines that nobody else can rerun. Most Khmer ASR work is not reproducible by a second person, which makes results hard to trust and harder to build on.

Who it serves

Developers and researchers who need Khmer speech-to-text building blocks, and — eventually — voice-first products for Khmer speakers, starting with agricultural data intake where typing is impractical.

Why it matters

Speech is the natural interface for many Khmer-speaking users, especially in field contexts. Because the training and evaluation code is public, every future improvement in data or compute can translate into a better model instead of a new unverifiable claim — even though the raw audio itself stays private.

My exact role

Sole builder of the public pipeline: data preparation, training and evaluation scripts, CLI packaging, and documentation.

Team contributions

Independent project.

Research

Studied why word error rate misleads for Khmer — the script does not separate words with spaces, so WER punishes segmentation choices rather than recognition quality. Character error rate became the primary metric, with WER kept only as a secondary signal, and the reasoning is documented in the repository.

Validation so far

Evaluation runs on a held-out split through the repository's own evaluation script. There is no external benchmark or third-party validation yet — the published numbers are self-reported and the README says so.

One repository that packages the entire path from raw Khmer audio to a trained, exportable model: dataset inspection, manifest building, resampling, speaker-stratified splitting, feature caching, training, evaluation, export, and a pip-installable transcription CLI for files, folders, and microphone input.

User workflow

1. Inspect the raw audio dataset and build CSV manifests
2. Resample audio to 16 kHz and verify formats so preprocessing cannot hide evaluation differences
3. Split train/validation/test stratified by speaker
4. Cache features, then fine-tune Whisper-small
5. Evaluate with CER as the primary metric on the held-out split
6. Export the model and transcribe through the CLI

System architecture

A staged pipeline of eleven Python scripts with explicit inputs and outputs. Raw audio stays outside git by design; the versioned repository holds manifests, scripts, and evaluation logic, and the fine-tuned weights are published separately on Hugging Face — so both the recipe and the resulting model are public even where the audio cannot be.

Methods

Fine-tuning openai/whisper-small with Hugging Face Transformers, torchaudio preprocessing, speaker-stratified splits, feature caching for iteration speed, and CER-first evaluation chosen for the linguistics of Khmer script.

Business value

An enabling layer rather than a product: reliable Khmer speech-to-text lowers the cost of every voice-first product idea that follows, including agricultural data intake for the Chomkar direction. Framed as potential — no commercial use exists yet.

Contracts & policy considerations

The code is MIT-licensed and public, and the fine-tuned weights are published on Hugging Face. The real commercial-legal question is dataset rights: audio provenance, speaker consent, and licensing must be documented before the raw audio or any dataset is released — which is why the recordings themselves stay private.

Data & privacy

Voice recordings are personal data. Raw audio is excluded from the repository, and any future release of weights or datasets requires documented consent and a provenance review first.

Risks

• A single aggregate metric can overstate quality for underrepresented speakers, dialects, or noisy environments
• Published numbers could be mistaken for production-grade accuracy claims
• Voice data misuse — any future dataset release without consent review would harm real speakers

Technical decisions

1. Character error rate as the primary metric, because Khmer does not reliably separate words with spaces
2. Raw audio stays outside git; manifests, scripts, and evaluation logic are versioned, and the fine-tuned weights are released on Hugging Face
3. The full training pipeline is separate from the lightweight CLI that transcription users install
4. Text normalization and 16 kHz verification happen explicitly, so evaluation differences cannot hide inside preprocessing

Lessons learned

• Metric choice is a linguistic decision before it is a technical one — CER vs WER changes what 'better' means for Khmer
• Normalization and resampling silently distort evaluation unless they are explicit, versioned steps
• Reproducibility discipline (manifests, splits, scripts in git) is what turns a personal experiment into something others can build on

What gets validated next

• Evaluate by speaker, province, recording device, and noise condition
• Publish a model card with dataset composition and known failure modes
• Measure latency and accuracy inside a real voice-first product workflow