Как создать систему поиска дипфейков на Python с AI

Дипфейки перестали быть экспериментом из лаборатории и превратились в обычный цифровой риск. Сегодня нейросетью можно заменить лицо в ролике, синтезировать голос, дорисовать мимику, изменить освещение или собрать полностью искусственного человека, которого никогда не существовало.

Для пользователя такая запись может выглядеть убедительно, а для бизнеса - стать причиной финансовых потерь, репутационного скандала или утечки данных.

Поэтому системы автоматического поиска дипфейков становятся частью медиаплатформ, банковских сервисов, редакций и корпоративных систем безопасности.

Разберём, как создать детектор дипфейков на Python с использованием методов компьютерного зрения и машинного обучения. Мы рассмотрим архитектуру проекта, подготовку данных, извлечение кадров, работу с лицами, обучение модели, оценку качества и развёртывание сервиса.

Сразу важное уточнение: универсального детектора не существует. Хорошая система не "видит ложь" напрямую, а находит совокупность признаков, характерных для конкретных способов генерации или монтажа.

Что именно должна обнаруживать система

Перед написанием кода необходимо определить, какой объект будет проверять алгоритм. Дипфейк не один формат подделки.

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

Если смешать все случаи в одну задачу без разметки, модель начнёт путать монтаж, плохое качество записи и настоящую генерацию.

Практически удобно разделить задачу на несколько классов. Бинарный вариант отвечает на вопрос "оригинал или подделка".

Более полезный промышленный вариант возвращает тип подозрительного изменения: замена лица, синтетическая мимика, искусственный голос, монтаж, повторная обработка или недостаточно данных для уверенного вывода.

Третий уровень - объяснение результата: какие кадры, области лица или аудиофрагменты повлияли на оценку.

• Видеоаналитика: поиск артефактов в последовательности кадров.
• Аудиоаналитика: проверка спектра, тембра, пауз и особенностей синтезированной речи.
• Мультимодальный анализ: сопоставление движения губ, голоса, мимики и временной шкалы.
• Проверка происхождения: анализ метаданных, цепочки обработки и цифровых подписей.

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

Такой подход позволяет быстро проверить гипотезу, собрать ошибки и только потом добавлять звук, метаданные и сложные нейросетевые признаки.

Архитектура проекта и рабочий конвейер

Надёжный детектор строится не как один вызов модели, а как последовательный конвейер. На вход поступает файл, затем система проверяет формат, длительность, разрешение и наличие видеопотока.

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

В конце формируется отчёт с вероятностью, уровнем уверенности и техническими предупреждениями.

Разделение на этапы важно по двум причинам. Можно заменить один компонент, не переписывая всё приложение. Например, OpenCV удобно оставить для чтения видео, а Haar Cascade заменить на более современный детектор лиц.

Каждый этап можно тестировать отдельно. Если модель показывает слабый результат, разработчик видит, проблема в кадрах, обрезке лица, обучении или агрегации.

1. Приём видео и проверка безопасности файла.
2. Транскодирование в предсказуемый формат.
3. Выбор кадров через равные интервалы или детектор сцен.
4. Поиск и выравнивание лиц.
5. Изменение размера и нормализация изображения.
6. Предсказание по отдельным кадрам.
7. Объединение оценок во временную оценку.
8. Формирование результата и журналирование.

Пример базовой структуры каталогов может выглядеть так:

deepfake_detector/
 app/
 api.py
 pipeline.py
 preprocessing.py
 inference.py
 models/
 detector.pt
 scripts/
 extract_frames.py
 train.py
 data/
 train/
 validation/
 test/
 tests/
 requirements.txt

В продакшене желательно отделить API от тяжёлого инференса. Веб-сервис принимает запрос и ставит задачу в очередь, а отдельный worker обрабатывает видео на CPU или GPU. Это защищает API от зависания при загрузке большого файла.

Для небольших роликов подойдёт синхронная обработка, но даже тогда необходимо ограничить размер, длительность и число параллельных задач.

Подготовка датасета без утечки информации

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

На тесте результат будет красивым, а в реальной эксплуатации всё развалится.

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

Тогда при анализе ошибок станет ясно, на каких генераторах или условиях система работает хуже.

Ключевое правило - разделять данные по людям и источникам, а не случайно по кадрам. Нельзя положить первые кадры одного ролика в обучение, а последние - в тест. Они почти одинаковы, поэтому модель фактически увидит тестовый пример заранее.

