Czy komputery kwantowe są już gotowe planować produkcję?

W piątek po południu pan Zenon, kierownik produkcji w fikcyjnej firmie MetalTech, dostaje pilne zamówienie. Trzy części, trzy maszyny: tokarka, frezarka, spawarka. Każda część przechodzi przez maszyny w tej samej kolejności, a każda operacja ma inny czas technologiczny. Pytanie jest proste: w jakiej kolejności ułożyć operacje ze zleceń na maszynach, żeby całe zamówienie skończyło się jak najszybciej?

Kilka dni później pan Zenon miał dziewięć planów od zespołów QPoland Quantum Hackathon 2026. Wszystkie optymalne.

Na co dzień pracuję przy projektowaniu systemu ERP, więc planowanie produkcji to dla mnie jeden z wielu algorytmów. To zadanie przygotowałem na hackathon, który wspierała moja firma KLL-ERP, z jednym pytaniem: czy metody kwantowe dają tu dziś coś więcej niż zwykły komputer?

Krótka odpowiedź na pytanie z tytułu brzmi: nie, jeszcze nie. Ale droga, na której to widać, jest dużo ciekawsza niż samo „nie”.

Dziewięć zespołów oddało projekty [1]. Każdy kod uruchomiłem w izolowanym środowisku, a kluczowe liczby przeliczyłem niezależnie. Gdzie się nie dało, piszę o tym wprost. Numery w nawiasach kwadratowych odsyłają do listy źródeł na końcu.

Jeśli trafisz na nieznane pojęcie, jak QUBO, QAOA czy kubit, kliknij je w tekście albo zajrzyj do słowniczka na końcu artykułu.

Zadanie było celowo małe

Hackathon miał dwa etapy [14]. Pierwszy, obowiązkowy, był wejściówką: dwie małe instancje problemu.

• Instancja A: 2 zlecenia na 2 maszynach, optymalny plan to 4 godziny. Zapisana jako QUBO, po odrzuceniu niemożliwych godzin startu, ma ok. 8–12 zmiennych binarnych. W bezpośrednim kodowaniu każda zmienna to jeden kubit, więc taki obwód da się zasymulować na laptopie. Tu zespoły musiały rozwiązać QUBO algorytmem kwantowym, zwykle QAOA, na symulatorze albo na prawdziwym sprzęcie.
• Instancja B: 3 zlecenia na 3 maszynach, optymalny plan to 8 godzin. W zapisie czasowym, w którym każda zmienna mówi, czy dana operacja startuje o danej godzinie [15], QUBO ma 72 zmienne, a po odrzuceniu niemożliwych godzin startu 39 [14]. Pełna symulacja 39 kubitów wymagałaby ok. 8 TiB pamięci. To już za dużo na zwykły komputer.

QUBO to format, który przyjmują wyżarzacz kwantowy i QAOA [2, 6], więc zespoły budowały modele w języku, w którym da się rozmawiać z komputerem kwantowym. Przeniesienie takiego modelu na prawdziwy sprzęt nie jest jednak „za darmo”. Trzeba go dopasować do połączeń między kubitami, co zwykle dokłada kubitów albo bramek [16, 17].

Dziś liczymy takie modele klasycznie, na przykład na VeloxQ. Powodem nie jest sama liczba kubitów, bo dzisiejsze procesory mają ich ponad sto [18]. Ważniejszy jest szum. Dzisiejszy procesor kwantowy przypomina maszynę z dużym odsetkiem braków: im dłuższa operacja, tym większa szansa, że detal wyjdzie wadliwy. Analizy teoretyczne pokazują, że przy typowych modelach szumu głębokie obwody optymalizacyjne nie dają wyraźnej przewagi nad metodami klasycznymi, dopóki poziom błędów nie spadnie o rzędy wielkości [11]. Dlatego zespoły walczyły o to, co liczy się na każdym komputerze kwantowym: o jak najmniejszy, ale wciąż dokładny model. W bezpośrednim kodowaniu każda zaoszczędzona zmienna to jeden kubit mniej.

Drugi etap był główną częścią konkursu. Każdy zespół rozbudowywał problem po swojemu: dodawał terminy, przezbrojenia, awarie maszyn, więcej zleceń albo szukał sposobu, żeby zmieścić problem na mniejszej liczbie kubitów.

Wszyscy mieli rację. I to był pierwszy sygnał ostrzegawczy

Wszystkie dziewięć projektów doszło do optymalnych planów: 4 i 8 godzin. Na pierwszy rzut oka sukces. Na drugi pojawia się pytanie: skoro wszyscy mieli rację, to co tu właściwie różnicuje metody?

Odpowiedź jest niewygodna dla mnie jako autora zadania. Instancja 3x3 okazała się jednocześnie za łatwa, żeby cokolwiek udowodnić, i za duża, żeby wprost policzyć ją kwantowo.

W tym typie problemu (tzw. flow shop) wystarczyło wybrać kolejność zleceń, wspólną dla wszystkich maszyn [19]. Dla dwóch maszyn daje ją prosta reguła Johnsona [20], a od trzech maszyn problem jest w ogólności NP-trudny [21]. Łatwa była więc nasza instancja, a nie cały problem.

Trzy zlecenia można ustawić tylko na 6 sposobów, a aż 4 z nich dają optymalne 8 godzin. To jak test wyboru, w którym cztery z sześciu odpowiedzi są poprawne. Losowo wybrana kolejność trafia w optimum w 67% przypadków. Na instancji 2x2 są dwie kolejności, więc rzut monetą daje 50%.

Inaczej wygląda to samo zadanie zapisane jako godziny startu. Wśród 512 000 przypisań, w których każda operacja startuje dokładnie raz (po przycięciu niemożliwych godzin), poprawnych planów jest tylko 13. Tu losowanie praktycznie nie trafia.

Tyle że ten zapis potrzebuje 39 kubitów, za dużo na prostą symulację i na dzisiejszy, zaszumiony sprzęt [17, 11]. Zespoły stały więc przed wyborem: zapis na kilku kubitach, w którym optimum trafia nawet losowanie, albo pełny zapis, którego nie da się wprost zasymulować ani wiarygodnie uruchomić na dzisiejszym sprzęcie. Między tymi skrajnościami z wyraźnym efektem zmieścił się tylko jeden projekt. Wrócę do niego za chwilę.

W małym zapisie algorytm, który nie robi nic sensownego, i tak często „znajduje” najlepszy plan. Szansa, że wśród $N$ niezależnych prób znajdzie się sukces, wynosi $1 - (1 - p)^N$. Przy losowaniu kolejności ($p = 4/6$) wystarczy 6 prób, żeby mieć ok. 99,9% szansy na optimum. Samo „znalazł optimum” niczego więc nie dowodzi. W dwóch projektach kod zamieniał dowolny ciąg bitów na jakąś poprawną kolejność, a potem liczył jej czas. Przy takim dekoderze losowy ciąg bitów trafiał w optimum w 75–81% przypadków. W jednym z tych projektów częściej niż wynik samego algorytmu kwantowego.

Dlatego przy kolejnych projektach przestałem pytać, czy wynik jest dobry. Pytałem: kto naprawdę policzył ten plan, algorytm kwantowy czy zwykły komputer obok niego?

Gdzie naprawdę pracuje komputer kwantowy

To była najciekawsza część oceny. Powtarzało się kilka wzorców, w których wynik formalnie pochodził z „metody kwantowej”, ale decydującą pracę wykonał klasyczny kod. Nie każdy z nich jest błędem. Część to zwykłe, dobre elementy podejścia hybrydowego. Trzeba je tylko zobaczyć, zanim przypisze się zasługę komputerowi kwantowemu.

Odpowiedź zaszyta we wzorze. Wyobraź sobie planistę, który najpierw w Excelu policzy czas wszystkich możliwych kolejności, a potem poprosi nowy system, żeby wybrał najlepszą z tej tabeli. System „znalazł” optimum, ale pracę wykonał Excel. Najmniejsze kodowania zapisywały problem 2x2 na 1 kubicie, a 3x3 na 3–4 kubitach. Brzmi imponująco, dopóki nie zajrzy się, skąd biorą się współczynniki. W kilku projektach kod najpierw liczył czas wszystkich kolejności, a potem budował z tej tablicy funkcję energii. Samo klasyczne liczenie współczynników jest normalne. Problemem jest pełny przegląd: kto policzył czas każdej kolejności, ten już zna najlepszą. Dla 3 zleceń to 6 przeliczeń, dla 20 zleceń byłoby to ok. 2,4·10¹⁸, zanim komputer kwantowy w ogóle zacznie pracę. Część zespołów, w tym zwycięzcy, wprost opisała takie kodowanie jako porównanie, a nie właściwy model.

Najlepsza próbka z prawie wszystkich możliwych. Rzuć kostką sto razy, a szóstka prawie na pewno wypadnie. Nie znaczy to, że umiesz rzucać. QAOA nie zwraca jednego wyniku, tylko rozkład pomiarów: tysiące ciągów bitów, z których jedne pojawiają się częściej, inne rzadziej. Wybranie najlepszej z wielu próbek to standardowa część optymalizacji, bo sprawdzenie jednego planu jest tanie [6]. Kłopot zaczyna się wtedy, gdy próbek jest tyle, że pokrywają prawie całą przestrzeń możliwości. W skrajnym przypadku kod przeglądał wszystkie 16 możliwych stanów 4-kubitowego obwodu, czyli robił zwykłe klasyczne przeszukanie. Rzetelne porównanie to najlepszy wynik algorytmu kwantowego z $N$ próbek wobec najlepszego z $N$ losowych próbek, a w ocenie praktycznej także cały czas obliczeń [22].

Podpowiedź, która już jest odpowiedzią. Daj nowemu planiście gotowy, najlepszy plan i poproś, żeby go poprawił. Odda ten sam plan i formalnie będzie miał rację. Warm-start, czyli start algorytmu kwantowego od rozwiązania podpowiedzianego klasycznie, to pełnoprawna technika [23], ale liczy się to, ile algorytm poprawił. W dwóch projektach punkt startowy już był odpowiedzią. W jednym sam stan początkowy dawał ok. 91% optymalnych pomiarów, a po optymalizacji 99%: plan znalazł klasyczny etap przed algorytmem kwantowym.

Horyzont równy znanemu optimum. Powiedz planiście „zmieść wszystko w 8 godzinach”, gdy już wiesz, że 8 godzin to najlepszy możliwy wynik. Każdy plan, który się zmieści, będzie optymalny. Użyty tu czasowy model QUBO potrzebuje założonego horyzontu $H$ [15]. Szukanie najmniejszego wykonalnego $H$, zaczynając od dolnego ograniczenia, to poprawna metoda optymalizacji i tak robiły najlepsze zespoły. Inaczej jest, gdy $H$ ustawi się dokładnie na optimum policzonym wcześniej klasycznym solverem. Wtedy tabela „0% straty do optimum” wynika z konstrukcji, a nie z jakości solvera.

Klasyczne wstępne przetwarzanie. Dobry technolog najpierw wykreśla warianty, których nie da się wykonać, a dopiero potem oddaje zadanie planiście. To dobra praktyka, ale to jego zasługa, nie planisty. Najlepsze projekty mocno zmniejszały problem klasycznie, zanim trafił do algorytmu kwantowego. U jednego zespołu przycięcie okien startu i propagacja ograniczeń [24, 25] zmniejszyły liczbę przypisań, w których każda operacja startuje dokładnie raz, ze 134 mln do ok. 104 tys., czyli ok. 1300 razy. Algorytm kwantowy szukał potem 13 poprawnych planów wśród tych 104 tys. To samo zmniejszenie pomagało też metodom klasycznym: symulowane wyżarzanie trafiało optimum w 40% prób na pełnym modelu i w 97% na zmniejszonym. Rzetelny benchmark daje taki preprocessing także metodom klasycznym.

Co zostaje, gdy oddzielić te efekty?

Najlepiej widać to w formie lejka.

„Szansa na optymalny plan” to łączne prawdopodobieństwo wszystkich optymalnych planów w jednej próbce.

Ten jeden projekt na dziewięć to stegoqubit. Zespół zmniejszył QUBO dla 3x3 z 72 do 33 zmiennych bez utraty żadnego poprawnego planu i uruchomił na nim wariant QAOA z mieszaczem XY [26, 27]. Algorytm startuje od stanów, w których każda operacja startuje dokładnie raz, a mieszacz XY tej reguły nie łamie. Łączne prawdopodobieństwo 13 optymalnych planów wyniosło 17,2%, ok. 1400 razy więcej niż przy losowaniu jednego ze 104 tys. przypisań. Dziewięć najczęściej mierzonych stanów to optymalne harmonogramy. Osobno zespół zszedł nawet do 24 zmiennych dzięki kodowaniu „domain-wall” [28], ale tę wersję sprawdził tylko klasycznie. Wynik QAOA dotyczy modelu z 33 zmiennymi.

Warto jednak zapytać: czy tu w ogóle jest obwód kwantowy? Dla 3x3 zespół policzył działanie algorytmu kodem numerycznym, bez szumu, na wszystkich 104 tys. stanach. To poprawny sposób badania algorytmu, ale nie uruchomienie go na komputerze kwantowym. A ilorazy, ok. 1300 razy z przycinania i ok. 1400 razy z QAOA, to wzrost szansy trafienia optimum, a nie przyspieszenie obliczeń.

Na mniejszej instancji 2x2 wyraźny efekt QAOA pokazały też zespoły RafeyC i ls-QPoland (szansa na optimum 13–18 razy wyższa niż przy losowaniu, optymalny plan najczęstszym pomiarem) oraz AI-Native Quantum (ok. 8 razy, choć optymalny plan był dopiero trzecim najczęstszym wynikiem). To nie są duże liczby, ale to prawdziwy efekt algorytmu, a nie klasycznego kodu wokół niego.

Prawdziwy sprzęt: co pokazały procesory IBM

Tylko jeden zespół, Prometheus, uruchomił problem na prawdziwych komputerach kwantowych: trzech procesorach IBM Heron, ok. 147 tysięcy pomiarów obwodu na 4 kubitach. Zespół podał identyfikatory zadań i zrzuty z platformy IBM, a surowe wyniki są statystycznie spójne z obwodem dla zadania MetalTech. Samych zadań na platformie IBM nie mogłem sprawdzić, więc mam dowód spójności danych, ale nie ich pochodzenia.

Rozkład wyników ze sprzętu był bardzo podobny do idealnego. Miara podobieństwa, którą podaje zespół (kwadrat współczynnika Bhattacharyyi), wyniosła 0,90–0,97, gdzie 1 oznacza identyczne rozkłady. Zupełnie przypadkowe wyniki dałyby ok. 0,56. Sprzęt wiernie wykonał rysunek techniczny.

Kłopot w tym, że sam rysunek niewiele wnosił. Dekoder zespołu zamieniał każdy ciąg 4 bitów, także niepoprawny, na jakąś kolejność zleceń. Z takim dekoderem optymalny plan wychodził w ok. 60% pomiarów idealnego obwodu, w 55–66% na sprzęcie i w 81% z losowych ciągów bitów (13 z 16). Jeśli liczyć tylko ciągi, które same są poprawną i optymalną kolejnością, obwód wypadał lepiej od losowania: 57% w idealnej symulacji i 47–51% na sprzęcie wobec 25%. W całym potoku zespołu część kwantowa nie poprawiała jednak wyniku.

