Who is defining toxic speech? Where is that data being taken from?
This is the definition of using AI to set what the edges of “speech” should be based on potentially flawed data.
This is a clown world.
(Emphasis mine)
Following that link:
> Surge AI is a data labeling platform and workforce. Our labeling team pored over tens of thousands of social media comments to build this toxicity dataset. Each comment was then evaluated by multiple members of our team to determine its severity level.
My problem is with the dataset and datasets like this overall that sets the tone through AI of what is acceptable and what is not.
The negativity here just seems like sour grapes or weird goal posts.
Sure, it makes mistakes and needs verification. But know what also makes mistakes and needs verification? All the code I already manually write as I tediously ratchet towards a solution. Removing some cycles from that process is a win.
Just stubbing out close-enough boilerplate is a win by itself, like setting up an NLP pipeline or figuring out which menagerie of classes need to be instantiated and hooked up together to do basic things in some verbose libs/langs.
Can you give an example for this?
Indeed. Every negative comment I have seen here has been a shallow dismissal by someone who clearly hasn't engaged with the tool. I'm not sure why people here are so primed to shit all over anything potentially innovative, seemingly even without background knowledge. Like, is there something inherently offensive to coders about a model that threatens to do their job? Or is it just years and years of people getting burned by previous "AI" projects without knowing that this one is actually rather impressive and comes from good research?
Keep shallow dismissals to yourselves people. It's in the site's rules.
Maybe jealousy - people often downplay others' achievements to make theirs feel better. Or pride - "I don't need no stinking AI assistant! What are you saying? I couldn't write this myself?". I find the latter is a common reaction to static types too.
Which is maybe the point! As the article points out, remembering the correct incantation to get matplotlib to spit out a bar chart is hard[1]; I certainly have to look it up literally every time (well, these days, I just use tools which have more intuitive APIs, but that's maybe besides the point). I don't really know what it means to "binarize" a dataset, but apparently the language model did, and apparently seeing the giant stack trace when trying to plot a precision-recall curve was enough to prompt the article writer to realize such an operation might be useful. When you're doing exploratory analysis like this, keeping a train of thought going is extremely important, so avoiding paging back and forth to the scikit-learn documentation is obviously a huge win.
But, on the other hand, this isn't a "no-code" solution in any real sense, because for all intents and purposes the author really did all the difficult parts which would've been necessary for a "fully coded" solution: they knew the technical outcome they wanted and had very good domain knowledge to guide the solution, and, shoot, they still ended up needing to understand semantics of the programming language and abstractions they were working with in that stacktrace at the end. It's still extremely neat (and, presumably, useful) to see the computer was able to correctly guess at all the syntax and API interfaces for the most part[2], but I don't really think you can fault people for wanting to push back against the idea that this is somehow fundamentally transformative, since I think it's pretty obvious that the human is (still) doing the hard and interesting parts and the computer is (still) doing the tedious and boring parts. Maybe people shouldn't be getting flustered about a click-baity title over-promising a hip new technology, but as you say:
> Or is it just years and years of people getting burned by previous "AI" projects without knowing that this one is actually rather impressive and comes from good research?
There's definitely some of this.
---
[0] I wish I could find the link for this, but I'm very bad at google these days.
[1] To risk ascribing agency to a statistical model of github commits, it is sort of funny that the co-pilot pulled in seaborn as a dependency but then did everything directly with calls to plt and DataFrame.plot.
[2] I don't really have the expertise myself to tell you whether that scikit pipeline is at all reasonable, I suppose. It sure sounds fancy, though.
The problem is when it makes something that looks OK but does the opposite of what you want it to. See: machine translation
You can't classify a comment as boolean toxic, toxicity does not exist in a vacuum. To extend the analogy from it's biological counterpart, toxicity depends on the organism. You should never just a piece of text in isolation and draw any conclusion about it. It must understood in context, both that of the subject, the recipient and the sender.
Does that make sense?
However, the framing of the tutorial is clearly about using automated censorship at scale.
Someone is going to roughly copy-paste this into some forum software and call it a day.
This is some dystopian shit right here. I don't care what fancy models you train on it, or even what funny jokes you make of it. I'm just so done with this.
The article isn't making any suggestions about whether or not they are good or bad ideas.
So, a software developer?
Just kidding. Perhaps it would clear things up to know that "toxicity" classification is simply an introductory topic in natural language and machine learning. It is an interesting "problem" to try to solve precisely because of how ambiguous language gets. As far as I can tell, the article is mostly not concerned with the quality of the the classifier and is meant to be a proof of concept.
In any case, people have been coding and using such classifiers all over the internet since their inception. Believe me - this isn't accelerating that and the damage is likely mostly done. My advice? Self-host a web server.
Somehow, I suspect this the most. It's the defensive tone they tend to strike, I think. Particularly apparent in threads about new research. Lots of "I actually had this idea", and "my concern for this is [slippery slope fallacy here]".
I sincerely hope that I never become so egotistical about my own achievements (or lack thereof) that I instinctively despise those who achieve more. Fuck that.
I 100% agree that this is not a "no-code" solution as is defined. On the other hand, I wouldn't really mind a definition of "no-code/low-code" that involved this - but indeed, not there yet.
And yes, more-or-less I generally agree that this is a tool that must be used by experienced developers. So I can see how a false claim of "no-code" (basically defined as devs-not-needed) would trigger folks to be a little defensive.
However! If you are a programmer with experience, and you want to make your work just so much easier, then copilot is a great tool. I implore you to try it yourself with VS Code/Vim/emacs rather than using openai/codex as the autocomplete is what makes it great.
But also ... what do you need to know to recognize that the concept of a 'toxicity classifier' is likely broken? We can do _profanity_ detection pretty well, and without a huge amount of data. But with 1000 example comments, can you actually get at 'toxicity'? Can you judge toxicity purely from a comment in isolation, or does it need to be considered in the context in which that comment is made?
Maybe you don't need to know about python, but if you're building this, you should probably have spent some time thinking and grappling with ML problems in context, right? You want to know that, for example, the pipeline copilot is suggesting (word counts, TFIDF, naive Bayes) doesn't understand word order? Or to wonder whether it's tokenizing on just whitespace, and whether `'eat sh!t'` will fail to get flagged b/c `'shit'` and `'sh!t'` are literally orthogonal to the model?
More people should be able to create digital stuff that _does_ things, and maybe copilot is a tool to help us move in that direction. Great! But writing a bad "toxicity classifier" by not really engaging with the problem or thinking about how the solution works and where it fails seems potentially net harmful. More people should be able to make physical stuff too, but 3d-printed high-capacity magazines don't really get most of us where we want to go.
See, this tells me you may not have even used copilot. Because while tutorials such as this (and the OpenAI codex tools) have you use comments explicitly to code, the reality is that you're not hammering out plain english requirements for copilot to work. You just code - and sometimes it finishes your thought, sometimes it doesn't. You hit tab to accept autocomplete, just like you would for any other autocomplete. So you are generally reading and evaluating what copilot thinks is a good output and choosing whether it goes in the program or not with the TAB key.
The leading question is this:
>But as helpful as it is for coders, what if it enabled non-engineers to program too – by merely talking to an AI about their goals?
and it answers this in my opinion deceptively by presenting what amounts to a parlor trick. Whether copilot in general is any good or not is in my mind totally separate to this.
Just because one uses one of the ways doesn't mean they are not aware of the other way too.
This part from the article made me chuckle, because IMO the author fell for some of the most basic language processing smoke & mirrors:
…so we’ll give it some examples. When generating the array, it even creates the ideal variable name and escapes the quotations.
# create an array with the following toxic comments: [etc]
Copilot appears no different to most ML models out there. Poor and incomplete training data will yield ok results for popular things but as soon as you ask for edge cases it will fall apart like Siri trying to understand a Scottish accent.
Eventually it might get there with enough good representative training data but it's unclear to me how long that will take. If it tracks with speech processing models it might take decades plus.
Another consideration is that because the training data is being done using github public repos (at least last I read), it's likely that it's ripe for abuse. If that's still how they're doing it I'm looking forward to the TEDTalk in two years from a researcher who "hacked" the copilot AI by polluting its training data.
OK, I am waiting for you to propose a basic language parser that can do it. There's a reason we're only now having this debate - it was unconceivable 5 years ago, in the era of basic language parsers.
One newspaper was left leaning, the other had the reputation of right wing trolls commenting and one was somewhat in the middle ground with a reputation of the audience being pseudo intellectual neoliberalists.
The 'center' (most typical) comment for these three sites totally was in line with these sentiments. The perfect proof (or confirmation bias).
But the classification didn't work. While there were clear cut cases (one has to love stereotypes) most cases were just neutral. Meaning they could have been made on any of these media sites. Either they were just too short or just not extreme enough.
I feel (used explicitly here) that toxicity is not something that is easily classifiable without deeper understanding of the context. Else, if feeling a comment was toxic was the measure one would need to query all walks of life from extreme left to extreme right and afterwards would probably be left with a lot of toxicity that doesn't tell us much except that different people will find different things toxic.
From simple letter substitution (sh!t) to completely different words/concepts (unalive) to “layer 2 sarcasm” (where someone adopts the persona of someone who supports the word view that’s against what they believe in a non-obvious attempt to rally people against that persona).
People have been getting away with being toxic in public for a long time. ML cannot keep up. Humans can’t even keep up.
Similarly, a lot of the training data/features ML engineers use ignore context -- for example, a Reddit comment may seem hateful in isolation, until you realize the subreddit it's in changes the meaning entirely (https://www.surgehq.ai/blog/why-context-aware-datasets-are-c...).
Regarding your point, we actually do a lot of "adversarial labeling" to try to make ML models robust to countermeasures (e.g., making sure that the ML models train on word letter substitutions), but it's pretty tricky!
I'm now imagining a very frustrated junior developer a few years from now trying to argue with Copilot to write code for a classifier for chemical compounds, but it just spits out code for classifying text.
That's ages ago in AI time.
So just the future version of a junior developer not knowing how to use their tools? Yeah, that scans. Still sounds incredibly useful however. The alternative is, of course, a junior developer fumbling as they try to write said program entirely from their learned skills and experience.
There’s not always a quick fix or easy path. You can’t always patch existing stuff together or just wait until the problem goes away.
And when a tool helps you too much, then is there really a point in what you’re doing? It’s not even a learning experience anymore.
You still need to be able to code and understand what you're doing. You can't just ask simple questions and get complex answers. You still have to be capable of asking complex questions.
A common scenario I can think if is where I struggle to remember the name or API of the exact thing I want to do but I know exactly how it works - typing that in and getting a result would improve my workflow, but it's just saving a trip to Google, we're not talking the difference between doing and not doing, just a saving a minute.
I would rate the value of this more as interesting rather than useful, simply because as another commenter highlighted it's just easier to write code. It could be useful incrementally but not for everything.
Copilot adds tremendous value for someone who knows what they want, but not how to do it.
For example, I'm not a great programmer. I'm also a lazy programmer. I had to convert a time to a specific format, in a specific timezone in JS, and I couldn't be bothered looking up documentation for Date.toLocaleTimeString (or is that Date.toLocaleString?).
I wrote a comment outlining exactly what I wanted: // given a date in ISO format (and UTC timezone), return the time in hh:mm AM/PM format (and x timezone) and immediately Copilot generated the code I was after.
Making something easier can definitely mean the difference between doing and not doing — I've taken on a lot of projects I wouldn't have attempted without Copilot.
How do you know it was what you were after? Like you said, it could be .toLocaleTimeString or .toLocaleString (or something else).
How do you verify that the AI isn't giving you broken/incorrect code? I guess you could check the docs, or run the code yourself, but at that point what's the value add for copilot?
"Forget all that. Judged against where AI was 20-25 years ago, when I was a student, a dog is now holding meaningful conversations in English. And people are complaining that the dog isn’t a very eloquent orator, that it often makes grammatical errors and has to start again, that it took heroic effort to train it, and that it’s unclear how much the dog really understands."
Technology that can only make you go ooh and ahh is pretty useless.
And I know it sounds silly and like "I had an idea like that once" (see Office Space), but I actually came up with the idea for or at least a similar one to Copilot in an off comment to a coworker back in like 2014 or so. The idea was that as you wrote code, it would display on the side similar code that had been written by others doing the same or similar thing, and then it would allow you automatically upload small processing functions to some sort of cloud library. Same thing for doing autoformatting, although that's less of a concern now that formatters are becoming popular. The context I was working in was visual languages though. I had even started writing a tool during an "innovation week" (that I never showed) that would start visually classifying whether code written in the visual language was "good" or "clean" or not. I never got anywhere with it and mainly just have some diagrams generated from that project that were buggy so that they kind of look like art.
And as a bonus related to the article title, it literally lets you talk to your editor (ie you can press the keyboard shortcut and then give edit commands by voice[2]). I've been leaning on it heavily for the last few days and the setup feels really productive!
If you want to try it out you can install it here: https://marketplace.visualstudio.com/items?itemName=clippy-a...
You can also find the full source code here: https://github.com/corbt/clippy-ai/tree/main/vs-code-extensi...
I'd love feedback!
[1]: https://openai.com/blog/gpt-3-edit-insert/
[2]: I just wrote the voice command interface yesterday and it's still highly experimental. Relies on having ffmpeg installed on MacOS and doesn't work with all audio setups yet. But there's a clear path to making it more robust.
Copilot lets you do that in a way that is way beyond what a normal programming language would let you do, which of course has its own, very rigid, abstractions.
For some parts of the code you'll want to dive in and write every single line in painstaking detail. For others `# give me the industry standard analysis of this dataset` is maybe enough for your purposes. And being able to have that ability, even if you think of it as just another programming language in itself, is huge.
p.s. Does anyone know when Copilot will update the insecure example on their website? Or are they just trying to be honest with the possible quality issues with the generated code?
With this, I don't need to memorize the syntax OR be bottlenecked on looking at documentation or stack overflowing the commands I need.
In other words: you're celebrating the fact that a tool allows you to become more and more incompetent.
I don't have much hope for future generations at this point.
Aren't you at least a bit curious what new possibilities this technology could enable? What new discoveries could e.g. an expert doctor or a biologist achieve given access to programming tools without spending decades learning programming?
More importantly, only about 10% of my job time is spent doing work that is hands-on technical work. I'd say probably 1% of that total time is spent doing notebooks with dataframes. Whether I am competent or not is in no way determined by whether I can memorize the syntax to how to group by and count a dataframe. In fact I'd argue it's probably a poor use of time.
Whether memorizing things like syntax is part of competence or not is highly dependent on context. The ROI of me memorizing that specific syntax would probably be highly negative.
I'd fathom there are countless examples like that. There are people who only rarely need to code. There are people who code a lot but only rarely need to use a certain library or language. For people like that, making the code more accessible is a huge win (that includes IDEs, auto-complete or easy links to documentation, and things like Copilot).
i guess stack overflow has a similar problem but at least there people provide documentation, explanation, and helpful links. this just force feeds you some code. i dont see this as a positive movement for our industry as a whole
Can’t wait for this to be true! I will be treated as a demigod compared to them. Job security for life!
After all, "How to parse a CSV file in Python" is longer than "csv.reader(file)" but without knowing that "csv.reader" exists, you have no other way but to tell Google what you need.
This is how I already think of co-pilot, but these steroids seem to be mostly for prototyping.
SO often have comments and context such as "this works with 98% of browsers", "this isn't recommended, try X instead", "this works but can break library code because it changes the global scope", "this stopped working in version X" etc etc. Context like this can be important to take into account depending on what you're building.
2. I’m very skeptical of a small group of people reading a bunch of online comments and deciding what is “toxic” and “non-toxic”, even more so when it’s done with no clear definitions/guidelines. As their GitHub repo [0] says:
> Rather than operating under a strict definition of toxicity, we asked our team to identify comments that they personally found toxic.
That said, this isn't the robot that replaces us, obviously. Making the process of getting to 80% faster is better for everyone, but the last 20 is tough and anything further needs real expertise. I like how promising this is for the masses.
For instance, Microsoft Power Automate should rank highly.
I think this technology will really shake up how we code.
It is also highly symbolic that the first AI (copilot) was created to save humans from repeating toil, while the second (classifier) is about controlling and limiting us.
I believe the author chose to apply his method to this particular example intentionally for the two above points, not because of the hype of toxicity.
// generate 1e13 different versions of bubble sort and add to db"In the name of what's Good & Right, you have to behave how we want you to ... or else."
It's a really really cool tool and a lot of these comments are just shallow dismissals from people who haven't actually used it and like to be reactionary on the internet because that's the world we live in apparently. But I think it works best when it's used by people with experience.
Hopefully future models with higher accuracy and research in grounding can get us to that point however.
From what I saw, the actual language-processing part of it was top-tier. It's just it's a hard problem to come up with a demo for that people will actually respond positively to, hence the Jeopardy stint. It has limited real applications. It's really good at what it does but what it does isn't really widely useful.
Nobody wants to see "We're going to replace all our online help / support chat stuff with Watson" because people find those systems frustrating already, even if it would make things vastly better than some of the alternatives.
So you end up with weird stuff like Chef Watson, Doctor Watson, and so on -- things in areas where an ML model isn't going to replace a human anytime soon.
Then Marketing gets involved and suddenly anything that uses any kind of ML needs to have Watson slapped on it, even if it's not doing any language processing.
Still, Watson is pretty much the only one in its class. There are good alternatives out there that worked well for many people, but they offer only a subset of Watson's feature set. If an organization need some real bang, Watson is the only option.
This is really untrue. In fact, making "English as a programming language" was a goal of many older programming languages such as COBOL[1], BASIC, and PASCAL as early as the 60s. It's hardly a new idea and was hardly inconceivable "5 years ago" for something to output a programming language.
The sentence example here could easily be broken down by the ParseTalk model from the mid-90s[2].
Here's a recent ish example (2018) of someone developing a "fully English" programming language:
https://osmosianplainenglishprogramming.blog/2018/05/02/plai...
It's also a source of fun[3][4][5] for people.
These are all examples of either programming languages straight up using English as syntax, or lexical parsers that can break down language and provide you with the programmatic ability to make this kind of output.
The difference here is that while copilot is pulling in python examples based on its training data set, that one thing the author singled out for amazement could easily be done by these older non-ML methods. The value copilot is adding in the example is just outputting python compared to those other methods. The real value is way larger than that, pulling in potentially more complex code to accomplish a complete task.
It's a bit like seeing an all-electric cargo train and being amazed that a train can run on electricity, when electrified light rail has existed for a long time. The impressive part is not that a thing on rails can use electricity to move around, it's the fact that it can pull heavy cargo efficiently enough to make electric power viable.
[1]: https://en.wikipedia.org/wiki/COBOL#COBOL_60
[2]: https://arxiv.org/abs/cmp-lg/9410017
[3]: https://github.com/RockstarLang/rockstar/blob/main/examples/...
[4]: https://en.wikipedia.org/wiki/Shakespeare_Programming_Langua...
Basically, the concern that e.g. comment length gets too long is a weird one, because you don't tend to actually use copilot that way if you have access to it through tab-complete.
Perhaps what I really mean is - people should try using copilot for an actual coding project. Its benefits aren't really obvious in contrived examples.
Entering the programming field then becomes an iterative loop of you instructing an AI to generate code, generate tests and iterate / re-adjust until it does what you want.
"You" as in the next generations of programmers in a decade or two.
Also, while the programming languages you mentioned did evolve to higher levels of abstraction, one thing that didn't change was that you still were telling the computer what it should do. Of course, you could still run into problems when the abstractions you were relying on didn't do quite what you were expecting, but now you have Copilot giving you globs of code that supposedly do what you want to do. How are you supposed to check if it really does that if you haven't got the slightest idea about programming?
The uefi bootloader contains more code and complexity than your average 90s OS. Your smartphone is running at least two, possibly more operating systems. Desktop software of the past decades did not have to deal with even a fraction of the security considerations of even a simple web app. The base runtime of your typical managed language alone is more complex than complex desktop apps of the past.
> How are you supposed to check if it really does that if you haven't got the slightest idea about programming?
This one is easy: you check if its output matches your expectation. In the same way you don't need to know how to program a calculator in order to use one.
If you want to get fancy, you could even ask it to encode your expectations as a test suite.
You may be surprised to hear that a large amount, maybe even the majority, of academic research does not use source control, unit testing, etc, yet they still manage to get work done.
I've even encountered this in industrial research from teams in large companies that you'd expect to know better...
Have you seen the documentary about AlphaGo? After watching it, and seeing Lee Sedol just utterly devastated by losing to a computer, I felt like I too would surely feel the same thing in my life. I mean, surely Lee Sedol is a far more skilled Go player than I am a skilled programmer.
Anyway, sorry for the rambling. I agree - it's deeply important to _actually_ learn how things work. That's why I wouldn't recommend copilot to a junior dev. Unfortunately, the way things are going - those junior developers are going to use it anyways and I tend to be more of a realist than an idealist.
The Copilot tech is completely of my league.
You could do a similar thing with a robot DJ, by feeding it a stream of the dancefloor, and training it to keep that dancefloor grooving.
Some concepts become less offensive over time; some more offensive. 20 years ago gay marriage was offensive in many parts of the world. Should that be codified into our communication tools? Offence is in no way objective, and this will never change.
There is genuine, vast utility in advocating for this sort of thing, but only if you want to be the person with the power to decide what everyone else is allowed to talk about.
// CAVEATS:
// POTENTIAL ISSUES:
// Above is deprecated. Use below code instead
fn classify-toxicity(text: string) {
do_work(text)
while true {}
// this should never happen
}This very much seems like cheering on the destruction of your career.
I remember being 7 years old and not really understanding the AppleSoft BASIC manual. I memorized the variable names in the code examples, not realizing I could name variables whatever I wanted. A$, B$, LEFT_FOOT$. The latter was there to be obvious that one could name variables whatever one wanted, but 7 year-old me didn't understand. I remember talking to an older kid on the school bus whose father worked for IBM, and the confused look on his face when I started rattling off my list of memorized variable names. I can still picture his face, but I forget his name. I'm pretty sure he was Mike. Thanks for straitening me out, Mike (Schmidt?).
At least we're getting more effective cargo cults.
For example I can't draw faces but I can recognize a badly drawn face. If I ask an AI: Please draw me a 35 year old man with receding hair and crooked teeth I can quickly validate the result is fit for purpose. If it is not what I want I can modify the query. I then learn quickly how to prompt the AI to give me what I want.
In the example you give we can assume that the AI has produced a plausible option even if wrong. For example a scenario may be:
# User: Write a comment "Convert the date to the current local for printing"
# Copilot: generates the method 'toLocaleString'
# User: Mouse hover over the method to get the documentation for the 'toLocaleString' method
# User: See that the method produces the wrong output. We realize we don't want the date
# User: Modify the comment to "Convert the date to the current local for printing time only"
# Copilot: generates the method 'toLocaleTimeString'
# User: Yes this is the one I want. Moves on
Testcases, compilation, code review, documentation, IDE intellisense
This obviously gets harder the larger the amount of code copilot is being asked to generate. But good software engineering practises still stand. Try to keep your functions and modules small and to the point.
But code is not a face: you can't easily judge if it's correct or not, if you could you wouldn't need copilot in the first place, so now you have to trust it's correct and, if it isn't, you need to search for the correct answer anyway.
Their experience matches mine in my use of copilot.
I can critique a great book I couldn't write. I can marvel at John Carmack's early iD code without having been able to come up with it. I can be immensely impressed by what golfers produce for a mundane problem.
I'm not saying this is what copilot produces, but the concept could absolutely be useful, in theory.
Think of it like a snippet engine on steroids. It's a huge value add.
By testing it
>but at that point what's the value add for copilot?
Not having to look up the docs and writing it yourself.
It also bears repeating that Copilot will only get better.