Embeddings

Remem generates embeddings locally with the all-MiniLM-L6-v2 model inside the Go server. The model is packaged with the supported Docker build, so production does not depend on an external embedding API.

Model

Property	Value
Model	all-MiniLM-L6-v2
Dimensions	384
Similarity metric	Cosine
Inference	CPU, local, in-process

The model is configured via the [embedding] section of remem.toml:

[embedding]
model = "all-MiniLM-L6-v2"
cache_size = 10000                  # embeddings kept in LRU cache

No internet connection is required at runtime, no external embedding API, no per-query cost. dimension in [vector] must match the embedding model’s output size — changing [embedding].model to a different model requires updating [vector].dimension to match, and requires reindexing existing data.

When embeddings are generated

• On store_memory — the content is embedded and the vector is stored in the HNSW index
• On search_memories with search_type: "semantic" or search_type: "hybrid" — the query is embedded at search time

Similarity threshold for auto-discovery

Relationship discovery is controlled by the [discovery] section of remem.toml:

[discovery]
enabled = true
threshold = 0.7
top_k = 5

When a memory is stored, its embedding is compared against existing memories; pairs with cosine similarity at or above auto_discovery_threshold get linked, capped at auto_discovery_top_k new edges per memory. This runs on a background worker, so store_memory returns before discovery completes.

Lower values create denser graphs with more loose connections. Higher values create sparser graphs with only strong connections.

Long content

For long documents, consider:

• Storing paragraph-level chunks as separate memories and linking them with part_of connections
• Summarising the content and storing the summary as the memory content