Semantics & search
Two things that belong together: a semantic layer that defines a metric once and for all, and a search that combines meaning with exact words.
On this page
The semantic layer
A metric consists of a measure and the dimensions along which it may sensibly be sliced. A semantic view joins several tables through stored, validated joins. Administrators maintain both under KI & Semantik → Kennzahlen (AI and semantics → metrics); afterwards they are queried by name.
A metric's SQL is assembled exclusively from stored expressions. There is no path by which a metric name could smuggle in foreign SQL.
The practical value is less convenience than unambiguity: “revenue” becomes one definition rather than four, depending on who built the export.
Three ways to search
| Mode | How it searches | Good for |
|---|---|---|
| Vector | Cosine similarity over pgvector | Meaning — finds what is phrased differently |
| Keyword | PostgreSQL full-text search | Exact words — part numbers, names, error codes |
| Hybrid | Both result lists, fused by reciprocal rank fusion | The normal case: meaning, without losing the exact hit |
Pure vector search misses an exact part number with remarkable reliability; pure keyword search misses every paraphrase. Hybrid search fuses ranks rather than scores — so nobody has to tune a weighting factor that would only be guesswork anyway.
The embedding model is included
Embeddings are produced by a locally run model (nomic-embed-text via Ollama) behind an OpenAI-compatible endpoint. It runs on CPU, unloads when idle, and needs no cloud key. Search therefore works immediately after installation. The provider stays swappable under KI & Semantik → Embeddings.
The dimension belongs to the index
The vector column has a fixed dimension (EMBEDDING_DIMENSIONS). A model with a different one means rebuilding the index once.
Governance applies to results too
The index holds embeddings, not payload. What a hit actually contains is re-fetched from Trino under your identity before it is displayed. A row hidden by policy therefore never appears as a search result — and a masked column stays masked in the hit as well.
What is searchable
- Table data loaded into the lakehouse through any of the ingestion paths.
- Documents — PDF, Word and text — after extraction and chunking, as their own chunk tables.
Applies to: This page describes lavalake 0.16.0. Product and documentation live in separate repositories — when in doubt, what the console shows is authoritative.
Something missing?
If these pages do not answer your question, we will walk through the platform against your own case in half an hour.
Book a demo