Walking Down the Memory Maze: Beyond Context Limit...
Walking Down the Memory Maze: Beyond Context Limit through Interactive Reading
Howard Chen, Ramakanth Pasunuru, Jason Weston, Asli Celikyilmaz
Статья: https://arxiv.org/abs/2310.05029
Вечная проблема трансформеров -- ограниченный контекст и необходимость работать с длинными входами. Для решения проблемы уже существует множество подходов. Это и “просто” увеличение размера окна контекста, как правило совмещённое с какой-то модификацией механизма внимания. Про множество таких подходов мы писали типа вариантов sparse attention и/или linear attention или хотя бы не квадратичных, коих уже миллион, например Reformer (https://t.me/gonzo_ML/176), Longformer (https://t.me/gonzo_ML/292), Linformer (https://t.me/gonzo_ML/397), Big Bird (https://t.me/gonzo_ML/381) и т.п. Где-то рядом здесь также находится вариант с экстраполяцией позиционных эмбеддингов. Другие способы решения включают введение рекуррентности, и про многие их таких решений мы тоже писали. Эта ветка прослеживается начиная с Transformer-XL, Compressive transformer (https://t.me/gonzo_ML/165), Feedback memory (https://t.me/gonzo_ML/508), RMT (https://arxiv.org/abs/2304.11062), к предшественнику которого даже я приложился (https://arxiv.org/abs/2006.11527). Здесь же рядом retrieval-augmented models, про которые тоже было достаточно, например Unlimiformer (https://t.me/gonzo_ML/1507). И ещё есть подход с агентами, которые могут работать с частями текста и выполнять какие-то действия, тот же WebGPT (https://t.me/gonzo_ML/1140) или различные варианты итеративного промптинга. Но всё равно этого не хватает.
Текущая работа предлагает интересное альтернативное решение под названием MemWalker. Метод работает в два этапа.
Первый этап, построение memory tree, дерева памяти. Дерево содержит узлы, суммаризирующие куски входных данных. Для этого длинная входная последовательность нарезается на кусочки, влезающие в контекст модели. Каждый кусочек суммаризируется в текст, а несколько таких саммари далее суммаризируются в саммари следующего уровня. Так возникает древесная иерархическая структура. Дерево не зависит от запроса, который будет задаваться модели, так что его можно просчитать заранее.
По сути используются два промпта для генерации саммари, один для листьев (саммари из куска текста), другой для узлов (саммари из других саммари). Для узлов делаем суммаризацию стольких саммари, сколько влезает, потом повторяем для оставшихся.
Второй этап -- навигация. При получении запроса, MemWalker проходит по дереву в поисках релевантной информации, начиная с корня. И как только набрал её достаточно, генерирует ответ.
Здесь тоже два промпта, один для листьев (leaf prompt), другой для узлов (triage prompt). В каждом узле LLM получает саммари из всех дочерних узлов и в промпте её просят выбрать (с обоснованием, через Chain-of-Thougth, CoT с “First provide reasoning to compare the summaries before you make the decision“) в каком из пассажей наиболее вероятно содержится ответ на вопрос. В статье также написано, что если там ничего нет, то надо уйти в родительский узел, но по промпту я этого не увидел. Если дошли до листа дерева, то модель либо принимает его и отвечает на вопрос, либо откатывается к родительскому узлу.
Ответы требуются в определённом формате, если LLM не смогла это сделать, её просят перегенерить. Если не смогла три раза подряд, навигация прерывается с “no answer”. По мере навигации также поддерживается рабочая память, которая добавляется в промпт для листьев. Вроде как это контент родительских узлов.
Вообще логика оркестрации всего этого процесса описана плохо, очень много умолчаний, работа не воспроизводима в чистом виде. Как минимум явно надо трекать, где модель уже была, чтобы при возврате к родителю не уйти снова в тот же узел. Или неявно не позволять через процедуру поиска, но ничего этого не описано.
Проверялись по accuracy на трёх датасетах QuALITY, SummScreenFD, и GovReport из бенчмарка SCROLLS.
QuALITY это multiple choice question answering dataset по длинным текстам из Project Gutenberg. Оттуда взяли 187 примеров.
Howard Chen, Ramakanth Pasunuru, Jason Weston, Asli Celikyilmaz
Статья: https://arxiv.org/abs/2310.05029
Вечная проблема трансформеров -- ограниченный контекст и необходимость работать с длинными входами. Для решения проблемы уже существует множество подходов. Это и “просто” увеличение размера окна контекста, как правило совмещённое с какой-то модификацией механизма внимания. Про множество таких подходов мы писали типа вариантов sparse attention и/или linear attention или хотя бы не квадратичных, коих уже миллион, например Reformer (https://t.me/gonzo_ML/176), Longformer (https://t.me/gonzo_ML/292), Linformer (https://t.me/gonzo_ML/397), Big Bird (https://t.me/gonzo_ML/381) и т.п. Где-то рядом здесь также находится вариант с экстраполяцией позиционных эмбеддингов. Другие способы решения включают введение рекуррентности, и про многие их таких решений мы тоже писали. Эта ветка прослеживается начиная с Transformer-XL, Compressive transformer (https://t.me/gonzo_ML/165), Feedback memory (https://t.me/gonzo_ML/508), RMT (https://arxiv.org/abs/2304.11062), к предшественнику которого даже я приложился (https://arxiv.org/abs/2006.11527). Здесь же рядом retrieval-augmented models, про которые тоже было достаточно, например Unlimiformer (https://t.me/gonzo_ML/1507). И ещё есть подход с агентами, которые могут работать с частями текста и выполнять какие-то действия, тот же WebGPT (https://t.me/gonzo_ML/1140) или различные варианты итеративного промптинга. Но всё равно этого не хватает.
Текущая работа предлагает интересное альтернативное решение под названием MemWalker. Метод работает в два этапа.
Первый этап, построение memory tree, дерева памяти. Дерево содержит узлы, суммаризирующие куски входных данных. Для этого длинная входная последовательность нарезается на кусочки, влезающие в контекст модели. Каждый кусочек суммаризируется в текст, а несколько таких саммари далее суммаризируются в саммари следующего уровня. Так возникает древесная иерархическая структура. Дерево не зависит от запроса, который будет задаваться модели, так что его можно просчитать заранее.
По сути используются два промпта для генерации саммари, один для листьев (саммари из куска текста), другой для узлов (саммари из других саммари). Для узлов делаем суммаризацию стольких саммари, сколько влезает, потом повторяем для оставшихся.
Второй этап -- навигация. При получении запроса, MemWalker проходит по дереву в поисках релевантной информации, начиная с корня. И как только набрал её достаточно, генерирует ответ.
Здесь тоже два промпта, один для листьев (leaf prompt), другой для узлов (triage prompt). В каждом узле LLM получает саммари из всех дочерних узлов и в промпте её просят выбрать (с обоснованием, через Chain-of-Thougth, CoT с “First provide reasoning to compare the summaries before you make the decision“) в каком из пассажей наиболее вероятно содержится ответ на вопрос. В статье также написано, что если там ничего нет, то надо уйти в родительский узел, но по промпту я этого не увидел. Если дошли до листа дерева, то модель либо принимает его и отвечает на вопрос, либо откатывается к родительскому узлу.
Ответы требуются в определённом формате, если LLM не смогла это сделать, её просят перегенерить. Если не смогла три раза подряд, навигация прерывается с “no answer”. По мере навигации также поддерживается рабочая память, которая добавляется в промпт для листьев. Вроде как это контент родительских узлов.
Вообще логика оркестрации всего этого процесса описана плохо, очень много умолчаний, работа не воспроизводима в чистом виде. Как минимум явно надо трекать, где модель уже была, чтобы при возврате к родителю не уйти снова в тот же узел. Или неявно не позволять через процедуру поиска, но ничего этого не описано.
Проверялись по accuracy на трёх датасетах QuALITY, SummScreenFD, и GovReport из бенчмарка SCROLLS.
QuALITY это multiple choice question answering dataset по длинным текстам из Project Gutenberg. Оттуда взяли 187 примеров.
Источник: gonzo-обзоры ML статей
2023-10-16 14:49:54