gaoj0017 commented on PR #14078:
URL: https://github.com/apache/lucene/pull/14078#issuecomment-2573030521

   Hi @msokolov , the discussion here is not only about the blog posts but also 
related to the pull request here. In this pull request (and its related blogs), 
it claims a new method without properly acknowledging the 
contributions/inspirations from our extended RaBitQ method as we have explained 
in our last reply. Besides, we believe this discussion is relevant to the 
Lucene community because Lucene is a collaborative project, used and 
contributed to by many teams beyond Elastic.
   
   Thanks @mikemccand for your kind words - we truly appreciate them! It is 
also an honor to us that RaBitQ and the extended RaBitQ are seen as impactful 
in improving industry productivity.
   
   Our responses to @benwtrent  are as follows.
   Point 1 in our last reply: This has been ignored in Ben’s reply. We would 
like to emphasize once again that the so-called “BBQ” method from Elastic is 
largely based on our RaBitQ method, with only minor modifications - this can be 
reflected in the previous PRs. Yet Elastic has repeatedly referred to BBQ as 
their new algorithm without acknowledging RaBitQ. For example, in a [press 
release](https://www.elastic.co/blog/whats-new-elasticsearch-platform-8-16-0 ), 
Elastic states that "Elasticsearch’s new BBQ algorithm redefines vector 
quantization," omitting any reference to RaBitQ. This is unacceptable and 
particularly unfair to other teams who have openly acknowledged their use of 
RaBitQ. We request that our RaBitQ method should be properly credited in all 
existing and future blogs, press releases, pull requests, and other 
communications regarding the “BBQ” method.
   
   Point 2 in our last reply:  In the related blog that describes the method in 
this pull request, it states “Although the RaBitQ approach is conceptually 
rather different to scalar quantization, we were inspired to re-evaluate 
whether similar performance could be unlocked for scalar quantization” - this 
is not true since this target has already been achieved by our extended RaBitQ 
method. Your team should not have made this mis-claim by ignoring our extended 
RaBitQ method since we circulated our extended RaBitQ paper to your team more 
than three months ago. In addition, our extended RaBitQ method proposed the 
idea of searching for the optimal parameters of scalar quantization for each 
vector (for details, please refer to our 
[blog](https://dev.to/gaoj0017/extended-rabitq-an-optimized-scalar-quantization-method-83m)).
 The method in this pull request has adopted a highly similar idea. For this 
reason, we request that in any existing and potentially future channels of 
introducing t
 he method in this PR, proper acknowledgement of our extended RaBitQ method 
should be made.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to