Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Персонализацию LLM научились обновлять по истории пользователя без дообучения и отдельной копии весов для каждого профиля. FleetPilot хранит менее 1 МБ на пользователя против примерно 18 МБ у персонального LoRA-адаптера, хотя препринт не рецензирован и все числа получили сами авторы. Такой подход меняет расчёт инфраструктуры для ассистентов, рекомендательных интерфейсов и агентов, где предпочтения быстро устаревают.
Как история превращается в управляющие векторы
Обычная персонализация добавляет историю пользователя в запрос, дообучает адаптер или генерирует несколько ответов и выбирает лучший с помощью модели оценки. Первый вариант удлиняет контекст, второй требует обучения и развёртывания весов, третий увеличивает число генераций.
FleetPilot оставляет базовую модель замороженной и вмешивается в её внутренние активации во время генерации. Для каждой сохранённой пары из запроса и ответа система дважды пропускает один и тот же текст через модель: с подходящим пользовательским контекстом и с нерелевантным. Разница между внутренними состояниями показывает, как контекст с предпочтениями изменил обработку неизменного ответа.
Метод не сводит эту разницу к одному общему направлению. Он отдельно извлекает сигналы после блока внимания и из выхода MLP, потому что эти части модели по-разному влияют на продолжение текста. Получившиеся векторы сохраняются в словаре пользователя вместе с историческими взаимодействиями.
Для нового запроса FleetPilot ищет семантически близкие записи, объединяет их в два вектора и вводит каждый в соответствующую часть модели. Поэтому предпочтение выбирается под конкретный запрос, а не закрепляется в одном постоянном профиле. Новое взаимодействие можно добавить в словарь без градиентного спуска, состояния оптимизатора и повторного развёртывания модели.
Это отличает FleetPilot и от длинного пользовательского контекста. Сервису не требуется прикладывать всю историю к каждой генерации: он извлекает несколько подходящих сигналов и проводит один авторегрессионный проход. Однако сначала системе всё равно нужно построить векторы из записанных запросов и ответов.
Где точечное управление выдержало проверку
Метод проверяли на генерации заголовков, написании аннотаций и персональных вызовах веб-функций. Сравнение охватило персонализацию через контекст, параметрические адаптеры, модели предпочтений и другие способы управлять активациями. Таким образом, работа покрывает короткий текст, длинный текст и структурированные действия, но не подтверждает результат для других типов задач и базовых моделей.
В опыте с сокращённой историей на пользователя оставалось в среднем около шести взаимодействий. FleetPilot получил ROUGE-1 0,3920 против 0,3908 у ближайшего соперника; эта метрика измеряет совпадение отдельных слов с эталонным ответом. Лидерство сохранилось при всех проверенных долях истории, но на самом разреженном варианте отрыв составил лишь 0,0012 пункта, поэтому практическая разница зависит от задачи.
За персонализацию пришлось заплатить задержкой. На одной NVIDIA H100 метод добавил от 6 до 16% к времени прямой генерации в зависимости от набора данных. Основные расходы пришлись на поиск подходящих векторов и их введение в модель.
Эксперимент также моделировал смену интересов во времени: при оценке использовали только взаимодействия, которые предшествовали текущему запросу. Здесь запрос-зависимый профиль полезнее единого вектора пользователя, потому что недавние и тематически близкие записи не смешиваются со всей историей без разбора.
Когда FleetPilot меняет архитектурный план
Работа даёт повод пересмотреть персональные LoRA-адаптеры, если продукт обслуживает много пользователей с короткой и быстро меняющейся историей. FleetPilot убирает цикл обучения для каждого обновления профиля и сокращает объём пользовательского состояния. При росте аудитории это упрощает хранение, версионирование и переключение персонализаций между запросами.
Цена такого решения — более тесная интеграция с моделью. Нужно читать активации внутри блоков внимания и MLP, а затем изменять их во время прямого прохода. Команда, которая вызывает модель только через закрытый API генерации, обычно не имеет такого интерфейса; для неё результат работы не превращается в готовую замену контекстной персонализации.
FleetPilot выглядит практичнее там, где модель развёрнута под контролем команды, предпочтения поступают по одному взаимодействию, а несколько дополнительных процентов задержки допустимы. Если профиль стабилен и общий адаптер уже обучается пакетно, выигрыш от немедленного обновления будет менее существенным.
Главный инженерный вывод касается не качества одной метрики, а места, где хранится персонализация. Её можно вынести из промпта и весов в небольшой словарь внутренних направлений, выбираемых для каждого запроса. Работа показывает жизнеспособность этой схемы на трёх классах задач, но перенос на конкретную модель и рабочую нагрузку всё равно требует собственного замера задержки и качества.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