Wniosek jest dwojaki. Na kilku kubitach dzisiejszy sprzęt dał wyniki bliskie symulacji i był dostępny dla zespołu hackathonowego w jeden weekend. Sam dostęp przez chmurę nie jest nowością, bo IBM udostępnił publicznie pięciokubitowy procesor już w 2016 roku [29]. Od tego czasu rosła przede wszystkim liczba i jakość kubitów oraz dojrzałość narzędzi [18]. Jednocześnie 4 kubity to problem, który człowiek rozwiąże na kartce. Eksperymenty z QAOA na procesorach nadprzewodzących pokazują, że jakość wyników spada wraz z rozmiarem problemu, zwłaszcza gdy jego struktura nie pasuje do połączeń między kubitami [17].

VeloxQ: inspirowany fizyką, liczony klasycznie

Najbardziej praktyczne wyniki przyniosło narzędzie, które w ogóle nie jest komputerem kwantowym. VeloxQ to polski solver QUBO firmy Quantumz.io, oparty na heurystykach inspirowanych fizyką i działający na zwykłych procesorach i kartach graficznych [12, 13]. Przyjmuje ten sam format problemu co wyżarzacz kwantowy, ale obsługuje problemy o wiele większe niż dzisiejsze komputery kwantowe.

Co pokazały projekty:

• Na oficjalnej instancji 3x3 (24–72 zmiennych, zależnie od zapisu) VeloxQ według zapisanych wyników znajdował optymalny plan w każdym wywołaniu.
• Zespół AI-Native Quantum przeprowadził dwie kampanie na modelach do 128 zmiennych. VeloxQ trafił optimum potwierdzone przez CP-SAT w 3 z 4 przypadków w pierwszej i we wszystkich 4 w drugiej. Odsetek wykonalnych próbek spadał jednak z ok. 90% do ok. 20%, gdy problem rósł.
• Przy kilkuset i kilku tysiącach zmiennych zaczynały się kłopoty. W jednym projekcie VeloxQ uruchomiony na całym modelu był od 8 zleceń 22–59% gorszy od optimum, które CP-SAT potwierdził w niecałe 2 sekundy. W innym sam VeloxQ zwracał głównie puste plany.
• Z klasyką zaczynał konkurować dopiero razem z klasyczną pętlą, która dzieli problem na mniejsze kawałki i składa wyniki (przeszukiwanie dużego sąsiedztwa, LNS [30], albo dekompozycja). W projekcie zwycięzców, zespołu Axion, który zamiast fabryki modelował kuchnię cateringową, hybryda VeloxQ + LNS na modelach do ok. 2000 zmiennych była o jedną partię posiłków lepsza od klasycznego solvera CP-SAT [31] z limitem 30 sekund, ale gorsza od tego samego CP-SAT z limitem 4 minut. To porównanie z wynikami przy limicie czasu, a nie z potwierdzonym optimum.

Dla mnie to najbardziej pouczająca część hackathonu. Oba zespoły wyróżnione nagrodą VeloxQ, Axion i stegoqubit [1], pokazały nie tylko, gdzie solver pomaga, ale też, gdzie przegrywa.

Cena realizmu, czyli dlaczego prawdziwa fabryka nie mieści się w kubitach

Regulamin prosił zespoły o policzenie, ile zmiennych kosztuje każde nowe ograniczenie. Z perspektywy ERP to jedna z najbardziej wartościowych lekcji hackathonu, bo pokazuje, co dzieje się z modelem, gdy dopisujemy do niego prawdziwe życie fabryki.

W zapisie czasowym, którego używała większość zespołów, liczba zmiennych rośnie jak liczba operacji razy liczba możliwych godzin startu [15]. Dla 3 zleceń na 3 maszynach to 72 zmienne, po przycięciu niemożliwych godzin 39 [14]. Każde wydłużenie horyzontu, każda dodatkowa maszyna i każde zlecenie zwiększają tę liczbę. A ponieważ więcej zleceń wymaga też dłuższego horyzontu, rośnie ona szybciej niż sama liczba zleceń.

Przykłady z projektów:

• Model kuchni cateringowej zespołu Axion w zapisie czasowym potrzebowałby 1118 zmiennych. Sprytne przeformułowanie zeszło do 35.
• Rozszerzony model fabryki stegoqubit z przezbrojeniami, przeglądem maszyny i terminami zszedł ze 102 do 24 zmiennych dzięki klasycznej propagacji ograniczeń i kodowaniu „domain-wall”, bez utraty żadnego poprawnego planu.
• Kary za spóźnienie i koszt energii według taryfy, liczone z już istniejących zmiennych startu, nie kosztowały ani jednej dodatkowej zmiennej. Nie każde wymaganie biznesowe jest drogie. Twardy termin byłby czymś innym: ograniczeniem, które usuwa część możliwych godzin startu.
• Awarie maszyn zmniejszały liczbę zmiennych, bo usuwały niemożliwe godziny startu, ale wydłużały potrzebny horyzont. Netto zmiennych mogło przybyć.

Do tego dochodzą kary za łamanie reguł. Działają jak mandat: muszą być wyższe niż zysk z łamania przepisu, bo inaczej solver uzna, że regułę fabryki opłaca się złamać. Z kolei za wysoka kara zagłusza różnice między dobrymi i złymi planami [3, 32]. W jednym z projektów kara wynosiła ok. 11 milionów przy celu rzędu kilkudziesięciu, co wymagało osobnej pracy nad uwarunkowaniem problemu. Mandat nie może więc być ani za niski, ani tak wysoki, żeby wszystko inne zginęło w zaokrągleniu.

Klasyczny sędzia

Jest jeden fakt, który dobrze podsumowuje stan technologii. We wszystkich dziewięciu projektach optymalność wyniku potwierdzał klasyczny solver (CP-SAT z Google OR-Tools [31] albo MILP) lub pełne przejrzenie wszystkich możliwości. Takie porównanie to standard rzetelnego benchmarku, ale wymowne jest co innego. Ten sam CP-SAT rozwiązuje instancję 3x3 i rozszerzony model fabryki ze statusem OPTIMAL, czyli z dowodem optymalności [33], w ułamku sekundy. Losowe portfele z 12 zleceniami, przezbrojeniami i terminami zajmują mu ok. 1,2 sekundy (w obrębie przyjętego horyzontu). Solvery programowania z ograniczeniami radzą sobie też z szeregowaniem w skali przemysłowej [34], choć przy dużych instancjach w zadanym czasie nie zawsze dowodzą optymalności.

Najlepsze zespoły grały w otwarte karty: każdy wynik kwantowy porównywały z klasycznym i podawały różnicę. Według przeglądu stanu badań takie porównanie z najlepszymi metodami klasycznymi to jedno z kluczowych otwartych zadań całej optymalizacji kwantowej [35]. Zespół Neural Husars poszedł najdalej w drugą stronę: rozwiązał swoje QUBO dokładnym klasycznym solverem i formalnie udowodnił, że to ten sam problem. Takiej praktyki przydałoby się więcej w komunikatach o „kwantowej optymalizacji”.

AI napisało dużą część kodu. To zmienia, co trzeba sprawdzać

Regulamin pozwalał na AI, a prawie wszystkie projekty wyraźnie z niego korzystały. Copilot, Codex, Claude Code, Gemini i ChatGPT pojawiały się wprost w opisach, a w repozytoriach leżały instrukcje dla agentów. W kilku projektach dokumentacja mówi wprost, że kod w dużej części napisał lub wygenerował agent AI. Jeden kompletny i poprawny projekt według dziennika zespołu powstał w półtorej godziny. Inny to prawie 150 commitów w trzy dni i ok. 170 dokumentów.

To pokazuje dwie rzeczy. Po pierwsze, napisanie działającego kodu kwantowej optymalizacji przestało być barierą. Baseline, który kilka lat temu wymagałby tygodni nauki Qiskita, dziś powstaje w godzinę. Po drugie, rośnie ryzyko, że dokumentacja mówi co innego niż kod:

• W jednym projekcie kluczowe liczby w dzienniku prac (prawie 100% skuteczności) nie wynikały z kodu, który dawał ok. 30%.
• W innym deklarowana oszczędność kosztu energii 5,43% okazała się artefaktem: porównywane plany miały ten sam wynik, a kod wybierał jeden z nich przypadkowo. Przy powtórzeniu różnica wynosiła zero.
• W jeszcze innym tuż przed terminem przepisano dziennik prac i opis udziału AI, a w nowej wersji pojawiły się błędne liczby.

Sam przy ocenie też korzystałem z AI (Claude Code), czyli AI pomagało mi sprawdzać kod pisany z pomocą AI. Dlatego każdy kod uruchamiałem w odizolowanym środowisku, a kluczowe liczby przeliczałem niezależnie.

Wniosek dla każdego, kto ocenia projekty, oferty czy prezentacje z tej dziedziny: wygenerowanie przekonującego projektu kwantowego jest dziś tanie. Drogie i rzadkie jest jego sprawdzenie.

Najwyżej w kategoriach dokumentacji wypadły projekty, które mówiły wprost, co jest kwantowe, a co klasyczne, i których liczby odtwarzały się co do cyfry przy tych samych ziarnach losowości. Moja obserwacja z tej oceny: projekty, które otwarcie opisywały swoje ograniczenia, najłatwiej było też zweryfikować.

Czy to jest gotowe dla biznesu?

Na podstawie tych projektów odpowiedź dzieli się na trzy części.

Do codziennego planowania produkcji: nie. Żaden z ocenionych projektów nie wykazał praktycznej przewagi części kwantowej nad odpowiednimi metodami klasycznymi. Wyraźny efekt algorytmów kwantowych widać było tylko na problemach z kilkoma zleceniami, i to w symulacji. Podobne skale spotyka się w literaturze: przykładowo Kurowski i współautorzy badali QAOA dla szeregowania zadań na podstawowej instancji, w symulacji bez szumu [36]. W zapisie czasowym realny plan produkcji to tysiące zmiennych. Mniejsze kodowania i dekompozycja mogą to zmniejszyć, ale żaden projekt nie pokazał, że da się wtedy zyskać coś względem metod klasycznych.

Do pracy w modelu hybrydowym i do analiz: częściowo tak, ale nie dzięki kwantowości.

