← All AI Engineer talks

AI Engineer World's Fair 2026

What's next after RLHF?

Read the talk

What comes after AI’s assistance era?

RLHF helped make language models useful assistants. Dependable automation asks for a different target: correct, calibrated decisions that software can use without continual supervision.

From a talk by Diogo Almeida

Before you start: Basic familiarity with language models and model training is helpful; RLHF and RLVR are explained as they arise.

The ChatGPT era includes Claude Code

What comes after ChatGPT—and why wouldn’t Claude Code count as the next era? Diogo Almeida’s starting point is that both belong to the same category: AI built to assist an involved human. Changing the interface from conversation to coding does not necessarily change the objective underneath it.

Almeida brings experience working on GPT-4, ChatGPT and InstructGPT. He values ChatGPT as a product while questioning the consequences of the algorithmic choices behind it. That combination matters: the question is how a successful training approach can produce both extraordinary usefulness and persistent limitations.

Venn diagram titled “My relationship to ChatGPT,” with OpenAI under “Made ChatGPT,” Yann LeCun and Gary Marcus under “Hates on ChatGPT,” and “ME” in the overlap.
Almeida places himself between making ChatGPT and criticizing it.
0:410:52
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:41 · section reference included

Difficult math, ordinary customer service

The optimistic account of AI starts with benchmarks: difficult tests keep falling, and systems appear capable of handling increasingly long tasks. Almeida presents claims of exponentially growing autonomy as part of this narrative, without specifying a measurement or a reliability threshold.

The pessimistic account points to a different set of observations: bubble concerns, circular financing, and products that still look like chat apps or coding assistants. In Almeida’s telling, some expectations have contracted from an economic transformation to highly valuable B2B SaaS. These are competing interpretations of the field, not two measurements of the same thing.

A useful explanation has to accommodate both. How can models tackle difficult, even previously unsolved math problems while customer service still needs people to make decisions? The apparently simpler task remains difficult to entrust to software. Capability on a demanding problem and dependability in an ordinary workflow are different requirements. That is the discrepancy Almeida wants to explain.

1:492:06
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

1:49 · section reference included

Two different goals for the human in the loop

Almeida’s explanation begins with the role of the user. In assistance, satisfying the human is part of the task itself. Claude Code’s job, in this framing, includes how it converses with its user; it is not exhausted by whether the resulting code works. Automation has a different destination: a process running on a server that no one needs to watch, eventually becoming dependable, unremarkable software.

RequirementAssistanceAutomation
ObjectiveSatisfy the involved userComplete the task dependably
Human’s roleParticipate and guideIdeally no ongoing supervision
Desired operationUseful interactionUnattended background work

The distinction is about the objective and operating conditions, not whether the interface happens to contain a chat box.

Two columns labeled “Too good to be true” and “Too bad to be useful,” overlaid with red stamps reading “Human in the loop: Assistance” and “Machine only ideally: Automation.”
“The Sane View of AI” separates assistance from automation.

Almeida’s diagnosis is that today’s AI excels at the first category but remains difficult to trust with consequential decisions in the second. He criticizes a deployment pattern in customer service: businesses let AI send users through documentation and support interactions, but retain human control over expensive decisions. The user absorbs the inconvenience while the business protects itself from the cost of an incorrect action. That is his criticism of prevailing incentives, rather than a universal rule for every deployment.

4:294:40
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

4:29 · section reference included

RLHF optimizes the preference signal it receives

Reinforcement learning from human feedback, or RLHF, supplies the connection between the training objective and the product behavior. Almeida regards it as effectively ubiquitous among heavily used language models: he estimates roughly 100% of LLM usage involves RLHF-trained models, qualified by “As far as I can tell.” This is his estimate, not a measured market census.

The InstructGPT explanation provides the historical training example behind his summary. Stripped to its essentials, the loop is:

  1. Collect human preferences about model outputs.
  2. Optimize the model to produce outputs that score well under those preferences.

The target is what people prefer. It is not automatically the successful execution of an unattended software process.

