|
|
|
|
|
by jdp23
3744 days ago
|
|
Thanks for the reply, and interesting followup with ALICE. If you're using "software QA failure" in the very general sense of "a defect got introduced and then propagated to production", then yes that's what happened here. But then you're essentially saying "the root cause of this defect is that a defect got introduced and then propagated". This isn't useful for process improvement (it's true for every defect, so doesn't give any insight into what happened). If you're right about them reusing ALICE, then a more useful way of looking at the root cause of the repeat-after-me bug is "component reuse without considering the attack model". That highlights other situations where there are risks of similar defects, and points to ways to prevent or detect similar defects. Since there were other bugs as well, the requirement and/or design issues might still be a better candidate for root cause for the whole Tay-fail. One of the things you discover doing root cause analysis is that there are almost always multiple contributors, and you typically want to make process changes at multiple levels. |
|
Context: my blog posts are meant to contrast with "experts" who claimed that poisoning social AI was just in the nature of learning systems, even when they worked as designed (i.e. had no defects). They are claiming that Tay learned to be foul mouthed and racist, and thus had become foul mouthed and racist.
If that were true, then this undesirable behavior would not be a software QA problem. The AI would be working as designed. No QA process would change things.
In contrast, I'm claiming (from evidence) that the main problem in Tay is due to a hidden feature in a reused library + rule set that should have been detected and removed in a QA process that considered various attacks. BTW, this attack (getting bot to repeat naughty words) has been around since ELIZA in the 60s.
The other failings of Tay (esp. no black list) are design and requirement failures, not QA failures.