Более корректная схема: конкретный человек, исходный ролик или канал генерации целиком попадает только в один набор.

Не стоит ограничиваться идеальными роликами. В реальном интернете видео пересылают через мессенджеры, загружают на платформы, снимают с экрана и повторно кодируют.

Поэтому в датасет добавляют искусственные искажения: шум, размытие, изменение яркости, масштабирование, обрезку, сжатие H.264, пропуски кадров и наложение субтитров. Однако аугментация не должна уничтожать признаки, которые система должна находить.

Для быстрой проверки идеи можно начать с нескольких тысяч коротких фрагментов, но объём не гарантирует качество.

Важнее разнообразие генераторов и съёмочных условий. Датасет, в котором 20 000 кадров получены из 200 почти одинаковых роликов, слабее набора из 5 000 кадров, собранных из разных камер, лиц, возрастов, освещения и алгоритмов синтеза.

Извлечение кадров и обнаружение лиц

Видео нельзя бездумно передавать в классификатор как огромный массив пикселей. Сначала из него выбирают представительные кадры. Простейшая стратегия - брать один кадр каждые несколько секунд или фиксированное число кадров на ролик. Например, из десятисекундного видео можно получить 16 кадров.

Такой вариант быстрый и хорошо подходит для первичного прототипа.

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

Детектор сцен помогает не тратить ресурсы на повторяющиеся участки и одновременно не пропускать подозрительные переходы.

import cv2
import numpy as np

def sample_frames(path, count=16):
 capture = cv2.VideoCapture(path)
 total = int(capture.get(cv2.CAP_PROP_FRAME_COUNT))
 if total <= 0:
 raise ValueError("Не удалось прочитать число кадров")

 indexes = np.linspace(0, total - 1, count).astype(int)
 frames = []

 for index in indexes:
 capture.set(cv2.CAP_PROP_POS_FRAMES, int(index))
 ok, frame = capture.read()
 if ok:
 frames.append(frame)

 capture.release()
 return frames

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

Это уменьшает влияние положения головы и позволяет модели сосредоточиться на коже, мимике, границах маски и деталях рендеринга.

Для детектора лица можно использовать MediaPipe, RetinaFace, MTCNN или модели из OpenCV. Простые каскады работают быстро, но хуже справляются с поворотами, масками и низким разрешением.

Важно сохранять координаты рамки и уверенность детектора: если лицо найдено плохо, итоговый прогноз не должен выглядеть таким же надёжным, как прогноз по чёткому крупному плану.

Выбор нейросетевой модели

В качестве стартового классификатора подойдёт сверточная сеть с предварительным обучением на большом наборе изображений. В Python часто используют PyTorch и библиотеку timm, где доступны EfficientNet, ConvNeXt, ResNet и другие архитектуры.

Предобученные веса ускоряют обучение, потому что модель уже умеет выделять края, текстуры, контуры и простые визуальные структуры.

Последний слой заменяют на классификатор из двух выходов: "оригинал" и "подделка".

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

import torch
import torch.nn as nn
import timm

def build_model():
 model = timm.create_model(
 "efficientnet_b0",
 pretrained=True,
 num_classes=2
 )
 return model

device = "cuda" if torch.cuda.is_available() else "cpu"
model = build_model().to(device)

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

Для анализа последовательности можно добавить LSTM, GRU, temporal convolution или Transformer, который получает признаки нескольких кадров.

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

Такой подход требует больше памяти и аккуратной подготовки последовательностей, зато способен находить неестественное моргание, рывки мимики и нестабильность деталей между кадрами.

Обучение и борьба с переобучением

Для бинарной классификации обычно применяют Cross Entropy Loss или Binary Cross Entropy. Если классы несбалансированы, например оригинальных видео заметно больше, используют взвешенную функцию потерь, oversampling редкого класса или focal loss.

Иначе модель может научиться всегда выбирать наиболее частую категорию и демонстрировать высокий процент формальной точности.

Базовый цикл обучения должен включать отдельные режимы train и evaluation. В режиме обучения активируются аугментации и dropout, а веса обновляются оптимизатором. В режиме проверки градиенты отключаются.

После каждой эпохи сохраняют метрики на валидации и лучший checkpoint, а не просто последнюю версию модели.

import torch

criterion = torch.nn.CrossEntropyLoss()
optimizer = torch.optim.AdamW(
 model.parameters(),
 lr=2e-4,
 weight_decay=1e-4
)

for epoch in range(10):
 model.train()
 for images, labels in train_loader:
 images = images.to(device)
 labels = labels.to(device)

 optimizer.zero_grad()
 logits = model(images)
 loss = criterion(logits, labels)
 loss.backward()
 optimizer.step()

 model.eval()
 with torch.no_grad():
 # здесь рассчитываются метрики на validation
 pass

Главный враг проекта - переобучение. Сеть запоминает конкретные лица, шум камеры, логотипы или особенности генератора, но не учится обобщать.

Чтобы снизить риск, применяют случайные обрезки, горизонтальные отражения, изменение цвета, blur, jpeg-компрессию и mixup. Ещё важнее - проверять модель на полностью новых источниках, которых не было в обучении.

Не следует бездумно применять вертикальное отражение, сильные геометрические искажения или агрессивное размытие.

Некоторые аугментации создают нереалистичные данные и приучают модель к искусственным признакам. Хорошая практика - визуально просматривать случайные преобразованные кадры перед запуском долгого обучения.

Метрики, пороги и объяснение результата

Accuracy удобна для первого отчёта, но недостаточна. Если в тесте 90 процентов оригиналов, модель, всегда выбирающая "оригинал", получит 90 процентов точности и будет бесполезной. Для детектора дипфейков необходимо смотреть precision, recall, F1-score, ROC-AUC и PR-AUC.

Каждая метрика отвечает на свой практический вопрос.

• Precision: какая доля отмеченных подделок действительно оказалась подделкой.
• Recall: сколько всех подделок удалось обнаружить.
• F1-score: баланс между precision и recall.
• ROC-AUC: способность ранжировать примеры по риску.
• Матрица ошибок: показывает, какие классы система путает.

Порог 0,5 не является священным. Если сервис нужен редактору как фильтр предварительной проверки, важнее высокий recall: лучше отправить несколько настоящих роликов на ручную проверку, чем пропустить опасную подделку.

Для автоматической блокировки аккаунта, напротив, нужен высокий precision, потому что ошибка затронет реального пользователя.

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

Полезно отдельно хранить разброс предсказаний: если часть кадров получила 0,05, а другая часть 0,95, система должна обозначить результат как нестабильный и попросить дополнительную проверку.

import numpy as np

def aggregate(scores):
 values = np.asarray(scores, dtype=float)
 mean_score = float(values.mean())
 median_score = float(np.median(values))
 spread = float(values.std())

 return {
 "mean": mean_score,
 "median": median_score,
 "spread": spread,
 "risk": "high" if median_score >= 0.7 else "low"
 }

Пользователю нужен не только процент.

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

Это повышает доверие и помогает оператору понять, почему автоматике нельзя доверять безоговорочно.

Анализ аудио и мультимодальный подход

Видео нельзя оценивать только по лицу, если злоумышленник заменил голос или изменил речь. Аудиомодуль извлекает дорожку, преобразует её в спектрограмму и анализирует признаки синтетического голоса.

Среди подозрительных сигналов встречаются чрезмерно ровная интонация, неестественные паузы, повторяющиеся спектральные шаблоны, артефакты на согласных и несоответствие акустики помещению.

Для работы со звуком в Python применяют librosa, torchaudio и специализированные модели распознавания речи. На вход можно подавать log-Mel-спектрограммы, MFCC или сырые аудиофрагменты. Но аудиодетектор также уязвим к смене кодека, микрофона, языку и шуму.

Модель, обученная на студийной речи, может ошибочно считать дипфейком запись с телефона в метро.

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

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

Мультимодальный скоринг можно считать как взвешенную сумму: видео получает 0,6, аудио - 0,25, метаданные и технические признаки - 0,15. Эти коэффициенты не следует брать навсегда. Их подбирают на валидации и меняют в зависимости от сценария.

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

Метаданные, происхождение и цифровая подпись

Нейросетевой анализ полезен, но проверка происхождения иногда эффективнее. Файл может содержать сведения о времени создания, программе монтажа, цепочке экспортов и исходном устройстве.

Для чтения таких данных применяют ffprobe, ExifTool и библиотеки Python. Однако метаданные нельзя считать доказательством: социальные сети удаляют их, а злоумышленник способен изменить почти любое поле.

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

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