• Solvery inspirowane fizyką, jak VeloxQ, działają dziś na zwykłym sprzęcie. W połączeniu z klasyczną dekompozycją potrafiły konkurować z klasyką przy krótkim limicie czasu. To realne narzędzie do eksperymentów, choć jeszcze nie zastępstwo dla CP-SAT.
• Najciekawsze wnioski biznesowe z projektów były klasyczne, ale wynikały z dobrego modelu. Zespół Axion pokazał, że trzecia kuchenka nie zwiększa liczby wydanych posiłków, a dodatkowy pomocnik daje ich o 20 więcej. Zespół AI-Native Quantum pokazał, że najkrótszy plan nie zawsze jest najlepszy, gdy liczą się też spóźnienia i koszt energii: plan dłuższy o godzinę miał o ok. 6% lepszy wynik łączny. Zapisanie problemu jako QUBO zmusza do jawnego nazwania każdej reguły i ceny każdego ograniczenia. To dyscyplina, która przydaje się niezależnie od solvera.

Do budowania kompetencji: tak, i to już teraz. Sformułowanie realnego problemu ERP jako QUBO, zebranie danych i zbudowanie rzetelnego porównania z klasyką to praca, której nie da się zrobić w dniu, w którym sprzęt będzie gotowy. Projekty z hackathonu pokazują, że taki prototyp można dziś zbudować w kilka dni, a na symulatorze i w chmurze sprawdzić go za niewielkie pieniądze.

Pięć pytań dla pana Zenona

Gdyby pan Zenon dostał dziś ofertę „kwantowego planera produkcji”, podpowiedziałbym mu pięć pytań. Wszystkie wynikają wprost z oceny tych projektów i sprowadzają się do jednego: co dokładnie robi tu część kwantowa, czego nie zrobiłby klasyczny solver?

1. Jak wypada wynik w porównaniu z najlepszym z tylu samych losowych prób i z klasycznym solverem, który dostał tyle samo czasu [22]?
2. Skąd biorą się liczby w modelu? Czy żeby je policzyć, nie trzeba było najpierw przejrzeć wszystkich możliwych planów?
3. Jak często pojedynczy pomiar daje optymalny plan i ile pomiarów wykonano w stosunku do liczby wszystkich możliwości?
4. Co było wiadomo przed uruchomieniem: docelowy czas, najlepszy wynik, plan startowy?
5. Sprzęt czy symulator, ile kubitów i co się dzieje, gdy problem rośnie dwa razy?

Rzetelny dostawca odpowie na nie bez kłopotu. Jeśli odpowiedzi brakuje, to też jest odpowiedź.

Czego ten eksperyment nie pokazał

Rzetelność wymaga też listy ograniczeń samego hackathonu.

• Instancja 3x3 była jednocześnie za łatwa i za duża. Dobre zadanie konkursowe musi być dość trudne, żeby losowanie nie wystarczało, i dość małe, żeby dało się je policzyć kwantowo. To moja lekcja jako autora zadania.
• Prawie wszystko działo się na klasycznych symulatorach bez szumu. Tylko jeden zespół dotknął prawdziwego sprzętu, i to na 4 kubitach.
• Rozszerzenia opierały się na danych syntetycznych, wymyślonych przez zespoły, a nie na danych z prawdziwej fabryki.
• Projekty powstały w jeden weekend. To nie jest test dojrzałości technologii, tylko przegląd tego, co zdolny zespół z AI zrobi w kilka dni.
• Oceniałem sam, z pomocą AI. Wyników VeloxQ nie mogłem uruchomić ponownie, bo wymagają prywatnych tokenów. Część przeliczyłem z zapisanych próbek, resztę znam z podsumowań zespołów.

Czy magnesy opisały fabrykę?

Pan Zenon dostał dziewięć poprawnych planów, ale w prawie wszystkich decydującą pracę wykonał zwykły komputer.

Jednocześnie hackathon pokazał rzeczy, których kilka lat temu nie dałoby się zrobić w weekend. Jeden zespół uruchomił obwód na prawdziwych procesorach IBM. Inne zmniejszały problem z 72 do 24 zmiennych bez utraty poprawności, łączyły solvery inspirowane fizyką z klasycznymi pętlami na modelach z tysiącami zmiennych i rzetelnie mierzyły, gdzie to działa, a gdzie nie.

Przed hackathonem pisałem o magnesach Isinga i pytałem: sto lat temu jedno równanie opisywało magnesy, czy opisze też fabrykę? Opisuje. Wszystkie zespoły zapisały problem pana Zenona jako QUBO, czyli właśnie taki układ magnesików, a najlepszy plan był w nim stanem o najniższej energii. Tyle że na razie najszybciej i najpewniej znajduje ten stan zwykły komputer.

W tych dziewięciu projektach nie pokazano przewagi kwantowej. Pokazano natomiast, jak łatwo pomylić poprawny wynik, dobre modelowanie hybrydowe i przewagę nad metodami klasycznymi. Dlatego z tego hackathonu wynoszę jedną zasadę: nie pytaj, czy plan jest dobry. Pytaj, kto go naprawdę policzył.

