Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a no-code toxicity classifier by talking to GitHub Copilot

surgehq.ai

Post reply on HN
Print view View original

141–150 of 152 posts

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#141

Post by BeefWellington »

visarga wrote: post #110
BeefWellington wrote: post #45

Earlier quoted context omitted.

A few years ago I did some work with IBM's Watson Twitter integration. One of the fun things you could do was sentiment analysis. It was reasonably accurate for the extremes but anything in the gray area would be wildly off. A politely worded tweet that was scathing would come across high on the positive sides of the scale, whereas a perfectly reasonable sentence that included profanity as used in a quote would immed…

> I think the most basic english language parser could output something along the lines of what was suggested, given an understanding of what valid Python should look like. 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.

> 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.

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...

[5]: https://github.com/lhartikk/ArnoldC/wiki/ArnoldC

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#142

Post by echen »

joshspankit wrote: post #133
abeppu wrote: post #35

We're all focusing on the weaknesses of co-pilot (the comments can be longer than the code produced; you need to understand code to know when to elaborate your comment, etc). 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…

We must suspend disbelief a bit regardless: Any “toxicity classifier” has a limited operational life as people who want to say toxic things will simply adapt their language and walk circles around it. 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…

(Post author here.) Agree with both you and the parent here! We work a lot in the NLP and Trust & Safety space, and many of the models and datasets we see do ignore context -- and so real-world "toxicity models often end up simply as "profanity detectors" (https://www.surgehq.ai/blog/are-popular-toxicity-models-simp...). Which would certainly happen with a Naive Bayes model as well.

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!

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#143

Post by Ozzie_osman »

qayxc wrote: post #100
Ozzie_osman wrote: post #9

This is a game-changer, even if it doesn't work 100% of the time. I only infrequently need to use notebooks and dataframes, I'd say once every few months. Frequently enough that I have a vague idea of what I need to do but not frequently enough that I can remember syntax. With this, I don't need to memorize the syntax OR be bottlenecked on looking at documentation or stack overflowing the commands I need.

> 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.

Well, for starters, I'd love to count myself as a "future generation" but statistically speaking I'm older than most people in our field by a good margin.

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).

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#145

Post by robertlagrant »

achenet wrote: post #128
robertlagrant wrote: post #123

Earlier quoted context omitted.

Well, we probably could throw in the towel. The definition of the word is ever-changing and context-dependent, AND subjective to the receiver. That doesn't sound like something you can train a model for.

If you had access to the reactions of someone reading the content, you could _possibly_ train an agent to spot textual patterns likely to cause the reader to have negative reactions. 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.

But think about how this is trained. As with all of the authoritarian anti-offence rhetoric (i.e. not person to person politeness, but politeness enforcement), the response should be: who gets to decide?

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.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#146

Post by madrox »

KMag wrote: post #132
madrox wrote: post #58

Earlier quoted context omitted.

It's not that far off today from how junior engineers treat stack overflow. There's just fewer intermediate steps.

I think we all cargo-cult our way into programming and then over decades get better and better understanding of what we're doing and why. 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 wh…

This maps to my experience as well. Think many senior engineers forget what it's like to learn programming. It is, in fact, incredibly hard.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#147

Post by Spivak »

IshKebab wrote: post #90
abeppu wrote: post #35

We're all focusing on the weaknesses of co-pilot (the comments can be longer than the code produced; you need to understand code to know when to elaborate your comment, etc). 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…

The fact that "toxicity" is not well-defined or black and white and you'll never be able to reach 100% accuracy is extremely obvious and not very interesting. That's probably why nobody is talking about it.

Would you say the same about a less divisive speech pattern like a flamebait/flamewar classifier? Because it’s already double with simple heuristics like upvote/comment ratios and seems like a fine fit for a moderator assisted classifier.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#148

Post by IshKebab »

Spivak wrote: post #147
IshKebab wrote: post #90

Earlier quoted context omitted.

The fact that "toxicity" is not well-defined or black and white and you'll never be able to reach 100% accuracy is extremely obvious and not very interesting. That's probably why nobody is talking about it.

Would you say the same about a less divisive speech pattern like a flamebait/flamewar classifier? Because it’s already double with simple heuristics like upvote/comment ratios and seems like a fine fit for a moderator assisted classifier.

Yeah I would say the same. It's also not well defined or black or white but that doesn't mean you have to just give up. You can do better than nothing in both cases.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#149

Post by TauNeutrino »

It's an AI writing another AI, the miracle of guided reproduction! As programmers we should appreciate the subtle meta in that.

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.

Re: Building a no-code toxicity classifier by talking to GitHub Copilot

#150

Post by Loeffelmann »

I've been using copilot for a bit now and it's honestly really impressive. I was skeptical at first and didn't really believe all the praise but it works so well. You still have to understand what the code is doing but more often then not copilot spits out a out of the box working solution. It is phenomenal at writing tests. I can pretty much tell it "write tests for this function" and it will do it with surprising Quality and maybe even goes through cases I haven't thought about.

I think this technology will really shake up how we code.

Post reply on HN