← All episodes
Alex Khan

Episode · Sep 28, 2022

Alex Khan, ZebraKet

What Testing Every Amazon Braket Backend Actually Teaches You

Summary

Alex Khan, Quantum Computing Entrepreneur and CEO of ZebraKet is interviewed by Yuval Boger. Alex and Yuval talk about Alex’s book “Quantum Computing Experimentation with Amazon Braket,” his experience working with different hardware and software packages on Braket, the best way for optimization experts to get into quantum computing, and much more.

Key takeaways

  • Running the same problem across different Braket hardware backends exposes real differences in queue times, error rates, and how much code has to change between providers
  • Writing a practical book meant documenting the friction points that vendor demos usually skip, like calibration drift and inconsistent qubit connectivity across devices
  • People with an optimization or operations research background can get productive on quantum hardware faster than typical software engineers because the problem framing already matches formats like QUBO
  • Amazon Braket's value is less about any single quantum processor and more about having one consistent interface to compare gate-based and annealing approaches side by side

Transcript

Yuval Boger: Hello, Alex, and thanks for joining me today.

Alex Khan: Hi, Yuval. It's a pleasure being with you.

Yuval: So who are you and what do you do?

Alex: Well, I'm Alex Khan, and at the moment I'm an entrepreneur in quantum computing, though my journey started with engineering and physics. I was a dual major in college.

Eventually I got into IT and built automation solutions for claims processing and document automation solutions for policy generation. Then I got my MBA, which is kind of a story in itself, and then became AVP of Business Technology for Lincoln Financial. So I saw both the solution side, providing solutions, and also the corporations: how they evaluate solutions and their strategy to bring in new technologies.

So in 2018, I found out about quantum computing through the D-Wave Leap program, and to me that was just another technology that I wanted to learn about and get into. That's where my journey with quantum computing got started. And really it's from the perspective of: is it a technology that we can use?

Is it useful for companies? That's my perspective.

Yuval: And you have a recent book out. Could you tell me a little bit about the book and what made you start writing it?

Alex: Yes. The book was a year or more of considerable effort. Initially I had said I'm not going to write a book, because it's usually a lot of work and I was already very busy.

But Packt Publishing called me up and encouraged me to write the book, and I decided to write it because over the last few years I had learned some lessons on how to get into quantum computing and how to make use of quantum computing through various experiments and projects that I'd worked on.

And I thought that would be a different perspective that I don't see a lot in the quantum computing industry. We talk about the physics or the circuits, but we don't talk a lot about the process of actually making use of quantum computers as they are right now.

There's a lot of theory, but I'm more hands-on. I have a hard time hyping anything, so I have to get hands-on and see what something can do before I can promote it, and I thought that would be a good lesson and good information to put in this book. The reason it became more about quantum computing experimentation with Amazon Braket is that when I was starting, Amazon Braket was actually the service, or the platform, that made various quantum hardware available.

I started out with Rigetti and IBM. I couldn't access IonQ at that time, and even Rigetti was a little more complicated to access directly. So when Amazon Braket came out with a pay-per-use service, I was very excited about that, because I could just use the ion trap, I could use Rigetti, and I didn't have to worry about a lot of the SDK and setup and all of that.

So I thought that was a good platform to get exposed to multiple quantum computers. I thought it was somewhat efficient, and I thought it would allow me to bring my optimization work, which is all of the experimentation I'd done using D-Wave, into both annealing and gate quantum computing, and kind of make it a nice cohesive story in that area.

So that's what ended up happening.

Yuval: So, to the million-dollar question. If I'm an enterprise customer today, could I do something truly useful on Amazon Braket, whether it's optimization or something else? Or is the state of the service right now more about learning and experimentation and getting to know quantum a little bit more?

Alex: Yeah, it's certainly about getting to know quantum. I mean, it's taken me three years to get comfortable with the technology and how it can potentially be used. Just explaining quadratic relationships to others is a challenge: having people understand the difference between a linear solver and a quadratic solver, and the benefits of quadratic relationships…

I mean, people don't think in those terms. Most people in the industry are using a tool; there's very little optimization. In my whole career, we never optimized anything. So optimization is something new. Combinatorial optimization is new. Quantum computing is new. And the potential benefits of this technology are not that easy for people to grasp.

So I would say the first step is just to get comfortable with that. Now, how far can quantum computers go with it, and can we actually get something useful? I would say yes. I've done enough experiments. They're models. I wouldn't say that they are industry-level problems, but they are models of real-world problems that can actually be solved.

