Comment by ritzaco | Hacker News Reader

Comment by ritzaco | Hacker News Reader

I don't think the author completely understands RAG, and this article is a bit disconnected and unclear to me. Google already provides a "flexible natural language query interface".

I think ironically it would be fairly trivial to build what he wants _using_ RAG.

1. Accept a natural language query, like ChatGPT et al already do

2. Ask an LLM to rephrase it in N different ways, optimized for Google searches

3. Scrape the top M pages for each of the output of 2 in parallel. You now have dozens of search results

4. Clean and vectorize all of these

5. Use either vector similarity or an LLM to return the best matching snippets for the original query from 1, constrained to stuff contained in 4.

It would take a little longer than a ChatGPT or Google response, but I can see the appeal too.

Have you actually tried to use Google in the last few years? Its query interface is horrible!

2024-era Google doesn't give you what you ask for - it'll take a few keywords from your query and "helpfully" invent a completely different query. Try asking it for anything remotely obscure and it'll just return complete garbage. Unless you're looking for a "20 dishwashers under $300" article, Google is basically unusable these days.

10 or 15 years ago Google was actually useful. You could specify exactly what keywords to include - and more importantly exclude. What I am looking for (and probably the author too) is an LLM which rephrases a human-language request into a SQL-like query to feed to a 2010 Google. Bonus points if it actually clearly states the query it's going to run and ask for corrections.

You want google to search exactly for the keywords in the query without any "helpful" reinterpretation, but at the same time to accept flexible human language requests. How do you expect these 2 contradictory requirements to coexist?

That's basically what we're doing with app.studyrecon.ai.

What we've found is that vector similarity is often not the final solution. It is still only a crude proxy for the true goal of 'informativeness' or 'usefulness' with relation to the user goal/query. Works okay, but we're definitely seeing a need for more rigorous LLM-postprocessing to enrich the results set.

Which, yes, the time adds up quick!

This sounds exactly like what Perplexity.ai does.

Reply on news.ycombinator.com