It’s Tokens All The Way Down: How RLMs are Different — Kevin Madura, AlixPartners

AI Engineer · 20 min · 195 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

  1. 00:12Yep.
  2. 00:13Awesome.
  3. 00:14Thanks everyone for being here.
  4. 00:15My name is Kevin Madura.
  5. 00:17I'm from a company called Alex Partners.
  6. 00:18We're we're a consulting firm.
  7. 00:20Um I'm here to talk to you today about RLMs.
  8. 00:23Just curious, show of hands, who here is familiar with RLMs?
  9. 00:28So we know how much time to spend on it.
  10. 00:29Okay.
  11. 00:30So not many.
  12. 00:31All right.
  13. 00:31Well, that's good.
  14. 00:32So we'll start with what an RLM is and and why it's different.
  15. 00:36So RLM is recursive language model.
  16. 00:39And really the the key difference here is that it treats the context as an object that it can interact with symbolically in its environment.
  17. 00:48So it differs from a tool call in the sense that typically when you do a tool call it's JSON or some type of string that's being sent being interpreted elsewhere
  18. 00:59maybe by some other program and that's that's returning effectively as a string.
  19. 01:03The key difference here is that it's interacting with a symbolic environment.
  20. 01:08So typically that's a ripple Python ripple.
  21. 01:11Um so that's key difference number one.
  22. 01:14Key difference number two is that it's it has the ability to delegate to another LM often to itself.
  23. 01:20You can specify whether it's the same model or a different model, but fundamentally because it lives in this environment, you can offload or or make a sub call to another LM with particular parameters
  24. 01:31that also lives in that ripple environment.
  25. 01:34And so you get this ability to recursively decompose problems and apply and have the LLM basically decide how to apply certain logic or certain interpretations or write its own code to solve those problems
  26. 01:50and then that recurses down.
  27. 01:51So the subLM can do the same sort of thing in terms of understanding and interpreting what it thinks it needs to do.
  28. 01:57And I added this last one here.
  29. 01:59It's largely bitter lesson pilled in my opinion, right?
  30. 02:03is and and shared by Alex and the rest of the the creators of it.
  31. 02:06But as models get better, you should be able to defer more and more to the model for it to kind of figure out on its own what it needs to do.
  32. 02:17So the I don't know if this is the actual kind of starting point for RLMs.
  33. 02:22This is one that that I consider to be one of the the first kind of inklings of it.
  34. 02:26This is a tweet from Omar who is Alex's adviser um for for RLMs.
  35. 02:31And this was a concept that he had come up with where it was basically an ability to use DSPI and some other techniques to take in arbitrary um arbitrary length inputs.
  36. 02:43And basically the use case here would be summarizing an arbitrarily long document and coming up with a table of contents and some summary of of that content.
  37. 02:52But at least to me, this is kind of the first inkling of okay, context windows might not be something you need to deliberately manage.
  38. 03:00Although there's of course benefits to doing so, uh there there could be ways to um to exceed the the the context windows using some of these clever techniques.
  39. 03:10Uh and so if you read the paper and some of the blog posts that are out there from Alex and Omar, I mean it it it has demonstrabably better performance on some of these long context tasks.
  40. 03:20So, ulong is one benchmark where um the the intent of the benchmark it's is to measure model performance on answering questions about excessively long context.
  41. 03:30This another one browse comp where it needs to iterate through a large a large body and corpus of text and answer particular questions about it.
  42. 03:38You can see the blue line at the top there is the RLM.
  43. 03:41It's very good performance as compared to some of these other models.
  44. 03:45And even on on the price curve, the the purple is actually just using tool calling um with GBT5 calling a BM25 tool.
  45. 03:55And that's actually even more expensive for worse performance than than an RLM.
  46. 04:00So it's worth reading into if you're interested in in some of the benchmarks and how RLMs perform.
  47. 04:05Um but fundamentally uh an RLM again takes in your input and you're kind of deferring to the model about how to decompose the process what code it needs to write
  48. 04:15and it is very tightly integrated with the ripple itself.
  49. 04:19So it it by itself defines what it needs to do.
  50. 04:22And so I kind of had this mental model in terms of and I'm very DSP pipel if if you couldn't tell by now basically a student of of Omar and the rest of the group there where
  51. 04:32you have this relatively deterministic shell of what you want to do like what what is your intent what is your actual task that you're trying to accomplish.
  52. 04:41You define that in terms of your inputs and your outputs and some type of guidance or prompt or what have you to the model to say this is generally what I want to achieve.
  53. 04:50go off and do it.
  54. 04:52Here's the things that you can expect as your input.
  55. 04:54Here's what I want out of it.
  56. 04:55Go figure out the rest.
  57. 04:57And so this applies for using something like DSPI, but I think it applies to RLMs as well because you don't have to worry as much now about how the actual
  58. 05:07implementation works in the middle.
  59. 05:10You can just have some guarantees about the inputs and the outputs and you can let the model figure out the rest of of that part of it.
  60. 05:17So, a lot of this comes down to if if you were at um I think it was code in November in uh in New York City, Dex had this great talk about just broader context engineering and he he coined something like the dumb zone
  61. 05:29which it's kind of grayed out at the bottom there.
  62. 05:31But the point is that we all know that there's context rot, right?
  63. 05:35Once you fill up the context window to a certain degree, performance starts to degrade.
  64. 05:39And so RLMs somewhat get around this problem because the context itself doesn't fill up as quickly because you're deferring a lot of the subtasks to the subm models and it's
  65. 05:52the full kind of context and the inputs aren't exposed to the context window itself.
  66. 05:58It lives as a variable in the ripple and so the main LM can choose how to um how to access that.
  67. 06:05It can offload some of these subtasks to to sublim.
  68. 06:08And really the only context that it gets back are the things that actually matter.
  69. 06:13So in terms of how it's meaningfully different, rag of course you kind of just stuff the context window.
  70. 06:18You want it to limit there.
  71. 06:20Agents are largely just bringing strings back and you don't have this tight coupling between the logic, the execution and the results.
  72. 06:29And so you still run into the same sort of problem there.
  73. 06:32Same thing with tool calling and and codec.
  74. 06:35And then RLMs as I mentioned you're act the the LLM is actually just interacting with the context the results as variables in the ripple so that it can do additional computation on versus
  75. 06:48it trying to attend to all these different tokens in this in its context window.
  76. 06:52It's it's a meaningfully different way of of the LLM interacting with the uh the actual content itself.
  77. 06:59And so people always say, okay, what's the difference between that and and encoding agents?
  78. 07:03Um, in my mind, the largest difference is that the way that tool calls are tool calls calls are done is passing strings back and forth.
  79. 07:13Um but you can see with the release recently of workflows that uh Anthropic is doing something fairly similar and they um at the CIS conference I think it was Tar or someone similar
  80. 07:26um mentioned the RLM paper as a key driver of workflows and how they're how they've implemented it.
  81. 07:34And you can see here the intermediate results for workflows live in script variables i.e. a variable in the context.
  82. 07:44So, it's driving some of these these breakthroughs and some of these techniques from the from the labs as well.
  83. 07:53I'll skip through this a bit just because I have about 10 minutes left, but generally speaking, when you want to use it, it's obviously for large or dense input context.
  84. 08:02An underexplored area is outputs as well.
  85. 08:06So if you have a some type of task where you need to generate hundreds of thousands of lines or whatever it might be, RLMs I think would be a good candidate for that as well.
  86. 08:16Obviously tasks that are imunable to some type of decomposition.
  87. 08:19So if you want to look through the entire I don't know the whole tax code as an example and try and find loopholes or something.
  88. 08:27You can't obviously put all of that into context at once.
  89. 08:30You could use an LLM to crunch through all of that and iteratively explore and use sub agents to explore interesting areas of this of the tax code.
  90. 08:38Bring back those sections and then reason over that and then just generally for for longer horizon sessions.
  91. 08:44And when you want to skip it, of course, it' be something that fits in context.
  92. 08:48You want something that's low latency or the the model itself is as strong of a coder.
  93. 08:54And uh our friend Raymond here did some great perfor performance testing on the long chain of thought benchmark.
  94. 09:00Um I'll leave this link as a as a leave behind after, but just to give you a sense of how well it performs on some of these tasks.
  95. 09:07It's a meaningful jump overall from from 2.6 to 45.4% um accuracy on many of these tasks.
  96. 09:14And you can see it performs really well on things that are amanable to code.
  97. 09:18So logic puzzles and and chess and chemistry and things like that where it can dynamically write code bring in only the relevant part of the context compute that and then return the result where the main model is really just harvesting the results from from the subLM and try instead of trying to do that by itself.
  98. 09:38Um I put together a few just super simple examples.
  99. 09:41I mean, these are kind of they're somewhat unfair, I suppose, to to the base model, but it it makes the point that there are certain tasks that base models just aren't really fit to do themselves
  100. 09:52because they because they have to attend all these to different tokens at once in the context window where you need or want to use some type of coding approach to that.
  101. 10:01So in this random example, summing 12 numbers that are buried across 30,000 tokens, the LLM trying to figure all that out by itself and give you the answer isn't always going to work as well as something that you can write reg x4 or something similar.
  102. 10:16And then the same same sort of thing particularly for data frames and we'll walk through a brief example here where because the LLM can interact with the data frame within the ripple.
  103. 10:28It just has a much better understanding of the content and can iterate through that much more quickly than having to pass tool calls back and forth in terms of like JSON strings and and that sort of thing.
  104. 10:39Um, and then I threw this in there in terms of running the same experiments with a coding agent.
  105. 10:44Now, I didn't look into this too deeply.
  106. 10:46There's probably some unfair math going on here, but you can see that it was totally bloated in terms of the way that cloud code tried to um tried to solve these tasks.
  107. 10:56So, there's more work to be done there, of course, in terms of like running experiments to compare base models versus RLMs versus something like a coding agent.
  108. 11:06But there's just for certain tasks for like production workloads.
  109. 11:10My sense is you probably don't want to just do cloud-p your prompt and like hope for a good result.
  110. 11:16Like you want more of a structured approach to your inputs, your outputs and you want a defined pipeline for doing so which reduces your cost, it reduces your complexity, reduces your bloat, all that sort of thing.
  111. 11:27Um where RLMs can can shine.
  112. 11:32So in the real world there are a bunch of different open source libraries that implement RLMs at some level.
  113. 11:38Some of them are more RLM focused uh like a predict RLM would be a good example of that versus others are kind of just integrating it into the broader approach or the broader framework.
  114. 11:50DSPI obviously uh there's axe which is really interesting work uh that's being done there.
  115. 11:55Predict RLM is more focused on like knowledge work.
  116. 11:58So it works with spreadsheets and PDFs and that sort of thing and then fast RLM.
  117. 12:04And then there's a tweet yesterday from this guy Sam Hogan um where who runs inference.net.
  118. 12:09He's using an RLM to basically run and extract um insights from your particular um production workload traces so that they can see what makes sense to defer off to something like a GLM 5.2 too and do that iteratively and automatically as your traffic goes through.
  119. 12:28So point being, you don't have to worry about context engineering.
  120. 12:33You can kind of just throw the RLM at it and have it figure it out.
  121. 12:36Um, I only have five minutes left, so we won't go through this whole example and I'll I'll skip to some of the traces because that's probably the most interesting.
  122. 12:43Um, but this is all you would really need to do in terms of a simple, in this case it's like a a cohort retention analysis, something that you might give to a data scientist.
  123. 12:54But this concept of applying an RLM to a complex data structure like a data frame becomes very easy to do.
  124. 13:02This is all the code you need to do it where I'm feeding in three different data frames.
  125. 13:06I'm saying these are the sorts of things you need to look for.
  126. 13:09These are the output types that I want.
  127. 13:11and then just let the RLM go on it.
  128. 13:14And I'll I'll show you some of the traces.
  129. 13:18Um, and so it has its own ripple where it can interact with those data frames.
  130. 13:23And you can see it reasoning through.
  131. 13:25Okay, first I need to do this.
  132. 13:26It's writing the code.
  133. 13:27And because it's li it's living in the ripple with the dataf frame, you don't have this additional bloat of the tool calls back and forth.
  134. 13:34It's actually interacting directly with the dataf frame as if it was typing in its own Jupyter notebook.
  135. 13:40And there there's significant advantages for for doing so.
  136. 13:44And so you can see the sorts of outputs that it gets as a result.
  137. 13:48And it by itself will iterate.
  138. 13:50And in this case it didn't, but it has the option to defer to subLM to do okay.
  139. 13:55And now I have this big whatever this big subset of the data sublm go off and do this analysis give me the result and it can do that iteratively over time.
  140. 14:05Uh but the point is that the LM is directly interacting with the data frame in its ripple um and kind of iterating through the results.
  141. 14:15And so this u this platform compound is RLM and DSPI native.
  142. 14:20So it gives you this really nice breakdown of the reasoning.
  143. 14:23It separates out the code that's being generated and ultimately you can see uh the final output which is here where it's formatting.
  144. 14:34Okay, here are the key findings that I have.
  145. 14:35Here are the recommendations.
  146. 14:37And then you have this final submit which is the final answer that gives you the the typed um outputs that you had defined up front.
  147. 14:45And the key thing here is that the LLM itself is deciding when to stop.
  148. 14:49So you have this you have a variable of max iteration.
  149. 14:53So you can just you can decide whether you want it to have a maximum of 10 or 100 or whatever it is.
  150. 14:58But it will by itself explore the data, understand what needs to happen and then when it it itself is comfortable, it can run submit and give you the final output.
  151. 15:09Again, being bitter or less impilled, this will get better over time.
  152. 15:12You can kind of just defer everything and it will figure out what to do.
  153. 15:16And so the hope would be you don't have to I mean we're already you know whatever this is 20 lines of code or something.
  154. 15:23Um, but you can you can see a world where you can continue to go up levels of abstraction.
  155. 15:29As long as you can define what your objective is and what you want it to do, the the model will kind of figure out the rest.
  156. 15:36Uh, so we just walk through a bunch of this, but um these are the different steps that it took in this example in the code that it wrote.
  157. 15:43Um, and then I'll just breeze through a few real world case studies and where it's actually being used.
  158. 15:48So I mentioned predict rm before.
  159. 15:51So the company trampoline AI I think it is they're doing really interesting work in applying RLMs u like I mentioned before for different pieces of knowledge work.
  160. 16:01So natively interacting with PDFs and and spreadsheets and that sort of thing.
  161. 16:06So in this relatively simple example okay I have a bunch of I have a directory of invoices that I need to create one consolidated inventory out of.
  162. 16:17As we all know invoices can be complicated.
  163. 16:19that can be very long, that can kind of be all over the place.
  164. 16:23To do that today without RLMs or this sort of like framework gets very complicated very quickly.
  165. 16:31I have a lot of battle scars to to prove it.
  166. 16:33Um, but with something like an RLM, you you don't need to worry as much about, okay, if I have a 200page invoice or contract or whatever it is, you can let the RLM just churn through all of that and give you the result instead of having to worry about chunking
  167. 16:47and embedding maybe and doing all these different strategies to try and get around the context window management that we've all had to to do previously.
  168. 16:57Um, so it allows you, the point there is that you can focus on the abstractions and what you actually want to do instead of the context engineering itself, which I think is a really helpful
  169. 17:07um, helpful output of all of this.
  170. 17:10And an interesting tidbit for all the DSPI fans in the room, predict RLM uses DSPI to determine the schemas between the main LM and the subLM calls, which I personally think is is a nice feature because you have a lot more readability and maintainability.
  171. 17:28So you understand exactly what the model is trying to achieve and the model can be much more precise and prescriptive about the types of data that it's looking for from the subLM.
  172. 17:38And I would want to do some experiments to test this out, but I would think that this would improve performance for cheaper models like a a Quinn or some of the other ones because
  173. 17:48you're specifying the inputs and outputs and you're enforcing those types coming back.
  174. 17:52And so you get all the benefits of the RLM being able to churn through all this information, but you have a lot more of the structure in between where when it's handing off to a sublm,
  175. 18:03it it enforces some of the uh some of those schemas.
  176. 18:07This is an example from um an AWS engineer from a couple days ago.
  177. 18:12We were just kind of playing around with it, but I just thought it was a nice example of you can kind of just throw arbitrary data at RLM.
  178. 18:21In this case, it was a bunch of log data um to surface some interesting uh results and he he found it useful.
  179. 18:30Um there's a a project called Halo which uses an RLM to look at traces of um of different t uh agent tasks.
  180. 18:41And basically the promise of Halo is that instead of optimizing a particular like workflow or DSPI uh or or other framework uh like structure itself, it's it's actually iterating on the harness.
  181. 18:55So it's like a meta abstraction almost or meta optimization of the harness itself and it uses an RLM because as we all know tracing can get very long and and complicated.
  182. 19:07So the RLM can not only take in all that context but also leverage the um the structure of those traces to to recommend a better um a better harness.
  183. 19:18And then this last one uh this is all the code you need.
  184. 19:22I ran this little experiment.
  185. 19:24There's a an intentionally vulnerable application called uh it's from OASP, but basically there's a it's a web app with a bunch of vulnerabilities in it.
  186. 19:32This is all the code you need on the right hand side to run basically an agent to run through whatever it is 500,000 lines of code to generate some type of security report.
  187. 19:42That's just an arbitrary example, but the point is you don't need a lot of context engineering.
  188. 19:48You don't need a lot of structure around it to achieve what you want to do.
  189. 19:52And so you can feed in an arbitrary uh size codebase into this and get some type of insights out.
  190. 19:58So you can imagine that being applied to other areas as well.
  191. 20:02Um so I know I I rushed through everything a little bit but I'm happy to answer questions afterwards.
  192. 20:07Uh the I'll leave you leave you with this.
  193. 20:09The biggest promise I see here is just imagine a world where the models are actually post-trained and actually like RLM aware.
  194. 20:17I think things will get pretty crazy pretty quick when they actually know how to use and kind of take advantage of the RLM methodology natively.
  195. 20:27So, thank you so much for your time.