Доброго времени суток, уважаемые хаброжители! Сегодня поговорим о данных — о той самой основе, без которой в классическом машинном обучении да и в deeplearning, по большому счёту, не происходит вообще ничего, от слова совсем: ни обучения моделей, ни проверки гипотез, ни сколько-нибудь осмысленных выводов, ни построение пайплайнов. И в квантовом машинном обучении история, в сущности, та же самая. Только вот сами данные здесь устроены несколько иначе — и вот здесь как раз начинается самое интересное ;) Когда впервые слышишь словосочетание квантовые данные, реакция, как правило, одна из двух: либо это звучит как что-то из научной фантастики, где сейчас из-за угла выйдет кот Шрёдингера и испортит вам датасет, либо как «ну хорошо, ещё один датасет, просто теперь с модной квантовой приставкой» и всякими наворотами. Сразу скажу: на практике всё интереснее и более вариативно. Именно, последнее и приобретает особо важную роль в современном мире ИИ.

В этой статье мы разберём следующие важные положения:

• какие вообще бывают квантовые данные, откуда они берутся, а главное, сколько их надо;

• когда достаточно статистического анализа, а когда уже нужна конвертация в формат, удобный для ML и какие метрики есть для оценки этих самих данных;

• почему симулятор в QML — это не учебная условность, а вполне рабочий инструмент, и где именно, возникает разрыв между симуляцией и реальным устройством;

• как выглядит минимальный практический пайплайн в духе «получили результаты → сделали признаки → обучили модель → проверили результат»;

• какие бенчмарки и протоколы сравнения уже используются в практических и коммерческих исследованиях и на что следует олриентироваться в дальнейшем;

• где квантовый слой сегодня действительно уместен, а где он чаще добавляет сложности, чем пользы, как настроить более продуктивную работу с ним и что на него влияет;

Основной фокус будет у нас конечно же на практике, только хардкор )) короткие примеры, понятные шаги и минимум лишней теории. Итак, если вам интересно, как работать с квантово-классическими гибридными моделями уже сегодня, — поехали, всех приглашаем под кат :)

1. Особенности квантовых данных

Один из первых вопросов, который сразу встаёт, звучит довольно просто и при этом очень по-инженерному: Где вообще брать данные, сколько их надо, какими они должны быть, что по метрикам, что по качеству, где их хранить ?

В классическом ML всё более или менее привычно: есть, например, ImageNet, есть табличные выгрузки, пользовательские логи, Kaggle и т.д., то есть датасеты уже существуют и живут своей самостоятельной жизнью. Дальше всё идёт по знакомому сценарию: выбрали данные, подготовили, чекнули фичи, обучили модели, проверили, оценили, ещё обучили (много-много-много раз), подняли скор, оптимизировали, ещё все прогнали, обложили тестами, проверили (ещё много-много-много раз) запаковали в контейнер, навесили метрики для мониторинга и побежали дальше.

В квантовом мире логика уже другая: здесь данные часто не лежат где-то заранее, а появляются только после выполнения эксперимента на квантовом устройстве и вот это, по большому счёту, одно из первых важных отличий. Но об этом чуть позже, а пока сначала разберёмся, какими вообще бывают квантовые данные и в каком виде они обычно встречаются, и как их дифференцировать под наши задачи.

Если сильно упростить, можно выделить три основных типа:

• Реальные измерения с квантовых процессоров: Это битовые строки, их частоты и распределения вероятностей — по сути статистика физического эксперимента, а не привычная таблица признаков в знакомом нам представлении;

• Симуляторы: Реальные QPU пока шумные, медленные и дорогие, поэтому большинство экспериментов начинается с симуляции;

• Гибридные датасеты: Классические признаки кодируют в параметры квантовой схемы (например, переводят значения в углы вращений кубитов), при этом «квантовый датасет» — это уже результат квантового embedding’а и с ним уже можно работать.

В связи с этим сразу встаёт вопрос: Есть ли готовые наборы? Да, есть. Но их, сразу скажу, заметно меньше, чем в классическом ML, при этом обычно это: 1. данные квантовой томографии; 2. результаты вариационных алгоритмов (VQE, QAOA); 3. Экспериментальные измерения; 4. Синтетика из симуляторов. И почти всегда такой датасет жёстко привязан к конкретной схеме, числу кубитов и задаче, что не всегда есть хорошо, но в целом можно и здесь выкрутиться и жить. Поэтому сценарий «скачал и обучил модель» здесь встречается редко.

По каким задачам работают с квантовыми данными ?

Чаще всего речь идёт о четырёх направлениях: квантовая химия — энергии молекул, VQE; комбинаторная оптимизация — графы, QAOA; квантовая физика материалов — спиновые системы, фазовые переходы; квантовое машинное обучение — feature map’ы и вариационные модели, трейдин и формирование инвестиционных портфелей. Если проследить уже здесь все, то сразу становится ясно, что «кванты» работают там, где нужна особая «чистота» данных и борьба с шумовой составляющей здесь главная тема.

Почему датасеты такие маленькие ?

Есть особенность, которая обычно бросается в глаза довольно быстро: квантовые датасеты почти всегда небольшие и причины здесь вполне приземлённые: Во-первых, запуски весьма дорогие и, как правило, на квантовый компьютер очереди расписана на месяцы вперёд; во-вторых, сами устройства медленные и требуют времени на формирование; В-третьих: шум ограничивает число полезных измерений и с ним приходится постоянно бороться. В итоге вместо миллионов наблюдений мы чаще имеем сотни или тысячи, иногда — десятки тысяч. По меркам deep learning это, прямо скажем, немного, и именно поэтому в QML так часто появляются вариационные и гибридные подходы, а вот они-то уже очень востребованы и реально работают.

Кто даёт доступ к таким данным ?

В основном доступ к таким данным дают те же организации, которые развивают квантовое железо и облачные платформы: IBM Quantum, IonQ, Rigetti, Quantinuum, РКЦ, МГТУ им. Баумана и ФИАН им. Лебедева, а так же некоторые академические лаборатории. С инженерной точки зрения работа с ними выглядит довольно привычно: Python-SDK, запуск схемы, получение измерений — только вместо GPU внутри оказываются кубиты.

2. Как данные получают и подключают на практике

Как мы уже обговорили, в классическом ML всё устроено довольно просто: есть файл, база данных или API — мы подключаемся к источнику данных и начинаем работать. В квантовых вычислениях логика уже сложнее. Да, квантовые данные тоже могут существовать в виде готовых наборов — например, как результаты симуляций или прошлых экспериментов. Но их принципиальная особенность в том, что изначально такие данные возникают как результат конкретного эксперимента или симуляции квантовой схемы, а их объём заранее ограничен условиями этого эксперимента.

И вот здесь, по большому счёту, меняется само понимание работы с данными: вместо подключения к уже готовому датасету мы фактически взаимодействуем с устройством, которое эти данные создаёт. Поэтому и возникает вполне естественный вопрос: что вообще значит «подключиться к данным» в квантовом ML? В классических задачах подключение — это доступ к файлу или базе. Здесь всё иначе: 1. Мы описываем квантовую схему; 2. Отправляем её на симулятор или реальный QPU; 3. Получаем результаты измерений. То есть фактически подключаемся не к датасету, а к устройству, которое этот датасет создаёт. Пока схема выполняется, кубиты находятся в суперпозиции — это ещё не конкретные 0 и 1, а вероятности получить каждый из возможных результатов. В конце алгоритма мы делаем измерение и получаем уже обычные классические биты. Один запуск схемы даёт одну битовую строку — такой запуск называют shot. Если повторить эксперимент много раз, мы получим: набор наблюдаемых строк; сколько раз выпала каждая из них — counts; оценку распределения результатов измерения. Именно это и называют сырыми квантовыми данными.

Как выглядит результат на практике ?

Чаще всего он выглядит примерно так, это наш counts: {«00»: 512, «11»: 536}. То есть данные — это распределение по битовым строкам, а не привычная таблица признаков. Чтобы увидеть это не на словах, а на практике, давайте запустим самый простой квантовый эксперимент и посмотрим, какие данные приходят на выходе на примере QiSkit.

Если запустить этот код, на выходе мы увидим словарь вида {’00’: ~50%, ’11’: ~50%}. Это означает, что схема создаёт особое состояние двух кубитов, в котором они ведут себя как связанная пара. Проще всего представить это как две случайные монеты, которые лежат в разных комнатах. Каждая по отдельности выглядит случайной, но если посмотреть на обе сразу, они всегда показывают одинаковый результат — либо 00, либо 11. Смешанных вариантов вроде 01 или 10 здесь не бывает. В квантовой физике такое поведение называют запутанностью, а конкретно это состояние — Bell-состоянием. Но для дальнейшего нам важнее не термин, а практический вывод: квантовый эксперимент возвращает не таблицу признаков, а распределение наблюдаемых состояний и именно это распределение (counts) и становится исходной точкой для дальнейшей обработки и превращения квантовых результатов в привычные данные для машинного обучения.