Human feedback during training does not itself require a human to supervise every deployed inference. Almeida’s argument is about the behavior encouraged by the objective: training for human approval helps explain why the resulting systems fit naturally into assistance workflows. A preference signal and an autonomous-task success criterion are not interchangeable.

5:576:15
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:57 · section reference included

Looking right can diverge from being right

Once preference becomes the optimization target, a convincing answer can be rewarded even when its underlying result disappoints. Almeida describes overpromising as a consequence of this incentive. He refers to an older meta-study comparing preference and results, while acknowledging that its numbers may have changed; the useful point here is the proposed divergence between the two objectives, not a numerical performance gap.

His concrete example is a social-media post in which someone sends ChatGPT an audio file of fart sound effects and asks for feedback on music they made. The response treats it as an eerie atmospheric piece. As Almeida recounts it, the model supplies an agreeable interpretation instead of a candid assessment of the input.

In his account, uncertainty makes the mismatch especially visible: when the model does not know, it can favor the response that seems most likely to please the user. He characterizes engagement as the eventual destination of those incentives. Automation instead needs the system to perform the task correctly and remain calibrated about what it knows, even when that produces a less satisfying interaction.

The strong version of Almeida’s claim is that reward-model asymmetry makes wrong answers look right. That is a causal interpretation, not a universal law established by these examples. Preference optimization can reward persuasive errors, but it is neither the only source of hallucination nor necessarily an increase in hallucination: the original InstructGPT account reported fewer hallucinations than its pretrained GPT-3 baseline. The narrower engineering concern survives that qualification—an answer’s appeal is insufficient evidence of its correctness.

6:567:19
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

6:56 · section reference included

More agentic does not automatically mean autonomous

This returns the discussion to Claude Code. Almeida places it firmly within the assistance era because, in his account, its behavior still reflects RLHF. A system trained purely through reinforcement learning from verifiable rewards, or RLVR, would behave differently: its optimization would emphasize verifiable task success rather than human preference. This is an objective-level comparison, not a specification of Claude Code’s training mixture.

The resulting tension can appear as a model becoming better at agentic work while becoming less responsive to what its user actually wanted. Almeida sees those behaviors as movement between optimization targets. Neither stronger agency nor stronger deference, by itself, establishes dependable automation. The next era he is asking for would make unattended execution a first-class goal.

“What’s next after RLHF?” with RLHF crossed out, “the ChatGPT era?” added in purple, a large red Assistance stamp above, and a smaller Assistance stamp beside the Claude Code clue.
The revised title slide marks both the ChatGPT era and Claude Code as assistance.
9:019:18
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:01 · section reference included

Smarter software, not only cheaper software production

Software provides the practical test for that ambition. Almeida argues that the core behavior of SaaS has changed surprisingly little since 2019, beyond the addition of chatbots. If models are built for assistance, attaching an assistant to an existing workflow is a natural product outcome. It does not necessarily alter what the underlying software can do.

He contrasts this with the work-oriented ambition he associates with the OpenAI Charter: software would become smarter, rather than merely cheaper to write. Garry Tan’s description of a golden age of just-in-time software captures the latter possibility. Almeida appreciates that possibility—and continues to value coding assistants—but sees it as only part of the opportunity.

The missing change is in software’s expressive building blocks. Instead of starting with an entire person’s job and trying to automate all of it, Almeida points to a smaller unit: rote work that can be clearly communicated to someone else and repeated by a computer. The ambition is for intelligence to operate inside the workflow, where the work happens.

Software patternWhere intelligence contributes
Traditional softwarePeople specify the workflow
Just-in-time softwareAI helps produce the code
Smart softwareAI performs work within the workflow

Generating conventional code can accelerate software production while leaving the resulting program’s expressive limits unchanged. Almeida wants the third pattern to expand those limits.

Three panels show traditional software as a branching flowchart, just-in-time software as a chain above a harried cartoon brain, and smart software as a branching flowchart with brains embedded.
Traditional, just-in-time, and smart software appear as three contrasting diagrams.
9:5710:09
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:57 · section reference included