Komputery kwantowe nie są jeszcze gotowe planować produkcji. Są za to gotowe na to, żeby firmy uczyły się zadawać im dobre pytania. Moja hipoteza po tym hackathonie: zanim przewaga kwantowa pojawi się w planowaniu produkcji, najpierw pojawi się wartość z narzędzi hybrydowych i z samego sposobu modelowania.

Słowniczek

Krótkie wyjaśnienie pojęć, które pojawiają się w artykule.

• Kubit – podstawowa jednostka informacji w komputerze kwantowym. Bit ma wartość 0 albo 1, a kubit może być w superpozycji opisanej dwiema liczbami (amplitudami); pomiar daje 0 albo 1 z prawdopodobieństwem wynikającym z tych liczb.
• QUBO (Quadratic Unconstrained Binary Optimization) – sposób zapisania problemu jako wzoru, w którym każda decyzja to zmienna 0 lub 1 (np. „czy zlecenie Z1 startuje na tokarce o godzinie 2?”), a łamanie reguł fabryki podbija wynik karą. Najlepszy plan to układ zer i jedynek o najmniejszej wartości wzoru. To model matematyczny, a nie metoda kwantowa, więc jego minimum można szukać i klasycznie, i na komputerze kwantowym [2, 3].
• Hamiltonian Isinga – wzór na energię w klasycznym modelu Isinga, czyli w układzie „magnesików” skierowanych w górę albo w dół, znanym z fizyki od stu lat. Prosta zamiana zmiennych przekształca QUBO w taki wzór, więc najlepszy plan to stan o najniższej energii [2].
• Wyżarzacz kwantowy – specjalny komputer kwantowy (np. D-Wave), który przyjmuje problem w postaci QUBO lub modelu Isinga. Powoli przestraja układ kubitów i zwraca rozwiązania o niskiej energii, ale bez gwarancji, że trafi w najlepsze [4, 5].
• Obwód kwantowy i bramka – program dla komputera kwantowego to ciąg operacji (bramek) na kubitach. Bramki działające na dwóch kubitach naraz są na większości dzisiejszych platform bardziej podatne na błędy niż jednokubitowe.
• QAOA (Quantum Approximate Optimization Algorithm) – algorytm, który zamienia QUBO na obwód z naprzemiennych warstw: jedna zmienia fazy rozwiązań zależnie od ich jakości, druga dzięki interferencji przesuwa prawdopodobieństwo w stronę lepszych. Ustawienia warstw dostraja zwykły komputer [6].
• Klasyczny symulator obwodów kwantowych – program na zwykłym komputerze, który oblicza, co zrobiłby komputer kwantowy. W najprostszej metodzie każdy kubit podwaja potrzebną pamięć i rekordowe symulacje na superkomputerach sięgały 45–48 kubitów; inne metody radzą sobie z większymi obwodami o prostej strukturze [7, 8, 9].
• Szum – błędy, które zakłócają dzisiejsze komputery kwantowe. Im dłuższy obwód, tym bardziej wynik odbiega od zamierzonego: często w stronę przypadkowego, czasem systematycznie w jedną stronę [10, 11].
• VeloxQ – program polskiej firmy Quantumz.io, który szuka najlepszych rozwiązań QUBO. Korzysta z metod inspirowanych fizyką, ale działa na zwykłych procesorach i kartach graficznych [12, 13].

Źródła