И здесь возникает вполне естественный практический вопрос: это уже датасет или ещё нет? Иногда — да. Но чаще counts нужно привести к форме, удобной для вашей задачи: анализа, сравнения запусков или обучения модели. Сразу скажу: конвертация нужна не всегда и иногда можно работать прямо с распределением (или с нормированными вероятностями p(bitstring)), без перехода к «классическому» ML. Это типично, если вы: 1. Сравниваете распределения между запусками/настройками схемы; 2. Считаете расстояния/дивергенции (например, насколько два распределения различаются); 3. Проверяете вероятностные гипотезы или ищете статистические эффекты. При этом конвертация почти неизбежна, если вы: 1. Хотите подать данные в sklearn/PyTorch или любую модель с фиксированным входом; 2. Сравниваете много запусков, и вам нужен единый формат; 3. Строите признаки фиксированной длины (чтобы модель понимала «одно и то же» пространство признаков). То есть, по большому счёту, делаете самую обычную ML-работу: train/test, метрики, подбор параметров и всё, что к этому прилагается. Есть несколько вполне типовых способов привести counts к более «человеческому» виду. И, как это обычно бывает, каждый вариант хорош в своей ситуации.

1. Таблица частот / вероятностей (bitstring, count, p): Самый понятный формат для EDA и сравнения запусков. Здесь сразу видно, какие состояния вообще встречаются и с какой частотой. Очень часто это и есть первый шаг, прежде чем вы вообще решите, что делать дальше.

2. Полный вектор по всем битстрокам длины n (размер 2ⁿ): Этот формат удобен тем, что даёт одинаковую размерность для любых запусков: одна и та же позиция всегда соответствует одной и той же битстроке. Звучит приятно, но минус тоже приходит довольно быстро — размерность растёт экспоненциально, и вектор почти сразу становится очень разреженным.

Per-shot выборка (список «сырых» измерений)
На вид это уже почти классический датасет из наблюдений, но здесь легко попасть в ловушку: shots у вас может быть много, а новой информации — не так уж много, при этом по сути, это всё те же оценки вероятностей, только в другом формате.

Где возникает путаница с объёмами ?

Сырые данные — это фактически число запусков shots (обычно тысячи), но после фичеризации размерность может резко вырасти — особенно если вы разворачиваете распределение в полный вектор 2ⁿ и получается довольно характерный для QML парадокс: наблюдений немного, а признаков внезапно очень много. Поэтому в QML на практике часто используют: 1. Разреженные представления; 2. Агрегаты и компактные эмбеддинги; 3. Задачно-ориентированные признаки вместо полного перебора состояний.

3. Симуляторы в QML: как генерируют данные и где начинается sim-to-hardware gap

Хочется отдельно поговорить о том, как вообще генерируют квантовые данные и какую роль во всей этой истории играют симуляции. В прошлом разделе мы получили counts и перевели их в ML-формат. Важно, что для этого использовался симулятор — и это не учебная условность, а полноценный рабочий инструмент в QML. На практике разработка почти всегда начинается именно с него: симуляция позволяет быстро запускать схемы, получать результаты измерений и проверять гипотезы без доступа к реальному устройству, и что особенно важно, через симуляторы не только отлаживают алгоритмы, но и буквально создают датасеты, с которыми потом работают ML-модели. Отсюда и возникает естественный вопрос: насколько таким данным можно доверять и что меняется при переходе к реальному квантовому железу?

Без симуляторов квантовое ML развивалось бы заметно медленнее. Итерации стали бы дорогими, долгими и довольно болезненными, а цена любой ошибки росла бы слишком быстро. Симуляторы позволяют бодро прогонять схемы, собирать counts и проверять гипотезы без очередей на железо — и уже только поэтому они давно стали нормальной частью рабочего процесса, при этом Обычно рассматривают два режима: идеальный — чистая математика без шума; noisy — модель, которая хотя бы частично приближает поведение реального устройства. В инженерной практике второй почти всегда полезнее.

Можно ли генерировать синтетику ?

