Qwen3.5-4B-Car-Diagnostics
A fine-tuned language model for automotive troubleshooting, OBD-II fault-code interpretation, and diagnostic decision support.
khazarai/Qwen3.5-4B-Car-Diagnostics is a fine-tuned version of Qwen/Qwen3.5-4B, developed to assist with automotive diagnostic scenarios. The model is designed to interpret reported symptoms, diagnostic trouble codes (DTCs), and measurement data; identify plausible causes; and recommend practical next steps for fault isolation.
The model focuses on structured diagnostic reasoning rather than simply listing possible component failures. Its intended output is a concise, technically grounded diagnostic recommendation that distinguishes observed evidence from hypotheses and proposes appropriate verification steps before component replacement.
This model is an experimental diagnostic assistant. It is not a substitute for an experienced automotive technician, manufacturer-specific service information, or physical vehicle inspection.
Model Details
| Property | Description |
|---|---|
| Model name | Qwen3.5-4B-Car-Diagnostics |
| Hugging Face repository | khazarai/Qwen3.5-4B-Car-Diagnostics |
| Base model | Qwen/Qwen3.5-4B |
| Developer | KhazarAI |
| Model type | Fine-tuned language model |
| Primary domain | Automotive diagnostics and troubleshooting |
| Primary input | Text-based vehicle symptoms, DTCs, and diagnostic measurements |
| Primary output | Diagnostic hypotheses, explanations, and verification steps |
| Model size | Approximately 4B parameters, inherited from the base model |
| Intended users | Automotive technicians, automotive students, researchers, and developers |
| Model status | Experimental |
| License | Apache-2.0, subject to confirmation of the distributed artifact's licensing and compliance with the base model terms |
Model Description
Automotive troubleshooting often requires interpreting multiple signals rather than treating a diagnostic trouble code as a definitive diagnosis. Similar symptoms can arise from different faults, and replacing a component without verification can lead to unnecessary repair costs.
Qwen3.5-4B-Car-Diagnostics is intended to help organize this diagnostic process. Given a textual scenario, it can analyze relationships between symptoms, fault codes, component-swapping tests, and sensor measurements to suggest a likely fault and a next diagnostic action.
The model is intended to support tasks such as:
- Interpreting common OBD-II diagnostic trouble codes.
- Connecting engine symptoms with plausible ignition, fuel-delivery, electrical, and sensor faults.
- Reasoning about component-swapping tests and whether a fault follows a component or remains with a cylinder.
- Interpreting diagnostic measurements, including crankshaft position sensor signals, fuel trims, charging voltage, and parasitic battery draw.
- Prioritizing diagnostic checks before replacing components.
- Producing structured explanations of automotive troubleshooting scenarios.
The model generates recommendations from the information provided in the prompt. It does not directly inspect a vehicle, read an ECU, operate diagnostic equipment, or independently verify that a proposed repair resolves the fault.
Intended Use
Primary Use Cases
1. Diagnostic trouble code interpretation
The model can help interpret codes such as P0300, P0302, and P0303 in the context of reported symptoms and test results.
2. Fault isolation
The model can suggest procedures to distinguish between competing hypotheses, such as an ignition coil failure, a wiring fault, or a sensor-related problem.
3. Sensor and measurement interpretation
The model can analyze provided readings and explain how they may support or weaken a diagnostic hypothesis.
4. Next-step recommendations
The model can recommend a practical verification step before a component is replaced, rather than treating a symptom or trouble code as sufficient proof of failure.
5. Automotive education and research
The model can support learning, diagnostic case discussions, and research into specialized language models for automotive troubleshooting.
Out-of-Scope Uses
The model is not intended to:
- Replace professional vehicle inspection or manufacturer-approved diagnostic procedures.
- Guarantee a correct diagnosis from incomplete or ambiguous information.
- Independently authorize component replacement or vehicle release.
- Provide safety-critical repair instructions without expert verification.
- Diagnose every vehicle make, model, engine configuration, or electronic control system with equal reliability.
- Substitute for current technical service bulletins, wiring diagrams, service manuals, or vehicle-specific specifications.
- Serve as a standalone autonomous repair system.
Evaluation
Preliminary Qualitative Evaluation
The model was examined using five text-based automotive diagnostic scenarios. The cases covered intermittent ABS sensor faults, heat-related engine stalling, fuel-trim interpretation, cylinder misfires, and parasitic battery drain.
The evaluation focused on diagnostic plausibility, use of evidence, quality of the recommended next step, clarity, and unnecessary repetition.
| Test | Diagnostic scenario | Observed fine-tuned model behavior |
|---|---|---|
| 1 | ABS wheel-speed fault appearing during cornering | Produced a concise hypothesis involving a connector or ground issue. The available evidence was insufficient to establish that this was the correct cause. |
| 2 | Engine stalls when hot; crankshaft position sensor RPM signal drops to zero | Identified a failing crankshaft position sensor as the leading suspect and recommended further signal verification. Wiring and connector faults remain alternative explanations. |
| 3 | Negative long-term fuel trim combined with fuel pressure above specification | Misinterpreted the meaning of negative fuel trim and prioritized a vacuum leak. This exposed a substantive diagnostic knowledge limitation. |
| 4 | Misfire moves from cylinder 3 to cylinder 2 after swapping ignition coils | Correctly identified the moved ignition coil as the primary suspect and recommended verifying the result and checking the coil and its wiring. |
| 5 | Excessive parasitic battery draw after the vehicle is switched off | Recommended isolating the responsible circuit through fuse-by-fuse or module-by-module testing and inspecting the associated module or relay. |
Evaluation Findings
The preliminary tests suggest that the model can produce useful diagnostic hypotheses and actionable troubleshooting steps in several common automotive scenarios.
Observed strengths include:
- Clearer and more concise answers than those observed from the base model in the same scenarios.
- Recognition of the diagnostic significance of component-swapping tests.
- Practical recommendations for isolating electrical circuits and verifying suspected faults.
- Better organization of the final answer, with less repetitive discussion.
The tests also identified limitations:
- Incorrect interpretation of negative fuel-trim values in one scenario.
- Occasional prioritization of a plausible cause without sufficient evidence to establish it as the most likely fault.
- Incomplete consideration of alternative explanations, including wiring, connectors, and other components in the same circuit.
Evaluation status: Preliminary qualitative testing only.
The five cases do not constitute a statistically representative automotive diagnostic benchmark. They do not establish an overall diagnostic accuracy rate, a statistically significant improvement over the base model, or reliable performance across different vehicle platforms.
No standardized accuracy percentage, comprehensive benchmark score, or claim of superiority on a broad diagnostic test suite is reported here.
Limitations
1. Diagnostic uncertainty
A diagnostic trouble code identifies a detected condition, not necessarily the component that caused it. The model may recommend a plausible component without enough evidence to distinguish it from an electrical, mechanical, or control-system fault.
2. Domain-specific knowledge errors
The model can make fundamental mistakes when interpreting automotive measurements. For example, under the usual OBD-II fuel-trim convention, negative fuel trim means the engine control module is subtracting fuel, generally in response to a rich condition. Positive fuel trim generally means it is adding fuel to compensate for a lean condition.
The observed fuel-trim test demonstrates that the model may nevertheless misapply this relationship. Important measurements and technical claims should therefore be independently checked.
3. Vehicle-specific differences
Diagnostic procedures and specifications vary by manufacturer, model year, engine, ECU calibration, and hardware configuration. The model may not account for every vehicle-specific distinction.
4. Incomplete or misleading input
If a prompt omits relevant information, such as freeze-frame data, actual fuel pressure, wiring measurements, service history, or the conditions under which a fault occurs, the model may draw an incorrect conclusion.
5. Generated explanations are not verified measurements
A coherent explanation does not prove that a diagnosis is correct. The model does not have direct access to vehicle sensors or workshop equipment unless an external system explicitly supplies that information.
6. Limited evaluation coverage
The initial evaluation covers only five scenarios. It does not establish reliability across diesel engines, hybrid or electric vehicles, transmission faults, advanced driver-assistance systems, manufacturer-specific procedures, or safety-critical failures.
7. No guaranteed repair outcome
A recommended repair must be followed by appropriate verification. The model cannot guarantee that replacing a suggested component will resolve the underlying problem.
Safety Considerations
Automotive diagnosis can have direct safety implications. Incorrect advice may result in unnecessary component replacement, vehicle damage, emissions-system damage, or unsafe vehicle operation.
Users should:
- Treat the model's output as diagnostic decision support rather than a definitive repair instruction.
- Verify recommendations against manufacturer-specific service information.
- Confirm suspected component failures through appropriate measurements and tests.
- Follow proper electrical safety procedures when measuring current or disconnecting vehicle circuits.
- Avoid driving a vehicle when symptoms or warning indicators suggest an unsafe condition.
For example, a flashing Check Engine Light can indicate an active misfire that may damage the catalytic converter. A qualified technician should assess the vehicle and determine whether continued operation is appropriate.
The model should not be used as the sole decision-maker for vehicle safety or repair authorization.
Training and Development Information
The base model is Qwen/Qwen3.5-4B.
The fine-tuned checkpoint is intended to specialize the base model toward automotive diagnostic reasoning and troubleshooting.
The following details are not specified in the information available for this model card and should be added when verified:
| Training property | Status |
|---|---|
| Fine-tuning method | LoRA |
| Training dataset and source | build-small-hackathon/nemotron-car-diagnostics-datasets |
| Number of training examples | 15K |
| Training hardware | Nvidia RTX Pro 6000 Blackwell |
| Optimizer and learning rate | adamw8_bit |
| Batch size and sequence length | 32 |
| Number of training epochs or steps | 1 |
| Training loss and convergence results | 1.70 > 1.01 |
| Independent validation results | 1.71 > 1.01 |
These fields are intentionally left unspecified rather than inferred. They should be completed from the actual training configuration and dataset records before making reproducibility claims.
Recommended Inference Practices
For the most useful diagnostic output, provide a structured case description that includes:
- Vehicle make, model, year, engine, and relevant configuration.
- The customer's reported symptoms and when they occur.
- Diagnostic trouble codes and any available freeze-frame data.
- Relevant live sensor readings and measurements.
- Diagnostic tests already performed and their results.
- Any repairs or component swaps already attempted.
Ask the model to distinguish between:
- The leading diagnostic hypothesis.
- The evidence supporting that hypothesis.
- Alternative explanations that remain plausible.
- The next test that would best distinguish between those explanations.
- The findings that would confirm or reject the hypothesis.
For production use, a diagnostic application should validate critical numerical relationships, incorporate vehicle-specific reference information, and require verification of safety-relevant recommendations.
Recommended Future Evaluation
A more rigorous evaluation should use a larger, independently reviewed dataset of automotive diagnostic cases.
Recommended metrics include:
- Top-1 diagnostic accuracy: Whether the leading diagnosis matches an expert-validated reference answer.
- Top-k diagnostic accuracy: Whether the correct diagnosis appears among the model's leading hypotheses.
- Diagnostic action accuracy: Whether the recommended next test is appropriate and discriminates between plausible causes.
- Technical consistency: Whether the interpretation of codes, sensor readings, and physical relationships is correct.
- Unsupported-claim rate: How often the model presents an unverified hypothesis as established fact.
- Contradiction rate: How often the response contains mutually inconsistent technical claims.
- Efficiency: Output tokens, response length, and latency for comparable prompts.
- Calibration: Whether the model communicates uncertainty appropriately when the evidence is incomplete.
The base model and fine-tuned model should be evaluated on identical cases with consistent inference settings and a predefined scoring rubric. Reference diagnoses should be established independently by qualified automotive professionals.
The evaluation should also include unseen vehicle platforms, ambiguous cases, misleading symptoms, and cases where the correct response is to request more information rather than make a definitive diagnosis.
Ethical and Responsible Use
This model is intended to support human understanding and diagnostic decision-making. It should not be presented as infallible, professionally certified, or independently validated for safety-critical automotive use.
Model outputs should be reviewed by qualified personnel before repair decisions are made. Any application built on this model should clearly communicate uncertainty, preserve relevant diagnostic context, and avoid presenting generated hypotheses as confirmed faults.
Licensing and Attribution
This model is based on Qwen/Qwen3.5-4B.
The upstream Qwen3.5-4B repository identifies its license as Apache-2.0. Users should review the upstream license, applicable notices, and the license metadata of the distributed fine-tuned artifact before redistribution or commercial deployment.
Upstream model documentation and technical details:
Acknowledgements
Developed by KhazarAI as an experimental effort toward specialized language models for automotive diagnostics and technical troubleshooting.
Disclaimer: Qwen3.5-4B-Car-Diagnostics is an experimental AI model. Its outputs may contain technical errors. Always verify diagnostic conclusions against physical measurements, manufacturer documentation, and qualified professional judgment.