Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Языковую модель научили отвечать по длинному документу, не держа его текст в контексте во время генерации. В нерецензированном препринте Virginia Tech и Stanford все числа получили сами авторы: Cache2LoRA почти сравнялся с полным контекстом по качеству. Подход может ускорить сервисы, где много запросов обращаются к одним и тем же большим документам, но переносит часть затрат в подготовку памяти для каждого вопроса.
Почему записать документ в веса недостаточно
Методы класса context-to-LoRA превращают документ в низкоранговое обновление весов (LoRA). Модель применяет это небольшое обновление при ответе и не просматривает исходный текст на каждом шаге генерации.
Проблема прежних методов в том, что они записывают документ до появления вопроса. Им приходится заранее решать, какие сведения сохранить, хотя неизвестно, что понадобится пользователю. Когда в тексте есть несколько похожих фактов, нужный факт конкурирует с остальными.
В диагностическом тесте модель получала биографии нескольких людей и вопрос о годе рождения одного из них. Ошибочный ответ часто совпадал с годом из другой биографии. Когда этот посторонний год меняли в исходном тексте, ответ следовал за ним — значит, модель не просто забывала сведения, а выбирала не тот источник.
Отдельный тест выявил вторую проблему. Даже сохранив правильный факт, прежний метод слабо реагировал на требование дать короткий ответ или объяснение. Запомнить содержание и выразить его в нужной форме оказалось двумя разными задачами.
Эксперименты с фиксированным размером обновления показали, что узкое место связано не только с объёмом памяти. Когда в генератор передавали состояния, лучше выделявшие нужный фрагмент, качество росло без увеличения LoRA. Поэтому Cache2LoRA использует вопрос уже во время записи.
Как вопрос превращает кэш документа в LoRA
Сначала фиксированная базовая модель один раз читает документ и сохраняет кэш состояний внимания. Для каждого нового вопроса отдельный кодировщик обрабатывает только сам вопрос и небольшой набор обучаемых токенов памяти, но может обращаться к сохранённому кэшу документа.
Полученные состояния превращаются в отдельное LoRA-обновление для этого вопроса. Модель ответа видит инструкцию и вопрос, а сведения из документа получает через изменённые веса. Исходный текст и служебные токены памяти в контекст генерации не входят.
Такое разделение позволяет повторно использовать дорогой проход по документу. Однако готовое LoRA-обновление привязано к конкретному вопросу: другой вопрос требует новой подготовки, хотя повторно читать весь документ кодировщику не приходится.
Во время обучения модель видела ответы в нескольких стилях: короткую формулировку, полное предложение и объяснение. Её также учили не менять поведение на тексте, который не относится к документу. Это связывает извлечение факта с выполнением инструкции, а не только с воспроизведением похожих слов.
На 17 задачах Cache2LoRA получил макро-F1 0,663 против 0,671 у модели с полным документом в контексте. Макро-F1 здесь усредняет совпадение токенов ответа, давая каждой задаче одинаковый вес. Основное сравнение проводили на Qwen3-4B, дополнительные проверки — на Mistral и Gemma.
При одинаковом размере памяти Cache2LoRA превзошёл проверенные методы отбора состояний внимания по F1 и точному совпадению ответа. Некоторые из этих методов сохраняли больше слов из эталона, но хуже соблюдали требуемую форму — поэтому одной полноты для сравнения оказалось недостаточно.
Где кэш меняет архитектуру сервиса
На документе длиной 32K токенов, ответе в 256 токенов и пакете из 16 запросов скорость генерации оказалась в 5,9 раза выше, чем при полном контексте. Выигрыш появляется потому, что во время каждого шага ответа модель не пересчитывает внимание по всему документу.
Лучший сценарий для такой схемы — стабильный большой источник, к которому приходит много независимых запросов: база регламентов, техническая документация или набор материалов для аналитического сервиса. Документ можно прочитать заранее, хранить его кэш и строить компактную память под каждый вопрос.
Для единственного запроса к новому документу преимущество менее очевидно. Перед первым токеном Cache2LoRA всё равно формирует обновление, а стоимость этой подготовки растёт вместе с длиной источника. Замеры использовали кэш на GPU и не включали задержку переноса с CPU, поэтому инфраструктура хранения влияет на итоговую задержку.
Проверки охватывали индивидуальные вопросы к фиксированным документам. Многоходовые диалоги, обновление источника во время работы и объединение независимо созданной памяти из нескольких документов потребуют отдельной политики: сервису придётся решать, когда перестраивать кэш и LoRA.
Поэтому работа не предлагает прямую замену обычному поиску по документам. Она показывает другой компромисс: один раз сохранить вычислительное представление источника, перед каждым ответом собрать память под вопрос, а затем генерировать без длинного текста. Командам с повторными запросами к крупным неизменным документам имеет смысл заложить такой вариант в нагрузочное сравнение наряду с полным контекстом и отбором фрагментов.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
