Visual Search

Find anything. By showing it. On your infrastructure.

Visual search replaces the assumption that everything in your catalogue, your archive, or your footage has been correctly tagged, labelled, and catalogued. It doesn't. Parts arrive without markings. Defects recur without anyone connecting the pattern. Objects appear in footage that nobody logged at the time.

Visual search lets your team query with an image instead of a keyword. Photograph an unknown part — get its catalogue match in under a second. Upload a defect example — retrieve every similar instance across your QC archive. Submit a reference image — find every frame across six hours of camera footage where that object or person appears.

Athena AI builds these systems to run entirely on your infrastructure. The embedding index, the search engine, the query interface — all on-premise. Your parts catalogue, your QC archive, your footage never transit a third-party service. No per-query API billing that compounds as search volume grows.

[Book a Discovery Call →]   [See How It Works]

What visual search replaces

The honest version of why keyword and metadata search fails at scale:

Where this deploys

• Manufacturing and quality control. Parts identification, defect similarity search, QC archive retrieval, counterfeit / non-compliant component detection. The primary vertical — query by photographing a part, retrieve its catalogue match and full history.
• Maintenance, Repair and Overhaul (MRO). Field technicians photograph an unknown or unlabelled component and retrieve its part number, supplier, and compatible replacements from the parts library. No manual cross-referencing. No dependency on legible markings.
• Security and investigations. Retrieve all frames from a camera archive in which a specific object, person, or vehicle appears. Query by reference image. No manual review of footage. No dependency on prior tagging.
• Retail and e-commerce. Customer submits a product photo — retrieve the closest matches from your catalogue. 'Shop the look' implemented without manual attribute tagging of your entire product range.
• Logistics and supply chain. Identify shipment contents from a photograph and match against the expected manifest. Flag visual discrepancies between received goods and expected specification.
• Brand protection and compliance. Compare product images against an approved visual library to identify counterfeits, substitutions, or non-compliant variants.
• Healthcare and medical devices. Identify instruments or devices from a photograph against a device catalogue. Retrieve similar cases from a clinical archive. Fully on-premise — no cloud processing.

Why Athena AI

The index is yours

Visual search SaaS charges per query, hosts your catalogue on their infrastructure, and ties your search capability to their uptime. We build the index on your hardware. The embedding model, the Faiss index, the query API — all on-premise. No per-query billing. No vendor dependency on the search path.

Fine-tuned for your domain, not a general catalogue

Off-the-shelf visual search works well for diverse consumer product catalogues. It underperforms on industrial parts catalogues where components look visually similar, defect archives where the distinguishing features are subtle, and proprietary product lines where no public training data exists. We fine-tune embedding models on your data and benchmark accuracy on your catalogue before production commitment.

Two use cases, one architecture

Catalogue search (find this part in my library) and archive search (find this object in my footage) share the same underlying embedding and index infrastructure. You don't need two systems. The same on-prem deployment serves both query types — catalogue queries from a web interface, archive queries from an investigative tool or QC dashboard.

Scales to your archive, not against you

A Faiss HNSW index containing one million frame embeddings queries in under 10 milliseconds. A 100-million-frame index queries in under 100 milliseconds. Index size scales with storage, not with query cost. You pre-build the index once; every query against it is fast, on your hardware, with no incremental cost.

Reference work

Ready to see what this looks like on your catalogue or archive?

A discovery call is a one-hour technical conversation against your actual data — your parts catalogue, your QC archive, your footage, your query volume. We don't pitch. We benchmark. By the end you know whether visual search is the right architecture for your operation, which embedding model is appropriate for your domain, and what accuracy is achievable before any significant investment.

[Book a Discovery Call →]

Want more detail? Continue to [How It Works →] for a non-technical walkthrough, or jump to [Architecture →] for the engineering breakdown.

What visual search actually does

Every search system you use today works the same way: you describe what you want in words or structured fields, and the system finds records that match those words or fields. That works when everything in your database has been correctly described. It fails when it hasn't — and in most operational environments, most things haven't been.

An industrial parts catalogue has 40,000 components. Perhaps 60% have complete, accurate metadata. The rest have partial records, legacy part numbers, outdated descriptions, or no description at all. A keyword search of that catalogue is, in practice, a search of 24,000 items — the ones someone got around to labelling correctly.

Visual search works differently. Instead of matching words, it matches visual meaning. You submit an image. The system converts it to a compact numerical representation — a vector that encodes what the image looks like. It then finds the vectors in its index that are most similar to your query vector, and returns the corresponding items ranked by visual similarity. No keywords. No tags. No dependency on someone having labelled things correctly at the time they were added.

The two modes: catalogue search and archive search

