Skip to content

JAVA-6099 Add new fields for Auto embedding #1936

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
strogiyotec wants to merge 3 commits into
base: main
Choose a base branch
from
Open

JAVA-6099 Add new fields for Auto embedding #1936

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9065008
JAVA-6099 Add new fields for Auto embedding
Apr 9, 2026
c140c58
disable test case
Apr 9, 2026
b674eb9
upgrade embedding test cases
Apr 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
198 changes: 198 additions & 0 deletions ...ional/com/mongodb/client/vector/AbstractAutomatedEmbeddingVectorSearchFunctionalTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,12 +28,15 @@
import org.bson.codecs.configuration.CodecRegistry;
import org.bson.codecs.pojo.PojoCodecProvider;
import org.bson.conversions.Bson;
import org.junit.Ignore;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Assumptions;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;

import java.util.ArrayList;
import java.util.Collections;
Expand All @@ -44,6 +47,7 @@
import static com.mongodb.client.model.Aggregates.vectorSearch;
import static com.mongodb.client.model.search.SearchPath.fieldPath;
import static com.mongodb.client.model.search.VectorSearchOptions.approximateVectorSearchOptions;
import static com.mongodb.client.model.search.VectorSearchOptions.exactVectorSearchOptions;
import static com.mongodb.client.model.search.VectorSearchQuery.textQuery;
import static java.util.Arrays.asList;
import static org.bson.codecs.configuration.CodecRegistries.fromProviders;
Expand Down Expand Up @@ -210,6 +214,200 @@ private void insertDocumentsForEmbedding() {
));
}


@ParameterizedTest(name = "should create auto embedding index with {0} quantization")
@ValueSource(strings = {"float", "scalar", "binary", "binaryNoRescore"})
void shouldCreateAutoEmbeddingIndexWithQuantization(final String quantization) {
final String indexName = INDEX_NAME + "_" + quantization;
mongoClient.getDatabase(getDatabaseName()).createCollection(getCollectionName());
SearchIndexModel indexModel = new SearchIndexModel(
indexName,
new Document(
"fields",
Collections.singletonList(
new Document("type", "autoEmbed")
.append("modality", "text")
.append("path", FIELD_SEARCH_PATH)
.append("model", "voyage-4-large")
.append("quantization", quantization)
)),
SearchIndexType.vectorSearch()
);
List<String> result = documentCollection.createSearchIndexes(Collections.singletonList(indexModel));
Assertions.assertFalse(result.isEmpty());
}

@Test
@DisplayName("should create auto embedding index with custom numDimensions")
@Ignore("Currently numDimensions can't be used, it fails with server error: 'Invalid numDimensions value for autoEmbed field in index: test_auto_embed. Expected an integer.'")
Copy link

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The @Ignore reason mentions an index name test_auto_embed, but this test creates the index using INDEX_NAME (currently "voyage_4"). Consider making the ignore/disabled message generic or matching the actual index name to avoid confusion when diagnosing failures.

Suggested change
@Ignore("Currently numDimensions can't be used, it fails with server error: 'Invalid numDimensions value for autoEmbed field in index: test_auto_embed. Expected an integer.'")
@Ignore("Currently numDimensions can't be used; it fails with a server error for the autoEmbed field: 'Invalid numDimensions value for autoEmbed field. Expected an integer.'")

Copilot uses AI. Check for mistakes.
void shouldCreateAutoEmbeddingIndexWithCustomNumDimensions() {
Comment on lines 31 to +243
Copy link

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test class is using JUnit Jupiter (@test, @beforeeach, etc.), but the method is annotated with JUnit 4's @ignore. JUnit Jupiter will not honor @ignore, so when the class-level Assumption is eventually removed this test will run (and currently looks intended to be skipped). Use org.junit.jupiter.api.Disabled (or the project’s existing conditional-disable mechanism) and drop the org.junit.Ignore import.

Copilot uses AI. Check for mistakes.
mongoClient.getDatabase(getDatabaseName()).createCollection(getCollectionName());
SearchIndexModel indexModel = new SearchIndexModel(
INDEX_NAME,
new Document(
"fields",
Collections.singletonList(
new Document("type", "autoEmbed")
.append("modality", "text")
.append("path", FIELD_SEARCH_PATH)
.append("model", "voyage-4-large")
.append("numDimensions", 512)
)),
SearchIndexType.vectorSearch()
);
List<String> result = documentCollection.createSearchIndexes(Collections.singletonList(indexModel));
Assertions.assertFalse(result.isEmpty());
}

