Direct answer
BERT and a small LLM are different approaches to mobile text extraction, and neither is a universal winner. A BERT-style encoder produces contextual representations that are typically fine-tuned with a task head for a defined problem, such as classifying text or labeling spans. A small LLM generates text from a prompt and can return an extraction in a requested format, but the output still needs schema validation and review. For a stable set of fields with strict output rules, compare a task-tuned encoder against an LLM on the same reviewed corpus. If the document is an image or scanned PDF, text recognition is a separate first step; a language model receiving extracted text has not performed OCR. Official BERT and MobileBERT papers describe encoder-based downstream tasks and a mobile-oriented model research path; Google’s Gemma mobile documentation describes on-device LLM text generation. Those sources explain candidate architectures, not a result for your product. Pin the exact artifact, task head or prompt, tokenizer, runtime, device, and test set, then measure field-level correctness, rejection behavior, memory, latency, and failures. Do not infer quality or phone fit from the word “BERT,” “LLM,” or a model-size label.
Scenario: extract maintenance fields from short field notes
A field-service team wants a phone feature to extract an asset identifier, issue category, date, and assigned action from a typed maintenance note. The fields are known in advance and downstream software expects a fixed schema. Some notes omit a value or contain negation, such as “do not restart until inspected.” The team is considering a fine-tuned BERT-style encoder and a small instruction-tuned LLM, but has no matched mobile measurements for this task.
Decision
Use a versioned synthetic or consented corpus with reviewed field labels, and require both candidates to produce the same schema with an explicit missing-value representation. Compare the encoder’s task-specific output head with the LLM’s generated-and-validated output. Score omissions, invented fields, and negation errors separately; do not treat fluent wording as extraction accuracy.
Expected outcome
The team learns which exact artifact and runtime meets the prewritten extraction criteria under its device test conditions, or that neither has enough evidence. Any conclusion remains specific to the tested task, language, input path, and build.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Shared extraction corpus and schema
- Model, task-head, and runtime manifests
- Field-level quality, resource, and failure records
A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.
Implementation workflow
- Define the extraction target before choosing a model. List every field, allowed value, normalization rule, and missing-value behavior. Decide which text spans must be preserved exactly and what constitutes a critical contradiction. Keep extraction from typed or parsed text distinct from OCR, document layout analysis, summarization, and open-ended question answering.
- Build one labeled corpus and split it safely. Create privacy-safe examples with reviewed expected fields, including ordinary notes, abbreviations, dates, names, negations, incomplete records, and adversarial text that asks the model to ignore the extraction task. Keep training, tuning, and evaluation examples separate. Do not put private customer records into a public test repository or external labeling tool without approval.
- Pin model and task components for each candidate. For the BERT path, record the encoder checkpoint, tokenizer, fine-tuning revision, task head, and label map. For the LLM path, record the exact model artifact, prompt template, tokenizer, decoding policy, output schema, and validator. Record format conversions and model provenance; a family name alone is not a reproducible candidate.
- Keep preprocessing and output rules matched. Apply the same text normalization, truncation policy, and field definitions to both approaches. If one pipeline uses sentence splitting or entity normalization, document and version that step. Require the LLM output to parse against the same schema used to evaluate the encoder, and treat invalid JSON or omitted required fields as failures rather than repairing them silently.
- Run both candidates under the same mobile conditions. Pin the physical device, OS, app build, runtime version, backend, and network state. Warm-up and cold-start procedures should be identical where possible. Capture model-load and request phases, process memory, elapsed time, cancellation, and every failed or incomplete run. A result from a desktop or a different conversion is not a mobile comparison.
- Score field behavior, not prose style. Compare each output with the reviewed reference at the field level. Count exact matches, omissions, unsupported additions, wrong normalization, and negation reversals. For a high-risk field, define whether the correct response is a value, an explicit unknown, or refusal. Keep human review in the product path until the required evidence and policy are established.
- Publish a bounded decision and preserve artifacts. Report the corpus revision, label policy, encoder and task head, LLM artifact and prompt, preprocessing, runtime, device, OS, metrics, and failures. State what was not measured. Do not claim that one architecture is faster, smaller, more accurate, or more compatible in general based on one task or a single phone.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Both systems receive the same text, field schema, normalization policy, and evaluation examples; their distinct model and output components are fully identified.
- Required values, missing values, negation, invented fields, and malformed output are scored against reviewed labels with failures retained.
- Runtime, device, memory, and timing observations come from the exact tested mobile configurations and include method and failed runs.
- The conclusion is task-specific and does not infer general architecture quality, OCR support, device compatibility, or production readiness.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Task shape | BERT-style encoder with a fine-tuned classification or span-labeling head | A candidate when fields and label rules are stable; evaluate the exact head and labels rather than the encoder name alone. |
| Task shape | Small LLM prompted to generate a fixed-schema extraction | A candidate when instructions or output need more flexibility; validate every generated field and malformed response. |
| Input is a scan or photo | OCR or text recognition before either language-understanding path | Recognition and extraction are separate stages; a BERT or LLM receiving text has not proven image recognition. |
| Missing or ambiguous field | Use the same explicit unknown, reject, or human-review policy | Compare whether each pipeline invents a value or correctly leaves it unresolved. |
| Mobile deployment evidence | Pin one device, artifact, runtime, backend, and representative workload | Architecture papers and mobile positioning do not replace measurements for the tested stack. |
Failure patterns to prevent
- Comparing OCR with language understanding
- Ranking from model size or architecture alone
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
Release checklist
- ☐ The primary query is answered without an unsupported number.
- ☐ Every artifact and runtime is pinned.
- ☐ The representative task and failure policy are explicit.
- ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
- ☐ User-content and network boundaries are documented.
- ☐ Result wording applies only to the recorded configuration.
- ☐ The page links to raw method or evidence when results are added.
Sources and related evidence
- Cove benchmark method
- ML Kit text recognition
- Google Research — BERT pre-training and downstream tasks
- ACL Anthology — MobileBERT for resource-limited devices
- Google AI for Developers — Deploy Gemma on mobile devices
- Google ML Kit — Text recognition structure
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Is BERT or a small LLM more accurate for mobile text extraction?
There is no task-independent answer established by the model names. BERT-style encoders are commonly fine-tuned for task-specific outputs, while an LLM generates text from instructions. Compare both on the same reviewed corpus, schema, device, and error rubric, including omissions, invented values, and negation.
Can BERT or a small LLM extract text directly from a photo?
Not from the architecture labels alone. A photo or scanned page needs an image-to-text recognition stage. Then a language model or task-specific extraction model can process the recognized text. Measure OCR and field extraction separately so recognition mistakes are not counted as model reasoning errors.
Does BERT naturally return JSON?
A BERT encoder is not a general text-generation decoder. A deployment usually maps its representations to a task-specific output such as labels, spans, or classification scores, then application code can serialize those values. Verify that mapping and the schema explicitly; do not assume it works because the encoder is pretrained.
Can a small LLM return structured fields offline?
A local LLM runtime can generate text on a mobile device when the exact model and required assets are available, but this does not establish that a specific extraction app or configuration works offline. Test a fresh request with connectivity disabled, parse the result against a schema, and account for invalid or unsupported values.
Which approach uses less memory or runs faster on a phone?
This cannot be inferred from the architecture names alone. Model artifact, precision, tokenizer, runtime, task head, context, preprocessing, and device all affect resource use. Measure both exact candidates with the same workload and report storage separately from process memory and request timing.