Ending AI Slop — Thais Castello Branco, Taste Labs

AI Engineer · 16 min · 166 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:13Hello everyone.
  2. 00:15It's great to meet you all.
  3. 00:16I'm Tais.
  4. 00:17I'm the founder of Taste Labs.
  5. 00:20For those of you who don't know us, we came out of Stealth a few weeks ago.
  6. 00:23Uh, and our whole mission is basically how do we end AI slop?
  7. 00:27And we believe that to really solve this problem, we have to first decompose and understand subjective domains.
  8. 00:34Right?
  9. 00:34I think as probably all of you know, AI has gotten quite good at things like coding and math.
  10. 00:38Uh but it's still super behind on things like design, creative writing, personality, emotional intelligence.
  11. 00:44And to understand these domains, I think we have to take a little bit of a different approach than we do with um with objective ones.
  12. 00:50So our idea is like how do we become this data and infrastructure layer to really uh understand these problems and to become the solution for them across the stack.
  13. 00:59So from the foundation model layer all the way to how do we build solutions for agents as well.
  14. 01:04So we work primarily in two ways.
  15. 01:07We work with the top frontier labs on how do we evaluate benchmark their models understand where they're breaking uh understand how we can fix them and how do we determine also which problem is better fixed through each method.
  16. 01:18So what things should be turned into RL environments, which things should be turned into post- training data problems.
  17. 01:23Um, but then we also go and work with a lot of agent and application layer companies on what are things that we actually don't believe should be solved at the foundation model layer and that might be better solved through methods like context
  18. 01:35uh or understanding user intent.
  19. 01:36Right?
  20. 01:36We're basically betting on a world where suddenly you're going to have billions of people creating uh that are not necessarily experts.
  21. 01:43So this understanding of user intent and contest and context is equally as important as how do we get these models to improve.
  22. 01:49For today I'm going to focus on the model training part.
  23. 01:51For those that are here tomorrow I'll also be giving a chat on the design track where I'll cover more on what we're doing on the agent side of the house.
  24. 01:58But there we go.
  25. 02:01Okay.
  26. 02:01So most of the world is subjective as I was mentioning.
  27. 02:04Uh a lot of the world is subjective right?
  28. 02:05If we talk about these domains of writing even workflows within companies right of sales marketing uh a lot of the times there's this multitude of answers there's not one clear right answer and it's very hard to define what great even means I think at the end of the day like those are why these domains are so difficult
  29. 02:22um and we oftentimes I would say forget to mention like why uh we treat for example the fact that code is verifiable and measurable as something that is a property about models and models are great at at coding
  30. 02:40um because we've made them great at coding but realistically it's actually a fact about code.
  31. 02:44Code is something that decomposes, it verifies, it executes and so it makes it a lot easier for us to be able to train on these domains for something like design or writing like how do you decompose it?
  32. 02:54How do you verify it?
  33. 02:55How do you judge if it's actually good?
  34. 02:57So that's why they become so difficult.
  35. 02:59Um, so there's two characteristics that I want to touch on today on why fundamentally subjective domains are harder.
  36. 03:05One is that capability follows measurability.
  37. 03:08So if we can solve the measurability problem or at least part of it, then we can solve a big portion of these domains.
  38. 03:14Uh the second which I'll touch on later is basically this like collapse to the mean and why the mean is not necessarily optimal in subjective domains.
  39. 03:25Okay.
  40. 03:32So to really start solving this problem, we have to turn something that feels fuzzy like if I ask you what is great design into something that is more verifiable.
  41. 03:40So there's a few questions here, right?
  42. 03:42Because if I ask you this of what is great design um you could ask yourself, okay, um do you mean great for which type of person, for which type of taste, for which situation?
  43. 03:52The same slide could be amazing.
  44. 03:54for example, if you are a startup and completely inappropriate if you are a finance firm.
  45. 03:59So it's contextual first of all.
  46. 04:01Second of all, it has this property that it changes over time which is different from other domains.
  47. 04:06What is considered good today is different than five years ago and different than five years from now.
  48. 04:10In code that's not necessarily true or in math, right?
  49. 04:12That's something that is way more consistent over time.
  50. 04:15So our ability to again decompose it and understand how is this good for a specific audience, how is this good today, how is this good in context um is some of the things that we've been thinking about in terms of how to how to break this down.
  51. 04:27But I want to give you a very specific example because of course this can mean many things.
  52. 04:30So let's talk about brand.
  53. 04:32Um if you're at a company and you've used coding agents, you've probably shipped an internal dashboard.
  54. 04:37You've probably shipped an internal like landing page.
  55. 04:40And oftentimes you might wonder, okay, how do I determine if this is slop, if this is actually good?
  56. 04:46And you have kind of this secret weapon at your disposal, which is really all the work that probably designers at your companies, for example, put into defining your brand.
  57. 04:53A brand to define takes a lot of effort, takes a lot of care.
  58. 04:56You're defining all these components about it, when it's good, why you're choosing certain combinations of colors, of typography, of spacing, of texture.
  59. 05:03Um, but if I just ask you to be like, okay, create something great, that's very hard.
  60. 05:07But suddenly if I'm like okay make something that is on brand that is a much easier problem to define and a brand is something that can become decomposable.
  61. 05:14Uh so for example if we I'm using the reduct brand as an example here because I I I like their website.
  62. 05:19Um let's say that we decompose this brand into the colors, the typography, the motion, the animation, the textures.
  63. 05:26Suddenly you have these very codified things that you can verify against.
  64. 05:30Verifying in general if something's on brand and you can try this uh by prompting an LLM as a judge to do it is quite hard.
  65. 05:36But once you start picking apart the exact elements that represent what great is, then it suddenly becomes the shape of something that is codifiable and verifiable.
  66. 05:46So if you want to turn this into a shape of an RL environment, for example, right, how would you train a model for a capability like brand adurance?
  67. 05:53Uh LLM LLM as a judge might not necessarily always be the best method.
  68. 05:59We know that there's a lot of reward hacking.
  69. 06:01We know that there's uh interesting hallucination patterns there too.
  70. 06:04And so we oftentimes try to create methods of basically how do we turn a task that feels fuzzy into one where there's a clear ground truth so that it can become the shape of an environment.
  71. 06:14So in this case the task design itself is really kind of the hardest part of the problem of how do you turn something that appears very fuzzy into something that actually can be arled.
  72. 06:23Um and so in this case that decomposition that I mentioned becomes the ground truth.
  73. 06:27So let's say that you start by tasking an agent to create a new page that is going to adhere to the reductal brand but be completely net new and different.
  74. 06:34Um you would want that output to not only be graded versus the original but to be graded on this ground truth, right?
  75. 06:40Because it could come up with completely new ways of using these components that are still valid but are different from the original.
  76. 06:47So you don't necessarily want to just see if it's replicating the original.
  77. 06:50So this is one example of like how to turn this into a problem of environment shaped um so that we can make it more verifiable.
  78. 06:57But in a way all of these things are I would say like spectrums right you have uh in a problem like design you have these elements of things like vision
  79. 07:06uh alignment typography that are closer to objective once you start moving up that scale onto things like style fit creativity how do you judge and measure something like creativity right that's much harder and so you kind of need to think of this as like a routing problem of how do you understand this like vast fuzzy problem break
  80. 07:24it down into smaller components and what is the best solution for each of these components.
  81. 07:30So why does something feel like slop?
  82. 07:32For example, when we're talking about something like creativity, right?
  83. 07:35I think this is the second reason why um subductive domains are so much harder to solve because if we're talking about the properties of models, they're basically predicting what's the most likely outcome
  84. 07:45to show up next.
  85. 07:46And they assume that that outcome is the ideal outcome.
  86. 07:48And for something like math encoding, that is true, right?
  87. 07:51You want the answer that your model gives you to be the average answer.
  88. 07:55If you're asking what 2 plus 2 is, uh, which also happens to be the right answer and the optimal answer.
  89. 08:00But for something like writing or design, you don't necessarily want the average answer, right?
  90. 08:04The average meaning the most likely does not necessarily coincide with like the optimal.
  91. 08:09Uh, a lot of like what I describe it is a lot of greatness and creativity happens actually at the ends of the distribution.
  92. 08:16It's not the most likely outcome.
  93. 08:17It's when you actually actively break from rules and actively break from patterns that you can create things that are subjective and and great.
  94. 08:24Um, and so the reason why this feels like slop and that we have this feeling that we're surrounded by by slop is exactly because of this collapse to the mean and this repetition.
  95. 08:34And so we have to find ways of okay, how do we break these patterns?
  96. 08:37How do we break from the mean uh but in a way that's also intentional.
  97. 08:40So then you kind of shift the problem onto things that are not so easily maybe verifiable.
  98. 08:44Uh but that are more questions of human preference and judgment and that might be better solved by data for example than by environments.
  99. 08:51And so again this kind of like mode collapse is is really the thing that we're trying to solve.
  100. 08:56And how do we force that distribution back?
  101. 08:58Uh, oftentimes, by the way, we we work, for example, with a community of designers, um, over like a thousand experts that are experts in different types of medium, different styles, and we purposely want to force that distribution when we're breaking down the problem.
  102. 09:12Exactly.
  103. 09:12So, we don't end up in this mode collapse, but there's of course a lot of other pieces of that puzzle.
  104. 09:17Uh, but I think this is an interesting framework is like the closer you are to something that it becomes verifiable, especially programmatically, the better for something like RL, right?
  105. 09:26And I think the challenge is how do we turn things that feel fuzzy into things that become more verifiable by establishing this ground truth and designing tasks in a way that allow for that.
  106. 09:35But then the more that it does shift to things that are contextual or that depend on that time element that we talked about or this like distinction in preference,
  107. 09:43the more this shifts towards something that requires human judgment.
  108. 09:48So uh I I I like this analogy of basically kind of pulling things toward verification.
  109. 09:54So brand adherance on its own would be something that's very hard and that is probably better judged by a human than for example by an LLM as a judge or something deterministic.
  110. 10:02But by codifying it by understanding which pieces matter and how do I turn that into something that is observable and measurable we can kind of pull it into this realm of verification.
  111. 10:12uh so this routing logic is I would say if you have one takeaway uh take this away it's like how do we break down this problem into something that you understand what's actually the best method to solve it
  112. 10:23and so when we are talking about these things that are more subjective uh we do require human judgment I think this is something that we um we believe human judgment is still at a much higher level than any LLM as a judge and this like human taste is really how do we encapsulate this in a way that
  113. 10:40uh can be turned into high quality data so that we can train these models better.
  114. 10:46And I think one of the tricky things here is often times in the past you had kind of this uh collection of preference data that would collapse again to the mean because you would collect it from a bunch of different people without necessarily understanding who they are, what they like, why they like it, when they like it.
  115. 11:01And if you don't break up that problem accordingly, you then end up again with preferences that kind of don't agree with each other.
  116. 11:06Because that naturally happens in the world, right?
  117. 11:08I bet that some of you might like one style better than another.
  118. 11:11And that doesn't mean either of those things are wrong or it doesn't mean that the best answer is the average of what two people might like.
  119. 11:17It means that we need to fundamentally understand that the world is multi-preference and how do we do that matching accordingly.
  120. 11:23So this almost like understanding of how do we create like a preference vector let's say for someone and attach that to even something like preference data can help us to
  121. 11:32train in a way that allows for that more pluralism of preferences intentionally instead of that data being turned into something that's noisy.
  122. 11:40when we talk about data quality as well for these domains, I think it becomes very uh I don't know if any of you have bought data for example for these domains or or have tried to curate data yourselves.
  123. 11:50Um but there's it's very hard to define okay like now I'm realming to the side of data.
  124. 11:55What is actually good?
  125. 11:56What is actually going to be helpful to my model?
  126. 11:58Um and there's obviously a few things that are harder to define but a few that I think become more controllable and how do we actually understand patterns of quality so that we can measure them.
  127. 12:07So one I would say is that problem decomposition.
  128. 12:09How do we force like true distributions of what you see in the world?
  129. 12:12How do you force true like expert selection across these u different buckets?
  130. 12:16And these are things that you can totally control, right?
  131. 12:18You can see who those experts are.
  132. 12:20You can do a selection pattern that is very strict um and you can decompose that problem and this is something that is completely in your control and that totally helps with the
  133. 12:29um results let's say of the experiment being being good.
  134. 12:33Um the second is I would say that like flow of like how do you determine then the right problem routeed to the right solution.
  135. 12:40Um we also I would say do a lot of what we call essentially like QA on this data and I think there's two ways to do that is understanding what are properties about that data point that
  136. 12:52correlate with being it being rich and high signal.
  137. 12:54So for example, specificity when you're trying to ask an expert to define is this good, is this bad or put reasoning behind it or create a whole observation system around
  138. 13:06uh how they would judge an asset.
  139. 13:08The specificity of their language and of how precise they're being able to be with how they're doing that description is what will determine that data quality.
  140. 13:17Or for example, if you can tie their commentary with actually which piece in the code does this relate to.
  141. 13:22Like let's say you have an expert that's judging a landing page.
  142. 13:26Uh they might be able to just like write a paragraph describing this.
  143. 13:29But we know that models have a tricky time kind of actually connecting the piece of the code to the visual.
  144. 13:35And so if you can find for example a method to tie that exact code component to the commentary of the expert, suddenly you have data that is way less noisy and way more clear.
  145. 13:44So these are some things that we can do both in terms of the flow of how you connect the data uh of how you collect the data but also in these like QA checks of how do you determine characteristics about it that will uh correlate highly let's say with with valuable data and same with human QA.
  146. 13:59I think by the way human QA is tricky here because there's two sides to it.
  147. 14:02There is a side of for example let's say you're collecting uh a bunch of preference data about slide design.
  148. 14:11Um you could have human QA be like okay is this again high quality data is the following the specs which most people would agree on but suddenly if you ask for expert consensus and you try to have
  149. 14:21another expert see if they agree with the initial designers like votes you might start seeing some disagreement there and you I think the key is understanding is that disagreement something that's actually
  150. 14:31a flaw in the data meaning are they for example disagreeing on something that they should be agreeing on such as alignment like alignment is something that's pretty objective So it would be kind of odd to see experts disagreeing on that front.
  151. 14:44But suddenly if they're disagreeing on things like sty style or um aesthetics that is not necessarily bad data that's actually good data.
  152. 14:52It shows you that there is a distinction for what people like.
  153. 14:55And so uh this almost like analysis of how do you run human QA in a way that both screens for kind of the fundamentals but then when you use consensus I think in an intentional way is another big big piece of this.
  154. 15:06Um and then obviously kind of seeing actually how this data is is interacting with models.
  155. 15:10Uh we run a lot of research on our side.
  156. 15:12Obviously when you're interacting with labs as we do um it there's a lot more involved and we oftentimes don't get that feedback loop of exactly what affected this cause which is why we're so adamant on focusing on these things we can control in terms of data quality because these are things that
  157. 15:27uh we can completely measure on on our side.
  158. 15:30Um so I think one other uh piece of advice or message of the day is I think especially when it comes to subjective domains I would advocate for a quality over quantity approach.
  159. 15:44I think creating high quality data is expensive.
  160. 15:47It's difficult.
  161. 15:47It takes a lot of understanding and depth around a specific domain.
  162. 15:51and having that be incredibly high quality done by people that also are incredibly high taste or whatever you want to call it in that domain uh yield far better results than getting a bunch of noisy data or a bunch of messy data uh that was not necessarily intentional or didn't have all those things we talked about of
  163. 16:06like the problem breakdown.
  164. 16:07So that is my my message of of the day.
  165. 16:10Thank you.
  166. 16:27[music]