What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

MongoDB Automated Embedding generates embeddings for documents using models such as Voyage AI, but the generated embeddings are stored in an internal collection under __mdb_internal_search rather than being available as a field in the source document.

This makes the generated embedding difficult to use as application data outside of $vectorSearch. For example, it is not straightforward to retrieve, export, reuse, inspect, or pass the generated embedding to another system or downstream processing pipeline.

We would like to be able to access the embedding generated by Automated Embedding as a normal field associated with the source document.

What would you like to see happen?

Describe the desired outcome or enhancement.

We would like MongoDB Automated Embedding to optionally materialize the generated embedding into a configurable field in the source collection.

For example:

{
  "_id": 123,
  "description": "MongoDB is a document database",
  "descriptionEmbedding": [0.0123, -0.0456, ...]
}

MongoDB could continue using __mdb_internal_search internally for $vectorSearch and for managing embedding generation, synchronization, model changes, and re-embedding. The request is simply to provide an officially supported, user-visible representation of the generated embedding in the source document.

Ideally, the field would be automatically kept synchronized whenever the source content changes or the embedding is regenerated.

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

The main benefit would be being able to treat an automatically generated embedding as reusable application data while still benefiting from the simplicity of Automated Embedding.

Today, using Automated Embedding means giving up easy access to the generated vector. This creates friction for use cases such as exporting embeddings, integrating with other AI/vector systems, performing downstream processing, debugging or inspecting embeddings, and migrating between embedding/search solutions.

Without this capability, applications that need both automated embedding generation and access to the resulting vectors have to choose between Automated Embedding and manually generating/storing the embeddings themselves.

Providing an officially supported materialized field would give users the best of both approaches: managed embedding generation from MongoDB and direct access to the resulting vector.

What steps, if any, are you taking today to manage this problem?

Today, the alternatives are either to generate the embeddings ourselves and store them directly in the source documents, or to access the generated embeddings from the internal __mdb_internal_search collections.

The first approach requires us to manage embedding generation, synchronization, model configuration, and re-embedding ourselves, which largely defeats the purpose of Automated Embedding.

The second approach relies on an internal MongoDB namespace and internal collection structure, which is not an appropriate or stable application-facing interface.

As a result, there is currently no clean, officially supported way to use Automated Embedding while also treating the generated embedding as application data.