Do You Need A Vector Database in 2026? (ft Arjun Patel)

Join the Tool Use Discord: https://discord.gg/PnEGyXpjaX

Vector databases can be an important component for building reliable AI agents and scalable semantic search applications. In this episode, Arjun Patel from Pinecone breaks down how to optimize your RAG pipeline, choose the right embedding models (sparse vs. dense), and implement effective chunking strategies for better data retrieval. We also explore the new Pinecone plugin for Claude Code, demonstrating how to build a recommendation system and chat with your documents using Pinecone Assistant without writing complex code.

https://www.pinecone.io/

https://www.linkedin.com/in/arjunkirtipatel/

Connect with us 

https://x.com/ToolUsePodcast

https://x.com/MikeBirdTech 

00:00:00 - Intro

00:01:11 - What Vector Databases Unlock

00:04:40 - Optimal Chunking Strategies for RAG

00:09:07 - How Embedding Models Work

00:17:25 - Improving Search with Re-ranking

00:26:52 - SQL vs Vector Database Architecture

00:35:48 - Claude Code & Pinecone Assistant Demo

Subscribe for more insights on AI tools, productivity, and vector databases.

Tool Use is a weekly conversation with the top AI experts.

Episode Transcript

(00:00):
With agents becoming more powerful by the day, do you even
need a vector database? On episode 79 of Tool Use, we're
joined by Arjun Patel. He's the Senior Developer
Advocate at Pine Cone, which is a vector database for AI
applications. We're going to discuss what use
cases are best suited for vectordatabases, strategies to improve
the results from your vector database, and discuss the full

(00:21):
range from low level details up to no code implementation.
So please enjoy this conversation with Arjun Patel.
So a vector database is a specialized data store that
allows you to quickly index and query over information called
vectors. Vectors can be described many
different ways, but for our purposes we can just.
We can think of them as meaningful lists of numbers.

(00:43):
And it turns out that you can encode things that are
unstructured, like images, text,audio, video, sometimes even
tabular or data or PDFs, into these vectors that correspond to
meaning. And you can search over those
vectors really quickly by using other ones.
So the trick is, if you have hundreds of thousands of these
vectors, millions, 10s of millions, how can you do that

(01:06):
quickly and at scale? That's what a vector database is
for. And could you give some concrete
examples what gets unlocked whenwe use a vector database?
What is possible that wasn't possible prior?
Yeah. So any any operation that
requires searching over unstructured data at scale
becomes possible with a vector database, provided that you can
convert those things into vectors.
So for example, if you wanted tosearch across hundreds of

(01:29):
thousands of images with other images to find the most similar
ones, that operation is possiblewith the vector database and
embedding model. But let's say you're embedding
model also handles text input atthe same time.
Now you've unlocked the ability to do a sort of multimodal
search where you can pass in text queries and get back images
really quickly in that scale. And because the vector database

(01:50):
has this nice property of being able to index this data very
efficiently, the response times you get are going to be very,
very quick, like under seconds, under milliseconds, right?
So you're able to do these typesof fast operations much more
quickly than you would if you did a brute first search.
And just specifically around Pine Cone, I've heard about PG
vector and I think even SQL Litehas embeddings.

(02:10):
What what are the ranges in a vector database?
Like what's the what makes something premier versus
something that's more entry level?
Absolutely. So Pine Cone is a great option
for anybody who's trying to do really high throughput
operations or really high scale.But it's also wonderful for the
starting developer, right? All you have to do with Pine
Cone, we manage everything for you, so you can just interact
with us through the APIs. Nice thing about Pine Cone is

(02:33):
that it's very specialized in doing this type of vector
search. So you could use other services
that offer vector search capabilities.
But if you're really wanting something that's performing and
fast and focused on being able to return these items quickly,
you want to reach for Pine Cone,and that's where we specialize
and work well at. Is there any prep work or or or

(02:54):
things like that that people need to do before they go to a
vector database? You need to structure their data
certain way or prepare to to query the database differently.
What's the the prerequisites forthis?
Absolutely. So traditionally, and a lot of
this will be in the context of text data because when you start
thinking about other modalities,things get really hairy really
quickly. But for text data, the main the

(03:14):
thing that you usually need to do is turn it into vectors
before they can get indexed intoa vector database.
With Pine Cone, we have our own embedding models you can use
through something we call Pine Cone Inference.
So you can interact with the database entirely in text.
But the second order issue becomes how much text are you
allowed to represent in a fixed size vector, and how can you

(03:34):
search across those text vectorsin order to get the best, most
appropriate response? So most people have to do
something called chunking, whichmeans you take your input text
and you break it up into the literal chunks that are big
enough to fit in size the context window of the embedding
model that you're using. That's usually the extent of the
pre processing you have to do for a simple chunk based search.

(03:57):
So you can imagine if we had a bunch of sentences from the
titles of product reviews that we were embedding inside a
database and you wanted to do some sort of similarity search
where you're looking for certainproduct qualities that satisfy
some conditions. You could pass in that query
embedded, embed all the titles of all the product reviews and

(04:17):
have the most similar ones returned inside the vector
database and you'd be chunking at the sentence level.
But if you had a Wikipedia article, you might want to chunk
at the paragraph level because each paragraph encodes some sort
of meeting. However, at Pine Cone, we have a
product called Pine Cone Assistant now where you can just
throw your PD FS in and it'll dothe chunking for you.
So there's lots of different options to use the underlying
vector database, but traditionally you you got to do

(04:40):
some chunking. I've heard different techniques
around chunking strategies. We had Kirk Marple on a while
ago and he talked about wanting your chunks to have a little bit
of overlap with each other just to make sure you're not doing a
hard stop to to kind of bucket the context.
Do you have any insights there? Even though I know Pine Cone
Assistant could help with that. Just for people get an
understanding, what should they think about when they do their
chunking? Yeah.
So this is one of the most frequent questions we get asked

(05:03):
to the point where like we have an article on our website that's
like one of the most viewed articles on our website that's
about chunking strategies. And the the hard truth is that
it really depends on the type ofapplication that you're building
and the type of search that you want to benefit from.
But there are some heuristics that are pretty helpful.
What I normally tell people is to try the simplest chunking

(05:24):
strategy that you can implement on whatever data that you're
working on and hit your data setwith some queries and just see
how it feels querying the data and getting the responses back.
And as soon as you start lookingat how your data looks like,
once you've applied some sort ofchunking strategy, you will
quickly start to see some of theholes and issues.

(05:44):
For example, one of the common techniques that people implement
to fix a OK chunking strategy issomething called chunk
expansion. So if you have a bunch of chunks
in a document, let's go back to our Wikipedia example, you have
a bunch of paragraphs that you're chunking.
Sometimes the paragraph that you've embedded might not
contain the entirety of the argument that you're trying to

