1 00:00:00,040 --> 00:00:04,000 Welcome back to the Deep Dive. Usually we take a wide angle 2 00:00:04,000 --> 00:00:06,800 lens to a topic, you know, exploring the ecosystem, the 3 00:00:06,800 --> 00:00:09,440 market dynamics, or even the philosophical implications. 4 00:00:10,400 --> 00:00:12,640 But today we're doing something a little different. 5 00:00:12,720 --> 00:00:14,800 This is our Practical AI Digest edition. 6 00:00:14,800 --> 00:00:16,640 We are zooming in. Weigh in. 7 00:00:16,640 --> 00:00:20,320 We're going past the headlines and straight into the 8 00:00:20,320 --> 00:00:21,680 engineering. Exactly. 9 00:00:21,720 --> 00:00:24,640 We aren't just going to talk about cogeneration in the 10 00:00:24,640 --> 00:00:27,360 abstract. We are going to unpack 11 00:00:27,720 --> 00:00:31,920 specifically how to build and I think maybe more importantly, 12 00:00:32,080 --> 00:00:34,840 how to evaluate the models that build software for us. 13 00:00:34,840 --> 00:00:36,840 And we have a perfect subject for that today, the. 14 00:00:36,880 --> 00:00:40,320 Topic on the table is the engine that really launched this whole 15 00:00:40,320 --> 00:00:44,040 era of AI assisted programming, Open AI's codecs. 16 00:00:44,040 --> 00:00:46,720 This is the model that powers GitHub Copilot. 17 00:00:47,240 --> 00:00:49,880 And you know, while it's really easy to just install the 18 00:00:49,880 --> 00:00:52,560 extension and let it auto complete your loops, the actual 19 00:00:52,560 --> 00:00:56,160 mechanism under the hood is, well, it's a fascinating case 20 00:00:56,160 --> 00:00:58,200 study and machine learning adaptation. 21 00:00:58,240 --> 00:01:00,320 So what are we basing this on? What's the source measure? 22 00:01:00,440 --> 00:01:03,560 We're basing this deep dive on the primary research paper from 23 00:01:03,560 --> 00:01:06,920 the Open AI team. It's called Evaluating Large 24 00:01:06,920 --> 00:01:10,840 Language Models Trained on Code. We'll also pull in some context 25 00:01:10,840 --> 00:01:13,440 on the launch from a great piece in Singularity Hub. 26 00:01:13,440 --> 00:01:17,720 OK, so the mission for us today is to bridge that gap between it 27 00:01:17,720 --> 00:01:20,120 works like magic and it works like math. 28 00:01:20,520 --> 00:01:23,120 I like that. We really want you to understand 29 00:01:23,120 --> 00:01:26,200 how a model translates natural language, you know, plain 30 00:01:26,200 --> 00:01:28,840 English, into functional Python code. 31 00:01:29,360 --> 00:01:33,200 And to do that, we have to look at 3 very specific areas. 32 00:01:33,280 --> 00:01:37,120 Right, first the architecture. Specifically how it even reads 33 00:01:37,120 --> 00:01:38,640 text. Then the metrics. 34 00:01:38,920 --> 00:01:41,480 Why do standard language scores totally fail for code? 35 00:01:41,720 --> 00:01:45,000 And finally, the tuning. How do you actually control the, 36 00:01:45,400 --> 00:01:47,520 let's call it, creativity of the machine? 37 00:01:48,160 --> 00:01:50,760 And I think for the developers listening or maybe anyone 38 00:01:50,760 --> 00:01:53,480 managing a technical team, there's a key concept here we're 39 00:01:53,480 --> 00:01:55,680 going to hit. Hard Oh yeah, the Passat collie 40 00:01:55,680 --> 00:01:58,320 main metric it is absolutely crucial. 41 00:01:58,320 --> 00:02:00,760 It really changes how you should think about the reliability of 42 00:02:00,760 --> 00:02:03,760 these tools Well, it's not just about getting the right answer, 43 00:02:03,800 --> 00:02:07,120 it's about the probability of generating the right answer 44 00:02:07,120 --> 00:02:10,600 within a specific budget of demps. 45 00:02:10,600 --> 00:02:13,320 It's a whole new way of thinking about correctness. 46 00:02:13,320 --> 00:02:15,760 Right, let's start at the beginning, then the origin story 47 00:02:15,760 --> 00:02:20,440 with rewind a bit back to GPT 3. The original text Titan. 48 00:02:20,480 --> 00:02:23,840 When GPT 3 launched, it was the king of text. 49 00:02:24,360 --> 00:02:27,200 It could write poetry, it could summarize emails. 50 00:02:27,200 --> 00:02:28,760 It could generate marketing copy. 51 00:02:29,680 --> 00:02:32,120 But was it a coder? Not really. 52 00:02:32,120 --> 00:02:33,760 I mean not in any practical sense. 53 00:02:33,760 --> 00:02:36,080 It was a generalist. So what was it trained on? 54 00:02:36,200 --> 00:02:38,560 It was trained on the Common Crawl, which is basically a 55 00:02:38,560 --> 00:02:40,360 scrape of the entire public Internet. 56 00:02:40,560 --> 00:02:43,000 And the Internet has code on it. Oh, it has a lot of code. 57 00:02:43,000 --> 00:02:45,800 If you script the web, you're going to get Stack Overflow. 58 00:02:45,800 --> 00:02:48,960 You get technical blogs, you get random snippets and forums. 59 00:02:49,440 --> 00:02:53,640 O GT3 definitely saw code, but it just saw it as another form 60 00:02:53,640 --> 00:02:56,160 of text. O it didn't understand the like 61 00:02:56,600 --> 00:03:00,080 the physics of code, the rules. Exactly, that's a perfect way to 62 00:03:00,080 --> 00:03:01,760 put it. It could mimic the structure O. 63 00:03:01,760 --> 00:03:05,000 If you asked it for a for loop, it would give you something that 64 00:03:05,000 --> 00:03:06,600 looked like a for loop. But it wouldn't work. 65 00:03:06,760 --> 00:03:08,880 Often not. The variables wouldn't quite 66 00:03:08,880 --> 00:03:11,400 match, or the syntax would be just slightly off. 67 00:03:11,680 --> 00:03:15,240 It was like a student who memorized the textbook glossary 68 00:03:15,440 --> 00:03:18,440 but didn't actually understand the grammar or the logic flow. 69 00:03:18,440 --> 00:03:21,160 It was producing text that looked like code rather than 70 00:03:21,160 --> 00:03:23,360 functional instructions. Let's just say it was a mimic. 71 00:03:23,600 --> 00:03:27,840 So the pivot to codex then wasn't just let's make GPT 3 72 00:03:27,840 --> 00:03:30,400 bigger, it was something more fundamental. 73 00:03:30,640 --> 00:03:32,640 Right, it was. Let's specialize. 74 00:03:32,880 --> 00:03:36,760 They took the foundational GPT 3 model and they fine-tuned it. 75 00:03:37,200 --> 00:03:40,840 They basically force fed it a massive diet of pure code. 76 00:03:40,840 --> 00:03:43,680 Where'd they get all that code? Specifically, they gathered 77 00:03:43,680 --> 00:03:46,040 publicly available code from GitHub. 78 00:03:46,520 --> 00:03:49,840 We are talking about a data set that even after filtering came 79 00:03:49,840 --> 00:03:53,360 out 259 gigabytes of unique Python files. 80 00:03:53,440 --> 00:03:55,680 I want to pause on that word filtering because it sounds so 81 00:03:55,680 --> 00:03:57,840 trivial, but in data science that's everything, isn't it? 82 00:03:57,960 --> 00:04:01,280 It's the whole game, you can't just feed it every single repo 83 00:04:01,280 --> 00:04:03,160 on GitHub, that would be a disaster. 84 00:04:03,160 --> 00:04:04,800 Why? What's wrong with the data on 85 00:04:04,800 --> 00:04:06,840 GitHub? Well, a lot of it is auto 86 00:04:06,840 --> 00:04:09,880 generated. Think of those massive compiled 87 00:04:09,880 --> 00:04:13,280 JavaScript files or configuration dumps. 88 00:04:13,560 --> 00:04:16,680 It's repetitive and it's very low quality information. 89 00:04:16,680 --> 00:04:19,320 It's noise. OK, so they stripped that out. 90 00:04:19,320 --> 00:04:22,320 They stripped that out. They also removed files that had 91 00:04:22,320 --> 00:04:26,640 super long lines, like over 1000 characters, because that's 92 00:04:26,640 --> 00:04:29,160 usually just data storage, not actual logic. 93 00:04:29,200 --> 00:04:31,240 Right, like a big Jason BLOB or something. 94 00:04:31,240 --> 00:04:33,400 Exactly. And most importantly, they 95 00:04:33,400 --> 00:04:35,840 filtered for quality to some extent, which we'll get into 96 00:04:35,840 --> 00:04:37,880 later when we talk about the Codex S version. 97 00:04:38,120 --> 00:04:42,320 But just the sheer volume here is the first big differentiator 98 00:04:42,320 --> 00:04:44,440 from GPD 3. But here's where it gets really 99 00:04:44,440 --> 00:04:46,000 interesting for the engineers listening. 100 00:04:46,480 --> 00:04:50,000 You can't just feed code into a text model without changing how 101 00:04:50,000 --> 00:04:52,120 the model reads, can you? No, you can't. 102 00:04:52,160 --> 00:04:53,720 We have to talk about the tokenizer. 103 00:04:53,760 --> 00:04:56,680 This is such a crucial piece of engineering that I think most 104 00:04:56,680 --> 00:04:59,680 people just totally overlook. So what is a tokenizer, 105 00:04:59,840 --> 00:05:01,640 honestly? Large language models. 106 00:05:01,640 --> 00:05:05,600 They don't read words like cat or print, they read tokens, 107 00:05:05,600 --> 00:05:09,520 which are just chunks of characters and the standard text 108 00:05:09,520 --> 00:05:11,960 tokenizers like the one in Jeeple T3. 109 00:05:12,240 --> 00:05:14,520 They're optimized for English sentences. 110 00:05:14,600 --> 00:05:17,880 So they're really good at encoding common words like the 111 00:05:18,000 --> 00:05:20,160 and, or, you know, suffixes like ING. 112 00:05:20,160 --> 00:05:23,000 Exactly. They're very efficient at that, 113 00:05:23,000 --> 00:05:26,280 but code isn't English. The whole distribution of 114 00:05:26,280 --> 00:05:28,080 characters is completely different. 115 00:05:28,080 --> 00:05:31,000 And in Python specifically, there's a very unique problem. 116 00:05:31,080 --> 00:05:32,840 White space. Because in Python, the 117 00:05:32,840 --> 00:05:35,920 indentation isn't just for looks, it's grammatical. 118 00:05:36,120 --> 00:05:38,000 It actually defines the scope of the code. 119 00:05:38,160 --> 00:05:42,480 Right, If you're using Java or C++ L, you have curly braces. 120 00:05:42,480 --> 00:05:44,600 You can mess up the spacing all you want and the compiler 121 00:05:44,600 --> 00:05:46,080 doesn't care. The code still runs. 122 00:05:46,080 --> 00:05:49,840 But in Python, 4 spaces versus 2 spaces completely changes the 123 00:05:49,840 --> 00:05:52,080 logic of the program. It's a different program now. 124 00:05:52,080 --> 00:05:55,280 A standard GPT 3 tokenizer is just terrible at this. 125 00:05:55,280 --> 00:05:57,680 It treats multiple spaces really inefficiently. 126 00:05:57,840 --> 00:06:01,080 If you have a heavily indented block of code, a standard 127 00:06:01,080 --> 00:06:04,320 tokenizer might burn through 5 or 6 different tokens just to 128 00:06:04,320 --> 00:06:07,000 represent the blank blank space. Before you even get to the 129 00:06:07,000 --> 00:06:09,440 actual code. Before the line even starts. 130 00:06:09,440 --> 00:06:13,160 And remember, these models have a limited context window, a 131 00:06:13,160 --> 00:06:15,960 limit on how much text they can remember at once. 132 00:06:16,160 --> 00:06:20,320 So wasting tokens on blank space is a huge performance hit. 133 00:06:20,400 --> 00:06:22,920 It's a massive hit. It's pushing the actual logic, 134 00:06:22,920 --> 00:06:25,520 the important stuff, out of the models memory. 135 00:06:25,520 --> 00:06:27,160 It's a waste of memory and compute. 136 00:06:27,320 --> 00:06:31,520 So what did they do for codecs? They modified the tokenizer. 137 00:06:31,600 --> 00:06:34,720 They added a specific set of new tokens that represent runs of 138 00:06:34,720 --> 00:06:36,120 white space of different lengths. 139 00:06:36,120 --> 00:06:39,640 So 2 spaces is its own token, 4 spaces is another token. 140 00:06:39,680 --> 00:06:42,360 Precisely 8 spaces is a token and so on. 141 00:06:42,480 --> 00:06:44,560 It's kind of like you're zip compressing the silence. 142 00:06:44,560 --> 00:06:47,560 That's a great analogy, and the paper notes that this single 143 00:06:47,560 --> 00:06:50,960 optimization allows the model to represent code using 144 00:06:50,960 --> 00:06:54,000 approximately 30% fewer. Tokens. 145 00:06:54,400 --> 00:06:57,640 That is a massive number. That means for the same amount 146 00:06:57,640 --> 00:07:01,640 of computing power, the model can see 30% more of your code 147 00:07:01,640 --> 00:07:02,400 base. Correct. 148 00:07:02,560 --> 00:07:04,160 It can. Look further back in your file 149 00:07:04,160 --> 00:07:06,480 to understand the context of what you're trying to build. 150 00:07:06,480 --> 00:07:11,280 It's not just some efficiency hack, it is a capability unlock. 151 00:07:11,400 --> 00:07:15,040 Because if the model can see the function definition from 50 152 00:07:15,040 --> 00:07:18,360 lines ago because it saves space on indentation. 153 00:07:18,400 --> 00:07:20,400 It's going to write better code, it's just that simple. 154 00:07:20,600 --> 00:07:23,480 OK, so we have a modeled trained on billions of lines of code 155 00:07:23,960 --> 00:07:25,920 with a tokenizer that's optimized to read it 156 00:07:25,920 --> 00:07:28,280 efficiently. Now comes the hard part. 157 00:07:29,200 --> 00:07:31,800 The evaluation problem How? Do you know if it's actually any 158 00:07:31,800 --> 00:07:34,040 good? This is where the paper really 159 00:07:34,040 --> 00:07:36,720 shifts the paradigm for the entire industry. 160 00:07:36,960 --> 00:07:39,600 So in traditional natural language processing, we'd rely 161 00:07:39,600 --> 00:07:41,920 on metrics like the Bleu score, right? 162 00:07:42,000 --> 00:07:46,040 Bleu. Yes, and VLEU is essentially a 163 00:07:46,040 --> 00:07:49,160 text matching score. It's pretty simple if I ask a 164 00:07:49,160 --> 00:07:52,640 translation model to translate the cat sat on the mat into 165 00:07:52,640 --> 00:07:55,800 French and I have a reference translation from a human. 166 00:07:56,040 --> 00:07:57,520 You just see how much they overlap. 167 00:07:57,520 --> 00:08:00,240 You just check how much the machine's output overlaps with 168 00:08:00,240 --> 00:08:02,920 the human's output. The more matching sequences of 169 00:08:02,920 --> 00:08:04,680 words and grams, the higher the score. 170 00:08:04,680 --> 00:08:06,320 Which makes perfect sense for language. 171 00:08:06,640 --> 00:08:09,720 The cat sat on the mat and the cat sat on the rug are very 172 00:08:09,720 --> 00:08:11,400 close in meaning and in structure. 173 00:08:11,600 --> 00:08:13,440 But code is fragile. It's brittle. 174 00:08:14,200 --> 00:08:15,800 Let me give you the example from the paper. 175 00:08:16,360 --> 00:08:21,920 Suppose the correct code to solve a problem is X = y + Z OK. 176 00:08:22,040 --> 00:08:25,320 Simle addition. Now imagine the model outputs X 177 00:08:25,320 --> 00:08:28,400 = Z + y. Textually, that's different. 178 00:08:28,920 --> 00:08:30,960 The Z and the Y have swapped places. 179 00:08:31,200 --> 00:08:34,919 A text matching metric like Bleu would see that the order is 180 00:08:34,919 --> 00:08:36,760 wrong and penalize it. Exactly. 181 00:08:36,760 --> 00:08:39,559 The Bleu score would drop, but functionally. 182 00:08:39,559 --> 00:08:41,760 It's identical. It's perfect addition is 183 00:08:41,760 --> 00:08:44,240 commutative. The code works 100%. 184 00:08:44,480 --> 00:08:46,160 The computer doesn't care about the order. 185 00:08:46,160 --> 00:08:49,200 OK, so now imagine the reverse. Let's say the model outputs 186 00:08:49,280 --> 00:08:52,280 XAYZ. Well that looks almost identical 187 00:08:52,280 --> 00:08:55,120 to the correct answer. The text match is incredibly 188 00:08:55,120 --> 00:08:56,960 high. It's just one character off. 189 00:08:57,120 --> 00:09:01,080 The Bleu score would be near perfect, probably a 99% match. 190 00:09:01,200 --> 00:09:02,720 But the logic is completely wrong. 191 00:09:02,720 --> 00:09:05,080 It subtracts instead of ads. It's a totally different 192 00:09:05,080 --> 00:09:09,080 program, or even worse, imagine it just misses a single colon at 193 00:09:09,080 --> 00:09:10,600 the end of a function definition. 194 00:09:10,600 --> 00:09:12,600 The program crashes. It won't even compile. 195 00:09:12,600 --> 00:09:15,720 It won't even run. It's a syntax error and yet to a 196 00:09:15,720 --> 00:09:18,280 text matching algorithm it looks like a master piece. 197 00:09:18,280 --> 00:09:21,920 It's a 99.9% match. So the researchers found that 198 00:09:22,000 --> 00:09:26,040 high Bleu scores just didn't correlate with working code. 199 00:09:26,040 --> 00:09:28,560 They explicitly found that the correlation was weak. 200 00:09:28,920 --> 00:09:32,760 You could optimize a model to get a really high Bleu score and 201 00:09:32,760 --> 00:09:34,840 it would produce code that looked like code. 202 00:09:35,600 --> 00:09:38,400 It had the right variable names and the right structure, but it 203 00:09:38,400 --> 00:09:40,720 just didn't function. It was what they called cargo 204 00:09:40,720 --> 00:09:42,000 cult programming. Exactly. 205 00:09:42,000 --> 00:09:44,200 It's going through the motions without understanding the 206 00:09:44,200 --> 00:09:47,000 substance. So Open AI had to just abandoned 207 00:09:47,000 --> 00:09:49,600 the standard NLP metrics. They needed a metric that 208 00:09:49,600 --> 00:09:51,800 actually measured software quality. 209 00:09:51,800 --> 00:09:53,560 And they moved to functional correctness. 210 00:09:54,400 --> 00:09:56,920 They effectively applied the principles of Test Driven 211 00:09:56,920 --> 00:10:00,560 Development to AI evaluation. And to do that, they built a new 212 00:10:00,560 --> 00:10:03,040 benchmark. Yes, a benchmark called Human 213 00:10:03,040 --> 00:10:05,160 Evil. Tell us about human evil. 214 00:10:05,280 --> 00:10:06,600 Why did they have to build a new one? 215 00:10:06,600 --> 00:10:10,160 I mean why not just use problems from say leet code or hacker 216 00:10:10,160 --> 00:10:12,000 rank? Data contamination. 217 00:10:12,000 --> 00:10:14,400 It's a huge, huge issue in machine learning. 218 00:10:15,120 --> 00:10:17,600 Remember, the model was strained on all of GitHub. 219 00:10:18,200 --> 00:10:21,920 It is almost certainly seen every solution to every popular 220 00:10:21,920 --> 00:10:24,680 leak code problem ever posted. So if you tested on those 221 00:10:24,680 --> 00:10:26,960 problems. You aren't testing its ability 222 00:10:26,960 --> 00:10:29,880 to code, you're just testing its ability to memorize. 223 00:10:30,080 --> 00:10:32,800 It's like giving a student the exam questions a month 224 00:10:32,800 --> 00:10:34,200 beforehand. Exactly. 225 00:10:34,200 --> 00:10:38,400 So what the Open AI researchers did was they handwrote 164 brand 226 00:10:38,400 --> 00:10:41,800 new programming problems. These are problems the model has 227 00:10:41,800 --> 00:10:44,880 never ever seen before. And what's in each problem? 228 00:10:45,080 --> 00:10:47,560 Each one has a function signature, a dock string that 229 00:10:47,560 --> 00:10:51,120 explains what needs to happen, and this is the absolute key, a 230 00:10:51,120 --> 00:10:54,400 suite of unit tests. And the rule is simple, it 231 00:10:54,440 --> 00:10:56,560 either passes all the tests or it fails. 232 00:10:56,680 --> 00:11:00,080 Zero or one, black and white. There's no partial credit for 233 00:11:00,080 --> 00:11:03,880 looking nice or being close. And this binary success fail 234 00:11:03,880 --> 00:11:07,240 criteria leads us to the most important metric in the entire 235 00:11:07,240 --> 00:11:10,680 paper, the metric that really defines the current state of AI 236 00:11:10,680 --> 00:11:13,240 coding. We are talking about pass at K. 237 00:11:13,480 --> 00:11:17,200 Pass at Ki think for a lot of people just seeing K in a metric 238 00:11:17,200 --> 00:11:20,160 name brings back some bad memories of Alger class. 239 00:11:20,240 --> 00:11:22,400 Yeah, probably. So let's break this down 240 00:11:22,400 --> 00:11:24,760 conceptually. Why do we even need a variable 241 00:11:24,760 --> 00:11:26,320 there? Why not just pass or fail? 242 00:11:26,440 --> 00:11:29,320 Because these models are probabilistic, they are non 243 00:11:29,320 --> 00:11:32,480 deterministic. If you ask codecs to write a 244 00:11:32,480 --> 00:11:37,040 function to sort a list of names 5 different times, you might get 245 00:11:37,040 --> 00:11:38,920 5 slightly different pieces of code. 246 00:11:39,040 --> 00:11:41,000 So we can't just ask does it work? 247 00:11:41,120 --> 00:11:43,560 No, we have to ask how often does it work? 248 00:11:43,640 --> 00:11:46,320 That's the right question, so pass at Tay answers this. 249 00:11:46,760 --> 00:11:50,640 If I let the model generate a color number of solutions, let's 250 00:11:50,640 --> 00:11:54,240 say 100 different solutions, what is the probability that at 251 00:11:54,240 --> 00:11:56,880 least one of them is correct? At least one. 252 00:11:57,720 --> 00:11:59,960 OK, that sounds like a very generous metric, doesn't it? 253 00:12:00,200 --> 00:12:04,120 If I'm a developer, I don't want to have to dig through 99 broken 254 00:12:04,120 --> 00:12:05,960 snippets just to find the one that works. 255 00:12:06,280 --> 00:12:08,960 You would think so, but let's think about how these tools are 256 00:12:08,960 --> 00:12:10,520 actually deployed in the real world. 257 00:12:10,520 --> 00:12:13,640 When you use an auto complete in your IDE it often gives you a 258 00:12:13,640 --> 00:12:15,520 drop down list of suggestions, right? 259 00:12:15,640 --> 00:12:17,360 You get a few options. Or if you're using a chat 260 00:12:17,360 --> 00:12:19,400 interface, you can just hit the regenerate button. 261 00:12:19,400 --> 00:12:22,160 True, if the first one looks wrong, I just hit the button 262 00:12:22,160 --> 00:12:25,160 again. Right, so from a user experience 263 00:12:25,160 --> 00:12:28,560 perspective, if the model generates the correct code 264 00:12:28,560 --> 00:12:31,600 within the top few tries, the user is happy, they can 265 00:12:31,600 --> 00:12:33,920 recognize the right solution, they accept it, and they move 266 00:12:33,920 --> 00:12:36,400 on. So pass it K is really measuring 267 00:12:36,400 --> 00:12:39,200 the hit rate of the models brainstorming process. 268 00:12:39,280 --> 00:12:43,080 That's a great way to put it. It treats the AI as a generator 269 00:12:43,080 --> 00:12:46,040 of candidates, not as a sole source of truth. 270 00:12:46,200 --> 00:12:49,240 Now, there's a specific engineer's note in the paper 271 00:12:49,240 --> 00:12:52,040 about how they calculate this. It's not as simple as just 272 00:12:52,040 --> 00:12:54,120 running it 100 times and dividing dividing by 100. 273 00:12:54,120 --> 00:12:57,200 No, that would be incredibly computationally expensive and 274 00:12:57,200 --> 00:13:00,160 also statistically noisy. They use what's called an 275 00:13:00,160 --> 00:13:03,440 unbiased estimator. It's a bit of math gymnastics, 276 00:13:03,480 --> 00:13:05,840 but it's really important for getting an accurate number. 277 00:13:05,840 --> 00:13:07,920 Can you give us the simplified version? 278 00:13:07,920 --> 00:13:09,960 Sure. Essentially what they do is they 279 00:13:09,960 --> 00:13:12,200 generate a large pool of samples upfront. 280 00:13:12,600 --> 00:13:15,640 Let's say they generate 200 samples, so an equals $200. 281 00:13:16,120 --> 00:13:17,960 Then they run the tests and check how many of those are 282 00:13:17,960 --> 00:13:19,360 correct. Let's call that number 2. 283 00:13:19,720 --> 00:13:22,040 OK, so you have your big pool of answers. 284 00:13:22,160 --> 00:13:25,160 Then instead of running a whole new experiment for every single 285 00:13:25,160 --> 00:13:28,680 value of Calor, they just use a combinant torques formula to 286 00:13:28,680 --> 00:13:31,120 calculate the probability. Right, the one in the paper is 287 00:13:31,240 --> 00:13:34,480 $1.00 Frack Banal Deitman. Exactly, and without getting out 288 00:13:34,480 --> 00:13:37,800 the chalkboard, the intuition there is that it's calculating 289 00:13:37,800 --> 00:13:41,000 the probability of picking purely wrong answers. 290 00:13:41,000 --> 00:13:44,840 So it's asking, if I reached into this bag of 200 samples and 291 00:13:44,840 --> 00:13:48,440 pulled out, say, 10 samples, what are the odds that every 292 00:13:48,440 --> 00:13:50,760 single one of them is a failure? Precisely. 293 00:13:50,920 --> 00:13:53,280 And then you just subtract that number from 1:00 to get the 294 00:13:53,280 --> 00:13:56,520 probability of success. And if the probability of 295 00:13:56,520 --> 00:14:00,440 getting all failures is low, then the probability of finding 296 00:14:00,440 --> 00:14:02,640 at least one success must be high. 297 00:14:02,720 --> 00:14:04,720 Correct. It lets them report very 298 00:14:04,720 --> 00:14:07,640 accurate statistics for any value of tellers without having 299 00:14:07,640 --> 00:14:09,440 to run an infinite number of tests. 300 00:14:09,720 --> 00:14:13,000 It's a standard statistical method for sampling without 301 00:14:13,000 --> 00:14:15,680 replacement, just applied here to software generation. 302 00:14:15,800 --> 00:14:19,320 So let's get to the scoreboard using this very rigorous pass at 303 00:14:19,320 --> 00:14:22,320 Co metric. How did codecs actually perform 304 00:14:22,360 --> 00:14:25,560 on the Human Evil benchmark? OK, first the baseline. 305 00:14:25,600 --> 00:14:28,200 Let's talk about the original GPT 3 model. 306 00:14:28,320 --> 00:14:31,080 How did it do? It solved 0% of the problems. 307 00:14:31,080 --> 00:14:34,320 Zero as in none. Effectively 0. 308 00:14:34,440 --> 00:14:37,400 It just could not handle the functional logic constraints. 309 00:14:38,000 --> 00:14:40,360 Like we said, it might write a nice poem about the code, but it 310 00:14:40,360 --> 00:14:41,680 couldn't actually write the code. 311 00:14:41,720 --> 00:14:44,600 OK, So what about codecs? Now looking at codecs, 312 00:14:44,600 --> 00:14:48,320 specifically the 12 billion parameter version, on the very 313 00:14:48,320 --> 00:14:53,600 first try which is pass at one, it solved 28.8% of the problems. 314 00:14:53,600 --> 00:14:57,400 28.8% that is. Well, it's not taking anyone's 315 00:14:57,400 --> 00:14:59,400 job just yet. That's a failure rate of over 316 00:14:59,400 --> 00:15:02,840 70% on the first guess. It's AC minus student at best. 317 00:15:03,400 --> 00:15:06,440 But, and this is a huge but, this is where that pass at K 318 00:15:06,440 --> 00:15:08,400 logic kicks in. What happens if we give it a 319 00:15:08,400 --> 00:15:10,360 hundred tries? What's the number for tasks at 320 00:15:10,360 --> 00:15:12,240 100? If you let it generate 100 321 00:15:12,240 --> 00:15:14,560 different samples, and specifically if you use the more 322 00:15:14,560 --> 00:15:17,880 fine-tuned Codex S model which we'll talk about, the success 323 00:15:17,880 --> 00:15:20,960 rate shoots up to 77.5%. Wow. 324 00:15:21,160 --> 00:15:23,240 OK, that is a staggering difference. 325 00:15:23,240 --> 00:15:26,680 We go from barely functional to solving more than three out of 326 00:15:26,680 --> 00:15:28,840 every 4 problems. It tells us something really 327 00:15:28,840 --> 00:15:30,840 profound about the nature of these models. 328 00:15:30,840 --> 00:15:33,480 They aren't oracles of truth, they're idea generators. 329 00:15:33,720 --> 00:15:35,640 They contain the knowledge to solve the problem. 330 00:15:35,720 --> 00:15:38,400 Yes, but they have trouble focusing on the exact right 331 00:15:38,400 --> 00:15:42,120 syntax in a single shot. But if you let them just shotgun 332 00:15:42,120 --> 00:15:44,960 the problem with a bunch of attempts, they almost certainly 333 00:15:44,960 --> 00:15:47,640 find the answer somewhere in that spray. 334 00:15:47,720 --> 00:15:51,120 Which brings us to a really practical dilemma for the user, 335 00:15:51,120 --> 00:15:53,880 for the developer. If I need to generate 100 336 00:15:53,880 --> 00:15:57,320 samples to find the right one, how do I configure the model? 337 00:15:57,680 --> 00:16:00,680 I mean, if I just ask the same question 100 times, won't it 338 00:16:00,680 --> 00:16:02,240 just give me the same wrong answer 100? 339 00:16:02,240 --> 00:16:05,240 Times it would, yes, unless you tune the temperature. 340 00:16:05,360 --> 00:16:08,120 This is section four of our digest the Concept of 341 00:16:08,120 --> 00:16:11,120 Temperature in AI. Temperature is a hyper parameter 342 00:16:11,120 --> 00:16:13,800 that controls the randomness of the model's next token 343 00:16:13,800 --> 00:16:16,200 prediction. It's basically a knob that you 344 00:16:16,200 --> 00:16:19,160 can turn to adjust how adventurous or creative the 345 00:16:19,160 --> 00:16:22,080 model is allowed to be. Let's define the extremes. 346 00:16:22,240 --> 00:16:23,800 What does a low temperature look like? 347 00:16:23,800 --> 00:16:27,840 What does that do? A low temperature, let's say .0 348 00:16:27,840 --> 00:16:30,960 or 0.2, makes the model very conservative. 349 00:16:31,200 --> 00:16:34,000 When it predicts the next word or the next token, it looks at 350 00:16:34,000 --> 00:16:36,960 the probability distribution and it almost always just picks the 351 00:16:36,960 --> 00:16:38,400 top winner. It's greedy. 352 00:16:38,560 --> 00:16:40,840 It plays it safe, it doesn't take any risks. 353 00:16:40,880 --> 00:16:42,880 Very safe. It's almost deterministic. 354 00:16:42,880 --> 00:16:46,280 If you run the same prompt 10 times that temperature 0, you're 355 00:16:46,280 --> 00:16:48,320 going to get the same exact code 10 times. 356 00:16:48,640 --> 00:16:51,440 It just locks in on what it thinks is the most likely path 357 00:16:51,440 --> 00:16:53,600 and sticks to it. OK, So what about high 358 00:16:53,600 --> 00:16:56,720 temperature? A high temperature like .8 or 359 00:16:56,720 --> 00:16:59,520 even 1.0 flattens that probability curve. 360 00:16:59,920 --> 00:17:02,840 It makes the model much more willing to take risks. 361 00:17:02,840 --> 00:17:05,920 It might pick the second most likely token, or the third, or 362 00:17:05,920 --> 00:17:09,000 even the 10th. This introduces variation. 363 00:17:09,000 --> 00:17:11,800 It gets creative. Creative or sometimes it 364 00:17:11,800 --> 00:17:13,800 hallucinates depending on how you look at it. 365 00:17:14,160 --> 00:17:17,079 Now the paper presents a crucial strategy guide for this. 366 00:17:17,400 --> 00:17:20,599 The optimal temperature to use depends entirely on your taller 367 00:17:20,599 --> 00:17:22,880 strategy. So if I only have one shot if my 368 00:17:22,880 --> 00:17:24,319 Telugu was one, what should I do? 369 00:17:24,359 --> 00:17:25,960 You use low temperature? Absolutely. 370 00:17:25,960 --> 00:17:28,960 If you only get one guess, you want the models absolute best, 371 00:17:28,960 --> 00:17:31,280 most confident guess. You don't want it experimenting 372 00:17:31,280 --> 00:17:33,560 on your time, you want the highest probability. 373 00:17:33,560 --> 00:17:36,200 Path. But if I have 100 shots if Kalu 374 00:17:36,200 --> 00:17:39,160 equals 100. Then you absolutely must use 375 00:17:39,160 --> 00:17:42,120 high temperature. Think about it, if you use a low 376 00:17:42,120 --> 00:17:46,080 temperature for 100 samples, you just get 100 copies of the same 377 00:17:46,080 --> 00:17:49,680 potentially wrong piece of code that's totally useless. 378 00:17:49,680 --> 00:17:51,600 You need diversity. You need diversity. 379 00:17:51,960 --> 00:17:55,240 By cranking the temperature up to .8, you force the model to 380 00:17:55,240 --> 00:17:58,320 try different approaches. Sure, maybe fifty of those 381 00:17:58,320 --> 00:18:01,400 samples will be complete gibberish or syntax errors 382 00:18:01,400 --> 00:18:05,000 because it took a weird risk, but five of them might be 383 00:18:05,000 --> 00:18:08,640 brilliant, novel solutions that solve the problem in a way you 384 00:18:08,640 --> 00:18:10,600 didn't expect. It's the difference between 385 00:18:10,600 --> 00:18:13,640 asking one expert for their single best piece of advice 386 00:18:14,080 --> 00:18:16,960 versus asking a whole room full of people to just brainstorm 387 00:18:16,960 --> 00:18:18,520 wild ideas. Precisely. 388 00:18:18,640 --> 00:18:21,200 And for code generation, the paper proves that the 389 00:18:21,200 --> 00:18:24,080 brainstorming approach yields significantly better results. 390 00:18:24,080 --> 00:18:27,560 That's how you get to that 77.5% success rate we mentioned. 391 00:18:27,560 --> 00:18:29,800 This creates a new problem, a very practical 1. 392 00:18:29,920 --> 00:18:32,800 The selection problem. Right, in the research lab they 393 00:18:32,800 --> 00:18:36,240 had the unit tests. So they can generate 100 crazy 394 00:18:36,240 --> 00:18:38,560 ideas, run them all against the tests and just see which ones 395 00:18:38,560 --> 00:18:40,600 pass. But if I'm a developer sitting 396 00:18:40,600 --> 00:18:43,760 in VS Code, I don't have a unit test for the function I haven't 397 00:18:43,760 --> 00:18:45,160 even written yet. Exactly. 398 00:18:45,480 --> 00:18:47,440 This is what's called the Oracle problem. 399 00:18:47,800 --> 00:18:50,280 The model generates 100 options in the background. 400 00:18:50,440 --> 00:18:54,000 It knows one of them is probably right, but how does it know 401 00:18:54,000 --> 00:18:57,200 which one to actually show you? It can't run the code itself. 402 00:18:57,360 --> 00:19:01,120 So they need a heuristic, a way to guess which code is the 403 00:19:01,120 --> 00:19:03,160 winner without actually running it. 404 00:19:03,440 --> 00:19:05,440 And the paper explores a few of these. 405 00:19:05,560 --> 00:19:09,560 The most robust one they found is mean log probability. 406 00:19:10,080 --> 00:19:15,560 Can you put that in English for? It its confidence, the model 407 00:19:15,560 --> 00:19:18,560 assigns A probability score to every single token it generates. 408 00:19:18,640 --> 00:19:21,160 If you average all those scores across the whole snippet of 409 00:19:21,160 --> 00:19:23,320 code, you get a kind of confidence score. 410 00:19:23,640 --> 00:19:25,120 So it's basically the model saying. 411 00:19:25,400 --> 00:19:28,360 I felt really sure about this code when I was writing it, 412 00:19:28,360 --> 00:19:29,040 yeah. That's it. 413 00:19:29,520 --> 00:19:33,240 So the heuristic is you show the user the one the AI felt best 414 00:19:33,240 --> 00:19:36,280 about, and it's a pretty good proxy for correctness. 415 00:19:36,400 --> 00:19:39,360 It helps filter out that high temperature nonsense where the 416 00:19:39,360 --> 00:19:41,680 model took a wild risk and just got confused. 417 00:19:41,760 --> 00:19:44,720 If the model is kind of mumbling its way through the code with 418 00:19:44,720 --> 00:19:47,800 low confidence on every token, you probably shouldn't show that 419 00:19:47,800 --> 00:19:49,240 one to the user. Probably not. 420 00:19:49,680 --> 00:19:52,200 They also mentioned a really clever technique that involves 421 00:19:52,200 --> 00:19:54,680 dock strings. This is what they called Codex 422 00:19:54,680 --> 00:19:57,040 D, right? The D is for dock string. 423 00:19:57,040 --> 00:20:00,680 Yes, this part is fascinating. So far we've only talked about 424 00:20:00,680 --> 00:20:03,280 text to code. Codex D is a model that's 425 00:20:03,280 --> 00:20:05,880 fine-tuned for the reverse code to text. 426 00:20:05,880 --> 00:20:09,680 It reads a piece of code and then explains in plain English 427 00:20:09,800 --> 00:20:11,720 what it does. Right, it generates the doc 428 00:20:11,720 --> 00:20:14,000 string. So here's a way you could verify 429 00:20:14,000 --> 00:20:17,240 your code without needing any unit tests back translation. 430 00:20:17,320 --> 00:20:19,680 OK, how does that work? It's a round trip verification. 431 00:20:19,800 --> 00:20:23,240 So step one, take your prompt, write a Python function to 432 00:20:23,240 --> 00:20:27,560 calculate the area of a circle. Step 2, the model generates a 433 00:20:27,560 --> 00:20:30,720 code snippet. Step three, you take that code 434 00:20:30,720 --> 00:20:34,080 snippet that it just generated and you feed it back into Codex 435 00:20:34,080 --> 00:20:36,680 D and ask, hey, what does this code do? 436 00:20:36,960 --> 00:20:41,360 And Step 4, Codex D writes a new doc string a new explanation. 437 00:20:41,480 --> 00:20:44,640 And then you compare you compare the new explanation to your 438 00:20:44,640 --> 00:20:47,320 original request. If the model looks at its own 439 00:20:47,320 --> 00:20:50,960 code and says this function calculates the perimeter of a 440 00:20:50,960 --> 00:20:53,840 square, then you know the code is wrong. 441 00:20:53,840 --> 00:20:56,000 It drifted from the original intent. 442 00:20:56,000 --> 00:20:59,240 But if it says this function takes a radius and calculates 443 00:20:59,240 --> 00:21:02,680 the area of a circle, then the intent was preserved. 444 00:21:02,680 --> 00:21:05,640 Exactly, It's a semantic check. The paper does note that this 445 00:21:05,640 --> 00:21:08,440 successfully filters out a lot of bad code, though. 446 00:21:08,440 --> 00:21:11,440 Surprisingly, it wasn't quite as effective as the simple mean log 447 00:21:11,440 --> 00:21:13,720 probability heuristic. But it shows the direction 448 00:21:13,720 --> 00:21:15,080 researchers are going. Totally. 449 00:21:15,080 --> 00:21:19,320 It's using AI to grade AI. It's mimicking how a human might 450 00:21:19,320 --> 00:21:22,000 double check their own work. Wait, does this code actually do 451 00:21:22,000 --> 00:21:24,240 what I wanted it to do? I want to circle back to 452 00:21:24,240 --> 00:21:26,600 something you mentioned earlier. You said codecs. 453 00:21:26,720 --> 00:21:28,840 You mentioned filtering the training data, right? 454 00:21:28,880 --> 00:21:31,520 This is the supervised fine tuning version. 455 00:21:31,560 --> 00:21:34,640 And we know GitHub is a a messy place. 456 00:21:34,840 --> 00:21:36,680 It is. It's full of half finished 457 00:21:36,680 --> 00:21:40,240 projects, homework assignments that probably got AC minus and 458 00:21:40,240 --> 00:21:43,160 just, you know, bad coding habits that have been copied and 459 00:21:43,160 --> 00:21:45,360 pasted for a decade. Lot of spaghetti code. 460 00:21:45,400 --> 00:21:47,520 A ton. So if you train the model on 461 00:21:47,520 --> 00:21:49,800 everything, it learns the bad habits too. 462 00:21:49,800 --> 00:21:53,120 It learns to write inefficient loops, or to use terrible 463 00:21:53,120 --> 00:21:56,000 variable names like temp one and temp two. 464 00:21:56,320 --> 00:21:58,680 It learns to write code that doesn't even compile. 465 00:21:58,680 --> 00:22:01,920 So for cut excess, they changed the diet, they got pickier. 466 00:22:01,920 --> 00:22:04,440 Much pickier. They identified high quality 467 00:22:04,440 --> 00:22:06,360 code. They didn't just grab random 468 00:22:06,360 --> 00:22:08,640 files from GitHub. They specifically looked for 469 00:22:08,640 --> 00:22:11,280 standalone functions that could be compiled and run. 470 00:22:11,280 --> 00:22:13,040 Where do they find this good code? 471 00:22:13,560 --> 00:22:17,080 They prioritize code from 2 main sources, competitive programming 472 00:22:17,080 --> 00:22:19,760 websites where solutions are almost always correct and highly 473 00:22:19,760 --> 00:22:22,720 optimized, and from repositories that had heavy continuous 474 00:22:22,720 --> 00:22:26,800 integration or CI testing. So code that is proven to work. 475 00:22:26,800 --> 00:22:29,640 Proven and clean and the impact was significant. 476 00:22:29,640 --> 00:22:32,920 Standard codec solved 28.8% of problems on the first try. 477 00:22:32,920 --> 00:22:36,480 Pass at 1:00. Kodak staff solved 37.7%. 478 00:22:36,480 --> 00:22:38,520 Well, that's nearly A10 percentage point jump just by 479 00:22:38,520 --> 00:22:41,480 cleaning up the data. It really reinforces the golden 480 00:22:41,480 --> 00:22:45,480 rule of AI. Data quality almost always beats 481 00:22:45,480 --> 00:22:48,720 sheer data quantity. You want the model to learn from 482 00:22:48,720 --> 00:22:51,240 the senior engineers, not from the interns. 483 00:22:51,480 --> 00:22:54,800 OK, we've covered the tech. The model is powerful, it's 484 00:22:54,800 --> 00:22:57,520 efficient. But is it safe? 485 00:22:58,160 --> 00:23:00,920 Section 6. The paper covers limitations and 486 00:23:00,920 --> 00:23:04,200 risks, and frankly, there are some serious engineering red 487 00:23:04,200 --> 00:23:07,160 flags here. There really are, and for anyone 488 00:23:07,160 --> 00:23:09,720 thinking about deploying this in an enterprise environment, you 489 00:23:09,880 --> 00:23:11,560 absolutely need to listen to this part. 490 00:23:11,800 --> 00:23:15,320 Let's start with what they call alignment failure, or as I was 491 00:23:15,320 --> 00:23:17,480 thinking of it, the bad influence problem. 492 00:23:17,720 --> 00:23:19,440 This is from the Settle bug experiment. 493 00:23:19,440 --> 00:23:22,240 The researchers wanted to know, does the model always try to 494 00:23:22,240 --> 00:23:25,560 write the best possible code? You would assume it would You 495 00:23:25,560 --> 00:23:27,240 assume it's trying to be helpful and correct. 496 00:23:27,440 --> 00:23:29,280 But it's not. It's not trying to be helpful, 497 00:23:29,280 --> 00:23:32,000 it's trying to predict the next token based on the context it's 498 00:23:32,000 --> 00:23:34,360 given. So they ran this experiment 499 00:23:34,360 --> 00:23:36,880 where they gave the model a prompt that already included a 500 00:23:36,880 --> 00:23:38,360 bug. They wrote some sloppy, 501 00:23:38,360 --> 00:23:40,840 incorrect code in the setup part of the prompt. 502 00:23:40,880 --> 00:23:43,760 They set a bad example for it. And codecs followed it. 503 00:23:44,080 --> 00:23:47,720 Instead of fixing the bug or writing clean code, it produced 504 00:23:47,720 --> 00:23:51,080 more buggy code. It aligned with the sloppy style 505 00:23:51,080 --> 00:23:52,800 of the user. That is wild. 506 00:23:52,800 --> 00:23:55,320 It's like a chameleon. If you act incompetent in the 507 00:23:55,320 --> 00:23:58,000 prompt, it mimics incompetence back at you. 508 00:23:58,160 --> 00:23:59,800 The paper calls this misalignment. 509 00:24:00,320 --> 00:24:05,200 The user's actual content is help me write correct code, but 510 00:24:05,200 --> 00:24:08,120 the models objective is just match the distribution of the 511 00:24:08,120 --> 00:24:11,120 text provided. If that text looks like garbage, 512 00:24:11,120 --> 00:24:12,880 it generates more garbage to match. 513 00:24:12,880 --> 00:24:15,160 That feels like a massive trap, especially for junior 514 00:24:15,160 --> 00:24:17,040 developers. If you don't already know what 515 00:24:17,040 --> 00:24:19,760 you're doing, the AI will just validate your mistakes. 516 00:24:19,760 --> 00:24:22,280 It will amplify them. It gives you this false sense of 517 00:24:22,280 --> 00:24:25,200 confidence because the code it generates looks just like your 518 00:24:25,200 --> 00:24:26,840 code. OK, what about complexity? 519 00:24:26,840 --> 00:24:29,680 Can I ask codecs to, you know, build me a clone of Twitter? 520 00:24:29,800 --> 00:24:32,160 Not a chance. The performance drops off a 521 00:24:32,160 --> 00:24:35,520 Cliff as complexity increases. The paper shows this really 522 00:24:35,520 --> 00:24:38,840 clear graph of success rates for what they call chained 523 00:24:38,840 --> 00:24:40,760 components. Meaning what like do task A, 524 00:24:40,840 --> 00:24:43,960 then do task B, then do task C? Exactly. 525 00:24:44,040 --> 00:24:48,120 A prompt like read the data from this file, parse it as a CSV, 526 00:24:48,360 --> 00:24:51,040 sum the values in the third column and then print the 527 00:24:51,080 --> 00:24:53,120 average. A multi step process. 528 00:24:53,320 --> 00:24:56,240 As soon as you chain more than just a few operations like that, 529 00:24:56,320 --> 00:25:00,040 the model gets confused. It struggles with binding, with 530 00:25:00,040 --> 00:25:03,480 remembering which variable holds the data from step one while 531 00:25:03,480 --> 00:25:05,920 it's working on Step 3. So it has a short attention 532 00:25:05,920 --> 00:25:08,280 span. It's a sprinter, not a marathon 533 00:25:08,280 --> 00:25:10,520 runner. It is excellent at writing a 534 00:25:10,520 --> 00:25:14,000 single complex function. It is terrible at designing a 535 00:25:14,000 --> 00:25:17,680 multi part system architecture. Security is another big one. 536 00:25:18,160 --> 00:25:20,480 We hear about supply chain attacks constantly. 537 00:25:20,880 --> 00:25:24,600 Is Codex writing secure code? The findings in the paper are 538 00:25:25,240 --> 00:25:28,400 pretty concerning on this front. The researchers asked codecs to 539 00:25:28,400 --> 00:25:30,440 generate cryptographic configurations. 540 00:25:30,440 --> 00:25:32,400 You mean like encryption keys and settings? 541 00:25:32,400 --> 00:25:34,920 And it frequently generated insecure configurations. 542 00:25:34,920 --> 00:25:37,840 For example, it would often use RSA encryption keys with fewer 543 00:25:37,840 --> 00:25:41,080 than 2048 bits. Which is considered cracked or 544 00:25:41,080 --> 00:25:43,040 at least very weak by modern standards. 545 00:25:43,040 --> 00:25:45,440 Why on earth would it do that? Because it's trained on the 546 00:25:45,440 --> 00:25:48,720 Internet, and the Internet is absolutely full of tutorials 547 00:25:48,720 --> 00:25:51,800 from 2012 that use small keys. Because they are faster for 548 00:25:51,800 --> 00:25:54,280 demos and examples. So codecs doesn't know what year 549 00:25:54,280 --> 00:25:56,040 it is. It has no idea that NIST 550 00:25:56,040 --> 00:25:58,200 standards have changed. It just knows that 551 00:25:58,200 --> 00:26:01,200 statistically, after these words I usually see this number. 552 00:26:01,520 --> 00:26:04,480 It propagates obsolete security practices. 553 00:26:04,480 --> 00:26:08,120 So if you just copy paste security related code from an AI 554 00:26:08,240 --> 00:26:11,240 without having an expert audit it, you are very likely 555 00:26:11,240 --> 00:26:14,080 introducing vulnerabilities. Yes, you're just repeating the 556 00:26:14,080 --> 00:26:16,760 statistical average of the Internet, and the average code 557 00:26:16,760 --> 00:26:18,920 on the Internet is definitely not secure code. 558 00:26:19,240 --> 00:26:21,200 And finally, let's talk about bias. 559 00:26:21,640 --> 00:26:24,640 We often talk about this in terms of text and images, but 560 00:26:24,640 --> 00:26:27,920 does it manifest in code? It does, and in a really 561 00:26:27,920 --> 00:26:30,880 interesting way. Specifically, it manifests in 562 00:26:30,880 --> 00:26:32,880 the data structures the model creates. 563 00:26:33,080 --> 00:26:36,600 If you ask codecs to create a class for a person or a user, 564 00:26:36,600 --> 00:26:38,560 what happened? It often defaults to things like 565 00:26:38,560 --> 00:26:41,760 binary gender fields or very limited outdated racial 566 00:26:41,760 --> 00:26:44,000 categories. Because that's how databases 567 00:26:44,000 --> 00:26:46,200 were designed in the 90s and 2000s. 568 00:26:46,360 --> 00:26:49,040 Exactly. It's mirroring the structural 569 00:26:49,040 --> 00:26:51,360 biases of the legacy code it was trained on. 570 00:26:51,600 --> 00:26:54,480 It preserves the rigid categorization of the past. 571 00:26:54,760 --> 00:26:58,360 If your modern application needs more or inclusive data 572 00:26:58,360 --> 00:27:01,360 structures, codecs might actually fight you on it because 573 00:27:01,360 --> 00:27:03,920 it just hasn't seen enough examples of that new way of 574 00:27:03,920 --> 00:27:06,280 thinking yet. It's an artifact of the training 575 00:27:06,280 --> 00:27:09,120 datas age and distribution. A direct reflection 1. 576 00:27:09,120 --> 00:27:12,000 Last thing that people always ask about this stuff copyright. 577 00:27:12,240 --> 00:27:15,280 Is this thing just a big plagiarism machine? 578 00:27:15,280 --> 00:27:18,240 Is it just stealing code? The paper addresses this 579 00:27:18,240 --> 00:27:20,560 directly. They did a specific check for 580 00:27:20,560 --> 00:27:22,600 what they called literal copying. 581 00:27:22,600 --> 00:27:25,080 Verbatim copy paste from the training data. 582 00:27:25,120 --> 00:27:28,000 And they found that literal copying occurred in less than 583 00:27:28,240 --> 00:27:30,240 .1% of cases. That's. 584 00:27:30,240 --> 00:27:32,520 Extremely low. It's almost nothing, and when it 585 00:27:32,520 --> 00:27:35,800 did happen, it was almost always what you'd call boilerplate 586 00:27:36,120 --> 00:27:39,760 standard license headers or very common simple algorithms like 587 00:27:39,760 --> 00:27:42,760 quicksort that pretty much everyone writes the exact same 588 00:27:42,760 --> 00:27:43,440 way. So it acts. 589 00:27:43,520 --> 00:27:46,080 It's more like a synthesizer than a photocopier. 590 00:27:46,200 --> 00:27:47,680 That's a great way to describe it. 591 00:27:47,680 --> 00:27:50,960 It learns the patterns, but it rarely regurgitates the exact 592 00:27:50,960 --> 00:27:52,960 source file. So pulling all this together, 593 00:27:52,960 --> 00:27:55,960 we've looked at the specialized tokenizer, the big shift from 594 00:27:55,960 --> 00:28:00,480 Bleu to pass AK, the importance of temperature tuning, and all 595 00:28:00,480 --> 00:28:02,400 these risks of alignment and security. 596 00:28:02,760 --> 00:28:07,040 What is the final verdict here? The verdict is that codecs and 597 00:28:07,040 --> 00:28:11,120 tools like it are incredible productivity multipliers, but 598 00:28:11,120 --> 00:28:14,920 they fundamentally change the job description of a programmer. 599 00:28:14,920 --> 00:28:17,600 How so? The job is moving away from 600 00:28:17,600 --> 00:28:20,560 writing syntax and towards verifying intent. 601 00:28:20,640 --> 00:28:22,600 You're not the writer anymore, you're the editor. 602 00:28:22,640 --> 00:28:25,720 You're the architect and you are the quality assurance department 603 00:28:25,760 --> 00:28:29,080 all rolled into one. The pass at Hick metric proves 604 00:28:29,080 --> 00:28:31,280 that the AI is a candidate generator. 605 00:28:31,600 --> 00:28:35,000 It just gives you options. You, the human, must have the 606 00:28:35,000 --> 00:28:37,880 skill to look at those options and distinguish the diamond from 607 00:28:37,880 --> 00:28:39,440 the glass. That's a really powerful 608 00:28:39,440 --> 00:28:40,920 thought. It doesn't lower the bar for 609 00:28:40,920 --> 00:28:43,400 knowledge. In some ways, it actually raises 610 00:28:43,400 --> 00:28:45,200 the bar for critical thinking. It does. 611 00:28:45,200 --> 00:28:48,320 If you can't read code well, you can't safely use the tool that 612 00:28:48,320 --> 00:28:49,960 writes it for you. Exactly. 613 00:28:49,960 --> 00:28:52,640 You can't delegate the responsibility of correctness to 614 00:28:52,640 --> 00:28:54,200 the machine. Not yet. 615 00:28:54,440 --> 00:28:57,000 Before we wrap up, I want to leave our listeners with a 616 00:28:57,000 --> 00:28:59,640 thought that really struck me while I was reading the paper. 617 00:29:00,160 --> 00:29:03,280 They mentioned that codec struggles with dock strings 618 00:29:03,280 --> 00:29:05,600 describing long chains of operations. 619 00:29:06,400 --> 00:29:08,720 It can't handle infinite complexity yet. 620 00:29:08,920 --> 00:29:11,160 Right, the sprinter, not the marathon runner. 621 00:29:11,280 --> 00:29:13,480 But let's just assume Moore's Law holds. 622 00:29:13,840 --> 00:29:15,640 Assume the models get better and better. 623 00:29:15,880 --> 00:29:18,360 Assume they can eventually handle massive chained 624 00:29:18,360 --> 00:29:21,040 complexity perfectly. OK, where are you going with 625 00:29:21,040 --> 00:29:23,920 this? Well, today the doc string, the 626 00:29:23,920 --> 00:29:27,560 English explanation is just a comment, it's ignored by the 627 00:29:27,560 --> 00:29:29,880 machine. The code itself is the source of 628 00:29:29,880 --> 00:29:32,720 truth. But if the model gets perfect at 629 00:29:32,720 --> 00:29:36,360 translating English to code, does the code itself become 630 00:29:36,360 --> 00:29:38,520 invisible? That is the ultimate abstraction 631 00:29:38,520 --> 00:29:40,000 layer. If I can just write the dock 632 00:29:40,000 --> 00:29:43,400 string and the machine perfectly and reliably executes the logic, 633 00:29:43,680 --> 00:29:45,880 will we eventually lose the ability to even read the code 634 00:29:45,880 --> 00:29:48,160 entirely? Will Python just become the new 635 00:29:48,160 --> 00:29:50,440 assembly language, something only the machines look at? 636 00:29:50,440 --> 00:29:52,200 Well, we humans just write prompts. 637 00:29:52,360 --> 00:29:54,200 We might. The dock string would become the 638 00:29:54,200 --> 00:29:56,200 source code. The English language becomes the 639 00:29:56,200 --> 00:29:59,040 programming language. A world where we program in 640 00:29:59,040 --> 00:30:01,800 plain English. It's democratizing, it's 641 00:30:01,800 --> 00:30:05,480 exciting, and for those of us who kind of love the syntax, 642 00:30:06,680 --> 00:30:10,320 it's a little terrifying it. Makes verifying that intent the 643 00:30:10,320 --> 00:30:12,080 most valuable skill on the planet. 644 00:30:12,200 --> 00:30:14,960 Absolutely. Well, that is all for our 645 00:30:14,960 --> 00:30:17,720 Practical AI Digest on Open AI's codecs. 646 00:30:18,080 --> 00:30:20,120 We hope you have a much better understanding of the engine 647 00:30:20,120 --> 00:30:21,840 under the hood of your autocomplete now. 648 00:30:21,880 --> 00:30:25,320 And if you are a developer, go into your settings, try tuning 649 00:30:25,320 --> 00:30:27,880 that temperature parameter. See what happens when you crank 650 00:30:27,880 --> 00:30:30,320 it up to .8 on a really hard problem and. 651 00:30:30,320 --> 00:30:32,880 Let us know if you get any brilliant or just hilarious 652 00:30:32,880 --> 00:30:34,760 results. Thanks for listening to the deep 653 00:30:34,760 --> 00:30:35,880 dive. We'll see you next time.