They can be solved on D-Wave, with QAOA. They can be solved on simulators. And in the book, I show that you can get reasonable results even through Rigetti or IonQ, as long as you stay within the framework of what those systems can actually solve right now. So my goal isn't to show that quantum computers can only solve a certain set of problems.

My goal is just to see what we can do right now. Stay within the tool that you have. I used to have a microscope, which could only see so far. It had a zoom of a certain number, and I used it for whatever it could do. And I'm doing the same thing with quantum computers, just using them right now for what they can do.

Yuval: So if I'm a classical optimization expert, I've been doing optimization all my life, hypothetically, and I hear about this new quantum technology, how deep do I have to get into quantum to do something useful with it? Do I have to understand matrices, tensor math, the gate level? How deep do I have to go to do something useful in optimization using quantum technology?

Alex: Yeah, that's a good question. Industrial engineers and industrial scientists that are doing optimization are using linear solvers. They have a very good understanding of how to optimize within certain constraints, and it's a well-known and very broad discipline. I didn't go into industrial engineering.

I had no idea what that was. But having gotten into optimization now, I have a stronger appreciation of it. So it is a different discipline, and people from that background do have a good understanding. The challenge, I think, is that a lot of the equations are more linear programming types of equations.

The quadratic part has, to some extent, been kept out, or even higher order. You go from second order to third order, like the power of three. Those kinds of equations have been kept out of the solvers because, traditionally, the solvers couldn't actually solve these problems efficiently.

So that's the whole point of linear programming. I think even that group of people can now begin to see the world differently, with quantum computers coming out, and look at those quadratic relationships. For example, with Microsoft QIO, you can go to higher-order problems. So the question is: can we recognize these higher-order relationships in our real world?

For example, we talk about bundling: if you buy one item, you want to buy some other item with it. Is that important? Is that not important? Because you can bring out those quadratic, or pairwise, relationships from the real world, and you have to think about whether that's useful for you.

Because if it is useful, then these quadratic solvers, or QUBO solvers, will eventually be able to give good results and have an advantage over the linear solvers.

Yuval: If I understand you correctly, the classical optimization expert would want to understand what QUBO is, or other nonlinear optimizations, and would have to understand how to express real-world problems as a QUBO or other optimization problem.

But once you do that, you don't necessarily have to understand whether it's an annealer or a trapped ion or a superconducting computer. You don't have to understand what a Hadamard gate is. Is that a fair statement?

Alex: At this point, no. I think eventually that would be a fair statement. Especially, I mean, you're involved with Classiq. There will come a time when you don't have to worry about the circuits for gate quantum computers.

But for now, it depends on the technology you're using. D-Wave has come out with a number of different toolkits for their hybrid solvers, like their binary quadratic model and their CQM, which is a new model that allows you to just put down the actual objective, the variables, and the constraints, and behind the scenes it develops the QUBO.

So you don't have to worry about developing the QUBO. Now, I would say that's still good for prototyping. If you were actually building a solution for the industry, you would want to know how to build a QUBO and optimize your own QUBO, rather than give it to a generic algorithm to build the QUBO itself.

But it's great. You can very quickly get answers, and you don't have to go very deep into building the QUBO. With gate quantum computers, there isn't a tool available that will take your real-world objective function and create a QUBO. You would have to build the QUBO.

You would have to understand that the QUBO is going to go into QAOA. You're going to build a QUBO, or Hamiltonian, and you're going to run it through QAOA. So you have to know a little bit about the mechanics of QAOA. QAOA isn't a single solver where you just give it a problem and it'll solve it and give you the perfect results.

I think at this point you have to know QAOA, know its limitations, and work with it to optimize it, to get the right parameters. So yes, you have to know a little bit about opening up the hood, looking inside the engine, and tweaking it a little bit to make it work properly for you.

In the future, as the gate quantum computers become more powerful and the algorithms are more automatically optimized, or maybe there are better ones than QAOA, then one might not have to worry about that. And maybe at that point people will have built some layers where, for the gate quantum computers, you can have 50,000 variables, like we can on D-Wave's hybrid model.

And it's competing with linear programming solvers, where you don't have to know all the insides. But right now, I think you do have to. And that's one of the reasons I spend multiple chapters explaining QAOA, exactly how QAOA is actually optimized, and what kind of results come out of it.