Redesigning the stack around reliability

Almeida expects automation to become the next organizing goal for AI. He calls RLHF an unexpected detour, rather than simply a mistake, and describes the amount of work currently automated as a rounding error despite models’ intelligence. That phrase expresses his judgment about the gap between capability and deployment; it is not a quantified estimate.

At TypeSafe, the question is what would change if the AI stack were designed around reliability and automation from the beginning. At the time of the talk, Almeida describes the company as still somewhat stealthy and approaching a release, inviting people to its mailing list and careers page. He presents a research direction, without disclosing a training algorithm, deployment procedure or reliability results.

He also teases a separate criticism of the original scaling laws. The recording does not develop that argument; the technical discussion that follows instead returns to pre-training, reward objectives and the interface between models and software.

12:1912:38
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

12:19 · section reference included

Pre-training and the incentive to sound confident

The first substantive audience question concerns training a classifier head alongside pre-training, a proposal Almeida approximately associates with Yoshua Bengio. He declines to address the specific architecture in the available time. His broader answer is that pre-training is not the central problem: compressing internet knowledge into a reusable core of intelligence is already a remarkable achievement.

The challenge, in his view, is how to elicit that intelligence. He compares preference-reward asymmetry to mode dropping in generative adversarial networks: an optimization process can favor a narrower set of outputs rather than preserving the full range of possibilities. In the language-model case, his emphasis is on the pressure toward confidence.

Visible uncertainty is easy for a reward model to recognize and penalize. If expressing doubt incurs a penalty, a model has an incentive to produce a confident answer instead. Almeida offers this as an explanation for how useful pretrained knowledge can be elicited badly; he does not provide a formal derivation of the GAN analogy or a complete account of hallucination.

14:0814:26
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

14:08 · section reference included

A third objective: calibrated decision-making

Asked whether TypeSafe’s approach is another form of RLVR, Almeida explicitly says it is not. To explain the distinction, he turns to Richard Sutton’s The Bitter Lesson. Almeida summarizes it as compute mattering more than algorithms, then challenges the extension of that view from games to reality. Sutton’s actual essay also covers speech recognition and computer vision; its thesis concerns general methods that scale with computation. Almeida’s response is a competing emphasis: choosing the right task matters more than data, and data matters more than compute.

That priority places the optimization target before the machinery used to pursue it:

ApproachTarget in Almeida’s comparison
RLHFHuman preference
RLVRVerifiable correctness
TypeSafe’s proposed approachCalibrated decision-making

Almeida describes RLVR in terms of “log error rates of pure correctness,” without defining a mathematical objective. His proposed third target is to make pretrained intelligence directly useful for decisions inside software. This distinguishes the intended behavior, but does not disclose how TypeSafe trains for it.

The final technical question asks whether rewards are injected throughout a process rather than delivered only at its end. Almeida does not confirm either reward arrangement. Instead, he says that changing the post-training objective changes even the shape of the API: RLHF, RLVR and TypeSafe’s approach would expose different interfaces.

Instruction following is his analogy for how such a change might unfold. A new way of eliciting model behavior can initially feel unfamiliar, then become obvious once people build around it. The proposed destination is an interface suited to dependable decisions within software. Its concrete shape remains undisclosed.

15:3815:43
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

15:38 · section reference included

Resources

From the talk

Updates since the talk

  • Scaling Laws, HonestlyArticle

    Almeida's July 2026 explanation of his criticism of the original scaling-law training setup.