Да, и для квантового ML это абсолютно стандартная практика, при этом обычно процесс выглядит так: 1. Задают семейство схем или параметров; 2. Прогоняют их на симуляторе; 3. Cобирают counts; 4. Превращают результаты в признаки для ML. Иными словами, датасет буквально производится программно, что особенно удобно в мире, где реальные запуски на QPU дорогие, ограниченные и не слишком располагают к бесконечным экспериментам. Идеальная симуляция почти всегда слишком оптимистична: 1. На реальном устройстве есть шум; 2. Cуществуют аппаратные ограничения; 3. Результаты могут заметно отличаться. Именно здесь появляется тот самый sim-to-hardware gap: в симуляции всё выглядит аккуратно, воспроизводимо и местами даже слишком красиво, а на железе часть эффекта может резко ослабнуть — или вообще развалиться. Поэтому практический маршрут почти всегда один: идеальная симуляция → noisy-симуляция → проверка на QPU. Без последнего шага очень легко поверить в результат, который в реальности просто не переживает встречу с устройством.

4. Из counts в признаки: два маршрута + реальный пример

В прошлых разделах мы уже зафиксировали базовую картину: на выходе квантового эксперимента у нас чаще всего оказываются измерения, и почти всё здесь начинается с counts. А дальше начинается уже вполне инженерная часть истории: как эти counts превратить в удобный ML-вход и как вообще выглядит минимальный runnable-пайплайн, который можно не только прочитать, но и реально прогнать руками. На практике после измерений у вас обычно два пути. Либо вы остаетесь в мире counts и p(bitstring) — как мы обсуждали ранее — либо уже переводите это в ML-вход. И вот тут, по большому счёту, тоже есть два основных маршрута: либо строим явные признаки, то есть какой-то вектор, который потом честно подаём в модель, либо не строим явный вектор вообще и учимся через kernel-подход. Ниже — поговорим про то, откуда вообще берутся квантовые сэмплы, а затем два рабочих маршрута: A) явные признаки и B) kernel-подход.

Генерация квантовой синтетики: три типичных сценария

Если говорить чуть более по-взрослому, генератор здесь — это схема, которая задаёт распределение, а измерения уже дают выборку из него. Дальше всё, в сущности, снова сводится к тем же знакомым форматам: counts, p(bitstring), embeddings. Все четыре ссылки ниже — runnable: их можно открыть и прогнать end-to-end (схема → измерения → counts/p(bitstring)), а дальше этот выход уже превращать в ML-вход — как в ветках A/B ниже.

1. QCBM / Born Machine: Параметризованная схема задаёт распределение по битстрокам, а параметры подбираются так, чтобы это распределение стало похоже на целевое. На выходе получаем либо counts, либо p(bitstring). То есть, грубо говоря, модель учится не предсказывать класс, а воспроизводить нужную структуру распределения. Демо: PennyLane QCBM (видно, как распределение меняется в процессе обучения):
   https://pennylane.ai/qml/demos/tutorial_qcbm

2. qGAN (квантовый GAN): Здесь идея уже ближе к привычной GAN-логике, только генератор — или хотя бы его часть — квантовая. Лосс, оптимизация, итерации — всё выглядит достаточно знакомо, а на выходе снова оказываются либо распределения, либо сэмплы, в зависимости от постановки. Туториал: Qiskit ML «PyTorch qGAN»:
   https://qiskit-community.github.io/qiskit-machine-learning/tutorials/04_torch_qgan.html

3. Вариационная схема как генератор (без обучения): Инженерно это, пожалуй, один из самых прямых и удобных сценариев: берём параметризованную схему как «фабрику данных», задаём параметры, запускаем, получаем counts или p(bitstring) и двигаемся дальше по пайплайну. Вполне рабочий вариант. Ссылки:
   https://github.com/qiskit-community/qiskit-machine-learning
   https://qiskit-community.github.io/qiskit-machine-learning/tutorials/index.html

После измерений у нас есть counts. Дальше обычно два пути:

• Ветка A (схема → shots → counts → (явные признаки) → модель): строим явные признаки (вектор, который реально подадим в модель)

• Ветка B (x → feature map → kernel matrix K → kernel-модель): явный вектор не строим — учимся по матрице сходства (kernel matrix)

Ветка A: явные признаки из counts

Формат 1: counts → probability vector (pvec)

