GSoC '26 Week 6: The Agentic Pipeline, Node 0, and the SPARQL Gate
by
I continued with my idea of LangGraph integration first, to make this an Agentic AI Pipeline, and now LangGraph will take care of when to fire which node.
I officially migrated the pipeline into a cyclical StateGraph. Now, instead of crashing on an error, Node 4 (The Judge) can emit states like ADJUST_MATH, ADJUST_PREDICATE, or RE_SEARCH, dynamically routing execution backward to previous nodes up to a hardcoded retry limit.
So now, according to the need of the particular sentence and the output of Node 4, now with the help of the LangGraph agent we are able to do exactly what needs to be fixed! If for a sentence the judge figured out that the extraction is wrong, the required entity for the sentence is not even in the top 15 candidates generated by Node 2, that means the extraction has been wrong and we need to extract again. So LangGraph will fire RE_SEARCH to Node 2, and with the feedback of Node 4, this time it’ll be able to extract the correct entities.
If Node 4 finds out that the extraction is correct and the correct Object/Subject sits somewhere in the top 15 triples, but not at the top! That means this time the issue has been with the maths and the ranking system. So this time the LangGraph will fire ADJUST_MATH to Node 3 with a feedback to update the filters from original hardcoded to the ones required for this particular sentence. This will help the Node 3 to rank the entities correctly.
And if the judge notices that everything is correct but the predicate is wrong, then it’ll loop back to Node 3 via LangGraph and share its feedback for re-extracting the predicates.
This is how the LangGraph agent is going to work and going to make our pipeline more efficient.
Now when I ran the pipeline again I found another thing, a massive Data Gap. If a user typed “I read a piece in the new york times,” DBpedia obviously had no entity for “I”, and lowercase extraction caused API failures. That is why I built Node 0 to standardize inputs (e.g., resolving “I” to “The user” and enforcing Named Entity capitalization).
Node 0 is supposed to act as a preprocessing layer. For example if there is a sentence that includes the magazine name “The New York Times”, now we know that this is a magazine, but the Node 1 LLM can break it down, which will destroy the final triple. The Node 0 will quote it with “” so that Node 1 understands that it is one full name. And for the sentences that include “I”, earlier on the pipeline was extracting garbage in such sentences, in one of the cases it literally emitted “Italy”, probably the most popular entity starting with I!
Now the Node 0 pre-processes it to “User”, so that the Node 1 and rest of the pipeline doesn’t get confused.
Another minor bug in Node 0 that was happening after this was that it started replacing everyone’s name (like “Buzz Aldrin”) with “The user”!! Had to fix this by tightening up the prompt of Node 0, and applying some strict prompt constraints.
Now comes the biggest upgrade of this week, the prompt changes in Node 4 and adding a final sanity check!
It was noticed that sometimes Node 4 was getting lazy and approving the wrong entities, and in the end updating it to the correct entity. It was just being lazy and breaking the pipeline, it wasn’t looping back to the earlier nodes for correcting entities, it was simply approving the wrong ones and simply editing them itself.
For example, in one of the sentences Node 3 gave out Eiffel_Tower_replicas_and_derivatives instead of the correct entity Eiffel_Tower, and Node 4, instead of rejecting it, simply approved it and corrected it itself in the final triple.
To fix this, I updated the prompt of the Node 4 and made it stricter, so that now it doesn’t happen again. Do not approve any wrong triple and manually edit the entities until it’s not the final override layer where the Node 4 LLM has the power to give the final triple itself, if even after 2 retries our pipeline is not able to give the final triple.
Another thing that was noticed was that Node 4 also sometimes invented some entities that didn’t even exist!! Especially in the override layer.
Hence we need a final sanity check whether the particular triple even exists in DBpedia or not!
For that I built a 3-layered SPARQL Gate.
After the final triple is given by the pipeline, whether it’s the pipeline or the final judge override, we will fire a SPARQL search to see if this full triple is even present in DBpedia or not!
It was noticed that sometimes the final triple actually makes sense logically and factually but it doesn’t exist in DBpedia. It can happen, and if we reject this triple then we’ll reject a fully correct triple! Which we don’t want.
So we check if all the entities present in the triple exist individually, if not, straight up reject. If yes then we search in the DBpedia graphs, to see if there’s some sort of connection between all the entities with the help of BFS search.
If yes then we definitely have a valid and correct triple, and we approve it.
Every final triple given by the pipeline must pass this SPARQL gate, as this is the final sanity check and this solves a lot of problems. Now at least we have a guarantee that the final triple given by our pipeline is correct and exists in DBpedia, and it makes sense factually and logically!
With this I wind up my first half of GSoC, this is the work done till the mid-term evaluation. Will show the results showcased in the mid-term evaluation in the next blog, stay tuned! Let’s keep the momentum going!
tags: