June 13, 2025 • 12 mins
This week, there were quite a few things I learned:
- Common steps for implementing GraphRAG in Java using Spring AI and Langchain4j, highlighting key differences in setup and customization.
- Study prep updates and help on the Neo4j Developer Certification for June!
- Celebrate Langchain4j’s 1.0 release.
- Two thought-provoking articles—one on enhancing RAG with graphs, and another analyzing the effectiveness of voice-based interfaces.
For a high-level review of steps for GraphRAG in Java, upcoming step-by-step help for prepping to take the Neo4j certification, Langchain4j GA news, and keeping up on tech content, this episode has you covered!
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:05):
You are listening to the BreaktimeTech Talks podcast, a bite-sized tech
podcast for busy developers where we'llbriefly cover technical topics, new
snippets, and more in short time blocks.
I'm your host, Jennifer Reif, anavid developer and problem solver
with special interest in datalearning and all things technology.
(00:25):
This week has been a flurryof little tidbits and more
work on some upcoming content.
I can't wait to tell you aboutit, so let me fill you in.
First up is that, as I've explored bothSpring AI and Langchain4j in the last
few weeks, I've gotten a feel for howGraphRAG often works in Java ecosystems.
You'll have some slight variationsdepending on the implementation
(00:49):
and the framework and such that youchoose, but these are just the general
outline steps that I have found.
I.
First is that you willhave some boilerplate.
You'll typically connect to a database.
You'll configure the LLM model, thevector store, the repository, or some
sort of user interface, et cetera.
Now, the configuration willslightly differ based on the
(01:10):
framework that you choose.
Some frameworks will requireone particular configuration or
another, and vice versa for others.
An example of this is that SpringAI requires the initialize-schema
equals true or false, dependingon the vector store that you pick.
Some vector stores, thisis not required at all.
Other vector stores, it is required foryou to specify whether the application
(01:33):
initializes the schema or not.
For Neo4j, which is the vector storethat I choose and use all the time, this
is a required configuration parameter.
As long as you know it's thereand know it's needed, it's not
that big of a deal to provide it.
Now, though, if I were to do Langchain4j,they don't require the intialize schema.
In fact, that's not evena configuration there.
(01:53):
But they do require the numberof dimensions in your embedding,
the embedding length, basically.
How many floats are in the array.
And this will change basedon the model that you pick.
For instance, one OpenAI model versusanother OpenAI model versus Claude
versus Ollama or Llama or so many others.
There's so many options out there.
(02:14):
Your embedding length, thedimensions that are in that
embedding, are going to change.
So you will have to specify thatin a Langchain4j application.
That is required.
Then after you get done withall the boilerplate, you have a
vector similarity search step.
This is where the retrieval augmentedgeneration piece comes in, but it
finds semantically similar documentsto whatever input you provide.
(02:37):
And that could be an input question,it could be a search phrase, it
could be something else entirely.
But an embedding will getcreated for that input as well.
And then it goes to whateverexternal retrieval source you have.
Sometimes it's a vector store, sometimesit's a list of documents, sometimes
it's a folder, sometimes it's whatever.
And then it does a semanticsimilarity search on that, that
(03:01):
vector store, that resource, andfinds the documents or entities
that are most similar to that input.
The next step is oftena graph retrieval query.
You get done with the boilerplate,the vector similarity search, and
then you tack on a retrieval query.
It takes these similar results from thevector similarity search and traverses the
connected entities in the graph to pullrelated data to those similar results,
(03:23):
extra context and additional entities thatare connected to those similar results.
You'll have some variationson this, depending on the
implementation you choose.
Spring AI it feels like to me, hassome fewer classes and more options
to customize parts of the pipeline.
For instance, in naive rag versusGraphRAG, you can pick and choose which
(03:43):
things you wanna customize, tack on aGraphRAG with a retrieval query piece
without touching some of the other pieces.
Where in Langchain4j, it's very easyand straightforward to do naive RAG,
but if you're customizing things toGraphRAG, you end up having to write
all the boilerplate for all of it.
At least, I haven't found a way to getaround that just yet, but that may change.
Both Spring AI and Langchain4jare very straightforward.
(04:06):
In straightforward use cases.
Things like a plain LLM call, a naiverag, but when you start getting into those
more advanced RAG types of flows, thatis where they diverge just a little bit.
I also have not done things likeagents memory or MCP yet with either
Spring AI or Langchain4j, so thatmay change the conversation as well,
(04:26):
but this is just my analysis so far.
Once you get done with the graph retrievalpiece, then you actually need to stuff the
context into the prompt and call the LLM.
So you have that vector store similarityresults plus a retrieval query context,
and you're gonna stuff that into yourprompt string and send that over to
the LLM in order for the LLM to usethat in a response or an answer.
(04:50):
This is very similar, whether you'redealing with spring AI or Langchain4j,
some slight variations, but generallythe same process and steps happen here.
Now that wraps up my summary on runningGraph Rag in Java and the frameworks
that I've touched and played with so far.
However, this may change and, I'll,I'll have an update in a second that
(05:13):
already things are changing out fromunderneath us as I, I record this, I.
The next thing I've been working on isthat we're updating and focusing on the
Neo4j developer certification in June.
if you're not familiar with the program,the Neo4j certified developer is where
you set a standard of your knowledgeon Neo4j Foundations, how to use,
(05:35):
learn, and understand Neo4j in bothyour personal and professional lives.
There's both free preparation materials,things like online courses and general
published blog posts and content,but there's also, the exam is free
as well, just to showcase what youknow and the foundations of Neo4j.
We will be revamping some oldermaterials, refreshing some things,
(05:59):
helping people interact and study for,and then pass the Neo4j certification.
And I'll be revamping someof my older content as well.
There will be some events andthings going on later in the month.
If you're interested in somethinglike this, you wanna take the Neo4j
developer certification and areinterested in prepping for it and
getting a little bit of a walkthroughinsight into what's coming.
(06:21):
Feel free to join one of those, keepan eye on my channels and on the Neo4j
channels to check for details on that.
Then the last thing I have for thisweek is I just saw that Langchain4j
released 1.0 general availability.
Spring AI just did this recently and nowLangchain4j has joined the group too.
Now I need to go back and updateboth my Spring AI apps and my
(06:42):
Langchain4j apps to 1.0 releases.
All of those are already out of date.
The joys of technology,especially in generative AI.
That will be coming.
I'm really excited to see whereboth of these libraries go and
the things that they do in thenext weeks and months there.
I looked at a couple ofcontent pieces this week.
One is called Beyond Vector Search,unleashing the Power of GraphRAG
(07:04):
for Smarter Recommendations.
This was written by a teammate ofmine, and I really liked this article
because it actually aligned very wellwith the things that I've talked about
previously on this podcast and some ofmy other content on the steps of graph.
In fact, we just talked about thatearlier in the episode, right?
I came across this article after I'dput together my take on the graph
rag steps, and though the example Sidprovides is in Python, it follows the
(07:27):
same general steps that I listed above.
I also really loved that Sid took aprevious example of a chat bot using
Vector only RAG that he had builtpreviously and layered GraphRAG onto that.
I've mentioned that I like to thinkof Gen AI and layers and SID'S
perspective also takes this approach.
The article takes on process differencesbetween vector only RAG and GraphRAG,
(07:49):
as well as functionality differences,both strengths and weaknesses of each.
Then the article goes through somedemo steps, highlights some code, and
then provides links to repositoriesand more resources at the end.
I really thought this was a fascinatingarticle, so if you wanna get someone
else's take on this or want to see somePython code, check out Sid's article.
(08:09):
The next article that I found was theCase Against Conversational Interfaces,
and I really liked Julian's take on this.
I have some mixed comments Iguess on this, but we'll dive
into that just a little bit more.
The article overall talks though howtech has tried to migrate to voice-based
interfaces, but each time they fizzle out.
(08:29):
And the why from Julian's perspective isthat it's based on two different factors
of data transfer speed and lossiness.
Speed is how fast thedata transfer happens.
And then lossiness is how muchinformation is lost in that transfer step.
Using general averages, humans arefaster in receiving data, reading
(08:49):
or listening to it, versus sendingdata, writing or talking and so on.
We form thoughts very, veryquickly, but actually putting
them into words is much slower.
However, day-to-day communication,human to human interactions
feel very fast, don't they?
Why is that?
Because you have things like bodylanguage, gestures, and so on that
(09:11):
speed up the interactions and help youshorten conversations with fewer words.
If we compare the human to humaninteraction with human to computer
interfaces, things like GUIs andkeyboard shortcuts allow us to
interact quickly and make sense ofcommands without using text formats.
Touch screens further increasedthis a little bit and made
(09:33):
the process flow smoother andquicker, but it enhanced existing
experience rather than replacing it.
There's still lots ofopportunities where touchscreen
just doesn't make sense either.
Now, where does this leave speech to text?
There are some issues in the pastwith previous iterations where we
had technical limitations, right?
Things like the AI wasn't fast enoughto interpret speech and successfully
(09:57):
use it and provide something in return.
But even though we've made massiveincreases in improvements to this,
it still seems slower and clunkierto do voice interactions versus
keyboard shortcuts or touch.
Now the article and I will both makethe case that that does not mean
that voice interactions don't enhanceor improve several interactions or
(10:19):
open the doors for accessibilitythat just did not exist before.
But I do think we have to thinkintentionally about where voice
communication enhances and where it mightactually decrease productivity or usage.
For instance, one of my thoughts onsome of the coding tools out there
is evaluating when is it simpler,faster, et cetera, to explain to
(10:41):
the LLM how to build somethingversus somebody just building it.
Where do these interactions, these datatransfer interactions, where does it
enhance my productivity versus hinder it?
Where does it make sense to implementvoice-based interfaces or applications
versus other interaction mechanisms?
I find this study really fascinating andalways love an article that encourages me
(11:04):
to be intentional about building tools andthe decisions that I make going into them.
What I loved is that itwas thought provoking.
It was a bit negative towardsvoice-based interfaces, but the
article still made some good points.
And while I think that voice interfacesare so important to have and we should
invest to improve them, I do think weshould evaluate which interface type is
(11:26):
most powerful in a particular use caseand not implement any single interaction
method across the board, especially forthe reason of it just being shiny and new.
This week I enjoyed getting some moreperspectives on how GraphRAG works
throughout the Java ecosystem andtrying to keep up with the latest
developments in AI with a now 1.0release of Langchain4j to add to the mix.
(11:47):
I'm also updating materials tohelp developers take and pass the
Neo4j developer certification.
I read two articles one that clarifiedVector RAG versus GraphRAG and the other
took a thoughtful look at conversationalinterfaces of the past and present.
As always, thanks forlistening and happy coding.
You are listening to the BreaktimeTech Talks podcast, a bite-sized tech
podcast for busy developers where we'llbriefly cover technical topics, new
snippets, and more in short time blocks.
I'm your host, Jennifer Reif, anavid developer and problem solver
with special interest in datalearning and all things technology.
(00:25):
This week has been a flurryof little tidbits and more
work on some upcoming content.
I can't wait to tell you aboutit, so let me fill you in.
First up is that, as I've explored bothSpring AI and Langchain4j in the last
few weeks, I've gotten a feel for howGraphRAG often works in Java ecosystems.
You'll have some slight variationsdepending on the implementation
(00:49):
and the framework and such that youchoose, but these are just the general
outline steps that I have found.
I.
First is that you willhave some boilerplate.
You'll typically connect to a database.
You'll configure the LLM model, thevector store, the repository, or some
sort of user interface, et cetera.
Now, the configuration willslightly differ based on the
(01:10):
framework that you choose.
Some frameworks will requireone particular configuration or
another, and vice versa for others.
An example of this is that SpringAI requires the initialize-schema
equals true or false, dependingon the vector store that you pick.
Some vector stores, thisis not required at all.
Other vector stores, it is required foryou to specify whether the application
(01:33):
initializes the schema or not.
For Neo4j, which is the vector storethat I choose and use all the time, this
is a required configuration parameter.
As long as you know it's thereand know it's needed, it's not
that big of a deal to provide it.
Now, though, if I were to do Langchain4j,they don't require the intialize schema.
In fact, that's not evena configuration there.
(01:53):
But they do require the numberof dimensions in your embedding,
the embedding length, basically.
How many floats are in the array.
And this will change basedon the model that you pick.
For instance, one OpenAI model versusanother OpenAI model versus Claude
versus Ollama or Llama or so many others.
There's so many options out there.
(02:14):
Your embedding length, thedimensions that are in that
embedding, are going to change.
So you will have to specify thatin a Langchain4j application.
That is required.
Then after you get done withall the boilerplate, you have a
vector similarity search step.
This is where the retrieval augmentedgeneration piece comes in, but it
finds semantically similar documentsto whatever input you provide.
(02:37):
And that could be an input question,it could be a search phrase, it
could be something else entirely.
But an embedding will getcreated for that input as well.
And then it goes to whateverexternal retrieval source you have.
Sometimes it's a vector store, sometimesit's a list of documents, sometimes
it's a folder, sometimes it's whatever.
And then it does a semanticsimilarity search on that, that
(03:01):
vector store, that resource, andfinds the documents or entities
that are most similar to that input.
The next step is oftena graph retrieval query.
You get done with the boilerplate,the vector similarity search, and
then you tack on a retrieval query.
It takes these similar results from thevector similarity search and traverses the
connected entities in the graph to pullrelated data to those similar results,
(03:23):
extra context and additional entities thatare connected to those similar results.
You'll have some variationson this, depending on the
implementation you choose.
Spring AI it feels like to me, hassome fewer classes and more options
to customize parts of the pipeline.
For instance, in naive rag versusGraphRAG, you can pick and choose which
(03:43):
things you wanna customize, tack on aGraphRAG with a retrieval query piece
without touching some of the other pieces.
Where in Langchain4j, it's very easyand straightforward to do naive RAG,
but if you're customizing things toGraphRAG, you end up having to write
all the boilerplate for all of it.
At least, I haven't found a way to getaround that just yet, but that may change.
Both Spring AI and Langchain4jare very straightforward.
(04:06):
In straightforward use cases.
Things like a plain LLM call, a naiverag, but when you start getting into those
more advanced RAG types of flows, thatis where they diverge just a little bit.
I also have not done things likeagents memory or MCP yet with either
Spring AI or Langchain4j, so thatmay change the conversation as well,
(04:26):
but this is just my analysis so far.
Once you get done with the graph retrievalpiece, then you actually need to stuff the
context into the prompt and call the LLM.
So you have that vector store similarityresults plus a retrieval query context,
and you're gonna stuff that into yourprompt string and send that over to
the LLM in order for the LLM to usethat in a response or an answer.
(04:50):
This is very similar, whether you'redealing with spring AI or Langchain4j,
some slight variations, but generallythe same process and steps happen here.
Now that wraps up my summary on runningGraph Rag in Java and the frameworks
that I've touched and played with so far.
However, this may change and, I'll,I'll have an update in a second that
(05:13):
already things are changing out fromunderneath us as I, I record this, I.
The next thing I've been working on isthat we're updating and focusing on the
Neo4j developer certification in June.
if you're not familiar with the program,the Neo4j certified developer is where
you set a standard of your knowledgeon Neo4j Foundations, how to use,
(05:35):
learn, and understand Neo4j in bothyour personal and professional lives.
There's both free preparation materials,things like online courses and general
published blog posts and content,but there's also, the exam is free
as well, just to showcase what youknow and the foundations of Neo4j.
We will be revamping some oldermaterials, refreshing some things,
(05:59):
helping people interact and study for,and then pass the Neo4j certification.
And I'll be revamping someof my older content as well.
There will be some events andthings going on later in the month.
If you're interested in somethinglike this, you wanna take the Neo4j
developer certification and areinterested in prepping for it and
getting a little bit of a walkthroughinsight into what's coming.
(06:21):
Feel free to join one of those, keepan eye on my channels and on the Neo4j
channels to check for details on that.
Then the last thing I have for thisweek is I just saw that Langchain4j
released 1.0 general availability.
Spring AI just did this recently and nowLangchain4j has joined the group too.
Now I need to go back and updateboth my Spring AI apps and my
(06:42):
Langchain4j apps to 1.0 releases.
All of those are already out of date.
The joys of technology,especially in generative AI.
That will be coming.
I'm really excited to see whereboth of these libraries go and
the things that they do in thenext weeks and months there.
I looked at a couple ofcontent pieces this week.
One is called Beyond Vector Search,unleashing the Power of GraphRAG
(07:04):
for Smarter Recommendations.
This was written by a teammate ofmine, and I really liked this article
because it actually aligned very wellwith the things that I've talked about
previously on this podcast and some ofmy other content on the steps of graph.
In fact, we just talked about thatearlier in the episode, right?
I came across this article after I'dput together my take on the graph
rag steps, and though the example Sidprovides is in Python, it follows the
(07:27):
same general steps that I listed above.
I also really loved that Sid took aprevious example of a chat bot using
Vector only RAG that he had builtpreviously and layered GraphRAG onto that.
I've mentioned that I like to thinkof Gen AI and layers and SID'S
perspective also takes this approach.
The article takes on process differencesbetween vector only RAG and GraphRAG,
(07:49):
as well as functionality differences,both strengths and weaknesses of each.
Then the article goes through somedemo steps, highlights some code, and
then provides links to repositoriesand more resources at the end.
I really thought this was a fascinatingarticle, so if you wanna get someone
else's take on this or want to see somePython code, check out Sid's article.
(08:09):
The next article that I found was theCase Against Conversational Interfaces,
and I really liked Julian's take on this.
I have some mixed comments Iguess on this, but we'll dive
into that just a little bit more.
The article overall talks though howtech has tried to migrate to voice-based
interfaces, but each time they fizzle out.
(08:29):
And the why from Julian's perspective isthat it's based on two different factors
of data transfer speed and lossiness.
Speed is how fast thedata transfer happens.
And then lossiness is how muchinformation is lost in that transfer step.
Using general averages, humans arefaster in receiving data, reading
(08:49):
or listening to it, versus sendingdata, writing or talking and so on.
We form thoughts very, veryquickly, but actually putting
them into words is much slower.
However, day-to-day communication,human to human interactions
feel very fast, don't they?
Why is that?
Because you have things like bodylanguage, gestures, and so on that
(09:11):
speed up the interactions and help youshorten conversations with fewer words.
If we compare the human to humaninteraction with human to computer
interfaces, things like GUIs andkeyboard shortcuts allow us to
interact quickly and make sense ofcommands without using text formats.
Touch screens further increasedthis a little bit and made
(09:33):
the process flow smoother andquicker, but it enhanced existing
experience rather than replacing it.
There's still lots ofopportunities where touchscreen
just doesn't make sense either.
Now, where does this leave speech to text?
There are some issues in the pastwith previous iterations where we
had technical limitations, right?
Things like the AI wasn't fast enoughto interpret speech and successfully
(09:57):
use it and provide something in return.
But even though we've made massiveincreases in improvements to this,
it still seems slower and clunkierto do voice interactions versus
keyboard shortcuts or touch.
Now the article and I will both makethe case that that does not mean
that voice interactions don't enhanceor improve several interactions or
(10:19):
open the doors for accessibilitythat just did not exist before.
But I do think we have to thinkintentionally about where voice
communication enhances and where it mightactually decrease productivity or usage.
For instance, one of my thoughts onsome of the coding tools out there
is evaluating when is it simpler,faster, et cetera, to explain to
(10:41):
the LLM how to build somethingversus somebody just building it.
Where do these interactions, these datatransfer interactions, where does it
enhance my productivity versus hinder it?
Where does it make sense to implementvoice-based interfaces or applications
versus other interaction mechanisms?
I find this study really fascinating andalways love an article that encourages me
(11:04):
to be intentional about building tools andthe decisions that I make going into them.
What I loved is that itwas thought provoking.
It was a bit negative towardsvoice-based interfaces, but the
article still made some good points.
And while I think that voice interfacesare so important to have and we should
invest to improve them, I do think weshould evaluate which interface type is
(11:26):
most powerful in a particular use caseand not implement any single interaction
method across the board, especially forthe reason of it just being shiny and new.
This week I enjoyed getting some moreperspectives on how GraphRAG works
throughout the Java ecosystem andtrying to keep up with the latest
developments in AI with a now 1.0release of Langchain4j to add to the mix.
(11:47):
I'm also updating materials tohelp developers take and pass the
Neo4j developer certification.
I read two articles one that clarifiedVector RAG versus GraphRAG and the other
took a thoughtful look at conversationalinterfaces of the past and present.
As always, thanks forlistening and happy coding.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.