Direct answer
Treat on-device entity extraction as a layered workflow that distinguishes literal text spans, normalized fields, downstream validation, and a user review stage, without inferring additional stages, data flows, or external dependencies beyond what is stated. Every action belongs to one of these named parts, and boundaries between them are kept explicit and verifiable.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Entity schema
- Span-level fixtures
- Ambiguous and missing cases
Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.
Implementation workflow
Record and compare the entity schema, span-level fixtures, and the catalog of ambiguous and missing cases as the evidence base for assessing an on-device extractor. These items, taken together, describe what is being extracted, how the raw text is aligned, and where the dataset intentionally fails or withholds information, supporting repeatable comparison across runs.
- Write the user promise and offline requirement.
- Separate source data from derived output.
- Define typed stage contracts.
- Create privacy-safe fixtures and expected properties.
- Test each stage without hiding partial failure.
- Run the complete task in airplane mode and through lifecycle changes.
Failure patterns to prevent
- Inventing missing entities
- Discarding source locations
Two pitfalls constrain release wording: inventing missing entities, which is the hazard of fabricating values the source does not contain, and discarding source locations, which is the hazard of losing the span positions tied to each literal extraction. Release statements are limited to evidence recorded under FUNCTION-01 and BENCHMARK-01, with no extrapolation beyond what those artifacts document.
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
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.