Search by meaning as well as words
Embeddings turn text into vectors that support similarity search. Wildo gives this work its own capability, so the service finding relevant material can be configured separately from the model composing an answer.
Corpus passages and search queries use the same model binding. This keeps the two sides of semantic search in the same vector space.
Example — Find a policy with different wording
A question about reimbursing a journey can retrieve relevant travel-expense passages even when its wording differs. Lexical search remains part of retrieval rather than being replaced by embeddings.
For engineers
The following configuration excerpts belong in three existing configuration sections, not one object. Preserve any capabilities already declared for OpenAI when adding embeddings. Application setup enables AI_EMBEDDINGS, declares a provider serving it and selects that provider for the runtime scope.
// In engineCapabilities:
[EngineCapability.AI_EMBEDDINGS]: { enabled: true },
// In the runtime scope's providers:
openai: {
engineCapabilities: [EngineCapability.AI_EMBEDDINGS],
providerCapabilities: ['LLM_EMBEDDINGS'],
protocols: ['EMBEDDINGS_PROVIDER'],
},
// In that scope's selection:
[EngineCapability.AI_EMBEDDINGS]: {
primary: 'openai',
whenUnavailable: [],
},
EmbeddingsBackendService.resolveBinding distinguishes a deliberately absent provider from a selected but broken configuration. With no provider, successfully ingested corpus text remains lexically searchable once its search indexes are ready; vectors can be produced later. The binding records provider, model and dimensions; changing the model requires the corpus to converge to the new vector space. Applications should not write a separate embedding loop for resource-backed retrieval.
Keep queries in the corpus’s vector space
Resource retrieval consumes embeddings through this service path after resolving its binding. The excerpt is internal framework code: query is the validated search text, applicability is the selected retrieval class, and resolution.binding is the configured binding checked earlier.
const embedded = await this.embeddings.embedTexts({
texts: [query],
purpose: EmbeddingsProvider_TextPurpose.QUERY,
applicability,
});
const vector = embedded.vectors[0];
if (!vector) {
throw new Error('Embeddings provider returned no vector for the query text.');
}
return {
embeddingClass: resolution.binding.applicability,
embeddingModel: embedded.model,
embeddingDims: embedded.dims,
vector,
};
The corpus worker uses the corresponding corpus purpose. Model and dimensions travel with the vector so retrieval can distinguish matching bindings from stale embeddings. Application features normally call resource retrieval and consume attributed passages; they do not need to manipulate these vectors directly. Configure AI_EMBEDDINGS and its provider in the runtime that runs both retrieval and the embedding worker.