Самый прямой маршрут — собрать вектор длины 2^n, где n — число измеряемых кубитов. Каждый элемент — вероятность соответствующей битстроки. Ключевая инженерная деталь здесь простая, но важная: порядок битстрок нужно задавать заранее и фиксировать явно, иначе потом можно очень весело запутаться в том, что именно лежит в какой координате.

Плюсы: дальше это просто численный вектор, и ML-часть выглядит «как обычно».
Минусы: размерность растёт как 2^n, вектор быстро становится разреженным, а оценки вероятностей «шумят» из-за конечных shots.

Формат 2: counts → feature embedding

Когда полный вектор 2^n становится уже слишком тяжёлым, данные обычно начинают сжимать в embedding. Способов много, но один из самых понятных — ожидания по каждому кубиту: ⟨Zᵢ⟩.

Как считать ⟨Zᵢ⟩ из p(bitstring):

• для i-го бита: 0 → +1, 1 → −1

• берём среднее по всем битстрокам с их вероятностями

Плюсы: компактно, устойчивее при росте n. Минусы: это «сжатие» теряет часть информации — но часто это нормальная цена за стабильность и размерность.

Ветка B: явные признаки не строим — учимся по квантовому сходству

Это другая логика: вместо counts → вектор мы считаем похожесть объектов напрямую через квантовые состояния.

• Feature map: кодируем классический вектор x в квантовую схему (data encoding)
  https://quantum.cloud.ibm.com/learning/courses/quantum-machine-learning/data-encoding

• Quantum kernel: функция сходства K(x, y) — по сути overlap/fidelity двух состояний после feature map
  https://qiskit-community.github.io/qiskit-machine-learning/stubs/qiskit_machine_learning.kernels.FidelityQuantumKernel.html

То есть, если совсем упростить, здесь мысль такая: мы не пытаемся руками вытащить из измерений явные признаки, а отдаём модели уже готовую геометрию сходства между объектами. Это не всегда дешевле и не всегда проще, но в некоторых задачах такая логика оказывается весьма естественной. Ниже соберём этот подход в рабочий пайплайн.

5. Минимальный runnable ML-пайплайн: quantum kernel + SVM

Чтобы показать полный цикл прозрачно и быстро, возьмём маленький знакомый датасет Iris и пройдём путь: X → feature map → kernel matrix K → QSVC → метрика. Qiskit показывает ровно этот сценарий в туториале по quantum kernels:
https://qiskit-community.github.io/qiskit-machine-learning/tutorials/03_quantum_kernel.html

В kernel-подходе важны два объекта: Ktr — матрица сходств train×train, форма (n_train, n_train); Kte — матрица сходств test×train, форма (n_test, n_train). Если test_size=0.3 на Iris, будет примерно: Xtr.shape ≈ (105, 2), Xte.shape ≈ (45, 2), Ktr.shape ≈ (105, 105), Kte.shape ≈ (45, 105). А если распечатать кусок Ktr[:5, :5], вы увидите числа в диапазоне [0, 1] и диагональ, близкую к 1 (объект максимально похож сам на себя). Именно эта матрица сходства и является «данными» для QSVC.

Если запускать это всерьёз (на реальных данных и больших датасетах), быстро всплывают вещи, которых нет в красивых примерах: 1. На реальном устройстве шум смещает распределения (особенно редкие события); 2. Измерения ограничены и стоят времени → датасеты часто небольшие; 3. Kernel-подход дорожает по числу объектов, потому что сходства считаются попарно; 4. Cимулятор и железо ведут себя по-разному → устойчивость лучше проверять отдельно.

На этом этапе у нас есть практическая картина: какие форматы данных реально живут в пайплайне, как их получают, во что конвертируют и как выглядит runnable-обучение. Дальше предлагаю посмотреть, как это устроено в исследованиях: какие датасеты берут, как кодируют признаки, какими протоколами сравнивают подходы и что реально воспроизводится, когда условия становятся сильно жёстче по сравнению с идеальным примером.

6. Квантовые данные в современных исследованиях

В предыдущем разделе мы уже разобрали всю базовую инженерную механику: измерения → counts → (явные признаки или kernel-матрица) → обучение. В исследованиях это ровно так же устроено, просто поверх добавляются две вещи: стандартизированные бенчмарки и протоколы сравнения, в которых уже неизбежно нужно будет учитывать шум, стоимость измерений, ограничения железа. Ниже — несколько опорных наборов, которые регулярно всплывают в QML-работах. Они удобны тем, что достаточно просты, воспроизводимы и позволяют сравнивать разные способы кодирования, feature map’ы и сами квантовые пайплайны без лишней экзотики.

