GraphRAG and Explainable AI: Building Trustworthy LLM Outputs - Rohit Bhardwaj

This talk focuses on the implementation of Graph RAG, a system designed to provide defensible answers in the context of artificial intelligence. The speaker addresses how trust failures in enterprises often stem from the inability to provide accountable answers, rather than issues within the AI models themselves. They emphasize the importance of grounding AI outputs with evidence that supports decision-making processes, using frameworks like Neo4j to build relations among data points. The discussion covers various industries, highlighting challenges such as data integrity, compliance, and the need for human oversight in low-confidence situations. The speaker outlines production patterns to ensure AI systems can produce explainable, auditable outcomes while complying with new regulations. Overall, this session provides insights into constructing a trustworthy AI infrastructure that balances precision and accountability.

So, we will be discussing this in more details of the tinyurl.com/explainableai. What is it? tinyurl.com/explainableai. This is where I have everything related. So, we let's get started on our subject. So, we are very clear. You are here not for the possible AI. You're here for the defensible answers. So, what is graph rag really solving for? If you say that like, you know, hey, this is the answer

I gave. But, how do you come to that answer? That is graph rag, okay? So, that's not the way people describe it. That's the way I describe it. If you're able to defend like, if project manager is saying, hey, why did you make this code change? You should be able to defend, yeah, there was a design decision we made and we did it this way. Same thing

is true. At run time, graph rag can be used for that purpose. And we're going to discuss that today as part of our journey. So, when we say, you know, graph rag, so what does that really means? That, you know, enterprise level, they're not failing due to intelligence. It's the failing on the trust layer. You are saying hallucination is happening really. So, graph rag is how to

move into more defensible answers which you can come up with this in this case. So, trust failure, the most enterprise are failing because the model because the model it's not because of the model is stupid. Like, hey, that model it does not work. The because the organization cannot defend any answer coming to you. So, if you're starting able to do this defense, then you should be able

to make make the perspective in this case. So, enterprise the main thing is three ways of trust break which happens. Actually, this is how this actually happened in production. I'm discussing those those three cases. Number one, somebody is asking for for for correct sounding grounded ungrounded data which is coming in. Can I Can I get a refund? And this is for the Air Canada. You know, somebody

went in and they asked the question in the Air Canada. Hey, can I you know, get a refund for a bereavement? You know, I have to I have to change my flights and do that. And you know, the AI said, yes, you can do it in this circumstances. I sympathize with you and you know, do that. Oops. And then later on, Air Canada says, "Sorry, you can't

do it." And of course, it got settled because it was they hit they took a snapshot of of that value. So, no visible evidence, no path to back up the data and the logic which is there. Now, that is the real risk. No accountability, no auditability. So, you are here for insurance claim. Like the insurance claim came up with a decision whether you will get the insurance

and how much amount you will get it. Yes? There is a defense you have to do. Yes? How can you do the same defense through an AI? Everybody with me? That's a real challenge which will be solving today. The third one is conflicts. The policy or source of today the basically, there are a lot of solutions which are there, but policy is violated. If you have a

violation in the policy, how you attend that violation? That's a real compliance breach which can happen and you know, you get get these problems. Any one of these these are enough to lose a trust. So, we are here to build the trust. To Graph RAG, I'm considering not just hey, you get the answer and then being that, but how do you build that trust by using Graph

RAG? I'm not building a pilot. Pilot is okay. Like pilot like everything looks really good like, you know, utterances look very good. The wrong answer can still sound professional. Very professional answer is there. Now, health care, the question came along, is this treatment covered under the patient's plan? Yes, the exception appears to apply. You yeah, model is saying yes, the exception apply and then the policy exclusion

clause is there which they did not read. And now the claim is denied and then that's where the real problem is coming So, this is happening in most of these industries. Now, what sounds fluent language, confident tone, everything good is really not good. Is not does not equal to what we need is a grounded source of truth. And 90% of issue people say is there in the

AI. Not really, not from my perspective. It's actually garbage in garbage out. If you don't have a clean data, you cannot do this. That's the real problem which we are all facing. Consistent policies audit, you're not able to provide the auditable fluency for your for your data. That's another problem which is there. So, that's what we'll be doing looking at as part of our our our usage.

So, what are the means? We're going to look at three things. You should be defensible, you should be able to verify, audit, and accountable. If you are able to do these four things to a claim with somebody is opting for, and that is what we'll be looking at graph rag turning into answer into evidence-based backing. So, traditional rag is helping grounding. So, I'm not saying don't use

traditional rag. Traditional rag is needed and I'll talk about a pattern which requires traditional traditional rag to be there. But, we need relationship-aware grounding. That means you're chunking the documents, you're embedding them, retrieving similar chunks, and then you're adding the context and you're generating the answer. That's traditional rag. Yes, that's pretty much you're getting the data from their database and getting that perspective for us. The problem

is the answer is still failing. You're still going to go through the top layer and then getting generating this data and then classic rag is good. Like you're ingesting the document. The problem is when I'm ingesting this document, most of the time people are ingesting it, But they have a huge document of 100 pages. Is that a good thing to ingest a document? So, the first thing

we have to do is that the document is for machine to understand. Not a human to understand. Well, human is never going to read it anyways, you know. Who reads the document? You just sign wherever people tell you to sign, you know. But the problem is if the machine needs to read it, machine should be able to get it in chunks which you can really apply. So,