В собственной системе стоит вычислять криптографический хеш исходного файла и сохранять его вместе с результатом анализа. Для большого видео можно использовать SHA-256.

Хеш не рассказывает, является ли видео правдой, но позволяет доказать, что повторно проверялся тот же файл, а отчёт не относится к другой версии.

import hashlib

def file_sha256(path, chunk_size=1024 * 1024):
 digest = hashlib.sha256()
 with open(path, "rb") as file:
 while True:
 chunk = file.read(chunk_size)
 if not chunk:
 break
 digest.update(chunk)
 return digest.hexdigest()

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

Без такой истории невозможно объяснить, почему публикация была отмечена или пропущена.

Создание API на FastAPI

Когда модель проверена, её можно завернуть в HTTP-сервис. FastAPI подходит для такого прототипа благодаря простой типизации, автоматической документации и хорошей скорости. Эндпоинт принимает видео, сохраняет его во временный каталог, запускает pipeline и возвращает JSON с результатом.

В реальном проекте необходимо добавить авторизацию, лимиты, антивирусную проверку и удаление временных файлов.

from fastapi import FastAPI, UploadFile, File, HTTPException
from pathlib import Path
import uuid

app = FastAPI()
TEMP = Path("/tmp/deepfake")

@app.post("/analyze")
async def analyze(file: UploadFile = File(...)):
 allowed = {"video/mp4", "video/webm", "video/quicktime"}
 if file.content_type not in allowed:
 raise HTTPException(415, "Неподдерживаемый формат")

 TEMP.mkdir(exist_ok=True)
 target = TEMP / f"{uuid.uuid4()}.bin"

 data = await file.read()
 if len(data) > 300 * 1024 * 1024:
 raise HTTPException(413, "Файл слишком большой")

 target.write_bytes(data)

 try:
 result = run_pipeline(str(target))
 return result
 finally:
 target.unlink(missing_ok=True)

Проверять только MIME-тип недостаточно: его можно подделать. Сервис должен анализировать контейнер через ffprobe, ограничивать число кадров, длительность и глубину декодирования, а также запускать обработку в изолированном окружении.

Медиафайлы исторически были источником уязвимостей в библиотеках декодирования, поэтому обновление ffmpeg и контейнеров безопасности - обязательная часть эксплуатации.

Если обработка занимает больше нескольких секунд, лучше возвращать идентификатор задания. Клиент затем запрашивает статус: queued, processing, completed или failed. Для очереди подойдут Celery, RQ, Redis Streams или облачный брокер.

Такая схема позволяет масштабировать GPU-workers отдельно от API и не держать HTTP-соединение открытым во время анализа.

Производительность и запуск на GPU

Самая дорогая операция обычно не чтение файла, а инференс по большому числу кадров. На CPU лёгкая модель может обрабатывать короткие ролики за несколько секунд, но при массовом потоке задержка резко возрастает.

GPU ускоряет пакетную обработку, особенно если кадры заранее приведены к единому размеру и отправляются в модель группами.

Для оптимизации уменьшают разрешение входа, используют mixed precision, кэшируют обнаруженные лица и не запускают повторный анализ одинаковых кадров. Если бизнес-сценарий допускает, вместо 64 кадров берут 16 или 24 репрезентативных кадра.

Важен баланс: чрезмерное сокращение выборки снизит чувствительность к коротким артефактам.

После обучения модель можно экспортировать в ONNX или TorchScript, а затем запускать через ONNX Runtime или TensorRT. Это уменьшает накладные расходы Python и упрощает развёртывание. Перед оптимизацией нужно проверить, не изменились ли вероятности и пороги.

Иногда ускоренная версия выдаёт близкие, но не идентичные значения, что критично для пограничных решений.

В мониторинге полезно собирать время декодирования, поиска лиц, инференса и записи результата. Отдельно отслеживают загрузку GPU, долю ошибок, размер очереди и процент файлов, по которым лицо не найдено.

Если время обработки растёт, причина может быть не в модели, а в роликах с необычно высоким разрешением или повреждённым контейнером.

Тестирование устойчивости и защита от обхода

Создатели дипфейков быстро меняют инструменты, поэтому детектор необходимо испытывать в условиях, близких к атаке. Проверяйте ролики после перекодирования, обрезки, добавления рамок, изменения скорости, зеркального отражения, наложения шума и повторной съёмки экрана.

