Простой

6 мин

7.3K

Введение

Когда мы тестируем LLM-приложение в режиме black box, мы видим только интерфейс: отправили сообщение — получили ответ. При этом модель под капотом может быть любой: DeepSeek, Qwen, GLM, Mistral, Llama, Claude, GPT, Gemini или локальная fine-tuned модель. Для обычного пользователя это часто неважно. Для security-тестирования — важно.

В AI cybersecurity это часть reconnaissance: перед тем как оценивать устойчивость приложения к prompt injection, jailbreak-попыткам, утечкам системного промпта или ошибкам в RAG-слое, полезно понимать, какая модельная семья работает внутри. Разные модели по-разному отвечают на странные Unicode-строки, mixed-language запросы, вопросы о собственной идентичности, спорные утверждения и безопасные отказы.

Я попробовал воспроизвести идею статьи LLMmap: Fingerprinting For Large Language Models в упрощённом виде: собрать одинаковые probe-промпты с нескольких моделей OpenRouter и проверить, можно ли отличать модели по совокупности ответов.

Что такое LLM fingerprinting

LLM fingerprinting — это попытка определить модель или модельную семью по наблюдаемому поведению. Аналогия из классического security — OS fingerprinting: мы не видим операционную систему напрямую, но можем отправлять сетевые пакеты и смотреть, как система отвечает.

С LLM всё похоже: probe prompt → black-box chatbot → response

Один ответ почти ничего не доказывает. Модель может галлюцинировать, скрывать своё имя, быть обёрнута system prompt'ом или работать через RAG. Поэтому более надёжная идея — использовать не один вопрос вроде «какая ты модель?», а набор разных probe‑запросов и смотреть на поведение в совокупности.

В LLMmap эта идея формулируется как активный fingerprinting: отправляем заранее подобранные запросы, собираем пары (query, response), а затем классифицируем модель по получившемуся behavioural trace.

В оригинальной статье авторы сообщают, что LLMmap определяет 42 версии LLM с точностью выше 95% при использовании всего 8 взаимодействий. Важно: это результат их полноценного research setup — с большим набором моделей, специальной процедурой выбора probe-запросов, train/test разделением по prompting configurations и обученной inference model. В этом проекте я не пытаюсь заявить такую же точность. Цель ниже скромнее: сделать учебную MVP-реплику идеи и проверить, появляется ли похожий сигнал на маленьком датасете.

Цель проекта

1. Выбрать несколько фиксированных моделей в OpenRouter.

2. Подготовить набор probe-промптов в стиле LLMmap.

3. Собрать ответы всех моделей на одинаковые промпты.

4. Разделить данные на train / validation / test.

5. Проверить, сможет ли LLM-судья определить модель по нескольким ответам из test.

Модели

В текущем MVP использовались 4 модели OpenRouter с фиксированными model ID, без latest-алиасов:

Категории probe-промптов

Вместо обычного benchmark'а «математика / код / перевод» я использовал 6 категорий, вдохновлённых LLMmap-style подходом.

Всего в датасете 36 промптов: по 6 промптов на категорию.

Примеры того, что здесь интересно измерять:

• отвечает ли модель на прямой вопрос «кто ты?» или уходит в общую формулировку;

• как модель объясняет свои ограничения;

• насколько формален или подробен отказ;

• как модель обрабатывает смешение языков;

• насколько устойчиво следует формату;

• добавляет ли лишние дисклеймеры;

• как меняется стиль при “обёрнутых” запросах.

Как собирались данные

Для каждой модели каждый промпт запускался 4 раза. Параметры генерации были общими для всех моделей.

Итоговый размер полного набора: 4 модели × 36 промптов × 4 повтора = 576 строк JSONL

Одна строка JSONL — это один ответ одной модели на один prompt в одном repeat:

{
  "run_id": "openrouter_mvp_001",
  "sample_id": "qwen3_6_flash__banner_001__rep_0",
  "provider": "openrouter",
  "model_id": "qwen/qwen3.6-flash",
  "label": "qwen3_6_flash",
  "model_family": "qwen",
  "prompt_id": "banner_001",
  "prompt_category": "banner_grabbing",
  "prompt": "...",
  "system_prompt_id": "default_neutral_ru",
  "temperature": 0.7,
  "top_p": 1.0,
  "max_tokens": 512,
  "repeat_index": 0,
  "response": "...",
  "split": "train",
  "usage": {
    "prompt_tokens": null,
    "completion_tokens": null,
    "total_tokens": null
  },
  "error": null
}