(06:05):
retrieve given some query. So it might just be a helpful
heuristic for you to look at where that paragraph is relative
to the rest of the document, andthen pull out the additional
chunks above and below that chunk in order to return an
entire kind of document there. Padgrown Assistant does that.
You could also do that yourself by including chunk numbers and
then just retrieving the -1 chunk and the +1 chunk.

(06:26):
And that can kind of remediate any sort of like not optimal
chunking strategy. So I would say like start at
like a meaningful unit of information that you feel like
is relevant for you. So for Wikipedia articles like
paragraphs are pretty good. Maybe you have a really
structure like textbook and you're like, OK, these chapters
and sub chapters should be like really the minimum amount of

(06:47):
information you look at. Or sometimes people do entire
pages. If you're dealing with like
multimodal PD FS and like all right, each page will be my
chunk. Trying something is better than
nothing, and trying to understand how far you can go
with a simple method is better than applying something really
complicated, spending a lot of time, and then not getting good
results. Yeah.
And when you mentioned potentially doing a full page,
is there an upper bound to how much you put in is?

(07:08):
Does it depend on the vector side?
So that's a really good question.
It's really dependent on the type of embedding model that
you're using, what it's context window is.
But like with chunking, there's some heuristics that you can
follow that make it easy to kindof do so.
It used to be the case that people would say that you could
fill up the entirety of the chunking window, the context

(07:29):
window of an embedding model. So if an embedding models like
context windows like 1024 tokensor 2048, you could just count
the number you should tokenize your text, fill up to that
amount, and just throw it insidethe embedding model.
But there's some anecdotal evidence that says that if you
do this for embedding models that have particularly large
context windows, so greater than2048, so on so forth, you might

(07:53):
start a washing out or averagingover the information that exists
in that chunk. And therefore it no longer
becomes relevant to any query than any other chunk would be.
So in that regime, you probably want to only fill up like half
to maybe 2/3 of a context windowand kind of go from there.
So that's that's kind of what I would say.

(08:14):
And it also depends on the complexity of your text.
So if your text is very information dense, then you want
to have smaller chunks that allow you to retrieve that
information kind of independently of one another.
But if your text is not information dense, then it's OK
to kind of pack more informationin there.
But yeah, it depends on your embedding model.
It depends on your depends on the amount of information you're

(08:35):
passing, but the vibes kind of tell me that.
Like as embedding models get really good at getting more and
more information in, that doesn't necessarily scale the
same way as how that informationis getting represented.
Similar to how if you have a context window for a model
that's like 200 K, 1,000,000 tokens, even if you jam all that
up, you're not going to get thatgreat of a response out.

(08:56):
Yeah, we very traditionally keepit under 50% if not lower just
to make sure we get the better results, especially with coding
models. Just on the note of embedding
models, I'm, I'm admittedly not very well versed in it.
When you talk about embedding models being better than others
is better just in terms of having because I, I OK, backing
up a bit. My idea is it takes a certain
amount of information and puts into a number of dimensions with

(09:18):
a value for each dimension. When an embedding model is
better than others, does it justmean that number like the vector
has more precision? Does it just have a better
representation of the information you give it?
Like what makes 1 embedding model better than another?
Man, this is like one of my favorite topics.
And this is like something that I've thought a lot about for
many years. So one of the one courses I took

(09:40):
in college on AI machine learning, because there weren't
that many offers at the time I was there, was on vector
embedding. So this is like the first kind
of thing that I was introduced to.
And all the techniques there aregoing to sound almost alien to
like anybody who's working with vector embeddings now, because
we're talking about techniques that work much differently than
the embedding models that do now.

(10:01):
For example, we could be talkingabout bag of word like
techniques which rely on the frequency of how often a word
occurs in a text and apply some sort of waiting algorithm to
that frequency in order to determine it's importance or
meaning. Whereas now we have this
completely unsupervised method that just produces a list of
numbers and it's not necessarilyinterpretable inside those
numbers. So I'm gonna try to give you a

(10:22):
brief overview of how these things are supposed to work and
then we can talk about what makes different things better
and more interesting. So at first when you had
embedding models, you had very simple heuristics that didn't
deal so much with the relationship between the words
in a given text. So if you think about searching
on Google before like, I don't know, 20/18/2017 2016 like

(10:43):
before they switched to a transformer kind of model.
When you search something, you type in as many keywords as you
can before you get a text that kind of maps with that keyword,
because you're basically just trying to hit all of those words
that are inside the thing that you're relevant and I think that
you're interested in looking for.
But the trick is, is that these words actually have meaning
associated with them. And the meaning of the words

(11:06):
depend on how they occur inside of a sentence.
So you can think about like homophones, like I went to the
park or I'm going to park, like those mean different things in
different contexts because of the way that they kind of relate
to one another. So there's this idea called the
distributional hypothesis, whichclaims that words can kind of,
you can kind of understand what words mean based on how they

(11:28):
cluster around the words that are around them.
So if you look at a word and youlook at the words next to them,
so there's something about the words that Co locate with that
center word that can give you information about what that word
means. And it turns out that if you
train a model to say, hey, here's the 1st 4 words in a
sentence, can you tell me the fifth word?
Or here's a sentence that has 10words.

(11:49):
I'm going to throw away 3 or 4 of them randomly.
And I want you to guess what words should kind of go in
there. If you train a model with that
objective, it turns out that youcan learn a lot about the
meaning of words from that task.So if you think of like Mad Libs
or you can think of just like charades, right?
Just like guessing words and trying to complete those things.
So we figured out how to train models that can follow that sort

(12:10):
of learning objective. And the representations that
these models learned in order toachieve that objective turned
out to be very good at representing the underlying
concept. So this is like the second wave
of like embedding models being able to represent what these
words kind of mean, right? And so the differentiation here
is the loss function. So how is the model learning

(12:30):
this information to generate this representation?
Is it getting better at guessingthe words that are there and
then also the data that's being trained on?
So the Wikipedia, the Internet, whatever corpuses you're going
on are gonna affect like this distribution of words that are
kind of occurring, right? And it turns out that you could
abandoned this idea of working only in English.

(12:51):
You could train a model that predicts on a sub word level or
token level, literally looking at like how often certain
characters are Co occurring and train on tons and tons of
languages and learn something fundamental about how tokens Co
occur, which inform the meaning of those words.
So you start getting surprising research results like, oh, we

(13:12):
were able to kind of train on the entire corpus of
multilingual data. And now we have a way of kind of
searching across languages, eventhough we haven't necessarily
cracked a deterministic way of translating across those
languages, right? There's something inherent about
how these words are coexisting that informs information there.
So going down to this sub token level, token level allowed us to

