41–50 of 84 posts
https://github.com/langroid/langroid/blob/main/langroid/agen...
Earlier quoted context omitted.
"we have no stemming support in Confluence" goes far beyond unfortunate defaults.
Which is the height of bullshit since Confluence uses Lucene internally, which obviously does support stemming (at least it didn't. Luckily, I haven't had to use Confluence for ages). Confluence search is what happens when some dev gets told "hey, add search, we need to mark a checkbox", searches for 30s for "Java search lib" and just adds Lucene without knowing anything about it.
How it survives (thrives) on the marketplace is a mystery.
Many, many big companies don't see any value in search. They simply use the defaults, and when those defaults are abysmal (like in the case of Confluence for example), well... they just suffer through it in silence. I have so far mostly failed in trying to explain 1/ why search matters and 2/ that not all "search" functionality are equal and that building good search is an art form.
> I have so far mostly failed in trying to explain 1/ why search matters and 2/ that not all "search" functionality are equal and that building good search is an art form. Yeah, it takes an absurd amount of tuning to make search work well. Given how poorly the average search field works in almost anything, it's fair to say this crucial step isn't happening. I suspect a lot of organizations just don't have workflows t…
Earlier quoted context omitted.
> I have so far mostly failed in trying to explain 1/ why search matters and 2/ that not all "search" functionality are equal and that building good search is an art form. Yeah, it takes an absurd amount of tuning to make search work well. Given how poorly the average search field works in almost anything, it's fair to say this crucial step isn't happening. I suspect a lot of organizations just don't have workflows t…
Doesn't look like work, yet tragically, incremental improvements to "frictionlessness" represent order-of-magnitude improvements to user experience.
I think a fundamental issue with search, and the reason why many companies do not invest in tuning a good search experience, is that the main metric usually is to minimise embarrassing/irrelevant results, rather than get the best possible set of results. How can you even know what is the best answer to your query? Systematic evaluation is very hard.
It's important we get through the trough of disillusionment quickly. There's a lot of market education needed to know when they're truly needed.
But be careful because the output is not guaranteed. Which means you have to take care to provide the schema and what you're trying to do within the context window, and validate the output. There is a non-trivial overhead to this.
Many, many big companies don't see any value in search. They simply use the defaults, and when those defaults are abysmal (like in the case of Confluence for example), well... they just suffer through it in silence. I have so far mostly failed in trying to explain 1/ why search matters and 2/ that not all "search" functionality are equal and that building good search is an art form.
I'd love to have a search engine for all of my different conversations I've ever had with people through various messaging apps, that combines email and my scanned documents through paperless-ngx and any other PDFs or documents in my nextcloud in a single search interface
I agree too. My impression is that almost all RAG tutorials _only_ talk about vector DBs, when these are not strictly required for Retrieval Augmented Generation. I'm guessing vector DBs are useful when you have massive amounts of documents on diverse topics. Some gotchas I experienced (but I might be using the wrong embedding/vector DB: spaCy/FAISS): - Short user questions might result a low signal query vector, e.…
Neo4j are mixing vector embeddings with knowledge graphs - https://neo4j.com/generativeai/
I have no opinion on your products or your post, but some % of people steer away from companies for such things.