Hacker News Reader

Comment by dsr_ | Hacker News Reader

So instead of asking google or wikipedia, you ask a natural language tokenizer to break your query into several possible queries, then feed that to an LLM in order to get an essay that might answer your question.

Do I have that basically correct?

edit, 43 minutes later: the first three responders say yes. So, it's a way of increasing the verbosity and reducing the reliability of responses to search queries. Yay! Who would not want such a thing?

(me. And probably you.)

View on HN

At its most basic perhaps. But the LLM has an enormous semantic corpus embedded in its model that augments the retrieved document. The retrieved document in a way cements the context better to help prevent wandering into hallucinations. So the LLM would indeed be able to summarize the retrieved document, but also synthesize it with other “knowledge” embedded in its model.

But the more important thing is you can interrogate the LLM to ask it the specific questions you have based on what it has said and your goals. Contrast this to an information retrieval based methods where you read the article hoping your questions are answered, and when they aren’t you are stuck digging through less and less relevant results or refining a search string hoping to find the right incantation that tweaks the index in the right way, sifting through documents that may contain the kernel of information somewhere if it wasn’t SEO’ed out of existence. This is a really unnatural way of discovering information - the natural way, say with a teacher, is to be told background, ask questions, and iterate to understanding. This is how chat based LLMs work.

However with RAG you can ground them more concretely, as their model is a massive mishmash of everything that may or may not embed the information sought, but it’s also mixed in with everything else trained. You can bring in factual information into context that may not have even been trained. However the facts are a small aspect of knowledge - the overall semantics in the total corpus supports the facts in adjacent areas.

You could also introduce a classifier step that takes the result of the query and asks the LLM if the results truly are relevant or not before passing them on to the summarization step. You can even add more steps (with possibly diminishing returns) such as taking the more relevant results and crafting a new query that is a very condensed summary, embedding it and then finding more results that are semantically similar to it.

Yep. But the idea that a RAG backed LLM is merely an efficient summarizer is missing the real power, which is it can summarize then be interrogated iteratively to refine in a semantic sense the actual questions you have, or explore adjacent spaces. It’s not just a search engine that can summarize, it’s a search engine that you can interrogate in natural language and it responds directly to your questions, as opposed to throwing a bunch of documents at you that have a probability of being related to your query.

Yes, a bit, though an important feature here is it's still searching the underlying data sources (e.g. Google, Wikipedia, or others) and then using a LLM to summarize the results.

The "natural language tokenizer" itself is often an LLM (they do a pretty good job of this).

A further extension this article doesn't talk about is to have a LLM with a different prompt analyze the answer before returning to the user, and do more queries if it doesn't believe the question has been well answered (imagine clicking "next page" of google search results under the hood).

The potential complexity of this scales all the way up to a full "research assistant" LLM "agent" that calls itself recursively.

Before learning about RAG I thought that it is recurrent LLM agent that traverse over documents. After some study I must say that VectorDBs are boring.

It can be as simple or as complicated as you want. The article starts off by saying the naive approach of just embedding the query and looking for similar documents is a bad approach and what you actually want to embed and compare is something similar to the expected result. They don't go into detail on this but using their example of "what is the capital of France" you would conceivably transform that into "list of European capital cities" or "list of cities in France" using an LLM, embed that, find the similar documents, feed those documents into an LLM along with the query and some system instructions about how to format the response and then return that. Keep in mind this is an absurdly simplified example query and none of this process is needed to answer the actual question which the LLM would know from its training data but you would want this process in place to ensure accurate results for more complex or specialized queries.

> none of this process is needed to answer the actual question which the LLM would know from its training data.

I think this isn't true; even if the model has the answer stored implicitly in its weights, it has no way of "citing it's source" or demonstrating that the answer is correct.

if your model can't predict the completion of "the capital of France is _" then it's going to really suck for other completions

This is a great example of something GPT-4 gets confidently wrong, today. I just ran this query:

Prompt: "The year is 894 AD. The capital of France is: Response: "In 894 AD, the capital of France was Paris."

This is incorrect. According to Wikipedia, "In the 10th century Paris was a provincial cathedral city of little political or economic significance..."

The problem is that there's no good way to tell from this interaction whether it's true or false, because the mechanism that GPT-4 uses to return an answer is the same whether it's correct or incorrect.

Unless you already know the answer, the only way to be confident that a LLM is answering correctly is to use RAG to find a citation.

lol you just gamed it with an edge case where the most likely completion is incorrect and you're proving my point that the simple case doesn't need RAG but weird complex edge cases do.

But how is the user supposed to know if their query is a weird complex edge case or not? The model certainly can't tell them.

which is why you would use RAG if you want your app to be an encyclopedia

What, because you want your encyclopedia to be confidently wrong on everything that -- unbeknownst to both you and your encyclopedia reader(s?) -- happens to be "a complicated edge case"? (And what isn't "a complicated edge case", in some way or other?)

Eh... Does that really make sense to you?

Not quite, the advantage is that you can give it any documents you want to search even ones that aren't available to google or wikipedia. But I think otherwise that is essentially what is proposed here. The nice part is that since you know which documents got looked up when forumlating the answer you can also provide those as part of the output to the user so they can then go check the source data to confirm what was stated by the LLM.

Reply on news.ycombinator.com