Product · Embedding API

Embedding: meaning becomes computable

The flinq Embedding API turns construction data into vectors. Software can then search and compare by meaning instead of exact wording.

Endpoints: POST /v1/embeddingsPOST /v1/search

What is an embedding?

An embedding is a list of numbers, a vector, that describes the meaning of a piece of content. A model computes such a vector for each item, for example a bill-of-quantities line item or a product datasheet. Content with similar meaning lands close together, regardless of wording.

That makes similarity computable: instead of comparing strings, software compares positions in the vector space. This is the foundation for semantic search, matching, RAG, deduplication and clustering. Once embedded, search is pure vector math and answers in milliseconds.

What does that mean for construction?

Construction data is heterogeneous: bills of quantities, BIM models (IFC), construction-site images, product and cost data. The same work item is worded differently in every document, and word-based search regularly fails on that.

The cross-modal flinq model embeds all these data types into the same vector space. A bill-of-quantities line item, the matching IFC component and the manufacturer product sit on nearby vectors and become findable across format and manufacturer boundaries. On the BauSatz benchmark, flinq reaches nDCG 0.78 on product retrieval versus 0.60 for OpenAI.

Why an embedding model and not an LLM?

For search, matching and RAG over construction data, an embedding model has clear advantages over a generative LLM, in cost, speed and reliability.

Up to 100× cheaper than running an LLM for the task

You embed each object once and store the vector. Search and matching are then pure vector math, with no costly model call per query like an LLM.

Real-time answers, even across millions of objects

Vector search over precomputed embeddings returns in milliseconds. An LLM call takes seconds.

Reproducible, defensible results

Same input, same vector, every time. Traceable for costing and tenders, where LLM output varies.

No hallucination

Embeddings retrieve real, existing objects, an actual bill-of-quantities item or a real product, rather than inventing an answer.

Fewer false matches, less rework

Trained on construction data: BauSatz nDCG 0.78 vs 0.60. Higher domain accuracy saves manual correction.

See the benchmark

One integration, many features

The same vectors power search, matching, RAG, deduplication and clustering, several features from one embedding call.

Connect data across format boundaries

Match a bill-of-quantities item, an IFC component and a datasheet cross-modally. Connections that were previously manual or impossible.

Your data stays in the EU

GDPR-compliant in the EU, without a detour via a US LLM provider.

Cost comparison against generative LLMs on retrieval and matching tasks; depends on the model and query volume.