AI Customer Service for a Laser-Equipment Maker
Background
A laser-equipment maker — single machines run into serious money. Their buyers are manufacturing line managers and procurement teams, and the questions they ask aren't "what does your product cost." They're "I'm cutting 3mm stainless with your 3000W fiber laser — what's the right speed, assist-gas pressure, and focal position for this job?"
Two traits of these questions:
- Highly technical. Clients need answers tailored to their workpiece, line, and equipment — not generic explanations.
- Costly mistakes. Machines are expensive; one bad parameter recommendation can ruin a batch, force rework, and cost far more than a single support ticket.
They had a deep archive of product technical documentation — long-form manuals plus a lot of diagrams (optical-path diagrams, cutting-parameter tables, exploded structural drawings).
Goal: an AI support agent that's both deeply technical and disciplined enough to say "I don't know" rather than guess wrong.
Why This Was Hard
Standard RAG handles text well, but laser manufacturing has two extra challenges:
- Diagrams carry the data. Many key facts live inside drawings — optical layouts, parameter tables, dimensional specs — that text-only retrieval can't reach.
- Wrong answers are expensive. A consumer support bot can apologize. A wrong parameter recommendation can cost a client an entire batch.
We had to do two things: let the AI see the diagrams, and let the AI stay quiet when it shouldn't answer.
Approach
Multimodal diagrams: Qwen2.5-VL + fine-tuning
We deployed the Qwen2.5-VL multimodal model (~32B) — a ViT vision encoder + Qwen LLM backbone that accepts images and text together. We fine-tuned it lightly on the client's own archives:
- Cutting parameter tables (power, gas pressure, speed, focal position)
- Optical path diagrams (spot size, lens placement)
- Exploded structural drawings (part names, assembly relations)
We used their historical docs plus a few hundred to ~1000 engineer-labeled Q&A pairs as supervised fine-tune data — enough to bring diagram-recognition error down to usable levels.
Text retrieval: standard RAG
For the long-form docs (manuals, maintenance guides, process SOPs), we ran standard RAG — chunking, vector indexing, semantic retrieval. Text and diagram evidence are merged in the same answer module.
"Better silent than wrong"
This was the hardest part of the build. We layered three fallbacks:
- Prompt rules. Hard constraints: only answer based on retrieved evidence; never invent.
- Confidence thresholding. The multimodal model emits a confidence with each answer — low confidence triggers fallback.
- Hard fallback reply. "I'm not certain about this — please contact our support engineer." And the thread is forwarded to a human.
After the three layers, the AI is 90%+ accurate on the cases it should answer — closer to 95% — and stays silent when it shouldn't speak. That's exactly the boundary the client wants.
Net result: 75%+ of customer questions are resolved by AI without a human in the loop.
Channels
The deliverable wasn't a separate cloud tool — it was embedded into the client's own entry points:
- Web widget. A floating chat icon in the bottom-right of their website.
- Their own mini-program. The same Q&A API, embedded in their WeChat mini-program.
Both consume the same AI backend and knowledge base — update once, both stay in sync.
Final Thoughts
The deepest lesson from this build: in many B-side scenarios, "knowing when to stay silent" matters more than "being able to answer."
General-purpose consumer AI is trained to "answer fully and naturally." But B-side clients buy a guarantee: "can I trust this with my work?" — and that trust comes less from coverage than from knowing when to shut up.
It's the same principle as our project rule: don't reach for AI when rules will do — and keep it lean when you do. What makes the system safe isn't the model. It's the rules, the thresholds, and the fallbacks.