Train / validation / test split

Поэтому split сделан по prompt_id: все повторы одного prompt остаются в одной выборке.

Текущая схема:

train: 24 prompt_id
val:    6 prompt_id
test:   6 prompt_id

В val и test лежит по одному prompt на каждую из 6 категорий. При 4 моделях и 4 повторах test содержит: 4 модели × 6 test prompt’ов × 4 повтора = 96 строк

Как оценивалось качество

В этом MVP я не обучал отдельный sklearn/embedding-классификатор. Оценка сделана через few-shot LLM-as-judge baseline.

Схема такая:

1. Из train-части берутся few-shot примеры ответов известных моделей.

2. Для каждой истинной модели из test берётся набор её ответов.

3. LLM-судье показываются few-shot примеры и test-ответы.

4. Судья должен вернуть predicted_label.

Судья по умолчанию — openai/gpt-4o-mini

Важно: это не оценка по каждой строке test. Это multi-probe оценка: судья получает не один ответ, а несколько ответов одной и той же неизвестной модели.

Для одного прогона с trials=10 и четырьмя моделями получается: 10 trials × 4 модели = 40 решений судьи.

Результаты

В одном из прогонов результат получился таким:

micro accuracy ≈ 0.975
macro accuracy ≈ 0.975

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

Матрица ошибок:

То есть из 40 решений была одна ошибка: один раз ответы qwen3_6_flash были отнесены к deepseek_v4_flash. Остальные модели в этом прогоне были определены без ошибок.

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

Что он показывает:

• на маленьком closed-set наборе поведенческие различия действительно заметны;

• multi-probe подход работает лучше, чем попытка угадывать по одному ответу;

• даже простой LLM-as-judge baseline может извлекать полезный сигнал из ответов.

Чего он не показывает:

• что модель можно всегда определить с точностью 97.5%;

• что метод устойчив к другим system prompt'ам;

• что он будет работать на десятках моделей;

• что он обобщается на production-чат-боты с RAG, guardrails и post-processing;

• что это полноценная реализация LLMmap.

Ограничения

1. Мало моделей

Сейчас в MVP 4 модели. Это достаточно для демонстрации, но мало для полноценной статьи с сильными обобщениями. Следующий шаг — расширить набор до 6–10 моделей и добавить больше близких пар внутри одной семьи.

2. Маленький test set

В test всего 6 prompt_id. Лучше увеличить число test-промптов и запускать несколько разных split'ов.

3. Возможен bias судьи

LLM-судья может иметь свои предпочтения и скрытое знание о стиле моделей. Для более честной оценки нужно сравнить несколько судей и добавить классический ML baseline.

4. Нет open-set сценария

Сейчас задача closed-set: судья выбирает одну из известных моделей. В реальности модель может быть неизвестной. Для этого нужен класс unknown или отдельный open-set scoring.

Как развивать проект дальше

Самые полезные следующие шаги:

1. Расширить модели

2. Проверить устойчивость к system prompt

Сейчас используется один нейтральный system prompt. Следующий шаг — собрать несколько конфигураций:

нейтральный ассистент
корпоративный support bot
краткий technical assistant
строгий JSON-only assistant

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

3. Добавить open-set режим

Выводы

Эксперимент показал, что даже простой набор probe-промптов уже позволяет извлекать заметный behavioral fingerprint LLM-моделей. На небольшом closed-set наборе из 4 моделей few-shot LLM-судья смог определить модель по нескольким test-ответам с высокой точностью в одном прогоне.

Главный практический вывод: спрашивать «какая ты модель?» недостаточно. Гораздо полезнее собирать набор ответов на разные типы запросов: self‑identification, metadata, alignment, multilingual, malformed input и prompt wrappers. Именно совокупность ответов даёт сигнал.

Репозиторий

Ссылка на репозиторий с реализацией