if you have a document 100 page long, make it 10 pages. At least make it chunkable, like you know, you are able to get and have an intent what we need to do. You chunk this data and which steps in the pipeline you teams over trust. You're trusting the top K chunks. What is your What is your What is your current design pattern looks like? Like we

need to see how the pipelines are coming in. You're providing summaries for your data, but the crack problem is the crack really is happening. Then somebody is asking for linked facts. It's not the order, it's the product has a skew. For that skew, you have a policy attached to it for a given reason. It's not for a general reason, it's for a given reason. How do you

do that in a classic rag? And people say, "Hey, put everything in classic rag." No, it's not going to work. Policy definition, you can't you can't do that. And that's where the similarity is not the truth. That's the real problem which is there. Attribution is often weak. You're trying to do that, that's not good. Chunk hides the relationship. You are having multiple chunks, they are hiding the

relationship and the entity ambiguity is also there, like wrong joints are coming in and that is the real cause of problem, like you know, you're not getting uh proper answer for yourself. So, practical example that exposes this gap. Customer is making a call and they have a policy. Can this customer receive a refund under this policy for this product in this region given this exception and order

history? Uh, that's the real real thing. Real problem is how do we do that aspect, you know, using the regular thing. This is not such a text similarity search. This is the evidence problem. How you defend your decision. Yes? And that's what we'll be uh discussing how do we defend this decision today. And this is the enterprise truth of relationship which is missing and that's where the

graph rag is really coming in. Better chunking is added just because of that reason. All right? So, what does that mean? Traditional rag. Now, we're going to go to act three. Now, think about this is a movie going on, you know, I'm just going to go through different different movies. Uh anybody saw Durander? Yes? Durander has like, you know, Durander 1, Durander 2, now there Durander 3

is coming, yeah? This is Durander 3, yeah? So, we know what the problem we know the villain. The villain is really not chunk data. What is the villain? We don't have a relationship between them, you know, we're not able to relate the data which is coming to us. So, where that's where the understanding the entities is very important. Understanding traversing through this relationship is going to get

you the right answer for yourself. And that is what we'll be looking at act three. So, when the act three, the understanding these relationship is that what the graph rag is. Text similarity search, but now you're asking which chunks look similar. Which are connected facts? Which matters to me? You are having multiple facts, you get these facts out from there and then what really matters for me?

That's what we are trying to call it as a graph rag. So, example is customer is there who's having generating an order. I got the order and now I have a product which is there related to it and product has a policy attached to it and for a given region there's an exceptional policy there and how do I get this data in a graph rag is not

just retrieval, it's also being contextual aware. Somebody asked a question, "Hey, how do I bring in the context?" We can bring in the context using this. That means the documents are connected with evidence. Now, you have got customer calling an order and a policy and a product is there. I have this document 17 1714 is a document is there. Policy 3.2 is there and case is this

much. We have to attach these documents which are attached to a case notes. Yes, you greeted a case. Now, somebody is asking for a case. There's a problem going on. I want a refund for myself. How do I get this refund from this document? That's where the entities and relationship and citations are coming in. You should be able to cite why this document where is this document

coming from? And that is where the graph is really used for. And the reflection point here is that we need to find out the business facts. You need to go to your business and look at those facts and then and then that becomes your something called as canonical data model. Don't reinvent the wheel. Canonical data model is there for insurance industry, for banking industry, for healthcare industry.

Use those canonical data model and build this relationship. So, Neo4j fits the graph rag naturally. And the reason is when I say Neo4j, it does not mean Neo4j. There are other products doing the same thing. I mean, but I'm going to take one example just to talk on this, okay? So, relationship and the path with multi-hop is done. So, that means you're going from one path from

customer to order to product. Okay? We're going to this multi-hop to get the answer for myself. That's where the dependency hierarchy and the linked evidence is really coming in. To path-based routing is coming in. So, I can generate a hierarchical effect. So, in your enterprise, you need to ask how do you get the answer? Do you get the answer in one hop? Probably not. And that's what's

happening right now. That's the way we are all getting the data and we're not getting right data for us. And we'll give take a look at different different ways of looking at this. A practical question is not the text is a problem, the graph problem. Can a customer receive a refund for this policy? Same thing, you know. Now we do the top K. The region clause is

another document, product is another document, and graph rack can now reason over all these orders, exceptions, products, which are all linked to each other. And then get me the answer which is the right answer for myself. That's where the graph rack is really used. So we're going to go through the same process. The documents are there. You extract the document. You construct the graph first. Okay? Number

one, you're going to construct the graph. Yeah? Based on that graph, the knowledge graph is constructed. Now you can do vector search plus lexical search and you orchestrate to get the right answer for yourself. That's pretty much what we're going to do. We'll look at all the five patterns to do it properly. Right? So the key shift really is from the traditional which is like, you know,

looking at the document, but now we have a ground in terms of text entities and paths. Now you're going through multiple hops to solve this particular problem. So the perspective which we get is this is the bridge to solve the explain. Explain me how this happened. That's where the act four comes in. Act you know, think about like, you know, they talk about like, you know, Durandal

also goes act two and act two, you know, something like that. So try to follow that. Explainable AI in practice. Now that's where enterprise does not need magical answers. It needs auditable answers. If you just audit this, that means show me the source documents where you got this data from. Show the entities and relationship. How did you get this data? Show why one path was chosen. Now,

this is called as reinforcement learning. What is it called? Reinforcement learning. I'm I'm We must have seen that like you know when you get an answer when you do reinforcement learning that means you have multiple paths to go through. Based on the multiple paths to go through, you're finding out two or three paths. On the graph also you can find that and you can say that there

