[9rx]

If an LLM understands that coffee and expresso are both relevant, like the earlier comment suggests, why wouldn't it understand that it should search for something like `foo LIKE '%coffee%' OR foo LIKE '%expresso%'`?

In fact, this is what ChatGPT came up with:

   SELECT *
   FROM documents
   WHERE text ILIKE '%coffee%'
      OR text ILIKE '%espresso%'
      OR text ILIKE '%latte%'
      OR text ILIKE '%cappuccino%'
      OR text ILIKE '%americano%'
      OR text ILIKE '%mocha%'
      OR text ILIKE '%macchiato%';

(I gave it no direction as to the structure of the DB, but it shouldn't be terribly difficult to adapt to your exact schema)

[jimbokun]

You are slowly approaching the vector solution.

There are an unlimited number of items to add to your “like” clauses. Vector search allows you to efficiently query for all of them at once.

[9rx]

The handwavvy assertion was that relational database solutions[1] work better in practice.

[1] Despite also somehow supporting MongoDB...

[mr_toad]

Implementations that use vector database do not use LLMs to generate queries against those databases. That would be incredibly expensive and slow (and yes there is a certain irony there).

Main advantages of a vector lookup are built-in fuzzy matching and the potential to keep a large amount of documentation in memory for low latency. I can’t see an RDMS being ideal for either. LLMs are slow enough already, adding a slow document lookup isn’t going to help.

[9rx]

The main disadvantage of vector lookup, allegedly, is that it doesn't work as well in practice. Did you, uh, forget to read the thread?

[cluckindan]

What does ”doesn’t work as well” mean here? From my experience, vector lookup via HNSW is fast and accurate enough for practical purposes.

[cluckindan]

You could ask an LLM to provide categorizarions for nouns and verbs, and store those. For ”I don’t like cappuccino”, you’d get back ”self”, ”human”, etc. for ”I”; ”negation” etc. for ”don’t”; ”preference”, ”trait” etc. for ”like”; ”coffee”, ”hot”, ”drink”, ”beverage” etc. for ”cappuccino”.

It would become unwieldy real fast, though. Easier to get an embedding for the sentence.

[muzani]

An actual use case I had for vector DBs was when users were using "credit card", "kredit kad", "kad kredit", "kartu" interchangeably.

If you're matching ("%card%" OR "%kad%"), you'll also match with things like virtual card, debit card, kadar (rates), akad (contract). The more languages you support, the more false hits you get.

Not to say SQL is wrong, but 30 year old technology works with 30 year old interfaces. It's not that people didn't imagine this back then. It's just that you end up with interfaces similar to dropdown filters and vending machines. If you're giving the user the flexibility of a LLM, you have to support the full range of inputs.

[9rx]

> The more languages you support, the more false hits you get.

Certainly you're at the mercy of what the LLM constructs. But if understands that, say, "debt card" isn't applicable to "card" it can add a negation filter. Like has already been said, you're basically just reinventing a vector database in 'relational' (that somehow includes MongoDB...) approach anyway.

But what is significant is the claim that it works better. That is a bold claim that deserves a closer look, but I'm not sure how you've added to that closer look by arbitrarily sharing your experience? I guess I've missed what you're trying to say. Everyone and their brother knows how a vector database works by this point.