What you see here is the last week's worth of links and quips I have shared on LinkedIn, from Monday through Sunday.
For now I'll post the notes as they appeared on LinkedIn, including hashtags and sentence fragments. Over time I might expand on these thoughts as they land here on my blog.
A university prof has (wrongly) accused some students of turning in work written by ChatGPT. How did he determine who had cheated? His sleuthing skills boiled down to:
"A professor accused his class of using ChatGPT, putting diplomas in jeopardy"
This is a particularly nasty form of "because The Algorithm said so." It's bad enough to trust any AI output as gospel truth. Even worse when the AI is an LLM – a type of model that is known to regularly "hallucinate" (emit nonsense). LLMs capture grammatical structure, not necessarily factual structure, so you need to check their outputs before acting on them.
What's happened here highlights a wider issue: executive data literacy is a key element of AI safety and AI risk management. Companies expose themselves and others to needless risks when they put too much faith in a technology they don't truly understand.
Doubly so when they let the robot make the decision, instead of weighing the robot's outputs in their decisions (and taking the responsibility for doing so). We've already seen cases of people facing legal troubles or job loss because an automated system decided they were up to no good.
At what point do companies slow down and learn when/how/where to put humans in the loop?
(I highly recommend Paul Scharre's book Army of None for a deeper explanation of this topic. He notes that a proper autonomous weapons system balances human and machine involvement. Either the AI marks a target and a human makes the decision to take action; or the human marks the target and the AI takes action. If you unthinkingly follow the robot's bidding, you are effectively letting the AI both mark the target and take action.)
Another example of letting machines take on work that is dull, repetitive, and predictable:
"Sweetgreen Tests Robots to Make Faster, More Efficient Sad Desk Salads" (Bloomberg)
Two points stand out.
The first:
It turns out that it’s really, really hard to build a robot that approaches the adaptability of a human when it comes to all the tasks involved in preparing food. Today’s robotic solutions are piecemeal.
This is to be expected when automating any process or procedure. It's rare that a single robot (of the mechanical, software, or AI variety) will be able handle everything stem-to-stern. Instead, expect to break up a process into specific tasks, as robots tend to handle (some) narrowly-scoped work very well.
And the second:
On top of the labor savings and improved accuracy, Sweetgreen believes the automated assembly line may be able to handle a greater number of orders at peak times. It might also, the company says, make the jobs that are left more appealing. Frantically scooping quinoa while being barked at by teens in yoga pants is nobody’s dream job.
This matches my usual refrain: instead of using robots to outright remove people from a company, we can free them up for work that actually requires human experience and nuance. And also leave them some spare cycles for those times when (not "if," but "when") the robots fail.
"Les effets ambivalents de l'intelligence artificielle sur le travail" (Les Echos)
Point clé:
Enfin, et sans doute plus que jamais, gardons en tête les mots de Jean Fourastié : « La machine conduit l'homme à se spécialiser dans l'humain. »
Releasing a generative-AI, LLM-driven chatbot requires special considerations for AI safety and AI rIsk management .
I've jotted down my thoughts in a recent blog post. This explains both the source of the exposures, as well as some ideas on mitigation:
"Risk management for AI chatbots"
Perhaps the data transfers happened because they were being shady with data. Perhaps the transfers happened because they're genuinely unable to trace how data flows through their organization.
Seriously. Let's say you were compelled to remove a single customer's records from your models and other data products. Do you have the data governance and infrastructure in place to make that happen?
"Facebook owner Meta hit with record €1.2bn fine over EU-US data transfers" (FT)
Ireland’s Data Protection Commission (DPC), the regulator responsible for holding the Facebook owner to EU data protection law, handed down the fine on Monday.
It said that Facebook, whose European headquarters is in Dublin, had violated rules requiring that transfers of personal data from the EU to the US had appropriate safeguards in place.
This is interesting: Netflix needs to balance "reduce password sharing" with "increase viewership for advertising." Both contribute to revenue, so it's not a simple either/or decision.
How do you balance the two?
This is a common problem in N-sided marketplaces, in that sometimes you have to subsidize one group (here, allowing people to use a shared password) in order to bring another group to the table (advertisers).
Hiring your company's first data scientist or ML engineer? People will offer you a lot of advice that sounds reasonable on the surface, but will probably backfire.
I summarized my take in a recent blog post:
"Four antipatterns when hiring your first data scientist"
This post is part of a short series on hiring in data science/ML/AI, including:
(For more posts on hiring, retention, and other such matters, check out the “employment” tag on my blog. )
This article is about Google, but it could apply to any number of companies out there:
Does this sound familiar?
[S]taffers have concerns about the impacts of Google's aggressive push to build generative AI into all of its products.
"Many AI goals across the company focus on promoting AI for its own sake, rather than for some underlying benefit," read one of the top-voted questions. The employee asked how Google will "provide value with AI rather than chasing it for its own sake," according to a recording of the meeting reviewed by Insider.
If you start with your business model, and the challenges you face, you stand a much better chance of surfacing real use cases for AI.
This one's been making the rounds:
"A lawyer used ChatGPT and now has to answer for its ‘bogus’ citations" (The Verge)
Lawyers suing the Colombian airline Avianca submitted a brief full of previous cases that were just made up by ChatGPT, The New York Times reported today. After opposing counsel pointed out the nonexistent cases, US District Judge Kevin Castel confirmed, “Six of the submitted cases appear to be bogus judicial decisions with bogus quotes and bogus internal citations,” and set up a hearing as he considers sanctions for the plaintiff’s lawyers.
When it comes to AI safety and AI risk management, this incident highlights three important points about large language models (LLMs) like ChatGPT:
1/ Always, always, always check the model's outputs. This is my old refrain of "never let the machines run unattended." And you need to do that with LLMs in particular because of point 2:
2/ Remember that LLMs pick up on patterns in grammar, not facts. All they see is that "this word usually follows this other word" and "this one word can sometimes be a substitute for this other word." Hence why most of what comes out of an LLM parses well, even when it is utter nonsense. Which takes us to point 3:
3/ Let's be mindful of accepting an idea just because it appears reasonable. People caught the use of ChatGPT in this case because it was part of a legal proceeding, a situation in which the parties involved are supposed to bring facts to the table and they get to check each other's work. Outside of this setting, I expect most people would have been able to hand-wave over the official-sounding documents and others would have accepted them as fact.
Four antipatterns when hiring your first data scientist
A handful of all-too-common pitfalls in hiring.
The always/never tradeoff in data collection
A reminder that risk and reward are a package deal