How Intuit uses LLMs to explain taxes to millions of taxpayers

[on-hold music] 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, well, help you understand your taxes better.

So I think, uh, to... just to understand the scale, right? Uh, Intuit TurboTax successfully processed forty-four million tax returns for tax year '23,

and that's really the scale we are going for. We want everybody to be-- have high confidence in how their taxes are filed and understand them, that they're getting the best deductions, uh, that they can.

So, so this is the experience that we work on. So, uh, you go into TurboTax, you, uh, enter your information, then you go through what credits you are eligible for and so on.

And we basically help you expa- uh, expand onto how you are getting the tax breaks that you are, help you understand them better, uh, 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 OS that we have built, uh, as a platform capability, and it has a lot of different pieces, uh, that you see over here.

Uh, 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, uh, safety, security, uh, is very, very important, so we wanna focus on that.

At the same time, we wanna build a piece that a company at the scale of Intuit can use end-to-end at a 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 the right solution to answer the right question? And, uh, Intuit calls, uh, the entire experience that we power through this Intuit Assist. So I'm gonna deep dive into specific pieces that our team used to build out, uh, 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.

Uh, of course, to begin with, the first iteration was the prompt tooling. Uh, basically a prompt-based solution to try and go through, uh, 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 wanna 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, uh, for this use case.

Uh, Intuit is one of the, uh, biggest users of Claude. Uh, we had a multi-million dollar contract for this year as well. And, uh, 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, uh, 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, uh, overall, so that would be

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

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

We are now iterating on the newer versions. Of course, models change every year, uh, every month, I should say. Uh, so we're trying to focus on that. Um, same for the dynamic piece again.

Another important, uh, aspect is, you know, tax information. IRS changes forms every year. Uh, Intuit has proprietary tax, uh, information, tax engines that we wanna use. So we have, uh, RAG-based and of course GraphRAG-based solutions around it as well.

So they help us, uh, answer users' questions much better. And, uh, one thing that we also piloted recently was actually having a fine-tuned LLM. So, uh, 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, uh, it does well. Uh, it definitely does well. Uh, quality is there. Uh, it takes effort to fine-tune the model. Uh, however, we found that it was a little too specialized in the specific use case.

And, uh, one thing I want to highlight, I'll deep dive further on, is evals. So you wanna make sure that we evaluate everything we do. Um, you wanna make sure what's happening in production.

You want to make sure in the development life cycle, you're doing everything you need to do to make sure that you have the best prompts out there. Uh, and with that, moving on to the next slide.

So to 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- At the bottom part in this slide, actually.

The human domain expert. So, uh, Intuit has a lot of tax analysts that we work with, uh, of course, that are on our-- uh, that work with us, uh, decoding IRS changes year over year, making changes and so on.

So they are the experts that provide us the information, uh, make sure the evaluations are correctly done. So we have a phased evaluation system. We have manual evaluations initially in the development life cycle.

Um, 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, uh, making sure we have a nice data set that we can iterate on and test on, uh, as we go

along. As I said, models change. We wanna try out different models. We wanna see da-- uh, the laws change in the IRS, say tax year '23 to '24, what happened, uh, so those changes, we focus on that.

Uh, 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.

Um, LLM-as-a-judge is what we use as well. Uh, I'm gonna talk a little bit more about that. Uh, I'm gonna take, uh, going back then to what I was telling earlier about the Claude 3 Haiku and fine-tuning.

So, uh, fine-tuning, as part of GenOS, we built out a lot of tool sets. Uh, 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, uh, the quality of responses. Uh, biggest driver, of course, is, uh, fewer instructions, uh, needed once you have fine-tuned a model.

We wanna make su-- uh, latencies are a big concern, so we wanna see if we can squeeze down the prompt size and at the same time keep the quality, uh, that we need and keep going there.

So this is roughly what it looks like. We build out, uh, we have different test AWS accounts, different environments, uh, that are provided by the, uh, platform teams that we work with.

We look at the data and, uh, brief not to regulations, uh, seven to six-- uh, 16 regulations. So we only use consented data from users, uh, make sure, uh, we're on the right.

And, uh, 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, uh, automated systems. Basically look at sample data, uh, on what the LLM is basically giving real users in real time. And, uh, for this tooling that we've built out, uh, here, LLM-as-a-judge comes in, in the auto eval side.

We've also developed some tooling, uh, in-house, uh, 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.

Uh, it needs different information. It needs some manual samples, which are the, like, golden dataset. We use AWS Ground Truth for that, uh, and take on that. Uh, one more thing that I want to highlight here is, uh, models.

So we made the move from, uh, uh, Anthropic Claude Instant to Anthropic Claude Haiku for the next year, uh, for, uh, 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, uh, whatever we are changing.

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

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

as you can see, the key output is we wanna make sure it stacks accurate. That's the main thing we want to aim for and focus on that. I'm gonna move on here.