@Test
@DisplayName("should create auto embedding index with filter field")
void shouldCreateAutoEmbeddingIndexWithFilterField() {
Copy link
Copy Markdown
Member

@vbabanin vbabanin Apr 14, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Index creation and vector search queries are separate concerns, and the codebase currently reflects this split:

Index management tests (index creation, deletion etc) live in AbstractAtlasSearchIndexManagementProseTest
Vector search query tests live in AggregatesBinaryVectorSearchIntegrationTest / AbstractAutomatedEmbeddingVectorSearchFunctionalTest

I suggest we move the index creation tests in this PR to AbstractAtlasSearchIndexManagementProseTest:

  • shouldCreateAutoEmbeddingIndexWithQuantization
  • shouldCreateAutoEmbeddingIndexWithCustomNumDimensions
  • shouldCreateAutoEmbeddingIndexWithFilterField
  • shouldFailWhenMixingVectorAndAutoEmbedTypes
  • shouldFailWhenDuplicatePathsAreUsed
  • shouldFailWhenAutoEmbedFieldUsedAsFilterField

They aren’t spec-defined prose tests today, but colocating this additional (non-prose) coverage alongside the prose tests is still a good fit: it extends index-management coverage in the same area, and if/when the spec adds auto-embedding prose tests, they’d naturally land there as well. The C# driver took the same approach by adding auto-embed index creation tests under their Atlas Search index management tests (mongo-csharp-driver PR #1900).

The class would stay then quite simple and would have only:

  1. shouldExecuteVectorSearchQuery (existing, from previous PR)
  2. shoulduExecuteVectorSearchWithModelOverride (new, added in this PR)
  3. shouldExecuteExactVectorSearchQuery (new, added in this PR)

mongoClient.getDatabase(getDatabaseName()).createCollection(getCollectionName());
SearchIndexModel indexModel = new SearchIndexModel(
INDEX_NAME,
new Document(
"fields",
asList(
new Document("type", "autoEmbed")
.append("modality", "text")
.append("path", FIELD_SEARCH_PATH)
.append("model", "voyage-4-large"),
new Document("type", "filter")
.append("path", "director")
)),
SearchIndexType.vectorSearch()
);
List<String> result = documentCollection.createSearchIndexes(Collections.singletonList(indexModel));
Assertions.assertFalse(result.isEmpty());
}

@Test
@DisplayName("should fail when mixing vector and autoEmbed types in the same index")
void shouldFailWhenMixingVectorAndAutoEmbedTypes() {
mongoClient.getDatabase(getDatabaseName()).createCollection(getCollectionName());
SearchIndexModel indexModel = new SearchIndexModel(
INDEX_NAME,
new Document(
"fields",
asList(
new Document("type", "autoEmbed")
.append("modality", "text")
.append("path", FIELD_SEARCH_PATH)
.append("model", "voyage-4-large"),
new Document("type", "vector")
.append("path", "plot_embedding")
.append("numDimensions", 1024)
.append("similarity", "cosine")
)),
SearchIndexType.vectorSearch()
);
Assertions.assertThrows(
MongoCommandException.class,
() -> documentCollection.createSearchIndexes(Collections.singletonList(indexModel)),
"Expected index creation to fail because vector and autoEmbed types cannot be mixed"
);
}

@Test
@DisplayName("should fail when duplicate paths are used")
void shouldFailWhenDuplicatePathsAreUsed() {
mongoClient.getDatabase(getDatabaseName()).createCollection(getCollectionName());
SearchIndexModel indexModel = new SearchIndexModel(
INDEX_NAME,
new Document(
"fields",
asList(
new Document("type", "autoEmbed")
.append("modality", "text")
.append("path", FIELD_SEARCH_PATH)
.append("model", "voyage-4-large"),
new Document("type", "autoEmbed")
.append("modality", "text")
.append("path", FIELD_SEARCH_PATH)
.append("model", "voyage-4-large")
)),
SearchIndexType.vectorSearch()
);
Assertions.assertThrows(
MongoCommandException.class,
() -> documentCollection.createSearchIndexes(Collections.singletonList(indexModel)),
"Expected index creation to fail because of duplicate paths"
);
}

