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.