So let's talk about some major learnings that we have. So, uh, the contracts are really expensive, and the only way they are slightly cheaper, if you have long-term contracts.

So, uh, you are tied into the vendor, so, uh, it helps to have strong partners on the vendor side who work with you, uh, to help iterate, help improve.

And, uh, I think I was in this conference last year, and this was one thing called out then as well that, uh, essentially vendors are a form of, uh, 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 to the next year.

So we want to focus on that. Uh, another thing I really wanna highlight here is the latency. So, uh, LLM models, of course, they don't have the SLAs of back-end services.

We're not looking at, you know, hundred millisecond, two hundred milliseconds. We're talking about three seconds, five seconds, ten seconds. So as the user's tax info-- uh, 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, uh, if you're trying to figure out the outcome.

And, uh, as you go into, you know, tax day, everybody's trying to file on tax day, right? April 15th. So, uh, latency really is, uh, shooting through the roof.

So we design a product around that. We wanna make sure we have the right, uh, fallback mechanisms, the right, uh, user design, uh, product design to make sure that the user experience is seamless and, uh, useful.

Uh, we wanna make sure that the explanations are helpful more than anything else. And, uh, I think I covered all the other places, but once again, I cannot say that enough, evals are a must to launch.

Uh, focus on evals. Make sure you have clear guidelines on what you're building. Uh, have clear golden dataset. I've heard that from other talks as well. That's really a key point.

Uh, that's all. I'm gonna pause here for questions.

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

Yeah, hi. Um, you said, uh, evaluate everything, right?

Right.

But, uh, with GenAI systems there could be, you know, very small changes, right?

Yes.

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, are there anything that you just say, "Uh, we ran some aggression tests and it looks fine," so you launch? Or do you always go kind of with a expert-

Sure. Sure

... opinion approach?

Uh, 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, uh, 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, uh, uh, tax experts and use that to train a judge prompt for the LLM.

So that LLM is once again expensive. Uh, we go for the GPT-4 series until recently on that one. And, uh, then minor iterations we can do with auto-eval. So we have clear understanding with product.

We wanna 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.

Uh, if the prompt changes a lot, we would, uh, go for manual evaluations.

Um, thank you for the technical deep dive. I was more interested in the product side of it.

Sure.

We, we also do taxes, so I was curious, what are the kind of, um, LLM interactions that the users are having? Like, what are the kind of questions they're asking?

Is it, is it more like critical parts of the workflow or more like, um-

Sure

... what are my taxes?

So, uh, 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?" Uh, or also their tax situation.

So for example, uh, "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, uh, accordingly, different types of questions need different solutions, and that's where maybe I would reiterate, go back to

here. So... There. So this piece here, Planner. So essentially, this is where it comes in. We wanna 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.

Uh, 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.

Right. Right. Absolutely.

So how do you verify those numbers in terms of the evaluation? Let's say, uh, the actual tax number is eleven [REDACTED:generic_id] thirty-five.

Right. So-

And if it's something like eleven thousand one hundred. So it's quite difficult to catch this with a manual evaluation-

Yes. Yes

... or with an AI. So yeah.

Yes. Uh, thank you for the question. So that's a key thing that we work on. So TurboTax, of course, has a tax knowledge engine that we have bui- 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, uh, 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, uh, the data is coming from the tax engine itself.

Yeah. Correct.

But when you formulate the final explanation, the answer itself, so how do you make sure that, uh, the numbers that are actually in the final answer are, you know-

Right. Right

... same as that's coming from data?

So, so basically we have ML models that are working under the hood as part of the, uh, security aspect that you see here that basically make sure we did not hallucinate any numbers that we built on.

Got it. Yeah. Thank you.

Yeah.

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

Sure, sure. So, uh-

And, 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 where it needs needed?

I'll take the first one. Uh, so a G- uh, GraphRAG, we've definitely seen better response, uh, better response quality with GraphRAG. Uh, even more than that though, I think for end user helpfulness, me- getting personalized answer is the key piece, I would say.

GraphRAG definitely outperforms, uh, uh, regular RAG. Uh, and what even more outperforms is personalizing the answers. And to your second question, uh, we are constantly evaluating the models. Uh, 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, uh, in-house models that Intuit trains and develops. So we are constantly evaluating and, uh, I don't have an answer now what we'll do for the next tax year, but yes, we keep working on that.

Uh, you mentioned, uh, you have different situations, tax situations, and you come up with an answer. So if I describe my situation, uh, 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 h-how you came up with that answer? And I, I assume there's going to be a lot of legal challenges to-

Right. Right. Right

... wrong answers.

Right. Absolutely. I mean, uh, Intuit focuses heavily on legal, legal and privacy, uh, 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.

Uh, thanks.

Uh, thank you so much. What a great talk. [upbeat music]