Visual search in an operational environment takes two distinct forms. The underlying technology is the same. The index structure, the latency requirement, and the workflow around it differ significantly.

Catalogue search — find this in my library

You have a known set of items: parts, products, devices, approved components. You build an index from that catalogue. When a query arrives — a photograph of an unknown part, a customer product image, a field technician's phone photo — the system finds the closest matches in the catalogue and returns them ranked by similarity.

The index is built once, updated incrementally as the catalogue changes, and queries against it are fast — typically under 500 milliseconds end-to-end. This is the mode for parts identification, product visual search, counterfeit detection, and MRO lookup.

Archive search — find this in my history

You have a growing archive of images or video frames: QC inspection frames, camera footage, historical photographs. The system embeds every frame in the archive and builds a searchable index over it. When a query arrives — a reference defect image, a photograph of a person or vehicle, an object of interest — the system searches the entire archive and returns all frames where something visually similar appears.

The index is built offline over the existing archive, then updated incrementally as new frames are added. Query latency depends on archive size and index type — typically under 10 seconds for a multi-hour video archive, under 2 seconds for a bounded QC frame archive. This is the mode for defect similarity search, QC retrospective analysis, and security archive investigation.

The four things that determine whether visual search works

Visual search is not a plug-in. Whether it delivers the accuracy your operation requires depends on four decisions made before a single query is run.

1. The embedding model and whether it understands your domain

An embedding model trained on general internet images will struggle with a parts catalogue where 200 components look nearly identical except for a dimensional tolerance difference. The model needs to have learned to distinguish the features that matter in your domain — surface texture for defect search, dimensional proportion for parts matching, colour and pattern for product search. The baseline is a general-purpose model. The ceiling is a model fine-tuned on your data.

2. The quality and coverage of the index

A catalogue search system is only as good as what's in the catalogue. If 30% of your parts have no image in the library, the system cannot return them. If the catalogue images were taken under different lighting conditions than field query images, similarity scores will be lower than expected. Index coverage and image quality are operational decisions that precede the technical ones.

3. The similarity threshold and what happens below it

Every visual search system has a confidence threshold: above it, a result is returned as a match; below it, a result is returned as a candidate for review, or not returned at all. Setting this threshold is a business decision, not a technical one. A threshold set too high produces false rejects — the system says 'no match' when there is one. Too low produces false positives — the system returns wrong matches confidently. We set and document this threshold explicitly during deployment, and expose it as a configurable parameter.

4. The query image quality

A blurry, dark, severely angled photograph of a part will produce lower-confidence results than a clear, well-lit, frontal photograph. This is not a flaw in the system — it is physics. We benchmark accuracy across the range of query image quality your operation actually produces, not just under ideal conditions, and design query capture guidance accordingly. For automated query sources (inline cameras, fixed inspection stations), we control image quality in hardware. For human-submitted queries, we provide quality guidance and real-time capture feedback in the query interface.

What deployment looks like

1. Discovery: catalogue or archive review, query volume estimation, accuracy threshold definition, query image quality assessment. We benchmark a zero-shot model baseline on a sample of your data before any architecture decision is made.
2. Model selection and fine-tuning: choose the embedding model based on your domain and zero-shot baseline. Fine-tune if the baseline is below threshold. Validate on held-out test set from your catalogue or archive.
3. Index build: embed your catalogue or archive, build the Faiss index, validate query latency on your hardware at your expected query volume.
4. Interface and integration: query interface (web, API, or embedded in your existing QC or ERP system), result schema definition, downstream workflow integration.
5. Production and operations: index maintenance as the catalogue or archive grows, model drift monitoring, accuracy benchmarking on new query samples, retraining cycle on schedule or on drift trigger.

For the engineering detail, continue to [Architecture →]. For index maintenance, drift handling, and integration, see [Operations →].

Visual search is an embedding pipeline feeding a vector index, served by a query API. Each of those three components involves choices that interact with each other and with your specific domain, catalogue size, archive scale, and latency requirement. We make those choices explicit during discovery and document them before any code is written.

Use cases and index architecture by mode

Embedding model selection

The embedding model is the highest-leverage decision in a visual search system. The right model for a diverse consumer product catalogue is not the right model for a parts catalogue of 40,000 near-identical fasteners. We evaluate a zero-shot baseline during discovery and fine-tune where the baseline accuracy is below your threshold.

Model selection is confirmed during discovery against your actual data. We benchmark top-1 and top-5 recall on a held-out test set before committing to a production model. Fine-tuning is scoped only when the zero-shot baseline is below the accuracy threshold agreed during discovery.

Index architecture and scale

