Summary
rerank(...) can only be attached to the near* search operators. BM25, Hybrid and FetchObjects cannot be reranked through the client, even though the server, the gRPC wire format and the other official clients all support it.
Where it comes from
rerank(Rerank) is declared on BaseVectorSearchBuilder:
abstract class BaseVectorSearchBuilder<SelfT, NearT> extends BaseQueryOptions.Builder<SelfT, NearT> {
public SelfT rerank(Rerank);
...
}
so only NearText.Builder, NearVector.Builder, NearObject.Builder and the NearMediaBuilder family inherit it. Bm25.Builder, Hybrid.Builder and FetchObjects.Builder extend BaseQueryOptions.Builder, which has no rerank.
It is not a wire limitation
SearchRequest.rerank is a top-level proto field. Marshalling a plain BM25 search with the client's own code produces a request with hasRerank() == false — nothing sets it — but setting that single field and sending the result down the same GrpcTransport works:
client marshalled hasRerank=false
BM25+rerank over gRPC: rows=3 scores=3
0.054848 The rabbit is a small and cute animal,
0.051831 The cat is an independent and agile do
0.051601 The dog is a very popular domestic ani
Those values match what GraphQL returns for the same query (0.05484826, 0.05183117, 0.051601294), so the server is doing the same work either way.
Verified against Weaviate 1.39.0 with reranker-cohere, client 6.3.1. The equivalent GraphQL queries succeed for both BM25 and Hybrid:
{ Get { Reranker(limit: 3, bm25: {query: "animal"}) {
t1 _additional { rerank(property: "t1", query: "fish") { score } } } } }
Other clients expose it
The docs page for reranking has a "Rerank keyword search results" section with bm25Rerank examples for Python, JavaScript/TypeScript, Go and GraphQL. Java is the only language missing from that tab set.
Suggested fix
Move rerank from BaseVectorSearchBuilder up to BaseQueryOptions.Builder, so every search operator inherits it. Rerank.appendTo(SearchRequest.Builder) already targets the top-level request, so no marshalling change appears to be needed.
Version
- java-client 6.3.1 (also present in 6.3.0)
- Weaviate 1.39.0
Summary
rerank(...)can only be attached to thenear*search operators. BM25, Hybrid and FetchObjects cannot be reranked through the client, even though the server, the gRPC wire format and the other official clients all support it.Where it comes from
rerank(Rerank)is declared onBaseVectorSearchBuilder:so only
NearText.Builder,NearVector.Builder,NearObject.Builderand theNearMediaBuilderfamily inherit it.Bm25.Builder,Hybrid.BuilderandFetchObjects.BuilderextendBaseQueryOptions.Builder, which has norerank.It is not a wire limitation
SearchRequest.rerankis a top-level proto field. Marshalling a plain BM25 search with the client's own code produces a request withhasRerank() == false— nothing sets it — but setting that single field and sending the result down the sameGrpcTransportworks:Those values match what GraphQL returns for the same query (
0.05484826,0.05183117,0.051601294), so the server is doing the same work either way.Verified against Weaviate 1.39.0 with
reranker-cohere, client 6.3.1. The equivalent GraphQL queries succeed for both BM25 and Hybrid:{ Get { Reranker(limit: 3, bm25: {query: "animal"}) { t1 _additional { rerank(property: "t1", query: "fish") { score } } } } }Other clients expose it
The docs page for reranking has a "Rerank keyword search results" section with
bm25Rerankexamples for Python, JavaScript/TypeScript, Go and GraphQL. Java is the only language missing from that tab set.Suggested fix
Move
rerankfromBaseVectorSearchBuilderup toBaseQueryOptions.Builder, so every search operator inherits it.Rerank.appendTo(SearchRequest.Builder)already targets the top-level request, so no marshalling change appears to be needed.Version