News for hackers. Stuff that matters.
Re:Build a search engine, not a vector DB by sroussey on Wednesday December 20, 2023 @03:21AM (#38706491)
Ask the LLM to summarize the question, then take an embedding of that.

I think you can do the same with data you store… summarize it to same number of tokens, then get an embedding for that to save with the original text.

Test! Different combinations of summarizing LLM and embedding generation LLM can get different results. But once you decide, you are locked in the summarizer as much as the embedding generator.

Not sure is this is what the parent meant though.

Re:Build a search engine, not a vector DB by sroussey on Wednesday December 20, 2023 @03:23AM (#38706504)
BTW: I think of this like asking someone to put things into their own words, and then it’s easier for them to remember. Matching on your way of talking can be weird from the LLM’s point of view, so use their point of view!
Re:Build a search engine, not a vector DB by deckar01 on Wednesday December 20, 2023 @11:47AM (#38710643)
It is two different language models. The embedding model tries to capture too many irrelevant aspects of the prompt that ends up putting it close to seemingly random documents. Inverting the question into the LLM’s blind guess and distilling it down to keywords causes the embedding to be very sparse and specific. A popular strategy has been to invert the documents into questions during initial embedding, but I think that is a performance hack that still suffers from sentence prompts being bad vector indexes.
Re:Build a search engine, not a vector DB by sroussey on Wednesday December 20, 2023 @12:36PM (#38711250)
You can use llama2 to do embedding and summaries and chat.

Turning the docs into questions is something I will test on stuff (just learning and getting a feel).

I am intrigued... what makes a good vector index??

Re:Build a search engine, not a vector DB by deckar01 on Wednesday December 20, 2023 @05:03PM (#38714247)
My heuristic is how much noise is in the closest vectors. Even if the top k matches seem good, if the following noise has practically identical distance scores, it is going to fail a lot in practice. Ideally you could calculate some constant threshold so that everything closer is relevant and everything further is irrelevant.
Re:Build a search engine, not a vector DB by sroussey on Friday December 22, 2023 @12:04PM (#38736147)
Apologies for being naive, but how do you calculate noise?
Re:Build a search engine, not a vector DB by bayesian_limit on Thursday December 28, 2023 @01:04PM (#38796364)
I could not help but notice the Contriever curve is so much higher on y-axis Recall than the other methods (figure 11 in https://arxiv.org/pdf/2307.03172.pdf).

Has anyone come across more recent experiments, results, or papers related to this? I'm acquainted with the: - Contriever 2021 paper https://aclanthology.org/2021.eacl-main.74.pdf - Hyde 2022 https://arxiv.org/pdf/2212.10496.pdf

My suspicion is some pre-logic such as is the user's question dense enough then use Hyde with chat history. If anyone has more recent experience with Contrievers, would love to learn more about it!

Feel free to contact me directly on LinkedIn. https://www.linkedin.com/in/christybergman/