This is very concerning in a number of ways
-
I lost the actual page where I saw this in an article, but had copied this much before. I'm not even sure it is from a reliable source:
"A first-of-its-kind incident has shocked the world after a civil servant robot at Gumi City Council in South Korea was found unresponsive after what appears to be a deliberate plunge down a two-meter staircase.
Local media and social media users have called it the first “robot suicide” in the country."
Those of you that know me on here are well aware of my misgivings regarding this whole AI thing, but this tops it all. It raises two main questions in my mind, both of which I guess are possibilities.
Is this something that AI came up with on its own and caused this robot to destroy itself?
Is this something that is buried in the code by developers and is a planned event triggered by some circumstance?
Or is this evidence of the dangers of relying far too much on technology instead of our own instincts and understanding?
I've never been much of an alarmist or conspiracy theorist, but I do pretty much try to anticipate results of the things we create. After all, our careers are largely based on just that - being able to anticipate, predict, and prepare for such things.
Here is that kind of insane response I saw on one web site:
What do you all think?
- This topic was modified 4 months, 3 weeks ago by skeleton567.
- This topic was modified 4 months, 3 weeks ago by skeleton567.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) ) -
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
-
A lot of links for that incident show up with the following search.
https://duckduckgo.com/?q=robot+suicide
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Bugs. Natural and inevitable. And probably perpetual.
I didn't trust virtual machines when we first started using them. And, we had problems. Then, over time, they just became a standard. I jumped on the cloud the moment I saw Azure SQL Database. But, let's be fair, out of the gate, it was a horror show. Then, over time, lots of people are using it. Does this mean that virtual machines still don't have problems? Nope. They do. Does it mean that any technology that isn't flawless can't be used? Well, we'll have to find that flawless technology first, cause from what I can see, even toasters can be messed up pretty badly, let alone software.
Do I put a lot of faith in AI today? Nope. But do I see it getting better over time and there will be a moment when it becomes extremely useful, even the standard mode for getting lots of stuff done? Yep.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning -
"Bugs. Natural and inevitable. And probably perpetual."
Grant, I totally agree. There will always be bugs. Sometimes even the bug fixes themselves introduce new bugs. I might add "and sometimes intentional.
What I am concerned about regarding AI is the potential for INTENTIONAL 'bugs' that may or may not be discovered.
Dumb Example:
I'm creating a vote counting process. My instructions are:
Maintain a temporary variable for the count for each of the candidates. Every time a temporary count for candidate A reaches 1000 multiplied by a random number between 1 and 10, add a random quantity between 1 and 100 to the count. reset the variable, and start again. At the end of the process, self-destruct the code that does this.
If discovered, the excuse is "Well, you must have 'lost' some ballots. Has to be the manual system that failed". Then do a recount WITHOUT the AI 'bug', and all is good.
The point is that AI can and will be constructed to do its damage and then self-destruct the evidence. There is more risk in trusting coders than in trusting code. Remember the TV show called 'The Price is Right'.
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) ) -
Yep. Could be a real problem. No denying it. But, I tend towards this.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply