leadingtorch/circuit-reasoning-google-gemma-4-31B-it-thinking-enabled

Circuit Reasoning VLM (Gemma Fine-tuned)

Model Used: google/gemma-4-31B-it | Blog Post: BLOG-NAME | Authors: Leading Torch Pvt. Ltd.

Introduction

Large Vision-Language Models (VLMs) have shown incredible progress in understanding natural images, but they still struggle with complex spatial reasoning in technical domains. If you show a typical VLM a picture of an ESP32 wired to a sensor on a breadboard, it might tell you "there are wires and a chip," but it can rarely trace the exact connections—like telling you that the green wire is plugged into D18 instead of D19. For electronics students, hobbyists, and QA engineers, catching these tiny wiring mistakes is critical, yet often tedious. That’s why we’ve trained a specialized Circuit Reasoning model. This model uses "Chain of Thought" (CoT) reasoning to act as a virtual hardware assistant, systematically checking your power, ground, and data lines against a schematic and a textual pinout reference before you ever plug in the power.

📌 Primary Goal

The primary goals of this model are to:

• Improve structured reasoning ability for visual circuit inspection.
• Provide step-by-step Chain-of-Thought (CoT) explanations for hardware validation.
• Detect wiring errors in circuits.

📊 Training Data

The model was fine-tuned on a custom, high-quality circuit wiring dataset. This dataset consists of paired inputs: a textual ESP32 pinout reference, a reference schematic image, and a corresponding breadboard circuit photo (which may be correctly or incorrectly wired). It features step-by-step reasoning traces and final conclusions designed to teach the model how to audit physical builds against reference diagrams and pin definitions.

🗺️ Training Pipeline Overview

Base Model (google/gemma-4-31b-it)
 │
 ▼
gemma-4-31b-it with Unsloth optimization
 │
 ▼
Supervised Fine-Tuning (SFT) + LoRA
(Using custom circuit-reasoning data with Chain-of-Thought)
 │
 ▼
leadingtorch/circuit-reasoning-google-gemma-4-31B-it-thinking-enabled

🧠 Example of Learned Reasoning Scaffold

This model is trained to follow a structured, step-by-step reasoning process to evaluate circuit wiring.

A typical abstract scaffold looks like:

1. Step 1: Component Check. Identify the microcontroller and connected sensors on the breadboard based on the provided pinout.
2. Step 2: Power Wiring. Verify the VCC and GND connections between the components and the microcontroller.
3. Step 3: Data Wiring. Trace the data lines from the sensor to the specified GPIO pin on the microcontroller, referencing the pinout text.
4. Step 4: Pull-up Resistor (if applicable). Check for necessary passive components like pull-up resistors.
5. Conclusion: Provide a final assessment (e.g., ✅ or ❌) summarizing the findings and identifying any critical errors.

💡 Example Model Output (Chain-of-Thought Enabled)

When given a schematic and a breadboard photo where the VCC (power) wire was missing entirely, the model correctly utilizes its "thinking" block to step through the audit and find the exact error:

Reference Schematic:

Breadboard Photo:

--- FINAL AUDIT REPORT ---
<thought>
I will perform a step-by-step audit of your physical build against the schematic.

### Step 1: Power Connection (VCC)
*   Schematic: The VCC pin of the DHT11 sensor should be connected to the 3V3 pin on the ESP32.
*   Physical Build: There is no wire connected to the VCC pin of the sensor.
*   Result: ❌ Critical Error. The sensor has no power source and will not activate.

### Step 2: Ground Connection (GND)
*   Schematic: The GND pin of the DHT11 sensor should be connected to the GND pin on the ESP32.
*   Physical Build: The black wire is correctly inserted at the GND pin of the ESP32 and the GND pin of the sensor.
*   Result: ✅ Correct.

### Step 3: Data Connection (DATA)
*   Schematic: The DATA pin of the DHT11 sensor should be connected to pin D5 on the ESP32.
*   Physical Build: The purple wire is correctly inserted at pin D5 of the ESP32 and the DATA pin of the sensor.
*   Result: ✅ Correct.
</thought>

### Final Conclusion & Recommendation
The circuit is incomplete. While the data and ground wires are correct, the VCC wire is missing entirely. Without power, the DHT11 sensor cannot produce any output.
Required Fix: Insert a jumper wire from the 3V3 pin of the ESP32 to the VCC pin of the DHT11 sensor.

⚙️ Training & Inference with enable_thinking = True

This specific model was strictly trained and optimized with the enable_thinking = True parameter explicitly enabled via the gemma-4-thinking chat template. This means the model has been taught to inherently generate structured <thought> blocks before producing its final answer.

Why enable_thinking Matters

During testing and verification, we discovered a significant difference in accuracy and explainability based on whether the thinking block was utilized:

• When Disabled / Standard VLM Behavior: If the model is prompted to jump straight to a final conclusion without a reasoning trace, it is far more prone to hallucinations. It may falsely mark an incorrect circuit as ✅ Correct or fail to identify which exact pin a wire is mistakenly plugged into.
• With enable_thinking = True: By forcing the model to generate a <thought> block, it systematically aligns the schematic's requirements and the textual pinout reference with the physical breadboard's state step-by-step (Component, Power, Data). This greatly reduces hallucinations and allows the model to accurately isolate specific spatial faults (e.g., "The purple wire is inserted at TX0 instead of D18").

How to use?

When running inference on this model (e.g., using FastVisionModel from Unsloth), you must structure your messages array correctly. The model was trained to accept the ESP32 pinout diagram as text context, followed by the reference schematic image, and finally the breadboard photo image in a single user turn.

You must also pass enable_thinking = True in your tokenizer's chat template application to achieve the advertised accuracy:

# Prepare the images
schematic_img = Image.open("path_to_schematic.png").convert("RGB")
photo_img = Image.open("path_to_breadboard.jpg").convert("RGB")

pinout_text = """ESP32-WROOM-32 DevKit V1 (30-Pin) technical pinout context..."""

# Structure the Messages
messages = [
    {"role": "user", "content": [
        {"type": "text", "text": "Perform a step-by-step circuit audit. Compare the schematic wiring to the breadboard photo.\n\nPinout:\n" + pinout_text + "\n\n"},
        {"type": "image", "image": schematic_img},
        {"type": "text", "text": "Reference Schematic.\n\n"},
        {"type": "image", "image": photo_img}, 
        {"type": "text", "text": "Breadboard photo. Audit the physical build."},
    ]},
]

# Apply Chat Template with 'enable_thinking'
inputs = tokenizer.apply_chat_template(
    messages,
    tokenize = True,
    enable_thinking = True,  # <--- CRITICAL: Required for CoT reasoning
    add_generation_prompt = True,
    return_dict = True,
    return_tensors = "pt",
).to("cuda")

# Generate Response
outputs = model.generate(**inputs, max_new_tokens=2048)

By fine-tuning the model to map spatial data into structured text blocks before concluding, the model learns a much more stable and reliable internal mechanism for visual QA tasks.

---

Last Updated: 17th April 2026