Техническое расследование: как обнаружить производные модели через анализ весов и кода

Проблема: как отличить оригинальную модель от производной?

В мире open-source LLM постоянно появляются новые модели, которые заявляют о революционных архитектурах и улучшениях. Но как понять, является ли модель действительно оригинальной разработкой или просто производной от существующего проекта с минимальными изменениями? Эта проблема особенно актуальна для сообщества, где честность и прозрачность имеют критическое значение.

Методы технического расследования

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

1 Анализ косинусной схожести весов

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

import torch
import numpy as np
from sklearn.metrics.pairwise import cosine_similarity

def compare_model_weights(model1, model2):
    """
    Сравнивает веса двух моделей слой за слоем
    Возвращает словарь с косинусной схожестью для каждого слоя
    """
    similarities = {}
    
    # Получаем состояния моделей
    state1 = model1.state_dict()
    state2 = model2.state_dict()
    
    for key in state1.keys():
        if key in state2:
            # Преобразуем тензоры в векторы
            w1 = state1[key].flatten().numpy()
            w2 = state2[key].flatten().numpy()
            
            # Вычисляем косинусную схожесть
            similarity = cosine_similarity([w1], [w2])[0][0]
            similarities[key] = similarity
            
    return similarities

# Пример использования
similarities = compare_model_weights(original_model, derived_model)

# Анализ результатов
high_similarity_layers = {k: v for k, v in similarities.items() if v > 0.95}
print(f"Слоёв с косинусной схожестью > 0.95: {len(high_similarity_layers)}")

2 Исследование архитектуры кода

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

Что нужно искать в коде моделирования (например, modeling_solar.py или аналогичных файлах):

• Идентичные имена классов и функций
• Совпадающие значения гиперпараметров
• Одинаковые архитектурные трюки и хаки
• Специфические константы и магические числа

# Пример специфической константы в коде моделирования
# Оригинальная модель может содержать уникальные значения

class SolarAttention(nn.Module):
    def __init__(self, config):
        super().__init__()
        # ... обычные параметры ...
        
        # Специфическая константа для Multi-Token Prediction
        self.mtp_factor = 92  # Уникальное значение, которое редко меняется

3 Анализ конфигурационных файлов

Конфигурационные файлы моделей содержат множество параметров, которые могут быть скопированы без изменений. Сравнение config.json или model_config.yaml часто выявляет прямые заимствования.

{
  "architectures": ["SolarForCausalLM"],
  "attention_dropout": 0.0,
  "bos_token_id": 1,
  "eos_token_id": 2,
  "hidden_act": "silu",
  "hidden_size": 7168,
  "initializer_range": 0.02,
  "intermediate_size": 28672,
  "max_position_embeddings": 131072,
  "model_type": "solar",
  "num_attention_heads": 56,
  "num_hidden_layers": 80,
  "num_key_value_heads": 8,
  "rms_norm_eps": 1e-05,
  "rope_theta": 1000000.0,
  "tie_word_embeddings": false,
  "torch_dtype": "bfloat16",
  "transformers_version": "4.36.0",
  "use_cache": true,
  "vocab_size": 32000
}

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

Этап 1: Подготовка инструментов

1. Установите необходимые библиотеки:

pip install torch transformers numpy scikit-learn
pip install huggingface-hub
pip install git+https://github.com/huggingface/peft.git

2. Загрузите модели для сравнения:

from transformers import AutoModelForCausalLM, AutoConfig
import torch

# Загрузка оригинальной модели
try:
    original_model = AutoModelForCausalLM.from_pretrained(
        "upstage/SOLAR-10.7B-Instruct-v1.0",
        torch_dtype=torch.float16,
        device_map="auto"
    )
except:
    print("Оригинальная модель недоступна, используем веса из локального хранилища")

# Загрузка подозрительной модели
derived_model = AutoModelForCausalLM.from_pretrained(
    "suspicious/model-name",
    torch_dtype=torch.float16,
    device_map="auto"
)

Этап 2: Анализ весов

Создайте полную сравнительную таблицу весов:

Этап 3: Анализ кода

Сравните файлы моделирования по нескольким критериям:

import difflib
from pathlib import Path

def compare_code_files(file1_path, file2_path):
    """Сравнивает два файла кода и возвращает процент схожести"""
    with open(file1_path, 'r') as f1, open(file2_path, 'r') as f2:
        lines1 = f1.readlines()
        lines2 = f2.readlines()
    
    # Используем SequenceMatcher для сравнения
    matcher = difflib.SequenceMatcher(None, lines1, lines2)
    similarity = matcher.ratio()
    
    # Находим совпадающие блоки
    matching_blocks = matcher.get_matching_blocks()
    
    return {
        'similarity': similarity,
        'matching_blocks': matching_blocks,
        'total_lines': len(lines1) + len(lines2)
    }

