cat posts/2023-11-21-the-openai-weekend-and-ai-vendor-risk.md

The OpenAI weekend and AI vendor risk

· 5 min read · ai vendors risk openai

I’m writing this on Tuesday morning, and I want to be careful about that, because the story has changed roughly every six hours since Friday and it may have changed again by the time anyone reads this.

Where it stands as far as I know: on Friday afternoon OpenAI’s board fired Sam Altman, saying in a blog post that he “was not consistently candid in his communications with the board”. Greg Brockman was removed as chairman and quit a few hours later. Mira Murati was named interim CEO. Over the weekend there were talks about bringing Altman back, which didn’t produce a deal, and on Sunday night the board named Emmett Shear, who used to run Twitch, as interim CEO instead. Shortly after that, Satya Nadella announced that Altman and Brockman were joining Microsoft to lead a new AI research group. On Monday a letter went around inside OpenAI saying the signers might quit and join Microsoft unless the board resigned and reinstated Altman, and by the evening most of the company had signed it, by every count I’ve seen. Ilya Sutskever, who is on the board and was reportedly central to the firing, signed it too, and posted that he deeply regretted his part in it. There are reports this morning that negotiations with Altman are still going on.

I have no idea how it ends. Altman could be back at OpenAI by the weekend, or OpenAI could be a shell with a famous API and a few hundred empty desks, or something stranger. I’m not going to guess, partly because everyone else already is.

Why I care, selfishly

We have one feature in production that calls OpenAI’s API. Support agents get a summary of a long ticket thread at the top of the ticket, written by GPT-3.5, with a “regenerate” button and a thumbs-down. It shipped in September, after OpenAI went through vendor review and onto our subprocessor list, which meant emailing every customer in August, exactly as the April policy said it would. It’s popular with the support team, it saves them real time on the long threads, and it costs us a few hundred dollars a month. We also have an internal prototype that answers questions from our own docs, which runs on GPT-4.

On Friday night I did the thing you’re supposed to do when a key vendor looks shaky, which is ask what we’d do if it went away. The honest answer was that the summary feature would break, the button would spin, and we’d find out from the support team.

That’s not great, and it isn’t new either, I just hadn’t looked at it squarely. The OpenAI API has already had a busy month without any help from the board. DevDay on the 6th brought GPT-4 Turbo and big price cuts, which was good news. Two days later, on the 8th, ChatGPT and the API had hours of outages that OpenAI put down to a DDoS attack. And back in July they announced that the older completion models would be shut down on January 4, which is a deprecation I have on my own calendar for a different prototype. Vendors change. This weekend is just the version of it that’s on the front page.

What “wobble” could mean

Writing it down helped, so here’s the list I put in our planning doc. These are the ways this could hurt us, roughly from most to least likely:

  1. Nothing happens to the API, but the company is distracted for months. Roadmap stalls, support gets slower, the things they promised at DevDay arrive late.
  2. Prices or terms change, because whoever ends up running the company has different priorities or needs money faster.
  3. Reliability drops because the people who keep it running leave. If most of the company really walks out, someone still has to be on call for the API.
  4. The API goes away or becomes something we can’t use. I think this is unlikely in any short timeframe, but I’d have said the same about Friday.

None of these are hypothetical in general. We’ve lived through a vendor repricing on thirty days’ notice, and a cloud account being suspended. What’s different with a model is that switching isn’t a config change. The prompts are tuned to one model’s habits, and the output from another model will be different in ways a test suite doesn’t easily catch.

What we’re doing about it

The first thing, which I should have insisted on in September, is making the feature fail gracefully. If the call fails or times out, the ticket shows without a summary and a small note, instead of a spinner. That was a two-hour change on Monday.

The second is a thin interface between our code and the model. Right now we call the OpenAI SDK directly from two places. It’s going behind one function that takes a ticket and returns a summary, so swapping the provider is a change in one file. I resist abstractions like this most of the time, because they tend to get designed around the first implementation, but here there’s a concrete second one waiting.

The third is the hard part: having an alternative that’s been tried. I see three candidates. Azure OpenAI runs the same models under Microsoft’s operation and contract, which protects against OpenAI’s own infrastructure falling over and protects against nothing else, given who just hired whom. Anthropic’s Claude 2 is a genuinely different model and company. And there’s running Llama 2 ourselves, which I tried on a laptop in July and which was close to GPT-3.5 for summarizing, if not as good. To compare them properly we need an eval set, and we’re building one: 60 real tickets, with a summary for each that a support lead wrote and marked as good, and a simple rubric for scoring what each model produces. Real tickets means only OpenAI and a model we host ourselves can be scored on it until anyone else has been through the same vendor review, which for Anthropic would mean another round of customer emails. That’s slow, and the eval set is the piece I’d want regardless of this weekend, because it’s also how we’d know whether GPT-4 Turbo is worth switching to.*

I don’t want to overreact. GPT-3.5 for ticket summaries is a small, contained use, and if OpenAI is fine by Friday we’ll still have spent a few days on things we should have done anyway. But the model is now a dependency like a database or a payment provider, except that we have far less experience with how these companies behave under stress, and so do they.

* Six months ago I’d have called a 60-ticket eval set overkill for a feature like this. That was before I watched two models produce summaries that read equally well and disagreed on what the customer actually wanted.