1. QPoland Global Quantum Hackathon 2026 – strona konkursu, w tym wyniki (nagroda główna: Axion; nagroda VeloxQ: Axion i stegoqubit). qaif.org
2. Lucas, A. (2014). Ising formulations of many NP problems. Frontiers in Physics, 2, 5. doi:10.3389/fphy.2014.00005
3. Glover, F., Kochenberger, G., Du, Y. (2019). Quantum Bridge Analytics I: a tutorial on formulating and using QUBO models. 4OR, 17, 335–371. arXiv:1811.11538
4. Kadowaki, T., Nishimori, H. (1998). Quantum annealing in the transverse Ising model. Physical Review E, 58, 5355–5363. doi:10.1103/PhysRevE.58.5355
5. D-Wave Quantum Inc. What is Quantum Annealing? Dokumentacja techniczna (dostęp 31.10.2026). docs.dwavequantum.com
6. Farhi, E., Goldstone, J., Gutmann, S. (2014). A Quantum Approximate Optimization Algorithm. arXiv:1411.4028
7. Häner, T., Steiger, D. S. (2017). 0.5 Petabyte Simulation of a 45-Qubit Quantum Circuit. SC17: International Conference for High Performance Computing, Networking, Storage and Analysis. arXiv:1704.01127
8. De Raedt, H. i in. (2019). Massively parallel quantum computer simulator, eleven years later. Computer Physics Communications, 237, 47–61. arXiv:1805.04708
9. Qiskit Aer. AerSimulator – dokumentacja metod symulacji (statevector, density_matrix, matrix_product_state, tensor_network i in.; dostęp 31.10.2026). qiskit.github.io/qiskit-aer
10. Preskill, J. (2018). Quantum Computing in the NISQ era and beyond. Quantum, 2, 79. doi:10.22331/q-2018-08-06-79
11. Stilck França, D., García-Patrón, R. (2021). Limitations of optimization algorithms on noisy quantum devices. Nature Physics, 17, 1221–1227. arXiv:2009.05532
12. Pawłowski, J., Tuziemski, J., Tarasiuk, P., Louzada, H., Adamski, R., Hendzel, K., Pawela, Ł., Gardas, B. (2025, wersja 2 z 4.05.2026). VeloxQ: A Fast and Efficient QUBO Solver. arXiv:2501.19221v2. Praca autorów solvera; porównania w niej to wyniki autorów, a nie niezależne potwierdzenie.
13. The Quantum Insider (4.09.2025). Quantumz.io Unveils VeloxQ Algorithm That Outperforms Quantum Annealers on Standard Computers (materiał prasowy). thequantuminsider.com
14. QPoland Quantum Hackathon 2026. Production Scheduling Optimization (ERP) – opis zadania dla uczestników (dane instancji A i B, referencyjne liczby 72 i 39 zmiennych, kryteria oceny).
15. Venturelli, D., Marchand, D. J. J., Rojo, G. (2015). Quantum Annealing Implementation of Job-Shop Scheduling. arXiv:1506.08479
16. Choi, V. (2008). Minor-embedding in adiabatic quantum computation: I. The parameter setting problem. Quantum Information Processing, 7, 193–209. arXiv:0804.4884
17. Harrigan, M. P. i in. (2021). Quantum approximate optimization of non-planar graph problems on a planar superconducting processor. Nature Physics, 17, 332–336. arXiv:2004.04197
18. Kim, Y. i in. (2023). Evidence for the utility of quantum computing before fault tolerance. Nature, 618, 500–505. doi:10.1038/s41586-023-06096-3
19. Pinedo, M. L. (2016). Scheduling: Theory, Algorithms, and Systems (wyd. 5). Springer.
20. Johnson, S. M. (1954). Optimal two- and three-stage production schedules with setup times included. Naval Research Logistics Quarterly, 1(1), 61–68. doi:10.1002/nav.3800010110
21. Garey, M. R., Johnson, D. S., Sethi, R. (1976). The complexity of flowshop and jobshop scheduling. Mathematics of Operations Research, 1(2), 117–129. doi:10.1287/moor.1.2.117
22. Rønnow, T. F. i in. (2014). Defining and detecting quantum speedup. Science, 345(6195), 420–424. arXiv:1401.2910
23. Egger, D. J., Mareček, J., Woerner, S. (2021). Warm-starting quantum optimization. Quantum, 5, 479. arXiv:2009.10095
24. Mackworth, A. K. (1977). Consistency in networks of relations. Artificial Intelligence, 8(1), 99–118. doi:10.1016/0004-3702(77)90007-8
25. Debruyne, R., Bessière, C. (1997). Some Practicable Filtering Techniques for the Constraint Satisfaction Problem. IJCAI-97, 412–416. ijcai.org
26. Hadfield, S., Wang, Z., O’Gorman, B., Rieffel, E. G., Venturelli, D., Biswas, R. (2019). From the Quantum Approximate Optimization Algorithm to a Quantum Alternating Operator Ansatz. Algorithms, 12(2), 34. arXiv:1709.03489
27. Wang, Z., Rubin, N. C., Dominy, J. M., Rieffel, E. G. (2020). XY-mixers: analytical and numerical results for QAOA. Physical Review A, 101, 012320. arXiv:1904.09314
28. Chancellor, N. (2019). Domain wall encoding of discrete variables for quantum annealing and QAOA. Quantum Science and Technology, 4, 045004. arXiv:1903.05068
29. IBM Quantum Blog (2021). Wpis z okazji pięciu lat IBM Quantum Experience, uruchomionego 4 maja 2016 r. z pięciokubitowym procesorem. ibm.com/quantum/blog
30. Shaw, P. (1998). Using Constraint Programming and Local Search Methods to Solve Vehicle Routing Problems. Principles and Practice of Constraint Programming – CP98, LNCS 1520, 417–431. Springer.
31. Perron, L., Didier, F., Gay, S. (2023). The CP-SAT-LP Solver. CP 2023, LIPIcs 280. doi:10.4230/LIPIcs.CP.2023.3
32. Ayodele, M. (2022). Penalty Weights in QUBO Formulations: Permutation Problems. EvoCOP 2022, LNCS. doi:10.1007/978-3-031-04148-8_11
33. Google OR-Tools. CP-SAT Solver – dokumentacja (statusy OPTIMAL, FEASIBLE, INFEASIBLE, MODEL_INVALID, UNKNOWN; dostęp 31.10.2026). developers.google.com/optimization
34. Da Col, G., Teppan, E. C. (2022). Industrial-size job shop scheduling with constraint programming. Operations Research Perspectives, 9, 100249. doi:10.1016/j.orp.2022.100249
35. Abbas, A. i in. (2024). Challenges and opportunities in quantum optimization. Nature Reviews Physics, 6, 718–735. doi:10.1038/s42254-024-00770-9
36. Kurowski, K., Pecyna, T., Slysz, M., Różycki, R., Waligóra, G., Węglarz, J. (2023). Application of quantum approximate optimization algorithm to job shop scheduling problem. European Journal of Operational Research, 310(2), 518–528. doi:10.1016/j.ejor.2023.03.013

Inne źródła

• VeloxQ w krajowej infrastrukturze PLGrid: Cyfronet