# Пример использования
result = compare_code_files(
    "solar/modeling_solar.py",
    "derived/modeling_derived.py"
)
print(f"Схожесть кода: {result['similarity']:.2%}")

Этап 4: Проверка архитектурных особенностей

GLM-архитектуры имеют специфические особенности, которые редко меняются:

• Multi-Token Prediction (MTP): проверьте наличие и реализацию
• Positional Encoding: сравните тип и параметры (RoPE, ALiBi и т.д.)
• Normalization layers: тип нормировки (RMSNorm, LayerNorm)
• Activation functions: функции активации (SiLU, GELU, ReLU)

Типичные ошибки при анализе

Кейс-стади: обнаружение производной модели Solar

Рассмотрим реальный пример, основанный на недавних событиях в сообществе:

1. Начальные подозрения: Новая модель заявляет о революционной архитектуре, но показывает производительность, идентичную существующей модели Solar.
2. Анализ весов: Косинусная схожесть слоёв достигает 0.989, что статистически невозможно для независимой разработки.
3. Исследование кода: Файл modeling_solar.py содержит идентичные имена классов и специфическую константу "92" для MTP.
4. Архитектурный анализ: Все гиперпараметры (hidden_size, num_layers, num_heads) полностью совпадают.
5. Заключение: Модель является производной с минимальными изменениями.

Этические соображения и лучшие практики

При публикации результатов технического расследования важно соблюдать баланс:

• Прозрачность: Предоставляйте все данные и методологию
• Верификация: Позвольте сообществу самостоятельно проверить выводы
• Конструктивность: Фокусируйтесь на технических аспектах, а не на личных атаках
• Открытость: Делайте код и инструменты анализа доступными для всех

Если вы хотите углубиться в анализ архитектур моделей, рекомендую прочитать статью «Как «мыслят» Llama-3 и Qwen-2.5: сравниваем геометрию внутренних представлений», где подробно разбираются внутренние механизмы работы LLM.

Инструменты для автоматического анализа

Для упрощения процесса можно использовать следующие инструменты:

# Пример класса для комплексного анализа
class ModelForensicAnalyzer:
    def __init__(self, model1_path, model2_path):
        self.model1_path = model1_path
        self.model2_path = model2_path
        
    def analyze(self):
        """Выполняет полный анализ моделей"""
        results = {
            'weight_similarity': self.compare_weights(),
            'code_similarity': self.compare_code(),
            'config_similarity': self.compare_configs(),
            'architecture_similarity': self.compare_architecture(),
            'conclusion': self.draw_conclusion()
        }
        return results
    
    def compare_weights(self):
        # Реализация сравнения весов
        pass
    
    def compare_code(self):
        # Сравнение файлов моделирования
        pass
    
    def compare_configs(self):
        # Сравнение конфигурационных файлов
        pass
    
    def compare_architecture(self):
        # Сравнение архитектурных особенностей
        pass
    
    def draw_conclusion(self):
        # Формирование заключения на основе всех данных
        pass

FAQ: Часто задаваемые вопросы

Как отличить fine-tuning от полного копирования?

Fine-tuning обычно затрагивает только последние слои модели (классификатор или адаптеры), в то время как полное копирование сохраняет все слои практически без изменений. При fine-tuning косинусная схожесть ранних слоёв остаётся высокой, но последние слои могут значительно отличаться.

Что делать, если модель загружена в разных форматах?

Используйте инструменты конвертации (например, transformers для загрузки моделей в разных форматах) или приведите обе модели к единому формату перед сравнением. Для работы с разными форматами моделей может быть полезно ознакомиться с материалом «Разгон 6700XT под ROCm: полный гайд по сборке стека для локальных LLM».

Какова погрешность измерений косинусной схожести?

Для float16/float32 моделей погрешность сравнения весов составляет менее 0.001. Значения выше 0.98 практически гарантированно указывают на прямое копирование. Случайные совпадения редко превышают 0.95.

Можно ли скрыть происхождение модели?

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

Заключение

Техническое расследование происхождения моделей — это мощный инструмент для поддержания прозрачности в open-source сообществе. Комбинация анализа весов, кода и архитектуры позволяет с высокой точностью определить, является ли модель оригинальной разработкой или производной.

Главный принцип — не запрещать производные модели (они являются важной частью экосистемы), а обеспечивать честность и прозрачность. Если модель основана на существующей работе, это должно быть чётко указано в документации.

Для тех, кто хочет глубже понять внутреннее устройство моделей, рекомендую ознакомиться с исследованием «Как Llama 3.2 3B думает внутри: удивительные находки трассировки активаций», где рассматриваются методы анализа внутренних представлений моделей.

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