Iris

• Размер: 150×4.

• Кодирование: обычно берут 2–4 признака, нормируют и прогоняют через feature map (типа ZZFeatureMap), затем считают kernel-матрицу.

• Какие квантовые данные: kernel matrix K_train и K_test (попарные сходства), дальше QSVC/SVM учится по K.

• Ограничения: датасет учебный — хорошо показывает механику, но редко говорит что-то про масштабирование.

• Что обычно сравнивают: квантовый kernel vs классические ядра (RBF/poly) и простые модели на тех же признаках; цель — понять, даёт ли кодирование более «удачную» геометрию.

• Ссылка: https://scikit-learn.org/stable/modules/generated/sklearn.datasets.load_iris.html

Wine

• Размер: 178×13.

• Кодирование: почти всегда нужно предварительное сжатие/отбор признаков, иначе «13 признаков → 13 кубитов» для NISQ выглядит тяжело.

• Какие квантовые данные: либо kernel-матрица (kernel-ветка), либо измеряемые ожидания/эмбеддинги (VQC/QNN).

• Ограничения: результат начинает сильно зависеть от того, как именно упаковали признаки (кодирование может «решить всё» ещё до квантовой части).

• Что обычно сравнивают: те же kernel-бейзлайны, но отдельно смотрят влияние предобработки (отбор признаков/PCA), потому что именно она часто решает итог.

• Ссылка: https://scikit-learn.org/stable/modules/generated/sklearn.datasets.load_wine.html 

MNIST

• Размер: 60k train / 10k test, картинки 28×28.

• Кодирование: почти всегда делают «MNIST-лайт»: уменьшают размер, берут PCA/автоэнкодер/несколько признаков, затем angle/amplitude encoding на малом числе кубитов.

• Какие квантовые данные: либо эмбеддинги (ожидания измерений), либо kernel-матрица.

• Ограничения: это часто не честный «полный MNIST», а демонстрация того, как ведёт себя кодирование + квантовый блок в маленьком режиме.

• Что обычно сравнивают: квантовый слой (embedding/kernel) vs маленькая классическая модель на тех же сжатых признаках; важно честно фиксировать, насколько «урезали» исходный MNIST.

• Ссылка: https://yann.lecun.org/exdb/mnist/index.html

Графовые датасеты для QAOA

• Размер: обычно это наборы графов разной структуры и размера — от совсем маленьких до умеренных, потому что масштаб здесь довольно быстро упирается и в глубину схемы, и в стоимость эксперимента.

• Кодирование: граф фактически задаёт задачу напрямую, например MaxCut, а параметры QAOA формируют распределение по возможным решениям.

• Какие квантовые данные: counts по битстрокам-решениям + статистики качества решения (насколько хорош разрез).

• Ограничения: ограниченная глубина и шум; результаты чувствительны к структуре графа и оптимизации параметров.

• Что обычно сравнивают: качество решения QAOA против классических эвристик или релаксаций, плюс стабильность результатов по разным запускам. Отдельно обычно смотрят чувствительность к шуму и глубине схемы.

• Ссылка: https://sparse.tamu.edu/Gset

Молекулярные данные для VQE

• Размер: чаще это даже не датасет в привычном ML-смысле, а серия молекул или геометрий. Классический старт — совсем небольшие молекулы.

• Кодирование: молекулу переводят в оператор на кубитах, VQE подбирает параметры анзаца.

• Какие квантовые данные: измеряемые значения (ожидания операторов), из которых собирают целевую величину (например, энергию).

• Ограничения: много измерений, шум и нередко довольно капризная оптимизация параметров.

• Что обычно сравнивают: точность целевой величины, например энергии, относительно числа измерений и устойчивости оптимизации. В качестве baseline’а обычно выступают классические расчёты, референсные значения или симулятор без шума

• Ссылка: https://pennylane.ai/datasets/h2-molecule

Экспериментальные результаты и метрики

В статьях обычно сравнивают не абстрактное «квантовое против классического вообще», а вполне конкретные пары: quantum kernel vs классические kernel’ы (RBF/poly) и обычные модели; VQC/QNN vs маленькие MLP/логрег/деревья как честные безлайны; QAOA vs классические эвристики для графовых задач. Метрики — те же, что в обычном ML: классификация (accuracy/F1/ROC-AUC); регрессия (MAE/MSE); оптимизация (качество решения + стабильность по запускам).