(13:33):
kind of capture more of this generalized information, right?
The last kind of way you can getmore power out of embedding
models or build embedding modelsthat are cleverer is gonna be
your data set distribution. So the previous thing I
described was like loss functions and then like clever
ways of preprocessing the data, looking at the sub token level.
And the last thing is data set distribution.

(13:54):
So this is where you get specialized embedding models
from. So if you want to say, do legal
search really, really well and it matters to you how to
represent this domain specific terminology, then you probably
need an embedding model that hasbeen fine-tuned on that data in
order to really understand what's going on there.
Because for the same reason thatwords mean different things in
different context, there are certain words that have

(14:16):
extremely powerful meanings in specific context that these
generalized embedding models will never have access to.
So if you're working at a large organization, you have tons of
internal data, maybe there's a concept or an idea that you
refer to that means something way different than it would out
on the Internet or out in the wild.
So changing the data distribution of how these
embedding models are trained on are gonna really affect their

(14:37):
ability to retrieve this information.
And there's also this idea of fine tuning for information
retrieval. So not only do we, so before I
describe tasks of like, oh, guessing words like, oh, like we
can like complete a sentence or we can fill in like what's
called masked sentences. Like, that's cute, right?
But we, we care about actually finding information.

(14:58):
So why don't we train on findinginformation?
So you'll have data sets that are like here's the input query
or real question someone asked, and here's like all the
documents that are actually relevant to that input query.
Can we produce a model that takes that input query, creates
an embedding, embeds these documents, creates another
embedding such that the relevantdocuments cluster closer in

(15:21):
vector space than the unrelevantones?
So now you're actually learning the signal that is important for
the test that we're describing, which is semantic search.
And that's kind of like this latter class of embedding models
that are getting really good at representing user questions and
kind of returning things back. So that was a little long
winded, but that's kind of like why you have to care about
embedding models and what they kind of do.

(15:42):
And the ones that we host have these properties of like, not
only are they good at generalizing, not only are they
good at blah, blah, they're alsoreally good at doing information
retrieval, which is why that we've kind of selected them to
be on our platform. OK, very cool.
Appreciate that explanation. I'm going to take a swing at my
like just explain my mental lot of what semantic similarity is
and and you just tell me how offI am because I had trouble.

(16:04):
I had trouble just like picturing things in, you know,
1024 dimensions. I just can't really comprehend
that. But when someone broke it down
and just brought down to 2 two basic dimensions, 2 arbitrary
points in in space, the semanticsimilar is kind of like the
angle between them. And if you want to have
something like with a smaller angle, it's more similar and a
bigger angle is less similar. So that's why semantic
similarity kind of gauges like what your threshold is for

(16:26):
difference. Is that okay?
Am I kind of close? Right, right, right.
That is one measure of semantic similarity.
And again, it depends on the embedding model and what
distribution of angles you're embedding model produces.
But that's like a detailed, right?
The overall idea is the closer in angle you are to this input
vector or query vector, the moresemantically similar and

(16:49):
relevant you could be to whatever question that you're
asking. And it's crazy, like when you
look at some of these word plotsthat some of these embedding
models produce, you'll get things that make a lot of sense.
Like you'll have the embedding for dog, and it'll be next to
like things that dogs do or things that dogs like.
And you'll have the embedding for a cat, and we'll be next to
the things that cats do or cats like.
But hot dog won't be near any ofthose things because it means a

(17:11):
completely different thing. And you're sitting there like,
how does this work? Like, how does this make any
sense? And it just, it just turns out
it just does. Like we can just learn
information from how these wordsare used in context.
That's pretty wild. But that that explanation is
more or less correct. Yeah.
But in terms of trying to fine tune a system so I I have my
vector database up, I have a fewqueries and I'm not totally in

(17:33):
love with the results I'm getting.
Is semantic similarity the one knob that I turn?
Or what else would I try to adjust to improve the quality of
my results? Right.
So having a good embedding modelis one piece of the puzzle of
building a performance semantic search system.
And semantic search is like a good layer of abstraction to
kind of talk about all kinds of applications.

(17:54):
You can build with Pine Cone or with other vector databases.
O we're talking about recommendation systems, we're
talking about like rag chat bots, all that stuff.
It's basically doing some sort of search under the hood.
So this is kind of like one layer, right?
And the embedding model will control how much fidelity you
can initially get with like yourquery and like all of your
documents that are being represented.

(18:15):
But there's still other engineering decisions or even
other models that you can kind of apply to the system in order
to improve the quality of the results.
But beyond like what the embedding model is giving you,
it's kind of like one thing you can do.
So a common recommendation we give at Pine Cone is to apply a
reranker to your results. So we talked about embedding
models which kind of like allow you to represent queries and

(18:37):
documents in vector space with respect to their meaning using
vectors. Rerankers do that kind of, but
instead of outputting and embedding, they output a score.
So the there's two trade-offs tothink about with these types of
models. So ideally what happens is you

(18:57):
have a query, you embed that query and you have a bunch of
documents, you embed those documents.
But when you embed those things,you're trying to extract the
meaning or the information inside the query and each
document independently, they don't know about one another.
And that's nice because it meansyou can embed all of your
documents independently of embedding your query.

(19:17):
So you can pre index your vectordatabase without having to
rebuild your index every single time as you get a new query.
And if you had to think about them in context.
So that makes that type of system very performant.
And this is a property of like any any vector database.
And the compromise though is that there are situations in
which you'd want to adjust the influence a a the idea of

(19:42):
relevance or similarity has based on the query and the
document at the same time. So what a reranker does is that
it inputs a query and a documentat the same time with context of
one another, and it outputs a score between zero and one.
Usually that score correlates tonot only the semantic
similarity, but the relevance ofthe document to the query.

(20:06):
O It's possible to have documents that are semantically
similar but aren't relevant. It could be about things that
are close in meaning to the thing that you're trying to ask,
but they're not the thing that you're actually looking for.
So we consider this as sort of refining step after doing an
initial semantic search. So you do a search, you have a
million documents, you reduce itdown to like 100 or 200

(20:27):
documents, and then you apply a reranker and you reduce it down
even further to the top, like 10or 15 documents and you return
that back. So that allows you to increase
the quality of the already good results to something even better
without having to re index everything.
So that's like one thing you cando, and there's tons of other
tools in the toolbox to make search better, but that's like
one thing we recommend. OK, and just so I'm making sure

(20:50):
I understand the rear maker concept so it won't impact the
embeddings at any weight. It's just like a filter after a
query returns a number of chunksor a number of embeddings I
should say. It is a, it is a scoring
algorithm. So it you, you could say it
filters for like the most relevant documents, but
mechanically it's rescoring everything, giving it a new