are some weak links are there which you're going to shed and not use. Okay? And then at the end you need to summarize and add those facts as a As a text box for that decision you have made. If you don't do that you can't defend what you did and that is where explainable means. Audience shift is shift you want you know from answer to quality quality.

Uh to answer defensible possible solution and compliance and regulations are there. By the way, there's a compliance coming and I'll talk about compliance a little bit later. Uh you know EU EU has a AI law coming coming in June, yeah? Very soon. So so we need to know that so that you know you could prepare you actually prepare. Anybody has a European customer? You I mean global

companies have it so you need to actually work on that to make it happen and that's where if the answer were challenged by an auditor. The question is if somebody's challenging that CFO is coming to you, what proof would you have? And if you provide this proof explainable envelope that means final answer it has a direct you know unsaid you know clear you know problem and definition

panel you're creating and there's a governance panel is also there to solve for this problem, okay? So that's what we will be doing and and and would you have an AI system with all three panels or you having only one? Most of us have the answer panel. We don't have evidence. We're not collecting evidence. Most of them are not doing governance. If you do governance and evidence,

now you are able to come through refund decision. Can you receive the re- refund decision? Form from refund policy because refund allowed from this policy because the product category is eligible. Within 14 days you can do the refund. So, source document, so you have source documents entities are coming in here. What is the path traced to get that exception? And then at the end the boundary, like

you know, confidence level. Is the confidence medium or high? If the confidence is high, that means If the confidence is low, what you can do? Anyone? Human in the Huh? Human in the loop, yes. Perfect. So, we need to provide human in the loop. So, which of these evidences are missing in your current pilots? If you are are you doing all four of these or missing one

of them? If you do all four of these, you are good. You are golden. From your perspective, yeah? That's what is a important thing to understand here. So, why one path is chosen over the other? And this is where the chosen path comes in. This is sometimes called as reinforcement learning, you know, sometimes ChatGPT does that also, you know, when it's giving an answer it ask us

like, you know, you want to pick this answer or this answer? What is it trying to do? It's trying to create a path and start to give us an answer and trying to figure out like uh do I want the one type of answer or the other? And that is what is called a matched chosen path and use exception bulletin and which one should we that I

did I pick in there? And what is the chosen path and what is the rejection path also? Like why I did not pick the old That's something I should be able to defend saying that document chunk was similar authoritative be able to provide the solution. So, the main thing you should be able to justify exclusion and inclusion both in your any in your perspective. Are you doing

both of them? That's my question. If not, it's a good time to do it. So, now you are defending yourself. Now, separate model summarization for for this is also there. Now, high stakes is there. Now, model may do summarization and also do comparing of the passages and get the answer. System needs to assert the facts which are there. So, don't just look at the model. What model

can do has to be dictated by who? System. If you have a policy, you have to enforce the policy through system, not through model. Don't give model privilege to dictate your policy. That's what I'm trying to say here. So, if you do that, you know, you have to see like, draw the boundary. System is a truth enforcement. Model is the generation. LLM, how many here have hallucination

in terms of this coming in? This is exactly the reason you have this problem. So, what the industry is moving towards is more determinism. So, determinism means like, you know, uh in in uh in Salesforce also, we have an agent Agent Force, we have something called Action Script is there. We are trying to have if-then-else statement, like, you know, to be able to have determine exactly how

you want to execute this plan which is coming to you. If you have that, you have more control over what's going on. So, you need to enforce these policies. More important to enforce these policies. That is the real problem of the uh thing which is coming in. No, provenance concrete is important. Without this chain citation, you cannot really do anything. You can't really find the lineage coming

in. Who is the What is the source? These are the three documents for the source. Well, these are the links which are coming in. Entity extraction, what are the extractions are there? What is the graph path? And what's the answer output? If you have all four of them, now you have proven this value is correct. Yes? And and if if if a customer disputed the answer 6

months later, can you replay this provenance? Can you do that? Well, it's a JSON format behind the scene. You took a decision. Now, how many here have seen the architecture decisions? Yes? You know, there was a talk with Venkat also. He talked on architect decision. You know, you should decide that. My decision is a code. Like it is actual JSON file. I want to keep that file

if somebody asking me question, "Hey, why did you make the decision?" Because of this I made this decision. So, graph rack is not giving you that decision. You have to store it somewhere and then that is what is you're going to be useful for you. >> [snorts] >> Now, there is a confidence boundary there. Now, you look at the evidence and you look at are there any

conflicting utterances coming? Based on the conflicting utterances coming and the policy versions are missing or ambiguous, in that case what do you need to do? What should system pass forward or not? Where are the risk which are coming in? And that is where the output is there where human in the loop we're going to add to really solve this puzzle for us. And I'm doing the same

thing. So, what's happening is one of the project I'm working on. So, email is coming in. Based on the email coming in, I need to find out what do I where do I route my traffic to? I'm doing the same thing. I'm using the graph rack to really understand the entities which are being sent from the user. Based on those entities, then I'm finding out the utterances.

Utterances means what if the user So, the how do you get that utterances, anyone? How do you get that utterances? From the user, they are typing in on the email the utterances are coming. Where are those utterances coming from? You say that we have to wait for them to add this. Yes? No, it's there in your system. All the interactions user did, they made the decision. You

are doing this manually right now. These are called as jobs to be done. What is it called as? Jobs to be done. When I'm creating an agent, what am I doing? I'm saying that I'm creating a new employee. What What are the jobs you do in this employee and what are the actions you're trying to perform for Two things I'm doing. If you're doing this job, refund

