Vector databases in plain English

When talking to customers about AI, one of the funnest challenges is to explain key innovations in plain English.

Yesterday, a customer asked me why people are moving to "vector databases".

Here's my analogy:

Imagine you are planning a big dinner party. You have many tables, and you would like the guests of each table to have common interests and topics.

So you labor away at night, planning and debating who to put next to whom.

When you are done, a surprising benefit is that you can find a certain type of guest depending on the table.

There is a table for university friends.

There is a table for your marketing team.

There is the "let's go OUT out" table.

A "vector database" enables the same benefit in a similar way – you can get to the right data simply by describing the type of data you want, instead of rigid if-then-else statements.

When data gets stored into a vector database, it uses an idea called "embeddings" to determine the "common interests" of each data record.

In the real world, there are many useful applications:

• you can put company data into a vector database, and get lookalike companies by describing a company profile. Works similarly for leads, contacts and opportunities.

• you can put case studies into a vector database, and enable your team to quickly find 3 relevant case studies, no matter the prospect.

• you can put help center articles and videos into a vector database, and match the right help content with a customer question.

What is your analogy for a vector DB?