Direct answer
When classifying text offline with a local model, the recommended focus is on limiting the set of possible labels, checking the model's output for correctness, and ensuring that text which does not fit any known label is kept aside rather than forced into a category. Nothing beyond this focus should be inferred or added.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Label taxonomy
- Versioned fixtures
- Unknown-label behavior
Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.
Implementation workflow
Three pieces of evidence should be recorded and compared: the label taxonomy used by the system, a set of versioned fixtures that the classifier is evaluated against, and the behavior observed when an input carries an unknown label. These records provide a stable basis for checking future runs and for confirming consistency between the offline results and expected outcomes.
- 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
- Accepting arbitrary prose
- Executing labels directly
Two pitfalls should be avoided, with release wording limited strictly to what the recorded evidence supports. The first is accepting arbitrary prose as input without the restrictions defined above. The second is executing labels directly, meaning treating the model's output as an instruction rather than as a classification result. Both pitfalls should be addressed using only the evidence captured in fact cards FUNCTION-01 and BENCHMARK-01.
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 端侧专题.