job you're trying to do, what are the actions you can perform for that job? Two things I'm trying to do there. That's exactly what this is. And then we are I'm finding out the confidence level there then and there and then saying that, "Hey, I have seen 90% of the time most likely this is the queue I need to send it to." And I'm forwarding it to

that queue. If my confidence level is less than 70%, I'm uh sending it to the regular queue which they are currently going through. So, that is the way you need to have a confidence level. So, so you can use LLM for confidence level generation also. But, this is a a nitpick technique which I which you can use to do that. So, percentage of AI answers. So, where

do you get these answers from? History. From past 2 years, what have you done? How you did the interaction? How you manually solve this? AI is making it what? Automated. That's it. That's it. That's the only thing. It's providing LLM. Patterns are all coming from there. Now, main thing is what makes the difference from the vague XAI? Provenance. You should be able to prove. Path trace, evidence

chain, citation, and human review. If you do all five of them, now the last act comes in. We're going to talk about the last tech now, which is production patterns. So, you are all We are all interested in what? Production patterns, yes? We are all here to learn what is happening in production right now. So, let's talk about these patterns, you know? And before we do that,

these are the current stack which we need to do auditable. These are the five things if you do it through graphrag, you can do this. You should be able to do the act five. So, act five is move from concept to These are the five patterns and I'm going to talk about all of them. What are those patterns? Number one is hybrid retriever pattern. We have all

seen this pattern. It's like, you know, retrieving the pattern but with graph rack. You need to do that. Evidence first orchestration. You have to have a evidence then you orchestrate on that evidence. That's another problem which is there. And entity resolution and colonization. If once I talk about the third one, this is the 90% of every customer's problem is. How many of you have duplicates? Duplicate problems,

you know? How many have bad data? And we are saying AI is the problem. No, it's the it's your it's your house is not clean. You are saying that AI is not cleaning my house properly and then putting in the right place. It's not clean to begin with. So, that is the first entity problems are there. We need to resolve colonization and then it has to be

in a format which which like the way you want roll up to be done. Explainable envelope. You should be able to explain it and save fallback and escalation. These are the five patterns if you apply in your project, you know, everything which you're working on. Okay, let's talk about the first pattern. Hybrid retrieval pattern. We all know about what hybrid retrieval pattern is there. What basically it's

a lexical vector and graph search. And we'll do this this example right now. But basically, why it matters is exact match plus cues and policy changes are they're all coming in to solve the puzzle for us. So, let's do this together, okay? So, I'm just going to go to our example here and by the way, this is interactive so you're going to see this in action. And

I created an assignment just exactly for this reason, all right? So, in this assignment, we have to choose between all three, which one to pick. Now, you as an architect has been given a choice which one to pick out of this and a lexical retrieval I'm trying to do if somebody's asking you exact keyword In that case, you need to have a lexical search in place. If

somebody's asking for vector retrieval, that means paraphrase the paraphrase question, natural language question, then it's a vector retrieval is there. That means K nearest neighbors. We are trying to get LLM to solve for us. And graph traversal is for depend upon the relationship problem, then use graph. Can we pick either one of them and to solve solve my problem? No, you can't do that. So, this is

the assignment for the prompt. So, I have a prompt here. So, the reason I have a prompt here is go back to your office and run this prompt. First thing. So, what would you retrieve and and the from graph traversal? So, I'm going to do the same thing, refund, and I put this information in and let's do that for the chat. I'm going to do it here.

Based on this now, this is doing the same thing which you were just discussing right now, which is which is lexical. If somebody's asking for authoritative answers, like SKU, product ID, numbers. Now, where is this product ID coming User utterance. User utterance, we are able to do that. Now, if somebody's asking for this data, we need to do lexical search for that. Vector search is for intent.

Can they still get the money back? That's the lexical part which is coming in. And graph traversal is how I traverse the graph to get the answer. Right? And why the single retrieval fails? Because lexical can only do one So, we need to combine all three things to solve this problem. So, step number one, lexical. You know, lock the rules for this product only, find out the

edge cases which are there in the intent which is coming in and then apply the graph evaluation. Now, evaluating the graph based on that we creating an evidence assembly and then coming up with the policy for us and we are making a deterministic approval denial and not do that, you know, and they they might be conflict conflicting or incomplete information might be there. If there is a

conflicting information, what are we going to do? We're going to escalate it to the human. And if you follow this process, so anything with SQL queries vector is for case comments and these are coming in to solve this problem. Now, you say, "Rohit, I don't have you I don't have you know, this I have a banking system." Same thing on the banking system. You know, is this

wire transfer allowed if the customer is high risk? But the transaction is below the manual manual, you know, review threshold. So, we need to find out what are the lexical things there what are the vector things there and graph things there, combine all of them to get the final strategy. Same thing on the health care side. Now, I'm not going to run through manufacturing and other ones,

you should do that on your own. Insurance is also I have added the insurance also here, but I want to you to look at the the prompts. And so, these are the important prompts and architect tasks tasks are all here, you can look at that in more detail, but now I have the prompt for us to look at. We already discussed this, so I need to go

to the prompts now. Yeah, this is a prompt. So, retrieval mode. So, when I'm in the retrieval mode, you need to retrieve this data and then find out what this data is for. Okay? So, I suggest do all these prompts. This will get you a better how you're making a particular decision to do certain things. If the question is, can this customer receive receive an exception for

us exception for the final product per se purchase. Can you do that? Yes, so this one is what? This one the reasoning is that you need to have graph and all of them in this case in this case. Now what is the fault code e means in the asset? Now in this situation you definitely need to have exact fault code Now do I need to have graph

search in this case or optional search? No, you don't need to have this. So this is what is called a determinism. Now somebody ask you a question is taking a long time. Who was saying that? Taking a long you're saying long time. You need to do exactly this what I'm doing here. Okay, you need to have determinism find out predict the determinism and find out do I

need to do all of them? So only do one the one which is determinant, you know, which which plants are most affected by the supplier this week? This is the only one which is there which is graph is the only one you need to do in this case. Make sense? Correct. Yes. So what determine that? Because it is a very difficult. So From the history. From the

history. Yes, you have see what this is what happening what's happening. You say oh AI is new. Not really. You have 5 year old data. You know the history, you know how you acted on when you were successful doing Are we analyzing that and based on that you're making a decision? Because you did that same thing manually sometime, no? So you have this decision in place and

this just by doing this exercise you'll be able to do this. Make So great question like he's asking a very good question like you know we say hey designing for retrieval workflow. Now this is another one good to know. By the way these are architects. These are actual architect questions. You going to ask me. So I'm answering these questions because you guys asked like before the meeting

you know and then discussing them right now. So decision system that must be explainable, reversible, and auditable. Okay? That's the main thing. So, you are able to decide on the intake Intake is coming in refund refund exception is there. Now, based on this exception, now you are asking the query decomposition. What are the binding policies? Now, this is if you don't do you just get the query

and then send it to the LLM. Is that a good thing? It's not a good thing. So, before you send to the LLM intent, you convert it into questions. Now, why am I converting into questions? Can anybody tell me only that part? Why I convert into questions here? Determining what to belong to which category to identify those category. That's one thing. Yeah, that that's one thing. But,

the other thing is that if you have a question, you have an answer. Yes? Then, if you have a question, what you can do? You can do inverted index. This chunk answers this question. This chunk answers this question. This chunk answers this question. These two chunks answer the same question. You see, you have already done the inverted index on that for the five past five years. Now,

you get it fast. Somebody here having problem on making it fast. I have made it fast for, you know, 500 documents and then it's very fast. By the way, when I'm doing it, the person is talking to the other person and I'm getting the answer. Like, you know, anybody has seen the interview like, you know, you giving an interview and somebody's getting an answer without the other

person knowing? There are some tools like that. You should not use it, but for your client, you should use that. But, it's Is it possible? Yes, it's possible. So, people miss out you know, this perspective. So, why we are doing that? So, now I select which one I need to pick out of this. And yes. These questions like the sub questions Yeah. That would be given by

the another part No, user is sending an intent. Big big big text they are sending. Okay? When they send the big text, I need to decompose into what questions I need to bring in. If that said, decomposition is that you use it? LLM, yeah, you can still use LLM to do that using the past data which you already have. So, you can get that data in a

much better shape and then now you have you know what things are coming in. Now you send it to the right place. Now you create the evidence card and decision tree and be able to look at this data. Makes sense? Now you do the vector intent. Now this is what I'm doing. Final sale, that's a lexical in Germany. That's a lexical that may exact match I need

to do. Vector, can they still be given the money? No, that's a vector search. You know, you know, vector search which is the edge case search is there and graph is the for the traversal. And if I join all of them and then when I join them, that means what? Like I'm combining all the chunks and getting the answer for me. Yeah? So, that is one thing

which I'm doing here. So, this is the JSON format I was talking about, you know? This is the evidence. This for this customer, for this order, for this reason, this is the policy which is there and I have a confidence of 99% this is correct. If it is 99%, now you have much better confidence, yes? It's not hallucinating and this and people say it hallucinates. Yes. If

it is 30% it is hallucinating. So, we need to find out the percentage. Now I can I can actually come in and solve for this. Makes sense? So, that is another prompt I would suggest you should run to really understand what's going on. The third one is compare the vector and hybrid For for all these things you can do to really understand what's going on with Now,

when you run this explainability and other aspects of it, now you get a better way of saying the precision. You want more precision? You do this one. You get more precision. Explainability is more in this one. Policy is very high. Risk of hallucination is very high here and this is low here. Audibility is strong and high. You got the idea. That's the way guys. I think we

talked on this one also. Uh let's complete the loop and look at the last one. Industry specific. How many here have industry specific hybrid search which is coming in? Now you will be able to get the industries for your industry. You will be able to look at what things are coming in. Because you want See, nobody's asking you not to use ChatGPT or and any LLM. Nobody

wants you saying to do that because it's not like it's illustrating. It is illustrating right now. Not right now. What it is doing here you need to give the proper Proper input. Garbage in, garbage out. And that's what's happening. User intent came, send it to LLM. Give me the answer. No. That's not the right thing. You get what questions you are really looking for and then sequence

it and do that. And that is what is done here in the health care. Now the health care question is, does this patient qualify for for the authorized prior authorization? What things are lexical, vector, graph, and common? Is this useful for you? Can you take this and use it in your project? Yes, no. You get the idea. Same thing is doing the banking side. What kind of

question is there and what things are working? Insurance side, manufacturing side, supply Can you put your company and get this for this prompt? Is this useful? Say yes. Yeah, it's useful for you. Okay, great. So that is what you gain because I want to make it like very clear for us why why Rohit is spending time on this because I want to give you tools. You apply

right now in your project. Like tomorrow you apply this. Now why wait for it, yeah? So this is what you need to do for graph and other features. So targeted questions are where are the exact match vocabulary coming from? You know, what are the users fuzzy fuzzy languages there, you know, and vector surgery for the fuzzy language. And once we build this in, now we get the

lexical perspective to build this in. Okay, that's the pattern number one. All right, we discuss the pattern number Pattern number two is evidence first orchestration. This is the another pattern which is used. Now, this one is talking about the prompt which are coming in. Retrieve first and generate second. You retrieve information first and generate second. What does it mean? What What it means the system should assemble

evidence before answer is generated. You have to get the evidence and then the answer is generated because it's possible it's hallucinating. A lot of people are saying hallucinating hallucinating is five six people are saying that. Collect the documents, collect the graph, collect the policies, and pass the evidence bundle to the LLM for open-ended prompts. And now you get a proper answer for it. And once you do

that, you're able to build it properly. Let's take a look at this for a second. This is the second pattern which I suggest to us to use. So, this is Why this pattern is important? You will be able to gather the evidence, assemble the facts, evaluate the completeness. Now, if you don't evaluate the completeness, what will happen? Just give it that you to the user. That's wrong,

you know, so that we don't want to do that. The core principle here is detect intent and risk first. Intent, what is the user intent? What the user wants to do? And then retrieve and then assemble and then check for conflicts and gaps. People miss this People just miss this one and we are not doing this act activity and only generate the answer and escalate if there

is a human issue going on. Doing this practice just 30-minute practice you did that we just spend like 30, you know, 40 minutes with each other. You know what practice to use to do this this perspective. Now, these are the questions to ask. If you know what questions to ask, what evidence you which systems are there, if you ask this question for e-commerce refund, now we'll be

able to you will be able to get you will be able to get, you know, evidence for the record, evidence that must be gathered first. Now, what does that mean? Evidence must be gathered for anyone. Can you tell me what do you think this sentence means? Well, it's all that context related. Yeah. So, so what's really happening is that user is on the chat or on the

phone. If you don't if they don't give you their order number, can you really work on the something else? Like, you know, can I get a refund for for my shoe? No, I can't, sorry. So, you need to get this evidence first. What's happening is before the evidence we are sending to and that is it's coming back to us, sorry, it's giving us garbage back because it's

still garbage in, garbage out. It'll give that, but we miss this portion out. Second is system and sources to check first. Now, after I get the order, then I check the order management system, product catalog, policies, and other ones here. So, that means this is a sequence. If you don't follow this sequence, what what is what is happening? Illumination is going to happen. You know, we we

are we will not be able to solve this particular problem given to us. And that is what we are trying to What are the possible conflicts? Product marked for final sale in one system, but in not in another one. Now, this can happen through parallel paths because now you're doing the reinforcement learning, you're going through parallel path to get the answer. Now, you got conflicted chunks. Now,

in the LLM prompt, you write down, "If I get conflicting chunk, what do I do?" Huh? Human. Low confidence. Make that confidence low, less than 70% or 60%. Because it's low confidence, you have a pipeline, let a human handle it. AI is not to solve all the problem. It's not for like, you know, every problem in the world, but it can solve for most of the problem

and that is the way to do that. Now, safe answer condition. What are the safe answer conditions are there? When to narrow to escalate and and why prompt first answering is dangerous. You know, that is what we are trying to do because the model may sound convincing justification, but it's wrong I think you got the idea. I'm not going to do for banking, but if you follow

these steps gather evidence. And this is sometime called a claim check. Hey, do you have every in the whole information before you answer any question? If you don't do that, you're going to be hallucinating this one. Okay. So, but I have provided for every industry including manufacturing industry to look at. Insurance industry is also there for you to look at. Supply chain also added here, so you

get get you you can look at it on your own. So, what it is doing is what what do you think of this answer? That's not the right thing to do. What evidence do we need before we can answer? What evidence you are defining an evidence and working on top of it. Evidence first orchestration pattern. Classify the questions. First bring in the questions. Identify the required Get

the evidence and then retrieve and then assemble and then and then generate the evidence. Based on that, you escalate if you need to. Once you do that, you are in a good shape. You know, um bad design we're going to do all the bad things there, but these are the prompts which are there. I'm not going to do all all of them, but you get the idea.

For each question, minimum evidence required, systems to process and possible evidence needed for each one of them. Can you Can you for this transaction? So, can you put in this your utterance and get it get your prompt ready to go? >> [clears throat] >> Yes. So, some use cases are Yeah. If I have to generate user story from epic given epic I have to generate a user

story using it. That's not a graph right problem. You don't need to solve everything through graph right now. So it's like you you are more you know vector search problem is there like you just you're you're exploring based on the vector search. But within that if you have entities defined, that's where the graph right will come in because you want to make sure these entities are getting

matched properly and then you have a parent-child relationship hierarchical relationship is there. So parent should be there before child can happen. You know, those things you have to put in place. But but you have a good question. So that's So these things design and evidence first orchestration flow. If you need to define define So Rohit, why did you create this prompts? Because we need to have prompt

because otherwise you don't know. You can ask chat GPT, I want to solve evidence. What it will give me? Junk, yes? So this is where the prompt really comes in place. So let's just run for this one just to get you perspective on this. So if you do this, it will get you escalation logic, intent classification. This is what we need to do. We need to understand

what the user really looking for. Extract the entities from the intent coming in and then determinism parallelized determinism we need to do to go and get the contracts. Graph traversal we did. Now we created the JSON from we already discussed the JSON before and then conflict Okay. Policy versus exception. If there's a conflict there. Global versus regional, that's a conflict there. So we need to find out

these conflicts and resolve the strategy what we need to use and give the determinism and then work on top of it. Just by doing this pattern now you You compare the evidence and you know, prompt first versus evidence first logic to really really being being the perspective for us. And most of the people are doing prompt first. If you have a prompt and you're solving this without

the evidence, this is what will happen. So, decision A prompt first is low. Like you the the the confidence in factual defensibility is low. So, audibility is low. Hallucination is high. And that is what you are said that hallucination you need to protect. How do you do that? Just for run this prompt and you'll be able to get the perspective on this. Okay? Now, you can do

the same thing, adapt the prompt for one concrete question. So, just like this one why we have this con- concrete question is there. Now, for a given industry, how do we deal with this? Like, you know, minimum sequence of required is product classification, order. For If you are e-commerce, you need to And system to check. And escalation trigger. Banking is the same thing. Now, you got everything

ready to go. Okay? Now, that said, this is great. Now, the question comes is evidence first orchestration is done. Now, entity resolution conalization. Now, this one I would say is the most problematic area. Clean entities broken rag is really coming because of this reason. This is 90% of the problem. It's not It's not the code. It's not the AI. It's the dirty entities, wrong entities, wrong joints,

and wrong roll ups coming in. That's what is really causing these problems for us. So, somebody wants to do trend analysis. I had a I had a project. People the the the product manager said, "I want to do trend analysis." If you need to do trend analysis, what do you need? You need roll up data. You need fiscal period data. You need to pre-configured all this data.

You cannot do that just by raw data coming to you. So, all those have to be pre-fetched, pre-configured, and ready to go before you can do that analysis. So, that is you have a different tool to do it. So, if you understand the problem, then you can work on it. So, now you know if the data is not clean, we had to actually create new fields as

a foundation because the the the semantic data is missing. So, roll up data is missing, so you can't really use that data to begin with. So, that is where this this is coming in. So, this is called as graph rag, you know, can just going to spend time on this. This is a very important thing to understand for everyone. So, why is this there? Duplicated. How many

here have duplicate problems? Inconsistent names across different systems. You have same entity, different different names are coming in. Fragmented across different system. Version Versioning is also poor between them. Linked data is also poor. Wrong joins are coming in. Graph rags are bringing broken failed joins are coming in. Misleading explanation is coming in. Would it give me the right answer? It Who's at fault? Is it graph rag

at fault or LLM at fault? No. It's our design, how we design the system. That's what is at fault. So, what we need to do core principle wise is resolve aliases. Different name in different entities. You need to work with canonical data model. That's number one. Very important. And then because we know these entities, remove the duplicates. Now, I'm doing it If I don't do Some customer

is calling. Customer is calling and currently the what we do is we the user goes and and find out the customer name they put in. They see four customers showing up. And then they pick one of them, they validate that's the right customer, and then use that. It's working as of now. But how do AI do How do AI pick the right customer? Somebody's asking that customer,

which customer should I pick? Which account should I pick? And because there are duplicates there, I don't really know what's really going on. So, those things are a problem. Canonical IDs are missing. The, you know, stable what's what's the what's the canonical ID Uh those are missing. Version entities are missing. For all products and policies are missing. You're getting a new policy coming out that in in

the in knowledge article, the old policy is also effective as of now. It's not like it's not effective. These are effective dated policies are there. This policy will go till end of May. Then the effective dated another will go. You see where I'm going with this? You need to have these perspective for the assignment. So, this is the assignment for us. The assignment is you have you

need to design which entities are likely to be ambiguous and duplicated. So, ask these question, you know, canonical ID and what you need to do for e-commerce solution. Can this customer receive an exception refund? What are the ambiguous entities are there for customer across the system? Alias entities, customer appear as email in CRM, loyalty ID in e-commerce solution. So, what is my identity resolution look like? That

is what we are gaining from this and and we need to build that perspective. Now, at the end, I'm not going to go through all of them, but you get the idea here. Now, for architects for us itself, we have created the prompts here. I would suggest look at these prompts. They'll help you define what are the problem which can happen, let's say, for your e-commerce solution.

Okay, let's do this one for a second. And this is there in most of the companies. It's not like it's not like just one company. I've seen this in the most of the company you have this problem going on. So, now you can see from the e-commerce perspective, ambiguous entities are always customer, order, and policy, and region. Banking system has a similar kind of thing. So, if

you know these are the canonical IDs are there and bring that relationship, they'll will able to back get you a better answer for yourself. Make sense? All right. The next one is explainable envelope. Every answer carries its own proof package. I already talked on the JSON object which is there. If I have a proof, why this matters because production you should be able to have audit coming

in to solve the perspective for you. That's the reason this pattern is there. So, explainable envelope. You create an envelope. Where is this answer coming from? So, the questions you are asking is what? this answer coming from? What is the evidence for this? How confidence are you with the answer is coming from? If you are able to explain this principle, where is the source is coming from?

Now, you are able to get from the e-commerce perspective. Now, proof. Source policy documents are used. Order is referenced. Now, if I have this perspective, what is the proof? What's the source coming from? What's the graph there? Policy there? Confidence there? We are able to work on So, that's what the pattern number four is. I'll talk about the last pattern and then we'll do one very important

thing to complete the play for us. Save fallback escalation. I think we talked on this one. So, we need to always make sure that there is a fallback and escalation path is there. If you have a confidence low, then you should do that. Go through the assignment. You'll get better understanding. All right? So, let's talk about another thing which is regulation and governance. I want to spend

