Skip to main content

Use Cases

Ahnlich DB looks flexible, but almost everything you'd build with it is the same recipe: turn your data into vectors, find the nearest ones, and (optionally) filter by metadata. Once that clicks, the examples below are just variations on that single idea.

Your inputtext · imageaudio · a userAhnlichfind nearest vectors+ filter by metadataRelevantresultsrankedSame recipe powersSemantic searchRecommendationsCross-modal (text↔image)Clustering
Every use case below is the same three steps: turn your input into a vector, find the nearest stored vectors, and optionally filter by metadata. Only the data and the labels change.

Three families of use cases

Most projects fall into one of three buckets. Find the question you're asking and jump to that section.

FamilyThe question you're askingExamples
🔍 Search & retrieval"What's most like this?"Semantic search, image-to-product
🎯 Personalization"What should I show this user?"Recommendations
🧭 Analysis & discovery"How does my data group?"Clustering, exploration

And one technique — filtering with context — that layers on top of all three.


🔍 Search & retrieval

"Find the items that mean the closest thing to my query."

Meaning map (vector space)your querynearest 3 → results
Search finds items by meaning. The query sits in the same space as your data; the closest points come back even when they share no exact keywords.

Semantic search goes beyond keyword matching — it finds items that are conceptually similar to a query, even when the words differ. Embeddings from an NLP model (sentence-transformers, BERT, etc.) are stored, then queried.

Example — a news site lets readers search by meaning, not keywords:

GETSIMN 5 WITH [0.42, -0.13, 0.76, ...] USING cosinesimilarity IN news_store WHERE (topic != "sports")

Returns the top 5 articles closest in meaning to the query vector — a search for "climate change effects on agriculture" also surfaces an article titled "how droughts reshape farming", despite sharing no keywords.

Cross-domain (multimodal) retrieval

Because a vector can represent any modality — text, images, audio — you can search across them: query with one kind of data, match another.

Example — a shopper uploads a photo and finds similar products:

GETSIMN 3 WITH [0.31, 0.88, 0.64, ...] USING cosinesimilarity IN fashion_store WHERE (availability = "in_stock")

The photo is embedded into the same space as the catalog images, so the 3 visually closest in-stock products come back — image-to-product search.


🎯 Personalization

"Given who this user is, find the items closest to them."

Recommendation is just search where the query vector is a user instead of a text or image. Store a vector per user (built from their profile and behavior) and a vector per item; the nearest items are the recommendations.

Recommendation engines

Example — an e-commerce store recommends products from browsing history:

Python
get_sim_n(
store="product_store",
search_input=[0.24, 0.15, 0.93, ...], # the user's embedding
closest_n=10,
algorithm=CosineSimilarity,
condition=Predicate::NotEquals { key="status", value="out_of_stock" },
)

The 10 products nearest the user's vector — personalized, and never showing out-of-stock items.


🧭 Analysis & discovery

"I don't have a single query — show me how everything relates."

Similar items sit together → natural groupsGroup AGroup BGroup C
No labels required: because similar items land near each other, running similarity searches reveals the natural groups already present in your data.

Clustering & exploration

Because similar vectors sit near each other, similarity search reveals the natural groups in your data — no labels required. Ahnlich DB becomes the backbone for unsupervised exploration.

Example — a research lab explores thousands of genomic-sequence embeddings:

  • Pick sample vectors with certain traits.
  • Run similarity searches to gather their neighbors into groups.
  • Narrow with metadata filters (e.g. species = "human").

Scientists discover relationships between sequences without having labelled them first.


Combining any of these with filters

"Similar — but only the ones that also fit the rules."

Similarby vectorMatches filterby metadatareturnedrelevant &correct
Filtering with context returns only the overlap: items that are both semantically similar and satisfy your metadata rules (in stock, recent, this language…).

This is the trick that makes results trustworthy: pair vector similarity with metadata predicates, and you get only the items that are both relevant and correct (in stock, recent, the right language…).

Example — a video platform recommends similar videos, but only recent uploads:

# 1. find the most similar videosGETSIMN 8 WITH [0.89, -0.33, 0.55, ...] USING euclideandistance IN video_store # 2. keep only those matching a metadata ruleGETPRED (upload_date >= "2024-09-01") IN video_store

GETSIMN handles "similar", GETPRED handles "fits the rules". Together they enforce real-world constraints like time windows, categories, or per-user permissions.

Where to go next