<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
<br>
The approach I was thinking would look something like this:<br>
<br>
* instead of Features, which is really a namespace implemented as a<br>
class, we separate out the calculation of the different features<br>
into distinct subclasses of Feature, whose only job is to calculate<br>
a single feature. Currently the FeatureManager calls these (via<br>
FeatureManager::Internal::transform) with the correct arguments,<br>
things like document statistics or tf or idf caches. This is<br>
analogous to how Weight objects can request various statistics, and<br>
the Enquire process then makes them available. So we can do it in a<br>
similar way (Feature declares that it needs tf and doclen, for<br>
instance, and FeatureManager can make sure they're available to the<br>
Feature when it's building a FeatureVector for a given document).</blockquote><div><br></div><div>Yes. Features can get their own subdirectory with each Feature subclass having its own implementation. We can have FeatureManager do all the feature handling corresponding to a query. FeatureManager can have vector<Features*> FeatureList, which initialises each Feature sub-class object mentioned in the FeatureList (supplied at the time of training/ranking or as deafult set). </div><div>
<p class="">At present, letor is mostly centred around RankList (for both training and ranking), whereas RankList is just a vector of FeatureVectors corresponding to a qid. Having RankList in ranking has no meaning since qid isn't required once the training part is over. (letor_rank(*) method in letor_internal.cc supplies a junk qid to the RankList while performing the ranking, which points out that the RankList approach isn't quite correct). </p><p class="">Hence, RankList can be completely eliminated and instead we can have FeatureVector work on top of FeatureManager directly. Am I right?<br></p></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
* letor itself (during scoring) operates on FeatureVectors,<br>
representing Documents, and uses this to rerank an MSet; it does<br>
something similar during preparation of its training data. So how<br>
the FeatureVector is calculated just needs to be done the same<br>
in both situations.<br></blockquote><div> </div><div>Yes. At present Xapian::RankList create_rank_list(const Xapian::MSet & mset, std::string & qid, bool train) defined in FeatureManager does the job of preparing the FeatureVector for a query. At the time of preparing the training file, FeatureVector calculation can be done while parsing the query and qrel file, independently of RankList. Therefore, eliminating the need of maintaing a global qrel storage (map<string, map<string, int> > qrel; in FeatureManager::Internal) and thus eliminating the need of load_relevance(*) and getlabel(*) functions. The score in FeatureVector is simply the label, and fvals will be returned by FeatureManager (by using feature values obtained from each of the Feature sub-class).</div><div><br></div><div>While ranking, FeatureVector fvals will be computed similarly by FeatureManager, while the score gets assigned later at the time of ranking.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
* when configuring the letor system either for training or for<br>
reranking, we construct a FeatureList(*) (which is basically a<br>
vector<Feature>), which we can later ask to generate a<br>
FeatureVector for a given document. (This splits some of the<br>
functionality of FeatureManager, but makes it more clear what each<br>
piece does.)</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
* if you just construct a FeatureList, you'll get whatever the<br>
defaults should be. If you want to set your own features, you do<br>
that at construction time. That can include custom features, which<br>
wouldn't be possible under the enum model without editing<br>
xapian-letor and rebuilding it, which isn't friendly to<br>
developers.<br>
<br>
* Features becomes FeatureList, but with some functionality from<br>
FeatureManager. It's responsible for turning a Document into a<br>
FeatureVector, for the letor system to operate on.<br></blockquote><div><br></div><div>FeatureList can tell the vector<Features*> FeatureList object in FeatureManager as to what Features sub-classes to initialize. A vector<double> fval(*) function in FeatureManager can operate over vector<Features*> FeatureList to return fvals to the FeatureVector. Maybe your meaning of FeatureList is something different. Can you please explain?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
* Ranker should really be responsible for doing most of the work<br>
currently done by Letor. (Preparing training files, training the<br>
ranking algorithm &c.)<br></blockquote><div> </div><div>Preparing training file is limited to FeatureVector calculation only. Would there be a specific reason to include it in ranker?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
* The rest of FeatureManager is really utilities (which can be<br>
functions in the Xapian::Letor namespace, or methods on whichever<br>
class makes sense). For instance, load_relevance() has nothing to<br>
do with features; it's part of the training stage. (It's also on<br>
FeatureVector, with effectively the same implementation.)<br></blockquote><div> </div><div>Yes. These functions are not defined at correct places. If we decide to eliminate RankList, most of these methods will have no meaning and therefore will be removed.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
* RankList is mostly a list of FeatureVectors, ie it's close to the<br>
thing we care about at the end. The final output we want is<br>
actually a ranked list of Documents, but this is almost the same<br>
thing.<br>
<br>
(*) FeatureList isn't a great name, but I didn't want to adopt<br>
anything too close to what we have, as it'd be confusing.<br></blockquote><div> </div><div>As I have asked above, I think there is a misunderstanding between my interpretation of FeatureList and yours. Please correct me where I am wrong.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
We shouldn't need serialisation of FeatureList or Feature, because<br>
this stuff doesn't have to persist, just be consistent, which is an<br>
issue very similar to getting prefixes right. Either a higher-level<br>
application has configuration, or it's in shared code between the<br>
indexing/training and querying/reranking parts of the system.<br></blockquote><div> </div><div>I understand this now. Its the user's job to make it consistent. Thanks for clarifying this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class=""><font color="#888888">
J<br>
<br>
--<br>
James Aylett, occasional trouble-maker<br>
<a href="http://xapian.org" rel="noreferrer">xapian.org</a><br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:12.8px;font-family:arial"><font size="2" color="#666666">----------------------------------------------------------------------------</font></div><div style="font-size:12.8px;font-family:arial"><font size="2" color="#666666">Kind Regards,</font></div><div style="font-size:12.8px"><font size="2" color="#666666" style="font-family:arial">Ayush Tomar</font><font size="2" color="#0000ee" style="font-family:arial"> | <a href="http://ayshtmr.xyz" style="color:rgb(17,85,204)">My Webpage</a></font><font color="#666666" style="font-family:arial"> | <a href="https://in.linkedin.com/in/ayushtomar" style="color:rgb(17,85,204)">LinkedIn</a></font></div></div></div></div></div></div></div></div></div></div>
</div></div>