Система, которая работает только на чистом исходнике, не готова к реальному интернету.

Отдельный риск - adversarial-атаки. Злоумышленник может подобрать незаметные для человека изменения пикселей, чтобы снизить оценку модели. Универсальной защиты нет, но помогают разнообразные аугментации, ансамбли моделей, случайный выбор кадров и регулярное переобучение на новых атаках.

Не стоит раскрывать наружу все внутренние признаки и точные пороги, если сервис используется для контроля доступа.

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

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

• Проверяйте false positive по реальным оригинальным роликам.
• Сравнивайте качество на новых генераторах, которых не было в обучении.
• Разделяйте ошибки низкого качества и ошибки самой модели.
• Проводите ручной аудит пограничных предсказаний.
• Переоценивайте порог после каждого крупного обновления данных.

Для продукта с высокими рисками следует вводить режим "не уверен". Если вероятность находится в промежуточном диапазоне, например между 0,4 и 0,6, система не должна вынужденно выбирать один класс. Такой файл отправляется на повторный анализ, проверку происхождения или человеку-эксперту.

Отказ от ложной определённости часто ценнее, чем несколько дополнительных процентов формальной точности.

Практический план разработки

Проект удобно запускать итерациями. На первой неделе собирают небольшой, но чистый датасет, пишут извлечение кадров и проверяют, что разметка корректна.

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

На втором этапе улучшают обнаружение лиц, добавляют аугментации и тестирование по источникам. Особое внимание уделяют ошибкам.

Если модель отличает подделки по логотипу, данные нужно пересобрать. Если она проваливается на профильных лицах, надо добавить такие примеры и проверить качество face alignment.

На третьем этапе внедряют временной анализ, аудио и API. Все новые компоненты должны сравниваться с базовой версией на одном и том же тестовом наборе. Иначе невозможно понять, улучшила ли система качество или просто изменилась методика измерения.

1. Сформулировать сценарий и допустимую цену ошибки.
2. Собрать разнообразные оригинальные и изменённые материалы.
3. Разделить данные по людям, роликам и генераторам.
4. Создать воспроизводимый pipeline предобработки.
5. Обучить базовую модель на лицах.
6. Проверить precision, recall, F1 и матрицу ошибок.
7. Добавить временные и аудиопризнаки.
8. Запустить API с очередью и ограничениями.
9. Настроить мониторинг, аудит и регулярное обновление.

Минимальная рабочая версия может быть компактной: FastAPI, OpenCV, MediaPipe, PyTorch, одна CNN и JSON-отчёт. Но даже в таком варианте не следует обещать пользователю абсолютное распознавание.

Корректная формулировка - "система оценивает вероятность искусственной обработки по доступным техническим признакам".

Ориентировочная статистика проекта выглядит так: модель может дать высокую точность на внутреннем тесте, но потерять 10–30 процентных пунктов на новых генераторах, другом кодеке или низком разрешении.

Это не универсальное число для всех систем, а типичный сигнал того, насколько опасно судить о качестве только по лабораторной выборке. Для реального сервиса важнее стабильность на разных источниках и прозрачная обработка неопределённости.

Детектор дипфейков на Python не магическая кнопка и не замена эксперту. Это многоступенчатая система, где нейросеть анализирует кадры, временные связи, звук и технический контекст.

Лучший результат даёт сочетание качественного датасета, честного тестирования, нескольких независимых сигналов и продуманного процесса ручной проверки.

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

Такой путь требует больше дисциплины, чем установка готовой библиотеки, зато позволяет построить систему, которая действительно помогает редакции, платформе или службе безопасности принимать решения в мире, где поддельное видео становится всё убедительнее.

Частые вопросы

Можно ли создать детектор только на CPU? Да, для коротких роликов и небольшой нагрузки достаточно современной модели на CPU. GPU понадобится при пакетной обработке, высоком разрешении и большом количестве запросов.

Достаточно ли анализа одного кадра? Нет. Один кадр иногда помогает найти визуальные дефекты, но временные артефакты, рассинхронизация и нестабильность мимики видны только по последовательности.

Можно ли считать вероятность доказательством? Нет. Вероятность отражает уверенность конкретной модели на конкретных данных. Для важных решений нужны дополнительные источники, журналирование и проверка специалистом.