Skip to content

Comments

Feat/lv 2l#176

Open
addloopy wants to merge 3 commits intodevelopfrom
feat/lv-2l
Open

Feat/lv 2l#176
addloopy wants to merge 3 commits intodevelopfrom
feat/lv-2l

Conversation

@addloopy
Copy link
Collaborator

🔁 Pull Request Template – BharatMLStack

Please fill out the following sections to help us review your changes efficiently.


📌 Summary

e.g., Adds optimizes Redis fetch latency in online-feature-store, or improves search UI responsiveness in trufflebox-ui.


📂 Modules Affected

  • horizon (Real-time systems / networking)
  • online-feature-store (Feature serving infra)
  • trufflebox-ui (Admin panel / UI)
  • infra (Docker, CI/CD, GCP/AWS setup)
  • docs (Documentation updates)
  • Other: ___________

✅ Type of Change

  • Feature addition
  • Bug fix
  • Infra / build system change
  • Performance improvement
  • Refactor
  • Documentation
  • Other: ___________

📊 Benchmark / Metrics (if applicable)

@addloopy addloopy added the draft Draft PR label Jul 25, 2025
Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment bugbot run to trigger another review on this PR

p.t().dot(&x)
} else {
x.to_owned()
};
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: OPQ Rotation Matrix Mismatch

The ProductQuantizer applies the rotation matrix inconsistently between the training (build_level0) and encoding (encode_vector) phases. During training, the rotation is applied as a right multiplication (X @ P), but during encoding, it's applied as a left multiplication with the transpose (P^T @ x). This mathematical discrepancy leads to incorrect vector transformations and quantization results when Optional Product Quantization (OPQ) is enabled. The encode_vector method should apply the rotation as x.dot(&p) to match the training phase.

Locations (1)

Fix in CursorFix in Web

"Dimension mismatch: {} != {} * {}",
total_dims, m_blocks, dims_per_block
));
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Quantizer Limits Exceeded

The ProductQuantizer's encoding and decoding logic implicitly limits k_centroids and m_blocks to a maximum of 16. This is because centroid IDs are packed into 4-bit fields within a u64 code.

  • If k_centroids exceeds 16, centroid IDs will be truncated, causing silent data corruption.
  • If m_blocks exceeds 16, the bit shift for encoding will exceed the u64's capacity, leading to undefined behavior or incorrect encoding.
    The build_level0 function lacks validation for these implicit limits.
Locations (1)

Fix in CursorFix in Web

p.dot(&decoded)
} else {
decoded
}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Quantizer Decoding Errors: Rotation and Bit Packing

The ProductQuantizer::decode_code method contains two bugs:

  1. Incorrect OPQ inverse rotation: It applies the rotation matrix P instead of its transpose P^T to reverse the transformation.
  2. k_centroids bit packing issue: It uses 4-bit packing (& 0xF) for centroid IDs, implicitly limiting k_centroids to 16. This causes out-of-bounds access if k_centroids < 16 and incorrect encoding/decoding if k_centroids > 16 (due to ID truncation).
Locations (1)

Fix in CursorFix in Web

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

draft Draft PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant