How Intuit uses LLMs to explain taxes to millions of taxpayers - Jaspreet Singh, Intuit

Hi, I'm Jaspreet. I'm a Senior Staff Engineer at Intuit. I work on GenAI for Turbotax, and today we'll be talking about how we use LLMs at Intuit to help you understand your taxes better. So, I think, uh,

just to understand the scale,right? Intuit Turbotax successfully processed 44 million tax returns for tax year '23, and that's really the scale we're going for. We want everybody to have high confidence in how their taxes are filed and understand that they're getting the best deductions that they can.

So,

so this is the experience that we work on. So, uh, you go into Turbotax, you enter your information, then you go through what credits you are eligible for, and so on. And we basically help you expand onto how you are getting the tax breaks that you are, help you understand them better, and so on.

And,

and this is another example. This is basically the overall tax outcome. Like, what is your overall refund for this year?

Now, Intuit's genAI experiences are built on top of our proprietary GenOS. That's the generative AI OS that we have built as a platform capability. And it has a lot of different pieces that you see over here.

The key goal is that we found that a lot of the GenOS tooling that comes out of the box is not supporting all our use cases. We want to, most prominently working in tax, we are in the regulatory business, safety, security

is very, very important. So we want to focus on that. At the same time, we want to build a piece that a company at the scale of Intuit can use end to end, really large scale. So that's where GenOS comes in.

We have different pieces. There's on the UI side, which is the GenUX, and then there's Orchestrator. That's basically the piece where different teams are working on different components, different pieces, different LLM solutions. How do you find theright solution to answer theright question?

And Intuit calls the entire experience that we power through this Intuit Assist. So I'm going to deep dive into specific pieces that our team used to build out the experience for Turbotax.

So, as I said earlier,right, we have millions and millions of customers who are coming in. So we're trying to build a scalable solution that can work end to end. So on the slide here, I'm basically going to talk about different pieces that are powering the experience.

It's supposed to begin with the first iteration was the prompt tooling, basically a prompt-based solution to try and go through what's your tax situation going on. Let's take an example of what I was showing earlier, which was your tax refund.

So your tax refund has many constituents. These are your deductions, these are your credits, standard deduction, W-2 withholding, and so on. So we want to make sure that you understand all of that. So we built a prompt-based solution around it and worked from there.

The production model that we went with is Claude for this use case. Intuit is one of the biggest users of Claude. We had a multi-million dollar contract for this year as well. And you'll also see OpenAI over there.

So OpenAI is where we used for other question and answering. So you'll see on the slide, we're talking about static and dynamic type of queries. So static queries would be, you know, what I was showing earlier, that we know you are looking at your summary, you want to see what happened overall.

So that would be a static prompt. Think of it like a prepared statement. However, the additional information that we're gathering is the tax info when the user comes in. Now, dynamic query would be users have questions about their tax situation.

You know, can I deduct my dog? Well, you can't, but you can try. So things like that. That's what we're trying to answer more dynamically. OpenAI's GPT-4 Mini had been the model of choice until a few months ago.

We are now iterating on the newer versions. Of course, models change every year, every month, I should say. So we're trying to focus on that. Same for the dynamic piece. Again, another important aspect is, you know, tax information.

IRS changes forms every year. Intuit has proprietary tax information, tax engines that we want to use. So we have RAG-based and, of course, graphRAG-based solutions around it as well. So they help us answer users' questions much better. And one thing that we also piloted recently was actually having a fine-tuned LLM.

So we went with Claude because that's the primary one we are using there. And we stuck to static queries and we tested it out. And it does well. It definitely does well. Quality is there. It takes effort to fine-tune the model.

However, we found that it was a little too specialized in the specific use case. And one thing I want to highlight that I'll deep dive further on is evals. So you want to make sure that we evaluate everything we do.

You want to make sure what's happening in production. You want to make sure in the development lifecycle you're doing everything you need to do to make sure that you have the best prompts out there. And with that, moving on to the next slide.

So just summarize a little bit. You know, these are the key pillars that we have. I already spoke about some of them before. I want to highlight here that the bottom part in this slide, actually, the human domain expert.

So Intuit has a lot of tax analysts that we work with. Of course, there are owner that work with us, decoding IRS changes year over year, making changes, and so on. So they are the experts that provide us the information, make sure the evaluations are correctly done.

So we have a phased evaluation system. We have manual evaluations initially in the development lifecycle. And another thing that we have done is actually using the tax analysts as the prompt engineers. So that allows us, the folks in data science and ML world, to actually focus on the quality, defining the metrics, making sure we have a nice data set that we can iterate on and test on as we go along.

As I said, models change. We want to try out different models. We want to see the loss change in the IRS, say tax year '23 to '24, what happened. So those changes, we focus on that. And human experts bring their expertise and are able to both help with prompt engineering and get the initial evaluations done.

That then becomes the basis for automated evaluations. LLM as a judge is what we use as well. I'm going to talk a little bit more about that.

I'm going to take going back then to what I was telling earlier about the Claude 3 Haiku and fine-tuning. So fine-tuning, as part of GenOS, we built out a lot of tool sets. One more thing that we want to do is support fine-tuning.

So for our use case, we actually stuck to just fine-tuning on Claude 3 Haiku powered by AWS Bedrock. And the goal there was that we wanted to see if we can actually improve the quality of responses. Biggest driver, of course, is fewer instructions needed once you have fine-tuned a model.

We want to make latencies are a big concern. So we want to see if we can squeeze down the prompt size and at the same time keep the quality that we need and keep going there. So this is roughly what it looks like.

We built out, we have different test AWS accounts, different environments that are provided by the platform teams that we work with. We look at the data and brief nod to regulations, 7 to 16 regulations. So we only use consented data from users, make sure we're on theright.

And just to double down on the evaluation part,right, you want to evaluate everything. So the key pillars are accuracy, relevancy, and coherence. So we have both manual and automated systems. We also have broad monitoring automated systems. Basically look at sample data on what the LLM is basically giving real users in real time.

And for this tooling that we've built out here, LLM is a just constant in the auto eval side. We've also developed some tooling in-house to basically do some automated prompt engineering. And that actually really helps to update our LLM as a judge.

Basically, LLM as a judge operates on top of a prompt. It needs different information. It needs some manual samples, which are the, like, golden data set. We use AWS Ground Truth for that and take on that. One more thing that I want to highlight here is models.

So we made the move from

Anthropic Claude Instant to Anthropic Claude Haiku for the next year for tax year '24. And that takes some effort. And the only way it's possible is because we have clear evals in place so that we can test out whatever we are changing.

And model changes are not as smooth as you would think.

These are some more details on what we're talking about on the automated evals.

As you can see, the key output is we want to make sure it's tax accurate. That's the main thing we want to aim for and focus on that. I'm going to move on here. So let's talk about some major learnings that we have.

So the contracts are really expensive. And the only way they are slightly cheaper is if you have long-term contracts. So you are tied into the vendor. So it helps to have strong partners on the vendor side who work with you to help iterate, help improve.

And I think I was in this conference last year, and this was one thing called out then as well, that essentially vendors are a form of lock-in. The prompts are a form of lock-in. It's not easy. And we found out it's not even easy to upgrade this model from the same vendor going into the next year.

So we want to focus on that. Another thing I really want to highlight here is the latency. So LLM models, of course, they don't have the SLAs of backend services. We're not looking at, you know, 100 milliseconds, 200 milliseconds.

We're talking about 3 seconds, 5 seconds, 10 seconds. So as the user's tax information comes in, maybe they have a complicated situation like me, that, you know, they own a home, they have maybe something in stocks, and they're trying to file.

They have, their spouse have their jobs as well. A lot of things going on. So the prompts really balloon up if you're trying to figure out the outcome. And as you go into, you know, tax day, everybody's trying to file on tax day,right?

April 15. So latency really is shooting through the roof. So we design a product around that. We want to make sure we have theright fallback mechanisms, theright user design, product design to make sure that the user experience is seamless and useful.

We want to make sure that the explanations are helpful more than anything else. And I think I covered all the other places, but once again, I cannot say that enough. Evals are a must to launch. Focus on evals.

Make sure you have clear guidelines on what you're building. Have clear golden data set. I've heard that from other talks as well. That's really a key point.

That's all. I'm going to pause here for questions.

If you're going to be asking questions, please come to one of the microphones so that we can capture the audio. Thanks.

Yeah, hi. You said evaluate everything,right? But with GenAI systems, there could be, you know, very small changes,right? You make a small change to a prompt, and evaluations can get very expensive or slow down your whole sort of development process,right?

So maybe could you dive a little bit deeper into, like, when do you bring in different types of evaluations? Are there anything that you just say, we ran some regression tests and it looks fine, so you launch? Or do you always go kind of with the expert?

