Пересадить алгоритм из маленькой модели в GPT-подобный LLM? Почему это почти невозможно

Вы разработали высокоэффективный, но крошечный модуль, который решает сложную задачу (например, модульную арифметику) идеально. Теперь вы хотите "встроить" эту логику в огромный, дорогой и универсальный LLM (как GPT-4), не тратя миллионы на fine-tuning. Если бы это было возможно, это бы изменило правила игры в AI-продуктах.

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

Что такое "компилированный алгоритм" в нейросети

Чтобы понять, где ломается мост, нужно понять, что мы пытались перенести.

В мире машинного обучения часто говорят о "черных ящиках" (black box) — мы знаем, что LLM работают, но не понимаем, как. Механистическая интерпретируемость (mechanistic interpretability) — это направление, которое пытается заглянуть внутрь нейросети и найти именно алгоритмы, зашитые в её весах.

На примере модульной арифметики (например, сложение чисел по модулю 100) стало очевидно: модель не просто запомнила 9409 пар примеров. Она сконструировала сам алгоритм.

Что это значит на практике: Когда маленькая модель обучается решать чистую, изолированную задачу (например, сложение), её внутреннее состояние (residual stream) не просто хранит данные — оно формирует геометрическую структуру. В данном случае, числа лежали на окружности, и операция сложения сводилась к простому вращению векторов. Это и есть "скомпилированный алгоритм".

Именно эту структуру мы пытались вытащить из крошечной модели и "впрыснуть" в гигантскую LLM.

Почему готовые патчинг-решения не работают

Наша амбициозная гипотеза была следующей: если алгоритм — это геометрическая структура в векторе, то между двумя моделями (маленькой и большой), решающими одну задачу, должен существовать линейный оператор $W$, который переводит структуру из одной в другую.

Проще говоря: взять выходной вектор $h_A$ из маленькой модели, умножить его на $W$, и получить вектор $h_B$, который большая модель поймет и обработает.

Мы протестировали несколько подходов, и каждый раз сталкивались с провалом.

❌ Попытка 1: Случайная проекция (Проблема геометрии)

Мы взяли случайную матрицу $W$ для преобразования вектора.

• Результат: Косинусное сходство (cos\_sim) было низким, а прирост точности был статистическим шумом.
• Вывод: Случайное преобразование полностью разрушает тщательно выстроенную геометрию алгоритма. Проекция $W$ должна быть обучена.

❌ Попытка 2: Обучение через MSE (Проблема цели)

Мы обучили $W$ минимизировать среднеквадратичную ошибку (MSE) между активациями двух моделей.

• Результат: cos\_sim остался низким, а прирост точности был нулевым ($\Delta=0$).
• Почему провал: MSE оптимизирует глобальную близость между точками. Она заставляет векторы находиться рядом, но это не гарантирует, что эти векторы станут линейно разделимыми — то есть, что мы сможем провести прямую линию, чтобы отделить класс "0" от класса "1". Мы оптимизировали близость, а не структуру.

❌ Попытка 3: Обход токенизатора (Проблема языка)

Мы попробовали подать в LLM не текст, а готовые эмбеддинги (inputs\_embeds), минуя токенизатор.

• Результат: Точность резко упала.
• Вывод: LLM — это не просто сложный математический вычислитель. Это языковая модель. Без контекста, заданного текстовым промптом ("What is X + Y?"), она не понимает, что от неё хотят. Для нее два вектора — это белый шум.

Где ломается мост: Фурье против Языка

Самый важный эксперимент — это патчинг прямо в residual stream с контекстом. Мы сохранили текстовый промпт, но заменили вектор, содержащий ответ, на вектор, полученный из маленькой модели.

Диагностика: Противоречие в архитектуре

Мы обнаружили критическое противоречие:

1. Проба (Probe): Когда мы поставили линейный зонд (Linear Probe) на слое L+1, он показал точность $1.0$. Это означает: информация о правильном ответе действительно есть в residual stream.
2. Логит (Logit Lens): Но когда мы подали этот же вектор напрямую в финальный слой модели (LM head), точность упала до $0.005$. Это означает: финальный слой модели не может эту информацию прочитать.

Главный вывод: Маленькая модель кодировала числа в Фурье-базисе (как вращения на окружности). LLM (например, Phi-2) кодируют числа в языковом базисе (контекст, синтаксис, семантика).

Вы можете перенести геометрически правильный вектор, но если финальный слой LLM обучен читать только свой родной языковой базис, он увидит ваш вектор как "иероглиф" и не сможет его расшифровать.

Подводные камни: Почему это не просто патчинг

Попытка "пересадить" алгоритм — это попытка заставить языковую модель работать не как языковая, а как чистый математический процессор.

Это не просто проблема "вставить вектор". Это проблема различия в внутреннем представлении знаний:

1. Язык vs. Математика: LLM построены на принципах вероятности и контекста. Они предсказывают следующее слово, основываясь на миллиардах примеров естественного языка. Это фундаментально отличается от чистых математических преобразований, где правила абсолютны.
2. Архитектурная жесткость: LLM — это авторегрессивные трансформеры декодерного типа. Они имеют жесткий поток информации, где каждый слой и каждый механизм (Multi-Head Attention) ожидают вход в определенном "языковом" формате.
3. Недостаточность механизма внимания: Хотя внимание (Attention) — это мощный механизм, он всё равно оперирует контекстом. Если вы подаете ему чистый, "неязыковой" вектор, он не знает, как его интерпретировать в рамках языковой структуры.

Что попробовать дальше

Если вам нужно встроить надежную, узкоспециализированную логику в LLM, обходные пути, основанные на чистом патчинге векторов, скорее всего, не сработают. Вместо этого стоит рассмотреть следующие архитектурные подходы:

1. RAG (Retrieval-Augmented Generation): Это самый надежный и промышленно используемый метод. Вы не передаете логику, а передаете факты или правила. LLM читает эти правила из контекста и генерирует ответ, который должен соответствовать заданным ограничениям.
2. Function Calling / Tool Use: Это лучший способ "вынести" расчет из LLM. Вы не пытаетесь заставить LLM вычислять $A+B$. Вы просите LLM определить, что ей нужно использовать внешний инструмент (функцию), которая и выполнит расчет, а затем передать результат обратно в LLM для генерации финального, языкового ответа.
3. Hybrid Architectures (Гибридные системы): Создание многоступенчатых пайплайнов, где LLM используется только для планирования и интерпретации задачи, а специализированный, маленький, высокоэффективный модуль (например, на PyTorch или ONNX) используется для выполнения критических вычислений.

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

Источники

• Habr ML: Можно ли пересадить алгоритм из маленькой модели в LLM? Эксперимент с grokking, residual stream и линейной проекцией