Где иногда появляется намёк на преимущество? Чаще всего в довольно аккуратных режимах: мало данных, специфическая структура задачи, удачно подобранное кодирование или feature map.

Где его нет: Там, где кодирование выбрано неудачно, данных слишком много, kernel становится дорогим, шум высокий или классический baseline просто сильнее. Именно поэтому в свежих работах всё чаще делают не единичные красивые демо, а систематические бенчмарки в духе «что работает, что не работает и от чего именно это зависит». Чтобы сравнение квантового и классического было осмысленным, в хороших работах обычно фиксируют несколько вещей:

• одинаковый вход: сравниваем модели на одном и том же представлении данных (одни и те же признаки/сжатие);

• сильные baselines: для kernel-ветки — RBF/poly, для VQC/QNN — простые, но честные классические модели;

• повторяемость: несколько сидов/разбиений, чтобы результат не был «удачным раскладом»;

• режимы шума: хотя бы идеальный симулятор и noisy-симуляция, а в идеале ещё и проверка на устройстве;

• стоимость: сколько измерений/запусков требуется и насколько стабилен результат (без этого «качество» неполное).

7. Ключевые работы на arXiv (мини-обзор: 5 линий)

1) Quantum kernel advantage (линия квантовых ядер):

Идея: feature map задаёт «другое» пространство признаков → учимся по kernel-матрице;
Данные: небольшие табличные/демо-бенчмарки;
Показали: рабочий протокол «feature map → K → SVM»;
Вывод: один из самых естественных входов в QML, но всё очень сильно упирается в дизайн кодирования и устойчивость результата;
Ключевая работа: Havlíček et al., Supervised learning with quantum-enhanced feature spaces ( arXiv:1804.11326)(https://arxiv.org/abs/1804.11326 );

2) Variational classifiers (VQC/QNN как модель/слой)

Идея: квантовая схема сама выступает моделью, а дальше идёт вполне привычный train loop;
Данные: уменьшенные изображения/табличные признаки;
Показали: end-to-end обучение возможно, но чувствительно к оптимизации и шуму;
Вывод: инженерно это действительно можно воспринимать как ещё один слой — только довольно дорогой по измерениям;
Ключевая работа: Pérez-Salinas et al., Data re-uploading for a universal quantum classifier (arXiv:1907.02085) (https://arxiv.org/abs/1907.02085 );

3) Noise-aware training (обучение с учётом шума)

Идея: тренировать так, чтобы модель меньше ломалась от NISQ-шума («учёт железа» в обучении);
Данные: малые бенчмарки + эксперименты на реальных устройствах;
Показали: устойчивость улучшается не только схемами, но и техникой обучения;
Вывод: в QML «данные» — это ещё и распределение шума, и игнорировать его просто не получится;
Ключевая работа: Wang et al., QuantumNAT: Quantum Noise-Aware Training with Noise Injection, Quantization and Normalization (arXiv:2110.11331) ( https://arxiv.org/abs/2110.11331);

4) Hybrid QML benchmarks (большие сравнения)

Идея: взять много датасетов, много вариантов кодирования, ядер и моделей и посмотреть на картину честно, а не по одному красивому примеру;
Данные: широкие наборы табличных задач и протоколов;
Показали: «универсального преимущества» нет, есть зоны применимости и зависимости от дизайна;
Вывод: область постепенно приходит к культуре настоящих бенчмарков — почти так же, как это давно произошло в классическом ML;
Ключевая работа: Schnabel et al., Quantum Kernel Methods under Scrutiny: A Benchmarking Study (arXiv:2409.04406) ( https://arxiv.org/abs/2409.04406 );

5) Эксперименты на реальном железе (переход от симулятора)