(21:13):
score. And then you order by that score
and just return everything past the cut off.
That's why I like to refer to itas refinement, because you get
like 100 documents and then you're saying, OK, I want to
further refine the quality of these 100 documents in the
context of this query. So then you reorder those
documents, and then you just take the top 15 most relevant
ones and return that back to theuser.

(21:35):
Right. And are rerankers, the type of
thing that can be fine-tuned based people, you know, they see
the performance like I actually want a number 12 or 13, let's
readjust it so that gets higher,higher ranking.
You could. There are limits to how
effective fine tuning is for like the developer.
It depends on how much data you already have and if your data

(21:55):
are labeled right. That's not easy.
Need to fine tune. Usually when you want to fine
tune something like information retrieval or a re ranker, you
need data sets that are like here's the query and here are
the relevant documents. And most people don't have that
because they don't have a systemin production yet or they don't
have it in the format that they actually need.
So you might have like data about, I don't know, things that

(22:18):
users are clicking on, but you might not know if that's
actually relevant to what they need.
It might just be a good heuristic.
So it is possible to fine tune any of these models, it just
depends on how specialized your domain is and whether you have
the data to support that sort ofoperation.
And is there anything such as metadata or I'm thinking like a
tagging system to put on embeddings to kind of highlight

(22:42):
them? Maybe it's from like a certain
book or certain chapter or something so you can instead of
going across everything, be likeI definitely want from this
area. Reduce the list that way.
Yeah. So this is another common thing
that people do with vector databases and on Pine Cone.
So we have two main systems of letting you.
And this is where like the engineering concerns of like
building a search engine really come into play.

(23:03):
So you can imagine that if you were some large like
organization or maybe you were just like a, a developer that's
really good at like getting datainto whatever system that you're
kind of making, building your own Wikipedia or whatever,
right? Indexing all of your notes, you
could have like a million documents or 100 million
documents or something insane, right?
And even if we have performant indexing algorithms, you might

(23:26):
not want to do a search that like does something to all of
those operations, right? You want to reduce the scope of
the search somewhat if you have some information at the
beginning, and there's two ways to do this with Pine Cone.
One is metadata filtering, whichis what you describe.
So every time you upsert A vector, which is our terminology
for putting data into your vector database, you can attach

(23:48):
metadata to that vector, and youcan also filter by that before
you're doing the vector search. So that means, hey, everything
that satisfies this, pull that and then do the vector search
over that information. So you're still getting the
benefits of a really performant vector search, but you're not
scanning like the entirety of your index because you don't

(24:08):
need to, because you already specified the filter in advance.
So you could do this with content, you could do it with
languages if you had multiple languages in a vector database
or sections of a document, any anything.
And the second, a layer of abstraction, which is more
strict is namespaces. Excuse me?
So namespaces are like partitions on your index that

(24:29):
allow you to enable a multi tenant architecture for your
users. So let's say you have a ton of
users and you don't want users to query each other's data, but
you want them all to live on thesame index so that you can
benefit from pine cones like auto scaling infrastructure.
We scale independently of queries and rights.
And you don't necessarily want everyone to have like their own
server or whatever. You kinda want them to all live

(24:50):
on the same infrastructure, so their latency is like quite low.
Namespaces let you specify that level of partition in your
database so that you're just querying inside there.
So each user could have their own namespace and then you're
just querying inside their partition of the vector
database. Are there any other free filters
or things that people should consider to help making sure

(25:11):
that the results they retrieve are accurate?
So metadata filtering is the bigone.
And then they're sort of like, and of course, metadata
filtering can be used for content type, any sort of
operation that allows you to, ifyou have this information in
advance, what data you're kind of putting into Pine Cone and
how you can sort of tag it. But another thing you could do

(25:32):
is have separate indexes and then use some sort of routing
mechanism in order to push people toward one index or
another. So, for example, you can embed
data in different ways, which allow for different sorts of
benefits. Like you can embed information
with a dense embedding model, which kind of exposes more
semantic meaningful concepts outof your data.

(25:55):
Or you can use a keyword or sparse embedding model, which
really focuses on the words thatare being used and their
meanings inside that context. And there might be situations in
which you want to route a user toward one type of search method
versus the other. And that way you're not hitting
the entirety of the index at thesame time, but you're just
hitting the specific kind of search method that they need.
That's something that somebody could implement like on top of

(26:18):
Pine Cone to route queries. We call that query routing.
That's another way of kind of like filtering results down.
Or if you, if you think you havean agent and it has access to
many different databases, you don't want it to hit every
single database on every single query.
You wanted to know about what information is in inside each
database and then only use the data from the relevant
databases. It kind of meta there, right?

(26:39):
You're doing a relevant databasesearch before you do a relevant
data search, and that can reduceyour search space as well, so be
beyond that. It's more engineering concerns
before you get to Pine Cone, butmetadata filtering is the really
big one. How well does a hybrid
architecture or or general advice you have?
If someone wants to use sequel for a portion of the information
in vector for another portion, how should I think about

(27:01):
dividing it? How should they orchestrate it?
Is it just simply having two simultaneous ones or or what?
What have you seen there? Yeah.
So this is a problem that a lot of like developers run into,
especially when they already have one database and they want
to kind of figure out another. So sometimes people will wanna
do like tabular structured operations on their vector data

(27:23):
or they'll have their tabular structured operations, but they
wanna do a vector search and they're like, well, what are
these heuristics I need to thinkabout and which data stores best
for what? So my advice would be is to
think about the type of search that you want to implement and
what field or fields of your data that you're already
collecting are gonna be important for that type of

(27:44):
search. That is the information that you
want to put inside Pine Cone because you can only embed like
one kind of concept in each of the indexes that you're kind of
working with. So an example would be like,
let's say you have product reviews and you have all this
information about the products, like what it is, how much it
costs, so on and so forth. That's like kind of your
structured data. And then you have the product
reviews which map back to the products.

(28:05):
And the product reviews are completely unstructured.
People can write like whatever they want.
So you might want to store information in Pine Cone being
the product reviews. Maybe you have another index for
just the titles, or you put the titles and the reviews in the
same index and then use metadatafilters to identify one from the
other, whatever you want to do. And you have a unique ID that
maps back to your structured database if you need to pull

(28:26):
this other information that's relevant.
And that way you're concentrating this like very
specific kind of data that requires this vector search
inside Pine Cone, which is what Pine Cone is really good for.
And then whenever you need to run your structured queries, you
can do that with your other databases.
It's really tempting for developers to kind of like
flatten their existing databasesand then put that all inside

(28:47):
Pine code and then try to do searches over that.
So like you can imagine if we had a product description and
all these attributes and all this stuff, you could put it
into one big text chunk and thenembed that whole thing.
That ends up doing the sort of averaging of information that we
talked about earlier where there's like too much stuff in
each chunk and that's not what you want to do.
You want to figure out the exactthing you want to help people

