AI and Computer Vision
A vision or AI system's accuracy on a slide deck and its accuracy on a production line are two different numbers. The gap between them is almost always lighting, camera placement, triggering, and the review process around uncertain results - not the model architecture.
The Problem
Manual visual inspection and manual data extraction are slow and inconsistent across shifts, but a vision or AI pipeline introduced without a validation and monitoring plan just replaces a visible human error rate with an invisible one.
Our Approach
We treat camera/lighting/triggering setup, model evaluation against a real holdout set, and a defined confidence threshold with human review as part of the deliverable - not an afterthought once the model looks good on training data.
Camera selection and triggering
Resolution and frame rate are chosen against the part's actual speed and the defect size that has to be detected, not maximized in the abstract. A part moving past a fixed camera usually needs a hardware trigger (sensor-based) rather than free-running capture, so the image is taken at a consistent position every cycle.
Lighting and image acquisition
Inconsistent ambient lighting is the most common cause of a model that works in testing and fails in production. Controlled lighting (diffuse or backlit, depending on what's being inspected) removes a variable that no amount of model tuning can compensate for reliably.
Inference pipeline and pass/fail decisions
A production pipeline is preprocessing (crop, normalize) -> model inference -> a post-processing step that turns a raw score into a decision. That last step is where a confidence threshold determines whether a result is treated as a clear pass, a clear fail, or routed to a human reviewer instead of forced into a binary answer.
Model validation
Before deployment, the model is evaluated against a held-out set that wasn't used for training, with the error cases reviewed manually - not just an aggregate accuracy number. A model that's 98% accurate but consistently wrong on one specific defect type has a real, addressable weakness the aggregate number hides.
Monitoring and data pipelines
Inference results are logged (input reference, decision, confidence) so accuracy can be re-checked against new samples over time - conditions on a production line change, and a model that was accurate at deployment can drift as lighting, parts, or cameras age.
Architecture and Approach
A camera or sensor triggers capture at a defined point in the process; the image is preprocessed and passed to a model for inference; a post-processing step applies a confidence threshold to decide pass, fail, or route-to-review; and every decision is logged for later evaluation and drift monitoring.
What We Build
- Vision-based inspection and defect detection
- Object detection and classification
- OCR and document data extraction
- Camera and robot integrations
- Custom AI chat and assistant workflows
Use Cases
Common Engineering Challenges
A model trained on images from one lighting setup will not perform the same under different ambient light. Controlling the lighting is usually a better investment than adding more training data to compensate for it.
Setting the threshold too permissive lets false passes through; too strict floods the review queue with clear passes. The right threshold is a business decision (cost of a miss vs. cost of a false alarm), not a fixed default.
A model's accuracy can degrade as physical conditions change (camera position, part supplier, lighting fixture age) without anyone changing the code. Ongoing monitoring, not a one-time validation, is what catches this.
FAQ
We evaluate against a held-out sample before deployment and report that number honestly, but production accuracy also depends on lighting and camera setup staying consistent with what was validated - conditions we help control, not just the model.
A confidence threshold routes uncertain cases to a review queue rather than forcing a binary pass/fail - the threshold itself is set based on the cost of a miss vs. a false alarm for your process.
Not automatically - physical conditions drift. We log inference results specifically so accuracy can be re-checked against new samples rather than assumed to be constant.