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​