RAG & Semantic Search

Matching Surgical Instrument Inquiries to Catalog Items by Meaning, Not Keywords

A retrieval-augmented matching system that replaces manual catalog lookup during quote preparation, accepting spreadsheets, documents, PDFs, and product photos and returning ranked catalog matches through semantic, not exact-text, comparison.

August 21, 2026

OUTLINE

ENGAGEMENT SNAPSHOT

Figure 1 - Key figures from this engagement, at a glance.

EXECUTIVE SUMMARY

Our client's sales and quoting team manually reviewed every incoming product inquiry - spreadsheets, Word documents, PDFs, and photographs of surgical instruments - to identify the closest matching item in the internal catalog before preparing a quote. That manual review step was slow and inconsistent, particularly for inquiries submitted as images or in formats that didn't map cleanly onto catalog terminology.

Pfactorial Technologies built and deployed an AI-powered product matching tool that automates that lookup. The system accepts unstructured inquiries in any of the supported formats, uses vector embeddings and similarity search to identify the closest corresponding catalog entries, and returns structured, ranked recommendations in a format that plugs directly into the existing quoting workflow.

The system has replaced the previous manual review process, built on a retrieval-augmented generation architecture with a hybrid embedding strategy - separate embedding models for unstructured text, structured catalog fields, and product images - rather than forcing one embedding model to represent everything.

Why this engagement is representative This engagement demonstrates Pfactorial's approach to retrieval-augmented systems in operational sales workflows: matching by semantic meaning rather than exact keywords, and choosing a hybrid embedding strategy specifically because no single model represents both free text and structured catalog data well.

THE CHALLENGE

Manually matching a product inquiry to the correct catalog item slowed down quote preparation, and the format of incoming inquiries made the problem harder than a simple text search.

1. Inquiries arrive in whatever format the customer used

Spreadsheets, Word documents, PDFs, and product photographs all needed to be accepted through a single intake pipeline, rather than requiring customers to reformat requests into one standard structure.

2. Exact keyword matching misses real equivalence

Product descriptions vary in wording between a customer's inquiry and the internal catalog's terminology, so a keyword-based search misses matches that a semantic comparison would catch.

3. A single embedding model doesn't represent everything well

Free-text product descriptions, structured catalog fields, and product images each need different embedding treatment; a single embedding model could not adequately represent all three.

4. Low-confidence matches need a decision point, not a guess

Some inquiries genuinely don't have a clean catalog match, and forcing the system to always return a confident top result would risk quoting the wrong instrument.

The real brief Not "search the catalog by keyword" but "match an inquiry to the closest catalog item by what it actually means, across whatever format it arrived in."

THE SOLUTION

Pfactorial built the system on a retrieval-augmented generation architecture orchestrated with LangChain, moving every inquiry through ingestion, embedding generation, vector storage and retrieval, and structured-output generation.

Figure 1 - System workflow: input formats through vector processing to a ranked, structured output.

Architectural principles

Hybrid embeddings, matched to data type - unstructured text is embedded with OpenAI embeddings, structured catalog fields with HuggingFace embeddings, and product images with CLIP - because a single embedding model could not adequately represent all three.
One vector space for photo and text inquiries - image-based inquiries are routed through CLIP for vector conversion before the same similarity-search step is applied, so photo-based and text-based inquiries resolve against the identical catalog index.
Local vector storage, chosen for cost and latency - FAISS was selected because it runs locally with no per-query licensing cost, delivers low-latency similarity search at the catalog's scale, and integrates directly with the LangChain retrieval layer already used elsewhere in the pipeline.
No training required to keep the catalog current - the internal catalog is embedded once into FAISS, and pretrained embedding and language models are applied at inference time - so refreshing the index when the catalog changes doesn't require retraining anything.

CAPABILITIES DELIVERED

The system's capabilities span the full path from an unstructured inquiry to a quote-ready recommendation.

CAPABILITY	WHAT IT DOES
Multi-Format Input Processing	Accepts Excel, Word, PDF, and image-based inquiries through a single intake pipeline.
AI-Powered Semantic Matching	Uses vector embeddings and similarity search to identify the closest catalog entries by meaning, not exact keyword overlap.
Structured, Ranked Output	Delivers results in Excel format, ready to drop directly into the existing quoting workflow.
Image-Based Matching	Converts product photographs and scanned competitor catalog pages into the same vector space as text inquiries via CLIP.
Feedback-Driven Refinement	Captures user corrections during quote review and folds them back into the matching process.
REST API Integration	Exposes the matching engine to other internal systems directly, without requiring the Streamlit interface.

