3 ms·

I have not read the paper yet (in my backlog, here's the paper: https://arxiv.org/pdf/2307.09009.pdf https://arxiv.org/pdf/2307.09009.pdf), but it's important n

by lhl 3y ago

I have not read the paper yet (in my backlog, here's the paper: https://arxiv.org/pdf/2307.09009.pdf https://arxiv.org/pdf/2307.09009.pdf), but it's important note that the paper is entitled "How Is ChatGPT’s Behavior Changing over Time?" not that it's necessarily "getting worse." Here's a more nuanced (not an AI clout chasing account) discussion by Arvind Narayanan (Princeton CS prof) about the results: https://twitter.com/random_walker/status/1681489529494970368 https://twitter.com/random_walker/status/1681489529494970368 One thing that I have confirmed is while the abstract and intro talk about evaluating "code generation" as if GPT-4 code generation is getting worse, In is 3.3/Figure 4 it says they judge correctness only if it's passing raw code: "We call it directly executable if the online judge accepts the answer" not whether the code snippet is actually correct (!). The latest model outputs code as triple ticked in Markdown: "In June, however, they added extra triple quotes before and after the code snippet, rendering the code not executable." I mean, this is important if you're passing code directly into an API I suppose, but I don't think this should be properly extracted to judge code generation capability. (I've had access to the Code Interpreter for several months now so I can't really say so much about the base GPT-4 model since I default to that most of the time for its programming abilities, but I use it basically every day and subjectively, I have not found the June update to make the CI model less useful). One other potentially interesting data-point is that while the original GPT-4 Technical Report (https://arxiv.org/pdf/2303.08774v3.pdf https://arxiv.org/pdf/2303.08774v3.pdf) gave the Human Eval pass@1 score as 67%, independent testing from 3/15 (presumably on the 0314 model) seems was 85.36% (https://twitter.com/amanrsanger/status/1635751764577361921 https://twitter.com/amanrsanger/status/1635751764577361921). And this current paper https://arxiv.org/abs/2305.01210 https://arxiv.org/abs/2305.01210 (well worth reading for those interested in LLM coding capabilities) scored GPT-4's pass@1 at 88.4%, which point towards coding capabilities improving since launch, not regressing.

sdwr 3y ago
How does Code Interpreter work vs base GPT-4 for code snippets? I'm writing questions and pasting context code into GPT-4 right now, and it works pretty well.
- lhl 3y ago
  I was using the GPT-4 base model for pairing when it launched, I'm sure it's still fine, but Code Interpreter I think is just a nice upgrade since it has a very full-featured VM and Python w/ several hundred libs built in, it is fairly smart about doing math or running code to answer questions, and you can upload datasets (and binaries, lol) for it to process so I consider it a strictly better version of ChatGPT. (Also, my assumption is that any tuning being done for the Code Interpreter model will be made towards it being a better programmer/logical thinker, which is all I care about for my CI use cases.)
insanitybit 3y ago
> One thing that I have confirmed is while the abstract and intro talk about evaluating "code generation" as if GPT-4 code generation is getting worse, In is 3.3/Figure 4 it says they judge correctness only if it's passing raw code: "We call it directly executable if the online judge accepts the answer" not whether the code snippet is actually correct (!). The latest model outputs code as triple ticked in Markdown: "In June, however, they added extra triple quotes before and after the code snippet, rendering the code not executable." I mean, this is important if you're passing code directly into an API I suppose, but I don't think this should be properly extracted to judge code generation capability. OK yeah I mean that's kind of critical information, wtf. I've upvoted this because it needs to be the top post. That's massively important - obviously you could go from ~100% to ~0% if your judge can't handle formatting changes.
lhl 3y ago
Just as a followup for those interested, after reading the paper and some more critique: The paper is mostly ok in that it points out model drift and the importance of making sure you use API versions. One good thing is that the full dataset/methodology was published on Github: https://github.com/lchen001/LLMDrift https://github.com/lchen001/LLMDrift (everyone should do this!) so it was easy to replicate/validate, but there are some issues: * Simon Boehm stripped the markdown output from the June model output and shows that it actually performs signficantly better than the March update when the Markdown is stripped - 70% correct vs 52% correct. https://twitter.com/Si_Boehm/status/1681801371656536068 https://twitter.com/Si_Boehm/status/1681801371656536068 - Matei Zaharia (co-author) replies that the point of the paper is that you have to watch out for formatting changes in the LLM, but Matei also announced in the parent tweet "We found big changes including some large decreases in some problem-solving tasks," so which is it? https://twitter.com/matei_zaharia/status/1681467961905926144 https://twitter.com/matei_zaharia/status/1681467961905926144 - I also think the authors should have been well aware that their prominent Figure 1 would be interpreted as reduced capabilities and that they shouldn't be implying that it is. I'm just going to say it's problematic and leave it at that... * Narayanan (and colleague Sayash Kappor) published an analysis of the Primality Test https://www.aisnakeoil.com/p/is-gpt-4-getting-worse-over-time https://www.aisnakeoil.com/p/is-gpt-4-getting-worse-over-tim... - basically, the March model didn't do any better than the June model. It's just that one tends to say yes, and one tends to say no, and the Prime factor questions that the authors asked were all "yes." They showed by flipping the questions, suddenly the June update does way better. So one, from a methodology perspective the distribution of yes/no should be equal, but secondly neither model actually has the capability to factor primes, so what's the point of judging if it's correct or not? If the June update for some reason said yes 500 times it would have scored a 100%, but wouldn't mean it actually made a difference on the results. Seems like a pointless test. * Another thing to note from looking at the code is that they call the API w/ temperature 0.1, not 0.0 - LLM responses are non-deterministic even at 0.0, but I don't know why you'd set it to 0.1 in the first place. The question has been asked: https://github.com/lchen001/LLMDrift/issues/2 https://github.com/lchen001/LLMDrift/issues/2 I wrote up a more points as well, will just leave a link for those interested: https://fediverse.randomfoo.net/notice/AXsoIewi72IUeXL888 https://fediverse.randomfoo.net/notice/AXsoIewi72IUeXL888

by lhl 3y ago

sdwr 3y ago

How does Code Interpreter work vs base GPT-4 for code snippets? I'm writing questions and pasting context code into GPT-4 right now, and it works pretty well.

lhl 3y ago
I was using the GPT-4 base model for pairing when it launched, I'm sure it's still fine, but Code Interpreter I think is just a nice upgrade since it has a very full-featured VM and Python w/ several hundred libs built in, it is fairly smart about doing math or running code to answer questions, and you can upload datasets (and binaries, lol) for it to process so I consider it a strictly better version of ChatGPT. (Also, my assumption is that any tuning being done for the Code Interpreter model will be made towards it being a better programmer/logical thinker, which is all I care about for my CI use cases.)

insanitybit 3y ago

> One thing that I have confirmed is while the abstract and intro talk about evaluating "code generation" as if GPT-4 code generation is getting worse, In is 3.3/Figure 4 it says they judge correctness only if it's passing raw code: "We call it directly executable if the online judge accepts the answer" not whether the code snippet is actually correct (!). The latest model outputs code as triple ticked in Markdown: "In June, however, they added extra triple quotes before and after the code snippet, rendering the code not executable." I mean, this is important if you're passing code directly into an API I suppose, but I don't think this should be properly extracted to judge code generation capability. OK yeah I mean that's kind of critical information, wtf. I've upvoted this because it needs to be the top post. That's massively important - obviously you could go from ~100% to ~0% if your judge can't handle formatting changes.

lhl 3y ago

Just as a followup for those interested, after reading the paper and some more critique: The paper is mostly ok in that it points out model drift and the importance of making sure you use API versions. One good thing is that the full dataset/methodology was published on Github: https://github.com/lchen001/LLMDrift https://github.com/lchen001/LLMDrift (everyone should do this!) so it was easy to replicate/validate, but there are some issues: * Simon Boehm stripped the markdown output from the June model output and shows that it actually performs signficantly better than the March update when the Markdown is stripped - 70% correct vs 52% correct. https://twitter.com/Si_Boehm/status/1681801371656536068 https://twitter.com/Si_Boehm/status/1681801371656536068 - Matei Zaharia (co-author) replies that the point of the paper is that you have to watch out for formatting changes in the LLM, but Matei also announced in the parent tweet "We found big changes including some large decreases in some problem-solving tasks," so which is it? https://twitter.com/matei_zaharia/status/1681467961905926144 https://twitter.com/matei_zaharia/status/1681467961905926144 - I also think the authors should have been well aware that their prominent Figure 1 would be interpreted as reduced capabilities and that they shouldn't be implying that it is. I'm just going to say it's problematic and leave it at that... * Narayanan (and colleague Sayash Kappor) published an analysis of the Primality Test https://www.aisnakeoil.com/p/is-gpt-4-getting-worse-over-time https://www.aisnakeoil.com/p/is-gpt-4-getting-worse-over-tim... - basically, the March model didn't do any better than the June model. It's just that one tends to say yes, and one tends to say no, and the Prime factor questions that the authors asked were all "yes." They showed by flipping the questions, suddenly the June update does way better. So one, from a methodology perspective the distribution of yes/no should be equal, but secondly neither model actually has the capability to factor primes, so what's the point of judging if it's correct or not? If the June update for some reason said yes 500 times it would have scored a 100%, but wouldn't mean it actually made a difference on the results. Seems like a pointless test. * Another thing to note from looking at the code is that they call the API w/ temperature 0.1, not 0.0 - LLM responses are non-deterministic even at 0.0, but I don't know why you'd set it to 0.1 in the first place. The question has been asked: https://github.com/lchen001/LLMDrift/issues/2 https://github.com/lchen001/LLMDrift/issues/2 I wrote up a more points as well, will just leave a link for those interested: https://fediverse.randomfoo.net/notice/AXsoIewi72IUeXL888 https://fediverse.randomfoo.net/notice/AXsoIewi72IUeXL888