@Test
@DisplayName("should fail when autoEmbed field is used as filter field")
void shouldFailWhenAutoEmbedFieldUsedAsFilterField() {
mongoClient.getDatabase(getDatabaseName()).createCollection(getCollectionName());
SearchIndexModel indexModel = new SearchIndexModel(
INDEX_NAME,
new Document(
"fields",
asList(
new Document("type", "autoEmbed")
.append("modality", "text")
.append("path", FIELD_SEARCH_PATH)
.append("model", "voyage-4-large"),
new Document("type", "filter")
.append("path", FIELD_SEARCH_PATH)
)),
SearchIndexType.vectorSearch()
);
Assertions.assertThrows(
MongoCommandException.class,
() -> documentCollection.createSearchIndexes(Collections.singletonList(indexModel)),
"Expected index creation to fail because autoEmbed field cannot be used as a filter field"
);
}

@Test
@DisplayName("should create auto embedding index and run query with model override")
void shouldCreateAutoEmbeddingIndexAndRunQueryWithModelOverride() throws InterruptedException {
mongoClient.getDatabase(getDatabaseName()).createCollection(getCollectionName());
createAutoEmbeddingIndex("voyage-4-large");
Copy link
Copy Markdown
Member

@vbabanin vbabanin Apr 14, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is related to the suggestion in: #1936 (comment)

Currently, these tests mix two concerns: index setup and running a query. When a test covers both, a failure doesn’t tell us - without digging into logs/code - whether the setup broke (index creation) or the operation broke (query execution).

This applies to:
shouldCreateAutoEmbeddingIndexAndRunQueryWithModelOverride
shouldCreateAutoEmbeddingIndexAndRunExactVectorSearchQuery
shouldCreateAutoEmbeddingIndexAndRunVectorSearchQuery

The createAutoEmbeddingIndex("voyage-4-large") is the exact same setup duplicated across all three - it's not the SUT, it's a prerequisite:

        createAutoEmbeddingIndex("voyage-4-large");
        TimeUnit.SECONDS.sleep(2L);
        insertDocumentsForEmbedding();
        TimeUnit.SECONDS.sleep(2L);

I think we should follow the pattern in AggregatesBinaryVectorSearchIntegrationTest: create the index and shared test data once, and have each test method exercise a single query concern (approximate, exact, model override), e.g. via @BeforeAll (and later it will be a pre-created index on the QA cluster).

The same pattern we did before:

  • AggregatesBinaryVectorSearchIntegrationTest (38fc561) - index setup in the BeforeAll.
  • Migration to QA cluster.

TimeUnit.SECONDS.sleep(2L);
insertDocumentsForEmbedding();
TimeUnit.SECONDS.sleep(2L);

List<Bson> pipeline = asList(
vectorSearch(
fieldPath(FIELD_SEARCH_PATH),
textQuery("movies about love").model("voyage-4-large"),
Comment on lines +367 to +375
Copy link
Copy Markdown
Member

@vbabanin vbabanin Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn’t actually exercise an override. The index is created with voyage-4-large, and the query also specifies .model("voyage-4-large") - same model. An override would mean using a different compatible model at query time.

The spec calls this out for the voyage-4 family (interoperability within the same family). To test override, we should create the index with voyage-4-large and run the query with a different compatible model (e.g., voyage-4 or voyage-4-lite).

INDEX_NAME,
5L,
approximateVectorSearchOptions(5L)
)
);
List<Document> documents = documentCollection.aggregate(pipeline).into(new ArrayList<>());

Assertions.assertFalse(documents.isEmpty(), "Expected to get some results from vector search query");
Assertions.assertEquals(MOVIE_NAME, documents.get(0).getString("title"));
}

@Test
@DisplayName("should create auto embedding index and run exact vector search query")
void shouldCreateAutoEmbeddingIndexAndRunExactVectorSearchQuery() throws InterruptedException {
mongoClient.getDatabase(getDatabaseName()).createCollection(getCollectionName());
createAutoEmbeddingIndex("voyage-4-large");
TimeUnit.SECONDS.sleep(2L);
insertDocumentsForEmbedding();
TimeUnit.SECONDS.sleep(2L);

List<Bson> pipeline = asList(
vectorSearch(
fieldPath(FIELD_SEARCH_PATH),
textQuery("movies about love"),
INDEX_NAME,
5L,
exactVectorSearchOptions()
)
);
List<Document> documents = documentCollection.aggregate(pipeline).into(new ArrayList<>());

Assertions.assertFalse(documents.isEmpty(), "Expected to get some results from exact vector search query");
Assertions.assertEquals(MOVIE_NAME, documents.get(0).getString("title"));
}

private void createAutoEmbeddingIndex(final String modelName) {
SearchIndexModel indexModel = new SearchIndexModel(
INDEX_NAME,
Expand Down