Reranker -custom expression based

[kumaramit01]

Hey Folks -Appreciate all the FunctionScore/Reranker work that has been done on Milvus over the last 6 months -I am interested in an Expression based custom reranker, it seems to line up with other the existing Decay/Model/Weight/RRF rerankers. We have some gnarly rerank functions that unfortunately do not map to the existing implementations in Milvus -the flexibility of being specify the custom reranker would help us in experimentation and migration. A client could use it something like this

from pymilvus import ...

rerank_func = Function(
    name="custom_rerank",
    function_type="Rerank",
    input_field_names=["created_at", "popularity"],
    params={
        "reranker": "expr",
        "expr_code": """ 
            let age_days = (1757288322 - fields["created_at"]) / 86400;
            let recency = exp(-0.01 * age_days);
            let pop_boost = 1.0 + log(fields["popularity"] + 1) / 10.0;
            score * recency * pop_boost
        """
    }   
)

Let me know what you all think -I can write a more formal enhancement/idea and follow up with an implementation if this has interest. Looking at 2025 Roadmap discussion it seems to align #40263

Best,
Amit

[xiaofan-luan]

Hi @kumaramit01

Yes this is on our roadmap. We are thinking of adding User defined function to support this.

Whether support python based UDF or WASM based UDF is still under discussion. Hopefully this will released together with Milvus 3.0.

Contribution, Suggestions are required. The Final Step would be supporting Ray Based UDF to all the customized logic can be running in a Ray cluster.

[kumaramit01]

@xiaofan-luan -that sounds great. Is there a doc or basic design that talks about how this UDF will look like from user perspective and any implementations that you think have done the WASM/UDF adoption better and a good model to look at? I am thinking about aspects like loading/defining/storing the udf binary, ease of development.
Python and Wasm offer different benefits -Python ones will be easy to develop and is the common language with many of the users compared to Wasm being more performant.
Let us know what you are thinking here and happy to help

Thanks
Amit

[xiaofan-luan]

right now we don't have design docs ready yet.
but I think we will probably have on later this month. @junjiejiangjjj

python will probably be supported first due to it's flexibility.
This library can potentially help us to call python from golang https://github.com/go-python/cpy3

[xiaofan-luan]

Feel free to write some document ore demo code and we'd definitely glad to talk about it

[kumaramit01]

hi @xiaofan-luan I have put together a prototype using expr-lang to enable Go-native reranking expressions -links in the doc. The experiment shows that we can run runtime-compiled functions with minimal dependencies and reasonable performance.

Longer-term, I agree that WASM, Python, and C-based UDFs are strong directions -especially with the promise of Ray-based UDFs for flexibility and scale. My view is that these make sense as a fast-follow once we validate expr-lang as a baseline.

Doc: https://docs.google.com/document/d/1gjel8t06GK9to35DX5xoeV-MOyZAmD5yauf8BUS4hrg

PDF: Custom-Reranking-Milvus.pdf

[xiaofan-luan]

that seems to be good, is there a pr for this?

Agree that in long time python would be more flexible.

Having an exprlang based udf is definitely not a bad idea

[kumaramit01]

that seems to be good, is there a pr for this?

Agree that in long time python would be more flexible.

Having an exprlang based udf is definitely not a bad idea

I have some experimental code for the expr_ranker that I used to run the benahcmarks
https://github.com/milvus-io/milvus/blob/e20deef99c1585ce32d504d8fa659b9d66e6566a/internal/util/function/rerank/expr_rerank.go

and

milvus/internal/util/function/rerank/function_score.go

Line 150 in e20deef

case ExprRerankName:

It's part of some larger changes -but definitely interested in changing/making it flexible where it needs to execute(proxy/query) as I mentioned in the message below.

[junjiejiangjjj]

These calculations will be better if they are moved down to the segment layer. The proxy layer is suitable for model-based reranker. @xiaofan-luan

[xiaofan-luan]

如果将这些计算移到segment层中，效果会更好。该proxy层适合基于模型的重新排序器。 @xiaofan-luan

there will be two layers.

Querynode/Proxy has one layer, and proxy has aother layer to do global calculation

[kumaramit01]

@xiaofan-luan Here is a PR #45043
This PR adds the two new Rankers we discussed above -they run on the proxy nodes -once we are able to accept the rankers, I can send another PR to allow rankers to run on the querynodes. That requires an API change and would like to discuss that.
Let's start with the new Rankers and let me know if have questions

[kumaramit01]

Thanks -yes it makes sense for these to move to the segment. So apply the reranker after the segments results are reduced before sending it to the query node. Looks like I will need to pipe a new FunctionSchema field through the SearchRequest and apply in the searchChannel function. Best,AmitOn Oct 6, 2025, at 20:44, junjiejiangjjj ***@***.***> wrote: These calculations will be better if they are moved down to the segment layer. The proxy layer is suitable for model-based reranker. @xiaofan-luan —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>