# Calibrated probabilities give developers control over AI decisions

Markdown copy of https://realalpha.app/s/calibrated-probabilities-give-developers-control-over-ai/ on Real Alpha, the best minutes from long interviews with the people building AI. Cite and link the page, not this copy.

- Speaker: [Diogo Almeida](https://realalpha.app/builders/diogo-almeida/) · Diogo Almeida is co-founder and CEO of TypeSafe. · Built Jev, a decision model returning typed probabilities; co-invented RLHF and InstructGPT at OpenAI.
- Host: [Sam Charrington](https://realalpha.app/people/sam-charrington/) · Host, The TWIML AI Podcast
- Show: The TWIML AI Podcast
- Episode: [Asking JEV's Creator the Hard Questions About This Hot New AI Model](https://realalpha.app/v/9Aato-NfjoU/), Oct 6, 2026
- Moment: 46:11 to 51:38 of the episode (5 min), playing on https://realalpha.app/s/calibrated-probabilities-give-developers-control-over-ai/; the episode from there: https://realalpha.app/v/9Aato-NfjoU/?t=2771

## Quote

> “so to me rlcd is about **exposing the right interface** to builders so that they can get the properties they want without just praying to the system message”
> — [Diogo Almeida](https://realalpha.app/builders/diogo-almeida/) at [49:20](https://realalpha.app/v/9Aato-NfjoU/?t=2960) · The TWIML AI Podcast

## Takeaways

1. RLCD focuses on calibrated decisions, not just human feedback.
2. Developers need thresholds they can tune for their use case.
3. Probabilities let applications control behavior directly.

## About this segment

Diogo Almeida explains RLCD as training for calibrated decisions and exposing probabilities developers can use to set behavior. That lets software teams tune thresholds instead of relying on a system prompt.

From “Asking JEV's Creator the Hard Questions About This Hot New AI Model”, Oct 6, 2026. [Watch the full episode](https://realalpha.app/v/9Aato-NfjoU/)

## Transcript

Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.

[46:15](https://realalpha.app/v/9Aato-NfjoU/?t=2775) So back to the topic of RLHF, like RLHF is not about PPO on reward model on, you know, like doing first SFT and then reward model training and then on policy training of that. Okay. RLHF is about human decisions and your thing is about decisions, calibrated decisions. Human preference. It's never about human decisions. Sorry. Yeah, yeah, yeah. Human feedback. back. So like when I talk about RLCD, I talk about like the general class of algorithms that optimize specifically for calibrated decisions, because that is what's useful for software.

[46:51](https://realalpha.app/v/9Aato-NfjoU/?t=2811) So we do have many algorithms in here that we have been playing around with. We actually have talked about publishing something here, though I will not promise anytime soon because the team is super duper swamped. But I think that you get out, you can imagine. But I think that We'll be right back. So, publishing RLHF was probably really good for the world. You know, it allowed a lot of people to understand stuff. It took us a couple of months to publish it. But, you know, we had InstructureGPT for a while. And I think that eventually publishing something here would be really good for the world too. So, I think that that could be in the cards.

[47:30](https://realalpha.app/v/9Aato-NfjoU/?t=2850) But the task, that's the algorithm versus the task, just to be clear. Other people will probably make other algorithms within the same umbrella of the task. Is it useful to talk more about the task or do you mean the task broadly in the way we've been talking about it thus far? Like what, like in an academic context, I'd ask about the setting. Like what is the setting for RLCD? Like how have you defined that?

[47:58](https://realalpha.app/v/9Aato-NfjoU/?t=2878) That is very complicated, but I can give a simplified version of it. Have you ever used like function calling in the chat completions API? So function calling is kind of like decision making because it is decision making really, but it's done on a layer above the string stuff. So all the knobs available are the stringy knobs that are still available from like the string models. And one example of a stringy knob is a logit bias.

[48:30](https://realalpha.app/v/9Aato-NfjoU/?t=2910) A logit bias allows you to like nudge in the direction of sampling a particular token. So you can do that to make certain tokens less or more likely, if that makes sense. And one of my claims is that no function calling API should exist without a logit bias for the function itself. Like, why would you not provide that knob to a user? because if you are, for example, doing a customer service thing and you need to figure out if you're escalating to a human, your policy is probably extremely different if you're Walmart versus like Costco.

[49:06](https://realalpha.app/v/9Aato-NfjoU/?t=2946) I know nothing about these policies, but I'm just making some of them. But like the only alternative now then is to like program again into the language, like please give refunds or please don't give refunds or something like insane instead of giving the controls of the system to the programmer implementing the downstream behavior so to me rlcd is about exposing the right interface to builders so that they can get the properties they want without just praying to the system message and like i like these types of basic things are table stakes like uh this hasn't happened recently but this happened back in the older days when open ai had issues with over refusals they had to like roll back the model because they refuse too much. And I would argue that that was actually bad decision-making. What was happening is the model within its weights was making a decision,

[50:00](https://realalpha.app/v/9Aato-NfjoU/?t=3000) refuse or no refuse. And then the system is just going with what the language model thinks because it blends the decision with the text and then just does that. So there does exist queries by construction that if you refresh it several times, it will sometimes refuse and sometimes not refuse that is insane behavior from like from an engineering point of view right why wouldn't you have a threshold why wouldn't you have a tunable threshold why would you not have a tunable threshold that responded at least somewhat indirectly to how people are complaining right or if you're doing customer service why can't your threshold on whether to escalate or not be dependent on really basic things like how much is this customer worth to you to us and how busy are our, you know, human workers right now, because maybe that changes things. And we just

[50:49](https://realalpha.app/v/9Aato-NfjoU/?t=3049) don't have any of those controls today. So I see RLCD as really exposing the most native to engineering controls. And that is the shape of the task. And a lot of stuff comes from that shape. Like in order to have meaningful knobs to tune and thresholds to chop, you need to be calibrated. you need your probabilities to be like smart and accurate. You care about the long tail of probabilities, not just the accuracy.

[51:15](https://realalpha.app/v/9Aato-NfjoU/?t=3075) And there's like a lot to the task itself on studying this, seeing trade-offs, figuring out what the right behavior is. There's a lot to the product of an ML API that most people don't realize because they mindlessly follow the gradient of things like MAUs, monthly active users.