The only way to make check whether a LLM output is true is to do the work (to have it dkne by a real person).
For tasks that are trivial to verify, it's ok: a code compiler will run the code written by a LLM. Or: ask a LLM to help you during the examples mapping phase of BDD, and you'll quickly be able to tell what's good and what isn't.
But for the following tasks, there is a risk:
- ask a LLM to make a summary of an email your didn't read. You can't trust the result.
- you're a car mechanic. You dump your thoughts to a voice recorder, and use AI to turn it into a textual structured report. You'd better tripple check the output!
- you're a medical doctor, attempting to do the same trick: you'd have to be extra careful with the result!
And don't count on software testing to make AI tool robust: LLM are non deterministic.
"Microsoft Bing Copilot has falsely described a German journalist as a child molester, an escapee from a psychiatric institution, and a fraudster who preys on widows.
Martin Bernklau, who has served for years as a court reporter [...] asked Microsoft Bing Copilot about himself. He found that Microsoft's AI chatbot had blamed him for crimes he had covered."
That's why I set up my own thing.
I don't care about analytics at all, so I just wrote a simple build system doto generate some very basic HTML redirects.
That was unclear for me too, so I opened an issue (the very first of the project, yay!). The instructions have been updated, they might be a bit clearer now: direct contributions to the code are welcome.
It's quite hard to create something that works optimally on a first try. I think I never managed to do so!
The first schema was slow, but hey, it worked, good job! That is a huge first step. Modifying it so it runs much faster can definitely come next.
Yep, you still have to deal with all kind of people when you do OS, and that isn't always nice.
I once made a PR to a project I use a lot at work. The PR was about the documentation of the project, so no change to any feature, no new thing, just an improved version of the tutorial... Or so I thought.
The maintainers refused my PR.
My first instinct was to be upset about it, but then I thought "this might be a natural reaction because they said 'no', but maybe, just maybe I can avoid acting like a kid and use my brain". So I re-read their reply: it contained a valid reason and provided me with a good solution to my problem, I thanked them and moved on. They were just right to refuse my PR.
I really hope that Intel wakes up: struggling with fab processes is not their biggest problem, their marketing strategy is. There are some really talented engineers in there, but the product segmentation and the way the "features" are sold is in my opinion not good at all.
I work as a tester for a some websites: I test the GUI and the REST APIs used by the smartphones apps.
These tools make my work a lot easier (they might not be the best for your specific needs, they are just the ones I use):
- Talend API Tester: a Chrome extension to test (you probably guessed it) APIs! I can automate many things with it and use regex in my tests. If I had to do all that manually, I'd have become crazy by now.
- Watir: a Ruby library that is essentially a wrapper around Selenium. Watir is easy to use, and I found Ruby very easy to learn. Also, bundler makes the process of keeping my libraries up to date really painless (when my webdriver tells my that it can't communicate with the browser because it has become outdated, a simple 'bundle install' fixes the issue)
[] Note: I don't need to do a fancy program, I just need to write some farily simple scripts that automate actions a verify a few things on web pages.
I don't mind the "-gates" : issues are bound to arise. The only way to avoid "-gates" is to stop producing and selling anything at all.
Modifying a manufacturing process to correct a flaw is not always easy and can take some time, so I understand the "We'll fix it in a later iteration" stance.
I think the real issue here is the failure of Apple to acknowledge the technical flaw. That, and the the poor customer service. If it's a design issue, it should be covered in the warranty : it would be costly on a short term perspective, but in this specific case I think it would be worth it, as it would keep customers happy with the brand.
Bad news: Apple takes us for fools, again. this sucks.
Good news: many businesses and influencers (iFixit, Louis Rossman, Linus Tech Tips ...) are talking about it. This is bad press for Apple. The more noise we make about these issues, the better the chances are that Apple improves on its flaws.
I'm not overly optimistic about it: spreading the word about Apple's bad habits might be useless. But trying and failing is in my opinion better than not trying at all : at best, Apple makes better product ; At worst, they just keep on doing what they're doing.
That is a compelling argument. Be careful with the terms of use though, they can hide a few surprises.
Example: in Vectary's terms of use[1] I interpret the section 4.6 as "backing-up your data is your responsibility. If our servers burn, we might not be able to recover your data and we won't be responsible for it".
That being said, the limits of Vectary's services seem to be clearly stated, so one can adapt to them (by using some storage drives from OVH, Digital Ocean or any such provider to back-up the data, for instance)
Oops! Sorry for the huge typo in my comment. "they having only some portions of their needs met" should be read "they are fine with having only some portions of their needs met".
For tasks that are trivial to verify, it's ok: a code compiler will run the code written by a LLM. Or: ask a LLM to help you during the examples mapping phase of BDD, and you'll quickly be able to tell what's good and what isn't.
But for the following tasks, there is a risk: - ask a LLM to make a summary of an email your didn't read. You can't trust the result. - you're a car mechanic. You dump your thoughts to a voice recorder, and use AI to turn it into a textual structured report. You'd better tripple check the output! - you're a medical doctor, attempting to do the same trick: you'd have to be extra careful with the result!
And don't count on software testing to make AI tool robust: LLM are non deterministic.