Почему fine-tuning для regex - это как стрелять из пушки по воробьям
Вы сидите с кучей неструктурированных логов. Нужно написать десятки декодеров для Wazuh или другого SIEM. Каждый лог - свой формат, своя структура. Классический путь - собрать датасет, арендовать GPU, дообучить модель. Месяцы работы, тысячи долларов.
А теперь представьте: вы берете современную локальную LLM, пишете правильный промпт и получаете работающий regex через 30 секунд. Без обучения. Без отправки данных в облако. Без месячных циклов разработки.
На 09.02.2026 актуальные модели для этой задачи - Llama 3.2 11B Vision или Mistral-Nemo 12B. Они достаточно умны для regex, но достаточно легки для локального запуска. Fine-tuning для генерации паттернов - это избыточно.
Архитектура, которая работает прямо сейчас
Вот что происходит в типичном проекте парсинга логов: у вас есть старые системы, кастомные приложения, облачные сервисы - все пишут логи по-своему. Wazuh требует regex-декодеры. Вы либо тратите недели на ручное написание, либо пытаетесь автоматизировать через ML.
Мой подход проще. Вместо обучения модели распознавать тысячи форматов, я учу ее одной вещи: превращать пример лога в регулярное выражение. Вся "интеллектуальная" работа сводится к правильно составленному промпту.
1Выбор модели: не самая большая, а самая подходящая
Для генерации regex не нужны монстры на 70 миллиардов параметров. Нам нужна модель, которая:
- Понимает структурированный текст (логи - это структурированный текст)
- Знает синтаксис регулярных выражений (большинство современных LLM изучали код)
- Работает локально на обычной машине
Мой выбор на 2026 год - Qwen2.5-Coder 7B. Почему? Она специально тренировалась на кодогенерации, включая regex паттерны. Запускается на ноутбуке с 16GB RAM через llama.cpp. Альтернатива - CodeLlama 13B, но она тяжелее.
2Промпт, который заставляет модель думать как инженер
Вот где большинство проваливается. Они пишут "сгенерируй regex для этого лога". Модель выдает какую-то ерунду. Потому что она не понимает контекста.
Правильный промпт должен:
- Объяснять задачу как человеку ("ты - senior DevOps инженер")
- Давать конкретные требования ("regex должен захватывать timestamp, уровень логирования, сообщение")
- Показывать ожидаемый формат вывода
- Включать примеры (few-shot learning без обучения)
SYSTEM_PROMPT = """Ты - senior DevOps инженер, специализирующийся на парсинге логов.
Твоя задача - анализировать примеры логов и создавать регулярные выражения для их разбора.
ТРЕБОВАНИЯ К REGEX:
1. Должен корректно захватывать все значимые поля (timestamp, уровень, сообщение и т.д.)
2. Должен быть эффективным - избегать излишне сложных конструкций
3. Должен учитывать возможные вариации в формате (разные форматы дат, опциональные поля)
4. Должен работать в Python re модуле
ФОРМАТ ОТВЕТА:
```regex
ТВОЙ_REGEX_ЗДЕСЬ
```
ОБЪЯСНЕНИЕ:
Краткое описание того, что захватывает каждая группа
"""3Пример из реальной жизни: лог Apache в JSON-подобном формате
Допустим, у вас лог такого формата:
[2025-02-09T14:30:22Z] INFO {\"client_ip\": \"192.168.1.100\", \"method\": \"GET\", \"path\": \"/api/v1/users\", \"status\": 200, \"response_time\": 145}Человек потратит 10 минут на написание regex. Модель с правильным промптом сделает это за 5 секунд:
USER_PROMPT = """Сгенерируй regex для парсинга этого лога Apache:
[2025-02-09T14:30:22Z] INFO {"client_ip": "192.168.1.100", "method": "GET", "path": "/api/v1/users", "status": 200, "response_time": 145}
Нужно извлечь:
1. Timestamp в квадратных скобках
2. Уровень логирования (INFO, ERROR, WARN)
3. Все JSON-подобные поля как одну строку для последующего парсинга
"""Модель вернет что-то вроде:
^\[(.+?)\]\s+(INFO|ERROR|WARN|DEBUG)\s+\{(.+)\}$Интеграция в пайплайн: от промпта до работающего декодера Wazuh
Генерация regex - это только половина дела. Нужно интегрировать это в реальную систему. Вот как выглядит полный пайплайн:
| Шаг | Инструмент | Время |
|---|---|---|
| Сбор примеров логов | grep + awk | 5 минут |
| Генерация regex через LLM | Qwen2.5-Coder + Ollama | 30 секунд |
| Тестирование regex | Python скрипт | 1 минута |
| Создание декодера Wazuh | Шаблон XML | 2 минуты |
Весь процесс на один формат лога занимает меньше 10 минут. Раньше на это уходили часы.
Код, который превращает regex в декодер Wazuh
После того как LLM сгенерировала regex, нужно превратить его в XML для Wazuh. Я автоматизирую и это:
import re
import xml.etree.ElementTree as ET
from datetime import datetime
def regex_to_wazuh_decoder(regex_pattern, log_format_name, description):
"""Преобразует regex паттерн в декодер Wazuh"""
decoder = ET.Element("decoder")
decoder.set("name", log_format_name)
parent_decoder = ET.SubElement(decoder, "parent_decoder")
parent_decoder.text = "json"
# Создаем regex декодер
regex_decoder = ET.SubElement(decoder, "regex_decoder")
# Добавляем порядок и экстракт полей
order_elem = ET.SubElement(regex_decoder, "order")
order_elem.text = "timestamp, level, json_data"
regex_elem = ET.SubElement(regex_decoder, "regex")
regex_elem.text = regex_pattern
# Добавляем поля
fields = [
("timestamp", "timestamp"),
("level", "log_level"),
("json_data", "extracted_json")
]
for field_name, wazuh_field in fields:
field_elem = ET.SubElement(regex_decoder, f"{field_name}")
field_elem.text = wazuh_field
# Генерируем XML
tree = ET.ElementTree(decoder)
ET.indent(tree, space=" ")
xml_str = ET.tostring(decoder, encoding="unicode", method="xml")
return xml_str
# Пример использования
regex_from_llm = r"^\[(.+?)\]\s+(INFO|ERROR|WARN|DEBUG)\s+\{(.+)\}$"
decoder_xml = regex_to_wazuh_decoder(
regex_from_llm,
"custom_apache_json_log",
"Декодер для кастомного Apache лога в JSON-подобном формате"
)
print(decoder_xml)Ошибки, которые сведут на нет все преимущества
Я видел, как люди портят отличную идею плохой реализацией. Вот что НЕ надо делать:
Ошибка 1: Использовать общую модель вместо кодогенерирующей. GPT-4 хорош, но CodeLlama или Qwen2.5-Coder сделают это лучше и дешевле.
Ошибка 2: Давать модели слишком мало контекста. "Сгенерируй regex" без примеров, требований, формата вывода - гарантия провала.
Ошибка 3: Не тестировать результат. LLM может сгенерировать синтаксически правильный regex, который не работает на реальных данных. Всегда проверяйте на разнообразных примерах.
Почему это работает лучше fine-tuning
Давайте посмотрим на цифры. Fine-tuning модели под конкретный формат логов требует:
- Сбор и разметка тысяч примеров (20-40 часов)
- Аренда GPU для обучения (от $50 в час)
- Валидация и доработка модели (еще 10-20 часов)
- Деплой и интеграция (5-10 часов)
Итого: минимум 35 часов и $200-500 на один формат лога.
Промпт-инжиниринг подход:
- Сбор 5-10 примеров логов (15 минут)
- Настройка промпта (30 минут один раз)
- Генерация и тестирование regex (10 минут на формат)
- Интеграция (5 минут)
Итого: около часа на формат, ноль долларов за инфраструктуру (если запускаете локально).
Как масштабировать: от одного regex до фабрики декодеров
Один regex - это хорошо. Но что если у вас сотни форматов логов? Создайте конвейер:
- Классификатор логов - простая LLM определяет тип лога (Apache, Nginx, кастомное приложение и т.д.)
- Генератор regex - в зависимости от типа применяется специфичный промпт
- Валидатор - автоматическое тестирование regex на реальных данных
- Генератор декодеров - превращение работающего regex в конфигурацию Wazuh
Весь этот конвейер можно запустить на одной машине с локальной LLM с поддержкой Tool Calling. Без облаков, без API ключей, без лимитов на запросы.
Что делать, когда промпты не работают
Иногда даже с идеальным промптом модель выдает ерунду. Вот что попробовать:
- Few-shot примеры - покажите модели 2-3 примера "вход-выход"
- Цепочка мыслей - заставьте модель объяснить шаги перед генерацией regex
- Температура - уменьшите до 0.1-0.3 для более детерминированных ответов
- Смена модели - если Qwen не справляется, попробуйте DeepSeek-Coder или CodeLlama
Если и это не помогает - возможно, ваш лог настолько неструктурирован, что даже человеку сложно написать regex. В таком случае посмотрите в сторону AI-поиска в логах на естественном языке вместо парсинга.
Будущее: почему fine-tuning для таких задач умрет
На 2026 год мы видим четкий тренд: модели становятся умнее, а промпт-инжиниринг - более sophisticated. Зачем тратить недели на сбор датасета и обучение, если можно за час написать промпт, который работает?
Fine-tuning останется для:
- Специализированных доменов (медицина, юриспруденция)
- Задач с очень специфическим языком
- Ситуаций, где требуется полный контроль над выводом модели
Генерация regex к этим случаям не относится. Это стандартная задача, которую современные LLM решают из коробки.
Мой прогноз: к концу 2026 года 80% задач по генерации кода (включая regex) будут решаться через промпт-инжиниринг. Fine-tuning сохранится только для edge cases.
Следующий шаг: автоматизация всего пайплайна
Сейчас мы автоматизировали генерацию regex. Что дальше?
1. Автоматическое обнаружение новых форматов логов - мониторинг лог-файлов на появление нераспознанных паттернов
2. Самообучающийся промпт - система, которая улучшает промпты на основе успешных/неуспешных генераций
3. Интеграция с существующими системами - автоматическое обновление декодеров Wazuh без downtime
Попробуйте начать с малого: возьмите один сложный лог, запустите локальную LLM и сгенерируйте regex через промпт. Вы удивитесь, насколько это проще, чем кажется. А сэкономленные часы потратьте на что-то действительно важное.
(Или на кофе. Кофе - это всегда хорошая идея.)
