Loading video player...
Let's say your company has an employee
handbook that covers policies like time
off requests, dress code, and equipment
use. Employees might ask questions like,
"Can I wear jeans in the office?" or
"Can I request time off on a holiday?"
or "Can I bring my company laptop home
for the weekend?" While these are common
questions that people would typically
ask, building a database around this
requirement can be a little bit tricky.
In a conventional approach where data is
stored in a structured database like
SQL, you typically need to do some
amount of similarity search like select
all from documents where content like
holiday or time off with the emp% around
it. And to expand your result set, you
might even increase the scope by
dropping a few characters like this and
removing spaces between time and off
like this. However, the drawback to this
approach is that it puts the onus on the
person searching for the data to get the
search term formatted correctly. But
what if there was a different way to
store the data? What if instead of
storing them by the value, we store the
meaning of the words? This way when you
search the database by sending the
question itself, can I request a time
off on a holiday instead of the SQL
query. So based on the meaning of the
words contained in the question, the
database returns only relevant data
back. This is a spirit of what vector
databases try to address storing data by
the embedding. So essentially, instead
of searching by value, we can now search
by meaning. While conceptually this
might seem a little bit straightforward,
there's a bit of an overhead in setting
this up. And you might be asking, well,
can we just throw the employee handbook
document into the database like we would
in SQL database? Not quite. And here's
why. With SQL databases, the burden is
actually put on the user searching for
the data that's stored in the structured
database. But with vector databases, the
burden is put on you who is actually
setting up the database since you are
trying to make it easier for someone
searching for the data that's inside it.
And you can imagine why a method like
this is becoming extremely popular when
paired with the large language models in
AI since you don't have to train the LLM
separately on how to actually search
your database. Instead, the LLM can
freely search based on meaning and have
the confidence that your database will
return relevant data that it needs. So,
let's explore some of the key concepts
behind what goes into setting up a basic
vector database. Let's start with the
embedding. Embedding is really the key
concept that makes the medium go from
value to meaning. In SQL, we store the
values contained in the employee
handbook as a straightup value. But in
vector databases, you need to do a
little bit of extra work up front to
convert the value into its semantic
meanings. And these meanings are stored
in what's called an embedding. For
example, the words holiday and vacation
should semantically share a similar
space since the meaning of those words
are close to each other. So before the
sentences like employee shall not
request time off on holidays that's
stored in the document is added to the
database, the system runs it through an
embedding model. The embedding model
converts the sentence into a long vector
of numbers and when you search the
database, you're actually comparing this
exact vector. That way when someone
later asks, "Can I take a vacation
during a holiday?" Even though the
phrasing is different, the database can
still service the request. This is the
fundamental shift. Instead of searching
by exact wording, we're now searching by
meaning. Another important concept is
dimensionality. And you might be asking,
why do I have to worry about
dimensionality? Can't I just throw the
words into an embedding and store them
into the database? Well, there's one
more aspect in embedding that you need
to think about. That's dimensionality.
Typically, a word doesn't just have one
meaning to learn from. For example, the
word vacation can have different
semantics depending on the context that
it is used. and capturing all the
intricacies like tone, formality and
other features that give richness to the
words are important. Typical dimensions
that we use today are,536
dimensions which gives a good mix of not
having too much storage burden in size
but also giving enough context to allow
for depth in each search. So once the
embedding is stored with the proper
dimension, there are two other major
angles that we need to consider when we
are working with vector databases and
this is the retrieval side. Meaning now
that we store the meaning of those
words, we have to take on the burden of
the retrieval of these embeddings. Since
we are not doing searches like we did in
SQL, we need to make a decision on what
would technically be counted as a match
semantically and by how much. This is
done by looking at scoring and chunk
overlap. And if you're wondering at this
point, this just seems like a lot of
tweaking just to use a vector database.
And that's the serious trade-off that
you ought to consider when using a
vector database, which is that while a
properly set up vector database makes
searching so much more flexible, getting
the data stored and retrieved often adds
complexity. So with that in mind,
scoring is a threshold that you set to
how similar the results need to be to be
considered a proper match. For example,
the word Florida might have some
similarity to the word vacation since
it's often where people go for vacation.
But asking the question, can I take my
company laptop to Florida is very
different than does my company allow
vacation to Florida? Since one is asking
about a policy on IT jurisdiction and
the other about the vacation policy. So
setting a score threshold based on the
question can help limit low similarities
to count as a match. Okay, there's one
final angle which is the chunk overlap.
So in SQL, we're used to storing things
rowby row. But in a vector database,
things look slightly different. When
we're storing values in vector database,
they're often chunked going into the
database. So when we chunk down an
employee handbook into chunks, it's
possible that the meaning gets chunked
with it. That's why we allow chunk
overlap so that the context spills over
to leave enough margin for the search to
work properly. Popular implementation of
vector databases include Pine Cone and
Chroma DB. And these platforms are
designed to handle embeddings at scale
and provide efficient retrieval based on
semantic similarity. And these are also
great tools to use for prototyping
something really quick. So now that we
have these concepts understood, we can
actually take on the burden of making
search easier for users and taking on
the burden ourselves to set up a vector
database for the company to use it for
employee handbooks and many more
documents that we need. All right, let's
start with the labs. In these series of
labs, we're going to explore how vector
databases solve one of the most
fundamental problems in information
retrieval. the semantic gap between how
humans ask questions and how computers
store information. While traditional SQL
databases require exact keyword matches,
vector databases understand meaning,
making them the backbone of modern AI
applications. Let's start by setting up
our environment. In this first section,
we're asked to run a simple setup script
that installs NumPy for vector
mathematics, sentence transformers for
real AI embeddings, and Chromma DB for
our production vector database. Once
you've activated the virtual
environment, we'll jump into lab one. In
this demonstration, you'll create a real
SQLite database containing company
policies, the dress code, time off
rules, and remote work guidelines. When
an employee asks, "What are the clothing
rules?" You'll watch the SQL like
operator search for clothing in the
policies. The result, nothing. Zero
matches. The policy says dress code, not
clothing, and SQL doesn't understand
these terms are related. Each query
pauses to let you see the failure happen
in real time. By the end, you're looking
at a 0% success rate. Three reasonable
questions but three complete failures.
Moving on to lab two, we encounter the
magic of embeddings. In this question,
we're asked to understand how the all
mini LM L6V2 model with its 22 million
parameters transformed words into
384dimensional
vectors. Here's where things gets
fascinating. You'll start by comparing
word pairs that mean the same thing but
share no common letters. The lab loads a
real AI model and shows you how holiday
and vacation, completely different
words, produce vectors that are 87%
similar. You'll see the actual numbers,
watching as the model converts each word
into a list of 384 floatingoint values.
The lab then explores why we need so
many dimensions. Just like describing a
person requires more than just their
height, capturing their meaning of texts
require hundreds of dimensions. One
dimension might capture formality,
another the topic, another the
sentiment. With 384 dimensions, the
model captures incredibly nuanced
semantic relationships. The interactive
section here lets you type any two texts
and see their similarity score in real
time.
Lab 3 takes us into similarity search
where we build our own vector database
from scratch. In this demonstration,
you'll implement cosign similarity and
see how it enables semantic search that
actually works. The real magic happens
when you test natural language queries.
Can I wear jeans to work? doesn't
contain the words dress or code, yet it
correctly matches the dress code policy.
The lab visualizes similarity scores as
progress bars, making it easy to see
which policies are most relevant. One of
the most enlightening sections is the
Florida example. When you ask, can I
take my company laptop to Florida? It
matches the remote work policy because
it understands that this is about
equipment. But can I use vacation days
for Florida trip? Matches the time off
policy because it recognizes this is
about vacation. So the same word Florida
completely different context correctly
identified. The scoring threshold
section is crucial for production
systems. You experiment with different
values. 0.7 for high confidence, 0.5 for
moderate matches, 0.3 for weak
associations. Setting the threshold too
high means missing relevant results
while too low introduces noise. Our
final lab, lab 4, brings everything
together with Chroma DB, a
productionready vector database used by
company worldwide. In this
demonstration, you're building Tia's
complete smart handbook system that can
answer any employee question naturally.
You'll start by initializing ChromadB
with persistence and load comprehensive
policy documents. You'll see queries
like, "Can I wear jeans on Monday?"
correctly matching the dress code policy
with accurate answer that jeans are only
allowed on Fridays. What makes this lab
particularly valuable is the document
chunking demonstration. You'll see why
overlap matters when splitting long
documents. The lab shows how carelessly
splitting text can break words in half.
Imagine splitting the word vacation into
vacay and chun across chunks. The
meaning is completely lost. With proper
overlap, split the sentence boundaries
first, then combine sentences to reach
target chunk size. Never split in the
middle of words. So, preserving semantic
coherence. With this, we have come to
the end of the lab where you've seen SQL
fail with natural language, watched AI
transform text into meaningful vectors,
implemented similarity search from
scratch, and deployed a productionready
system with Chromma DB. The key insight
is that vector databases aren't just
about better search. They're about
bridging the semantic gap between human
language and computer storage.
🧪Try Vector Database Hands-On Labs for Free - https://kode.wiki/46vlLjG Learn how Vector Databases are revolutionizing AI search and powering the next generation of intelligent applications! In this comprehensive video, we'll show you exactly how vector databases transform traditional keyword-based search into semantic understanding that actually comprehends meaning, not just matching words. Ready to build your own vector database system? Access our FREE interactive labs where you can experiment with real vector implementations, test different embedding strategies, and see semantic search in action! 🧪Try Vector Database Hands-On Labs for Free - https://kode.wiki/46vlLjG 🎯 What You'll Learn: • What are vector databases and why they're essential for modern AI • How embeddings transform text into searchable numerical representations • The magic behind 384-dimensional semantic space • Vector similarity scoring and threshold optimization • Critical chunking strategies for optimal retrieval • Real ChromaDB implementation walkthrough • Why traditional SQL databases fail with natural language queries Perfect for developers, AI engineers, and anyone building intelligent search systems! ⏰ Timestamps: 00:00 - The Problem with Traditional SQL Search 00:49 - How does a Vector Database work? 02:10 - What Are Embeddings? 03:08 - Understanding Vector Dimensions 03:50 - Scoring in Vector DB 05:05 - Chunk Overlap in Vector DB 06:02 - Lab Demo - Setting up the Environment 06:39 - Lab Demo - Problem in Traditional SQL Database 07:13 - Lab Demo - Embeddings 08:23 - Lab Demo - Similarity Search 09:13 - Lab Demo - ChromaDB 10:10 - Conclusion & Free Lab Access #VectorDatabase #AI #Embeddings #SemanticSearch #ChromaDB #Pinecone #ArtificialIntelligence #AITutorial #VectorEmbeddings #kodekloud