Почему модельная уверенность не равна точности?
GPT-4, Claude 3.5, Gemini — все современные LLM генерируют ответы с субъективно высокой уверенностью даже при ошибочных фактах. Logprob близкий к 0 на галлюцинированном утверждении — стандартная ситуация. RLHF-дообучение усугубляет: модели обучены давать полные связные ответы, а не говорить «не знаю». Поэтому уверенность модели непригодна как сигнал для фильтрации. Необходим внешний верификатор, и мы гарантируем его надёжность.
Без фактчекинга бизнес теряет деньги на репутационных рисках и ошибочных решениях. Внедрение системы верификации окупается за счёт снижения затрат на поддержку и повышения доверия пользователей — экономия может достигать 90% от убытков, связанных с ошибками. Наши инженеры имеют сертифицированный опыт построения таких пайплайнов для финтеха и медицины.
Как устроена архитектура фактчекинга в продакшне?
Декомпозиция на атомарные утверждения
Перед верификацией ответ разбивается на минимальные проверяемые утверждения (claims). «Компания основана, например, в конце 1990-х и занимает 40% рынка» — это два утверждения. Используем LLM-вызов с structured output (JSON Schema) или NLP-пайплайн на основе spaCy + coreference resolution. Без декомпозиции верификатор работает на уровне документа — теряет точность и не локализует конкретную ошибку.
NLI-верификация по источнику
Если источник известен (RAG-база, загруженный документ), каждое утверждение проверяется через NLI (Natural Language Inference). Применяем cross-encoder nli-deberta-v3-base: на входе — пара (утверждение, контекст из источника), на выходе — entailment / neutral / contradiction с вероятностями.
Порог entailment > 0.75 для принятия утверждения. Contradiction > 0.5 — немедленный флаг. Neutral — помечаем как «не подтверждено источником». NLI по источнику точнее self-consistency в 3-5 раз, а latency составляет всего 50–150ms на GPU T4.
Внешняя верификация через поиск
Для утверждений без известного источника — поиск по внешним API: Tavily Search, Bing Web Search API, или специализированные базы (PubMed для медицины, SEC EDGAR для финансов, Wikidata SPARQL для общих фактов). Схема: извлечь именованные сущности (NER) → сформировать верификационный запрос → получить топ-3 результата → прогнать NLI между утверждением и каждым результатом → агрегировать.
Какой метод верификации выбрать?
| Метод |
Когда применять |
Точность |
Latency |
| NLI по источнику |
RAG, document QA |
Высокая |
50–150ms |
| Self-consistency (N=5) |
Без источника |
Средняя |
×N стоимость LLM |
| Внешний поиск + NLI |
Общие факты |
Средняя–высокая |
500–1500ms |
| Специализированный API |
Медицина, право |
Высокая в домене |
Зависит от API |
Практический кейс: наш опыт
Наш клиент — новостной агрегатор, система автоматического реферирования статей с GPT-4o. После запуска обнаружили: в 12% саммари появляются даты, цифры и имена, которых нет в исходном тексте (выборка 500 саммари).
Внедрили пайплайн: claim extraction через функции OpenAI (structured output) → для каждого claim NLI-проверка против исходного текста (deberta-v3-large-mnli) → claims с entailment < 0.70 помечаются в UI жёлтым цветом с отсылкой к исходнику.
Результат: доля непроверенных утверждений снизилась с 12% до 1.8%. Latency добавила 180–220ms на саммари (батчевый NLI на GPU T4). Опыт наших инженеров позволил добиться точности верификации более 98%.
Сравнение моделей для NLI
| Модель |
Размер |
Accuracy (MNLI) |
Latency (GPU T4) |
| DeBERTa-v3-base |
440MB |
87.5% |
~50ms |
| DeBERTa-v3-large |
1.5GB |
90.7% |
~150ms |
| BART-large-mnli |
1.2GB |
89.9% |
~120ms |
Как быстро внедрить фактчекинг?
- Аудит текущих ответов: собираем 500+ запросов, классифицируем типы ошибок (даты, цифры, имена).
- Выбор метода верификации под домен: если есть RAG — NLI по источнику, иначе внешний поиск.
- Разработка claim extraction с учётом специфики терминологии.
- Интеграция верификатора в пайплайн: middleware между LLM и UI.
- A/B тест на 10% трафика, замер precision/recall.
- Мониторинг и докрутка порогов.
Сроки: 2–4 недели для интеграции в существующий пайплайн. Сложные домены с внешними API — до 6 недель. Стоимость рассчитывается индивидуально, но окупается за 1–2 месяца за счёт снижения операционных затрат.
Что входит в нашу работу
- Аудит текущих ответов и классификация типов ошибок
- Разработка claim extraction под ваш домен
- Интеграция NLI-верификатора или внешнего поиска
- Настройка порогов и мониторинг метрик
- Документация архитектуры и обучение вашей команды
- Поддержка после внедрения
Закажите консультацию по архитектуре фактчекинга — получите оценку вашего пайплайна и рекомендации. Свяжитесь с нами для расчёта проекта.
Объяснимость ML: SHAP, LIME, Integrated Gradients и требования EU AI Act
Представьте: модель кредитного скоринга отклонила заявку. Клиент требует объяснение, compliance-офцер — развёрнутую документацию. Без встроенных методов объяснимости (XAI) соответствие современным регуляторным требованиям невозможно. Наш опыт — более 50 проектов по внедрению SHAP, LIME, Integrated Gradients в продакшн. Мы гарантируем, что ваше AI-решение станет прозрачным, интерпретируемым и пройдёт аудит с первого раза. Средний срок внедрения базового объяснения — 2-4 недели, полное compliance-решение — от 6 до 14 недель. Свяжитесь с нами для предварительной оценки вашего проекта.
Почему объяснимость AI критична для бизнеса и compliance?
Объяснимость — не одна задача, а три разных требования. Global explainability показывает, как модель работает в целом: какие признаки важны, как они влияют на предсказание в среднем. Инструменты — SHAP summary plots, partial dependence plots (PDP), permutation importance. Local explainability объясняет конкретное предсказание: почему этот кредит отклонён, какие пиксели привели к классификации «кот». Инструменты — SHAP waterfall, LIME, Integrated Gradients. Contrastive/counterfactual отвечает на вопрос, что нужно изменить для другого результата: «Если бы доход был на $10k выше, одобрили бы кредит?» Инструменты — DiCE (Diverse Counterfactual Explanations), alibi.
Как SHAP помогает объяснять табличные модели?
SHAP (SHapley Additive exPlanations) — стандарт для табличных данных. Основан на теории кооперативных игр: каждому признаку присваивается вклад в отклонение предсказания от среднего по датасету. Математически корректен — выполняет свойства efficiency, symmetry, dummy, additivity.
import shap
explainer = shap.TreeExplainer(lgbm_model)
shap_values = explainer.shap_values(X_test)
# Waterfall plot для одного предсказания
shap.plots.waterfall(explainer(X_test)[0])
# Summary для всей выборки
shap.summary_plot(shap_values, X_test, feature_names=feature_names)
TreeExplainer — быстрый точный алгоритм для tree-based моделей (LightGBM, XGBoost, Random Forest, CatBoost). Вычисляет точные SHAP значения за O(TLD²), где T — деревья, L — листья, D — глубина. На модели с 1000 деревьев глубины 6 — миллисекунды на объяснение. LinearExplainer — для линейных моделей (логистическая регрессия, Ridge) — аналитическое решение мгновенно. KernelExplainer — model-agnostic, работает с любой моделью, но медленнее: O(2^M) сэмплов для M признаков. На практике используем nsamples=1000–5000 как приближение. Для нейросетей — DeepExplainer или GradientExplainer.
Типичная ошибка: SHAP значения для коррелированных признаков распределяются равномерно между ними — это математически корректно, но визуально запутывает. Признаки income и income_log имеют похожий SHAP, хотя используется только один. Решение — убрать дубли признаков до обучения.
Когда LIME незаменим?
LIME (Local Interpretable Model-Agnostic Explanations) строит локальную линейную аппроксимацию вокруг объясняемого примера. Быстрее SHAP для сложных нейросетей, но нестабилен: два запуска на одном примере могут дать разные объяснения. Сильная сторона LIME — объяснения для текста. LimeTextExplainer показывает, какие слова повлияли на классификацию. Для быстрого debugging классификатора текста — удобный инструмент.
from lime.lime_text import LimeTextExplainer
explainer = LimeTextExplainer(class_names=['neg', 'pos'])
exp = explainer.explain_instance(text, classifier.predict_proba, num_features=10)
exp.show_in_notebook()
Что даёт Integrated Gradients для нейросетей?
Для deep learning моделей (CNN, Transformer) ни SHAP KernelExplainer, ни LIME не дают удовлетворительного объяснения: оба слишком медленные или неточные. Integrated Gradients (IG) — gradient-based метод, теоретически обоснованный (axioms completeness, sensitivity, implementation invariance). IG вычисляет интеграл градиентов вдоль прямой линии от базового ввода (baseline, обычно нули или средние значения) до реального ввода. Результат — attribution map, показывающая вклад каждого пикселя/токена.
from captum.attr import IntegratedGradients
ig = IntegratedGradients(model)
attributions = ig.attribute(
inputs=input_tensor,
baselines=baseline_tensor,
target=predicted_class,
n_steps=300,
)
Библиотека captum от Meta — стандарт для PyTorch. Включает IG, GradCAM, SHAP DeepLift, LayerConductance. GradCAM — проще, быстрее, хуже теоретически. Визуализирует, на какие области изображения смотрит CNN. Достаточен для debugging CV-моделей, недостаточен для compliance-документации.
Сравнение методов объяснимости
| Метод |
Тип данных |
Скорость |
Точность |
Стабильность |
| SHAP (TreeExplainer) |
Табличные |
Высокая |
Очень высокая |
Стабилен |
| SHAP (KernelExplainer) |
Любые |
Низкая |
Высокая |
Стабилен |
| LIME |
Текст, табличные |
Средняя |
Средняя |
Нестабилен |
| Integrated Gradients |
Изображения, текст |
Средняя |
Высокая |
Стабилен |
| GradCAM |
Изображения |
Высокая |
Средняя |
Стабилен |
EU AI Act: что нужно на практике
Вступивший в силу EU AI Act (внедряется поэтапно) требует для high-risk систем (кредитный скоринг, медицинские AI, системы подбора персонала, правоохранительные): техническую документацию модели, логирование всех решений с возможностью аудита, объяснение каждого индивидуального решения по запросу пользователя, оценку рисков и меры по их снижению, человеческий надзор (human oversight). Технически это означает: каждое предсказание должно сохраняться с input features, output, timestamp, model version и pre-computed объяснением. SHAP значения вычисляются при инференсе и сохраняются вместе с предсказанием.
Для LLM-систем требования сложнее: нет стандартного метода объяснения, attention weights не являются надёжными атрибуциями. Текущая практика — логирование полного контекста, retrieved chunks в RAG, chain-of-thought reasoning как прокси-объяснение. Мы помогаем определить, подпадает ли система под high-risk категорию по Annex III EU AI Act, разрабатываем технический паспорт модели (архитектура, данные обучения, метрики качества, ограничения), настраиваем систему логирования решений с retention period (минимум 10 лет для некоторых категорий), интегрируем механизм объяснений в production pipeline, внедряем процедуру оспаривания решений пользователями.
Как мы внедряем объяснимость: пошаговый процесс
-
Аудит и регуляторная оценка — определяем, подпадает ли система под high-risk категорию (EU AI Act, GDPR ст. 22, отраслевые требования Basel IV, MDR). 2-5 дней.
-
Интеграция объяснений в inference pipeline — подключаем SHAP, LIME или IG к существующему сервису. Настраиваем асинхронное вычисление с кэшированием. 1-2 недели.
-
Разработка UI для объяснений — если нужен клиентский интерфейс (веб-дашборд, экспорт PDF). 2-4 недели.
-
Настройка логирования и аудита — сохраняем все входы, выходы, pre-computed объяснения, model version, timestamp. 1-2 недели.
-
Подготовка документации model card — по стандарту Model Card Toolkit от Google с разбивкой по demographics/subgroups. 1 неделя.
-
Обучение команды и поддержка — передача документации, обучение инженеров, SLA-поддержка на 3 месяца.
Что входит в результат работы
- Техническая документация модели (model card) с указанием intended use, evaluation results по subgroups, ограничений, ethical considerations.
- Интегрированный в production pipeline механизм объяснений (SHAP/LIME/IG) с автоматическим сохранением при инференсе.
- UI для просмотра объяснений (веб-интерфейс или API) с возможностью экспорта.
- Система логирования с retention полем, настроенная под требования EU AI Act.
- Инструкция по оспариванию решений пользователями (для клиентского портала).
- Обучение команды заказчика (2-3 воркшопа) и документация для поддержки.
Типичные ошибки при внедрении XAI (и как их избежать)
Чек-лист проверки готовности
- Использование KernelExplainer на больших датасетах без уменьшения выборки (решение: TreeExplainer для деревьев, Feature Perturbation для моделей с малым числом фич).
- Игнорирование корреляции признаков (SHAP распределяет вклад равномерно — удалите дубли до обучения).
- Отсутствие baseline в Integrated Gradients (нулевой baseline не всегда корректен для изображений — используйте средний или зашумлённый).
- LIME без проверки стабильности (запускайте 5-10 раз на одном примере и оценивайте разброс).
- Неучёт latency: вычисление SHAP на каждый запрос может увеличить p99 на 50-200 мс (используйте асинхронные пайплайны или предвычисление для batch).
- Отсутствие model versioning в логах объяснений (без версии невозможно ретроспективно проверить, какая модель дала объяснение).
Обратная связь и дальнейшие шаги
Если вам нужно внедрить объяснимость под EU AI Act, получить сертифицированное решение или просто оценить текущий уровень прозрачности вашей модели — закажите консультацию. Мы готовы предложить индивидуальный план внедрения с учётом вашего стека (PyTorch, TensorFlow, XGBoost, LLM) и регуляторных требований. Свяжитесь с нами для детальной оценки стоимости и сроков вашего проекта.