Large Language Model Programs
Imanol Schlag, Sainbayar Sukhbaatar, Asli Celikyilmaz, Wen-tau Yih, Jason Weston, Jürgen Schmidhuber, Xian Li
Статья: https://arxiv.org/abs/2305.05364

Любопытная работа, я её прочитал из-за авторства Sainbayar Sukhbaatar, но тут и Шмидхубер в соавторах.

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

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

Есть другой подход, всеми любимый in-context learning, вотчина промпт-инженеров, когда результата добиваются составлением правильного промпта с примерами решения задачи, сопутствующими техниками типа Chain-of-Thought (CoT) и т.д. Здесь свои сложности, главная из которых это ограниченный размер текста, который можно подать в модель -- и тут есть тренд на увеличение контекста, вспомним тот же недавний Unlimiformer (https://news.1rj.ru/str/gonzo_ML/1507) или вот свежий анонс от Anthropic про новую версию Claude с контекстом в 100k (https://www.anthropic.com/index/100k-context-windows). Да и у того же GPT-4 (https://news.1rj.ru/str/gonzo_ML/1383) где-то до сих пор висит в загашнике модель с контекстом в 32k. Есть и более тонкие сложности, например, в том, что в сложном многоходовом промпте шаги могут интерферировать между собой и модель может отвлекаться на то, на что в моменте отвлекаться не надо.

Авторы предлагают альтернативный путь под названием LLM Programs, который можно рассматривать как развитие in-context learning. Здесь LLM встраивается в программу (на обычном языке программирования, например, на питоне) и хранением состояния и ведением модели по шагам занимается этот внешний для модели код. Плюсы в том, что языки программирования для этого приспособлены замечательно, и если мы уже структурировали последовательность шагов решения задачи (что нам обычно нужно сделать и в случае промпт-инжиниринга, да и для файнтюнинга часто надо достаточно хорошо понять задачу, чтобы нагенерить примеров), то задать их внешним кодом может быть и проще. Как бонус, растёт размер доступного контекста и шаги не интерферируют между собой, потому что теперь контекст не забивается данными, не относящимися к другим шагам алгоритма. На каждом шаге промпт строго специфичный для этого шага.

Ключ для решения задачи через LLM Program -- это способность декомпозировать решение задачи в последовательность более простых шагов (и очевидно не со всеми задачами такое легко сделать). Выход каждого шага надо парсить, собирать важные части состояния программы в этом высокоуровневом коде, генерить новые промпты для новых шагов. Этот подход отличается от предыдущих работ, где модель использовала внешние тулы, типа калькуляторов или интерпретаторов кода (например, Toolformer, https://news.1rj.ru/str/gonzo_ML/1305, но не только, LaMDA, например, тоже это умела, https://news.1rj.ru/str/gonzo_ML/1229). Там за поддержание состояния отвечала LLM, а здесь наоборот.

Чем такой подход хорош? Ну, во-первых, не требуется (или требуется мало) файнтюнинг. Во-вторых, можно таким образом описать достаточно сложную и развесистую задачу, которую описать промптом или обучить может быть весьма непросто. Попутно появляются более точные спецификации входных и выходных данных для разных шагов программы, с этим проще и тестировать, и отлаживаться, и оценивать качество. Интерпретируемость тоже выше. И защиты разные проще ставить. Ну и интерференции между шагами нет, LLM работать проще, промпт инженеру работать проще.

Дальше в работе разбирают пример создания вопросно-ответной системы на базе LLM. Таких систем сейчас уже миллион (и много было до LLM). Как сейчас решается задача ответов на вопросы, например, по корпоративному сайту?

Сайты часто апдейтятся, так что замороженная модель не вариант, она быстро устареет и не сможет ответить на вопросы про новые продукты. Вариант с постоянным переобучением модели на каждый апдейт сайта выглядит не очень реалистичным, и дорого, и долго, и возни много. Поэтому обычно индексируют страницы сайта, кладут в какую-нибудь базу, часто векторную (пользуясь случаем, порекламирую Unum и их свежую библиотеку USearch, на которой можно быстро собрать свой собственный векторный движок, а также посты Ашота https://ashvardanian.com/posts/abusing-vector-search/), ну и дальше по запросу пользователя подтягиваются релевантные документы, отправляются в качестве контекста в LLM, и та уже отвечает на вопрос с заданным контекстом (если всё влезло в контекст).

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

Проверялись на датасете StrategyQA (https://arxiv.org/abs/2101.02235), содержащим задачи бинарной классификации, решение которых подразумевает многоходовое рассуждение. Типа “Проникает ли солнечный свет в самое глубокое место Чёрного моря?”. Для ответа надо найти эту максимальную глубину (2км) а также информацию про то, что свет проникает в воде до глубины 1км, и сделать вывод. Другой пример, это вынесенный в заголовок работы про датасет вопрос “Did Aristotle use a laptop?”. Можно было бы задать вопрос, из которого последовательность шагов рассуждения следует явно, например, “Was Aristotle alive when the laptop was invented?”, но датасет фокусируется на вопросах, где такая последовательность подразумевается неявно. В датасете всего 2780 вопросов, из них только для 918 есть параграфы с evidences, подкрепляющие все шаги рассуждения. В текущей работе ограничиваются этим подмножеством, иначе пришлось бы полагаться на выучивание LLM каких-то фактов во время предобучения.

В качестве LLM взяли OPT-175B. По дефолту она не очень хорошо умеет следовать инструкциям, у неё не было файнтюнинга на на инструкции, ни на разговорные данные.

Для решения задачи evidence-supported question-answering она разбивается на этап фильтрации данных и этап поиска по дереву.

На этапе фильтрации, имея вопрос, мы проходим по всем параграфам и отбираем наиболее релевантные. Например, с помощью few-shot промпта мы просим LLM ответить (да/нет), релевантен ли данный параграф заданному вопросу. Проверялись на подмножестве размером 300 из StrategyQA, где каждому вопросу был сопоставлен параграф, релевантный или нет, 50/50. OPT-175B и text-davinci-002 дают качество не сильно выше случайного бейзлайна, до 56%. Более продвинутая 11B Tk-Instruct (https://aclanthology.org/2022.emnlp-main.340/) не сильно лучше со своими 61.6%.

Из-за низкого качества такого подхода собрали альтернативный, который считает average negative log-likelihood (NLL) вопроса в сочетании с предшествующим параграфом текста и далее ранжирует результаты. Оценивались на датасете где для каждого вопроса было 100 параграфов и только один из них релевантный (так что случайное угадывание даёт 1%). Получили top-1 accuracy в 79%, и top-5 в 93%. Для этого подсчёта обычно надо иметь доступ к самой модели, в API такое вынесено не всегда.

Далее наступает этап построения цепочек вывода. Это делается через поиск по дереву, где корнем является вопрос, а на каждом уровне дерева находятся множество параграфов с возможными evidences, которые используются как контекст для генерации следующего шага. Каждый путь по дереву это потенциальная цепочка вывода. Делать вывод по всем возможным цепочкам нереалистично, поэтому все имеющиеся цепочки ранжируются и происходит расширение самой высокоранговой. Это такая вариация beam search. Процесс останавливается когда произведён ответ или же прошло максимально разрешённое число шагов.