It was comforting for some LinkedIn Recruiter users to hear about the search results discrepancies, shared previously in the posts
- Discrepancies in Search: LinkedIn Recruiter vs. Personal
- LinkedIn Basic Search is Semantic – LIR Search is NOT.
Here is some feedback I got:
“GREAT GREAT GREAT article on the discrepancies in search (LIR vs Personal LinkedIn). A few colleagues and I have been experiencing the same problems but were chalking it up to software bugs…”
“Glad you posted this! You validated the fact that I am not crazy! I had the same exact thing happen to me about two weeks ago. Side by side searches yielding less profiles from the LIR account search vs my own personal one.”
Here is an update.
I am happy to report that I got a clear explanation of what is going on there at a recent live “Technical Deep Dive” at LinkedIn San Francisco.
I was impressed with the Software Engineers at LinkedIn at the meeting; they are obviously high-class folks. They were explaining the complex ideas behind the new search algorithm and relevance. The difference in the search code behind LIR and Personal was not a central point of the Meetup in any way; it was just mentioned in passing. Of course, it is not the Engineers’ responsibility to explain to Recruiters what changes have been implemented.
So – not that we are getting any updates on when LIR is going to be moved to Galene (and it will be); not what user query interpretations are coming… but at least the basic reason for the differences is quite clear.
I heard about some exciting new features coming up with further development of Galene. If you are curious, I believe you can find some slides and materials online from the Software Engineers, to whom I listened, Sriram Sankar and Rahul Aggarwal, as well as from other LinkedIn Engineers.
I am proud that my guess, that semantic interpretation of the personal search happens before the search is executed, proved to be the case in reality. The Engineers used this language for it: “converting user query into a structured Galene query” and, in another instance, “query rewriting”.
As a side note, this information makes me worry about searching in LIR. Apparently the “old search”, Lucene, cannot be properly scaled to manage searching on that much information. The scaling necessities is what initially triggered the Galene development a year and 1/2 ago. LIR is currently working on a weak search mechanism, inadequate to handle 300+ MLN profiles and other data.