Ultrahost/ docs
All examples

Example 05

Experiment

Semantic Similarity

Find things that mean the same, even when they look nothing alike.

Embeddings turn anything into coordinates. This example picks a model to create them, keeps them next to the facts that explain them, groups similar ones together, and decides who is allowed to look.

Chapter one

When something is turned into coordinates

Anything can be embedded: a sentence, an image, a product, a person. A few small jobs make sure its coordinates can be trusted, explained, and protected.

  1. 1
    LLM Plane

    A model is chosen

    The LLM engine picks the best embedding model for this kind of content and uses it to turn the item into a vector.

  2. 2
    Vector DB

    The embedding is stored

    The vector is saved in the Vector engine, ready to be compared with every other vector.

  3. 3
    Document Database

    Its story is kept beside it

    A JSON document records what the vector stands for: its source, the model that made it, and any other metadata.

  4. 4
    Graph Database

    Related embeddings are linked

    If it shares an origin, a place, or an author

    Edges connect vectors that belong together, so closeness in meaning can be explained by closeness in life.

  5. 5
    Authorization Layer

    Who can reach it is decided

    Rules declare who may query these vectors, so private content never shows up as a neighbor for the wrong person.

Chapter two

When someone asks for something similar

The question is translated into the same coordinates, then the closest neighbors are found, explained, and followed outward.

  1. 1
    Authorization Layer

    Only visible vectors are considered

    The search is limited to the vectors this person is allowed to access, before any distance is measured.

  2. 2
    LLM Plane

    The question is embedded

    The same model that made the stored vectors turns the example into coordinates, so both live in the same space.

  3. 3
    Vector DB

    The nearest neighbors are found

    The Vector engine returns the closest vectors, even when no words or features match.

  4. 4
    Document Database

    Each match is explained

    The metadata of every neighbor is fetched, so results show what they are and where they came from.

  5. 5
    Graph Database

    The neighborhood is explored

    If the answer needs more context

    Links from each match lead to related embeddings, such as other items from the same origin or author.

Make it yours

Variations worth trying

  • Embed one kind of content first, such as support tickets, before mixing types.
  • Skip the graph and rely on nearest-neighbor queries if you do not need named groups.
  • Try a different embedding model per content type and compare the neighbors.

Starting point

Ask your coding agent for your version

Use this prompt as a starting point, then change whatever does not fit your idea.

Build a similarity feature that generates embeddings, stores them with metadata, groups similar items, and limits who can query them.

Use these Ultrahost building blocks, in this flow.

When something is turned into coordinates:
1. LLM Plane: The LLM engine picks the best embedding model for this kind of content and uses it to turn the item into a vector.
2. Vector DB: The vector is saved in the Vector engine, ready to be compared with every other vector.
3. Document Database: A JSON document records what the vector stands for: its source, the model that made it, and any other metadata.
4. Graph Database (if it shares an origin, a place, or an author): Edges connect vectors that belong together, so closeness in meaning can be explained by closeness in life.
5. Authorization Layer: Rules declare who may query these vectors, so private content never shows up as a neighbor for the wrong person.

When someone asks for something similar:
1. Authorization Layer: The search is limited to the vectors this person is allowed to access, before any distance is measured.
2. LLM Plane: The same model that made the stored vectors turns the example into coordinates, so both live in the same space.
3. Vector DB: The Vector engine returns the closest vectors, even when no words or features match.
4. Document Database: The metadata of every neighbor is fetched, so results show what they are and where they came from.
5. Graph Database (if the answer needs more context): Links from each match lead to related embeddings, such as other items from the same origin or author.

Treat this as a starting point. Keep the parts that fit my idea and adapt the rest.

Next example

User Profiles & Activity