(29:10):
find and build the search for that thing.
OK, so for, for concrete example, in my world, yeah, at
Box 1 Ventures, if I have information on a company, the
location, the headcount, the founding year, all of that still
sits in sequel because it's verydirect, easy to query, but a
description of what the company does, a description of the
science that led to their discovery.

(29:30):
What not things where people would say, hey, like I need
information on certain types of therapeutic companies that would
be more appropriate for a pine cone or vector database because
it's not going to be as binary. Give me this one field.
Exactly. And maybe there are certain
operations that you do along with that that are just useful
to have inside Pine Cone as metadata.
So maybe the industry, you've already pulled this information

(29:51):
out from the company. So it just makes sense to be
able to segment your searches inside Pine Cone by industry.
So if you care about medical applications and then you're
searching inside the subsection of medical companies about the
specific innovation that they'reexposing, you can see how that
would work. But what's interesting about
this conversation is that it reveals A trend that has changed
over the past five or six years.And something that I've seen a

(30:14):
lot of because when I started developing as a data scientist,
like the initial answer would have been to build models to
kind of pull information out of these structured descriptions in
order to populate the structureddatabase and then do queries
over those, right? Like build a model that can
predict the industry of a company or try to extract like
the thing that they're building,all that sort of stuff.

(30:34):
Now we have these powerful ways of kind of abstracting that
search out so we don't have to do this upfront engineering
work, right? It's kind of amazing.
Like we can offload this type ofquerying to this agent or the
representation of the information to this embedding
model so that we can find this information faster.
That's the key value there. And in one thing that I've been
exploring with is just having a,let's just say my Obsidian

(30:57):
vault. So a clutch and markdown files
let Claude code loose on it. It'll figure out what it needs
and it'll bring back that information to a natural
language query similar to how a vector database would without
all the steps in the middle. What are the pros and cons to
that approach? Because like you mentioned, the
speed is very fast with vector database and having Claude go
through which things is very slow.
But what else should people consider of those two
approaches? Yeah.
So this is like a very, this is like very interesting argument,

(31:18):
right? And I think that this depends,
obviously there's a lot of like qualifiers on the exact type of
search that you're doing, what your tolerance is for the
relevance of the results, how long you're willing to wait.
And I think it's really temptingfor for people to draw the
conclusion that as long as I start a task and then have the
results of the task come back, that's OK.

(31:39):
That's like kind of good enough.And there are a lot of
situations where that's completely fine, right?
Like maybe Mike, you don't need like the most low latent search
for your upsetting docs because you're gonna ask a lot of
questions. You're gonna walk away, then
you'll come back and you'll kindof have the answer.
And that's like, OK, right? That's completely fine, but
maybe you're realizing that, hey, you know what Claude is
doing a lot of queries and a lotof text searches and a lot of

(32:04):
tokens are kind of being used up.
Maybe this is a problem. Maybe I need a way to kind of
quickly identify which documentsare relevant, and then once I do
that, cloud can do grep search inside there.
So it doesn't necessarily have to be mutually exclusive at all.
Of course, there are engineeringconcerns like spinning, like
making sure you upsert all of your data and keeping that In
Sync. But we find that semantic search

(32:25):
can be a lot more flexible than just doing keyword searches
repeatedly. And of course, you're going to
save a lot of tokens if you're getting the results back the
first few times. So yeah, that's kind of like
what I would say. It's completely fine to just use
what you think is helpful, but Ithink if you look closely,
especially at how Claude is doing searches, it is a brute
force method. It doesn't know about what data

(32:45):
you have, so it's just trying tofind things as you could, and
it's kind of fast at it, so it can do it quickly, but you have
to think about the consequences of doing so many searches.
You're going to fill up your context window really quickly,
and at some point you have to decide if that's worth it over a
really large database. Yeah, And similar type mentioned
earlier, if it's just grepping through a file for dog and
there's something about, you know, a leash, it's not

(33:08):
necessarily going to come up with it.
So I might miss it completely. Just on the note of concrete
examples, having worked at Pine Code where some cool unique use
cases you've seen where people might not traditionally think a
vector database is the right solution, but it turned out to
be great for them. Yeah.
So I think that a lot of people think about pine cone and vector
databases for retrieval augmented generation, which is

(33:30):
like, hey, you have a chat bot, you upload some documents and
then it searches over the stuff and you get answers back.
And I think that's like fine. But there are a lot of really
interesting, like industry specific applications that are
particularly powerful that rely more on this idea of being able
to do semantic search really quickly rather than like, you

(33:50):
know, being able to generate like the appropriate or correct
response. So one of and and outside of
that, I think one of the interesting applications of
semantic search is recommendation systems.
So what people might not realizeor think about is that
recommendation systems are a form of search where you have an
input query, which might be users preferences or their
previous shopping history or whatever might have you, and you

(34:14):
have a bunch of information that's been embedded that can
quickly be things that are relevant to them.
And the ability to kind of make that sort of operation possible
very quickly is super cool. And I think that building
recommendation systems on top ofPine Cone is like very, very
underrated. I have a fun example of spinning
up kind of a quick simple one that I can show you in a couple

(34:36):
of minutes. Another thing that I think is
really cool personally, that's kind of outside of a super funky
enterprise application is the ability to encode data that
normally you wouldn't think would be easy to encode or map
up. So I'm talking about like
multimodal search or multilingual or cross lingual
search. One of the first things I
learned at Pine Cone is that there is such a thing called

(34:56):
multilingual embedding models. And these are embedding models
that have somehow figured out how to represent like hundreds
of languages in the same embedding space.
So if you ask a question in English, you'll get the correct
responses back in other languages.
And there's not a clear reason as to how this translation is
actually occurring under the hood.
It's just the property of how the languages are being used,

(35:16):
like across the world. So you can do crazy things like
just do translation without having to actually translate
because you're using an embedding model that finds the
most relevant information to thegiven input query purely off the
property of the semantic similarity search.
And once I built that demo, I was like, oh, there's something
very interesting here. And that extends to any, any

(35:38):
modality. So you can do text to image,
image to text, video to video, audio to video.
If you can represent it in the same embedding space, then you
can search over it and it gets things get really crazy really
fast. Well, you, you mentioned demo
and we talked before that you have something set up with the
cloud code which is getting hotter than ever, especially
with Four 6 coming out today. So would you mind giving us a
little demo? Yeah, absolutely.

(35:58):
So a little a little preface. So at Pine Cone, we think really
hard about how people are using US and their agentic IDs like
Cursor, Cloud Code, Copilot, Anti Gravity, so on and so
forth. And so we've been developing a
lot of content at Pine Cone to help people be successful with
our products inside those environments.
One of the things we developed was a plug in for Cloud Code.