Sure, sure. Thank you for the question. So just to reiterate, so the evaluations are different types. I would say when we are in the initial phase of development, we are looking more on the manual evaluations with tax experts so we can get a baseline in place.

Then as we are tweaking different things in the prompts, that's where auto evaluation comes in. So we basically take the input from the tax experts and use that to train a judge prompt for the LLM. So that LLM is once again expensive.

We go for the GPT-4 series until recently on that one. And then minor iterations we can do with auto eval. So we have clear understanding with product. We want to make sure that the quality is there. And maybe once we have major changes, for example, we went from tax year '23 to tax year '24, then we definitely reiterate.

If the prompt changes a lot, we would go for manual evaluations.

Thank you for the technical deep dive. I was more interested in the product side of it. We also do taxes. So I was curious, what are the kind of LLM interactions that the users are having? Like, what are the kind of questions they're asking?

Is it more like critical parts of the workflow or more like what are my tax?

Sure. So we have question answering for all types of questions. That includes both the product question as in, you know, how do I do this in Turbotax? Or also their tax situation. So for example, I paid the tuition for my grandchild.

Can I claim that on my taxes? So things like that. So our goal is we have different teams going after different pieces. Our goal is we want to answer all of these questions. And accordingly, different types of questions need different solutions.

And that's where maybe I would reiterate, go back to

here.

So,right. So this piece here, planner. So essentially this is where it comes in. We want to make sure when the query comes in, we understand what the user is trying to ask. And then we have different kind of solutions for different kind of questions and go through that.

Thank you.

Yeah, hi. So you mentioned about the evaluation. So one quick question, like, so Turbotax, I'm sure it involves a lot of numbers, the answers. So how do you verify those numbers in terms of the evaluation? Let's say the actual tax number is 11,235.

And if it's something like 11,100, so it's quite difficult to catch this with a manual evaluation or with an ISO.

Yes. Yes. Thank you for the question. So that's the key thing that we work on. So Turbotax, of course, has a tax knowledge engine that we built proprietary in-house, managed over the years, built and developed. And that's really what's providing these numbers.

The tax profile information is all coming from these numbers. We are not having LLMs do the calculations at all. We're basically using the ground truth that is already existing in our systems as the numbers that we see. And we have safety guardrails.

Maybe this piece here I would probably call out. We have a lot of safety guardrails on what's the raw LLM response. Make sure, you know, we are not hallucinating numbers before we send to the user.

Got it. So the data is coming from the tax engine itself. But when you formulate the final explanation, the answer itself, so how do you make sure that the numbers that are actually in the final answer are, you know, that's coming from data?

So basically we have ML models that are working under the hood as part of the security aspect that you see here. That basically makes sure we did not hallucinate any numbers that we built up.

Got it. Yeah. Thank you.

Could you give an overview of how you use both just a traditional RAG and graph RAG, like a hybrid in your workflow?

Sure, sure. So.

And sorry, one more question is, now with the new model Claude 4 coming out, do you think the fine-tuning might be getting easier or needs needed?

I'll take the first one. So graph RAG, we've definitely seen better response, better response quality with graph RAG. Even more than that though, I think for end user helpfulness, getting personalized answer is the key piece, I would say.

Graph RAG definitely outperforms regular RAG. And what even more outperforms is personalizing the answers. And to your second question, we are constantly evaluating the models. This is really the time that, you know, April is just behind us. We are trying to look at what new things we can do.

We also have some in-house models that Intuit trains and develops. So we are constantly evaluating. And I don't have an answer now what we'll do for the next tax year, but yes, we keep working on that.

You mentioned you have different situations, tax situations, and you come up with an answer. So if I describe my situation, it's complicated and it comes up with an answer. Is that answer being generated using the LLM or is it going back to the tax engine?

And how do you explain how you came up with that answer? And I assume there's going to be a lot of legal challenges to a wrong answer.

Right,right,right. Absolutely. I mean, Intuit focuses heavily on legal and privacy controls. So the solution for this one,right, what we worked on here, this is specific, this is more of the static variety of questions. So once again, what I was saying earlier, the inherent numbers are coming in from tax knowledge engine.

And we have tax experts who actually crafted these prompts. So they are specifically tested for each piece that you see here. So that's basically when we do the evals, we make sure it doesn't happen what you're suggesting.

Okay. Great.

Thanks.

Thank you so much. What a great talk.