As you change the parameters, I show how the probabilities of the best solution, or the minimum value, begin to increase, and I actually visualize all of that. So it's not just about the equation; it's about getting an intuition for what QAOA is doing.

Yuval: When I look at some of the book chapters, for instance, chapter 10 in your book, you write about various hardware platforms.

Putting D-Wave aside, it looks like you did some work with Rigetti, maybe IonQ, maybe others. Did you see any meaningful differences between the various gate-based computers, or should the user not have to care about that?

Alex: They definitely have to care about it, because they're so different. The ion trap that I had access to is 11 qubits; now you can have access to the 20-qubit ion trap.

And it's a fully connected graph for the ion trap, versus Rigetti, where I had access to the M-1, which was 80 qubits. Now they have the M-2, which is also 80 qubits. But it's very loosely connected; there are very few connections between the qubits, so you can only put a very sparse matrix on that model.

So that would be like solving an equation where you have very few quadratic terms. In the book, I basically take the actual graph of the Rigetti system and use that graph as a starting point for the equation. So I'm basically using Rigetti the way Rigetti is designed.

This is my analogy with the microscope, right? If I've got a microscope, I'm using it exactly the way it works. I'm not trying to make it do anything it doesn't actually do. So I'm using those different devices for what they're meant for. In one case, you have 11 qubits fully connected, so I give it that problem.

In the other case, it's 80 qubits with very few connections between the qubits, so I give it that problem. And when you look at it that way, you begin to actually see the value of what has been engineered so far. Now, of course, as the connections increase or the quality increases, things will get better.

With the current systems, I show that you can see the best answer using QAOA, and those answers show up. But if I give Rigetti, for example, a problem with a large number of quadratic relationships, or try to do multiple iterations, or Trotterization of QAOA, there'll be so much error that we won't see any results.

But that's not the point, right? Just seeing nothing doesn't help. It's good to see something and know which direction to go.

Yuval: So if the users need to understand the hardware, to what extent do they need to be proficient in multiple software packages? I see in the book that you cover PennyLane and Qiskit and maybe a couple of others.

Does it matter to the users, in your opinion?

Alex: Well, I tried to focus only on the SDKs or tools that Amazon Braket has brought in. The book was about Amazon Braket. I took the approach of writing my own code for everything. I didn't use any libraries. For example, in Amazon Braket, you cannot build the Bloch sphere.

So I could have used the Qiskit library to build the Bloch sphere and then somehow translated the circuit for Braket. But I really wanted to stay purely within Amazon Braket's framework, so I actually had to write the whole code for building the Bloch sphere myself. And that code is included with the book.

The point being that the Amazon Braket team is adding a lot of different libraries as they feel they're useful for their customers. PennyLane is one of them. They've now added a plugin for Qiskit. So they're going to expand the Amazon Braket service and bring in different libraries. You can bring in pytket, or all kinds of other tools. And for someone who's actually in quantum computing, there's no limitation, right?

You can use all kinds of different tools. You could use Classiq to build a circuit, then decide to send it to a Braket device. Or you could be working in DevOps with the EC2 services, using some other service in Amazon Web Services, and then pull in data from there and bring it to Braket.

So the Braket team is not saying that you should work in Braket in isolation. But in order to teach about Braket, I wanted to make sure that I focused on what is purely Braket. So with that, yes, there are so many packages for natural language processing and quantum machine learning.

There are so many other packages. It's up to the user to decide how they want to integrate a different package with the features and functions available in Braket, and make use of the devices on a pay-per-use basis if that's of value to them. So the book is really focused on Braket and what you can do out of the box.

But there's a lot you can do depending on your knowledge. A lot of people started out with Xanadu through the QHack hackathons. Some people started out with IBM; others started out with machine learning. So they can all eventually decide if Braket is an extra service they want to add to what they're already doing.

But the main purpose was for people who are already in the industry and using Amazon Web Services; Braket just becomes another service for them to add. So I think it's up in the air how people who start out with Qiskit or some other tool will find their usefulness in Braket.

But those are connected now.

Yuval: You mentioned that it took you a year to write the book, so you've written a lot of text and a lot of code, and spent a lot of hours experimenting with various packages. What's the thing, or things, that surprised you the most during that process?

Alex: Regarding my own skills, or regarding Braket?

