Full Transcript for ⚡ Building ChatGPT for Finance — Joseph Kim, OpenAI's Head of Financial Services
People
Get the key moments without reading the whole transcript
Full transcript
I really do think that there's going to be a billion dollar business built on top of a ChatGPT plugin. But
95% of what we built was something that absolutely a startup could do, another company could do. At OpenAI, we ran into problems with pre-training and therefore had difficulty scaling the model. In 2026, we've been able to solve many of these issues.
Today we have Joseph Kim, one of the heads of ChatGPT Finance from OpenAI, and our co-host and head of editorial from Latentspace, Richard, in the studio. It's a special episode. We're here in New York at AIE Finance. Joseph just gave a great keynote. I think we don't want to repeat most of the information. That makes sense. Honestly, go watch it, but give like a 30 second of what you talk about, and then we'll leave the breadcrumbs.
You guys can go watch the keynote. Sure, yeah, I can give a quick 30 second intro to kind of what we just chatted about. One, I would say like we just released a new product, ChatGPT for Financial Services. This is an enterprise-focused product that's really trying to mix the power of ChatGPT, kind of the tools and things that you really like to use in the consumer product, but also add in the enterprise layer.
So that's firm-specific templates. you know, sources like Dilupa, SMP, et cetera. And so really exciting. We've been working with our design partners, Morgan Stanley and Evercore on that and reception to that's been incredible. So that was kind of the first half of the talk. And the second half of the talk, really much more forward looking.
So thinking deeply about some of the trend lines that we're seeing in terms of model improvements and drawing those trends lined out to the future and trying to think a little bit about, okay, like what are these models gonna be able to do at the end of, you know, mid 27, end of 27? And what does that mean for folks that are building products on top of that model? And how can you kind of start to plan ahead to the intelligence that's coming in, you know, just a matter of months? I think it's a fun time because you actually come from the research side of things.
So you now lead a lot of product and engineering, but tell us what it takes to make a financial specific product. You mentioned in the keynote that there was sort of an uptick in users when you launched ChatGPT Work. So Codecs started to become available to the masses. People started using it for finance and now you're shipping your first finance product.
What is like financial reasoning data like? What goes into finance specific models? Yeah, and it's a great question. I mean, one thing I will say is that, like, you know,
all of the training data that we do for financial, you know, reasoning analysis, we do upstream into what we call the big run, which is the main kind of run that becomes, you know, something like 6 Astra or 6.1 Astra, et cetera. And so even though we're adding a bunch of financial data to the model, it's going into the main model, and so therefore it's available to folks that want to build on top of it.
And that is something that's very important to us. At OpenAI, we really do want that intelligence to be accessible, not only to our products that we're building in-house in first party ways, but also for folks that want to build startups, build businesses on top of that, as well as financial firms that want to integrate that directly into their companies.
And so we will make all that intelligence accessible there. I think you touched a little bit on product and research, and I think that's really core to what we do at OpenAI. Internally, we call ourselves a research and deployment company, and we kind of structure that in order on purpose. Research comes first, and then deployment comes second.
As we think about, you know, at the end of the day, trying to change the way that people do knowledge work, we kind of work in that order, right? We think about the model capabilities, where they're headed, what kind of new things can they enable. So that's one. And then two, we think very deeply about the product features and surface areas that we should build to make that model intelligence accessible to more people.
And I think you alluded to a slide in my conversation. keynote where we had this chart of Codex adoption within OpeningEye. And it's funny because you can see the software engineering adoption curve and it's just like up and to the right, pretty steady. People are picking it up and incorporating it into their daily routines. But if you look at finance, legal, and sales, it's pretty much at zero and suddenly it kind of jumps up to 90%.
And if you look at that line and try to see what happened around the time where it jumped up, we had released Codex desktop app in February. And that was when that adoption jumped up. And so I do think it kind of shows the importance of co-developing those things. And the purpose of the product is to make that model intelligence accessible to as many users as possible.
So in that uptick of data for using Codex for financial applications, what sort of things did you learn that you then applied into the post-training of financial data? Yeah, it's a great question. I could talk a little bit about how we went about building ChatGP for financial services. It was very unique. We haven't built a whole lot of first-party products.
I would say Codex was really our biggest and main one, and it was the first time we developed a product where the product, the model harness, and the research was all kind of under one house and under one roof, and it really gives us a lot of flexibility to go about building things. I think the biggest takeaway that I have from having worked on this for the last six months or so is in enterprise,
you have to deal with the reality of the industry that you're in and go build around that. And I think that piece, it's easy to ignore. If you just think about it from first base principles, you can come to a conclusion that makes sense and you talk about it and you can defend it with logic and reason. But if you ignore the state of the world that you're in when you start building and the forces that are at play within the industry to try, it's either competitive forces, people have their own objectives, and if you just don't think about that, you're not gonna build the right product.
And so we saw that with Chachapiti for financial services and we thought about that a lot. I'll give you one example, data. Data is like a huge part of how we thought about building the product. And data was one of those things where on first principles it was a little bit tough when I was talking about working on this product to defend because you say, hey, I want to go and bring quarter earnings transcripts into the product and bundle it.
And the first thing people are going to say is, look, there's an MCP connector in the store. What is the incremental value that you're providing by bundling that in? On paper, it looks bad. They might already have a license for it, so they might feel like they're paying twice for it. And they might have an MCP. And so why are you building those? And the reality is we went and we tested all these MCPs.
And what we found was the error rates were really, really high. Some of the MCPs that we connected, some big names, 40% plus error rate on their MCPs. And so MCPs is one of those things where it looks great on paper, but you have to go look at the data and see what's actually going on. And so for data, we're like, hey, look, this is really bad.
The only way we can go about fixing this at scale is to bring the data in-house, just control that experience end to end. And the extra money that you pay on top to bundle that data is worth it. So that was a product decision that we had to make that was very industry specific. and it's been resonating with customers. Customers love it. The number one thing they call out is the data, and so it worked.
So you had good success in this. Tell us about the technical side of things for people building a harness adaptation for a specific service, right? So you guys went out, you changed codecs, you did post-training, you did whatever you did to make ChatGPT for financial services. If someone was to do the same for another domain, say legal, sales, whatever, what are the best practices there? What did you learn? What goes into just taking off the shelf and actually making a certain product around it? Yeah, I like the question a lot.
I try to allude to this in my keynote as well, but the interesting thing is, it's fun to talk about the post-training stuff because it's unique to what we do and gets people excited. But 95% of what we built was something that absolutely a startup could do, another company could do. And we didn't really have to go leverage our ability to go make changes in the model to go about building fantastic product.
And so I think it's a great call to kind of mention that piece. What I would say is like a few fold. One is most of the product that we built was built on top of the Codex, or I should say ChachiBT now, plugin architecture and plugin primitives. And that is something that we've been investing a lot of time and energy in.
OpenAI is an interesting company where we face the same problems internally that a startup would face if they were to build on top of OpenAI. In a lot of ways, my team is like a startup that's building on top of OpenAI technology. Even internally, we need to find scalable ways for teams like myself to stand on the shoulders of giants and build on top of Codex.
Codex is fantastic. It's got great memory. It's got good skills. It's persistent. There's a lot of things that are wonderful about Codex. The thesis of my team was, Codex will get you about 80% of the way to a product that would be successful in the market, but the 20% is missing. And so we need to find some way for my team to go build that 20% to actually go win.
Because the other half of the thesis was, if you just took Codex and launched it as a finance product, it would fail. And so that 20% is actually pivotal. And so what I would say is, we went and we built on top of the plugin architecture. It's using the same primitives that are available to any of the builders that want to go build on top of ChachiBT.
And I had a line in my presentation, but I really do think that there's going to be a billion-dollar business built on top of a ChatGPT plugin. You're going to be able to leverage all of that horizontal functionality and just add your secret sauce on top. And that secret sauce might be data. It might be UI changes. It could be an integration.
But that secret sauce is really valuable. And I think there's a billion dollars worth of value to be built there. So yeah, it's an interesting time for the industry because we're at a time now where orchestration is becoming a lot more automated. You know, teams of agents going out and doing things. But for finance, obviously there are a lot of risks involved in that.
So can you talk a bit about the safety that you've baked into the product? Yeah, safety is super, super important.
I would say that like, and it's only gonna get more important because the agents are already getting more autonomous and more independent. And I think that trend we expect it to continue into 27, into 28. I would say,
For the product that we built and launched last month, there was a bunch of paradigms that already existed as it pertains to safety and being thoughtful around auditing the work, making sure that the model's not making a mistake that's gonna impact business outcomes. And we were able to lean heavily into those. And what I would say is the existing product that we launched is a productivity tool for knowledge workers working in the space.
And so the idea behind it is there's a deep assumption that there's always a human in the loop, right? So the idea there is you're a financial analyst and you have a laundry list of things you want to get done that day. And just like how software engineers do with Codex, for every one of those items, the first thing you do is try to build it with Chachapiti, right? And it might get you 30% of the way there.
It might get you 80% of the way there, depending on the task. But there's always this presumption of humans in the loop that are presiding over that work. And that made it very easy for us to build a product where we could kind of pass off the responsibility of auditing review into people's hands and into people's responsibility. And that worked for us well and it was easy to communicate.
So that was wonderful. I will say we're thinking very deeply about what comes next and what comes next looks different than a productivity tool that sits and is always being monitored by a human. And I think as we think about what comes next, there's kind of two things we're thinking about. One is, how do we kind of shape the security safety profile of the product into something that people understand intuitively?
I would say something that people understand very intuitively is how to work with other people. And so our thesis is if we make the product very similar to how you work with your coworkers, your interns, people around you, that is something that people can pick up and learn very quickly, very easily. And therefore we need to shape the security profile of that to look like a person.
And so there's a few things I'll call out there. One is there's this notion of read-write, even for people. You're a new software engineer at a company, you oftentimes, when I was at Google, you needed something called readability. And so there's these kind of checks and balances and systems in place before you can start mucking around and touching the system.
And so there's already systems in place to monitor the work of people. So if models behave more like people, then you can leverage those systems. And that makes it very easy to kind of talk about and work through this with these financial institutions. So that's something we're leaning into pretty heavily coming up. And the very last thing I would say is, at least in the context of banking, which is where we kind of started, there's already this system in place for junior analysts doing a lot of the ground work.
Their work gets passed off to associates. Associates are reviewing the work. Then the associates are kind of adding their secret sauce, their magic, their reasoning. That gets passed off to the VP. VP goes up to the director, management director. So there's this kind of like, a hierarchical system where there's this implicit work checking that's happening that's already been built out to try to prevent against mistakes that humans make, right? Humans make just as many mistakes as models.
And so those systems are built there. And so we're also leaning heavily in terms of those systems as it pertains to building financial products. I'd say there's this like sort of misconception where in the finance world, one mistake really compounds like your, your whole career is at risk. If you submit something wrong, how should people think about getting started and using it? So if you're an analyst, um, how should you use these tools? And do you have like any analogies towards where we're at right now? So there's like levels of autonomy and self-driving one of your slides, I think said like 2027, you see no more PowerPoint.
A lot of people will be using AI tools in the loop. So how should people think about where we are now and where things are going and how should they adopt these tools if they have that misconception of one mistake, my career's over? Obviously there's human in the loop, but how should they also think about it going forward as they need to offload more and more? Yeah, that's wonderful.
I have two perspectives on it. And they start with different assumptions. I think... I think the notion that my career is over if you make one mistake is an incorrect notion. And I have a line of thought that follows that. But let's first assume that it's true, right? And in the case that it's true, what I would say is not all mistakes are created equally, and not all model capabilities are created equally.
And so when you think about the mistake that a model or a human can make that could be a career ending, It's usually once you get up to a certain level. If you're a VP, the stakes are higher than when you're a junior analyst because there's a presumption of work having been checked up to that point. So if an MD sees a mistake, that's a huge problem.
A lot of the safety nets have failed for that mistake to make it up to an MD. But what I would say is the career-ending mistake is something where you get a piece of information factually incorrect. And that piece of factual information changes the conclusion. That is obviously the biggest type of mistake that you can make. And what I would say is we're seeing a lot of progress in attention to detail.
And the hallucination used to be a big term that used to come up in 2022, 2023, that doesn't come up nearly as often nowadays. I would say that we're starting to see huge improvements in the reliability of models as it pertains to factual mistakes. So the kind of egregious mistake that would get you fired, models are getting much better at and continue to get much better.
And so I feel actually quite confident that a combination of that continual improvements plus the existing system checks in place will make it such that that type of mistake, the chance of that propagating up to an MDE is just very low probability. What I would say the models are lacking today and they still need to improve is actually not the career ending mistake, but it's the bit that involves human judgment and taste.
So it's the, this slide looks ugly, right? And it's not wrong, but it's formatted, like the colors look a little bit off, something about it looks sloppy, and therefore, you know, this is not a good slide. And that's not a true ending mistake in the way that a
factual mistake is, but it still matters. It still matters in terms of how useful that work is. And so as we think about the progression going into 2027, what I would say is I expect the models to get much better at the human taste component. And that's what I was kind of alluding to in my keynote is I think the model will get much better human taste on things that are softer objective functions.
It's not is it right or wrong. It's comparative. Is there something that's better than this? And I think models are going to get much better along that dimension moving forward. How so? How do we solve taste? How do we train taste into the models? Yeah. So... It's funny, very early on in the early RLHF days, the only thing we trained models on were essentially taste.
There was reinforcement learning through human feedback, and the human feedback was always a pairwise signal. It was like given two options, which one's better? And so the early days of reinforcement learning were built on the notion of training on human taste. And then obviously things like verifiable rewards and environments and we built a lot of machinery to do other types of rewards and other types of RL.
And so people kind of forgot that the early days of reinforcement learning were all around human taste. And so how do you train on human taste? I think the technical answer is quite simple. I think the practical answer obviously is more complicated. The practical answer is you just train a reward model. You just train a reward model. You get a bunch of humans to look at pairs of things and say which one is better.
This still works. Fun fact, we did this for slides. How do you go about making these models better at generating presentations? Well, we just get a bunch of humans to look at pairs of slides and say which one looks better. Humans are actually really, really good at aesthetic judgment. Actually, much better than models is something that we discovered.
A human can look at two slides, and within seconds, say this one looks better. And if you have a model, like a grading model, try to go about doing that, it's going to spend a whole bunch of reasoning tokens, this pixel is this way, this thing's that, and then maybe come to the wrong conclusion. And so humans are still really valuable in making these models better.
And so we will rely a lot on human preference to imbue things like taste. So that's one. The last thing I'll kind of add is there's precedent for this, which makes us confident that this strategy will work. And that precedent, I would say, is coding. The models have gotten, I would say coding's not fully solved, but let's say we're 80% of the way there and we're making progress on the last 20%.
Coding is a combination of verifiable rewards and human taste. And so the verifiable rewards are, does the code compile? Are there syntax errors? Is the output of the function expected? And so there's these verifiable rewards that are in place. But a lot of good software engineering is, is this clean system design? Did you build a system that's maintainable over time? Is it easy to unit test? Is it following paradigms that the vast majority of the community or the industry thinks is the right paradigms? If you look at it from that lens, a lot of financial work looks very similar.
I have an Excel model, does it sum up? Are there reference errors? There's a whole bunch of verifiable things that we can check to make sure that the work is passing this first pass sanity check. But there's also a lot of, is this the way I would have built this model? Something I learned about as I started working in finance is there's this notion of like the feel of the model, which is you kind of perturb the inputs and you look at the outputs.
And an experienced financial professional can kind of perturb the inputs, look at the outputs and kind of understand does the data flow through this model in a way that feels good, right? And that is a human preference that looks a lot like does this code look clean? Is it well written? And I think our success in coding gives me confidence that we can solve a lot of these problems in finance as well.
Yeah, we can shout out Frontier Code from Cognition. So it's not only like Sweet Bench is very, you know, is the answer correct? This is also would you merge the code? So you can have multiple answers that are proper PRs that pass, but which one would you merge? And that's why you sometimes see the charts of lower reasoning is better, but it's a taste benchmark as well, right? Yeah, and one of your other 2027 predictions I thought was interesting was that, you know, the models that you're training will become much better at, you know, investment thesis and sort of generating ideas for investment and trading.
But obviously, you know, that's something that humans or experienced kind of financial professionals are very good at, and they kind of have an intuition for that kind of thing. But it's often counter to the prevailing wisdom out there. Otherwise, you know, there's less of a chance of it making a great return. So how are you tackling that problem in terms of training the agents to do that kind of work? Yeah.
I would say that up until date, the vast majority of applications of AI and finance have been really focused on, I would say, the junior analysts' work. And I think that's for two reasons. One is you have to build the product based on the capabilities of the model of today. And so if you look at the capabilities of the model today, they're really quite good at taking pretty concrete instructions of what to do and kind of executing.
So build me a slide, I want it to look this way, make it look good, use our template, these types of things. The model's quite capable of doing those things and so therefore we've built product experiences around that. And the other thing I would call out is there's a strong preference to make the model good at things that humans are not good at or don't like to do.
And so most humans I talk to, there's obviously exceptions, but a lot of the humans I talk to,
humans I talk to, people I talk to, they really don't like building Excel models. It's a tedious kind of work, and it's very detail-oriented, it's easy to get wrong, and similarly with slides. You're copying logos, you're placing them very precisely on a specific part of the page, and it's very tedious work that a lot of people don't like to do, and so that's been part of the impetus for us to go and focus on some of these tasks.
It's a combination of two of those things. The existing molecule is pretty good at certain types of tasks, and also human preferences of what they like to do and not like to do helps drive the direction of the product as well. It's a combination of those two things.
I think that we've solved a lot of the low hanging from those two things. And so going into 2027, we're going to start to move up the stack. We're going to go from the task that a junior analyst can do to some of the tasks that an associate can do to some of the tasks that an MD would do and move up that chain. And as you move up the chain, what I would say is the objectives become much fuzzier.
It goes from this is clearly a good or bad slide or something that would put in front of the client or not to, well, I don't know if this investment idea is good. And it would take me three years of waiting to really be able to give you a clear, concrete answer of what the market has done. And so the objectives start to become fuzzier. And so the way you go about training the model and the way you think about how to make the model better at those things becomes more difficult.
It becomes more difficult from a research perspective. And so, but it's not impossible is what I would say. And so what it takes is a lot of research focus. It takes a lot of wonderful data. It takes a lot of feedback from experts in the field. We really want to get the P99.9 type of feedback to make the model as good as humans. But I don't think it's an insurmountable problem.
And what it takes is continued scaling of the base model and focus. Focus on the research labs to think that this is an important problem to go solve. And one of the things that I'm doing on my team is making this an area of focus and priority for OpenAI. And I think because of the combination of those two things, I feel confident we'll make a lot of strides in 2027.
Do you have any comments on any of the current financial benchmarks? So I think we're still in the state of, you know, does this check out numbers wise? How do you think about making your own ad again taste? I think this is also an open call for people working in this space to work on their own benchmarks and a sort of follow along to that is you said build systems for models today, but you also give a lot of predictions for the future.
How do you put guardrails, limitations, checks on financial services that you build for people today, just so they're confident in, you know, this is not like going out off the rails? Yeah, makes sense. Let's talk a little about evals. Evals is something near and dear to my heart. Spent a lot of time working on evals. I would say that
the prior that I would share with people is building a good eval is incredibly hard. That's not obvious to people who haven't worked on an eval before. To build an eval that actually correlates with the thing that you're actually trying to measure, like the skill that you're trying to measure, capability you're trying to measure, very difficult.
Because whatever you put together is just a proxy for whatever that thing is, right? And it's just one dimension. So that's one. Two is it's very tedious to get the answer key or the way that you grade this correctly. And if you don't get the way that you grade the answers correctly, it's an eval that's very easy to hack, a very easy to reward hack.
And therefore, you know, you could score very highly on the eval, but actually do really poor on the actual underlying skill or objective that you're trying to measure, right? And so the, like, prior that I will share is evals are really hard, not just in financial work, but just across the board. And what I would say is we don't think that there's a really good eval today for financial work.
There's a bunch of existing prior work. I'll reference some of the work that we did, which was a GDP eval, which is like a little bit more broadly in knowledge work. If you guys look at the Astra announcement, we don't talk about GDP eval. We know that the eval is completely saturated and the pieces that are not saturated are essentially broken.
And so we actually don't report on that. We don't track it anymore. And so one of the tricky things for GPT-6 Astra was we didn't talk a whole lot about financial evals. We have some internally that we didn't talk too much about and didn't want to share at the time yet. They're coming. But there was no good way for us to show progress on financial tasks on these evals.
There's the funny things. I think there's this bias in evals where if the numbers look good, the researchers assume that the model's gotten better and they don't investigate it. If you've made a much more capable model and the eval numbers look bad or haven't increased in the scale that you want, then you go investigate. So this is kind of like bias baked into investigation of these evals.
Something like this happened with GBD6 where we ran GBD6 on a set of financial evals and the numbers didn't really change much. We're like, oh, what's going on here? Let's take a look at this eval. We did a deep dive into these different evals and lots of things were broken. Basically, we found that we had saturated the evals, and the questions that we were getting wrong were driven by incorrect answer keys, poorly specified prompts, or just some other flaw with the eval.
All that to say, one of the things that my team is working on currently is to try to build a much better eval that actually predicts the ability to automate the work of that specific profession. The idea is we'll have something like an investment banking eval that predicts, if you score well in this eval, you could probably automate a lot of the work of a junior analyst in investment banking.
We've got to wrap here soon. I want to ask, any call-outs for people in the finance space, the latent space audience? Your team is probably hiring, but last thing to put out there, how can people be helpful to you? Yeah, wonderful. Well, I would say, first and foremost, please check out Chat2Bee Financial Services. It is an enterprise product, but we're trying very hard to make it available to more prosumers on the pro plan.
And so hopefully we'll have some cool announcements there. Two, yes, my team is hiring. We're seeing incredible customer traction with the product, and because of that, we're hiring and scaling the team rapidly. It's a very diverse team with lots of different roles, and so I just want to call out a few of them very quickly. There's obviously the standard front-end, back-end engineering, so kind of traditional product building, so that's one.
Two, we're very much looking for wonderful product managers. I think in some ways, great product management is the main bottleneck in trying to go win in this space. And so we're trying to hire wonderful product managers in investment banking, equity research, asset management. Across the board, we're trying to hire product managers. And then the other role that I want to give a special shout out to is we're hiring something called a subject matter expert.
And, you know, it's really important. One of the things that we did well in coding is, you know, the people that were training the models and making them better understood what good code looks like, right? And that was a huge tailwind for us as we were making the models better at these things. We don't have that advantage when it comes to making the models better at finance.
And so we're building out and trying to hire a lot of folks that are able to bring that financial expertise and work with the engineers, work with the researchers, work with the product managers to make the model and the product better in your specific fields. And so if any of those resonates with you, I highly recommend that you reach out to me.
I'm available on LinkedIn. We also have these job listings posted on our careers page. It's pretty easy to find. Great. Well, you answered my question. I was going to ask, when can I have a play with this? But it is coming to fruition. Yeah, we're working very hard to make it available to more people. That's very common opening-eyed stuff.
It makes sense. You make stuff for enterprise, and then this trickles down, the regular models. It comes to ProPlan. So expect for your general usage down the line, it'll get better at financial stuff. Yes, absolutely. Awesome. Well, very excited to have you. Check out the keynote. You gave a lot. You gave good predictions. You talked a little bit about some juicy, we fixed pre-training issues.
I'll leave breadcrumbs for you guys to go watch. But thanks for joining. Yeah, awesome. Thank you so much.
Related episodes
- Using Agents for Long-Horizon Financial Work — Aman Singh, Arca
- How Anthropic ships the #1 LLM in the World safely: Separating the Brain from the Hands
- Why Agents Love Supabase
- Building Legal Agents When You Can't See the Data - Jacob Lauritzen, CTO of Legora
- 20VC: Cognition vs Factory: Vinod Khosla Creates a Storm | OpenAI Nears $70B Run Rate: Anthropic Under Threat | ElevenLabs Doubles Its Valuation to $22B & Salesforce Buys Listen Labs for $2B
- The Bumpy Road To AGI — With Kevin Roose
- Stop building AI wrappers. Start building agent harnesses.
- The Changing Physics of Cybersecurity and Drug Development with OpenAI President Greg Brockman