time on like 5 minutes on this. Very important. Don't miss this thing because this is coming. We all need to be prepared for it. You need to be transparent. Identify the risk. And why? Why? The because you will you want to be away from lawyers, you know? Lawyers are good if you're working on a patent. It's fine. They're not good any other way. So, so what we

need to do is the governance is rag is not regulation by itself, but it gives you architecture for transparency and traceability. That's the main thing which is there. EUAI Act. EUAI Act is there and you can actually see it's it's a it's a uh 2nd of August 2026. I think that's getting into effective. Risk-based obligations matter more for generic enthusiasm. So, so that's where the risk is

very, very important. You know, we need to be able um protect ourselves from this risk. Practical reading is if the answer affects the decision, compliance, and we should be able to improve the answer based on this. That's the That's the most important thing we need to know, and Graph RAG really helps in doing linkage and visibility for us. That's the reason Graph RAG is really useful. EU

is coming up with this. So, I suggest look into this. I would say uh this is going to help you prepare. Why the the use cases become more sensitive under risk-based governance lens. You know, same use case, you want to make sure from the e-commerce system, can the customer receive a refund exception? Now, we need to look at the financial outcomes, contract interpretation, and customer rights, and

and dispute handling. How do you handle the dispute? These are the problems which are there. These are sensitive problems, you know? And what is affected is customer financial outcome is affected. And what's the transparency goals for yourself? Based on the transparency goal, now you build to really get the product policy by reason you created. Now, you have Graph RAG to really support this. Okay? So, I suggest

look into this. It's going to help you understand how the EU law is working. And then the last one is NIST AI RMF. So, govern, map, measure, and and manage. There are four things it does. So, what is the governance means? You are looking at looking at defining the evidence policy. Based on that, you only do the approved sources, and human is reviewing all the thing which

is low threshold, which is coming for us. So, restrict evidence policy and trigger for review as needed. So, this is all governance perspective from map. Map, what is map means? You're trying to come up with entity relationship and find out the categories which are risky. And then build a build your perspective on that, and and you can use the graph rack for this purpose. Measure, you should

be able to measure groundedness, site citation. And and path is also added for this. So, this is another good thing we can we can build for our face. And then the last one is manage. So, what is manage doing? Manage the escalation. You have escalation there, and that escalation is for audits and, policy updates which are coming in. You are trying to do If there is an

escalation, how do you manage that escalation? Is this is the NIST perspective for that? I have an assignment of for us to do on this one. Let's take a look at one case for this. Does this model perform well? That's the question we are answering. Question answering. But what we need to say is how do we govern it, map its risk, measure whether it's trustworthy, and manage

it when condition changes. Uh That is the main thing which we are trying to do here. If you do this, so in interview also, answer this. Don't answer the first one, Because that's not even if you go for interview for AI, you need to be able to manage the risk and govern the risk. That's where the NIST really comes in play. So, what are the governance principle

for the e-commerce Governance will define which sources are approved for refund refund answers. Now, can you create a category for refund? Can you create a data category for How many here do that? Probably not. It is very simple. Create a data category for this product for this refund is there. Because you created a data category, now you can filter that category first. Who own the refund updates?

Who established the Map. What am I mapping, measuring, and and do that? And how is this helping is for for this for this case, all right? So, this is the way we can actually build our perspective and we can get the governance for us to work with. I think we already did the live walk-through for a lot of things, so I'm not going to do Act 5.

Uh we did a lot of things on on the on this one, but I want to Let's Let's do this for a for a second before before we move on on this one. So, Act 5 is a live answer which is coming in. So, can a customer receive an exception for the for for this period? Uh this is a revision, by the way. Everyone answer this question

before I show it, okay? Let's see how much we got out of this, yeah? So, end-to-end walk-through, what would you do first? Anyone, what would I do first? Question arrives. So, what do I do after question arrives, huh? Intend understanding, yes. Identify the entities and intend. Where Where do I need to ask the questions? What questions it's trying to get in? And look up the graphs which

is coming in. And documents are received from there. And then checks are applied. What are those checks? What are those checks? Policy? Policy checks, yes? And answers are generated and evidence is shown and confidence level of evidence. Now, at the end in the JSON object, and I don't have it in this, but create a text field of why you came to that conclusion. If you do all

these things with the flow, escalate if needed. If you provide that, the question arises, you're asking the incoming question, the question is asking refund, and then you do that, understand the question coming in, based on that entities are detected. Now we are just doing the same thing. Customer and all the Germany is detected in this case. Based on the entity which is directed, what do we need

to do next? Normalize that entity. Then basically product ID canonicalized entities we are trying to create here. Risks uh you know, wrong product policy is coming in. If it is there, then you do the look up for the for the paths. And then multi-hop system which you're trying to get to. And based on that, now we are able to come up with the answer for your policies

are retrieved. Based on these policies which are retrieved for German region, we are able to work on that policy. And then at the end, we do the relationship check is done. Is this product marked for final sale? So these are all the relationship checks we can do. Is allowing for this exception. Now the decision has been made with the policies coming for you. And then why is

this better for your results? And at the end you get the final generated answer. And based on that, you make a decision if the human needs to be involved in this. Okay? And evidence justification is done at the end. So 6 months later, if I have the same problem coming in, I should be able to go in, provide the evidence panel, panel, answer panel, evidence panel, and

governance panel. Remember we talked on this before. And now based on that, we have an escalation if there is any problem which is coming in. That's pretty much it from our side, I think. I hope you you enjoyed this session. >> [music] >> Oh.