(36:20):
You can find this plug in on theCloud Code official marketplace.
Chances are if you have Cloud Code, it's already on the
marketplace, is already installed in your session.
All you have to do is hit slash plugin, install Pine Cone, and
you can start using our plugin. So I'll walk you through some
demos on Semantic Search and Assistant if we have time.
It'll be super fun. Let me go ahead and share my

(36:40):
screen and get started. So I'm inside VS Code right now
and I've fired up Claude here. I've already have our plugin
installed and I'll show you whatthat looks like.
And I've also have claimed an API key from my Pine Cone
account and I've exported it in my environment.
Before I go here, I'm not going to show you that for obvious
reasons, but be aware that you'll have to export your API

(37:01):
key. You can get one for free at Pine
cone dot IO. Cool.
So what I'm going to do is I'm going to find the help command
from Pine Cone. So I'm trying to type help here.
And you can see we have the slash command which explains how
to use Pine Cone inside Cloud Code.
So I'm going to go ahead and hitthat.
And what it's going to do is it's going to check that an API
key has been set and that we canlist our indexes.

(37:22):
So we can see that we've invokedthe help command.
We have some features we have access to.
We have a bunch of Pine Cone assisted commands.
I'll go into that in a few seconds.
We have access to our Pine Cone MCP server, which means we can
create indexes, do semantic search, list our indexes, all
that sort of fancy fun stuff, some slash commands which let us
explore our data, and we have some setup instructions.

(37:45):
So it looks like we were able tosuccessfully list our indexes.
Here. I'll use Control O to kind of
show you what that looks like. This is an output from our MCP
server, which shows us the indexes that we have access to.
So it looks like we're all set up and we can start exploring
our indices. So I have some fun indices that
I've set up for us to kind of look through.

(38:07):
I have a few here. I have one that's just like a
simple sentence search. I have one that indexes 50,000
Wikipedia pages of North American birds with two
different methods. So we can kind of understand
like how semantic search works in one domain and how sparse
search works in another domain. And I also have a recommendation

(38:27):
system example that kind of shows us how someone could do
recommendation systems with foodas as kind of the domain.
So what I will do is I will start with this first a simple
semantic search example so we can get our bearings and then we
can do the bird search one or the food one, depending on what
you're interested in, Mike. So we got we got to do bird is

(38:47):
search for a puffin. OK, cool.
Awesome. Hell yeah.
Mike Bird, of course. My gosh, how could?
I it all works out. Even not notice.
So let me go ahead and query thesemantic search index that I'm
describing. So this is an index of English
sentences that are using that are about going to the park and
parking your car. So a very simple example of

(39:09):
semantic search is just trying to disambiguate the fact that
park is being used in two different contexts.
So I'm going to go ahead and say, OK, I want to query my
semantic search index and I wantto say where do I have to park?
Right as I'm running the slash command, Claude is going to
figure out what index I'm kind of working with.

(39:32):
It's looking what parameters it needs to kind of pass in, and
it's gonna go ahead and do that search.
This is all MCP calls. They're being enabled by Claude.
And now we're getting some outputs back and we can see
what's kind of going on. So I said, where do I have to
park? And I got a bunch of queries
that are coming back that are about parking my car, right?
And this is interesting because we're not at any point doing a

(39:55):
mapping over the query that I'm looking at and the text that's
coming back. This is just the meaning of the
sentences. And I can demonstrate that by
asking a different kind of query.
So instead of where do I have topark, I can say something like I
want to play and I can see what sort of sentences kind of have
kind of come out of that. So I can say I want to play at

(40:15):
the park and the same type of operation will happen again.
It's going to search the same index because it's saw that I'm
kind of passing in the same query again.
And it'll generate a list of thethings that kind of come back.
So I went to the park to play tennis, I'm playing in the park,
so on so forth. And we didn't get any of the
other sentences that I showed you prior of like where can I
park, blah, blah, blah. So this is like a very like one

(40:36):
O one example. I like to show people to like
really nail this point. At no point are we actually like
looking at the words that we're using inside the documents or
the query. This is all embedding models,
like all the way down, which is crazy to think about.
So now that I've shown you that,Are you ready for like this bird
kind of search example? Yeah, absolutely awesome.

(40:58):
So I actually built an application that basically shows
users how to index information in different ways in order to
expose different properties of semantic search.
So we've been talking a lot about like representing concepts
and ideas, and a lot of that comes from using what's called a
dense embedding model. These are embedding models that

(41:19):
take in documents and produce embeddings based on the entirety
of the meeting in the document, and less so on the words that
are being used. Sparse embedding models place a
greater emphasis on the words that are being used rather than
the entirety of the meaning of the document, but they reweight
the influence of the words basedon the other things that are
kind of occurring inside that document.

(41:40):
So why does this matter, right? You can imagine situations where
you'd want to do a sort of keyword search, but you also
want to preserve some of the meaning of the query that you're
passing in in order to adjust, like what words kind of
happened. We were doing a little bit of
that prior where I was saying, hey, I want to go play at the
park. So we want to find sentences

(42:00):
that include the word park, which is relevant for us, but we
care about how the word park is being used in that context.
So we still need an embedding model to inform the
representation of that word and change it because of the context
being shown there. So I have an example of having
indexed the same data with thesetwo different methods, and I'll
show you the differences in the data based on those querying

(42:23):
methods. So what I'm gonna say is, hey,
Claude, can you list my indexes that are named Ferd?
And those are going to be my bird dense index, my bird sparse
index. So I'm going to go ahead and
have Claude list those indexes and show me which ones they are
before we can actually query them.

(42:44):
OK, great. So I have a sparse bird index
and a dense bird index, and I have a Bestbatch 25 one, which
is just regular keyword search. We won't talk about that one
here because we can't easily query that one with the way all
this is set up. So we're going to run our
experiments on the sparse bird search and the dense bird
search. So I have some prompts here.
This one is large predatory birdthat hunts small mammals at

(43:06):
night. OK, before I send this out, what
kinds of data do you think are going to return if we were to
ask this in like Wikipedia search for example, or in a very
keyword based way like what do you what do you think we're
going to see like in the return information?
Sorry, like an owl. Yeah, it could be like an owl.
It could be probably a paragraphabout an owl describing its

(43:29):
hunting tactics. Right, Right.
But what's interesting about this sentence is that we're
never describing the name of thebird, right?
We're describing the property and the idea of the bird.
So my hunch is that this will probably work better with a
dense search over a sparse search because we don't really
care about like, specific terminology or information.