There was just a lot to learn. Initially, I had a vision for what I wanted to do with the book. I wanted to get deeper into other use cases that I had done, like portfolio optimization. I've done COVID optimization. I've done a number of different experiments with Shor's algorithm using both Qiskit and the Amazon simulators.

So I wanted to get that far. I wanted to really go to that level. And as I started writing the book, what I realized is just the steps it takes to educate someone, or the way I wanted to educate someone. I didn't want to just breeze over stuff, give an equation, and move to the next chapter. I really wanted to get people hands-on and have an intuition for how each step works, and get comfortable, for example, with the quantum Fourier transform, or working with phases.

Then with QAOA, I wanted them to actually see how QAOA, by changing parameters, begins to show better results for the minimum. How it brings out the minimum. So as I went through that process, I actually ran out of pages and ran out of chapters for how much I could put into the book.

And it would've taken another six months to do what I wanted to do originally. So I did cut a lot of material, and the book ended up really becoming about Braket and getting to the point where you're ready to actually have a real conversation on use cases.

So I think my learning was, number one, writing a book is very hard. We had to go through so many edits. My analogy for writing a book is moving sand upstairs: every grain of sand has to make it up. But it was a very useful exercise in gathering my own thoughts on things that I thought I knew, or things I had read. And when I didn't have a library to use and was determined to write it myself, I really had to get down to the theory and the details of how that thing worked.

So it was a great learning experience for me as well.

Yuval: As we get closer to the end of our discussion today, you mentioned that you were AVP, I think, at Lincoln Financial. A company like Lincoln Financial, when should they get into quantum? Should they do it a year from now? Should they have done it a year ago?

Should they start now? What's your perspective?

Alex: Well, my general sense is that companies like Lincoln Financial are already at least hearing about quantum computing. I've talked to the CEO of CareFirst, which is a Blue Cross Blue Shield health insurance company, and he already knew about quantum computing.

And if you talk to the VP of architecture, these are people who are supposed to know what is out there. So I would expect a company like Lincoln Financial, or any company, to at least be looking, listening, and being aware of the technologies and where they are.

Very quickly, these people are going to find out that this technology is most likely not ready for them. And that's the kind of evaluation I used to do, and my teams used to do. We were always looking at: what do our customers want? What are our goals, and does the technology fit that?

So if the technology is not ready, it's not ready. Now, that's not to say that some companies won't have an entrepreneurial group, or a group that supports startups, and start having conversations with them and maybe support them. That's more of giving back to the community; it's not necessarily of use for the company.

When I was AVP of Business Technology, I was responsible for the portfolio of the company. This is the project portfolio, not the financial portfolio, but it is a financial portfolio as well, because you're making choices: if you bring in a new technology, there are costs associated with it, and what are the benefits?

And every officer, or every business sponsor, has to be able to prove that the technology they're bringing in is going to have a value or a return. So I don't think quantum is at the point where, if I were the portfolio manager for that company, somebody could bring it in and prove to me that the technology is going to have a benefit for the company.

So I think right now it's still in the early stages. We have to prove it out under certain use cases. I've seen that in certain use cases you can get some good answers. But is that use case of value to a company? And where is it of value? If you look at some of the examples from D-Wave, D-Wave has hundreds of use cases that they have put on their website and on YouTube.

Some of those use cases, like the one by SavantX at the Port of Los Angeles: they were able to find a specific use case where they could get faster results and give value to the truck drivers, which was not available before. But it took them a while. I think it took them three years to find that specific use case and show that clear advantage.

Now, that is not to say that somebody else can't come up with a supercomputer or a genetic algorithm and say, "Hey, I can get the same result." But the point is they got there with an optimization solution using D-Wave that serves the purpose. And that's, I think, what we have to look for in these financial institutions and in supply chain: a solution that is valuable enough and was delivered by a quantum technology. Even though maybe somebody else can do it also, at least you get there first with a solution.

Yuval: It sounds like a time for experimentation, which dovetails with the title of your book, "Quantum Computing Experimentation with Amazon Braket." Alex, how can people get in touch with you to learn more about your work?

Alex: I'm actually in quite a few places, so I think the best thing is to just do a Google search for me: Alex Khan Quantum.

I think that usually brings up all the links. But the easiest place is usually LinkedIn. I'm available on LinkedIn a lot, and I do chat with people there, so if anyone wants to connect with me, that's the best place.

Yuval: Excellent. Well, thank you so much for joining me today.

Alex: Thank you, Yuval. It's a pleasure.