3 ms·

Evolution Through Large Models

32 points by lnyan 4y ago

Imnimo 4y ago
Super short version: You want to evolve programs. Randomly mutating programs is hard, most mutations break things. Instead, ask a giant language model to propose edits, in the form of diffs (like the ones you get with git or whatever). These mutations are usually reasonable, don't break things, and lead to more interesting evolved programs. You can even further improve the process by using the successful mutations to fine tune the language model to predict better future mutations.
- Mariehane 4y ago
  Thanks for the summary! Isn’t calling this “Evolution” rather overselling it?
  - groceryheist 4y ago
    Its "evolution" in the sense it's an attempt to apply concepts from evolutionary theory to engineering problems and the principles of biological evolution are similar in the abstract.
  - cjg 4y ago
    Evolution is just variation and selection. That might be the biological evolution we are familiar with, but it might also be improvements that a carpenter makes to their toolbox over time. Here (the toolbox and this paper) the variation is directed rather than random, but it's still variation and selection.
dataangel 4y ago
this is a brilliant idea
jal278 4y ago
Author here -- some fun videos from the paper: A gallery of evolved robots: https://y2u.be/QNyNtvwA9FI https://y2u.be/QNyNtvwA9FI An evolutionary lineage from an initial (barely-functional) seed to a final robot: https://y2u.be/M9pAJuX6dyM https://y2u.be/M9pAJuX6dyM
- pleonasticity 4y ago
  You may be interested in this paper: https://arxiv.org/abs/2105.09352 https://arxiv.org/abs/2105.09352 As far as I know it was the first to train a model on commit diffs to generate code mutations, in this case for bug fixing.
blackbear_ 4y ago
Next step: minimize the number of iterations by using another language model to write commit messages.
- eru 4y ago
  I wonder whether you should generate the commit messages first, and then base your code changes on that. (Might also be an interesting idea for human programmers. In analogy to Test-Driven-Development, this would be called Commit-Message-Driven-Development.)
  - blackbear_ 4y ago
    I would actually train a model to write the commit message by looking at the latest performance, sort of trying to identify the best next step.
  - gwern 4y ago
    Definitely. It'd be very Decision Transformer and prompt programmingesque: you declare what the high-level intended result should be, with requirements, test cases, examples, and then let the model condition on that and figure out the implementation. Why would you do it backwards? You're going to have to explain what you want anyway, after all. (And of course, you would ideally do it both directions, similar to image/text: neither direction is privileged, you want to be able to both generate images given a description, and generate a description of an image, and both tasks help the other.)
    - eru 4y ago
      Oh, I meant have the computer generate first the commit message, and then have another computer generate the commit. Though you are probably better off creating both at the same time. What you say makes a lot of sense, if you want a human to create the commit message as a sort-of prompt engineering to ask for specific changes.
spupe 4y ago
So their proposal is to leverage large language models to propose automated, reasonable changes to a codebase that is constantly checked for "fitness" in a particular task. I've always been fascinated with evolutionary mechanisms in programming, this is a clever idea to make things more interesting.
MathYouF 4y ago
I was watching this video recently from Weights and Biases on Linear Algebra intuition for ML. A mention was made in it that the real reason matrices rather than code or formal logic are used in ML is because of their ability to be changed in small ways with a relevant directional change in the operability of that matrix. Changing a single character of a code block doesn't have the have smooth changes. So your paper seems like a cool move in the right direction, and supportive of the work people are doing to try to make ML more interpetable by turning it into formal logic.

32 points by lnyan 4y ago

Super short version: You want to evolve programs. Randomly mutating programs is hard, most mutations break things. Instead, ask a giant language model to propose edits, in the form of diffs (like the ones you get with git or whatever). These mutations are usually reasonable, don't break things, and lead to more interesting evolved programs. You can even further improve the process by using the successful mutations to fine tune the language model to predict better future mutations.

Mariehane 4y ago
Thanks for the summary! Isn’t calling this “Evolution” rather overselling it?
- groceryheist 4y ago
  Its "evolution" in the sense it's an attempt to apply concepts from evolutionary theory to engineering problems and the principles of biological evolution are similar in the abstract.
- cjg 4y ago
  Evolution is just variation and selection. That might be the biological evolution we are familiar with, but it might also be improvements that a carpenter makes to their toolbox over time. Here (the toolbox and this paper) the variation is directed rather than random, but it's still variation and selection.

dataangel 4y ago

this is a brilliant idea

jal278 4y ago

Author here -- some fun videos from the paper: A gallery of evolved robots: https://y2u.be/QNyNtvwA9FI https://y2u.be/QNyNtvwA9FI An evolutionary lineage from an initial (barely-functional) seed to a final robot: https://y2u.be/M9pAJuX6dyM https://y2u.be/M9pAJuX6dyM

pleonasticity 4y ago
You may be interested in this paper: https://arxiv.org/abs/2105.09352 https://arxiv.org/abs/2105.09352 As far as I know it was the first to train a model on commit diffs to generate code mutations, in this case for bug fixing.

blackbear_ 4y ago

Next step: minimize the number of iterations by using another language model to write commit messages.

eru 4y ago
I wonder whether you should generate the commit messages first, and then base your code changes on that. (Might also be an interesting idea for human programmers. In analogy to Test-Driven-Development, this would be called Commit-Message-Driven-Development.)
- blackbear_ 4y ago
  I would actually train a model to write the commit message by looking at the latest performance, sort of trying to identify the best next step.
- gwern 4y ago
  Definitely. It'd be very Decision Transformer and prompt programmingesque: you declare what the high-level intended result should be, with requirements, test cases, examples, and then let the model condition on that and figure out the implementation. Why would you do it backwards? You're going to have to explain what you want anyway, after all. (And of course, you would ideally do it both directions, similar to image/text: neither direction is privileged, you want to be able to both generate images given a description, and generate a description of an image, and both tasks help the other.)
  - eru 4y ago
    Oh, I meant have the computer generate first the commit message, and then have another computer generate the commit. Though you are probably better off creating both at the same time. What you say makes a lot of sense, if you want a human to create the commit message as a sort-of prompt engineering to ask for specific changes.

spupe 4y ago

So their proposal is to leverage large language models to propose automated, reasonable changes to a codebase that is constantly checked for "fitness" in a particular task. I've always been fascinated with evolutionary mechanisms in programming, this is a clever idea to make things more interesting.

MathYouF 4y ago

I was watching this video recently from Weights and Biases on Linear Algebra intuition for ML. A mention was made in it that the real reason matrices rather than code or formal logic are used in ML is because of their ability to be changed in small ways with a relevant directional change in the operability of that matrix. Changing a single character of a code block doesn't have the have smooth changes. So your paper seems like a cool move in the right direction, and supportive of the work people are doing to try to make ML more interpetable by turning it into formal logic.