feat: implement rerank step in collection search API

[Shushankranjan]

Issue - [#1158]

1. Enhanced the create_search method in collection_service.py:

   • Added reranking after all index operations (vector, fulltext, graph) are completed
   • Implemented the rerank model selection logic to find models with the "default_for_rerank" tag
   • Added error handling to gracefully fall back if reranking fails

2. Implemented the _get_default_rerank_model method:

   • This method finds rerank models with the "default_for_rerank" tag
   • Returns the first model found, or None if no model is available

3. Added the fallback strategy when no rerank model is available:

   • Places graph search results first (as they typically have better quality)
   • Sorts remaining vector and fulltext results by score in descending order

The implementation leverages the existing rerank functionality from the flow system, ensuring consistency across
the application. When a search is performed, the system will now:

1. Execute the search operations (vector, fulltext, graph)
2. Find a suitable rerank model with the "default_for_rerank" tag
3. Apply reranking to improve result quality
4. Fall back to a score-based ordering if reranking isn't available

This enhancement will significantly improve search result quality by leveraging the existing rerank
infrastructure in the direct search API.
Closes #1158

[earayu]

Hi, @Shushankranjan
You should use RerankNodeRunner.
You can find it in aperag/flow package, take rag_flow2.yaml as an example

[Shushankranjan]

Hi, @Shushankranjan You should use RerankNodeRunner.

Sure , i will change it to reranknoderunner

[earayu]

1. After finding the model, you need to verify if it has an API key configured. It's highly possible that an LLM provider might have tagged models without a configured API key.
2. You shouldn't create a separate FlowInstance just to run the rerank node. Instead, you should add the rerank node and its edges to the existing FlowInstance above.

[earayu]

You shouldn't re-execute the flow. Instead, you should check if there's a rerank node; if so, include it in the execution. If there's no rerank node, then use the default rerank strategy.

[earayu]

If there's no API key, the fallback rerank strategy should be used.

[earayu]

The rerank node shouldn't just be added; it should form a DAG after the merge node. Our flow process has actually implemented the combination of search + rerank; you can refer to rag_flow2.yaml.

[earayu]

@Shushankranjan Thanks for your contribution, but this implementation has several critical issues that need to be addressed:

1. Fundamental Logic Error - Duplicate DAG Execution

Your current approach executes the entire DAG twice:

1. First execution: vector_search → fulltext_search → graph_search → merge
2. Then you check for rerank models and re-execute the entire flow again

This is incorrect and wasteful. The correct approach should be:

• Check rerank availability before building the flow
• Build the appropriate flow structure once (with or without rerank node)
• Execute engine.execute_flow() only once

2. Code Quality Issues

• Duplicate Code: The fallback sorting logic is repeated 3 times (no API key, no rerank model, exception handling)
• Excessive Nesting: Deep if-else nesting makes the code hard to maintain

if docs:
    if rerank_model:
        if api_key:
            try:
                # rerank logic
            except:
                # fallback logic (duplicate 1)
        else:
            # fallback logic (duplicate 2)
    else:
        # fallback logic (duplicate 3)

3. Correct Implementation Direction

The flow should be:

1. Check rerank model availability and API key upfront
2. Build flow structure based on availability:
   • With rerank: search_nodes → merge → rerank
   • Without rerank: search_nodes → merge (with fallback sorting in merge node)
3. Execute flow once and get results from the final node

Please refactor to eliminate duplicate execution, extract the fallback logic into a separate method, and reduce nesting complexity.

[github-actions]

This PR is stale because it has been open 45 days with no activity. Remove stale label or comment