(43:50):
There's this idea of this bird that we're trying to look for.
So I'm going to say, hey, Claude.
Hey, Claude, I'm going to, I'm going to use my query slash
commands. So I'm going to go down and hit
tab and I'm going to say, hey Claude, query this sentence in
both sparse and dense indexes and return the results.

(44:14):
And then I'll paste the sentenceand we'll just compare the
results together and see which one is better, one or the other.
So we can see it's making a bunch of MCP calls and then
it'll format both results for us.
It's searching both of these things and it's inputting that
query that we care about. And now it's it's honking.
That's so fun. Pretty odd point there.

(44:39):
And then we'll just see what kind of pops up here.
OK, awesome. So let's look at the search
results here. So for the 1st result we did
using pine Cone sparse, we got the Costa Rican pygmy Owl and
the details that we got is that it forges day and night and
hunts from a low perch. The diet includes birds, small
mammals, vertebrae, and arthropods.

(44:59):
And then with the dense results,we got something that
specifically preys on hummingbirds, which is
interesting because we didn't specify hummingbirds at all,
right? And it's also a bird of prey.
We got the Western screech owl, which is maybe kind of large,
and it kind of eats these other things like mice, rats, flying
squirrels, bats, so on, so forth.

(45:20):
We're not seeing the raw information.
I think Claude is helping us here by kind of cleaning up the
return results that are being generated.
But you can see that we're kind of extracting different ideas or
properties because of what's going on here.
And let me go ahead and just like show you the results.
So let's look at our sparse search here.

(45:44):
So we got the Costa Rican pygmy owl forges both day and night.
So we got knight in our query here, and we got Knight kind of
returned here. It hunts from a low perch and it
takes prey. It's dye has not been defined in
detail, but it's include birds, small mammals, and other
verbrae. So we have another hit here on
small mammals, which is why we got this result back.
Now let's look at our dense search.

(46:04):
Let's see the 1st result that's coming back.
It's diurnal, it's found primarily on humid forests, and
it's known to prey on hummingbirds.
So you can immediately see the difference in the quality of the
results, right? So here.
We got sorry even describes it as a small bird rather.
Than exactly exactly, which is probably just something that is
not as relevant, right? Like it probably got confused by

(46:27):
this idea of like praying on hummingbirds versus being small.
There's like too many attributesthat we're kind of searching
here, but it's still really interesting that we got a result
that's like, hey, this is eatinglike really small hopping
hummingbirds, right? There's like something like
valuable or interesting there. This second one is probably way
more relevant. So these nocturnal birds wait on

(46:47):
purchase to Snoop down. They catch insects in flight,
not mammals, but they do eat mice, rats, flank squirrels and
bats, other birds, and they're opportunistic predators.
So this result would probably bea lot more relevant than some of
the other things that we got with the other model.
OK. You did say you wanted to search
information about puffins. So I wonder if you wanted to
take a stab at forming a query and seeing which index gives you

(47:10):
better results here. Is there anything you want to
know about puffins? And then we could kind of like
go from there. Migratory Habits.
OK. So what are some migratory
habits of puffins, right? And are there puffins in North
America? I hope there are actually.
Different ones on the West and the east so.
Oh, really? Wow.
OK, we got, we got an expert. OK, awesome.

(47:32):
So I'm thinking that this would probably perform better in our
sparse search because we're really keying in on this
terminology of migratory habits.But we might get some sentences
that are relevant as well. So let let's go ahead and
inspect the results ourselves. So here's our sparse search.
First thing we got was the Ellen's Hummingbird.

(47:52):
All right, that's not that's notwhat we're looking for.
And it looks like we're getting migratory patterns back.
So this probably over indexed onthis idea of migratory patterns
and not on the actual bird that we're interested in.
However, the second block that we get back has something about
the Atlantic puffin, which is pretty awesome, but it's more

(48:14):
about the characteristics of that puffin rather than the
results that we were interested in.
Let's go back here. OK, great.
So those are our first two kind of like sparse results, right?
We got another puffin kind of section here, probably another
part of the same article, and then we got tufted puffins back
here. So it looks like we got

(48:35):
information about puffins, but not necessarily about the
migratory habits. So that could just be a data set
issue, like we might not have good information there.
In the dense search. We got information about puffins
right away, which is really cool.
It looks like we have the Atlantic puffin.
We got the doc horn puffin, which we didn't see in the
opposite results, we got the Atlantic puffin again, but the

(48:56):
sentence is more about like their habits that they kind of
do in danger. And then we got one sentence
about migratory patterns from a different bird, and then the
tufted puffins, which also are not really talking about their
migratory patterns. So we learned something
interesting here, right? Like maybe there's something
about the way we're chunking ourdata that's just not capturing
this migratory information at the same time as it's capturing

(49:19):
information about the animal that we're interested in.
But we were able to kind of see the different results that each
search method produced and maybemake actionable choices based on
that. So, OK, I know that we're not
supporting migratory queries that well, so maybe we'll have
to think about how we want to chunk around that specific idea
in general, especially if a lot of our bird search users are

(49:39):
trying to find that sort of information.
But yeah, that's, that's kind ofthe idea.
That's that's kind of how the plug in works.
I have. I have a few more things to show
you, but I know we're kind of running up on time, so I don't
want to take up too much of. It yeah, yeah, no happy to to
keep going with this. OK, cool.
Awesome. So that's kind of our search
demos there. There's another functionality of

(50:00):
Pine Cone of our Pine Cone plug in that people might be
interested in if they want to dothe whole retrieval augmented
generation pipeline without having to build it entirely
themselves. So we have a product called Pine
Cone Assistant, which sits on top of our Pine Cone database,
which is like our trusted knowledge kind of infrastructure
layer. And the idea is a lot of people
want to chunk their data, but they don't know how.

(50:23):
Or a lot of people have their data in PDFs or text files or
all that sort of stuff, and theyjust want to start asking
questions over that data. So we created a way for you to
instantly chat with your documents, upload them, and then
get generated answers off of them along with citations and
references back to the documentsthat you're kind of looking at.

(50:44):
So you don't have to build this whole pipeline yourself.
You can just say, hey, here's all my documents, go put them
inside Pine Cone and then let mequery over that data.
But we didn't stop there. We also handled the query
planning and orchestration for you.
So it's not just a simple semantic search over the
information that you care about.We do a lot of sub queries that
breakdown the question that you're asking.

(51:05):
We search all of those results, we re rank them, we represent
the results back to a language model like GPT or Claude, and
then we generate a response for you.
And then you can even see how the model generated the response
based on the data that it searched over.
Now there's a lot of ways to make a pine cone assistant.
You can make one inside of our console, but we were able to, I

(51:26):
was able to kind of create a no code experience inside the
plugin. So I can just tell Claude to
make my assistant for me upload these documents and start
chatting with it. So that's what we're going to
try to do here. So I have this folder here
called Assistant Documents and I've uploaded, I've put in a
bunch of PDFs in this folder. They're all about different