Read the complete timestamped transcript
  1. 0:00

    [upbeat music] Excellent. I will say that, um, I might speed run through this.

  2. 0:17

    Feel free, if you don't disag-agree with something, to yell out. It's way more fun for me if things get interactive. Um, otherwise, I will go through this. Uh, first, can I have, like, a vague show of hands of who knows what RLHF is?

  3. 0:32

    Oh, excellent. I might be able to skip through that part quickly and get into the interactive stuff. So my name's Diogo Almeida. I'm talking about what's next after RLHF.

  4. 0:41

    More accurately, I think this should be called what's next after the ChatGPT era that I think we're all in, and my hint for you guys is it is not the Claude Code era.

  5. 0:52

    I will justify this later on, but I actually believe them to be part of the same era. Why should you listen to me? I was co-author to what, what is basically OpenAI's greatest hits, at least published hits.

  6. 1:04

    Co-author to GPT-4, ChatGPT, RLHF/InstructGPT. Um, the team I was part of basically invented post-training as a concept, so, um, very qualified on a lot of this stuff. But what makes me somewhat unique here is that I'm one of the few people at OpenAI who actually hates on ChatGPT. [audience laughing]

  7. 1:26

    Uh, thank you. Uh, I don't hate ChatGPT as a product, to be clear. I think ChatGPT is a world-changing product that will probably stay with us for the rest of time unless something better comes up.

  8. 1:36

    But I also acknowledge its limitations, and I, I think a lot of what's happened in the state of the field can be traced back to minor decisions we made in making the algorithms behind ChatGPT.

  9. 1:49

    Um, I feel like the question that's relevant to everyone in AI right now is what's actually going on. Um, there's a lot of, like, differing opinions, and I think it's really useful to, like, map out the spectrum and figure out how can smart people have, like, such different opinions.

  10. 2:06

    There's cult one, um, AI is not just going well, it's going insanely well. Every single benchmark, we surpass human level, and as far as we can measure, we are continuously surpassing human performance, uh, you know, like basically every new benchmark, and it's only getting faster and accelerating.

  11. 2:25

    You have, uh, you know, every-- Can I see my mouse? Excellent. Basically, every, like, NLP benchmark is getting crushed, and not only that, allegedly the time that LLMs can operate autonomously is growing exponentially.

  12. 2:39

    On the other hand, you have AI is not just going poorly, it's going like insanely poorly. AI is a bubble. It's basically generating no value. It's just circular financing deals, et cetera, et cetera.

  13. 2:52

    And you know, if AI is so great, why is, why is everything just like a chat app right now or like a Claude Code thing? Um, and a, a lot of the people have actually kind of given up on what was the old guard's terminology of a transformative AI revolution.

  14. 3:06

    People aren't really talking about that anymore. They're talking about it being like massively valuable, like B2B SaaS. So the only thing that everyone agrees on is, like, there's just these extreme points of view and like nothing in between, and everyone basically thinks AI is insane, but, like, for different reasons.

  15. 3:22

    And what I would want to talk about is what is the sane view of AI? Let's take all the evidence of, like, cult one, it's going super well, take all the evidence of cult two, it's going super poorly.

  16. 3:33

    Like, uh, you know, map them out and try to explain what, what, what explains that divide. Like, what is the simplest possible explanation of why some things are too good to be true and some things are not just bad, they are so bad that we would still employ human workers to do like, you know, like kind of

  17. 3:50

    like dumb tasks? Um, no offense to any of them. A lot of these tasks on the right seem way, way, way easier than the stuff on the left. Like, how can we be solving like, you know, unsolved math problems, but still customer service requires like humans in the loop in order to actually like make decisions?

  18. 4:08

    This I think is like kind of like a wild state of affairs, and in my opinion, anyone who works adjacent to AI should have an answer to this because this is like the evidence in the field right now.

  19. 4:20

    Um, I would normally pause and ask people if they wanna like yell out their thoughts on this, but, uh, that-- I don't think we have time for that, and I've been told to not take Q&A until after.

  20. 4:29

    Um, but I'll just give you my answer to this, which is, uh, in my opinion, the simplest explanation. All the stuff on the left is not just a task that happens to have a human in the loop.

  21. 4:40

    In the left, the task, the goal of it is to please the human in the loop. These tasks are intrinsically human-in-the-loop tasks. The-- Like Claude Code's job is not to just make code work.

  22. 4:51

    Um, the, the, the, the way it converses would be totally different. The goal is to please the human in it. And on the other side, all of these tasks that seem way more basic, the goal is to not have-- remove the human loop.

  23. 5:03

    Ideally, it would be running in the background in a server that you never even look at, and ideally, it eventually becomes like legacy software that you don't really worry about.

  24. 5:11

    So-- And this is the divide between assistance and automation.

  25. 5:15

    Um, lesson one for my talk is that today's AI, everything inherited from RLHF, is incredible at the human-in-the-loop stuff, but not for automation tax-- tasks. This is a longer aside, but the lesson basically every business has learned is do not use AI for decisions with stakes to your business.

  26. 5:36

    Um, a, a common pattern is make sure that all of the costs are to the user and not to your business. So, um, it's o-- totally okay to throw the user at infinite docs and customer service, but it is not okay to make it make expensive decisions.

  27. 5:49

    Horrible pattern, but that is the state of AI right now. Uh, I can, I can blitz through the what is RLHF part 'cause you all seem to know what it, what it is.

  28. 5:57

    Um, it's the algorithm behind not just ChatGPT, but basically every LLM today. As far as I can tell by usage, 100%, roughly, of LLMs are trained with RLHF. And we have this, uh, we as in we the OpenAI team, had this great blog post on how it worked.

  29. 6:15

    Um, I will not get into that because you all know it, and this is super boring. Um, the summary of this is it is just collect human preferences, optimize for human preferences.

  30. 6:25

    Um, and if you want to see, like, an annotated version of this, you can see which parts are collecting human preferences, which ones are optimizing for them. And this, I think, provides a really clear answer to everyone in the field asking, "Why do all LLMs require a human in the loop?"

  31. 6:42

    The... And the simple answer is we literally put them in the loop. The goal of the loop is to optimize for human preference. It is not to run software autonomously.

  32. 6:50

    It's kind of super obvious. Thank you, my man at the back. [laughs]

  33. 6:56

    The, yeah. The I, I, I love that you're laughing at this. Um, and because of that, overpromising is a feature. This is by design. This is an old meta study, um, and the, the numbers probably have changed, but by construction, every RLHF model will always have a big difference between human preference and results even if the results

  34. 7:19

    are good because the main objective you're optimizing for is for human preference. This is just, like, natural to how LLMs work. Um, I love this tweet of, um, uh, sending ChatGPT an audio file of fart sound effects and asking, like, "What ti- what do you think of the music I made?" [laughs]

  35. 7:38

    "Here's a straight, honest reaction. It's a very eerie vibe atmosphere piece." Um, and this is just how RLHF works. If it doesn't know, it will err on the side of doing what it thinks is best for human preference, and this makes total sense if you're a user in the loop because, like, the end game for all, uh,

  36. 7:56

    RLHF models is optimizing for engagement. But what you really want if you want automation is for it to just, like, not give a shit about, uh, the humans, um, and just do the task correctly in a calibrated way.

  37. 8:10

    Um, lesson number two is that today's AI was designed for assistance through optimizing for human preference. This is like, it- it's, like, in the name. This is not, like, a controversial, uh, take.

  38. 8:22

    And the consequences are maybe more controversial, but it's, like, very obvious if you think about what we really are optimizing for which is no matter how wrong the models are, they will look right because of the asymmetry within the reward model in RLHF.

  39. 8:37

    Um, and this is where a lot of, like, the dilemma in the field stems from because people really want automation to happen.

  40. 8:47

    Cool. So back to the original question. I'm over halfway done with the talk and I haven't even answered it. I was just talking about what's RLHF. But, um, this was a framing to talk about what RLHF is to talk about what's next.

  41. 9:01

    And I would say the real question is what's next after AI's assistance era, which I think that we are, like, very firmly in right now. And back to the original clue of why it's not Claude Code, it's actually a super fun nuanced discussion, but it's not Claude Code because Claude Code is still part of that assistance era.

  42. 9:18

    Claude Code is still RLHFed, and it'll, it would look very, very different if it was purely... This is a little advanced, but if it was purely RLVR'd it would look very, very different.

  43. 9:27

    And this is why you get, like, this dilemma with models where sometimes it gets really good at agentic stuff, but it stops following what you actually want. This is, like, the trade-off in optimization space that keeps dancing, but both of these trade-offs in optimization space do not add to the automation component.

  44. 9:43

    And, like, that leads to what I think the re- the logical answer of what's next after assistance is real automation. Um, to talk about, a little bit about automation, uh, and how that would work, I want to talk about software.

  45. 9:57

    Um, maybe this is a little bit philosophical for you guys, but I think it's... When it clicks ho- and hopefully it clicks if I do a good job, it, it, it, I, uh, hopefully it'll be, like, really clear, which is I'm a lover of software.

  46. 10:09

    I assume everyone here loves software. Software is, like, super valuable. See all the SaaS. And kind of like the craziest part of software, in my opinion, is that all of the SaaS basically has not changed since 2019.

  47. 10:23

    Like, SaaS has not really changed in the LLM era except sometimes a chatbot is, like, latched on which is, like, kind of insane if you think about, like, the progress made in AI, but is actually very predictable when you think that AI is assistance native, right?

  48. 10:39

    Like, AI is made for assistance. What can you do in SaaS? Just provide an assistant on the side. And this is not what early AI pioneers used to think would happen.

  49. 10:49

    Like, when you see, like, the early wording in OpenAI's, uh, charter, it's about, like, doing, like, tons of work, not about, like, making profit or anything like that. And we used to think that software would get a lot smarter, not just cheaper to write, which is kind of the direction we're going down right now.

  50. 11:06

    And I actually really like this phrasing from Gary Tan. Um, uh, I, I think he means this as a compliment to, uh, what's going on right now. We're entering the golden age of just-in-time software, but I actually think that this is like a, like a double-edged sword.

  51. 11:21

    Like, I don't w- just want just-in-time software, which is cool. I u- I love Claude Code, to be clear, just like I love ChatGPT. It would keep using it.

  52. 11:29

    But, like, what I want is smarter software. Why can't, like, B2B s... Like, why can't software just be more expressive? Like, why are the, like, the building blocks of software actually still the same?

  53. 11:41

    And, um- Uh, uh, I think this is a question that the whole AI industry should ask itself, and basically every time you're thinking about we want to do automation, it is not about like, you know, an amalgamation of like automating a person's work.

  54. 11:54

    It's about like, hey, there's this extremely rote work. It's so simple that we can like communicate to someone else that this thing should be done, and ideally like it, it's so basic that it could be done repeatedly for basically free.

  55. 12:06

    Um, or it could be done by computers, and that's really not happening right now. What we're doing is we're just automating the writing of the software, but then it, its expressibility is the same, and that's, uh, that to me is like tragic in the state of the world.

  56. 12:19

    Um, cool. Oh, lesson three. Um, this is, uh, something that I believe strongly in. I believe that the, like eventually the field will write the-- I wouldn't say RLHFs are wrong, but it was like a weird detour and one that we didn't expect.

  57. 12:38

    Uh, tomorrow's AI, I believe, will be for automation, and, uh, we will eventually have a world with smarter software. Like there will start to be actual work that is automated, which, uh, you know, right now it's a rounding error despite LLM's intelligence.

  58. 12:52

    And, uh, that is what we are working on at TypeSafe. We are still kind of, um, stealthy. Like, uh, I'm willing to give these talks, but these are like some of the early ones.

  59. 13:03

    Um, our core question is what if the AI stack was redesigned for reliability and automation? Like how would that all change? Um, what, what would you do? Uh, and actually there's a lot-- It's a, it's a very interesting fork in the road, uh, for what's go- you know, the, like from basically every LLM that's built today, and

  60. 13:24

    I think it's one of the most satisfying things I've worked on, and I've worked on some pretty cool stuff. We are releasing soon, so, um, if you want to work with us or you want to like, uh, you know, be the first-- one of the first to build smart software, please sign up on either our mating-- mailing

  61. 13:38

    list or careers page. And I am trying to start a Twitter, so follow me and I will post really spicy things. I actually will post something later today that I guarantee will be very spicy.

  62. 13:48

    Uh, the hint is that the original scaling laws were incorrect.

  63. 13:53

    Cool. Um, that, uh, that's it for my prepared stuff. I would love-- Do I have time for, for people yelling out questions? I would love questions, feedback, disagreements, strong stuff.

  64. 14:04

    I can repeat the question. You don't have to worry about the, the mic. Hell yeah.

  65. 14:08

    Uh, cool. The, uh, the question was roughly what if you trained like a classifier head with pre-training as well, uh, roughly, uh, like Yoshua Bengio is suggesting. Um, I will say that that's complicated, and I, I actually think I don't have the time to answer that particular question.

  66. 14:26

    I will give like my simplified view on this, and it, it-- the answer is I actually don't think that pre-training is the problem. I think pre-training is, uh, fucking phenomenal.

  67. 14:36

    Like the fact that we compressed the knowledge of the internet into like this core of intelligence that then can be utilized is incredible, and the pre-trained models are incredibly intelligent.

  68. 14:47

    Uh, and I, I believe that the problem is like how we unearth it, and hallucination to me is intrinsic to, um, optimizing for human preference. Like there's an asymmetry in the reward model, kind of like GANs have.

  69. 15:00

    Oh, I really should not get-- This is a very advanced topic, but there's an asymmetry in the reward model like what GANs have that allow for, um,

  70. 15:09

    that encourage the models to drop modes and be confident because it's very easy to see when the model is not confident and to punish that from a reward model perspective.

  71. 15:18

    It's very complicated, but, uh, I'm happy to chat afterwards if you wanna jam.

  72. 15:22

    I didn't get it all, but [inaudible].

  73. 15:26

    Cool. Oops. Um, uh, I have other slides from other talks as well that I could go into more about that.

  74. 15:34

    I have a minute left. Hell yeah.

  75. 15:36

    The third thing [inaudible].

  76. 15:37

    Say it again.

  77. 15:38

    I said the third thing. Are they just RLVR a new thing or still RLVR?

  78. 15:43

    It is definitely not RLVR. So it is a new thing. Uh, every single optimization stack, I will actually go into an old presentation that I have because I think this is super important.

  79. 15:53

    Um, in terms of like to me what the-- like Sutton's bitter lesson is that algorithms matter more than compute. This is true in games but not true in reality.

  80. 16:03

    I actually think that the full stack is that data matters more than compute, and doing the right task matters way more than data. And basically every single branch of LLM post-training, if you want to call it, has its own North Star of what it's optimizing for.

  81. 16:19

    So RLHF is optimizing for human preference. RLVR is optimizing for like log error rates of pure correctness. But we are doing a third thing that is optimized for calibrated decision-making and like basically mainlining the intelligence of pre-trained models into like being actually useful for software, which I think is like quite different.

  82. 16:41

    The, the reward is dispersed, not a final answer throughout the process?

  83. 16:46

    Uh, could you say that again?

  84. 16:47

    So the, the reward is sort of, um, injected throughout the whole process, not just at the end [inaudible]?

  85. 16:53

    Uh, they're asking if the, the reward is injected through the whole process. I will actually say that even the shape of the API is different because the shape of the API of RLHF is different from RLVR, which is different from what we are doing.

  86. 17:05

    So we are like thinking about it from scratch, just like no one thought about instruction following before we made instruction following happen. Um, usually when there's a big branch in new ways to post-train, like it, it just looks like totally alien, and then in hindsight becomes super obvious.

  87. 17:22

    Cool. I believe I'm over time 'cause this red thing is, is beeping, but please find me afterwards. I love questions. I love the interactivity. Um, and, uh, follow me on Twitter for spicy stuff.

  88. 17:35

    Heck yeah.

  89. 17:36

    But what's up with the fact [inaudible]?

  90. 17:37

    Oh, uh, oh, yeah, it's over here. Complete skeptic. Um-

  91. 17:41

    Okay.

  92. 17:41

    It's, it's on brand for me. Cool. Heck yeah. Thank you. [audience applauding] [upbeat music]