Thanks Ameer! Was thinking about few ideas. Thought something like tapping into Codec extension to store multi-IDF values in 2 files, namely an IDF Meta-file & a IDF Data-file
IDF Meta-file holds List of {UserId, Terms-Data-File-Offset} pairs for each Term, encoded via ForUtil. IDF Data-file that holds a "Count" & {doc_type, idf} pairs, encoded as vInts. ["Count" is the number of vInt pairs to decode for a given UserId] TermStats for each Term also needs to be extended to store the start offsets pairs of {IDF Meta-file, IDF Data-file}, as vLongs There's a possibility of long-tail occurring in IDF Meta file. That is, the users sharing a term (possibly a common term) could be very high, in which case we might need to generate a sampling data. But it is currently doesn't happen in our app This is just a quick hack & really don't have an estimate of the penalty we have to pay for fetching this info Not sure if this is a worthwhile idea to explore. Any input from members is much appreciated -- Ravi On Tue, Dec 3, 2019 at 10:30 PM Ameer Albahem <ameer.alba...@gmail.com> wrote: > IDF is a simple measure to calculate. So, if building a separate index for > each user is not an ideal solution, then I suggest you could try to > calculate these statistics upfront. Just maintain these statistics for each > user, then use them in the query process. > > As the search time, you use these stats in your ranking. One possible way > is to write a similarity wrapper that will read the needed information from > a hash map. > > Regards > Ameer > > > > On Wed, 4 Dec 2019 at 00:55, Ravikumar Govindarajan < > ravikumar.govindara...@gmail.com> wrote: > > > > > > > it is enough to give each its own field. > > > > > > > I kind of over-simplified the problem at hand. Apologies. > > > > DOC_TYPE is just one aspect of the problem. The other one is that, it is > > actually shared index where there are multiple-users (100-3000 users per > > index). There are many hundreds of such shared-indexes in our cluster > > > > Search happens per-user & it doesn't make sense to have a single IDF. We > > are ideally looking at some lucene extensions/tricks to store & retrieve > > IDF in <User/DOC_TYPE> pairs. > > > > Is there any reason why you are not storing each DOC_TYPE in its own > index? > > > > > > There are some common-fields across all DOC_TYPES (Ex: content/attachment > > et al..) & to provide unified-search for a user, we colocate them in a > > single index > > > > -- > > Ravi > > > > On Tue, Dec 3, 2019 at 6:30 PM Diego Ceccarelli (BLOOMBERG/ LONDON) < > > dceccarel...@bloomberg.net> wrote: > > > > > Hi Ravi, > > > Can you give more details on how you store an entity into lucene? what > is > > > a doc type? > > > what fields do you have? > > > > > > Cheers > > > > > > From: java-user@lucene.apache.org At: 12/03/19 12:50:40To: > > > java-user@lucene.apache.org > > > Subject: Multi-IDF for a single term possible? > > > > > > Hello, > > > > > > We are using TF-IDF for scoring (Yet to migrate to BM25). Different > > > entities (DOC_TYPES) are crunched & stored together in a single index. > > > > > > When it comes to IDF, I find that there is a single value computed > across > > > documents & stored as part of TermStats, whereas our documents are not > > > homogeneous. So, a single IDF value doesn't work for us > > > > > > We would like to compute IDF for each <Term/DOC_TYPE> pair, store it & > > > later use the paired-IDF values during query time. Is something like > this > > > possible via Codecs or other mechanisms? > > > > > > Any help is much appreciated > > > > > > -- > > > Ravi > > > > > > > > > > > >