RFC: optional exact late-interaction reranking and GPU scoring backends

[HuXinjing]

Summary

I have been prototyping an optional exact late-interaction reranking path for
VectorChord. The goal is to let PostgreSQL/vchordrq generate and govern a
candidate set while a pluggable backend computes exact MaxSim over full
multi-vector tensors. A CUDA sidecar and quantized tensor representations are
possible implementations, but neither would be required by the core extension.

Before opening implementation PRs, I would like feedback on whether the
maintainers consider these extension points compatible with VectorChord's
scope.

Motivation

The existing multi-vector index is effective for candidate generation, but
some applications also retain the original per-token tensor and want an exact
late-interaction score:

score(q, d) = sum over query tokens i of max over document tokens j dot(q_i, d_j)

Keeping candidate generation in PostgreSQL preserves filters, MVCC-visible
identities, and the existing index path. Keeping exact scoring behind a small
backend interface allows a CPU implementation, an external accelerator, or no
reranking at all without changing default behavior.

Prior work and attribution

The GPU scoring direction and the TileMaxSim name in this prototype are based on and inspired by Ashutosh Sharma’s ashutoshuiuc/tilemaxsim work, including its IO-aware tiled MaxSim formulation, dimension tiling, and fused product-quantized scoring.

This RFC does not claim those core GPU scoring ideas as original contributions. The work proposed here focuses on integrating this scoring model with VectorChord/PostgreSQL: a versioned backend boundary, external tensor metadata, bounded GPU/host/disk cache tiers, cache admission and eviction, multi-user fairness and priority scheduling, database-visible candidate binding, operational failure handling, and additional quantized kernel/runtime experiments.

The current Rust/CUDA implementation is an independent systems implementation and does not vendor the upstream Triton repository. The upstream repository currently does not publish a license file, so no upstream source code should be copied or adapted without explicit permission; any future reuse must also retain all applicable copyright and license notices.

Proposed boundaries

1. Planner statistics and cost model

   • Track indexed token counts without changing tuple layout compatibility.
   • Estimate candidate generation and optional exact reranking separately.
   • Keep all non-MaxSim opfamilies on the current upstream cost path.

2. Pluggable exact reranking interface

   • A narrow internal trait consumes the query tensor and explicit candidate
     identities.
   • A CPU reference backend defines correctness and fallback behavior.
   • Existing behavior remains the default.

3. Optional external tensor source

   • PostgreSQL stores governed metadata and immutable content references, not
     arbitrary accelerator state.
   • The request always contains an explicit candidate set; the scorer does not
     perform an implicit full-corpus search.
   • Versioned framing, bounded request sizes, timeouts, and fail-closed
     descriptor validation.

4. Optional GPU sidecar

   • Separate Rust/CUDA service and build target.
   • No CUDA dependency in the default extension build.
   • Bounded GPU/host caches, observable scheduling, and explicit fallback.

5. Optional scoring representations

   • Exact FP16 first; INT8/FP8 and PQ/OPQ/residual-PQ only as later backends.
   • A request binds an immutable quantization contract.
   • Quantization changes scoring precision only; it does not silently prune
     the candidate set.

Non-goals

• Tenant authorization inside the scoring daemon. Authorization remains an
  application/database concern; scheduler tenant IDs are resource hints only.
• Replacing vchordrq candidate generation.
• Requiring a GPU for normal VectorChord use.
• Making external storage or a particular model part of the core API.

Compatibility and failure behavior

• Default GUCs preserve the current upstream path.
• External protocols are explicitly versioned.
• Candidate and byte limits are enforced before allocation.
• Missing, inactive, mismatched, or corrupted tensor/quantization artifacts
  fail explicitly.
• CPU fallback is opt-in and never presented as equivalent precision when it
  is not.
• SQL upgrades preserve old metadata and treat absent new statistics as
  unknown rather than invalid.

Validation performed in the prototype

• PostgreSQL 16 release extension build from a clean container.
• Unit tests for planner estimates, descriptor validation, protocol versions,
  cache admission, fairness/priority scheduling, artifact activation and
  rollback.
• Real CUDA comparisons against CPU oracles for exact FP16, INT8, FP8, PQ,
  OPQ rotation, and multi-stage residual PQ.
• Tests for small-cache eviction, bounded batching, concurrent scheduling, and
  content-addressed artifact integrity.

The current full prototype is available on the
integration/upstream-main-tilemaxsim-v2
branch. It is intentionally not proposed as one PR: it is too broad and
also contains fork-specific documentation, packaging, benchmarks, and release
configuration.

Proposed upstream PR sequence

1. Planner statistics/cost model only.
2. Pluggable exact reranking trait plus CPU reference backend.
3. External tensor source registry and stable bounded protocol.
4. Optional GPU sidecar, if the external boundary is accepted.
5. Quantized GPU profiles, if the sidecar is accepted.

Each PR would be based independently on the latest upstream main, retain the
upstream CLA/workflows/README/release ownership, and include focused tests.

Questions for maintainers

1. Is exact reranking over an explicit vchordrq candidate set within the
   intended scope of VectorChord?
2. Would you prefer the backend interface to remain internal initially, or be
   exposed as a versioned extension API?
3. Is an optional external tensor descriptor registry acceptable, or should
   tensor storage remain entirely outside the extension?
4. If a CUDA implementation is acceptable, should it live in this repository,
   a separate repository, or only as a protocol-compatible example?
5. Would you like the first PR to contain only planner statistics, or planner
   statistics plus the CPU correctness backend?