The Faiss index type is determined by catalogue or archive size, query latency requirement, and available RAM on the inference server. We select the index type during architecture review — it is not a default.

Performance reference

The full pipeline — end to end

Ingestion pipeline (offline / incremental).

New catalogue items or archive frames enter the ingestion pipeline: image pre-processing (resize, normalise, colour correction for consistency), embedding extraction via the selected model (GPU-accelerated, batched for throughput), vector storage (embedding + metadata: item ID, source, timestamp, any structured attributes for filtered search), and Faiss index update (append for flat/HNSW indices; periodic re-train for IVF indices above a threshold). Ingestion pipeline runs offline for initial index build, then incrementally as new items arrive.

Query pipeline (online, latency-sensitive).

A query image arrives via the REST or gRPC API: pre-processing (same normalisation as ingestion — consistency here is critical; a mismatch between query and index pre-processing degrades recall significantly), embedding extraction (same model as ingestion; GPU or CPU depending on latency budget), Faiss nearest-neighbour search (ANN search against the index; optional metadata filter applied before or after search depending on filter selectivity), result formatting (top-k results with similarity scores, metadata, and optionally a thumbnail or archive frame reference), and API response. Total: under 500ms for catalogue search, under 10 seconds for archive search on appropriately sized indices.

Pre-processing consistency.

The single most common implementation error in visual search systems: query images are pre-processed differently from index images. A resize operation that uses bilinear interpolation at ingestion and nearest-neighbour at query time produces different embeddings for the same image. We enforce a shared pre-processing configuration used identically at both ingestion and query time, version-controlled alongside the embedding model.

The hard problems we plan for

Fine-grained similarity in homogeneous catalogues.

A parts catalogue containing 200 M6 bolts of different lengths, coatings, and thread pitches is a fine-grained retrieval problem. General-purpose embedding models collapse visually similar items into nearly identical vectors — their top-k results are all M6 bolts but not necessarily the right one. We address this through domain fine-tuning (training the embedding model to distinguish the features that matter in your taxonomy) and through structured attribute filtering (pre-filtering the index by category or dimension before the embedding similarity search).

Query image quality variance.

Field photographs submitted by technicians vary enormously in lighting, angle, focus, and occlusion. We build a query quality estimator into the interface — real-time feedback to the user on image quality before submission, with guidance on how to improve it. For automated query sources, we control quality in hardware (fixed camera position, controlled lighting). We benchmark accuracy across your actual query quality distribution, not idealised conditions.

Index freshness as the catalogue grows.

A Faiss flat or HNSW index supports efficient incremental insertion. An IVF index requires periodic re-training as the index grows beyond the original training size. We design the index maintenance pipeline during architecture review, with a re-train trigger based on index size growth, and benchmark the re-train time against your operational window (overnight batch, weekend job, or continuous background job depending on ingestion rate).

Embedding model drift.

If the embedding model is updated — due to a fine-tuning cycle, a model architecture change, or a base model upgrade — all existing index embeddings are invalidated. They must be re-generated with the new model before the new model can be deployed to the query path. We version models and indices together, run index re-generation as a background job before model promotion, and gate promotion on a recall benchmark against the held-out test set.

Cross-mode query (catalogue and archive from a single query).

A technician photographs an unknown part and wants to know: (a) what is it (catalogue match) and (b) has it appeared in any QC failure frames (archive match). This requires searching two indices from a single query embedding. We support this through a unified query API that fans out to multiple indices in parallel and merges results — the embedding is extracted once and reused across both searches.

One architecture, seven operational profiles

Deployment topology

On-prem GPU server (standard)

Single T4 or A10 GPU server handling embedding extraction for both ingestion and query paths, with Faiss index resident in RAM. GPU handles embedding model inference; CPU handles Faiss search (Faiss is CPU-optimised). Appropriate for catalogues up to several million items and query volumes up to 50+ QPS. Zero cloud dependency.

CPU-only (small indices)

For catalogues under ~50K items and query volumes under 10 QPS, a CPU-only server is sufficient — embedding extraction on CPU is slower but viable at low volume, and Faiss flat search on CPU is fast at this index size. Lower hardware cost; appropriate for MRO lookup tools with intermittent usage.

Multi-server (large archives)

For very large archives (tens of millions of frames), the Faiss index may be sharded across multiple servers. Query API fans out to all shards in parallel, merges results, and returns the global top-k. Embedding extraction can be parallelised across GPU workers for faster archive ingestion.

Air-gapped

Full pipeline with no outbound network. Appropriate for defence, government, and regulated manufacturing environments. Model updates and index re-generation via signed packages on a controlled inbound channel.

[Request Architecture Review →]   [Talk to an Engineer]