金融向けChatGPTをつくる ― OpenAI金融サービス責任者 Joseph Kim 氏

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 Latent Space, 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, so honestly go watch it, but give like a 30 second of what you talk about. Sure. 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 started about. One, I would say, like, we just released a new product, ChattoBD for Financial Services.

This is an enterprise-focused product that's really trying to mix the power of ChattoBD, kind of the tools and things that you really like to use in a consumer product, but also add in the enterprise layer. So that's firm-specific templates, you know, sources like Dilupa, S&P, 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 trend lines out to the future and trying to think a little bit about, okay, like, what are these models going to 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 Codex started to become available to the masses. People started using it for finance, and now you're shipping your first finance product. What is financial reasoning data like? What goes into finance-specific models? Yeah, and it's a good 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. You know, 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, you know, 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, like, 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, like research comes first, and then deployment comes second. And so 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 keynote where, you know, we have this chart of codex adoption within OpenAI. 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 good question. I would say like, so yeah, I can 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. products, I would say like Codex was really like 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 on one roof. And it really gives 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, it's, you know, you have to deal with the reality of the industry that you're in and go build around that. And I think that piece is, it's easy to ignore. Like 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, you know, 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, you know, it's either competitive forces, people have their own objectives. And if you just don't think about that, you're not going to build the right product, right? And so we saw that with Chachapi 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, you know, and data was one of those things where on first principles it was a little bit tough when I was talking about building this product to defend because, you know, you say, hey, like, I want to go and bring quarter earnings transcripts into the product and bundle it. And the first question that the first thing people are going to say is, look, there's an MCP connector in the store. Like, what is the incremental value that you're providing by bundling that in? On paper, it looks bad. It's like 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, like, 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 right and so MCPs is one of those things where it looks great on paper but you have to go see 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 like just control that experience end to end and the extra money that you pay on top to bundle that data is worth it That was a product decision that we had to make that was very industry specific. And it's been resonating with customers. Customers want 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, you know, making a certain product around it?

Yeah. Yeah. I like the question a lot. You know, I try to allude to this in my keynote as well, but the like interesting thing is, you know, but 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 products, right? And so I think it's a great call to kind of mention that piece. What I would say is, like, a fewfold. One is most of the product that we built was built on top of the Codex, or I should say Chat should be T now plug-in architecture and plug-in primitives. And that is something that we've been investing a lot of time and energy in. OpenAI is like an interesting company where we kind of face the same problems internally that a startup would face if they were to build on top of OpenAI. So in a lot of ways my team is kind of like a startup that's building on top of OpenAI technology. And so 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. Like, you know, it's persistent. There's a lot of things that are wonderful about Codex. But the thesis of my team was Codex was, Codex will get you about 80% of the way to a product that would be successful in the market. But, you know, 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 plug-in architecture. it's using the same parameters that are available to any of the builders that want to go build on top of ChatGPT. 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, right? Like, you're going to be able to leverage all of that, for example, 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, you know, 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 out. But for finance, obviously, there are a lot of risks involved in that. So can you talk a bit about the safety sort of that you've baked into the product? Yeah, safety is super, super important. I would say that, like, and it's only going to get more important because, you know, the agents are already getting more autonomous and more independent. and I think that trend we expected 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 is not making a mistake that's going to 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 this space. And so the idea behind it is there's a deep assumption

that there's always a human in the loop, right? Like, so the idea there is, you know, you're a financial analyst and you have a laundry list of things you want to get done that day. And just like how a software engineer is doing with Codex, for every one of those items, the first thing you do is try to build it with ChachVT, 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 responsibilities and that worked for us well and 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? And 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 like you're a new software engineer at a company you often times, when I was at Google you need something called readability and so there's these kind of like 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 leading 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 work their work gets passed off to associates associates are reviewing the work then the associates are kind of adding their secret sauce

their reasoning that gets passed off to the VP VP goes up to the 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 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 sort of misconception where in the finance world, one mistake really compounds. Like 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, how should you use these tools? And do you have any analogies towards where we're at right now? So there's 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 like, one mistake, my career is 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, no, that's wonderful. I have two perspectives on this, and they start with different assumptions. 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. And in the case that it's true, what I would say is not all mistakes are treated equally. And not all model capabilities are treated equally. And so when you think about the mistake that a model or a human can make that could be a career ending it usually once you get up to a certain level like if you a VP the stakes are higher than when you a junior analyst because there 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, right? 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, you know, 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, like, 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 improvement plus the existing system checks in place will make it such that, you know, that type of mistake, the chance of that propagating up to an MD is just very low probability, right? 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. 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. Right? Like there was reinforcement learning through human feedback. And the human feedback was always a pair by 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, right? You just train a reward model. You get a bunch of humans to look at pairs of things and see which one is better. and this still works. So, like, fun fact, like, we did this for slides, right? Like, I mean, 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 and humans are actually really, really good at aesthetic judgment, right? Actually, much better than models is something that we discovered is, like, 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 to get into this pixel, this way, this thing, that and then maybe comes 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 is 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, right? And so the verifiable rewards are, you know, does the code compile? Are there syntax errors? Is the output of the function expected? And so there's the verifiable rewards that are in place. But a lot of good software engineering is, is this a 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? And if you look at it from that lens, a lot of financial work looks very similar. It's the, you know, 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 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? 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 SweetBench 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 the models that you're training will become much better at investment thesis and sort of generating ideas for investment and trading. But obviously that's something that humans or experienced 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 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, like, up until date, the vast majority of applications of AI and finance have been really focused on, I would say, like, the junior analysts' work. And I think that's for two reasons. One is you have to build the product based on the, like, 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, right? So build me a slide, I want it to look this way, you know, 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, right? And so, you know, most humans I talk to, there's obviously exceptions, but a lot of the humans I talk to, like, humans I talk to, people I talk to, you know, they really don't like building a cell model.

It's a tedious kind of work, and it's very detail-oriented, it's easy to get wrong. And similarly with slides. You know, you're copying logos, you're placing them very precisely on a specific part of the page That very tedious work that a lot of people don like to do and so that been part of the impetus for us to go and focus on some of these tasks It a combination of two of those things There the existing molecule that 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 tasks that a GD 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, you know, the P99.9 type of feedback to make the model, you know, 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 opening eye and 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 adding in 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. Yeah, let's talk a little about evals. Evals is, yeah, something near and to my heart, spend 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 can score very highly on the eval,

but actually you're really poor on the actual underlying skill or objective that you're trying to measure, right? And so the, like, prior that I was sharing 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 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, right? And so we actually don't report on that. We don't track it anymore. And so one of the tricky things for GPD6 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 a funny thing. 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 there's kind of 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 of the eval. And so 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. And so 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. We've got to wrap here soon. I want to ask any call-outs for people in the finance space, the latest 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, like, first and foremost, like, please check out Tech2B 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, you know, 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, like 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's coming to a pretty good point. Yeah, we're working very hard to make it available to more people. That's a very common opening eye step. You know, it makes sense. You make stuff for enterprise, and then this trickles down. the regular model as 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.