[Feature Request]: [POC] Introduce v17::TopK with Deterministic NaN Handling Enum

[Lagmator22]

Request Description

1. Motivation & Model Examples

As discussed in PR #33633 with @mitruska and @nshchego, the current v11::TopK and earlier operations have implementation-defined NaN ordering behavior. Because different frontend frameworks handle NaNs differently (e.g., NumPy treats them as smallest, PyTorch treats them as largest), there is a need for a deterministic, configurable approach to NaN handling in OpenVINO.

Model Examples Benefiting from this:

• Multimodal AI Models (CLIP, Vision Transformers): Embeddings can occasionally produce NaN values due to numerical instabilities in FP16/BF16 projections. If TopK propagates these NaNs unpredictably, it corrupts downstream similarity searches.
• RAG (Retrieval-Augmented Generation) Pipelines: When retrieving the top K relevant document chunks, a single rogue NaN similarity score can currently push valid, highly-relevant documents out of the TopK results, breaking the retrieval chain entirely.

2. Proof of Concept (POC)

Following @mitruska's recommendation to prepare a POC to define constraints and benefits, I have built a comprehensive standalone C++ implementation here:
POC Repository & README: Lagmator22/TopK-NaN-OpenVINO

The POC demonstrates a proposed nan_mode attribute with three explicit modes:

1. NAN_AS_SMALLEST (Matches NumPy behavior: NaNs are pushed to the bottom of descending sorts)
2. NAN_AS_LARGEST (Matches PyTorch behavior: NaNs are pushed to the top of descending sorts)
3. NONE (Undefined/Fastest path: Preserves strict backward compatibility with current OpenVINO performance footprints)

3. Constraints & Benchmarking

To ensure no performance regressions for existing users, the POC includes micro-benchmarks comparing the NONE path against the NAN_AS_SMALLEST/NAN_AS_LARGEST paths.

• When nan_mode = NONE is selected, the sorting completely bypasses the NaN checks, ensuring identical performance to the current v11::TopK.
• When explicit handling is requested, the overhead is minimal and safely isolated.

4. Next Steps

Based on these findings, I am proposing the introduction of v17::TopK referencing this nan_mode structure. I would appreciate it if the maintainers could review the POC implementation and let me know if this architectural direction aligns with the project's vision!

(Note: I plan to write the upstream PR for v17::TopK as part of my ongoing open-source contributions to OpenVINO).

CC: @mitruska @nshchego @kblaszczak-intel @praasz

Feature Use Case

No response

Issue submission checklist

• The feature request or improvement must be related to OpenVINO

[DharshniRaja]

Hi, I would like to work on this issue. Could you please assign it to me?

[abhayuvi]

Hi, I would like to work on this issue. Could you please assign it to me?

Hey @DharshniRaja , just comment ".take" , the respected issue will be assigned to you . Please also kindly go through the attached PR .

[Rishabh-Sahni-0809]

. take

[SudharshanamBuddha]

Hello!
I went through the POC and the proposed nan_mode design makes sense for handling
framework inconsistencies.

I’m exploring how NaN handling is currently implemented in TopK across CPU/GPU paths
in OpenVINO to better understand integration points.

Would the intended implementation handle NaN ordering within the comparator itself,
or via preprocessing before sorting?

Happy to help with tests or validation if needed.

[Lagmator22]

Hi everyone, I appreciate the interest, but as noted in the issue description, I am already actively developing this feature and will be submitting the PR for it myself once the maintainers review the architectural POC. Because of this, the issue is not currently up for grabs!

@SudharshanamBuddha Thanks for checking out the POC! To answer your question, the implementation handles NaN ordering strictly within the comparator itself, rather than relying on a preprocessing pass. In the POC (specifically inside openvino/reference/topk.hpp), I introduced a NanAwareComparator that dynamically checks std::isnan() on the fly during the STL std::nth_element and std::stable_sort passes. I avoided preprocessing because a separate O(N) pass to scan, replace, and track NaNs introduces unnecessary overhead.
Crucially, when nan_mode == NONE is specified, the code completely bypasses the NanAwareComparator and delegates back to the original OpenVINO baseline comparator, guaranteeing zero performance regression for existing ops.

@mitruska Just pinging you on this thread whenever you have a moment to review the architectural approach! Let me know if this comparator-based design aligns with what you envisioned for v17.