Skip to main content
Embeddings turn the text of each record into a numeric vector so that semantically similar content sits close together in vector space. @talosjs/rag generates embeddings through OpenRouter. You pick the model in your vector database, and embedding then happens automatically on add() and search().

​
Choosing a model

Declare the model in getEmbeddingModel():
Every model is served through OpenRouter, so there’s no separate provider to configure. The available models:
Start with the default qwen3-embedding-8b. Reach for an OpenAI model only if you need parity with embeddings you already generate elsewhere through OpenAI.

​
Configuration

Embeddings are generated through OpenRouter, so set your API key in the environment:
The key is read when embeddings are generated, so a missing or invalid key surfaces when you first add() or search(), not at construction time.

​
How embedding works

You never compute or pass vectors yourself. When a table is created, the schema wires the embedding model into two roles: text is the source field (the column that gets embedded), and vector is where the generated embedding is stored and indexed. From there:
  1. On add(), the text of each record is sent to the embedding model and the resulting vector is stored on the row.
  2. On search(), your query string is embedded with the same model and compared against stored vectors.
Because the same model embeds both stored text and queries, the model is fixed for the life of a table.
The embedding model is part of a table’s schema. Changing getEmbeddingModel() after a table already exists does not re-embed existing rows. Embed new data into a fresh table instead, then switch over.

​
Where embeddings fit

Embeddings power the vector half of retrieval. At query time they are combined with a full-text search over the same text and merged with an RRF reranker. See Search for how the two halves come together.