(51:48):
kinds of AI research. So 1 is about how people write
agent dot MD files. If you're familiar.
They kind of help control the generation of the code that
you're creating. 1 is a researchrecent research paper.
Oops, don't want to open that inside VS Code. 1 is a research,
a recent research paper that discusses skill formation over

(52:08):
people that are using code generating models that Anthropic
kind of produced. And then I have, and then I have
research papers and articles that we wrote, articles that we
wrote and research papers that we gathered relating to sparse
and dense search. So I can say that my goal is,
hey, I want to combine all of these sources and I want to
think about how I can write likean agents dot MD or a skill dot

(52:30):
MD file to teach developers how to do sparse or dense search.
Like, here's all this information, synthesize an
answer for me. So what I'm going to do is I'm
going to 1st ask Claude to create an assistant and I'm
going to ask it to upload all this data from this document
here. So I'm going to say, hey,
Claude, using the assistant skill, can you please create an

(52:53):
assistant with the I'm going to add my folder.
Oops. Typing, Typing is hard docs
folder, and we'll go ahead and see what happens.
So ideally, we've created a skill and a bunch of slash
commands kind of make it easy for Cloud to create assistance
to chat with them, upload documents.

(53:16):
And you can see that it found our Pine Cone skill.
And what this skill's gonna do is that it's gonna create,
manage, and interact with Pine Cone assistance, so on and so
forth. So I'm gonna go ahead and click
yes. It's gonna load information
about what it's able to do, and now it's going to create our
assistant and it'll probably askme for a name.
It created the name for me. That's fine.

(53:36):
We'll call it the tool Use Podcast Stocks Assistant.
All right, that's cool. And now it's going to go ahead
and upload the document. So what's happening under the
hood here is that inside of our plugin, we've packaged the skill
slash commands and a bunch of scripts that Claude can use in
order to say, upload these filesto our assistant or query them.

(53:57):
And this property is really nicebecause we don't want Claude to
generate the code to upsert the data every single time because
that's a lot of tokens that are being generated.
So instead, we're giving access to tools that all it has to do
is generate the call over so that you're preserving a lot of
tokens and the script can do a lot of the hard work.
This will probably take maybe like 3040 seconds because

(54:18):
there's a lot of different documents that are kind of
uploading while that's going. I can show you where they're
being uploaded inside the console if you'd like to see
Yeah, perfect. I'm inside the pine cone console
and I can hit tool use podcast docs and I'll look inside my
folder and you can see that we have all of our files kind of
uploaded inside of our assistanthere, which is really awesome.

(54:40):
So that's great. Our assistant was made.
Our documents are here. We can start querying over them
and see what's what. Awesome.
So we're here and now we can kind of ask this question that
we're thinking about. So I pre wrote the prompt
because I find that it's always helpful to have that information
kind of there so I can copy paste, especially when I'm doing

(55:04):
live demos. So basically what this is gonna
say is, hey, what can you tell me about skill formation with AI
and how does that impact agent dot MD file creation?
What I need to do is create an agent dot MD file and skill
files that help users make better semantic search
pipelines, especially ones that deal with sparse or multilingual
data, which are the two embedding models that we kind of

(55:26):
one or two of the three embedding models that we
support. So I'm going to say pine cone,
whoops. I'm going to say slash pine cone
assistant chat, and I'm going tosay this query and I'm going to
hit enter. And you can see that whenever
I'm using some of these slash commands, there's options to
kind of fill in the arguments. But I'm just going ahead and

(55:48):
putting in my query and I'm letting Claude kind of figure
out what information you should put in each field based on the
context of the chat. And that's a really powerful way
of using Claude code because it has context to your previous
conversation and your workspace and the data that we've kind of
included with the pine cone plugin, we can kind of let it figure
out all that sort of stuff. So we can see that I think we're

(56:10):
getting a response back here. Oh yeah, this is super cool.
So we're seeing this backward because I have to kind of scroll
up, but I'll show you what the response is so we can see the
assistant response. Skill formation with AI and its
implications can be instituted through three aspects, the AI
and skill development role structure, context files.
I'm gonna see if. Yeah, right.

(56:32):
So we have some information hereto complement the agent's
identity file, create skill files that guide users in
billing, semantic search pipelines, which can include
tutorials on blah, blah, blah, blah, blah.
And we get page level citations for this type of information as
well. So if we were inside the
console, we could actually clickon these pages and we would be
able to see inside the console like where this information is

(56:55):
getting pulled from. And so that's super cool.
We were just able to do rag withour documents just like
out-of-the-box using cloud code without having to write any code
ourselves, like purely on the information that's kind of
there. But that's the kind of benefit
of making using the pine cone plug in there.
That's the extra thing I wanted to show you.
Yeah, very cool. It's making it so much more

(57:17):
accessible and removing a lot ofthe questions I know I had that
might have been intimidating me from getting into using vector
databases. If I can just have a quick chat
with Claude, fire it up, get some documents up there,
seamless. Exactly.
And very often people could takethis directly into production
because you could interact with Pine Cone assistance via an API.
So if you want to create your own web interface, you can just

(57:38):
have it pipe into our Pine Cone assistant.
Or maybe you're like, hey, I want apoc really quick.
Like I just want to know what itwould be like to like implement
an agentic search or like reallysimple rag over my documents,
throw it into assistant, see that it works really well, and
then learn how to build it yourself using our plugin and
the pine cone vector database. So it's nice, it has a nice
optionality and it's also super fun for these kinds of demos.

(58:00):
Like we can learn a lot about our data really quickly this
way. Absolutely.
This was awesome. Arjud.
Really appreciate coming on to teach us about vector databases
and Pine cone. Before I let you go, is there
anything you'd like the audienceto?
Know hey, you can always find meon LinkedIn or you can find me
inside the pine cone discord. Just search my name, Arjun
Patel, a pine cone. You'll probably find me.
Feel free to shoot me a message or interact with me there or

(58:22):
inside the disk inside our Pine cone Discord.
It was awesome hanging out with you, Mike.
This was so much fun. Thank you for listening to my
conversation with Arjun Patel. I really wanted to make sure
that both you and I understood the need for vector databases in
this point in time. They were all the rage before
and kind of fell out of fashion,but there's still a lot of
viable use cases for it. So I do hope you experiment with

(58:43):
it, play around, try different chunking strategies, see how it
works for you. Because there might be a
recommendation system that you didn't know you could build,
which is enabled by this technology.
Or maybe just your little chat bot can get better performance
if you get a little more meticulous in the way you
structure it. I hope you enjoy this
conversation and I'll see you next week.