If you're interested in graph databases and curious about
knowledge graphs and how you can use both within generative AI,
this episode is for you. Joining me today, I have two
guests, Bosco Brookmeyer, head of engineering over at Every
Cure and Neil Seyoung, product manager over at Neo 4 J.
We go through the basics. What are graph databases?
What are knowledge graphs, and what problems do they solve?
You might actually have more graph problems than you think,
so enjoy. Do you have any experience with
regards to like rack solutions or implementing stuff in
production with regards to Chen AI?
Oh, it's difficult. I mean, that's the reality of it
getting to production is is I think currently the biggest
challenge with Chen AI. Yeah, yeah, I think it's quite
easy to set something up. But once you start work,
especially like when you're I'm I'm living in a graph world,
right. When you're converting documents
to a graph, that's something that's quite easy to to do a
first demo, but you're going to have to start thinking about
chunking. You have to kind of model, you
have to do so many things to get to something that's production
worthy, and scaling to 10s of millions of documents is where
the challenge is. What do you mean when you say
OK, we're going from a document to a graph?
Like visually, I don't know what that means.
Yeah. So I mean, you can probably
speak about this as well, but when you're in my world, when
you're building a knowledge graph from unstructured data,
you're taking a document, you're converting that into a knowledge
graph, which means that you have to define a model.
You take the model which has your entities in it.
For example, you work in a bank. Your entities would be the bank
itself, a client, an account. These will be your notes in the
graph. And then you use your large
language model to extract these entities and convert that into a
knowledge graph. So you can use a large language
model to extract that. So this is something that is
kind of crucial when you want to do graph Rag, which I'm sure
we'll discuss later, to build the right knowledge graph.
And that's where most people kind of struggle.
Maybe you can say something about that, because I know
you've had a lot of very ambitious ideas to construct
knowledge graphs from from data. Yeah.
So I mean, my, my team right now, we mostly grab existing
knowledge graphs and they're based on certain ontologies and
we merge all of them together to try and create one very large
set. Because then you can still
introduce filtering steps between your modeling and the
graph itself where you can say, OK, I'm going to slice away
stuff. I'm going to take away certain
categories, I'm going to take away certain kinds of nodes.
But you can't add afterwards, right?
So we first throw everything together and make sure that it's
all harmonized within the ontology.
And then we do data experiments. So we say, OK, what if we remove
all of the proteins from the knowledge graph?
Does that up? Or like, does that lift up our
performance? Actually the experiment, I told
you on Friday that it was running where you perturbate the
edges. So I love how we just go
straight to the graph. So the question was what happens
if you mess with the knowledge graph?
Does it actually impact your model performance because the
the hypothesis you want to refute or you really want to
avoid that? You can mess the knowledge graph
up completely, but the model still performs the same way.
If you have that, then it means you actually didn't.
You're not deriving information from the knowledge graph.
Your model isn't performing good because of the structure.
Your model is performing good because it's memorizing answers
or because it's just in our case may be latching onto it, saying
that certain drugs, which we call frequent Flyers, just
always help. So if you inject someone with
adrenaline, that usually resolves most symptoms because
adrenaline just has that impact on the human.
Body shocks your system. But that's not necessarily
something that helps people in term.
And so that could be memorized by the model, but So what?
What we then found out in the experiment is if you mess up the
knowledge graph 99%. So I took the target nodes.
So you always have two nodes that are being connected with an
edge and they're directional in our case.
So I took them edges that point at that object and I changed
them to another object of the same class.
So I would say drug treats disease, but it would be a
different disease and that wouldn't actually be true,
right? It's false information most of
the time. But I wouldn't say drug treats,
I don't know. We have food types.
We also have like a food type category.
So you wouldn't say drug treats hamburger because of course
that's silly. And so we perturbate all of the
edges within each category, one percent, 2050 and 99.
And what is interesting to see is the model performance doesn't
drop to 0 when you perturbate 99%, it actually drops about
half. So half of our models
performance is from, at least that's my hypothesis.
It's from the data. So it's actually picking up from
signal from the graph. But the other half is also not
from the data. So yeah, that was just an
experiment. Yeah, yeah.
So you cut down your knowledge graph and you have a model that
uses this as a base for reasoning.
Do I understand that correctly? It's actually we open sourced
the whole thing last week. So that's, it's all in the in
the giant mono repo, but we take the knowledge graph, we then
create vector embeddings for each node.
And there's a variety of ways you can do embeddings.
At the moment we do node to vet because it's the highest
performing one. But you really want to encode
the neighborhood and kind of the topology around a node in the
number that describes this. And then you give those numbers
to a model because models, of course, they always need a, a
numerical representation. And then you try to predict what
is the probability that a certain drug treats a certain
disease. So I think it's the class of
edge prediction essentially. Yeah.
You mentioned ontologies as well.
Can you lay out what what do ontologies mean?
Do you want to do that? Because I'm not a big Ontology
fan. Yeah, I mean, they're this, this
is a very scary topic because people have different
definitions for an ontology. But in my world, an ontology is
just a model definition, OK? It's just a specification, as he
was saying. And this drug treats this
disease, and this disease is related to that disease.
So in the world of property crafts, we call it a model.
In the RDF world, they like to use the word ontology.
I kind of switched them up interchangeably.
Yeah, what's RDF? RDF is a oh, that I will
redirect that to you. That's a.
So they're they're basically two big philosophy in the craft
world on on storing craft data. Yeah, one camp says property
graphs are the way to go and the other side says RDF is is much
better way to go. OK, so it's a way of storing
your graph data. Yes, it is.
Yeah. Gotcha.
Yeah. What does it stand for then?
Resource description framework OK.
Yeah, just a different way of storing it.
Yeah, yeah, it's, it's all graphs, right?
It's just a different way of storing the data.
It's a different way of querying the data.
Yeah, yeah. And graph Graph thinking is not
something I'm used to. I was thinking before the show.
Have I seen any, any graphs in real life like you mentioned the
entities and there I can draw a relation to kind of DDD when it
comes to defining your domains within a certain field.
So that was kind of similar. I've recently been really
structuring my notes and I'm trying to be a settle custom
practitioner. And there one of my colleagues
said, OK, don't even think about the folder structure.
Just make sure that you have references from one document to
another when they just make sense.
And then I have a graph visualization.
That's the only thing I can think of where I think, OK, this
might be. I don't know if I would call it
a knowledge graph or if that's comparable.
Would you say that is? Yeah.
Yeah, what you're describing, I have a colleague, he calls it
the graph problem problem. OK, which means you don't know
that you have a graph problem. That's your.
Problem OK. And I love that.
And I think it's very fun because once you start thinking
about graphs, you start seeing everything as a graph.
OK? Like going to Amazon, buying a
laptop, It says other users who bought this laptop also
purchased a mouse. Yeah, that's also a graph.
OK, You're a node as a person. You bought a product that's a
node, and then there's another person that bought that same
product. So you're building this little
graph of connected entities and you're doing a recommendation.
These two nodes should be connected, you and this other
person, because you purchased the same product.
And then from that other person, again, next step in the graph,
what other products did they buy?
A mouse? So then you're thinking in terms
of connected entities. Do they use a graph under the
hood then also to recommend those things or?
I'm pretty sure. I'm not 100% sure, yeah, but it
feels like a very natural. Graph problem.
Interesting. Yeah, yeah, yeah.
So that apparently is a graph problem.
Yes. I never like, I never think
about that, what happens under the hood.
But it's very interesting that you go from one thing to an
action to then a person to their actions.
And you can kind of follow steps in that way.
Yeah, you can traverse those paths and you can use that with
regards to Gen. AI for reasoning then.
Yes, yeah. So my philosophy with Gen.
AI and Speaking of graph, right, context is, is king.
The more context, the more relevant context you pass
through a large language model, the better it performs.
And graphs are just extremely good at context because you've
got a network of connected things.
It's a document living attached to entities that are connected
to other entities. And you can go very, very deep
in that graph. So you have a very rich context
of a ontology or a model that you've defined.
And that is just why I think graphs and graph rag is is very
cool for for this kind of thing. Interesting.
I really wonder how it compares to like Rag.
In essence, how I've seen it is we use text and text is
interpretable for humans and then we make embeddings from
that and then we do reasoning for that.
It's a different way of kind of filtering this context.
But the way you explain a graph, if I have an action and then I
purchase a product and we have other people that also purchase
that product, but also they bought different products, it
very much narrows the context. It makes it hyper specific.
And that might be a good thing. I don't know though.
It's it's, yeah, it's relevant, right?
You're defining. These are the relevant things.
Yeah, have any of you experimented with kind of
embeddings? You mentioned node 2 VAC is the
highest performing one. Well, it's just in our specific
situation, right? So we used graph stage before,
OK, which was a combination of we first took the nodes name and
description and category. So it's like a certain drug, the
name, maybe a certain description from drug DB or
something. And you take all of this and you
throw it at an embedding model, the classic, well, not the the
opening icon, right, the the text embeddings.
And then you have a text embedding which describes the
node in isolation without its neighborhood.
And then graph Sage. I'm not going to be able to
perfectly recall it, but I believe it does a bunch of
random walks and then pertubes the the base embedding to also
encode the neighborhood. And so then this number contains
both the information of the node in isolation.
And the interesting theory is because you're throwing in,
you're throwing in a couple of things now, right?
You're having language models that read the entire Internet.
So they have very generalized knowledge about the world.
And you take that as a baseline. And then you kind of manipulate
that that vector and make it point at something slightly
different given the environment. And so then the resulting number
is a mix of both the structure of your graph and it encodes the
knowledge in general of the language model that the
embedding model was based on. That is nice because it's, it in
theory should contain information both from your
knowledge graph, which is very codified as well as just general
knowledge. But it's also problematic
because it might leak information because how do we
know that we're, we're, we're having a withholding set of, you
know, you do a training and then you withhold the data and you
try to predict whether your model is able to predict a
certain edge. And how do you know the language
model that you use for the embedding doesn't have that
information stored in its weights?
And that kind of leaks through the language model.
So that's why no to vec is probably more pure because you
use a system that you have entire control of.
You start at a vector that is completely randomized and then
you purely from no to vec you get purely on the topology of
the graph, you get a vector. So the problem now is you're
throwing away this magic power from machine that we have
invented the last couple of years transformer models because
we're just using Node 2 AC. Yeah.
I mean, for me like bringing Gen.
AI applications to production things that provide value,
that's already very challenging. And I feel like what we're
discussing now with regards to the knowledge graphs, it feels
like it's 2 steps above that even.
When would I use that from a from a use case perspective?
I know you have a good one, but was it like the first thing you
gravitated towards or did you evolve into kind of this way of
thinking? Did it just make sense for the
use case? So in my case, my founders
essentially decided that there's unique moment in time where we
have now machine learning models at our disposal that can connect
all the different information and they wanted to figure out,
OK, all the drugs, all the diseases, can we just search for
any repurposing opportunity? That is why we use knowledge
graphs for this I think was just because at the time that seemed
like the highest probability to be able to actually do a
prediction all versus all. But we're now mixing in a number
of other because other methods because we realized actually
it's it's just a ranking problem trying to rank everything.
You can rank things in many different ways, but I think when
when you both were talking about like it's so hard to get things
into production, I'm actually very happy that not everything
makes it to production because I have real beef with the
complexity of large corporations.
I sat in a boardroom couple years ago and someone like
mentioned kind of an off way rise, a major insurance company
with 23,000 IT systems and everyone seemed to be completely
fine with it. That's ridiculous.
I mean, how much can you, how many IT systems do you need to
manage? I don't know.
Even if you have 100 different forms of insurance, one Postgres
database probably could handle all of your customers, all of
the insurance contracts that you have, all of your employees.
Why do you need 20 + 1000 IT systems?
And I think the answer is they don't.
But now they have them and it's so hard to get rid of them.
So what I'm really waiting for is getting to the point where
maybe graphs of the answer there, I don't know, where
models were able to just stare at the system as a whole and go.
All of these things we can consolidate so that people have
much less chaos to focus, to worry about, and then try to
instead do this one thing that is actually valued to the
business. Yeah, I think we're we're seeing
early steps in that like we have some some customers, you know
for J where they're trying to consolidate all these different
data sources into a massive enterprise knowledge graph or
digital twin or whatever you want to call it, which is
currently it's somehow automated.
It's a little bit manual, but 23,000 systems that's obviously
far in the future. But I, I do think that's a big
area and I think we're going to see that because the, the
downside is there was 23,000 systems.
There will be a lot of people's jobs depending on it.
So they're not going to be very eager to participate and get
their stuff out. There I follow the training.
It was about like architecture and architecture patterns from
from Gregor Hope. And he said for every
dysfunctional organizational behaviour, there's a vendor and
they'll be happy to take your money to kind of fix that.
But the behaviour is still dysfunctional.
So all of a sudden if you have a process problem and you think,
OK, I'm going to have a SAS solution that's going to solve
that and it might not solve it or it just might alleviate it,
it's still contributing to this cost of ownership.
I feel like it's very challenging to keep things
simple. It's very easy to just buy,
acquire, to add things and then increase your complexity.
But yeah, it has long term consequences.
And I'm, I'm very not happy operating in a complex
landscape. Like I like to be productive.
I like to be effective. I think things should just make
sense. And when there's a lot of
dysfunctional behaviour and we have a lot of applications or
like tools for that to try and solve that, I'm just like, what
are we doing here? But still it grows like that.
It reminds me of that that thing, the programming thing,
where it's super easy to have 200 lines of code, but to remove
5 lines of code. No one wants to do.
That that feels like the the coding equivalent of what you're
just saying. Yeah, yeah, yeah, you get that.
Yeah. I still don't know if I'm then
in an organization and I have an actual use case where to go with
that. What do I do with my data?
Do I actually need a craft database or knowledge?
Like you already said, I live in this graph world and I can see
graph problems. What problems do you have, other
than the Amazon example for example, that you've solved?
I think there's a lot out there and I'm being surprised still to
this day. Unfortunately, I can't tell you
about all that. Of course.
I mean, there's a very obvious ones like real planning, right?
You're taking a route from a station to another station, the
extras algorithm, finding insurance path,
telecommunications industry, building a network of cables to
provide everyone fast Internet. That's a graph controlling the
load, understanding. If one link in my network goes
out, you know what, what will be impacted?
Where do I have to reroute? You can translate.
You can take that idea and copy that over to logistics problems
as well, right? There's a boat stuck in the Suez
Canal. How do I, how do I get around
and, and get my stuff out there? But I think that the really
interesting ones are the ones that are not so obviously craft
related. I think what I was just saying,
the Amazon example is one of them, right?
You have people, you have products.
You can think of any organization really.
You have teams with people in them.
The people have are working on a on a tool.
They have certain set of skills or expertises.
You can imagine a skill is a node in the graph, team is a
node in the graphs. Your team needs a Cotland
expert. We just discussed it.
You can look at your enterprise graph and see, OK, there's
someone working on the other side of the org that's a Cotland
expert. Maybe I can bring that person
in, identify skill gaps in teams, and then you're starting
to think, OK, yeah, everything in my organization is a graph.
I can combine that in different ways.
I can and keep expanding that as well.
Right. Interesting.
Yeah, Yeah, I mean, the reasoning part that for me is
most interesting, right? Because if I have something like
that that depicts kind of in a graph way what my organization
structure looks like, and indeed, if I have a question or
a query and who do I need or do I know a person that is related
to any people in my network, that might be really helpful.
Especially nowadays where getting a job to stay, it's more
and more difficult, like relationships are I think
something you build. Upon I think in consulting,
almost any consulting company should have at least a program
in place. Whether they try to solve that
with graphs is one question, but how can we bring our best
possible person to this specific line?
And I think, I mean, I've worked in three consultancies now.
It's always very organic and human organized.
You've got staffers and staffers have their network and then they
try and think maybe they call some some partners up or some
colleagues in different offices. And sure, you've got some
keyword based search systems where maybe you can you're
looking for, like you said, a Kotlin expert, right?
So then you search for Kotlin experts in in a consultancy in
your internal directory. What if the person didn't label
themselves with Kotlin because no one likes constantly updating
their labels for themselves. It's kind of.
And the ones that are really good definitely don't need to
because they're constantly getting one project after
another. So having some form of a
representation of what's everyone's expertise and what is
the most knowledgeable person. That could answer this question.
And then probably that person's going to be completely swamped
because if you're the most knowledgeable person about a
popular topic, everyone's going to come to you.
What are the people around that person that still have capacity
and they're probably good enough for the job to do some form of a
load balancing across talents and also kind of nurture that.
That all happens in organizations quite organically,
but it's certainly not optimized to the sense of what is a near
optimal way of leveraging our resources.
Yeah, yeah. I like that use case a lot.
For me, like the tagging principle that you mentioned, it
really hits on because we have exactly that.
We have a, a specific board on Monday and you're supposed to
tag like what technologies you're good at, what are you
comfortable with? It's going to help sales and
it's going to help your future assignment.
So if you want a great assignment, then you kind of
work to update that part of the tagging.
But wouldn't it be nice if do you guys use Slack?
Yeah, is something just constantly watches all the Slack
channels and sees you talk about certain topics and others
appreciating. And you can read from the way
that how many people respond, how many people react to it, And
then pulling that all into a graph.
I guess you could do a lexical graph where you see every post
as a node, you're attached to the node as an author, so that's
your relationship. And then how many people refer
to that. You can now pull out of the
graph structure the facts of you're going to be a central
node for a specific topic and so you could find the experts
through that and you don't have to manually label.
Yeah. I like what you said about this,
you you'd never want to get the ultimate expert because they're
going to be busy. But having a kind of community
again, I'm thinking in graph algorithms, bring a community
detection algorithm to find, you know, Pascal's the expert on X,
but these are the people that work with him.
So by definition, they might also be the expert on Kotlin or
whatever. I think that's very interesting.
And then then you start using data that's not super apparent.
So these tags, but you're starting to look at graph
patterns as part of your feature set.
Yeah. Now you get that.
I mean, for me, like information right now in the landscape that
I'm in is distributed because we don't just use Slack, we have
Slack. Some organizations or some parts
of the organizations use Teams. We have emails.
So I'll read there. The information is scattered,
but if you have indeed an automated way of already
plugging into Slack, that's incredibly valuable.
I know what's stopping you from also plugging in the other data
sources I feel like. So this was an interesting 1
during the classical RAG days where everyone wanted to stuff
things into a vector database. My hypothesis to this day still
is because most engineers who were put like made in charge of
a certain project and were vector database.
I didn't even know these things exist.
I want to build 1. I want to deploy one.
But so everything was trying to suck information into the vector
representation and then copy stuff.
And of course, then you've got the outdated problem, you've got
the access problem. Because if I take your direct
messages between the two of you and I chunk them, embed them,
put them in the knowledge graph, how do I now make sure that that
result isn't served to someone else, right?
So I need to attach metadata who can read it.
It's a huge pain, I guess. Now I think the term that's
emerging is a gentic rags. So you have an agent search
through search AP is so it calls, it calls the Slack search
API, it calls the team API, it calls SharePoint and Google
Drive and whatever. And then those systems return
them the most likely results. And then the agent kind of,
which is the same as what a normal human would do, right?
You kind of search for all the different systems.
But I was I was listening to a presentation from I think, I
don't know if it was the founder of Exa, but there's a company
called Exa and they're calling their way of searching now
neural search, where they argue that can you reinvent search in
the age of neural networks where yes, they do embed everything.
They do that for web-based search.
But their argument is that they that way actually out compete
companies like Google, which do keyword based search.
And so I think it's a really interesting feel to see what is
going to ultimately when is it going to be a hybrid?
Probably because everything's usually been mixed things.
Is it keyword search? Is it semantic vector embedding
based search? Is it an agent or some kind of
system that just calls a bunch of AP is and looks through the
different systems? Or can you really in the
Valhalla I guess is having this like 1 unified knowledge
structure of your company? And I know a graph companies say
like this is what you, but I don't know if we can ever reach
that because it requires you to only pull in all of the
different IT systems and connect them all to your graph system.
Have 20 in the insurance case, 23,000 ETL pipelines that all
translate things into one unified ontology.
Sounds like sounds like a project that's never going to go
live. Yeah, that would be painful.
Yeah. But again, like what what we
just said like not to get into production.
If I look and I think one thing that makes these projects fail,
it's the the ontology or the model, right.
So imagine you do have the ETL pipeline to suck in these 23,000
systems. If your model is not right, if
you're not modeling the right entities, you're not modeling it
in the right way, you're not gonna succeed.
But if you have the right model, I think then you can do well.
And you can do this step by step, right?
You can start with 100 systems and 100 more, but the model is
really where you fail or. Succeed.
What ensures you have the right model?
Is it starting small and expanding?
Or how do you kind of test your assumptions and validate?
Yeah, I think so. The first thing when you're
making a graph model you're coming from relational is you
throw away your relational model.
That's step one. That's step.
One step one, throw it away. I have nothing now.
And then you. So The thing is, the way graphs
work, they don't do joints like there are no real time, there
are no joints done at query time.
We store the relationships at right time, So you have pointers
between elements. So what you typically do is you
take a whiteboard, you start drawing, you say, this is my,
this is my employee, this is a skill, this is a team.
You draw that on a board. And almost always you can very
easily take that whiteboard model and convert it to a graph
model. So it's very much closer to
conceptual model. You don't need join tables and
all these awkward structures. Interesting.
So that's kind of a step one. And then I really like what you
were, what you were doing in your experiment.
Just getting back to that, like iterating on the model, seeing
what edges we can drop, what edges we can keep.
I think that's that's really interesting, especially in in
the age of LLM built ontologies and and you know.
I feel like right now, and it's more so now than ever, there's a
lot of information that's like new and that's fresh.
And we were talking about graph databases and knowledge graphs
in the 1st place. For me, these are all like I
knew they existed. I've never experimented with
them because I also see there's two types of engineers.
One of the engineers that you said was vector database is
really cool is now up and coming.
Let me see if I can put that in production.
Regardless of the use case. Maybe they just want to play
around with technologies. I know I'm not that type of
engineer. I'm the engineer that's like, I
want to keep things simple and I want to keep things maintainable
and rather find like a good solution fit.
And even if I have many options, I'll pick one, I'll pick, I'll
try and pick as fast as possible and then validate my
assumptions. And if it doesn't work, I'll
pivot. And I know for like really good
solutions, you probably need both aspects because otherwise
one person that's going to look at established solutions will
always lag behind when it comes to trailblazing and kind of
newer technologies. And the people that experiment,
they will get a better feel for what works where and form an
opinion on that. And then they can actually apply
that to production. So you need this balance of like
I think newer tech and experimenting versus actually
looking at things and keeping things maintainable simple.
It's very often have these, maybe not student labs, but a
lot of young, young, career driven individuals joining these
labs of larger companies, which is a bit of a ring fenced area
where you can experiment a lot. You can try stuff, you can throw
things away because they can let their creativity go wild in
there. While I guess the more seasoned
people that have burned themselves a couple times have
gone through the pain of now I have to deal with all this
legacy and all this complexity. They're the ones who then act as
the stage gate to say, do we take this forward, yes or no.
Ideally they're not the grumpy kind that just doesn't want
anything. They don't want to be the You
don't want the person who just wants to sit through this for
another 10 years until they hit retirement.
But you want someone who has who's interested in new things,
but burn themselves enough times that they don't want to deploy
the 74th Postgres database that does just stores 3 tables.
But then rather, let's consolidate and clean up.
Yeah, yeah, yeah. I'm interested then from your
perspective, Neil's looking at a product and you have kind of a
complex product graph database. It has interesting users because
those are then going to be developers.
Do you work on ease of use? Do you work on education?
Or how do you actually kind of inform users and make sure they
know this is the best solution for what problem they have?
Yeah, that's a good question. I don't know if graphs are
necessarily complex, but it's a different way of thinking.
Yeah, I think that's the biggest thing.
The modeling is different, the querying is different, the
visualization is different. So there's just a a big step
that you need to take. So we do a lot of education.
One thing that is actually really cool is that and for J,
we had a query language cipher for a very long time because we
open sourced that. It wasn't de facto graph
language. And now there is now a standard
language GQL like Sequel SQL that's for graphs.
Which is super cool because this is the first standard query
language in 40 years. Again, I'm geeking out this.
I know, I know, this really maybe sounds boring, but there
has never been a standardized query language for no SQL
databases. They just couldn't get to the
consensus. But the fact that there's not
one for graphs is awesome because you can then pivot
between different graph databases.
It's standard and it's just, I don't know, that's just feels
really cool to me. And we actually the people that
were involved in creating the GQL standard where some of the
people working on my original SQL standard 40 years ago.
So it's amazing that these people just came back.
Some came back from, I don't know what they were doing,
retired or retired, but it's just amazing and I think it's.
Really nice to have them on. Yeah, I think that in terms of
education, you know, first of all, if you have a standard
language, people will Start learning that and then this
other thinking, modelling, visualization, that comes later.
But having a good language is is is really important.
Yeah, Yeah. So that is, but that's not
really what you focus on for product sense, right?
Is that more the education side that you focus on?
Yeah. So I'm, so my, my job right now
is I'm working on visualization tools, right?
So I'm, I'm working on dashboarding tool for graphs.
So you can imagine your standard BI tool works really well with
tables. Yeah, graphs, not so much.
So we're making a tool that has a graph visualization component
in it, ease of use using then cipher or G call.
And from that perspective, what I'm focusing on is user
experience. So my, my thinking is graphs are
for many people difficult, new, I don't know, difficult is the
right word, but it's new is different.
So I feel like we should have a higher standard of user
experience compared to established tools because
there's already the cognitive jump to move to graphs.
If there's a cognitive jump to move to a different user
interface as well or, or the experience.
Yeah, I think that's difficult for people.
So I, I really care about user experience and I've had hour
long discussions with my team about very minor things like
button placement. But I but I love that.
I think it's, it's really nice to have amazing user experience.
Yeah, yeah. I've said this many times on the
podcast, like if I have to go through a hurdle to try
something out, I'm gone. I'm just, I'll search something
else. Yeah, if there's a paywall, I'm
out. But that's me.
I think people are impatient. I think it's also with the age
of LLMS getting even worse. Like people don't have patience
anymore. And if you build for the most
impatient person, then the more patient people will just also be
happy because for them it feels like a breeze.
You know they won't struggle. The struggles that they would
normally have patience with, They're not there.
So it feels amazing to them. And the inpatient ones will
still be grumpy, but at least they'll they'll stick.
They won't give up. Yeah.
Have you seen more adoption with
regards to Gen. AI, because we mentioned RAG, we
mentioned graph RAG is this way of kind of distilling your
context, giving it in a different way to reason about
and it might even outperform some other embeddings or might
have higher accuracy. Have you seen like improved
usage? I've got it in graph databases
in general because of that. Oh yeah, 100%, yeah, yeah.
Everyone is moving towards graph Rag, especially right now.
It's we've had a lot of people come to us and say, hey guys, we
tried Rag, but it's just not working out.
OK. That's the pattern that we see,
OK. And then they say.
To cater to that then, because they're already frustrated,
right? So you now have to be the
saviour for them. That's a tough spot to be in.
We tried vector databases, it didn't cut it for us.
Now this next, like we've got one more shot at getting this
right before we're going to get our funding cut.
Now fix it. Yeah, No, your database now has
to be the same here. It's a tough one.
Yeah. I mean, on the upside though,
people realize that simple rack doesn't cut it.
So they say, OK, we're OK with investing this time into making
a model and getting things set up right to get that boost in
accuracy, that graph rack. Yeah, first.
But things are moving so fast. Like I have had people on half a
year ago, a few months ago, maybe a year ago.
They were like vector DBS of the thing and now you're already
saying it's not cutting it and we need to go to this graph
database to like fix. It, I don't know, I think vector
DBS have have a good place, but I think if you really care about
accuracy, traceability is something that comes up all the
time. People say, I want to know that
where this answer comes from, how was it derived?
And again, back to the graph, what are the entities in my
graph that were used to compose this answer from this large
language model? So that's another thing.
And and for big companies, the difference between 80% accurate
and 90% accurate or 90% to 95, that's, that's huge.
That's huge. Yeah.
Gotcha. What I find a bit curious is
that all these companies are trying to build this themselves.
There's RAG came about and then every company decided to build
their own knowledge assistant. And I get the desire.
Having a Volkswagen GPT or a Continental GPT or, you know,
HSPCGPT, well, it's too many acronyms, but that's very
powerful. You want that.
But then at the same time, Google dominates search because
all of this is a search problem. Microsoft tried to come in and
it took them ages to get a decent search engine going.
It's very, very hard to build a good search engine.
So it's curious that now every company under the sun has a team
somewhere that is supposed to build their internal knowledge
agent. And as one problem out of many,
I mean, they have to get user usability, right?
Access management, right? What is the information that you
can actually have access to all the Etls?
And then they also just have to like on the side, solve the
retrieval problem, which is a search problem.
It just seems like I would, I would rather say, OK, can we sit
this one out and wait for a year instead, get all the stars
align. So what, what will we need to
do? We will need to make sure that
our data is accessible, well structured, that we have some
form of a grip of what are the main queries that we need
answering. And then if and when a start up
from Y Combinator or maybe one of the big tech companies bring
something that solves this problem.
So you can really feel like you can find the information in your
entire internal knowledge world the same way as you can just ask
strategy BT for something. When that technology comes about
that has get that gets everything right, the right mix
of graph database, vector database, keyword search, index,
look UPS, ranking, re ranking, synthesizing.
Then you plug that one in. Yeah, I still, I would have
probably, I gave this advice two years ago and I would still give
it to companies like sit this one out, wait until someone
solves and productizes it, and focus on the things you need to
actually get right data use cases.
What are the main queries and what are the.
Yeah. Where are the biggest levers of
optimization for you as a company?
Yeah. I mean, I feel like there's
never been as much FOMO as there is right now.
Yeah, right. And I think I can kind of think
of how to explain it. Proof of concepts are quite
easy, right? Models are decently accessible.
They're getting more and more accessible, giving access to
proof of concept data set to prove value of a certain
business case without even looking at cost factors.
Because especially in larger organizations, cost doesn't come
to play in proof of concepts yet.
Especially if you look at like say your IT landscape versus
using everything that's out there.
If you can do everything that's out there in a proof of concept,
you can get something decently up and running.
And then that's the next step is like, OK, user adoption is like
a huge thing. If people have this ingrained
way of working and they do that over and over again, it's like
their pride. That's what they're there for,
That's their job. And you come in with a tool and
that's like 75% accurate. Now let's see if you're more
productive. People will be like, what is
this shit? And even though it might be
accurate, let's say from a theoretical sense, if the
linguistics are not the same, if the tone of voice is not the
same, people that be like, it doesn't work for me.
They'll throw it in the trash faster than anything else
because they also see that it's just another tool.
And then instead of going from 14 screens, they now have a 15th
screen that they sometimes have to do something with and it's
just another tool in their tool belt.
I feel like that is the most underestimated part is the
adoption sense. There might definitely be really
good use cases in organizations. And I do agree that taking
something off the shelf versus like really looking at the
context that you have, leveraging that to make a more
optimal solution. I think the second one is
better, but I also recognise that not a lot of people, not a
lot of organizations are equipped to be able to execute
to the high standards that it needs to to succeed in that way.
For me, I feel like that's the bigger challenge.
We saw that, at least in consultancy, a lot of
organizations have this FOMO fear, like fear missing out,
basically. I don't know why I said FOMO
fear, but in any case, they're like, we need to do something
with AI because our competitors are doing something with AI.
And if everyone has that mindset, then indeed it UPS this
fear of missing out completely. And then people were looking at
their own organizations and seeing what's out there.
And then chat bots was like the fast food Jenny I solution that
a lot of companies were building themselves.
And then I asked the same exact question that you did.
Why are you building this yourself?
Like there are companies and there are start-ups that this is
the problem. How do we distill context from
an organization and create tooling for that to have an
optimal user customer journey with regards to chat And
companies think they can do that better themselves.
I was like, I don't, I don't see this yet, but waiting it out.
I feel like there's also not really a convincing alternative,
which means you need to start experimenting and start small
and kind of incrementally grow, which I think is healthy.
But then, yeah, you see a lot of failure and hopefully that's
good. If there's a culture of failing
is OK and we learn, then that's the best.
I think there's also, of course, it's not black or white, right?
But let me paint 2 extreme cases.
And then there's companies all in between.
You've got companies where, and I think there's probably a vast
majority of the companies out there, there's going to be
dozens of initiatives going on at the same time.
People are running 55, you know, hundreds of projects depending
on the size of the company, of course, that that number keeps
growing. But I think that the hallmark or
the the marker that I would look for is if you're in a group of
managers that are responsible for a department or for a
certain region or whatever and you ask all of them, what are
the three overarching? Priorities for us for this year
or for this quarter in a company that is very chaolic these and
everyone writes them down individually and then you put
them side by side, they will be very misaligned.
Everyone will kind of be in their own mind, in their own
headspace. And then you've got a laser
focus companies on the other end of the extreme where you could
probably go at through all of the different levels of the
company and you could say again, write down like what are the
three top priorities for you? They will be very unified
because everyone's aligned, everyone's kind of on the same
radar, on the same, on the same track.
And of course it starts at the top.
You need someone to just give a laser sharp vision.
This is our objective, this is our vision.
This is what we what this company was made for.
If you're over here, then you have such clarity.
People are able to now deploy a new project.
They can say, OK, we are now going to go after customer
support agents or customer support AI bots because it'll
drastically improve our customer attention, Whatever.
The companies over here I think are the ones that you and I are
familiar with where these projects actually get kicked
off. And then it's one project that
gets drowned in all the other things that are going on.
All the other initiatives, probably they have three half
finished transformation projects still going on Guilty having
been in a consultancy where you then also have the access to the
executive level, right. So then there's probably stuff
that gets pushed through with like you have the the rank,
right. So this is an executive sponsor
project, so it gets priority treatment.
So then others have to wait. That's frustrating in that chaos
projects. It's very hard to get a project
to to succeed unless you make it absolutely minimal, absolutely
simple. Yeah.
But just whipping up a company wide knowledge agent there,
tough one. Yeah.
It's not good enough. I feel like like you need to
figure out indeed, what does it contribute to in in business
outcomes and if there's no laser focus from an organizational
sense, then for some how shape or form you need to figure that
out bottom up right. This use case that I have, does
it actually make sense with regards to cost and benefit and
is going to be enough time saved for people to actually work to
adopt it? Like is it going to stand true
or do we need to indeed focus on kind of the exact decision and
like the highest priority cases and do we focus on that?
I also wonder what would happen if you take a lot of the
companies and you just said, OK, we're going to have to get rid
of 50% of all of our initiatives.
That's just a extrinsic requirement.
We're going to crank up the like the evolutionary pressure a
little bit. You do not have capacity to do
all these things. So 50% has to go.
That doesn't mean that people have to go.
It just means that the multitasking of the Organism as
a whole has to be toned down. I think that would actually be a
very healthy exercise for a lot of companies.
Yeah, I'm there with you. But that's the only reason I'm
there with you is because I had an inkling that was the case.
And then I was responsible for product and I already inherited
a road map that had like many tracks in parallel.
And I was like, this is this is impossible.
We cannot do all of this in parallel.
Nothing's going to work. Everything will go slower as a
response to that. So then one of my, and I also
thought that was my role was to say we do one thing at a time,
we execute, we deliver and we move on to the next.
And there will not be many things in parallel.
There will be nothing because I have this ordered list and we go
top to bottom and then that's it.
I was very, I, I did not have a road map.
I don't, I didn't have any Gantt charts.
Just made one XL sheet, it has already rose and it's very easy
to follow how we do things stop to bottom that's it in it's
simplest and kind of in essence priority and that's how we
execute it. And in the end it was really
hard to get through, but it was quite effective.
I. Have this hate love hate
relationship with gang charts. My first full time job, I worked
for a subcontractor for the European Space Agency and we
built the gang chart that plans out everything that you need to
bring to the space station. Because it was the, I forgot
what the name was, but it's like the management platform for the
ISS. The ISS has some pretty hard
deadlines because the rocket is going up if you forgot your
screwdriver. You're screwed.
You can't go back. That was a good pun.
I'm kind of proud of that one. And so that one, there was no
gun software for this kind of use case because gun softwares
are made with this idea that you've got dependencies, you can
move them forward and backward, you can make them the blocks
large and smaller. But it didn't have this concept
of you have launch windows and you're going to launch something
and you have certain capacity. And so all of these, this linear
optimization had to be custom built.
So I built gun software and I was kind of proud of it.
It's super hard to build on the front end.
You've got all this state management with the reactive
redox and whatever, but then you see a lot of project plans and
you just see all of these blocks on top of each other.
And I often look at these and then I just go, yeah, this
project's going to be massively delayed.
And then I mean, how, why? If you then get asked, like, how
do you know? I don't know, just intuition.
This is not going to work because we can't possibly do all
these things at the same time. People are going to be
distracted. This is just modelling what you
know. There's just all the stuff that
you don't know and your team of five people already has 25
active things going on just in your project management tool,
plus all the stuff that you don't even model.
No way. But then if you distill it down
to a gun chart where you would really say, OK, we have 3
objectives and that's the most we can paralyze.
So when we finish those, then we start with the next thing.
Then you don't need a gun chart anymore because you always have
three things. You can just write them on a
list and you finish like you cross one off and then a new one
makes it. So then gun charts, they come
from engineering. That makes sense if you build a
skyscraper, but they don't make sense in project management in
software in my mind. It sounds like a graph problem.
Dependencies. Yeah, exactly.
Dependencies between sorry, broke a record.
Like, as a final thought, I was wondering what you both think of
this because for me, newer technology pops up, right?
We have, first of all, newer models that just keep popping
up. There's tools that are trying to
solve organizational dysfunctional behaviour, but
also behaviour that like alleviate certain problems that
you didn't even know you had. And all of a sudden now with
tooling and technology, it might be a problem or it might be a
solution that's offered to you. Which means me as an individual
or let's take me as a software engineer.
I have a challenge with regards to my learning journey like you
with regards to Gantt charts. I'm not going to learn
everything at the same time incrementally.
I like to focus and prioritize. But then also from a software
engineering hat, I need not just the theory, I need to be able to
walk the walk. So I also need to build stuff.
And I feel like, especially nowadays, I feel like I need to
build more. I don't feel like I'm building
enough. How do you guys learn or
familiarize, familiarize yourself with new topics with
regards to executing and then trying to be kind of an
authority on that topic? How do you handle that?
Good question. Yeah, so I, I started being a
product manager about a year ago and I was an engineer before
solution architect doing a lot of hands on work.
And what I found myself doing recently is instead of writing
an RFPI just vibe called something which is really fun
because it kind of helps you think about a problem one step
ahead. And it also is an opportunity to
get in touch with new technologies, right.
If you're building something front end, you can try a
different stack every time. So I think coding something,
vibe coding, whether it's vibe coding or actually learning like
a language, whatever, just having these tiny problems in
your life and thinking about those in a software way, could
we could really help, yeah. What have you Vibe called it
lately? What have I vibe coded recently?
Actually something really fun. So we're building a cipher
editor. So for querying the graph, and
what I wanted to do is I wanted to have intelligence suggestions
based on the questions to the user.
So, OK, a little bit context. OK, so I'll keep it short.
We have for the graph, we have a cyber interface which is
queries. And then we have a natural
language interface where you can type normal text and it
translated to a graph query using an LLM.
Love that. That's really cool.
So you can use and you don't need to learn, don't need to
learn the graph language because you can just use natural
language. But there's still the problem of
looking at a blank screen. It says natural language input
right here. What am I going to write?
You know, that's I need to think about what is the question?
So what if I could suggest questions automatically by
looking at the user's schema, by looking at the type of chart
they want to create? So I've coded this super
quickly, this little demo that generates that natural language
queries that then could also be translated to me for jqueries.
So you kind of have this automated question generator for
for graphs. Yeah, yeah.
Is that going to make it in? Because that's very much like
it's very tangible to go then from this idea that I have,
look, here's how it works to making it even in the product at
the end. Let's see.
Yeah, let's see. I hope it makes it in.
I think it's, I don't know it it as an engineer, it's always fun
to do these things. But yeah, it does help you think
and it helps you reach your limitations.
Like OK, maybe I should have shorter questions.
Maybe I should look forward questions, check in at two
months and then see if it's in the product and try it out.
Yeah, what about you post call? What have I coded or how do I
learn? How do you learn?
I think I actually have the the inverse problem, so I'm very
curious about just trying all sorts of things, but I realize I
can't spend my whole day trying things because I'm being paid to
run a team and, you know, lead engineer.
Do the job. So what I want to make sure as I
time box my kind of curiosity journeys to a certain amount of
time where I say, OK, I allow myself 10 percent, 15% of my
time budget or say, and then whatever I do after work hours
that sometimes that goes out of hand, but you know, whatever.
And then within those boxes I just follow whatever I feel
like. I think you can say I'm going to
be really structured about it and I'm going to do this.
I'm going to build an agenda of my learning journey and I'm
going to do it like in a university, but I hate it.
I hate it. Structured learning.
I much rather go off into letting my curiosity be my
guide, and then I just hope that I'm curious about things that on
average, other people are also curious about.
Statistically speaking, it's likely right.
I'm most likely going to be interested in something that
other people are also interested in, because it's very unlikely
that I'm in the 0.001% of people that only like this one weird
little niche corner. So I'm going to try and learn,
or I'm going to be interested in a topic that other shows find
interesting. I'm going to learn about it.
I'm driven by my intrinsic curiosity, so I'm going to go
deeper and I'm going to have more fun on it.
Time's going to go fast, quickly, and I'll learn more
quickly. Yeah, I think learning you
shouldn't overthink in a way of this is a job, do your job.
And then just learn whatever you find cool.
Like right now I find multi criteria decision analysis and
stage gate modelling really interesting.
So I'm trying to think of can you model a lot of business
problem as like a multi stage gate system with MCDA ranking at
each level? I don't know why I find that
interesting. Just an article somewhere
random. Yeah, I think it reminds me of
decision theory in university. And I think it's what we do is
we rank drugs, right? So we have to figure out which
of the 60 million do we want to do.
But I saw a podcast you had where you were talking about
people asking how do I get like a high paying remote job from
the US and how do I get in there?
I think another big one in Europe is where do I live?
People constantly I'm in this bubble where everyone talks
about which is the best city to live in.
London is Amsterdam is a Paris. Should I move to New York?
Should I try the Asia? So this is a ranking problem.
Which is the best city for my unique situation?
What is my criteria grid and what is the weight of each
criterion? And So what is my personalized
ranking for the all options of all cities?
So that's a multi criteria decision problem and there's
many, many like it. What is the stock that a company
should invest in? What is a compound that a
pharmaceutical company should put more money into and which
should they kill? We have the same problem, so I
find the class of problems interesting, and so I'm reading
up in the literature. If I have to force myself to
read that literature because it's on my schedule now, I would
not read it, no. I feel like if I ever need like
a, a project or like I'm not aware of any problems that I can
solve. I just need to have a
conversation with you because I feel like you just, you just
have many already, the one where you know what's for my use case,
the best city to live in. I think that's fascinating.
I don't know if there's a tool out there somewhere, but I feel
like that solves the problem that many people have.
That's a funny one. I think once you're out of high
school or university, you have this, this possibility now to
guide your own learning journey. We were all forced to follow an
agenda where 9th grade, we have to learn about Napoleon.
You don't. Who says every 9th grader in
September is interested in Napoleon at that point in time
in their life, in their unique journey?
Doesn't matter. It's on the agenda.
General knowledge. Yeah.
As an adult now, you get to just do whatever you want.
Just make sure you time box it so that you also get to still do
the things that other people expect from you.
Yeah, yeah, I love that. Cool man.
Thanks, guys. This was a lot of fun.
I think it kind of kind of went everywhere.
I do have a better picture of graph databases, knowledge
graphs. I'm definitely going to have
many conversations, I think. I hope also after the show see
if I can build some stuff with the rest of that because I think
it's fascinating. It wasn't necessarily the most
structured. These are all three topics
conversation, but that's what graphs are all about.
They're they're network, they're messy, they're kind of chaotic.
Good stuff, good mess. Then we're going to round it off
here. If you're still listening, leave
a like. If you like the episode, they're
free. They only take a second and
otherwise we'll see you in the next one.