LLM в обнаружении аномалий: 6 паттернов для Python-разработчика

Зачем читать эту статью?

Обнаружение аномалий — одна из тех задач, которые никак не удаётся «решить» раз и навсегда. Каждый раз, когда появляется новая модная ML-парадигма, её сразу пробуют на аномалиях. LLM не исключение. В этой статье разберём 6 паттернов, как большие языковые модели вписываются в пайплайн обнаружения аномалий, и дадим практические примеры на Python для каждого.

Классический пайплайн обнаружения аномалий

Прежде чем нырять в детали, давайте вспомним стандартный workflow:

1. Feature engineering — извлечение признаков из сырых данных.
2. Детекция — применение алгоритма (например, Isolation Forest, LOF).
3. Объяснение — интерпретация результата.
4. Действие — что делать с найденной аномалией.

LLM могут встроиться в каждый из этих этапов. Поехали по порядку.

1. Прямое обнаружение аномалий

Идея: скормить сырые данные LLM и просто спросить: «Это нормально?» Вы надеетесь, что предобученные знания модели (плюс то, что вы добавили в промпт) достаточно, чтобы отделить аномалии от нормы.

Это отлично работает, когда данные уже являются текстом. Например, подход LogPrompt для анализа системных логов: подаёте сырые логи, получаете предсказание и понятное объяснение на естественном языке. Секрет — в промпт-инжиниринге: chain-of-thought, несколько размеченных примеров для in-context learning и ручные правила предметной области.

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

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

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

Пример кода:

import openai

# Пример прямого обнаружения аномалии в логах
log_entry = "ERROR: Connection timeout after 30s"
prompt = f"""Определи, является ли следующий лог аномальным.
Ответь только 'Да' или 'Нет'.
Лог: {log_entry}
"""

response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}]
)
print(response.choices[0].message.content)  # Ожидаем 'Да'

2. Аугментация данных с помощью LLM

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

NVIDIA сделала это с Cyber Language Models: обучили модель размером с GPT-2 на сырых логах кибербезопасности, а затем использовали её для генерации синтетических логов — подозрительных событий, специфичных для пользователя сценариев. Эти синтетические данные затем подавались обратно в цикл обучения, чтобы снизить количество ложных срабатываний.

Когда применять: ваш детектор тонет в ложных срабатываниях, потому что никогда не видел достаточно разнообразия «странного» (или «нормального»).

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

Пример кода:

import openai

# Генерация синтетического аномального лога
prompt = "Сгенерируй один пример аномального лога для веб-сервера. Формат: [timestamp] [level] message"
response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}]
)
anomalous_log = response.choices[0].message.content
print(anomalous_log)
# Пример вывода: [2025-03-15 10:00:00] ERROR: SQL injection attempt detected from IP 192.168.1.1

3. Объяснение аномалий

Идея: бинарная метка «да, аномалия» редко достаточна. Нужно понимать почему, чтобы решить, что делать. LLM могут заполнить разрыв между предсказанием и действием, генерируя объяснения на естественном языке.

Одно исследование использовало GPT-4 и LLaMA 3 для генерации объяснений аномалий временных рядов. Не просто «точка 18 странная», а реальное рассуждение: «значения здесь выходят на плато, хотя по установленному циклу они должны падать после пика, что нарушает паттерн».

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

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

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

Пример кода:

import openai

# Объяснение аномалии во временном ряду
data_description = "Временной ряд: [10, 12, 11, 13, 100, 12, 11]. Аномалия: значение 100 на позиции 5."
prompt = f"""Объясни, почему значение 100 является аномалией в данном временном ряду.
Данные: {data_description}
"""
response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}]
)
print(response.choices[0].message.content)

4. Извлечение признаков с помощью LLM

Идея: LLM может работать как преобразователь признаков: превращать сырые данные в богатые семантические эмбеддинги, а затем на этих векторах запускать классический алгоритм обнаружения аномалий (PCA, кластеризацию и т.д.).

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

Databricks показала это на примере обнаружения мошеннических покупок: эмбеддинги покупок через LLM, затем PCA для оценки аномальности, и всё, что выше порога, помечается. Интересный поворот: они сделали гибридную систему, где аномалии, пойманные эмбеддингами и PCA, затем передаются обратно в LLM для контекстного объяснения (это уже паттерн №3).

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

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

Пример кода:

from sentence_transformers import SentenceTransformer
from sklearn.decomposition import PCA
import numpy as np

# Преобразование текстовых логов в эмбеддинги
model = SentenceTransformer('all-MiniLM-L6-v2')
logs = ["User login successful", "Failed password attempt", "Connection timeout"]
embeddings = model.encode(logs)

# PCA для обнаружения аномалий
pca = PCA(n_components=2)
reduced = pca.fit_transform(embeddings)
# Вычисляем расстояние от центра
center = np.mean(reduced, axis=0)
distances = np.linalg.norm(reduced - center, axis=1)
threshold = np.percentile(distances, 95)
anomalies = [logs[i] for i, d in enumerate(distances) if d > threshold]
print("Аномалии:", anomalies)

5. Интеллектуальный выбор модели детекции

Идея: выбор правильного алгоритма обнаружения аномалий — головная боль даже для ветеранов. Алгоритмов много, и нет очевидного победителя для каждого датасета. LLM могут порекомендовать модель, потому что «прочитали» много статей.

PyOD 2 реализовал именно это. Его LLM-управляемый выбор модели работает в три шага:

1. Профилирование моделей: анализ статей и исходников каждого алгоритма для извлечения мета-информации о сильных сторонах («отлично работает в высоких размерностях») и слабостях («вычислительно тяжёлый»).
2. Профилирование датасета: вычисление статистик (размерность, асимметрия, шум) и преобразование их в теги с помощью LLM.
3. Интеллектуальный выбор: символьное сопоставление с последующим рассуждением LLM для взвешивания компромиссов.

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

Когда применять: «LLM как судья» в стиле AutoML, особенно полезно для новичков без глубоких знаний статистики и ML, а также для кодификации лучших практик команды.

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

Пример кода (концептуальный):

# Псевдокод: LLM рекомендует алгоритм
import openai

dataset_stats = {
    "n_samples": 10000,
    "n_features": 50,
    "skewness": 2.5,
    "noise_level": "low"
}
prompt = f"""На основе характеристик датасета: {dataset_stats}, какой алгоритм обнаружения аномалий ты рекомендуешь? Варианты: Isolation Forest, LOF, One-Class SVM, Autoencoder. Объясни почему."""
response = openai.ChatCompletion.create(
    model="gpt-4",
    messages=[{"role": "user", "content": prompt}]
)
print(response.choices[0].message.content)

6. Мультиагентные системы для автономного обнаружения

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

Система Argos — чистый пример для облачных временных рядов. Она генерирует воспроизводимые, объяснимые правила детекции через цикл из трёх агентов:

• Агент обнаружения — ищет аномалии.
• Агент ремонта — исправляет плохие правила.
• Агент ревью — проверяет качество правил.

Заметьте: это цикл, а не прямая линия. Агент ревью отклоняет плохие правила обратно в ремонт, а хорошие, но неполные — обратно в обнаружение. Argos также объединяет сгенерированные LLM правила с существующими продуктивными детекторами, давая лучшее из двух миров.

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

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

Пример кода (концептуальный):

# Псевдокод: мультиагентная система
class DetectionAgent:
    def detect(self, data):
        # возвращает список аномалий
        pass

class RepairAgent:
    def repair(self, rule):
        # исправляет правило
        pass

class ReviewAgent:
    def review(self, rule):
        # возвращает 'accept' или 'reject'
        pass

# Цикл
rule = initial_rule
while True:
    anomalies = DetectionAgent.detect(data)
    new_rule = RepairAgent.repair(rule, anomalies)
    decision = ReviewAgent.review(new_rule)
    if decision == 'accept':
        break
    rule = new_rule

Какой паттерн выбрать?

Вот краткая шпаргалка:

• Быстро прототипировать на текстовых данных → #1 Прямая детекция
• Исправить нехватку данных / проблему ложных срабатываний → #2 Аугментация
• Превратить метки в обоснованные действия → #3 Объяснение
• Улучшить классические алгоритмы более богатыми признаками → #4 Извлечение признаков
• Перестать мучиться с выбором модели → #5 Выбор модели
• Построить полностью автономную систему → #6 Мультиагентные системы

Практический вывод

LLM — не единый инструмент, который вы прикручиваете к обнаружению аномалий. Они могут затронуть каждый этап пайплайна: от извлечения признаков до детекции и объяснения. Выбирайте паттерн, который соответствует вашим реальным ограничениям, а не самый модный. Скучный PCA на хороших эмбеддингах победит шестиагентную систему за $40 за инференс в каждом раунде.

Что делать прямо сейчас: выберите одну задачу обнаружения аномалий в вашем проекте и примените к ней паттерн №4 (извлечение признаков через эмбеддинги + PCA). Это самый быстрый способ получить улучшение с минимальными рисками.