Идея: прогонять всё end-to-end уже на устройствах и честно смотреть, что именно начинает ломаться из-за шума и аппаратных ограничений;
Данные: чаще небольшие бинарные постановки;
Показали: реальные ограничения быстро доминируют над «красотой идеи»;
Вывод: ценность таких работ часто не только в самом результате, сколько в протоколах, воспроизводимости и честной отчётности;
Ключевая работа: Yin et al., Experimental quantum-enhanced kernels on a photonic processor (arXiv:2407.20364) ( https://arxiv.org/abs/2407.20364 );

Куда движется работа с квантовыми данными

Если смотреть на исследования в целом, тренды вырисовываются довольно чётко:

• Масштабирование: Больше кубитов — это хорошо, но ещё важнее научиться лучше сжимать и кодировать данные под ограниченные схемы.

• Шум как часть пайплайна: Всё больше методов обучения и оценки изначально строятся с учётом того, что железо шумное, а не «идеально по умолчанию».

• Гибридность по умолчанию: Квантовый блок всё чаще — это просто модуль: ядро, эмбеддинг или слой, вокруг которого работает обычный ML-стек.

• Новые бенчмарки: Область постепенно уходит от единичных красивых демо к систематическим сравнениям в духе «что действительно работает, где именно и при каких условиях».

8. Где квантовые данные уже полезны — и где пока нет

Предыдущий раздел показал довольно важную вещь: в исследованиях успех здесь почти никогда не возникает сам собой. Всё очень сильно зависит от кодирования, шума и стоимости измерений. И если перевести эту картину из мира статей и бенчмарков в нормальный инженерный язык, то получается вполне практичный чеклист: 

• Быстрый R&D на симуляторе: На симуляторе можно быстро прогонять гипотезы, сравнивать схемы и способы кодирования, отсеивать слабые идеи ещё до того, как вы вообще доберётесь до дорогих запусков на железе.

• Сценарии с bitstring / counts на выходе: Если вашей задаче действительно нужны выборки или распределения, то вся цепочка выглядит вполне естественно:  counts → p(bitstring) → признаки/эмбеддинги и дальше обычный ML.

• Гибридные пайплайны (самый реалистичный прикладной формат сейчас): И вот это, пожалуй, сегодня самый здравый сценарий. Квантовый блок даёт kernel, эмбеддинг или какие-то специфические признаки, а всё остальное — обучение, валидация и мониторинг — спокойно остаётся в классическом ML-стеке.

Не стоит тянуть «квантовый слой», если:

• классический pipeline уже стабильно решает задачу и у вас нет чёткой гипотезы, что именно квантовая часть улучшит;

• нет ресурсов пройти честный цикл: симулятор → noisy-симуляция → реальное устройство (или хотя бы два первых шага);

• нет baseline-сравнения после конвертации данных (то есть сравнения с классическими ядрами/эмбеддингами на том же входе);

• размер данных большой, а выбранный подход требует дорогих попарных вычислений (kernel-матрица) или огромных измерений.

Короткий вывод: сейчас квантовые данные чаще всего полезны как инструмент эксперимента и модуль в гибридной системе. Если этого нет — квантовый слой обычно добавляет сложность быстрее, чем даёт пользу. А это, очевидно, уже совсем не тот эффект, ради которого хочется тащить новую технологию в инженерный пайплайн.

Заключение

Если собрать всё в одну простую мысль, то квантовые данные — это не готовый файл, который можно скачать и сразу отправить в пайплайн, а результат эксперимента, который сначала ещё нужно провести и именно поэтому работать с ними приходится иначе, чем мы привыкли в классическом ML.

Да, в этой области уже постепенно складываются и бенчмарки, и протоколы сравнения. Но главный вывод довольно простой: квантовое преимущество не возникает само по себе только потому, что в задаче появились кубиты. Всё, как и раньше, упирается в кодирование данных, шум, стоимость измерений и честные baseline’ы.

Сразу скажу: квантовые вычисления сегодня не заменяют классические методы. На практике куда реалистичнее выглядит гибридный сценарий, где квантовый блок даёт признаки, эмбеддинги или сходства, а обучение и оценка качества остаются в привычном ML-стеке.

И, пожалуй, именно это здесь особенно интересно: область всё ещё формируется, но уже даёт живую среду для экспериментов, проверки гипотез и поиска действительно нетривиальных эффектов. Так что за этой темой точно стоит следить дальше. Хотя бы из любопытства ;-)

Еще больше инетерсных тем из мира AI можно найти в нашем блоге, подписывайтесь, ставьте лайки всех рады видеть: https://t.me/DenoiseLAB. Также у нас есть чат, можете написать по любым вопросам. Эта тема для нас новая, мы только погружаемся в нее, если вы увидели какие-то неточности или ошибки будем рады все поправить. Так сказать пилотная статья ))