Figure 2 - Where the matching tool plugs into the sales workflow, and how OCR and confidence scoring were validated.

Design note The matching engine currently operates on English-language content, though the embedding and retrieval architecture is language-agnostic by design, so additional languages can be added by swapping in language-specific embedding models rather than restructuring the pipeline. Low-confidence matches are flagged for manual review rather than auto-resolved.

ENGINEERING FOR SCALE AND RELIABILITY

Several engineering decisions shape how the system holds up on real, varied product inquiries rather than only on clean catalog data.

OCR evaluated on cost, customization, and integration, not accuracy alone

Tesseract OCR was selected over a proprietary alternative (Google Vision API) for cost, customizability, and direct pipeline integration, with its moderate baseline accuracy offset by a supplementary image-understanding layer and the human feedback loop.

Image understanding supplements OCR rather than replacing it

a BLIP-2 image-understanding layer supplements raw OCR text with descriptive image understanding on visually complex sources such as dense competitor catalog scans, mitigating Tesseract's moderate accuracy on those cases.

Confidence scoring routes uncertainty to a person

every match is ranked by a similarity score, and inquiries producing a low similarity score are flagged rather than auto-resolved, keeping recommendation quality consistent even for ambiguous inquiries.

A continuous feedback loop, not a static index

corrections made by users during quote review are captured through the feedback mechanism and used to sharpen future matches, rather than the system's accuracy being fixed at deployment.

Language coverage scoped deliberately, extensible by design

the system currently operates on English-language content, with the underlying embedding architecture designed so additional languages are added by swapping embedding models rather than restructuring the pipeline.

DELIVERY APPROACH

The engagement moved from format-by-format manual matching to a deployed, feedback-driven retrieval system.

1. Build the ingestion pipeline - implemented text extraction (PyPDF2, docx2txt, pandas) and an OCR path (Tesseract, BLIP-2) for spreadsheet, document, PDF, and image inquiries.

2. Index the catalog - embedded every catalog item once into a FAISS vector store using the hybrid embedding strategy, ready for repeated similarity search without retraining.

3. Build the matching engine - implemented semantic matching with GPT-4 Turbo and LangChain, with custom Python confidence scoring ranking each candidate.

4. Ship the interface and export - built the Streamlit application for upload, results display, and feedback collection, with pandas generating the Excel output for quoting.

5. Expose a REST API - connected the matching engine into existing internal systems directly, without requiring the Streamlit interface for every call.

6. Deploy and close the feedback loop - deployed the system into the quote-preparation workflow, replacing manual catalog lookup, with user corrections feeding back into matching quality.

RESULTS AND IMPACT

Figure - Key outcomes from this engagement.

The system has replaced the previous manual catalog review process used during quote preparation, with sales and quoting teams uploading an inquiry in its original format and receiving ranked catalog matches in Excel, ready to drop directly into the quote.

By routing photo-based inquiries through CLIP into the same catalog index used for text inquiries, and scanned competitor catalog pages through the OCR and image-understanding pipeline, the system extended matching to inputs a keyword-based tool could never have handled, without requiring a separate workflow per input type.

What it enabled commercially

By automating catalog lookup across every inquiry format the sales team receives, the client's quoting workflow moved from manual, per-inquiry review to a structured recommendation step - reducing the manual intervention rate for the clear cases while keeping low-confidence matches in front of a person rather than automated blindly.

WHY PFACTORIAL

This engagement draws on Pfactorial's data and pipeline infrastructure capability: building retrieval-augmented systems with hybrid embedding strategies matched to real data heterogeneity, deployed directly into an operational sales workflow rather than left as a standalone demo.

Figure - Service lines this engagement draws on.

Engagement enquiries Pfactorial Technologies works with distribution and sales operations teams whose product matching or lookup process still depends on manual review. If you are evaluating whether a semantic matching system is worth building for your catalog, we are happy to give you an honest read on scope, cost, and risk before anyone commits to anything. · pfactorial.ai

APPENDIX A - TECHNOLOGY STACK

The technology stack underpinning the system, grouped by the layer it serves.