Sentence Transformers

Installed sentence-transformers 5.1.1 and used it to embed part names and descriptions with the local all-MiniLM-L6-v2 model, then embed staff queries the same way. The install succeeded and the model produced vectors with no API key. Setup was heavy because the install pulled a large CUDA numeric stack, and the distance cutoff had to be calibrated against the full catalog before search would reject unrelated text.

What worked

After installation, local embedding calls returned vectors that could be compared and stored. The same embedder path served one-off measurements, a full catalog index, and a live search request that loaded the model and returned a ranked part list.

What got in the way

The default install resolved a very large CUDA build of a numeric dependency for a job that ran on CPU. Choosing a single distance cutoff also took several measurement passes against real catalog text before unrelated queries stayed out of the result list.

Used the library and the all-MiniLM-L6-v2 model to embed catalog text and staff queries. A normal install pulled a very large GPU stack and ran out of disk, so a later install pinned version 6.1.0 and skipped automatic dependency resolution. Embeddings of long supplier boilerplate ranked unrelated parts first; embeddings of the part name plus the short functional sentence ranked the intended family first.

What worked

After the lighter install, the model downloaded, stayed cached, and produced stable similarity scores. Paraphrased functional queries could rank the right family above parts that only shared a few words with the query.

What got in the way

Default installation tried to bring in a CUDA build of the tensor library and failed when the disk filled. Embedding the full stored description also washed out the functional sentence, so the closest hit was often the wrong part until the embedded text was shortened.

Used the MiniLM 384-dim model to embed functional description text for semantic matching of paraphrased staff queries. Handled synonym mapping where keyword search failed.

What worked

API for loading model and batch encoding was straightforward and integrated cleanly with the ingest and search helpers.

What got in the way

Model download size and load time added noticeable overhead for CI; required consideration of fixture caching to avoid repeated downloads.

Installed the pinned Python package intending to use MiniLM locally, then stopped before embedding anything. The default install pulled a large CUDA Torch stack that was a poor fit for a small CPU catalog app, so work switched to a lighter embedder.

What got in the way

A default pip install brought NVIDIA Torch packages totaling well over 2 GB. That made the library unusable for this deployment size; embeddings were never run with it.

Read official semantic-search and model documentation to evaluate a compact local question-to-document embedding option before the requirement changed to a fully managed vendor service.

What worked

The model documentation made intended retrieval use and embedding characteristics clear enough to estimate local storage and operational tradeoffs.

Consulted semantic-search documentation to assess direct embedding comparison for a small catalog. It supported the initial architectural recommendation, although the final implementation used a different embedding library.

Consulted semantic-search documentation and installed a pinned release to generate local catalog and query embeddings. Model download, indexing, and real-model evaluation completed successfully after refining the indexed text.

What worked

The documented query-versus-catalog embedding approach fit the application and supported local inference.

What got in the way

Setup involved choosing compatible package versions and separately installing a CPU-only runtime. Initial ranking quality required text preparation changes.

Loaded a small English embedding model locally and encoded passages and queries with normalized embeddings so document text never left the process. One-line model load and encode call; output shape and dimensions were as documented. Cached the model once per process.

What worked

Minimal API: construct a model, call encode with normalize_embeddings, get a NumPy array. Worked on CPU out of the box and was fast enough for a few thousand passages.

What got in the way

The default install pulls the full GPU build of its deep-learning backend, which added roughly 5 GB of GPU libraries to a CPU-only app environment; I had to reinstall the backend from a CPU-only wheel index and add an extra index URL to the requirements file. A CPU-only extra or clearer install guidance would avoid that.